diff options
Diffstat (limited to 'doc/rfc/rfc5860.txt')
| -rw-r--r-- | doc/rfc/rfc5860.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc5860.txt b/doc/rfc/rfc5860.txt new file mode 100644 index 0000000..4a66798 --- /dev/null +++ b/doc/rfc/rfc5860.txt @@ -0,0 +1,955 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Vigoureux, Ed. +Request for Comments: 5860 Alcatel-Lucent +Category: Standards Track D. Ward, Ed. +ISSN: 2070-1721 Juniper Networks + M. Betts, Ed. + M. C. Betts Consulting Ltd. + May 2010 + + + Requirements for Operations, Administration, and Maintenance (OAM) + in MPLS Transport Networks + +Abstract + + This document lists architectural and functional requirements for the + Operations, Administration, and Maintenance of MPLS Transport + Profile. These requirements apply to pseudowires, Label Switched + Paths, and Sections. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5860. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + +Vigoureux, et al. Standards Track [Page 1] + +RFC 5860 OAM Requirements for MPLS-TP May 2010 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Scope of This Document . . . . . . . . . . . . . . . . . . 3 + 1.2. Requirements Language and Terminology . . . . . . . . . . 4 + 2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. Architectural Requirements . . . . . . . . . . . . . . . . 6 + 2.1.1. Scope of OAM . . . . . . . . . . . . . . . . . . . . . 6 + 2.1.2. Independence . . . . . . . . . . . . . . . . . . . . . 6 + 2.1.3. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7 + 2.1.4. OAM and IP Capabilities . . . . . . . . . . . . . . . 7 + 2.1.5. Interoperability and Interworking . . . . . . . . . . 8 + 2.1.6. Configuration . . . . . . . . . . . . . . . . . . . . 8 + 2.2. Functional Requirements . . . . . . . . . . . . . . . . . 9 + 2.2.1. General Requirements . . . . . . . . . . . . . . . . . 9 + 2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 10 + 2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 10 + 2.2.4. Route Tracing . . . . . . . . . . . . . . . . . . . . 11 + 2.2.5. Diagnostic Tests . . . . . . . . . . . . . . . . . . . 11 + 2.2.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . 11 + 2.2.7. Lock Reporting . . . . . . . . . . . . . . . . . . . . 12 + 2.2.8. Alarm Reporting . . . . . . . . . . . . . . . . . . . 12 + 2.2.9. Remote Defect Indication . . . . . . . . . . . . . . . 13 + 2.2.10. Client Failure Indication . . . . . . . . . . . . . . 13 + 2.2.11. Packet Loss Measurement . . . . . . . . . . . . . . . 13 + 2.2.12. Packet Delay Measurement . . . . . . . . . . . . . . . 14 + 3. Congestion Considerations . . . . . . . . . . . . . . . . . . 15 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 6.1. Normative References . . . . . . . . . . . . . . . . . . . 16 + 6.2. Informative References . . . . . . . . . . . . . . . . . . 16 + + + + + + + + + + + + + + + + + + + +Vigoureux, et al. Standards Track [Page 2] + +RFC 5860 OAM Requirements for MPLS-TP May 2010 + + +1. Introduction + + In the context of MPLS Transport Profile (MPLS-TP, see [9] and [1]), + the rationales for Operations, Administration, and Maintenance (OAM) + are twofold as it can serve: + + o as a network-oriented functionality, used by a transport network + operator to monitor his network infrastructure and to implement + internal mechanisms in order to enhance the general behavior and + the level of performance of his network (e.g., protection + mechanism in case of node or link failure). As an example, fault + localization is typically associated with this use case. + + o as a service-oriented functionality, used by a transport service + 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 Agreement (SLA) parameters (e.g., + using performance monitoring) negotiated with the end 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 for + efficient and automatic detection, localization, and handling and + diagnosis of defects, as well as by minimizing service + interruptions and operational repair times. + + o the enhancement of network availability, by ensuring that defects + (for example, those resulting in misdirected customer traffic) and + faults are detected, diagnosed, and dealt with before a customer + reports the problem. + + o meeting 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. + +1.1. Scope of This Document + + This document lists architectural and functional 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 the set of requirements specified + by ITU-T and published in the ITU-T Supplement Y.Sup4 [10]. + + + +Vigoureux, et al. Standards Track [Page 3] + +RFC 5860 OAM Requirements for MPLS-TP May 2010 + + + By covering transport specificities, these requirements complement + those identified in RFC 4377 [11]; yet, some requirements may be + similar. + + This document only lists architectural and functional OAM + requirements. It does not detail the implications of their + applicability to the various types (e.g., point-to-point, point-to- + multipoint, unidirectional, bidirectional, etc.) of PWs, LSPs, and + Sections. Furthermore, this document does not provide requirements + on how the protocol solution(s) should behave to achieve the + functional objectives. Please see [12] for further information. + + Note that the OAM functions 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 by detecting failure conditions, but may + also be used for performance monitoring 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. + + Note also that it is anticipated that implementers may wish to + implement OAM message handling in hardware. Although not a + requirement, this fact could be taken as a design consideration. + +1.2. 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 [2]. + Although this document is not a protocol specification, the use of + this language clarifies the instructions to protocol designers + producing solutions that satisfy the requirements set out in this + document. + + In this document, we: + + o 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 [3]. + + o 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 [3]. + + + + + + +Vigoureux, et al. Standards Track [Page 4] + +RFC 5860 OAM Requirements for MPLS-TP May 2010 + + + o refer to OAM actions that are carried out continuously or at least + over long periods of time, permitting proactive reporting of fault + and/or performance results as proactive OAM. + + o refer to OAM actions that are initiated via manual intervention + for a limited time to carry out troubleshooting as on-demand OAM. + + o 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 a distinction between End Points (e.g., source and + destination) as it can be inferred from the context of the + sentences. + + o use the term "node" as a general reference to End Points and + Intermediate Points. + + o refer to both segment and concatenated segments as segments (see + [1] for definitions relating to the term "segment" as well as for + other definitions relating to MPLS-TP). + + o refer to both single segment PWs and multi-segment PWs as PWs. + + o refer to both bidirectional associated LSPs and bidirectional co- + routed LSPs as bidirectional LSPs. + +2. OAM Requirements + + This section lists the requirements by which the OAM functionality of + MPLS-TP should abide. + + 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. + + RFC 5654 [1] states (Requirement #2) that the MPLS-TP design, SHOULD + as far as reasonably possible, reuse existing MPLS standards. This + general requirement applies to MPLS-TP OAM. MPLS-TP OAM is defined + in this document through a set of functional requirements. These + requirements will be met by protocol solutions defined in other + documents. The way in which those protocols are operated and the way + in which a network operator can control and use the MPLS-TP OAM + functions SHOULD be as similar as possible to the mechanisms and + techniques used to operate OAM in other transport technologies. + + + + + +Vigoureux, et al. Standards Track [Page 5] + +RFC 5860 OAM Requirements for MPLS-TP May 2010 + + +2.1. Architectural Requirements + +2.1.1. Scope of OAM + + The protocol solution(s) developed to meet the requirements + identified in this document MUST at least be applicable to point-to- + point bidirectional PWs, point-to-point co-routed bidirectional LSPs, + and point-to-point bidirectional Sections. Section 2.2 provides + additional information with regard to the applicability to point-to- + point associated bidirectional LSPs, point-to-point unidirectional + LSPs, and point-to-multipoint LSPs. + + The service emulated by a PW may span multiple domains. An LSP may + also span multiple domains. The protocol solution(s) MUST be + applicable to end-to-end and to segments. More generally, it MUST be + possible to operate OAM functions on a per-domain basis and across + multiple domains. + + Since LSPs may be stacked, the protocol solution(s) 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 PW or LSP segments. + +2.1.2. Independence + + The protocol solution(s) SHOULD be independent of the underlying + tunneling or point-to-point technology or transmission media. + + The protocol solution(s) 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 a + given LSP (for example) should be used to achieve the OAM objectives + for that LSP. + + The protocol solution(s) MUST support the capability to be + concurrently and independently operated end-to-end and on segments. + Therefore, 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. + + + + + + +Vigoureux, et al. Standards Track [Page 6] + +RFC 5860 OAM Requirements for MPLS-TP May 2010 + + + 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. + + Note: Independence should not be understood in terms of isolation + as there can be interactions between OAM functions operated, for + example, on two different LSPs. + +2.1.3. 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. 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 processing these OAM packets. + + 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.1.4. OAM and IP Capabilities + + There are environments where IP capabilities are present in the data + plane. IP/MPLS environments are examples of such environments. + There are also environments where IP capabilities may not be present + in the data plane. MPLS-TP environments are examples of environments + where IP capabilities might or might not be present. + + Note: Presence or absence of IP capabilities is deployment + scenario dependent. + + It MUST be possible to deploy the OAM functionality in any of these + environments. As a result, it MUST be possible to operate OAM + functions with or without relying on IP capabilities, and it MUST be + possible to choose to make use of IP capabilities when these are + present. + + Furthermore, the mechanism required for enabling the encapsulation + and differentiation of OAM messages (see Section 2.1.3) MUST support + the capability to differentiate OAM messages of an OAM function + + + + + +Vigoureux, et al. Standards Track [Page 7] + +RFC 5860 OAM Requirements for MPLS-TP May 2010 + + + operated by relying on IP capabilities (e.g., using encapsulation in + an IP header) from OAM messages of an OAM function operated without + relying on any IP capability. + + Note that IP capabilities include the capability to form a standard + IP header, to encapsulate a payload in an IP header, to parse and + analyze the fields of an IP header, and to take actions based on the + content of these fields. + + For certain functions, OAM messages need to incorporate + identification information (e.g., of source and/or destination + nodes). The protocol solution(s) MUST at least support + identification information in the form of an IP addressing structure + and MUST also be extensible to support additional identification + schemes. + +2.1.5. Interoperability and Interworking + + It is REQUIRED that OAM interoperability is achieved between distinct + domains materializing the environments described in Section 2.1.4. + It is also REQUIRED that the first two requirements of Section 2.1.4 + 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 + protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [5], and VCCV-BFD + [14]). + +2.1.6. Configuration + + OAM functions MUST operate and be configurable even in the absence of + a control plane. Conversely, it SHOULD be possible to configure as + well as enable/disable the capability to operate OAM functions as + part of connectivity management, and it SHOULD also be possible to + configure as well as 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. + + + + + +Vigoureux, et al. Standards Track [Page 8] + +RFC 5860 OAM Requirements for MPLS-TP May 2010 + + +2.2. Functional Requirements + + 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 for the ability + to support experimental OAM functions. These functions MUST be + disabled by default. + + The use of any OAM function MUST be optional and it MUST be possible + to select the set of OAM function(s) to use on any PW, LSP, or + Section. + + It is RECOMMENDED that any protocol solution, meeting one or more + functional requirement(s), be the same for PWs, LSPs, and Sections. + + It is RECOMMENDED that any protocol solution, meeting one or more + functional requirement(s), effectively provides a fully featured + function; that is, a function that is applicable to all the cases + identified for that functionality. In that context, protocol + solution(s) MUST state their applicability. + + Unless otherwise stated, the OAM functionalities MUST NOT rely on + user traffic; that is, only OAM messages MUST be used to achieve the + objectives. + + For the on-demand OAM functions, the result of which may vary + depending on packet size, it SHOULD be possible to perform these + functions using different packet sizes. + +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 nodes. Mechanisms SHOULD exist such that corrective + actions can be taken. + + Furthermore, mechanisms MUST be available for a service provider to + be aware of a fault or defect affecting the service(s) he provides, + even if the fault or defect is located outside of his domain. + + + + + + + + +Vigoureux, et al. Standards Track [Page 9] + +RFC 5860 OAM Requirements for MPLS-TP May 2010 + + + 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. + +2.2.2. Continuity Checks + + The MPLS-TP OAM toolset MUST provide a function to enable an End + Point to monitor the liveness of a PW, LSP, or Section. + + This function SHOULD be performed between End Points of PWs, LSPs, + and Sections. + + This function SHOULD be performed proactively. + + The protocol solution(s) developed to perform this function MUST also + apply to point-to-point associated bidirectional LSPs, point-to-point + unidirectional LSPs, and point-to-multipoint LSPs. + +2.2.3. Connectivity Verifications + + The MPLS-TP OAM toolset MUST provide a function to enable an End + Point to determine whether or not it is connected to specific End + Point(s) by means of the expected PW, LSP, or Section. + + This function SHOULD be performed proactively between End Points of + PWs, LSPs, and Sections. + + This function SHOULD be performed on-demand between End Points and + Intermediate Points of PWs and LSPs, and between End Points of PWs, + LSPs, and Sections. + + The protocol solution(s) developed to perform this function + proactively MUST also apply to point-to-point associated + bidirectional LSPs, point-to-point unidirectional LSPs, and point-to- + multipoint LSPs. + + The protocol solution(s) developed to perform this function on-demand + MAY also apply to point-to-point associated bidirectional LSPs, to + point-to-point unidirectional LSPs, and point-to-multipoint LSPs in + case a return path exists. + + + + + + + + + +Vigoureux, et al. Standards Track [Page 10] + +RFC 5860 OAM Requirements for MPLS-TP May 2010 + + +2.2.4. Route Tracing + + 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 generally 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. + + The protocol solution(s) developed to perform this function MAY also + apply to point-to-point associated bidirectional LSPs, to point-to- + point unidirectional LSPs, and point-to-multipoint LSPs in case a + return path exists. + +2.2.5. Diagnostic Tests + + The MPLS-TP OAM toolset MUST provide a function to enable conducting + diagnostic tests on a PW, LSP, or Section. An example of such a + diagnostic test consists of performing a loop-back function at a node + such that all OAM and data traffic are looped back to the originating + End Point. Another example of such diagnostic test consists 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. + + The protocol solution(s) developed to perform this function MAY also + apply to point-to-point associated bidirectional LSPs, to point-to- + point unidirectional LSPs and point-to-multipoint LSPs, in case a + return path exists. + +2.2.6. Lock Instruct + + 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 it is expected that only test + traffic, if any, and OAM (dedicated to the PW, LSP, or Section) can + be mapped on that PW, LSP, or Section. + + + + +Vigoureux, et al. Standards Track [Page 11] + +RFC 5860 OAM Requirements for MPLS-TP May 2010 + + + This function SHOULD be performed on-demand. + + This function SHOULD be performed between End Points of PWs, LSPs, + and Sections. + + The protocol solution(s) developed to perform this function MUST also + apply to point-to-point associated bidirectional LSPs, point-to-point + unidirectional LSPs, and point-to-multipoint LSPs. + +2.2.7. Lock Reporting + + Based on the tunneling capabilities of MPLS, there are cases where + Intermediate Point(s) of a PW or of an LSP coincide with End Point(s) + of another LSP on which the former is mapped/tunneled. Further, it + may happen that the tunnel LSP is out of service as a result of a + lock action on that tunnel LSP. By means outside of the scope of + this document, the Intermediate Point(s) of the PW or LSP may be + aware of this condition. The MPLS-TP OAM toolset MUST provide a + function to enable an Intermediate Point of a PW or LSP to report, to + an End Point of that same PW or LSP, a lock condition indirectly + affecting that PW or LSP. + + This function SHOULD be performed proactively. + + This function SHOULD be performed between Intermediate Points and End + Points of PWs and LSPs. + + The protocol solution(s) developed to perform this function MUST also + apply to point-to-point associated bidirectional LSPs, point-to-point + unidirectional LSPs, and point-to-multipoint LSPs. + +2.2.8. Alarm Reporting + + Based on the tunneling capabilities of MPLS, there are cases where + Intermediate Point(s) of a PW or of an LSP coincide with End Point(s) + of another LSP on which the former is mapped/tunneled. Further, it + may happen that the tunnel LSP be out of service as a result of a + fault on that tunnel LSP. By means outside of the scope of this + document, the Intermediate Point(s) of the PW or LSP may be aware of + this condition. 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 indirectly + affecting that PW or LSP. + + This function SHOULD be performed proactively. + + This function SHOULD be performed between Intermediate Points and End + Points of PWs and LSPs. + + + +Vigoureux, et al. Standards Track [Page 12] + +RFC 5860 OAM Requirements for MPLS-TP May 2010 + + + The protocol solution(s) developed to perform this function MUST also + apply to point-to-point associated bidirectional LSPs, point-to-point + unidirectional LSPs, and point-to-multipoint LSPs. + +2.2.9. Remote Defect Indication + + The MPLS-TP OAM toolset MUST provide a function 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 proactively. + + This function SHOULD be performed between End Points of PWs, LSPs, + and Sections. + + The protocol solution(s) developed to perform this function MUST also + apply to point-to-point associated bidirectional LSPs and MAY also + apply to point-to-point unidirectional LSPs and point-to-multipoint + LSPs in case a return path exists. + +2.2.10. Client Failure Indication + + The MPLS-TP OAM toolset MUST provide a function to enable the + propagation, from edge to edge of an MPLS-TP network, of information + pertaining to a client (i.e., external to the MPLS-TP network) defect + or fault condition detected at an End Point of a PW or LSP, if the + client layer OAM functionality does not provide an alarm + notification/propagation functionality. + + This function SHOULD be performed proactively. + + This function SHOULD be performed between End Points of PWs and LSPs. + + The protocol solution(s) developed to perform this function MUST also + apply to point-to-point associated bidirectional LSPs, point-to-point + unidirectional LSPs, and point-to-multipoint LSPs. + +2.2.11. Packet Loss Measurement + + The MPLS-TP OAM toolset MUST provide a function to enable the + quantification of packet loss ratio over a PW, LSP, or Section. + + The loss of a packet is defined in RFC2680 [6] (see Section 2.4). + This definition is used here. + + + + + + +Vigoureux, et al. Standards Track [Page 13] + +RFC 5860 OAM Requirements for MPLS-TP May 2010 + + + Packet-loss ratio is defined here to be the ratio of the number of + user packets lost to the total number of user packets sent during a + defined time interval. + + This function MAY either be performed proactively or on-demand. + + This function SHOULD be performed between End Points of PWs, LSPs, + and Sections. + + It SHOULD be possible to rely on user traffic to perform this + functionality. + + The protocol solution(s) developed to perform this function MUST also + apply to point-to-point associated bidirectional LSPs, point-to-point + unidirectional LSPs, and point-to-multipoint LSPs. + +2.2.12. Packet Delay Measurement + + The MPLS-TP OAM toolset MUST provide a function to enable the + quantification of the one-way, and if appropriate, the two-way, delay + of a PW, LSP, or Section. + + o The one-way delay is defined in [7] to be the time elapsed from + the start of transmission 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 The two-way delay is defined in [8] to be the time elapsed from + the start of transmission of the first bit of a packet by an End + Point until the reception of the last bit of that packet by the + same End Point. + + Two-way delay may be quantified using data traffic loopback at the + remote End Point of the PW, LSP, or Section (see Section 2.2.5). + + Accurate quantification of one-way delay may require clock + synchronization, the means for which are outside the scope of this + document. + + This function SHOULD be performed on-demand and MAY be performed + proactively. + + This function SHOULD be performed between End Points of PWs, LSPs, + and Sections. + + + + + + + +Vigoureux, et al. Standards Track [Page 14] + +RFC 5860 OAM Requirements for MPLS-TP May 2010 + + + The protocol solution(s) developed to perform this function MUST also + apply to point-to-point associated bidirectional LSPs, point-to-point + unidirectional LSPs, and point-to-multipoint LSPs, but only to enable + the quantification of the one-way delay. + +3. Congestion Considerations + + A mechanism (e.g., rate limiting) MUST be provided to prevent OAM + packets from causing congestion in the Packet Switched Network. + +4. Security Considerations + + This document, in itself, does not imply any security consideration + but OAM, as such, is subject to several security considerations. OAM + messages can reveal sensitive information such as passwords, + performance data and details about, e.g., the network topology. + + The nature of OAM therefore suggests having some form of + authentication, authorization, and encryption in place. This will + prevent unauthorized access to MPLS-TP equipment and it will prevent + third parties from learning about sensitive information about the + transport network. + + OAM systems (network management stations) SHOULD be designed such + that OAM functions cannot be accessed without authorization. + + OAM protocol solutions MUST include the facility for OAM messages to + authenticated to prove their origin and to make sure that they are + destined for the receiving node. The use of such facilities MUST be + configurable. + + 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. Acknowledgements + + The editors gratefully acknowledge the contributions of Matthew + Bocci, Italo Busi, Thomas Dietz, Annamaria Fulignoli, Huub van + Helvoort, Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, 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. + + + +Vigoureux, et al. Standards Track [Page 15] + +RFC 5860 OAM Requirements for MPLS-TP May 2010 + + +6. References + +6.1. Normative References + + [1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and + S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, + September 2009. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] ITU-T Recommendation G.806, "Characteristics of transport + equipment - Description methodology and generic functionality", + 2009. + + [4] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label + Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. + + [5] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit + Connectivity Verification (VCCV): A Control Channel for + Pseudowires", RFC 5085, December 2007. + + [6] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet + Loss Metric for IPPM", RFC 2680, September 1999. + + [7] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay + Metric for IPPM", RFC 2679, September 1999. + + [8] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay + Metric for IPPM", RFC 2681, September 1999. + +6.2. Informative References + + [9] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., + and L. Berger, "A Framework for MPLS in Transport Networks", + Work in Progress, May 2010. + + [10] 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. + + [11] 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. + + [12] Busi, I., Ed., Niven-Jenkins, B., Ed., and D. Allan, Ed., + "MPLS-TP OAM Framework", Work in Progress, April 2010. + + + +Vigoureux, et al. Standards Track [Page 16] + +RFC 5860 OAM Requirements for MPLS-TP May 2010 + + + [13] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD + For MPLS LSPs", Work in Progress, June 2008. + + [14] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional + Forwarding Detection (BFD) for the Pseudowire Virtual Circuit + Connectivity Verification (VCCV)", Work in Progress, July 2009. + +Authors' Addresses + + Martin Vigoureux (editor) + Alcatel-Lucent + Route de Villejust + Nozay 91620 + France + + EMail: martin.vigoureux@alcatel-lucent.com + + + David Ward (editor) + Juniper Networks + + EMail: dward@juniper.net + + + Malcolm Betts (editor) + M. C. Betts Consulting Ltd. + + EMail: malcolm.betts@rogers.com + + + + + + + + + + + + + + + + + + + + + + + +Vigoureux, et al. Standards Track [Page 17] + |