idnits 2.17.1 draft-ietf-mpls-tp-oam-requirements-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 17, 2010) is 5182 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 4379 (ref. '4') (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 2679 (ref. '6') (Obsoleted by RFC 7679) == Outdated reference: A later version (-12) exists of draft-ietf-mpls-tp-framework-10 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-tp-oam-framework-04 -- Obsolete informational reference (is this intentional?): RFC 2680 (ref. '14') (Obsoleted by RFC 7680) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group M. Vigoureux, Ed. 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track D. Ward, Ed. 5 Expires: August 21, 2010 Juniper Networks 6 M. Betts, Ed. 7 ZTE Corporation 8 February 17, 2010 10 Requirements for OAM in MPLS Transport Networks 11 draft-ietf-mpls-tp-oam-requirements-05 13 Abstract 15 This document lists architectural and functional requirements for the 16 Operations, Administration and Maintenance of MPLS Transport Profile. 17 These requirements apply to pseudowires, Label Switched Paths, and 18 Sections. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 21, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 3 62 1.2. Requirements Language and Terminology . . . . . . . . . . 4 63 2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1. Architectural Requirements . . . . . . . . . . . . . . . . 6 65 2.1.1. Scope of OAM . . . . . . . . . . . . . . . . . . . . . 6 66 2.1.2. Independence . . . . . . . . . . . . . . . . . . . . . 6 67 2.1.3. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7 68 2.1.4. OAM and IP Capabilities . . . . . . . . . . . . . . . 7 69 2.1.5. Interoperability and Interworking . . . . . . . . . . 8 70 2.1.6. Configuration . . . . . . . . . . . . . . . . . . . . 8 71 2.2. Functional Requirements . . . . . . . . . . . . . . . . . 8 72 2.2.1. General Requirements . . . . . . . . . . . . . . . . . 9 73 2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 9 74 2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 10 75 2.2.4. Route Tracing . . . . . . . . . . . . . . . . . . . . 10 76 2.2.5. Diagnostic Tests . . . . . . . . . . . . . . . . . . . 11 77 2.2.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . 11 78 2.2.7. Lock Reporting . . . . . . . . . . . . . . . . . . . . 11 79 2.2.8. Alarm Reporting . . . . . . . . . . . . . . . . . . . 12 80 2.2.9. Remote Defect Indication . . . . . . . . . . . . . . . 12 81 2.2.10. Client Failure Indication . . . . . . . . . . . . . . 13 82 2.2.11. Packet Loss Measurement . . . . . . . . . . . . . . . 13 83 2.2.12. Packet Delay Measurement . . . . . . . . . . . . . . . 14 84 3. Congestion Considerations . . . . . . . . . . . . . . . . . . 14 85 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 88 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 90 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 93 1. Introduction 95 In the context of MPLS Transport Profile (MPLS-TP, see [8] and [1]), 96 the rationales for Operations, Administration and Maintenance (OAM) 97 are twofold as it can serve: 99 o as a network-oriented functionality, used by a transport network 100 operator to monitor his network infrastructure and to implement 101 internal mechanisms in order to enhance the general behaviour and 102 the level of performance of his network (e.g., protection 103 mechanism in case of node or link failure). As an example, fault 104 localization is typically associated with this use case. 106 o as a service-oriented functionality, used by a transport service 107 provider to monitor services offered to end customers in order to 108 be able to react rapidly in case of a problem and to be able to 109 verify some of the Service Level Agreements (SLAs) parameters 110 (e.g., using performance monitoring) negotiated with the end 111 customers. Note that a transport service could be provided over 112 several networks or administrative domains that may not all be 113 owned and managed by the same transport service provider. 115 More generally, OAM is an important and fundamental functionality in 116 transport networks as it contributes to: 118 o the reduction of operational complexity and costs, by allowing for 119 efficient and automatic detection, localisation, handling and 120 diagnosis of defects, as well as by minimizing service 121 interruptions and operational repair times. 123 o the enhancement of network availability, by ensuring that defects, 124 for example resulting in misdirected customer traffic, and faults, 125 are detected, diagnosed and dealt with before a customer reports 126 the problem. 128 o meeting service and performance objectives, as the OAM 129 functionality allows for SLA verification in a multi-maintenance 130 domain environment and allows for the determination of service 131 degradation due, for example, to packet delay or packet loss. 133 1.1. Scope of this Document 135 This document lists architectural and functional requirements for the 136 OAM functionality of MPLS-TP. These requirements apply to 137 pseudowires (PWs), Label Switched Paths (LSPs) and Sections. 139 These requirements are derived from the set of requirements specified 140 by ITU-T and published in the ITU-T Supplement Y.Sup4 [9]. 142 By covering transport specificities, these requirements complement 143 those identified in RFC 4377 [10], yet some requirements may be 144 similar. 146 This document only lists architectural and functional OAM 147 requirements. It does not detail the implications of their 148 applicability to the various types (e.g., point-to-point, point-to- 149 multipoint, unidirectional, bidirectional ...) of PWs, LSPs and 150 Sections. Furthermore, this document does not provide requirements 151 on how the protocol solution(s) should behave to achieve the 152 functional objectives. Please see [11] for further information. 154 Note that the OAM functions identified in this document may be used 155 for fault management, performance monitoring and/or protection 156 switching applications. For example, connectivity verification can 157 be used for fault management by detecting failure conditions, but may 158 also be used for performance monitoring through its contribution to 159 the evaluation of performance metrics (e.g., unavailability time). 160 Nevertheless, it is outside the scope of this document to specify 161 which function should be used for which application. 163 Note also that it is anticipated that implementers may wish to 164 implement OAM message handling in hardware. Although not a 165 requirement, this fact could be taken as a design consideration. 167 1.2. Requirements Language and Terminology 169 Although this document is not a protocol specification, the key words 170 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 171 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be 172 interpreted as described in RFC 2119 [2] and are to be interpreted as 173 instructions to the protocol designers producing solutions that 174 satisfy the requirements set out in this document. 176 In this document we refer to the inability of a function to perform a 177 required action, as a fault. This does not include an inability due 178 to preventive maintenance, lack of external resources, or planned 179 actions. See also ITU-T G.806 [3]. 181 In this document we refer to the situation in which the density of 182 anomalies has reached a level where the ability to perform a required 183 function has been interrupted, as a defect. See also ITU-T G.806 184 [3]. 186 In this document we refer to OAM actions which are carried out 187 continuously or at least on long periods of time, permitting 188 proactive reporting of fault and/or performance results, as proactive 189 OAM. 191 In this document we refer to OAM actions which are initiated via 192 manual intervention for a limited time to carry out troubleshooting, 193 as on-demand OAM. 195 In this document we refer to a Label Edge Router (LER), for a given 196 LSP or Section, and to a PW Terminating Provider Edge (T-PE), for a 197 given PW, as an End Point. Further, we refer to a Label Switching 198 Router (LSR), for a given LSP, and to a PW Switching Provider Edge 199 (S-PE), for a given PW, as an Intermediate Point. This document does 200 not make a distinction between End Points (e.g., source and 201 destination) as it can be inferred from the context of the sentences. 203 In this document we use the term "node" as a general reference to End 204 Points and Intermediate Points. 206 In this document we refer to both segment and concatenated segments 207 as segments (see [1] for definitions relating to the term "segment" 208 as well as for other definitions relating to MPLS-TP). 210 In this document we refer to both single segment PWs and multi- 211 segment PWs as PWs. 213 In this document we refer to both bidirectional associated LSPs and 214 bidirectional co-routed LSPs as bidirectional LSPs. 216 2. OAM Requirements 218 This section lists the requirements by which the OAM functionality of 219 MPLS-TP should abide. 221 The requirements listed below may be met by one or more OAM 222 protocols; the definition or selection of these protocols is outside 223 the scope of this document. 225 RFC5654 [1] states (Requirement #2) that the MPLS-TP design SHOULD as 226 far as reasonably possible reuse existing MPLS standards. This 227 general requirement applies to MPLS-TP OAM. MPLS-TP OAM is defined 228 in this document through a set of functional requirements. These 229 requirements will be met by protocol solutions defined in other 230 documents. The way in which those protocols are operated and the way 231 in which a network operator can control and use the MPLS-TP OAM 232 functions SHOULD be as similar as possible to the mechanisms and 233 techniques used to operate OAM in other transport technologies. 235 2.1. Architectural Requirements 237 2.1.1. Scope of OAM 239 The protocol solution(s) developed to meet the requirements 240 identified in this document MUST at least be applicable to point-to- 241 point bidirectional PWs, point-to-point co-routed bidirectional LSPs, 242 and point-to-point bidirectional Sections. Section 2.2 provides 243 additional information with regards to the applicability to point-to- 244 point associated bidirectional LSPs, point-to-point unidirectional 245 LSPs and point-to-multipoint LSPs. 247 The service emulated by a PW may span multiple domains. An LSP may 248 also span multiple domains. The protocol solution(s) MUST be 249 applicable end-to-end and to segments. More generally, it MUST be 250 possible to operate OAM functions on a per domain basis and across 251 multiple domains. 253 Since LSPs may be stacked, the protocol solution(s) MUST be 254 applicable on any LSP, regardless of the label stack depth. 255 Furthermore it MUST be possible to estimate OAM fault and performance 256 metrics of a single PW or LSP segment or of an aggregate of PWs or 257 LSPs segments. 259 2.1.2. Independence 261 The protocol solution(s) SHOULD be independent of the underlying 262 tunnelling or point-to-point technology or transmission media. 264 The protocol solution(s) SHOULD be independent of the service a PW 265 may emulate. 267 Any OAM function operated on a PW, LSP or Section SHOULD be 268 independent of the OAM function(s) operated on a different PW, LSP or 269 Section. In other words, only the OAM functions operated on e.g., a 270 given LSP should be used to achieve the OAM objectives for that LSP. 272 The protocol solution(s) MUST support the capability to be 273 concurrently and independently operated end-to-end and on segments. 274 Therefore, any OAM function applied to segment(s) of a PW or LSP 275 SHOULD be independent of the OAM function(s) operated on the end-to- 276 end PW or LSP. It SHOULD also be possible to distinguish an OAM 277 packet running over a segment of a PW or LSP from another OAM packet 278 running on the end-to-end PW or LSP. 280 Furthermore, any OAM function applied to segment(s) of a PW or LSP 281 SHOULD be independent of the OAM function(s) applied to other 282 segment(s) of the same PW or LSP. 284 Note: Independence should not be understood in terms of isolation as 285 there can be interactions between OAM functions operated on e.g., 286 an LSP, and on another LSP or a PW. 288 2.1.3. Data Plane 290 OAM functions operate in the data plane. OAM packets MUST run in- 291 band; that is, OAM packets for a specific PW, LSP or Section MUST 292 follow the exact same data path as user traffic of that PW, LSP or 293 Section. This is often referred to as fate sharing. 295 It MUST be possible to discriminate user traffic from OAM packets. 296 This includes a means to differentiate OAM packets from user traffic 297 as well as the capability to apply specific treatment to OAM packets, 298 at the nodes processing these OAM packets. 300 As part of the design of OAM protocol solution(s) for MPLS-TP, a 301 mechanism, for enabling the encapsulation and differentiation of OAM 302 messages on a PW, LSP or Section, MUST be provided. Such mechanism 303 SHOULD also support the encapsulation and differentiation of existing 304 IP/MPLS and PW OAM messages. 306 2.1.4. OAM and IP Capabilities 308 There are environments where IP capabilities are present in the data 309 plane. IP/MPLS environments are examples of such environments. 310 There are also environments where IP capabilities may not be present 311 in the data plane. MPLS-TP environments are examples of environments 312 where IP capabilities might or might not be present. 313 Presence or absence of IP capabilities is deployment scenario 314 dependent. 316 It MUST be possible to deploy the OAM functionality in any of these 317 environments. As a result, it MUST be possible to operate OAM 318 functions with or without relying on IP capabilities and it MUST be 319 possible to choose to make use of IP capabilities when these are 320 present. 322 Furthermore, the mechanism required for enabling the encapsulation 323 and differentiation of OAM messages (see Section 2.1.3) MUST support 324 the capability to differentiate OAM messages of an OAM function 325 operated by relying on IP capabilities (e.g., using encapsulation in 326 an IP header) from OAM messages of an OAM function operated without 327 relying on any IP capability. 329 Note that IP capabilities include the capability to form a standard 330 IP header, to encapsulate a payload in an IP header, to parse and 331 analyse the fields of an IP header and to take actions based on the 332 content of these fields. 334 For certain functions, OAM messages need to incorporate 335 identification information (e.g., of source and/or destination 336 nodes). The protocol solution(s) MUST at least support 337 identification information in the form of an IP addressing structure 338 and MUST also be extensible to support additional identification 339 schemes. 341 2.1.5. Interoperability and Interworking 343 It is REQUIRED that OAM interoperability is achieved between distinct 344 domains materializing the environments described in Section 2.1.4. 345 It is also REQUIRED that the first two requirements of Section 2.1.4 346 still hold and MUST still be met when interoperability is achieved. 348 When MPLS-TP is run with IP routing and forwarding capabilities, it 349 MUST be possible to operate any of the existing IP/MPLS and PW OAM 350 protocols (e.g., LSP-Ping [4], MPLS-BFD [12], VCCV [5] and VCCV-BFD 351 [13]). 353 2.1.6. Configuration 355 OAM functions MUST operate and be configurable even in the absence of 356 a control plane. Conversely, it SHOULD be possible to configure as 357 well as enable/disable the capability to operate OAM functions as 358 part of connectivity management and it SHOULD also be possible to 359 configure as well as enable/disable the capability to operate OAM 360 functions after connectivity has been established. 362 In the latter case, the customer MUST NOT perceive service 363 degradation as a result of OAM enabling/disabling. Ideally OAM 364 enabling/disabling should take place without introducing any customer 365 impairments (e.g., no customer packet losses). Procedures aimed to 366 prevent any traffic impairment MUST be defined for the enabling/ 367 disabling of OAM functions. 369 Means for configuring OAM functions and for connectivity management 370 are outside the scope of this document. 372 2.2. Functional Requirements 374 Hereafter are listed the required functionalities composing the 375 MPLS-TP OAM toolset. The list may not be exhaustive and as such the 376 OAM mechanisms developed in support of the identified requirements 377 SHALL be extensible and thus SHALL NOT preclude the definition of 378 additional OAM functionalities, in the future. 380 The design of OAM mechanisms for MPLS-TP, MUST allow for the ability 381 to support experimental OAM functions. These functions MUST be 382 disabled by default. 384 The use of any OAM function MUST be optional and it MUST be possible 385 to select the set of OAM function(s) to use on any PW, LSP or 386 Section. 388 It is RECOMMENDED that any protocol solution, meeting one or more 389 functional requirement(s), be the same for PWs, LSPs and Sections. 391 It is RECOMMENDED that any protocol solution, meeting one or more 392 functional requirement(s), effectively provides a fully featured 393 function; that is, a function which is applicable to all the cases 394 identified for that functionality. In that context, protocol 395 solution(s) MUST state their applicability. 397 Unless otherwise stated, the OAM functionalities MUST NOT rely on 398 user traffic; that is, only OAM messages MUST be used to achieve the 399 objectives. 401 For the on-demand OAM functions, the result of which may vary 402 depending on packet size, it SHOULD be possible to perform these 403 functions using different packet sizes. 405 2.2.1. General Requirements 407 If a defect or fault occurs on a PW, LSP or Section, mechanisms MUST 408 be provided to detect it, diagnose it, localize it, and notify the 409 appropriate nodes. Mechanisms SHOULD exist such that corrective 410 actions can be taken. 412 Furthermore, mechanisms MUST be available for a service provider to 413 be aware of a fault or defect affecting the service(s) he provides, 414 even if the fault or defect is located outside of his domain. 416 Protocol solution(s) developed to meet these requirements may rely on 417 information exchange. Information exchange between various nodes 418 involved in the operation of an OAM function SHOULD be reliable such 419 that, for example, defects or faults are properly detected or that 420 state changes are effectively known by the appropriate nodes. 422 2.2.2. Continuity Checks 424 The MPLS-TP OAM toolset MUST provide a function to enable an End 425 Point to monitor the liveliness of a PW, LSP or Section. 427 This function SHOULD be performed between End Points of PWs, LSPs and 428 Sections. 430 This function SHOULD be performed pro-actively. 432 The protocol solution(s) developed to perform this function MUST also 433 apply to point-to-point associated bidirectional LSPs, point-to-point 434 unidirectional LSPs and point-to-multipoint LSPs. 436 2.2.3. Connectivity Verifications 438 The MPLS-TP OAM toolset MUST provide a function to enable an End 439 Point to determine whether or not it is connected to specific End 440 Point(s) by means of the expected PW, LSP or Section. 442 This function SHOULD be performed pro-actively between End Points of 443 PWs, LSPs and Sections. 445 This function SHOULD be performed on-demand between End Points and 446 Intermediate Points of PWs and LSPs, and between End Points of PWs, 447 LSPs and Sections. 449 The protocol solution(s) developed to perform this function pro- 450 actively MUST also apply to point-to-point associated bidirectional 451 LSPs, point-to-point unidirectional LSPs and point-to-multipoint 452 LSPs. 454 The protocol solution(s) developed to perform this function on-demand 455 MAY also apply to point-to-point associated bidirectional LSPs, to 456 point-to-point unidirectional LSPs and point-to-multipoint LSPs in 457 case a return path exists. 459 2.2.4. Route Tracing 461 The MPLS-TP OAM toolset MUST provide functionality to enable an End 462 Point to discover the Intermediate (if any) and End Point(s) along a 463 PW, LSP or Section, and more generally to trace the route of a PW, 464 LSP or Section. The information collected MUST include identifiers 465 related to the nodes and interfaces composing that route. 467 This function SHOULD be performed on-demand. 469 This function SHOULD be performed between End Points and Intermediate 470 Points of PWs and LSPs, and between End Points of PWs, LSPs and 471 Sections. 473 The protocol solution(s) developed to perform this function MAY also 474 apply to point-to-point associated bidirectional LSPs, to point-to- 475 point unidirectional LSPs and point-to-multipoint LSPs in case a 476 return path exists. 478 2.2.5. Diagnostic Tests 480 The MPLS-TP OAM toolset MUST provide a function to enable conducting 481 diagnostic tests on a PW, LSP or Section. An example of such 482 diagnostic test consists of performing a loop-back function at a node 483 such that all OAM and data traffic are looped back to the originating 484 End Point. Another example of such diagnostic test consists in 485 estimating the bandwidth of e.g., an LSP. 487 This function SHOULD be performed on-demand. 489 This function SHOULD be performed between End Points and Intermediate 490 Points of PWs and LSPs, and between End Points of PWs, LSPs and 491 Sections. 493 The protocol solution(s) developed to perform this function MAY also 494 apply to point-to-point associated bidirectional LSPs, to point-to- 495 point unidirectional LSPs and point-to-multipoint LSPs in case a 496 return path exists. 498 2.2.6. Lock Instruct 500 The MPLS-TP OAM toolset MUST provide functionality to enable an End 501 Point of a PW, LSP or Section to instruct its associated End Point(s) 502 to lock the PW, LSP or Section. Note that lock corresponds to an 503 administrative status in which it is expected that only test traffic, 504 if any, and OAM (dedicated to the PW, LSP or Section) can be mapped 505 on that PW, LSP or Section. 507 This function SHOULD be performed on-demand. 509 This function SHOULD be performed between End Points of PWs, LSPs and 510 Sections. 512 The protocol solution(s) developed to perform this function MUST also 513 apply to point-to-point associated bidirectional LSPs, point-to-point 514 unidirectional LSPs and point-to-multipoint LSPs. 516 2.2.7. Lock Reporting 518 Based on the tunnelling capabilities of MPLS, there are cases where 519 Intermediate Point(s) of a PW or of an LSP coincide with End Point(s) 520 of another LSP on which the former is mapped/tunnelled. Further, it 521 may happen that the tunnel LSP be out of service as a result of a 522 lock action on that tunnel LSP. By means outside of the scope of 523 this document, the Intermediate Point(s) of the PW or LSP may be 524 aware of this condition. The MPLS-TP OAM toolset MUST provide a 525 function to enable an Intermediate Point of a PW or LSP to report, to 526 an End Point of that same PW or LSP, a lock condition indirectly 527 affecting that PW or LSP. 529 This function SHOULD be performed pro-actively. 531 This function SHOULD be performed between Intermediate Points and End 532 Points of PWs and LSPs. 534 The protocol solution(s) developed to perform this function MUST also 535 apply to point-to-point associated bidirectional LSPs, point-to-point 536 unidirectional LSPs and point-to-multipoint LSPs. 538 2.2.8. Alarm Reporting 540 Based on the tunnelling capabilities of MPLS, there are cases where 541 Intermediate Point(s) of a PW or of an LSP coincide with End Point(s) 542 of another LSP on which the former is mapped/tunnelled. Further, it 543 may happen that the tunnel LSP be out of service as a result of a 544 fault on that tunnel LSP. By means outside of the scope of this 545 document, the Intermediate Point(s) of the PW or LSP may be aware of 546 this condition. The MPLS-TP OAM toolset MUST provide functionality 547 to enable an Intermediate Point of a PW or LSP to report, to an End 548 Point of that same PW or LSP, a fault or defect condition indirectly 549 affecting that PW or LSP. 551 This function SHOULD be performed pro-actively. 553 This function SHOULD be performed between Intermediate Points and End 554 Points of PWs and LSPs. 556 The protocol solution(s) developed to perform this function MUST also 557 apply to point-to-point associated bidirectional LSPs, point-to-point 558 unidirectional LSPs and point-to-multipoint LSPs. 560 2.2.9. Remote Defect Indication 562 The MPLS-TP OAM toolset MUST provide a function to enable an End 563 Point to report, to its associated End Point, a fault or defect 564 condition that it detects on a PW, LSP or Section for which they are 565 the End Points. 567 This function SHOULD be performed pro-actively. 569 This function SHOULD be performed between End Points of PWs, LSPs and 570 Sections. 572 The protocol solution(s) developed to perform this function MUST also 573 apply to point-to-point associated bidirectional LSPs and MAY also 574 apply to point-to-point unidirectional LSPs and point-to-multipoint 575 LSPs in case a return path exists. 577 2.2.10. Client Failure Indication 579 The MPLS-TP OAM toolset MUST provide a function to enable the 580 propagation, from edge to edge of an MPLS-TP network, of information 581 pertaining to a client (i.e., external to the MPLS-TP network) defect 582 or fault condition detected at an End Point of a PW or LSP, if the 583 client layer OAM functionality does not provide an alarm 584 notification/propagation functionality. 586 This function SHOULD be performed pro-actively. 588 This function SHOULD be performed between End Points of PWs and LSPs. 590 The protocol solution(s) developed to perform this function MUST also 591 apply to point-to-point associated bidirectional LSPs, point-to-point 592 unidirectional LSPs and point-to-multipoint LSPs. 594 2.2.11. Packet Loss Measurement 596 The MPLS-TP OAM toolset MUST provide a function to enable the 597 quantification of packet loss ratio over a PW, LSP or Section. 599 Packet loss ratio is defined to be the ratio of the user packets not 600 delivered to the total number of user packets transmitted during a 601 defined time interval. The number of user packets not delivered is 602 the difference between the number of user packets transmitted by an 603 End Point and the number of user packets received at an End Point. 605 Note that RFC2680 [14] defines packet loss as well as provides 606 definitions for samples and statistics for packet loss. 608 This function MAY either be performed pro-actively or on-demand. 610 This function SHOULD be performed between End Points of PWs, LSPs and 611 Sections. 613 It SHOULD be possible to rely on user traffic to perform that 614 functionality. 616 The protocol solution(s) developed to perform this function MUST also 617 apply to point-to-point associated bidirectional LSPs, point-to-point 618 unidirectional LSPs and point-to-multipoint LSPs. 620 2.2.12. Packet Delay Measurement 622 The MPLS-TP OAM toolset MUST provide a function to enable the 623 quantification of the one-way, and if appropriate, the two-way, delay 624 of a PW, LSP or Section. 626 o The one-way delay is defined in [6] to be the time elapsed from 627 the start of transmission of the first bit of a packet by an End 628 Point until the reception of the last bit of that packet by the 629 other End Point. 631 o The two-way delay is defined in [7] to be the time elapsed from 632 the start of transmission of the first bit of a packet by an End 633 Point until the reception of the last bit of that packet by the 634 same End Point. 636 Two-way delay may be quantified using data traffic loopback at the 637 remote End Point of the PW, LSP or Section (see Section 2.2.5). 639 Accurate quantification of one-way delay may require clock 640 synchronization, the means for which are outside the scope of this 641 document. 643 This function SHOULD be performed on-demand and MAY be performed pro- 644 actively. 646 This function SHOULD be performed between End Points of PWs, LSPs and 647 Sections. 649 The protocol solution(s) developed to perform this function MUST also 650 apply to point-to-point associated bidirectional LSPs, point-to-point 651 unidirectional LSPs and point-to-multipoint LSPs but only to enable 652 the quantification of the one-way delay. 654 3. Congestion Considerations 656 A mechanism (e.g., rate limiting) MUST be provided to prevent OAM 657 packets from causing congestion in the Packet Switched Network. 659 4. Security Considerations 661 This document, in itself, does not imply any security consideration 662 but OAM, as such, is subject to several security considerations. OAM 663 messages can reveal sensitive information such as passwords, 664 performance data and details about e.g., the network topology. 666 The nature of OAM therefore suggests having some form of 667 authentication, authorization and encryption in place. This will 668 prevent unauthorized access to MPLS-TP equipment and it will prevent 669 third parties from learning about sensitive information about the 670 transport network. 672 OAM systems (network management stations) SHOULD be designed such 673 that OAM functions cannot be accessed without authorization. 675 OAM protocol solutions MUST include the facility for OAM messages to 676 authenticated to prove their origin and to make sure that they are 677 destined for the receiving node. The use of such facilities MUST be 678 configurable. 680 An OAM packet received over a PW, LSP or Section MUST NOT be 681 forwarded beyond the End Point of that PW, LSP or Section, so as to 682 avoid that the OAM packet leaves the current administrative domain. 684 5. IANA Considerations 686 There are no IANA actions required by this draft. 688 6. Acknowledgements 690 The editors gratefully acknowledge the contributions of Matthew 691 Bocci, Italo Busi, Thomas Dietz, Annamaria Fulignoli, Huub van 692 Helvoort, Wataru Imajuku, Marc Lasserre, Lieven Levrau, Han Li, 693 Julien Meuric, Philippe Niger, Benjamin Niven-Jenkins, Jing Ruiquan, 694 Nurit Sprecher, Yuji Tochio, Satoshi Ueno and Yaacov Weingarten. 696 The authors would like to thank all members of the teams (the Joint 697 Working Team, the MPLS Interoperability Design Team in IETF and the 698 MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and 699 specification of MPLS-TP. 701 7. References 703 7.1. Normative References 705 [1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and 706 S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, 707 September 2009. 709 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 710 Levels", BCP 14, RFC 2119, March 1997. 712 [3] ITU-T Recommendation G.806, "Characteristics of transport 713 equipment - Description methodology and generic functionality", 714 2009. 716 [4] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label 717 Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 719 [5] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 720 Connectivity Verification (VCCV): A Control Channel for 721 Pseudowires", RFC 5085, December 2007. 723 [6] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay 724 Metric for IPPM", RFC 2679, September 1999. 726 [7] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 727 Metric for IPPM", RFC 2681, September 1999. 729 7.2. Informative References 731 [8] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A 732 Framework for MPLS in Transport Networks", 733 draft-ietf-mpls-tp-framework-10 (work in progress), 734 February 2010. 736 [9] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on 737 transport requirements for T-MPLS OAM and considerations for 738 the application of IETF MPLS technology", 2008. 740 [10] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. 741 Matsushima, "Operations and Management (OAM) Requirements for 742 Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, 743 February 2006. 745 [11] Allan, D., Busi, I., and B. Niven-Jenkins, "MPLS-TP OAM 746 Framework", draft-ietf-mpls-tp-oam-framework-04 (work in 747 progress), December 2009. 749 [12] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD 750 For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress), 751 June 2008. 753 [13] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 754 Detection (BFD) for the Pseudowire Virtual Circuit Connectivity 755 Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-07 (work in 756 progress), July 2009. 758 [14] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet 759 Loss Metric for IPPM", RFC 2680, September 1999. 761 Authors' Addresses 763 Martin Vigoureux (editor) 764 Alcatel-Lucent 765 Route de Villejust 766 Nozay, 91620 767 France 769 Email: martin.vigoureux@alcatel-lucent.com 771 David Ward (editor) 772 Juniper Networks 774 Email: dward@juniper.net 776 Malcolm Betts (editor) 777 ZTE Corporation 779 Email: malcolm.betts@zte.com.cn