MPLS Working Group M. Vigoureux (Editor) Internet Draft Alcatel-Lucent Intended status: Informational Expires: January 2009 D. Ward (Editor) Cisco Systems, Inc. M. Betts (Editor) Nortel Networks July 7, 2008 Requirements for OAM in MPLS Transport Networks draft-vigoureux-mpls-tp-oam-requirements-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 7, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Vigoureux et al. Expires January 7, 2009 [Page 1] Internet-Draft OAM Requirements for MPLS-TP July 2008 Abstract This document specifies requirements for OAM (Operations and Management) functionality in MPLS networks that are used for packet transport services and network operations. The use of the term MPLS in this document refers to both MPLS PSNs and pseudowire technologies. These requirements are derived from the set of requirements specified by ITU-T and first published in the ITU-T Supplement Y.Sup4 [6]. 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...................................5 1.3.1. Transport Profile of MPLS............................5 1.3.2. Motivations..........................................6 2. OAM Requirements...............................................7 2.1. Architectural Requirements................................8 2.2. Functional Requirements...................................9 2.3. Performance Requirements.................................12 3. Security Considerations.......................................12 4. Congestion Considerations.....................................12 5. IANA Considerations...........................................12 6. Acknowledgments...............................................13 APPENDIX A : OAM Functions Information.........................14 A.1. Continuity Check.........................................14 A.2. Connectivity Verification................................14 A.3. Alarm Suppression........................................14 A.4. Lock Indication..........................................15 A.5. Packet Loss Measurement..................................15 A.6. Diagnostic Test..........................................15 A.7. Trace-route..............................................15 A.8. Delay Measurement........................................16 A.9. Remote Defect Indication.................................16 A.10. Client Signal Fail......................................16 APPENDIX B : Mapping between RFC 4377, Y.Sup4 and this document17 7. References....................................................18 7.1. Normative References.....................................18 Vigoureux et al. Expires January 7, 2009 [Page 2] Internet-Draft OAM Requirements for MPLS-TP July 2008 7.2. Informative References...................................18 Authors' Addresses...............................................18 Contributing Authors' Addresses..................................19 Intellectual Property Statement..................................20 Disclaimer of Validity...........................................21 1. Introduction This document specifies requirements for OAM (Operations and Management) functionality in MPLS networks that are used for packet transport services and network operations. The use of the term MPLS in this document refers to both MPLS PSNs and pseudowire technologies. These requirements may be met by one or more toolsets. The definition or selection of these toolsets is outside the scope of this document. 1.1. Terminology AC Attachment Circuit CSF Client Signal Fail FCAPS Fault, Configuration, Accounting, Performance, Security LER Label Edge Router LSP Label Switch 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 and Management PE Provider Edge PSN Packet Switched Network Vigoureux et al. Expires January 7, 2009 [Page 3] Internet-Draft OAM Requirements for MPLS-TP July 2008 PW Pseudowire SLA Service Level Agreement SS-PW Single Segment Pseudowire S-PE Switching Provider Edge T-PE Terminating Provider Edge TCME Tandem Connection Maintenance Entity 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 to 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 a 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. OAM packets can be inserted and extracted at various reference points, referred to as Maintenance Points (MP). These MPs are further characterized with regard to their position along the entity being monitored. The MPs can be end-points (Maintenance End Point, MEP) or intermediate points (Maintenance Intermediate Point, MIP). A MEP is capable of initiating and terminating OAM packets for fault management and performance monitoring. A MIP is capable of reacting to some OAM packets but does not initiate OAM packets. Therefore, LERs and T-PEs can be MEPs while LSRs and S-PEs can be MIPs. In case of Tandem Connection Maintenance Entity (defined below), LSRs and S- PEs can be MEPs. This document defines the following Maintenance Entities: o The PW Maintenance Entity, corresponding to end-to-end PW monitoring (between T-PEs). Vigoureux et al. Expires January 7, 2009 [Page 4] Internet-Draft OAM Requirements for MPLS-TP July 2008 o The LSP Maintenance Entity, corresponding to end-to-end LSP monitoring (between LERs). o The Tandem Connection Maintenance Entity (TCME), corresponding to one or more segment(s) of a PW or to a segment (a.k.a. sub-path) of a LSP. Note that: - A TCME could be defined between the two T-PEs of a SS-PW but there is no specific relevance to define such a TCME as it corresponds to the PW Maintenance Entity. - A TCME can be defined between a T-PE and any S-PE (and vice- versa) or between any two S-PEs on a given MS-PW. A TCME can span several PW segments, i.e. the PEs (T-PEs or S-PEs) where MEPs are located need not be adjacent on the MS-PW. - A TCME can be defined between a LER and any LSR (and vice-versa) or between any two LSRs, for that LSP. These points (LERs, LSRs) where MEPS are located do not need to be adjacent on the LSP. A TCME defined between the two LERs of a LSP corresponds to the LSP Maintenance Entity. - The LSP or MS-PW segment(s) that the TCME covers may however be dependant on administrative boundaries in case the LSP or the MS- PW spans multiple domains. - End-points of a TCME are MEPs, not MIPs. A Maintenance Entity can be viewed as the association of two (or more) Maintenance End Points that should be provisioned and managed. Each OAM flow is associated to a unique ME. MEPs of a given ME generate and/or terminate the OAM messages associated to the ME. The monitoring of a Maintenance Entity can only be performed at points where the Label associated with the Maintenance Entity is the top most label of the stack. TCMEs MAY be nested but MUST NOT overlap. 1.3. Context and Motivations 1.3.1. Transport Profile of MPLS This section does not give any requirement on MPLS-TP. Its sole intent is to describe the context in which the OAM requirements could fit and is for information only. The authors intend to move it to another draft at a later stage. A transport network must provide a means to commit, to the client signal, the quality of service and availability objectives. These objectives can be expressed in the form of a Service Level Agreement Vigoureux et al. Expires January 7, 2009 [Page 5] Internet-Draft OAM Requirements for MPLS-TP July 2008 (SLA). A transport network must also provide a means to monitor compliance to an agreed quality of service. Two important attributes of MPLS-TP (as in any transport network technology) are that o it is independent from both client and server networks. That is, demarcation points exist between MPLS-TP and the customer layer, and between MPLS-TP and the underlying tunnelling or point-to- point technology. o it is consistent with existing transport network operations and management models [8]. The purpose of a transport network is to transparently carry client signals (i.e. the stream of client PDUs or client bits), across the network, between ingress and egress (typically over several nodes). A key characteristic of transport networks is their ability to monitor and therefore maintain the integrity of the client signal between ingress and egress ports of the transport network. Networks deploying MPLS-TP are configured so as not to use specific MPLS capabilities such as ECMP, label merging (i.e. for mp2p purposes) and PHP. In the case of bidirectional connectivity, the forward and backward directions are congruent (i.e. they follow the same path and the pairing relationship between the forward and the backward directions is known in each node traversed by bidirectional LSPs). Just as for other transport technologies and associated transport networks, the presence of a distributed control plane in support of network operations is optional, and the absence of such control plane should not affect the ability to operate the network and to use MPLS- TP forwarding, OAM and protection capabilities. Finally, some MPLS-TP specific recovery mechanisms are independent of a control plane. They rely on OAM capabilities such as APS to trigger protection switching in the absence of a control plane. 1.3.2. Motivations In the context of MPLS Transport Profile the rationales for OAM mechanisms are twofold as they can serve as: Vigoureux et al. Expires January 7, 2009 [Page 6] Internet-Draft OAM Requirements for MPLS-TP July 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 performances 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 it 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. A transport service could be provided over several networks or administrative domains that may not be all owned and managed by the 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, operational repair times, and operational resources. o the enhancement of network availability, by ensuring that defects resulting in misdirected customer traffic are detected/diagnosed and can lead to appropriate consequent actions minimizing the number of defects that are not detected automatically 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 [7]. The requirements listed below may be met by one or more toolsets, the definition or selection of these toolsets is outside the scope of Vigoureux et al. Expires January 7, 2009 [Page 7] Internet-Draft OAM Requirements for MPLS-TP July 2008 this document. However, it is required that the specified solution MUST inter-work with the existing MPLS and PW OAM toolset. 2.1. Architectural Requirements OAM functions SHOULD be independent of the underlying tunnelling or point-to-point technology. OAM functions SHOULD be independent of the service a pseudowire may emulate (e.g. Ethernet). The set of OAM functions operated on each Maintenance Entity SHOULD be independent one from another. The set of OAM functions must be a self-sufficient set that does not require external capabilities to achieve the OAM objectives. 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 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 connectivity management are outside the scope of this document. The service emulated by a single segment of multi-segment pseudowire may span multiple domains. The LSP itself, supporting the pseudo- wire(s), may span multiple domains. It MUST be possible to perform OAM functions on a per domain basis and across multiple domains. 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 its domain. OAM functions operate at the data plane. OAM packets MUST run in- band. That is, OAM packets for a specific destination MUST follow the same data path as data traffic for this destination. 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 data traffic as well as the capability to apply specific treatment to OAM packets. OAM functionality MUST NOT be dependent on IP routing and forwarding capabilities as these may not be available in networks where MPLS-TP is deployed. Vigoureux et al. Expires January 7, 2009 [Page 8] Internet-Draft OAM Requirements for MPLS-TP July 2008 OAM functions MUST be able to be used for PWs and LSPs and Section. Furthermore, since LSPs MAY be stacked, OAM functions MUST be able to be run at each network layer (i.e. any level of the label stack). 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 tables below (Table 1 and Table 2) summarize the applicability of OAM functions. OAM functions SHOULD continue to meet their objectives regardless of congestion conditions. See also ITU-T Y.1541 [4]. 2.2. Functional Requirements In cases where the OAM of the native service of an AC or a PW type does not provide mechanisms to propagate failure conditions 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. 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 provided SHOULD 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. 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. The following two tables describe the required OAM functions constituting the MPLS-TP OAM toolset for Fault Management and Performance Management applications. 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 a required function, numbers indicate a required function while pointing to a footnote providing additional details. Appendix A provides a short description of the OAM functions typically supported in ITU-T defined transport networks. It is the expectation that MPLS-TP will provide an equivalent set. Vigoureux et al. Expires January 7, 2009 [Page 9] Internet-Draft OAM Requirements for MPLS-TP July 2008 +-------------------------------------------+ | Fault Management | |-------------------------------------------| | 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 | +---------------------+--+--+----+--+--+----+--+--+----+--+--+----| |continuity check | |x | | |x | |x |x | x | | | | |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| |connectivity verif. | |x | | |x | |x |x | x | | | | |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| |alarm suppression | | | | | | |x |x | x | | | | |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| |lock indication | | | | | | |x |x | x | | | | |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| |packet loss meas. | | | | | | |x |2 | x | | | | |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| |diagnostic test |x |1 | x | | | | | | | | | | |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| |trace-route | |x | | |x | | | | | | | | |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| |delay measurement | | | | | | | | | | | | | |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| |remote defect indic. | | | | | | | |x | | | | | +---------------------+-------------------------------------------+ 1: unidirectional and bidirectional test 2: in both directions of the bi-directional connection Table 1 : OAM Functions for Fault Management Vigoureux et al. Expires January 7, 2009 [Page 10] Internet-Draft OAM Requirements for MPLS-TP July 2008 +-------------------------------------------+ | Performance Management | |-------------------------------------------| | 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 | +---------------------+--+--+----+--+--+----+--+--+----+--+--+----| |continuity check | | | | | | |x |x | x | | | | |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| |connectivity verify. | | | | | | |x |x | x | | | | |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| |alarm suppression | | | | | | | | | | | | | |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| |lock indication | | | | | | | | | | | | | |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| |packet loss meas. | |1 | | | | |x |3 | x | | | | |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| |diagnostic test | | | | | | | | | | | | | |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| |trace-route | | | | | | | | | | | | | |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| |delay measurement |x |2 |x | | | | | | | | | | |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| |remote defect indic. | | | | | | | |x | | | | | +---------------------+-------------------------------------------+ 1: single-ended packet loss measurements 2: one-way and two-way packet delay measurements 3: in both directions of the bi-directional connection Table 2 : OAM Functions for Performance Management Note: In case a misconnection is detected, proactive Performance Management MUST be suspended until the misconnection has been repaired; i.e. all request/response OAM needs to be treated with caution as it cannot be assumed to function reliably, e.g. if traffic is leaking in a unidirectional sense with no return path. The use of OAM functions SHOULD be optional for the operator. A network operator SHOULD be able to choose which OAM functions to use Vigoureux et al. Expires January 7, 2009 [Page 11] Internet-Draft OAM Requirements for MPLS-TP July 2008 and which Maintenance Entity to apply them to. However, it is recommended that connectivity verification is performed on every Maintenance Entity in order to reliably detect connectivity defects. OAM functions such as Continuity Check (CC) and Connectivity Verification (CV) MUST NOT rely on user traffic. Dedicated OAM CV and CC flows SHOULD be used to detect continuity and connectivity defects. See also ITU-T G.806 [3]. As part of the design of OAM mechanisms for MPLS-TP, a mechanism MUST be provided enabling the realization of a channel for general purpose signalling, e.g. for control, management and OAM information, that is associated with the data plane paths. The design of OAM mechanisms for MPLS-TP MUST allow the ability to support vendor specific and experimental OAM functions. Finally, the OAM mechanisms in support of these requirements SHALL be extensible and thus SHALL NOT preclude additional OAM functions in the future. 2.3. Performance Requirements To 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. 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. Architectural aspects for security concerning MPLS-TP are described in Clause 13 of ITU-T G.8110.1 [5]. 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. Vigoureux et al. Expires January 7, 2009 [Page 12] Internet-Draft OAM Requirements for MPLS-TP July 2008 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 January 7, 2009 [Page 13] Internet-Draft OAM Requirements for MPLS-TP July 2008 APPENDIX A : OAM Functions Information This Appendix provides a short description of the OAM functions typically supported in ITU-T defined transport networks. A.1. Continuity Check Continuity Check (CC) is a function that is used to detect loss of continuity between MEPs. CC is useful for applications like Fault Management, Performance Monitoring and Protection Switching, etc. CC should be supported both in pro-active and on-demand modes. In pro-active mode it may be supported for both bidirectional and unidirectional connections. In on-demand mode, CC should be supported for bidirectional connections both between MEPs and between a MEP and a particular MIP along the connection. A.2. Connectivity Verification Connectivity Verification (CV) is a function that is used to check connectivity between MEPs in a single maintenance domain. CV should be supported both in pro-active and on-demand modes. In pro-active mode it may be supported for both unidirectional and bi- directional connections. In on-demand mode, CV should be supported for bidirectional connections both between MEPs and between a MEP and a particular MIP along the connection. A.3. Alarm Suppression Alarm Suppression is a function that is used by a server layer MEP to notify a failure condition 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 in the server layer. Alarm Suppression should be supported in proactive mode only, for all both unidirectional and bi-directional connections. Vigoureux et al. Expires January 7, 2009 [Page 14] Internet-Draft OAM Requirements for MPLS-TP July 2008 A.4. Lock Indication Lock Indication is a function that is used to indicate an administrative locking of a server layer MEP which may result in consequential interruption of data traffic forwarding towards the client layer MEP(s) expecting this traffic. The reception of a Lock Indication allows a MEP to differentiate between a defect condition and an administrative locking action at the server layer MEP. Lock indication should be supported in pro-active mode only. A.5. Packet Loss Measurement Packet Loss Measurement is a function that is used to measure packet loss ratio between a pair of MEPs. Packet Loss Ratio is the ratio of the service packets not delivered to the total number of service packets transmitted during a set time interval. The number of service packets not delivered is the difference between the number of service packets transmitted by the source node and the number of service packets received at the destination node. Packet loss Measurements can be performed by a MEP to measure near- end packet loss on unidirectional connections and near-end and far- end packet loss on bidirectional connections. Where, near-end packet loss refers to packet loss associated with ingress data packets while far-end packet loss refers to packet loss associated with egress data packets. The measurement of packet loss ratio should be supported in pro- active mode for both unidirectional and bi-directional connections. A.6. Diagnostic Test A diagnostic test is a function that is used between MEPs to verify bandwidth throughput, packet loss, bit errors, etc. This function may be used in on-demand mode for either unidirectional or bi-directional connections. A.7. Trace-route Trace-route is a function that is used to determine the route of a connection across the MPLS transport network. Trace-route should be supported in on-demand mode for bi-directional connections between a pair of MEPs or between a MEP and a MIP. Vigoureux et al. Expires January 7, 2009 [Page 15] Internet-Draft OAM Requirements for MPLS-TP July 2008 A.8. Delay Measurement Delay Measurement is a function that is used to measure 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 first bit of that packet by the destination node. 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. This function may be used in on-demand mode. A.9. Remote Defect Indication Remote Defect Indication (RDI) is a function that used by a MEP to notify its peer MEP of a detection of a defect on a bi-directional connection between them. This function should be supported in pro-active mode. A.10. Client Signal Fail Client Signal Fail function (CSF) is used to propagate a Client Failure indication to the far-end sink when alarm suppression in the client layer is not supported. Upon receiving a packet with CSF information a MEP detects a client-layer failure condition and notifies its client-layer. Upon receiving signal fail indication from its client-layer the MEP should immediately start transmitting periodic packets with CSF information. A MEP should continue to transmit periodic packets with CSF information until the client-layer failure indication is removed. Transmission of packets with CSF information can be enabled or disabled on a MEP. Vigoureux et al. Expires January 7, 2009 [Page 16] Internet-Draft OAM Requirements for MPLS-TP July 2008 APPENDIX B : Mapping between RFC 4377, Y.Sup4 and this document To be defined at a later stage. Vigoureux et al. Expires January 7, 2009 [Page 17] Internet-Draft OAM Requirements for MPLS-TP July 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 Recommendation G.8110.1/Y.1370.1 (2007), Architecture of Transport MPLS (T-MPLS) Layer Network [6] 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 [7] Nadeau, T., et al., "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006 [8] Response to liaisons on G.8110.1 (from ITU-T SG 15 to IETF) https://datatracker.ietf.org/liaison/265/ 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 January 7, 2009 [Page 18] Internet-Draft OAM Requirements for MPLS-TP July 2008 Malcolm Betts Nortel Networks Email: betts01@nortel.com Contributing Authors' Addresses Matthew Bocci Alcatel-Lucent Email: matthew.bocci@alcatel-lucent.co.uk 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 January 7, 2009 [Page 19] Internet-Draft OAM Requirements for MPLS-TP July 2008 Julien Meuric Orange Email: julien.meuric@orange-ftgroup.com Philippe Niger Orange Email: philippe.niger@orange-ftgroup.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 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. Vigoureux et al. Expires January 7, 2009 [Page 20] Internet-Draft OAM Requirements for MPLS-TP July 2008 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 January 7, 2009 [Page 21]