Internet DRAFT - draft-vigoureux-mpls-tp-oam-requirements

draft-vigoureux-mpls-tp-oam-requirements



MPLS Working Group                                M. Vigoureux (Editor) 
Internet Draft                                           Alcatel-Lucent 
Intended status: Informational 
Expires: April 2009                                    D. Ward (Editor) 
                                                    Cisco Systems, Inc. 
 
                                                     M. Betts (Editor) 
                                                       Nortel Networks 
 
                                                       October 31, 2008 
 
 
                                      
              Requirements for OAM in MPLS Transport Networks 
                draft-vigoureux-mpls-tp-oam-requirements-01 


Status of this Memo 

   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of BCP 79. 

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that other 
   groups may also distribute working documents as Internet-Drafts. 

   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress". 

   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt 

   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html 

   This Internet-Draft will expire on April 31, 2009. 

Copyright Notice 

   Copyright (C) The IETF Trust (2008). 

 

 
 
 
 
Vigoureux et al.        Expires April 31, 2009                 [Page 1] 

Internet-Draft       OAM Requirements for MPLS-TP          October 2008 
    

Abstract 

   This document lists the requirements for Operations, Administration 
   and Maintenance functionality in MPLS networks that are used for 
   packet transport services and network operations. 

   These requirements are derived from the set of requirements specified 
   by ITU-T and first published in the ITU-T Supplement Y.Sup4 [5]. 

Conventions used in this document 

   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 [1]. 

Table of Contents 

   1. Introduction...................................................3 
      1.1. Terminology...............................................3 
      1.2. Definitions...............................................4 
      1.3. Context and Motivations...................................4 
   2. OAM Requirements...............................................5 
      2.1. Architectural Requirements................................6 
      2.2. Functional Requirements...................................7 
         2.2.1. General requirements.................................8 
         2.2.2. Connectivity and Continuity Verification.............8 
         2.2.3. Client Failure Indication............................8 
         2.2.4. Remote Defect Indication.............................8 
         2.2.5. Alarm Suppression....................................9 
         2.2.6. Packet Loss..........................................9 
         2.2.7. Delay Measurement....................................9 
         2.2.8. Route Determination.................................10 
         2.2.9. Diagnostic..........................................10 
      2.3. Operational Requirements.................................10 
      2.4. Performance Requirements.................................11 
   3. Security Considerations.......................................11 
   4. Congestion Considerations.....................................12 
   5. IANA Considerations...........................................12 
   6. Acknowledgments...............................................12 
   7. References....................................................13 
      7.1. Normative References.....................................13 
      7.2. Informative References...................................13 
   Authors' Addresses...............................................13 
   Contributing Authors' Addresses..................................14 
   Intellectual Property Statement..................................15 
   Disclaimer of Validity...........................................16 
    
 
 
Vigoureux et al.        Expires April 31, 2009                 [Page 2] 

Internet-Draft       OAM Requirements for MPLS-TP          October 2008 
    

1. Introduction 

   This document lists the requirements for Operations, Administration 
   and Maintenance functionality in MPLS networks that are used for 
   packet transport services and network operations. 

1.1. Terminology 

   AC    Attachment Circuit 

   CSF   Client Signal Fail 

   FCAPS Fault, Configuration, Accounting, Performance, Security 

   LER   Label Edge Router 

   LSP   Label Switched Path 

   LSR   Label Switching Router 

   ME    Maintenance Entity 

   MEP   Maintenance End Point 

   MIP   Maintenance Intermediate Point 

   MP    Maintenance Point 

   MS-PW Multi Segment Pseudowire 

   OAM   Operations, Administration and Maintenance 

   PE    Provider Edge 

   PSN   Packet Switched Network 

   PW    Pseudowire 

   SLA   Service Level Agreement 

   SS-PW Single Segment Pseudowire 

   S-PE  PW Switching Provider Edge 

   T-PE  PW Terminating Provider Edge 

   TCME  Tandem Connection Maintenance Entity 
 
 
Vigoureux et al.        Expires April 31, 2009                 [Page 3] 

Internet-Draft       OAM Requirements for MPLS-TP          October 2008 
    

1.2. Definitions 

   In this document we refer to a fault as the inability of a function 
   to perform a required action. This does not include an inability due 
   to preventive maintenance, lack of external resources, or planned 
   actions. See also ITU-T G.806 [3]. 

   In this document we refer to a defect as the situation for which 
   density of anomalies has reached a level where the ability to perform 
   a required function has been interrupted. See also ITU-T G.806 [3]. 

   In this document, we refer to MPLS Transport Profile (MPLS-TP) as the 
   set of MPLS functions used to support packet transport services and 
   network operations. 

   In this document we refer to a MPLS Section as a network segment 
   between two LSRs that are immediately adjacent at the MPLS layer. 

   For definitions of OAM functional components such as Maintenance 
   Point, Maintenance End Point and Maintenance Intermediate Point, 
   please refer to [7]. 
   Additional definitions can also be found in [8]. 

1.3. Context and Motivations 

   Important attributes of MPLS-TP are that 

   o  it is able to function regardless of which client signals are 
      using its connectivity service or over which transmission media it 
      is running. The client, transport network and server layers are, 
      from a functional point of view, independent layer networks. That 
      is, demarcation points exist between MPLS-TP and the client layer, 
      and between MPLS-TP and the underlying server layer. 

   o  it provides means to commit to Service Level Agreements (SLAs) 
      negotiated with customers, as well as means to monitor compliance 
      with these SLAs. 

   o  it is consistent with existing transport network OAM models. 

   In the context of MPLS-TP, the rationale for OAM mechanisms are 
   twofold as they can serve: 





 
 
Vigoureux et al.        Expires April 31, 2009                 [Page 4] 

Internet-Draft       OAM Requirements for MPLS-TP          October 2008 
    

   o  as a network-oriented mechanism (used by a transport network 
      operator) to monitor his network infrastructure and to implement 
      internal mechanisms in order to enhance the general behaviour and 
      the level of performance of his network (e.g. protection mechanism 
      in case of node or link failure). For example fault localization 
      is typically associated to this use case. 

   o  as a service-oriented mechanism (used by a transport service 
      provider) to monitor his offered services to end customers in 
      order to be able to react rapidly in case of a problem and to be 
      able to verify some of the SLA parameters (i.e. performance 
      monitoring) negotiated with the end customer. Note that a 
      transport service could be provided over several networks or 
      administrative domains that may not be all owned and managed by 
      the same transport service provider. 

   More generally, OAM is an important and fundamental functionality in 
   transport networks as it contributes to: 

   o  the reduction of operational complexity and costs, by allowing 
      efficient and automatic detection, localisation, handling, and 
      diagnosis of defects, and by minimizing service interruptions and 
      operational repair times. 

   o  the enhancement of network availability, by ensuring that defects, 
      for example resulting in misdirected customer traffic are 
      detected, diagnosed and dealt with before a customer reports the 
      problem. 

   o  meet service and performance objectives, by running OAM 
      functionality which allows SLA verification in a multi-maintenance 
      domain environment and allows the determination of service 
      degradation due to, for example, packet delay or packet loss. 

   This is achieved through the support of FCAPS functionality, as 
   described in ITU-T M.3400 [2], itself relying on OAM related 
   information. 

2. OAM Requirements 

   This section lists the requirements by which the OAM functionality of 
   MPLS-TP should abide. Some requirements for this application are 
   similar to some of those listed in RFC 4377 [6]. 

   The requirements listed below may be met by one or more OAM 
   protocols, the definition or selection of these protocols is outside 

 
 
Vigoureux et al.        Expires April 31, 2009                 [Page 5] 

Internet-Draft       OAM Requirements for MPLS-TP          October 2008 
    

   the scope of this document. However, the specified solution MUST 
   inter-work with the existing MPLS and PW OAM protocols. 

2.1. Architectural Requirements 

   OAM functions SHOULD be independent of the underlying tunnelling or 
   point-to-point technology or transmission media. 

   OAM functions SHOULD be independent of the service a pseudowire may 
   emulate. 

   The set of OAM functions operated on each Maintenance Entity SHOULD 
   be independent one from another. 
   Note that independence should not be understood here in terms of 
   isolation but in terms of separate running processes. There should be 
   one OAM process running per Maintenance Entity but different OAM 
   running processes could interact (e.g. alarm summarization). 

   OAM functionality MAY be deployed in a variety of environments. In 
   some of these IP routing and forwarding capabilities are inherently 
   present (e.g. IP/MPLS) and the OAM functionality MUST also support 
   their use. Other deployment scenarios exist where IP routing and 
   forwarding capabilities are not necessarily present (e.g. MPLS-TP). 
   In these latter cases, the operation of OAM functions MUST NOT rely 
   on IP routing and forwarding capabilities. Further, it is REQUIRED by 
   this document that OAM interoperability is achieved across these 
   environments. It is also REQUIRED by this document that the two above 
   requirements are still met and still hold when interoperability is 
   achieved. 

   Furthermore, in case OAM packets need to incorporate identification 
   information of source and/or destination nodes, an IP addressing 
   structure MUST be supported. 

   When MPLS-TP is run with IP routing and forwarding capabilities, all 
   existing IP/MPLS OAM functionality (e.g. LSP-Ping, BFD and VCCV) MUST 
   be able to operate seamlessly. 

   OAM functions MUST operate and be configurable even in the absence of 
   a control plane. Conversely, OAM functions SHOULD be configurable as 
   part of connectivity (LSP or PW) management. Note that means for 
   configuring OAM functions and for connectivity management are outside 
   the scope of this document. 

   The service emulated by a single segment or a multi-segment 
   pseudowire may span multiple domains. A LSP may also span multiple 
   domains. It MUST be possible to perform OAM functions on a per domain 
 
 
Vigoureux et al.        Expires April 31, 2009                 [Page 6] 

Internet-Draft       OAM Requirements for MPLS-TP          October 2008 
    

   basis and across multiple domains. More generally it MUST be possible 
   to perform OAM functions between any two switching elements of a PW 
   or of a LSP. This is referred to as segment (or tandem connection) 
   monitoring (see [7]). Furthermore, in case of a fault or defect on 
   the service, means MUST be available for the service provider to be 
   informed of the fault even if the fault is located outside of his 
   domain. 

   OAM functions operate in the data plane. OAM packets MUST run in-
   band. That is, OAM packets for a specific Maintenance Entity MUST 
   follow the exact same data path as user traffic of that Maintenance 
   Entity. This is known as fate sharing. 

   It MUST be possible to discriminate data traffic from OAM packets. 
   This includes a means to differentiate OAM packets from user traffic 
   as well as the capability to apply specific treatment, to OAM 
   packets, at the MIPs or MEPs targeted by these OAM packets. 

   As part of the design of OAM mechanisms for MPLS-TP, a mechanism that 
   enables the realization of a channel for general purpose signalling, 
   e.g. for control, management and OAM information, associated with the 
   data plane paths, MUST be provided. Such mechanism SHOULD support the 
   operation of existing IP/MPLS OAM. 

   OAM functions MUST be able to be used for PWs, LSPs and Sections. 
   Furthermore, since LSPs MAY be stacked, OAM functions MUST be able to 
   run on each LSP, regardless of the label stack depth. 

2.2. Functional Requirements 

   Hereafter are listed the required functions composing the MPLS-TP OAM 
   tool-set. The list may not be exhaustive and as such the OAM 
   mechanisms developed in support of the identified requirements SHALL 
   be extensible and thus SHALL NOT preclude the definition of 
   additional OAM functions in the future. Furthermore, the design of 
   OAM mechanisms for MPLS-TP MUST allow the ability to support vendor 
   specific and experimental OAM functions. Vendor specific and 
   experimental OAM functions MUST be disabled by default and explicitly 
   enabled by a service provider or network operator, between nodes that 
   support them. 

   Moreover, the use of OAM functions SHOULD be optional for the service 
   provider or network operator. A network operator or service provider 
   SHOULD be able to choose which OAM functions to use and which 
   Maintenance Entities to apply them to. 


 
 
Vigoureux et al.        Expires April 31, 2009                 [Page 7] 

Internet-Draft       OAM Requirements for MPLS-TP          October 2008 
    

   Note that the functions listed below can serve the purpose of fault 
   and/or performance management. For example, connectivity verification 
   can be used for fault management application by detecting failure 
   conditions, but may also be used for performance management 
   application through its contribution to the evaluation of performance 
   metrics (e.g. unavailability time). Nevertheless, it is outside the 
   scope of this document to specify which function should be used for 
   which application. 

2.2.1. General requirements 

   If a defect or fault occurs, mechanisms MUST be provided to detect 
   it, diagnose it, localize it, and notify the appropriate entities. 
   Corrective actions SHOULD be taken according to the type of defect or 
   fault. 

   In the case of the PW Maintenance Entity, OAM mechanisms SHOULD be 
   provided to ensure that customers do not have to detect faults. The 
   OAM functions SHOULD allow the service provider to automatically 
   detect and notify the faults associated with a PW Maintenance Entity. 

2.2.2. Connectivity and Continuity Verification 

   The MPLS-TP OAM tool-set MUST provide a function to enable service 
   providers to detect loss of continuity but also mis-connectivity 
   between two points of a Maintenance Entity. 

2.2.3. Client Failure Indication 

   The MPLS-TP OAM tool-set MUST provide a function to enable a MEP to 
   propagate a client failure indication to its peer MEP when alarm 
   suppression in the client layer is not supported. 

   In cases where the OAM of the native service of an AC or a PW type 
   does not provide mechanisms to propagate failure condition 
   information, while a downstream indication of such state is needed, 
   MPLS-TP OAM SHOULD provide mechanisms for propagating AC failures and 
   their clearance across a MPLS-TP domain. 

2.2.4. Remote Defect Indication 

   The MPLS-TP OAM tool-set MUST provide a function to enable a MEP to 
   notify its peer MEP of the detection of a defect on a bi-directional 
   connection between them. 



 
 
Vigoureux et al.        Expires April 31, 2009                 [Page 8] 

Internet-Draft       OAM Requirements for MPLS-TP          October 2008 
    

2.2.5. Alarm Suppression 

   The MPLS-TP OAM tool-set MUST provide a function to enable a server 
   layer MEP to notify a failure condition or an administrative locking 
   to its client layer MEP(s) in order to suppress alarms that may be 
   generated by maintenance domains of the client layer as a result of 
   the failure condition or of the administrative locking in the server 
   layer. 

   The MPLS-TP OAM tool-set MUST allow the client layer to differentiate 
   between a defect condition and an administrative locking action at 
   the server layer ME. 

   The server layer MEP and the client layer MEPs MAY reside on the same 
   node or on different nodes. A mechanism MUST be provided for both 
   cases. 

   An alarm suppression and summarization mechanism MUST be provided. 
   For example, a fault detected at the LSP level MUST NOT trigger 
   various alarms at the PW level. 

2.2.6. Packet Loss 

   The MPLS-TP OAM tool-set MUST provide a function to enable service 
   providers to measure packet loss ratio between a pair of MEPs. Packet 
   loss ratio is the ratio of the user-plane packets not delivered to 
   the total number of user-plane packets transmitted during a defined 
   time interval. The number of user-plane packets not delivered is the 
   difference between the number of user-plane packets transmitted by 
   the source node and the number of user-plane packets received at the 
   destination node. 

2.2.7. Delay Measurement 

   The MPLS-TP OAM tool-set MUST provide a function to enable service 
   providers to measure the one-way or two-way delay of a packet 
   transmission between a pair of MEPs. Where, 

   o  One-way packet delay is the time elapsed from the start of 
      transmission of the first bit of the packet by a source node until 
      the reception of the last bit of that packet by the destination 
      node. 





 
 
Vigoureux et al.        Expires April 31, 2009                 [Page 9] 

Internet-Draft       OAM Requirements for MPLS-TP          October 2008 
    

   o  Two-way packet delay is the time elapsed from the start of 
      transmission of the first bit of the packet by a source node until 
      the reception of the last bit of the loop-backed packet by the 
      same source node, when the loopback is performed at the packet's 
      destination node. 

2.2.8. Route Determination 

   The MPLS-TP OAM tool-set MUST provide a function to enable service 
   providers to determine the route of a connection across the MPLS 
   transport network. 

2.2.9. Diagnostic 

   The MPLS-TP OAM tool-set MUST provide a function to enable service 
   providers to verify bandwidth throughput (and other diagnostic tests) 
   between a pair of MEPs. 

2.3. Operational Requirements 

   OAM functions such as connectivity and continuity verification MUST 
   NOT rely on user traffic. Dedicated OAM flows SHOULD be used to 
   detect connectivity and continuity defects. See also ITU-T G.806 .
   [3]. 
   This document does not mandate the use of a particular OAM function, 
   however, it is RECOMMENDED that connectivity and continuity 
   verification is performed on every Maintenance Entity in order to 
   reliably detect connectivity defects. 

   OAM functions MUST be applicable to bidirectional point-to-point 
   connections, and a subset of these OAM functions MUST be applicable 
   to unidirectional point-to-point and point-to-multipoint connections. 
   This subset is based on the nature of both the OAM functions and the 
   connections to which they can apply. 

   The following table describes how, on which Maintenance Entity and 
   between which points of the Maintenance Entity SHOULD the required 
   OAM functions be applied. In these tables, MEP stands for monitoring 
   from MEP to MEP, MIP stands for monitoring from MEP to MIP, U stands 
   for unidirectional, B stands for bidirectional. Crosses (x) indicate 
   the way the considered function should be applied, numbers indicate 
   the way the considered function should be applied while pointing to a 
   footnote providing additional details. 




 
 
Vigoureux et al.        Expires April 31, 2009                [Page 10] 

Internet-Draft       OAM Requirements for MPLS-TP          October 2008 
    

                          +-------------------------------------------+ 
                          |      on-demand      |      proactive      | 
                          |---------------------+----------+----------| 
                          |    MEP   |   MIP    |    MEP   |   MIP    | 
                          |----------+----------+----------+----------| 
                          | P2P |P2MP| P2P |P2MP| P2P |P2MP| P2P |P2MP| 
                          |-----+----+----------+----------+-----+----| 
                          |U |B | U  |U |B | U  |U |B | U  |U |B | U  | 
   +----------------------+--+--+----+--+--+----+--+--+----+--+--+----| 
   | cc verification      |  |x |    |  |x |    |x |x | x  |  |  |    | 
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| 
   | client fail. indic.  |  |  |    |  |  |    |  |x |    |  |  |    | 
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| 
   | remote defect indic. |  |  |    |  |  |    |  |x |    |  |  |    | 
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| 
   | alarm suppression    |  |  |    |  |  |    |x |x | x  |  |  |    | 
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| 
   | packet loss measure  |  |1 |    |  |  |    |x |2 | x  |  |  |    | 
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| 
   | delay measurement    |x |3 | x  |  |  |    |  |  |    |  |  |    | 
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| 
   | route determination  |  |x |    |  |x |    |  |  |    |  |  |    | 
   |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| 
   | diagnostic           |x |x | x  |  |  |    |  |  |    |  |  |    | 
   +----------------------+-------------------------------------------+ 
   1: single-ended packet loss measurements 

   2: in both directions of the bi-directional connection 

   3: one-way and two-way packet delay measurements 

         Table 1 : OAM functions and their applicability scope 

 

2.4. Performance Requirements 

   OAM functions SHOULD continue to meet their objectives regardless of 
   congestion conditions. See also ITU-T Y.1541 [4]. 

   Additional requirements will be incorporated in a future revision of 
   this document. 

3. Security Considerations 

   Mechanisms SHOULD be provided to ensure that unauthorized access is 
   prevented from triggering any OAM function. 
 
 
Vigoureux et al.        Expires April 31, 2009                [Page 11] 

Internet-Draft       OAM Requirements for MPLS-TP          October 2008 
    

   OAM messages MAY be authenticated. 

   An OAM packet for a Maintenance Entity MUST NOT leak out of the ME, 
   i.e. go beyond the terminating MEP. 

4. Congestion Considerations 

   A mechanism (e.g. rate limiting) MUST be provided to prevent OAM 
   messages from causing congestion in the PSN. 

5. IANA Considerations 

   There are no IANA actions required by this draft. 

6. Acknowledgments 

   The authors would like to thank all members of the teams (the Joint 
   Working Team, the MPLS Interoperability Design Team in IETF and the 
   T-MPLS Ad Hoc Group in ITU-T) involved in the definition and 
   specification of MPLS Transport Profile. 



























 
 
Vigoureux et al.        Expires April 31, 2009                [Page 12] 

Internet-Draft       OAM Requirements for MPLS-TP          October 2008 
    

7. References 

7.1. Normative References 

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement 
         Levels", BCP 14, RFC 2119, March 1997 

   [2]   ITU-T Recommendation M.3400 (2000), TMN management functions 

   [3]   ITU-T Recommendation G.806 (2006), Characteristics of transport 
         equipment - Description methodology and generic functionality 

   [4]   ITU-T Recommendation Y.1541 (2006), Network performance 
         objectives for IP-based services 

   [5]   ITU-T Supplement Y.Sup4 (2008), Transport Requirements for T-
         MPLS OAM and considerations for the application of IETF MPLS 
         Technology 

7.2. Informative References 

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

   [7]   Busi, I., Niven-Jenkins, B., "MPLS-TP OAM Framework and 
         Overview", draft-busi-mpls-tp-oam-framework, October 2008 

   [8]   Niven-Jenkins, B., Brungard, D., Betts, M., "MPLS-TP 
         Requirements", draft-jenkins-mpls-mpls-tp-requirements, October 
         2008 

Authors' Addresses 

   Martin Vigoureux 
   Alcatel-Lucent 
    
   Email: martin.vigoureux@alcatel-lucent.com 
    

   David Ward 
   Cisco Systems, Inc. 
    
   Email: dward@cisco.com 
    


 
 
Vigoureux et al.        Expires April 31, 2009                [Page 13] 

Internet-Draft       OAM Requirements for MPLS-TP          October 2008 
    

   Malcolm Betts 
   Nortel Networks 
    
   Email: betts01@nortel.com 
    

Contributing Authors' Addresses 

   Matthew Bocci 
   Alcatel-Lucent 
    
   Email: matthew.bocci@alcatel-lucent.com 
    

   Italo Busi 
   Alcatel-Lucent 
    
   Email: italo.busi@alcatel-lucent.it 
    

   Huub van Helvoort 
   Huawei Technologies Co.Ltd. 
    
   Email: hhelvoort@huawei.com 
    

   Marc Lasserre 
   Alcatel-Lucent 
    
   Email: mlasserre@alcatel-lucent.com 
    

   Lieven Levrau 
   Alcatel-Lucent 
    
   Email: llevrau@alcatel-lucent.com 
    

   Han Li 
   China Mobile Communications Corporation (CMCC) 
   Email: lihan@chinamobile.com 
    





 
 
Vigoureux et al.        Expires April 31, 2009                [Page 14] 

Internet-Draft       OAM Requirements for MPLS-TP          October 2008 
    

   Julien Meuric 
   Orange 
    
   Email: julien.meuric@orange-ftgroup.com 
    

   Philippe Niger 
   Orange 
    
   Email: philippe.niger@orange-ftgroup.com 
    

   Benjamin Niven-Jenkins 
   BT 
    
   Email: benjamin.niven-jenkins@bt.com 
    

   Jing Ruiquan 
   China Telecom 
   Email: jingrq@ctbri.com.cn 
    

   Nurit Sprecher 
   Nokia-Siemens Networks 
    
   Email: nurit.sprecher@nsn.com 
    

   Yuji Tochio 
   Fujitsu 
    
   Email: tochio@jp.fujitsu.com 
    

   Yaacov Weingarten 
   Nokia-Siemens Networks 
    
   Email: yaacov.weingarten@nsn.com 
    

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 
 
 
Vigoureux et al.        Expires April 31, 2009                [Page 15] 

Internet-Draft       OAM Requirements for MPLS-TP          October 2008 
    

   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights. Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 

   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 

   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard. Please address the information to the IETF at ietf-
   ipr@ietf.org. 

Disclaimer of Validity 

   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 

Copyright Statement 

   Copyright (C) The IETF Trust (2008). 

   This document is subject to the rights, licenses and restrictions 
   contained in BCP 78, and except as set forth therein, the authors 
   retain all their rights. 

Acknowledgment 

   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 







 
 
Vigoureux et al.        Expires April 31, 2009                [Page 16]