--- 1/draft-ietf-mpls-tp-oam-requirements-01.txt 2009-06-29 20:12:10.000000000 +0200 +++ 2/draft-ietf-mpls-tp-oam-requirements-02.txt 2009-06-29 20:12:10.000000000 +0200 @@ -1,581 +1,510 @@ MPLS Working Group M. Vigoureux, Ed. Internet-Draft Alcatel-Lucent -Intended status: Informational D. Ward, Ed. -Expires: September 10, 2009 Cisco Systems, Inc. +Intended status: Standards Track D. Ward, Ed. +Expires: December 30, 2009 Cisco Systems, Inc. M. Betts, Ed. - Nortel Networks - March 9, 2009 + Huawei + June 28, 2009 Requirements for OAM in MPLS Transport Networks - draft-ietf-mpls-tp-oam-requirements-01 + draft-ietf-mpls-tp-oam-requirements-02 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". + 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 September 10, 2009. + This Internet-Draft will expire on December 30, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document lists the requirements for the Operations, Administration and Maintenance functionality of MPLS Transport Profile. These requirements apply to pseudowires, Label Switched - Paths, and Sections. Architectural, functional and operational - requirements are covered in this document. - -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 RFC 2119 [1]. + Paths, and Sections. Architectural and functional requirements are + covered in this document. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.2. Contributing Authors . . . . . . . . . . . . . . . . . . . 5 - 2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1. Architectural Requirements . . . . . . . . . . . . . . . . 6 - 2.1.1. Independence . . . . . . . . . . . . . . . . . . . . . 6 - 2.1.2. Addressing, Routing and Forwarding . . . . . . . . . . 6 - 2.1.3. Interoperability and Interworking . . . . . . . . . . 6 - 2.1.4. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7 - 2.1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . 7 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Language and Terminology . . . . . . . . . . 4 + 2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Architectural Requirements . . . . . . . . . . . . . . . . 5 + 2.1.1. Scope of OAM . . . . . . . . . . . . . . . . . . . . . 5 + 2.1.2. Independence . . . . . . . . . . . . . . . . . . . . . 5 + 2.1.3. Addressing, Routing and Forwarding . . . . . . . . . . 6 + 2.1.4. Interoperability and Interworking . . . . . . . . . . 6 + 2.1.5. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Functional Requirements . . . . . . . . . . . . . . . . . 7 2.2.1. General Requirements . . . . . . . . . . . . . . . . . 8 2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 8 - 2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 9 - 2.2.4. Diagnostic . . . . . . . . . . . . . . . . . . . . . . 9 - 2.2.5. Adjacency . . . . . . . . . . . . . . . . . . . . . . 9 - 2.2.6. Route Tracing . . . . . . . . . . . . . . . . . . . . 10 - 2.2.7. Lock . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 2.2.8. Alarm Notification . . . . . . . . . . . . . . . . . . 10 - 2.2.9. Client Failure Indication . . . . . . . . . . . . . . 11 - 2.2.10. Remote Defect Indication . . . . . . . . . . . . . . . 11 - 2.2.11. Packet Loss . . . . . . . . . . . . . . . . . . . . . 11 - 2.2.12. Delay Measurement . . . . . . . . . . . . . . . . . . 12 - 2.3. Operational Requirements . . . . . . . . . . . . . . . . . 12 - 3. Congestion Considerations . . . . . . . . . . . . . . . . . . 14 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 + 2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 8 + 2.2.4. Diagnostic . . . . . . . . . . . . . . . . . . . . . . 8 + 2.2.5. Route Tracing . . . . . . . . . . . . . . . . . . . . 9 + 2.2.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . 9 + 2.2.7. Lock Reporting . . . . . . . . . . . . . . . . . . . . 9 + 2.2.8. Alarm Reporting . . . . . . . . . . . . . . . . . . . 10 + 2.2.9. Remote Defect Indication . . . . . . . . . . . . . . . 10 + 2.2.10. Client Failure Indication . . . . . . . . . . . . . . 10 + 2.2.11. Packet Loss . . . . . . . . . . . . . . . . . . . . . 10 + 2.2.12. Delay Measurement . . . . . . . . . . . . . . . . . . 11 + 3. Congestion Considerations . . . . . . . . . . . . . . . . . . 11 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction In the context of MPLS Transport Profile (MPLS-TP, see [5] and [6]), the rationales for Operations, Administration and Maintenance (OAM) mechanisms are twofold as they can serve: 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. + mechanism in case of node or link failure). For example, fault + localization is typically associated with this use case. o as a service-oriented mechanism (used by a transport service - provider) to monitor offered services to end customers in order to + provider) to monitor services offered 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 Service Level Agreements (SLAs) parameters (e.g., using 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 + customers. Note that a transport service could be provided over + several networks or administrative domains that may not all be 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 + o the reduction of operational complexity and costs, by allowing for 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, and faults, 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 + o meet service and performance objectives, as the OAM functionality + allows for SLA verification in a multi-maintenance domain + environment and allows for the determination of service degradation due, for example, to packet delay or packet loss. This document lists the requirements for the OAM functionality of MPLS-TP. These requirements apply to pseudowires (PWs), Label Switched Paths (LSPs), and Sections. - These requirements are derived from a set of requirements specified - by ITU-T and first published in the ITU-T Supplement Y.Sup4 [7]. + These requirements are derived from the set of requirements specified + by ITU-T and published in the ITU-T Supplement Y.Sup4 [7]. - By covering transport specificities, these requirements stand as a - complement to those identified in RFC 4377 [8]. + By covering transport specificities, these requirements complement + those identified in RFC 4377 [8]. -1.1. Definitions + Note that the OAM functionalities identified in this document may be + used for fault management, performance monitoring and/or protection + switching applications. For example, connectivity verification can + be used for fault management application by detecting failure + conditions, but may also be used for performance monitoring + 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 functionality should be used + for which application. - 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 +1.1. Requirements Language and Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + + In this document we refer to the inability of a function to perform a + required action, as a fault. This does not include an inability due to preventive maintenance, lack of external resources, or planned actions. See also ITU-T G.806 [2]. - 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 [2]. + In this document we refer to the situation in which the density of + anomalies has reached a level where the ability to perform a required + function has been interrupted, as a defect. See also ITU-T G.806 + [2]. In this document we refer to a Label Edge Router (LER), for a given LSP or Section, and to a PW Terminating Provider Edge (T-PE), for a given PW, as an End Point. Further, we refer to a Label Switching Router (LSR), for a given LSP, and to a PW Switching Provider Edge (S-PE), for a given PW, as an Intermediate Point. This document does - not make any distinction between End Points (e.g., source and + not make a distinction between End Points (e.g., source and destination) as it can be inferred from the context of the sentences. - In this document we use the term "node" as a general referral to End + In this document we use the term "node" as a general reference to End Points and Intermediate Points. - Other definitions, relating to MPLS-TP, can be found in [6]. - -1.2. Contributing Authors - - The editors gratefully acknowledge the contributions of Matthew - Bocci, Italo Busi, Thomas Dietz, Huub van Helvoort, Wataru Imajuku, - Marc Lasserre, Lieven Levrau, Han Li, Julien Meuric, Philippe Niger, - Benjamin Niven-Jenkins, Jing Ruiquan, Nurit Sprecher, Yuji Tochio, - Satoshi Ueno and Yaacov Weingarten. + In this document we refer to both segment and concatenated segments + as segments (see [6] for definitions relating to the term "segment" + as well as for other definitions relating to MPLS-TP). 2. OAM Requirements This section lists the requirements by which the OAM functionality of MPLS-TP should abide. Note that some requirements for this application of MPLS are similar to some of those listed in RFC 4377 [8]. The requirements listed below may be met by one or more OAM protocols; the definition or selection of these protocols is outside the scope of this document. 2.1. Architectural Requirements -2.1.1. Independence +2.1.1. Scope of OAM - OAM functions SHOULD be independent of the underlying tunnelling or - point-to-point technology or transmission media. + The protocol solutions developed to meet the requirements identified + in this document MUST be applicable to point-to-point bidirectional + PWs, point-to-point bidirectional LSPs, and point-to-point + bidirectional Sections and SHOULD additionaly be applicable to + unidirectional point-to-point and point-to-multipoint LSPs. - OAM functions SHOULD be independent of the service a PW may emulate. + The service emulated by a single segment or a multi-segment PW may + span multiple domains. An LSP may also span multiple domains. It + MUST be possible to operate OAM functions on a per domain basis. + More generally, the protocol solutions MUST be applicable end-to-end + and to segments. - The set of OAM functions operated on a PW, LSP or Section SHOULD be - independent of the set of OAM functions operated on a different PW, - LSP or Section. In other words, only the OAM functions available for - e.g., a LSP should be used to achieve the OAM objectives for that - LSP. Note that independence should not be understood here in terms - of isolation as there can be interactions between OAM functions - operated on e.g., a LSP and on another LSP or on a PW. + Since LSPs may be stacked, the protocol solutions MUST be applicable + on any LSP, regardless of the label stack depth. Furthermore it MUST + be possible to estimate OAM fault and performance metrics of a single + PW or LSP segment or of an aggregate of PWs or LSPs segments. + +2.1.2. Independence + + The protocol solutions SHOULD be independent of the underlying + tunnelling or point-to-point technology or transmission media. + + The protocol solutions SHOULD be independent of the service a PW may + emulate. + + Any OAM function operated on a PW, LSP or Section SHOULD be + independent of the OAM function(s) operated on a different PW, LSP or + Section. In other words, only the OAM functions operated on e.g., a + given LSP should be used to achieve the OAM objectives for that LSP. + Note that independence should not be understood here in terms of + isolation as there can be interactions between OAM functions operated + on e.g., an LSP, and on another LSP or a PW. + + Likewise, any OAM function applied to segment(s) of a PW or LSP + SHOULD be independent of the OAM function(s) operated on the end-to- + end PW or LSP. It SHOULD also be possible to distinguish an OAM + packet running over a segment of a PW or LSP from another OAM packet + running on the end-to-end PW or LSP. Furthermore, any OAM function + applied to segment(s) of a PW or LSP SHOULD be independent of the OAM + function(s) applied to other segment(s) of the same PW or LSP. + Finally, the protocol solutions MUST support the capability to be + concurrently and independently operated end-to-end and on segments. 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 (e.g., LSP or PW) management. Means for - configuring OAM functions and for connectivity management are outside - the scope of this document. + a control plane. Conversely, it SHOULD be possible to enable/disable + the capability to operate OAM functions as part of connectivity + management and it SHOULD also be possible to enable/disable the + capability to operate OAM functions after connectivity has been + established. In the latter case, the customer MUST NOT perceive + service degradation as a result of OAM enabling/disabling. Ideally + OAM enabling/disabling should take place without introducing any + customer impairments (e.g., no customer packet losses). Procedures + aimed to prevent any traffic impairment MUST be defined for the + enabling/disabling of OAM functions. Means for configuring OAM + functions and for connectivity management are outside the scope of + this document. -2.1.2. Addressing, Routing and Forwarding +2.1.3. Addressing, Routing and Forwarding The OAM functionality may be deployed in a variety of environments. o In some environments (e.g., IP/MPLS environments), IP routing and - forwarding capabilities are inherently present. In this case, the - OAM functionality MUST support the use of IP routing and - forwarding capabilities. + forwarding capabilities are inherently present in the forwarding + plane. In this case, it MUST be possible to operate the OAM + functions by relying on IP routing and forwarding capabilities. o In some environments (e.g., MPLS-TP environments), IP routing and - forwarding capabilities may not necessarily be present. In this - case, the OAM functions and their operation MUST NOT require - relying on IP routing and forwarding capabilities. + forwarding capabilities may not necessarily be present in the user + plane. In this case, it MUST be possible to operate the OAM + functions without relying on IP routing and forwarding + capabilities. - In case OAM messages need to incorporate identification information - (e.g., of source and/or destination nodes), the protocol solution - MUST at least support an IP addressing structure and MUST also be - extensible to support additional addressing schemes. + In cases where OAM messages need to incorporate identification + information (e.g., source and/or destination nodes), the protocol + solution(s) MUST at least support an IP addressing structure and MUST + also be extensible to support additional identification schemes. -2.1.3. Interoperability and Interworking +2.1.4. Interoperability and Interworking - It is REQUIRED by this document that OAM interoperability is achieved - across the environments described in Section 2.1.2. It is also - REQUIRED by this document that the two first requirements of Section - 2.1.2 still hold and MUST thus still be met when interoperability is - achieved. + It is REQUIRED that OAM interoperability is achieved across the + environments described in Section 2.1.3. It is also REQUIRED that + the two first requirements of Section 2.1.3 still hold and MUST still + be met when interoperability is achieved. When MPLS-TP is run with IP routing and forwarding capabilities, it MUST be possible to operate any of the existing IP/MPLS and PW OAM - functionalities (e.g., LSP-Ping [3], MPLS-BFD [9], VCCV [4] and VCCV- - BFD [10]). - - The protocol solution(s) developed to meet the requirements listed in - this document MUST interwork with the existing IP/MPLS and PW OAM - protocols. + protocols (e.g., LSP-Ping [3], MPLS-BFD [9], VCCV [4] and VCCV-BFD + [10]). -2.1.4. Data Plane +2.1.5. Data Plane OAM functions operate in the data plane. OAM packets MUST run in- band; that is, OAM packets for a specific PW, LSP or Section MUST follow the exact same data path as user traffic of that PW, LSP or - Section. + Section. This is often referred to as fate sharing. It MUST be possible to discriminate user 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 nodes targeted by these OAM packets. - - As part of the design of OAM protocol solutions for MPLS-TP, a - mechanism enabling to encapsulate and differentiate OAM messages, on - a PW, LSP or Section, MUST be provided. Such mechanism MUST also - support the encapsulation and differentiation of existing IP/MPLS and - PW OAM messages. - -2.1.5. Scope + as well as the capability to apply specific treatment to OAM packets, + at the nodes targeted by these OAM packets. - The service emulated by a single segment or a multi-segment PW may - span multiple domains. A LSP may also span multiple domains. It - MUST be possible to perform OAM functions on a per domain basis and - across multiple domains. More generally it MUST be possible to - perform OAM functions between any two switching elements (e.g., LSR - or S-PE) of a LSP or of PW. This is referred to as (concatenated) - segment monitoring. + As part of the design of OAM protocol solution(s) for MPLS-TP, a + mechanism, for enabling the encapsulation and differentiation of OAM + messages on a PW, LSP or Section, MUST be provided. Such mechanism + SHOULD also support the encapsulation and differentiation of existing + IP/MPLS and PW OAM messages. 2.2. Functional Requirements - Hereafter are listed the required functions composing the MPLS-TP OAM - toolset. 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. + Hereafter are listed the required functionalities composing the + MPLS-TP OAM toolset. 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 functionalities, in the future. - The design of OAM mechanisms, for MPLS-TP, MUST allow the ability to - support vendor specific and experimental OAM functions. These - functions MUST be disabled by default. + The design of OAM mechanisms for MPLS-TP, MUST allow for the ability + to support experimental OAM functions. These functions MUST be + disabled by default. - The use of any OAM function MUST be optional for the service provider - or network operator and a network operator or service provider MUST - be able to choose which OAM function(s) to use and on which PW, LSP - or Section to apply it(them) to. + The use of any OAM function MUST be optional and it MUST be possible + to choose which OAM function(s) to use and on which PW, LSP or + Section to apply it(them) to. - It is RECOMMENDED by this document that a protocol solution, - realizing a given function, effectively provides a fully featured - function, i.e., a function which is applicable to all the cases - identified in the table in Section 2.3, for that function. + It is RECOMMENDED that the protocol solution, meeting one or more + functional requirement(s), be the same for PWs, LSPs and Sections. - The OAM functions MUST be able to be operated on PWs, LSPs and - Sections. + It is RECOMMENDED that the protocol solution, meeting one or more + functional requirement(s), effectively provides a fully featured + function; that is, a function which is applicable to all the cases + identified for that functionality. In that context, protocol + solution(s) MUST state their applicability. - Note that the functions listed below can be used for fault - management, performance monitoring and/or protection switching - applications. For example, connectivity verification can be used for - fault management application by detecting failure conditions, but may - also be used for performance monitoring 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. + Unless otherwise stated, the OAM functionalities MUST NOT rely on + user traffic; that is, only OAM messages MUST be used to achieve the + objectives. 2.2.1. General Requirements If a defect or fault occurs on a PW, LSP or Section, 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. + appropriate nodes. Mechanisms SHOULD exist such that corrective + actions can be taken. - Furthermore, in case of a fault or defect, affecting a service - provided by a service provider, mechanisms MUST be available for the - service provider to be informed of the fault or defect even if the - fault or defect is located outside of his domain. + Furthermore, mechanisms MUST be available for a service provider to + be informed of a fault or defect affecting the service(s) it + provides, even if the fault or defect is located outside of his + domain. -2.2.2. Continuity Checks + The protocol solution(s) developed to meet these requirements may + rely on information exchange. Information exchange between various + nodes involved in the operation of an OAM function SHOULD be reliable + such that, for example, defects or faults are properly detected or + that state changes are effectively known by the appropriate nodes. - The MPLS-TP OAM toolset MUST provide a function to enable service - providers and network operators to detect loss of continuity, but - also unintended connectivity, on a PW, LSP or Section. +2.2.2. Continuity Checks - This function SHOULD be performed pro-actively. + The MPLS-TP OAM toolset MUST provide functionality to enable the + verification of the continuity of a PW, LSP or Section. This function SHOULD be performed between End Points of PWs, LSPs and Sections. - Means MUST be available to parameterize the frequency at which is - performed this function as well as to parameterize the criteria, if - any (e.g., number of consecutive OAM messages not received), based on - which loss of continuity or unintended connectivity is detected. A - default value MAY be defined. + This function SHOULD be performed pro-actively. 2.2.3. Connectivity Verifications - The MPLS-TP OAM toolset MUST provide a function to enable service - providers and network operators to verify the connectivity of a PW, - LSP or Section. - - This function SHOULD be performed on-demand. + The MPLS-TP OAM toolset MUST provide functionality to enable the + verification of the connectivity of a PW, LSP or Section. This function SHOULD be performed between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs and Sections. - Note that, this function is sometime referred to as loopback as End - Points expect to receive some level of information as a result of - their action. + This function SHOULD be performed on-demand. This function SHOULD be + performed pro-actively only between End Points of PWs, LSPs and + Sections. 2.2.4. Diagnostic - The MPLS-TP OAM toolset MAY provide a function to enable service - providers and network operators to perform diagnostic tests (e.g., - verify bandwidth throughput) on a PW, LSP or Section. + The MPLS-TP OAM toolset MAY provide functionality to enable the + conduction of diagnostic tests on a PW, LSP or Section. An example + of such diagnotic test would consist in looping the traffic at an + Intermediate Point, back to the End Point it originates from. + Another example of such diagnotic test would consist in estimating + the bandwidth of e.g., an LSP. This function SHOULD be performed on-demand. This function SHOULD be performed between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs and Sections. - This function MAY be provided as part of the Connectivity - Verifications function (see Section 2.2.3). - -2.2.5. Adjacency - - The MPLS-TP OAM toolset MUST provide a function to enable an End - Point to request, to, and receive from, any node along a PW, LSP or - Section, a certain level of information (e.g., identification, - distance in hops). - - This function SHOULD be performed on-demand. - - This function SHOULD be performed between End Points and any node of - a PW, LSP and Section. - - This function MAY be provided jointly with the Route Tracing function - (see Section 2.2.6). - -2.2.6. Route Tracing +2.2.5. Route Tracing - The MPLS-TP OAM toolset MUST provide a function to enable service - providers and network operators to trace the route a PW, LSP or - Section. The information collected SHOULD include identifiers - related to the nodes composing that route and MAY include interface - identifiers. + The MPLS-TP OAM toolset MUST provide functionality to enable an End + Point to discover the Intermediate (if any) and End Point(s) along a + PW, LSP or Section, and more generaly to trace the route of a PW, LSP + or Section. The information collected MUST include identifiers + related to the nodes and interfaces composing that route. This function SHOULD be performed on-demand. This function SHOULD be performed between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs and Sections. - This function MAY be provided jointly with the Adjacency function - (see Section 2.2.5). - -2.2.7. Lock +2.2.6. Lock Instruct - The MPLS-TP OAM toolset MAY provide a function enabling to - administratively shut down a PW, LSP or Section; that is, to stop - user traffic being sent over that PW, LSP or Section. + The MPLS-TP OAM toolset MUST provide functionality to enable an End + Point of a PW, LSP or Section to instruct its associated End Point(s) + to lock the PW, LSP or Section. Note that lock corresponds to an + administrative status in which forwarding traffic on and from the PW, + LSP or Section is disabled. This function SHOULD be performed on-demand. This function SHOULD be performed between End Points of PWs, LSPs and Sections. -2.2.8. Alarm Notification +2.2.7. Lock Reporting - The MPLS-TP OAM toolset MUST provide a function to enable server - layer End Points to notify a fault condition or an administrative - locking to the client layer End Points affected by this status. This - would enable to suppress alarms that may be generated in the client - layer as a result of the fault condition or of the administrative - locking in the server layer. + The MPLS-TP OAM toolset MUST provide functionality to enable an + Intermediate Point of a PW or LSP to report, to an End Point of that + same PW or LSP, an external lock condition affecting that PW or LSP. - The MPLS-TP OAM toolset MUST allow for the distinction between a - fault condition and an administrative locking action. + This function SHOULD be performed pro-actively. - The server layer End Points generating the notification and the - client layer End Points receiving the notification may or may not be - the same nodes. A mechanism MUST be provided to support both cases. + This function SHOULD be performed between Intermediate Points and End + Points of PWs and LSPs. + +2.2.8. Alarm Reporting + + The MPLS-TP OAM toolset MUST provide functionality to enable an + Intermediate Point of a PW or LSP to report, to an End Point of that + same PW or LSP, a fault or defect condition affecting that PW or LSP. This function SHOULD be performed pro-actively. - This function SHOULD be performed between the End Points of PWs, LSPs - and Sections and the End Points of the PWs and/or LSPs affected by - the fault condition or administrative locking. + This function SHOULD be performed between Intermediate Points and End + Points of PWs and LSPs. -2.2.9. Client Failure Indication +2.2.9. Remote Defect Indication - The MPLS-TP OAM toolset MUST provide a function to enable the - propagation of client fault condition information, across the MPLS-TP - network, if the client layer OAM mechanisms do not provide an alarm - notification/propagation mechanism. + The MPLS-TP OAM toolset MUST provide functionality to enable an End + Point to report, to its associated End Point, a fault or defect + condition that it detects on a PW, LSP or Section for which they are + the End Points. This function SHOULD be performed pro-actively. This function SHOULD be performed between End Points of PWs, LSPs and Sections. -2.2.10. Remote Defect Indication +2.2.10. Client Failure Indication - The MPLS-TP OAM toolset MUST provide a function to enable an End - Point to notify its associated End Point of the detection of a fault - or defect that it detects on a PW, LSP or Section between them. + The MPLS-TP OAM toolset MUST provide functionality to enable the + propagation, across an MPLS-TP network, of information pertaining to + a client defect of fault condition detected at an End Point of a PW + or LSP, if the client layer OAM mechanisms do not provide an alarm + notification/propagation mechanism. This function SHOULD be performed pro-actively. - This function SHOULD be performed between End Points of PWs, LSPs and - Sections. + This function SHOULD be performed between End Points of PWs and LSPs. 2.2.11. Packet Loss - Packet loss ratio is the ratio of the user packets not delivered to - the total number of user packets transmitted during a defined time - interval. The number of user packets not delivered is the difference - between the number of user packets transmitted by an End Point and - the number of user packets received at an End Point. - - The MPLS-TP OAM toolset MUST provide a function to enable service - providers and network operators to derive packet loss ratio over a - PW, LSP or Section. + The MPLS-TP OAM toolset MUST provide functionality to enable the + quantification of packet loss ratio over a PW, LSP or Section. - This OAM function MUST support the configurability of the interval of - time during which the measure is performed. + Note that packet loss ratio is the ratio of the user packets not + delivered to the total number of user packets transmitted during a + defined time interval. The number of user packets not delivered is + the difference between the number of user packets transmitted by an + End Point and the number of user packets received at an End Point. - This function SHOULD be performed pro-actively. + This function MAY either be performed pro-actively or on-demand. This function SHOULD be performed between End Points of PWs, LSPs and Sections. + It SHOULD be possible to rely on user-plane traffic to achieve that + functionality. + 2.2.12. Delay Measurement - The MPLS-TP OAM toolset MUST provide a function to enable service - providers and network operators to measure the one-way, and if - appropriate, the two-way, delay of a PW, LSP or Section. + The MPLS-TP OAM toolset MUST provide functionality to enable the + quantification of the one-way, and if appropriate, the two-way, delay + of a PW, LSP or Section. o One-way delay is the time elapsed from the start of transmission - of the first bit of an OAM packet by an End Point until the - reception of the last bit of that OAM packet by the other End - Point. + of the first bit of a packet by an End Point until the reception + of the last bit of that packet by the other End Point. o Two-way delay is the time elapsed from the start of transmission - of the first bit of an OAM packet by a End Point until the - reception of the last bit of that OAM packet by the same End - Point, when the loopback is performed at the other End Point. + of the first bit of a packet by a End Point until the reception of + the last bit of that packet by the same End Point, when loopback + is performed at the other End Point. - This function SHOULD be performed on-demand. + This function SHOULD be performed on-demand and MAY be perform pro- + actively. This function SHOULD be performed between End Points of PWs, LSPs and Sections. -2.3. Operational Requirements - - The OAM functions MUST NOT rely on user traffic to achieve their - objectives; that is, dedicated OAM messages MUST be used. - - Some OAM functions require certain parameters for their operation. - These parameters MUST be configurable. A default value MAY be - defined. - - The specification of certain parameters' values SHOULD be such that - it accounts, at the design phase, for various possible network - conditions (e.g., the continuity check function should continue to - meet its objective (i.e. detect failures) even in the context of high - traffic load (e.g., congestion)). - - This document does not mandate the use of a particular OAM function. - However, it is RECOMMENDED that MPLS-TP enables continuity checks to - be performed on every PW, LSP and Section in order to reliably detect - connectivity defects and faults. - - OAM functions MUST be applicable to bidirectional point-to-point PWs, - LSPs and Sections, and a subset of these OAM functions MUST be - applicable to unidirectional point-to-point and point-to-multipoint - PWs, LSPs and Sections. 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, between which points of PWs, LSPs - and Sections SHOULD the required OAM functions be applied. In these - tables U stands for unidirectional; B stands for bidirectional; EP - stands for an OAM function being performed between End Points; IP - stands for an OAM function being performed between End Points and - Intermediate Points. 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. - +-------------------------------------------+ - | on-demand | pro-active | - |---------------------+----------+----------| - | MEP | MIP | MEP | MIP | - |----------+----------+----------+----------| - | P2P |P2MP| P2P |P2MP| P2P |P2MP| P2P |P2MP| - |-----+----+----------+----------+-----+----| - |U |B | U |U |B | U |U |B | U |U |B | U | - +----------------------+--+--+----+--+--+----+--+--+----+--+--+----| - | c. checks | | | | | | |x |x | x | | | | - |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| - | c. verifications |1 |x | 1 |1 |x | 1 | | | | | | | - |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| - | diagnostic |x |x | x |2 |2 | 2 | | | | | | | - |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| - | adjacency |1 |x | 1 |1 |x | 1 | | | | | | | - |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| - | route tracing |1 |x | 1 |1 |x | 1 | | | | | | | - |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| - | lock |x |x | x | | | | | | | | | | - |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| - | alarm notification | | | | | | |x |x | x | | | | - |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| - | client fail. indic. | | | | | | |2 |x | 2 | | | | - |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| - | remote defect indic. | | | | | | |1 |x | 1 | | | | - |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| - | packet loss |2 |3 | 2 | | | |x |4 | x | | | | - |----------------------+--+--+----+--+--+----+--+--+----+--+--+----| - | delay measurement |x |x | x | | | |2 |2 | 2 | | | | - +----------------------+--+--+----+--+--+----+--+--+----+--+--+----+ - 1: the function MAY be provided if a return path exists - 2: the function MAY be performed - 3: the function SHOULD be performed in one direction - 4: the function SHOULD be performed in both directions - - OAM functions and their applicability scope + It SHOULD be possible to rely on user-plane traffic to achieve that + functionality. 3. Congestion Considerations A mechanism (e.g., rate limiting) MUST be provided to prevent OAM packets from causing congestion in the PSN. 4. Security Considerations This document, as itself, does not imply any security consideration but OAM, as such, is subject to several security considerations. OAM @@ -597,20 +526,26 @@ An OAM packet received over a PW, LSP or Section MUST NOT be forwarded beyond the End Point of that PW, LSP or Section, so as to avoid that the OAM packet leaves the current administrative domain. 5. IANA Considerations There are no IANA actions required by this draft. 6. Acknowledgements + The editors gratefully acknowledge the contributions of Matthew + Bocci, Italo Busi, Thomas Dietz, Huub van Helvoort, Wataru Imajuku, + Marc Lasserre, Lieven Levrau, Han Li, Julien Meuric, Philippe Niger, + Benjamin Niven-Jenkins, Jing Ruiquan, Nurit Sprecher, Yuji Tochio, + Satoshi Ueno and Yaacov Weingarten. + The authors would like to thank all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in IETF and the MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and specification of MPLS-TP. 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement @@ -628,47 +563,52 @@ Pseudowires", RFC 5085, December 2007. 7.2. Informative References [5] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in Transport Networks", draft-ietf-mpls-tp-framework-00 (work in progress), November 2008. [6] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "MPLS-TP Requirements", - draft-ietf-mpls-tp-requirements-04 (work in progress), - February 2009. + draft-ietf-mpls-tp-requirements-09 (work in progress), + June 2009. [7] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on transport requirements for T-MPLS OAM and considerations for the application of IETF MPLS technology", 2008. [8] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006. [9] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress), June 2008. [10] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit - Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-03 - (work in progress), February 2009. + Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-05 + (work in progress), June 2009. Authors' Addresses Martin Vigoureux (editor) Alcatel-Lucent + Route de Villejust + Nozay, 91620 + France Email: martin.vigoureux@alcatel-lucent.com - David Ward (editor) Cisco Systems, Inc. + 170 W. Tasman Dr. + San Jose, CA 95134 + USA Email: dward@cisco.com Malcolm Betts (editor) - Nortel Networks + Huawei - Email: betts01@nortel.com + Email: malcolm.betts@huawei.com