idnits 2.17.1 draft-ietf-mpls-tp-oam-requirements-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (December 16, 2009) is 5245 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 2680 (ref. '6') (Obsoleted by RFC 7680) ** Obsolete normative reference: RFC 2679 (ref. '7') (Obsoleted by RFC 7679) == Outdated reference: A later version (-12) exists of draft-ietf-mpls-tp-framework-06 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-tp-oam-framework-04 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 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: June 19, 2010 Cisco Systems, Inc. 6 M. Betts, Ed. 7 Huawei 8 December 16, 2009 10 Requirements for OAM in MPLS Transport Networks 11 draft-ietf-mpls-tp-oam-requirements-04 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 June 19, 2010. 43 Copyright Notice 45 Copyright (c) 2009 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 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. OAM and IP Capabilities . . . . . . . . . . . . . . . 7 68 2.1.4. Interoperability and Interworking . . . . . . . . . . 7 69 2.1.5. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 In the context of MPLS Transport Profile (MPLS-TP, see [9] 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 [10]. 142 By covering transport specificities, these requirements complement 143 those identified in RFC 4377 [11], 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 [12] 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. OAM and IP Capabilities 290 The OAM functionality may be deployed in various environments. 292 o In some environments (e.g., IP/MPLS environments), IP routing and 293 forwarding capabilities are inherently present in the data plane. 295 o In some environments (e.g., MPLS-TP environments), IP routing and 296 forwarding capabilities may not necessarily be present in the data 297 plane. 299 In the former case, it MUST be possible to operate the OAM functions 300 by relying on IP routing and forwarding capabilities (e.g., 301 encapsulation in IP header for (de)multiplexing purposes) while in 302 the latter case it MUST be possible to operate the OAM functions 303 without relying on IP routing and forwarding capabilities. 305 For certain functions, OAM messages need to incorporate 306 identification information (e.g., of source and/or destination 307 nodes). The protocol solution(s) MUST at least support 308 identification information in the form of an IP addressing structure 309 and MUST also be extensible to support additional identification 310 schemes. 312 2.1.4. Interoperability and Interworking 314 It is REQUIRED that OAM interoperability is achieved between distinct 315 domains materializing the environments described in Section 2.1.3. 316 It is also REQUIRED that the first two requirements of Section 2.1.3 317 still hold and MUST still be met when interoperability is achieved. 319 When MPLS-TP is run with IP routing and forwarding capabilities, it 320 MUST be possible to operate any of the existing IP/MPLS and PW OAM 321 protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [5] and VCCV-BFD 322 [14]). 324 2.1.5. Data Plane 326 OAM functions operate in the data plane. OAM packets MUST run in- 327 band; that is, OAM packets for a specific PW, LSP or Section MUST 328 follow the exact same data path as user traffic of that PW, LSP or 329 Section. This is often referred to as fate sharing. 331 It MUST be possible to discriminate user traffic from OAM packets. 333 This includes a means to differentiate OAM packets from user traffic 334 as well as the capability to apply specific treatment to OAM packets, 335 at the nodes processing these OAM packets. 337 As part of the design of OAM protocol solution(s) for MPLS-TP, a 338 mechanism, for enabling the encapsulation and differentiation of OAM 339 messages on a PW, LSP or Section, MUST be provided. Such mechanism 340 SHOULD also support the encapsulation and differentiation of existing 341 IP/MPLS and PW OAM messages. 343 2.1.6. Configuration 345 OAM functions MUST operate and be configurable even in the absence of 346 a control plane. Conversely, it SHOULD be possible to configure as 347 well as enable/disable the capability to operate OAM functions as 348 part of connectivity management and it SHOULD also be possible to 349 configure as well as enable/disable the capability to operate OAM 350 functions after connectivity has been established. 352 In the latter case, the customer MUST NOT perceive service 353 degradation as a result of OAM enabling/disabling. Ideally OAM 354 enabling/disabling should take place without introducing any customer 355 impairments (e.g., no customer packet losses). Procedures aimed to 356 prevent any traffic impairment MUST be defined for the enabling/ 357 disabling of OAM functions. 359 Means for configuring OAM functions and for connectivity management 360 are outside the scope of this document. 362 2.2. Functional Requirements 364 Hereafter are listed the required functionalities composing the 365 MPLS-TP OAM toolset. The list may not be exhaustive and as such the 366 OAM mechanisms developed in support of the identified requirements 367 SHALL be extensible and thus SHALL NOT preclude the definition of 368 additional OAM functionalities, in the future. 370 The design of OAM mechanisms for MPLS-TP, MUST allow for the ability 371 to support experimental OAM functions. These functions MUST be 372 disabled by default. 374 The use of any OAM function MUST be optional and it MUST be possible 375 to select the set of OAM function(s) to use on any PW, LSP or 376 Section. 378 It is RECOMMENDED that any protocol solution, meeting one or more 379 functional requirement(s), be the same for PWs, LSPs and Sections. 381 It is RECOMMENDED that any protocol solution, meeting one or more 382 functional requirement(s), effectively provides a fully featured 383 function; that is, a function which is applicable to all the cases 384 identified for that functionality. In that context, protocol 385 solution(s) MUST state their applicability. 387 Unless otherwise stated, the OAM functionalities MUST NOT rely on 388 user traffic; that is, only OAM messages MUST be used to achieve the 389 objectives. 391 For the on-demand OAM functions, the result of which may vary 392 depending on packet size, it SHOULD be possible to perform these 393 functions using different packet sizes. 395 2.2.1. General Requirements 397 If a defect or fault occurs on a PW, LSP or Section, mechanisms MUST 398 be provided to detect it, diagnose it, localize it, and notify the 399 appropriate nodes. Mechanisms SHOULD exist such that corrective 400 actions can be taken. 402 Furthermore, mechanisms MUST be available for a service provider to 403 be aware of a fault or defect affecting the service(s) he provides, 404 even if the fault or defect is located outside of his domain. 406 Protocol solution(s) developed to meet these requirements may rely on 407 information exchange. Information exchange between various nodes 408 involved in the operation of an OAM function SHOULD be reliable such 409 that, for example, defects or faults are properly detected or that 410 state changes are effectively known by the appropriate nodes. 412 2.2.2. Continuity Checks 414 The MPLS-TP OAM toolset MUST provide a function to enable an End 415 Point to monitor the liveness of a PW, LSP or Section. 417 This function SHOULD be performed between End Points of PWs, LSPs and 418 Sections. 420 This function SHOULD be performed pro-actively. 422 The protocol solution(s) developed to perform this function MUST also 423 apply to point-to-point associated bidirectional LSPs, point-to-point 424 unidirectional LSPs and point-to-multipoint LSPs. 426 2.2.3. Connectivity Verifications 428 The MPLS-TP OAM toolset MUST provide a function to enable an End 429 Point to determine whether or not it is connected to specific End 430 Point(s) by means of the expected PW, LSP or Section. 432 This function SHOULD be performed pro-actively between End Points of 433 PWs, LSPs and Sections. 435 This function SHOULD be performed on-demand between End Points and 436 Intermediate Points of PWs and LSPs, and between End Points of PWs, 437 LSPs and Sections. 439 The protocol solution(s) developed to perform this function pro- 440 actively MUST also apply to point-to-point associated bidirectional 441 LSPs, point-to-point unidirectional LSPs and point-to-multipoint 442 LSPs. 444 The protocol solution(s) developed to perform this function on-demand 445 MAY also apply to point-to-point associated bidirectional LSPs, to 446 point-to-point unidirectional LSPs and point-to-multipoint LSPs in 447 case a return path exists. 449 2.2.4. Route Tracing 451 The MPLS-TP OAM toolset MUST provide functionality to enable an End 452 Point to discover the Intermediate (if any) and End Point(s) along a 453 PW, LSP or Section, and more generally to trace the route of a PW, 454 LSP or Section. The information collected MUST include identifiers 455 related to the nodes and interfaces composing that route. 457 This function SHOULD be performed on-demand. 459 This function SHOULD be performed between End Points and Intermediate 460 Points of PWs and LSPs, and between End Points of PWs, LSPs and 461 Sections. 463 The protocol solution(s) developed to perform this function MAY also 464 apply to point-to-point associated bidirectional LSPs, to point-to- 465 point unidirectional LSPs and point-to-multipoint LSPs in case a 466 return path exists. 468 2.2.5. Diagnostic Tests 470 The MPLS-TP OAM toolset MUST provide a function to enable conducting 471 diagnostic tests on a PW, LSP or Section. An example of such 472 diagnostic test consists of performing a loop-back function at a node 473 such that all OAM and data traffic are looped back to the originating 474 End Point. Another example of such diagnostic test consists in 475 estimating the bandwidth of e.g., an LSP. 477 This function SHOULD be performed on-demand. 479 This function SHOULD be performed between End Points and Intermediate 480 Points of PWs and LSPs, and between End Points of PWs, LSPs and 481 Sections. 483 The protocol solution(s) developed to perform this function MAY also 484 apply to point-to-point associated bidirectional LSPs, to point-to- 485 point unidirectional LSPs and point-to-multipoint LSPs in case a 486 return path exists. 488 2.2.6. Lock Instruct 490 The MPLS-TP OAM toolset MUST provide functionality to enable an End 491 Point of a PW, LSP or Section to instruct its associated End Point(s) 492 to lock the PW, LSP or Section. Note that lock corresponds to an 493 administrative status in which it is expected that only test traffic, 494 if any, and OAM (dedicated to the PW, LSP or Section) can be mapped 495 on that PW, LSP or Section. 497 This function SHOULD be performed on-demand. 499 This function SHOULD be performed between End Points of PWs, LSPs and 500 Sections. 502 The protocol solution(s) developed to perform this function MUST also 503 apply to point-to-point associated bidirectional LSPs, point-to-point 504 unidirectional LSPs and point-to-multipoint LSPs. 506 2.2.7. Lock Reporting 508 Based on the tunnelling capabilities of MPLS, there are cases where 509 Intermediate Point(s) of a PW or of an LSP coincide with End Point(s) 510 of another LSP on which the former is mapped/tunnelled. Further, it 511 may happen that the tunnel LSP be out of service as a result of a 512 lock action on that tunnel LSP. By means outside of the scope of 513 this document, the Intermediate Point(s) of the PW or LSP may be 514 aware of this condition. The MPLS-TP OAM toolset MUST provide a 515 function to enable an Intermediate Point of a PW or LSP to report, to 516 an End Point of that same PW or LSP, a lock condition indirectly 517 affecting that PW or LSP. 519 This function SHOULD be performed pro-actively. 521 This function SHOULD be performed between Intermediate Points and End 522 Points of PWs and LSPs. 524 The protocol solution(s) developed to perform this function MUST also 525 apply to point-to-point associated bidirectional LSPs, point-to-point 526 unidirectional LSPs and point-to-multipoint LSPs. 528 2.2.8. Alarm Reporting 530 Based on the tunnelling capabilities of MPLS, there are cases where 531 Intermediate Point(s) of a PW or of an LSP coincide with End Point(s) 532 of another LSP on which the former is mapped/tunnelled. Further, it 533 may happen that the tunnel LSP be out of service as a result of a 534 fault on that tunnel LSP. By means outside of the scope of this 535 document, the Intermediate Point(s) of the PW or LSP may be aware of 536 this condition. The MPLS-TP OAM toolset MUST provide functionality 537 to enable an Intermediate Point of a PW or LSP to report, to an End 538 Point of that same PW or LSP, a fault or defect condition indirectly 539 affecting that PW or LSP. 541 This function SHOULD be performed pro-actively. 543 This function SHOULD be performed between Intermediate Points and End 544 Points of PWs and LSPs. 546 The protocol solution(s) developed to perform this function MUST also 547 apply to point-to-point associated bidirectional LSPs, point-to-point 548 unidirectional LSPs and point-to-multipoint LSPs. 550 2.2.9. Remote Defect Indication 552 The MPLS-TP OAM toolset MUST provide a function to enable an End 553 Point to report, to its associated End Point, a fault or defect 554 condition that it detects on a PW, LSP or Section for which they are 555 the End Points. 557 This function SHOULD be performed pro-actively. 559 This function SHOULD be performed between End Points of PWs, LSPs and 560 Sections. 562 The protocol solution(s) developed to perform this function MUST also 563 apply to point-to-point associated bidirectional LSPs and MAY also 564 apply to point-to-point unidirectional LSPs and point-to-multipoint 565 LSPs in case a return path exists. 567 2.2.10. Client Failure Indication 569 The MPLS-TP OAM toolset MUST provide a function to enable the 570 propagation, from edge to edge of an MPLS-TP network, of information 571 pertaining to a client (i.e., external to the MPLS-TP network) defect 572 or fault condition detected at an End Point of a PW or LSP, if the 573 client layer OAM functionality does not provide an alarm 574 notification/propagation functionality. 576 This function SHOULD be performed pro-actively. 578 This function SHOULD be performed between End Points of PWs and LSPs. 580 The protocol solution(s) developed to perform this function MUST also 581 apply to point-to-point associated bidirectional LSPs, point-to-point 582 unidirectional LSPs and point-to-multipoint LSPs. 584 2.2.11. Packet Loss Measurement 586 The MPLS-TP OAM toolset MUST provide a function to enable the 587 quantification of packet loss ratio over a PW, LSP or Section. 589 Note that packet loss ratio is the ratio of the user packets not 590 delivered to the total number of user packets transmitted during a 591 defined time interval. The number of user packets not delivered is 592 the difference between the number of user packets transmitted by an 593 End Point and the number of user packets received at an End Point. 594 See also [6]. 596 This function MAY either be performed pro-actively or on-demand. 598 This function SHOULD be performed between End Points of PWs, LSPs and 599 Sections. 601 It SHOULD be possible to rely on user traffic to perform that 602 functionality. 604 The protocol solution(s) developed to perform this function MUST also 605 apply to point-to-point associated bidirectional LSPs, point-to-point 606 unidirectional LSPs and point-to-multipoint LSPs. 608 2.2.12. Packet Delay Measurement 610 The MPLS-TP OAM toolset MUST provide a function to enable the 611 quantification of the one-way, and if appropriate, the two-way, delay 612 of a PW, LSP or Section. 614 Note that 615 o One-way delay is the time elapsed from the start of transmission 616 of the first bit of a packet by an End Point until the reception 617 of the last bit of that packet by the other End Point. See also 618 [7]. 620 o Two-way delay is the time elapsed from the start of transmission 621 of the first bit of a packet by a End Point until the reception of 622 the last bit of that packet by the same End Point. See also [8]. 623 Two-way delay may be quantified using data traffic loopback at the 624 remote End Point of the PW, LSP or Section (see Section 2.2.5). 626 This function SHOULD be performed on-demand and MAY be performed pro- 627 actively. 629 This function SHOULD be performed between End Points of PWs, LSPs and 630 Sections. 632 The protocol solution(s) developed to perform this function MUST also 633 apply to point-to-point associated bidirectional LSPs, point-to-point 634 unidirectional LSPs and point-to-multipoint LSPs but only to enable 635 the quantification of the one-way delay. 637 3. Congestion Considerations 639 A mechanism (e.g., rate limiting) MUST be provided to prevent OAM 640 packets from causing congestion in the Packet Switched Network. 642 4. Security Considerations 644 This document, in itself, does not imply any security consideration 645 but OAM, as such, is subject to several security considerations. OAM 646 messages can reveal sensitive information such as passwords, 647 performance data and details about e.g., the network topology. 649 The nature of OAM therefore suggests having some form of 650 authentication, authorization and encryption in place. This will 651 prevent unauthorized access to MPLS-TP equipment and it will prevent 652 third parties from learning about sensitive information about the 653 transport network. 655 OAM systems (network management stations) SHOULD be designed such 656 that OAM functions cannot be accessed without authorization. 658 OAM protocol solutions MUST include the facility for OAM messages to 659 authenticated to prove their origin and to make sure that they are 660 destined for the receiving node. The use of such facilities MUST be 661 configurable. 663 An OAM packet received over a PW, LSP or Section MUST NOT be 664 forwarded beyond the End Point of that PW, LSP or Section, so as to 665 avoid that the OAM packet leaves the current administrative domain. 667 5. IANA Considerations 669 There are no IANA actions required by this draft. 671 6. Acknowledgements 673 The editors gratefully acknowledge the contributions of Matthew 674 Bocci, Italo Busi, Thomas Dietz, Annamaria Fulignoli, Huub van 675 Helvoort, Wataru Imajuku, Marc Lasserre, Lieven Levrau, Han Li, 676 Julien Meuric, Philippe Niger, Benjamin Niven-Jenkins, Jing Ruiquan, 677 Nurit Sprecher, Yuji Tochio, Satoshi Ueno and Yaacov Weingarten. 679 The authors would like to thank all members of the teams (the Joint 680 Working Team, the MPLS Interoperability Design Team in IETF and the 681 MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and 682 specification of MPLS-TP. 684 7. References 686 7.1. Normative References 688 [1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and 689 S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, 690 September 2009. 692 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 693 Levels", BCP 14, RFC 2119, March 1997. 695 [3] ITU-T Recommendation G.806, "Characteristics of transport 696 equipment - Description methodology and generic functionality", 697 2009. 699 [4] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label 700 Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 702 [5] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 703 Connectivity Verification (VCCV): A Control Channel for 704 Pseudowires", RFC 5085, December 2007. 706 [6] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet 707 Loss Metric for IPPM", RFC 2680, September 1999. 709 [7] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay 710 Metric for IPPM", RFC 2679, September 1999. 712 [8] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 713 Metric for IPPM", RFC 2681, September 1999. 715 7.2. Informative References 717 [9] Bocci, M., Bryant, S., Frost, D., and L. Levrau, "A Framework 718 for MPLS in Transport Networks", 719 draft-ietf-mpls-tp-framework-06 (work in progress), 720 October 2009. 722 [10] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on 723 transport requirements for T-MPLS OAM and considerations for 724 the application of IETF MPLS technology", 2008. 726 [11] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. 727 Matsushima, "Operations and Management (OAM) Requirements for 728 Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, 729 February 2006. 731 [12] Allan, D., Busi, I., and B. Niven-Jenkins, "MPLS-TP OAM 732 Framework", draft-ietf-mpls-tp-oam-framework-04 (work in 733 progress), December 2009. 735 [13] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD 736 For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress), 737 June 2008. 739 [14] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 740 Detection (BFD) for the Pseudowire Virtual Circuit Connectivity 741 Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-07 (work in 742 progress), July 2009. 744 Authors' Addresses 746 Martin Vigoureux (editor) 747 Alcatel-Lucent 748 Route de Villejust 749 Nozay, 91620 750 France 752 Email: martin.vigoureux@alcatel-lucent.com 754 David Ward (editor) 755 Cisco Systems, Inc. 756 170 W. Tasman Dr. 757 San Jose, CA 95134 758 USA 760 Email: dward@cisco.com 762 Malcolm Betts (editor) 763 Huawei 765 Email: malcolm.betts@huawei.com