idnits 2.17.1 draft-ietf-mpls-tp-oam-requirements-06.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 date (March 5, 2010) is 5166 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-10 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-tp-oam-framework-04 Summary: 3 errors (**), 0 flaws (~~), 3 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: September 6, 2010 Juniper Networks 6 M. Betts, Ed. 7 M. C. Betts Consulting Ltd. 8 March 5, 2010 10 Requirements for OAM in MPLS Transport Networks 11 draft-ietf-mpls-tp-oam-requirements-06 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 September 6, 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 [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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in RFC 2119 [2]. 172 Although this document is not a protocol specification, the use of 173 this language clarifies the instructions to protocol designers 174 producing solutions that satisfy the requirements set out in this 175 document. 177 In this document we refer to the inability of a function to perform a 178 required action, as a fault. This does not include an inability due 179 to preventive maintenance, lack of external resources, or planned 180 actions. See also ITU-T G.806 [3]. 182 In this document we refer to the situation in which the density of 183 anomalies has reached a level where the ability to perform a required 184 function has been interrupted, as a defect. See also ITU-T G.806 185 [3]. 187 In this document we refer to OAM actions which are carried out 188 continuously or at least on long periods of time, permitting 189 proactive reporting of fault and/or performance results, as proactive 190 OAM. 192 In this document we refer to OAM actions which are initiated via 193 manual intervention for a limited time to carry out troubleshooting, 194 as on-demand OAM. 196 In this document we refer to a Label Edge Router (LER), for a given 197 LSP or Section, and to a PW Terminating Provider Edge (T-PE), for a 198 given PW, as an End Point. Further, we refer to a Label Switching 199 Router (LSR), for a given LSP, and to a PW Switching Provider Edge 200 (S-PE), for a given PW, as an Intermediate Point. This document does 201 not make a distinction between End Points (e.g., source and 202 destination) as it can be inferred from the context of the sentences. 204 In this document we use the term "node" as a general reference to End 205 Points and Intermediate Points. 207 In this document we refer to both segment and concatenated segments 208 as segments (see [1] for definitions relating to the term "segment" 209 as well as for other definitions relating to MPLS-TP). 211 In this document we refer to both single segment PWs and multi- 212 segment PWs as PWs. 214 In this document we refer to both bidirectional associated LSPs and 215 bidirectional co-routed LSPs as bidirectional LSPs. 217 2. OAM Requirements 219 This section lists the requirements by which the OAM functionality of 220 MPLS-TP should abide. 222 The requirements listed below may be met by one or more OAM 223 protocols; the definition or selection of these protocols is outside 224 the scope of this document. 226 RFC5654 [1] states (Requirement #2) that the MPLS-TP design SHOULD as 227 far as reasonably possible reuse existing MPLS standards. This 228 general requirement applies to MPLS-TP OAM. MPLS-TP OAM is defined 229 in this document through a set of functional requirements. These 230 requirements will be met by protocol solutions defined in other 231 documents. The way in which those protocols are operated and the way 232 in which a network operator can control and use the MPLS-TP OAM 233 functions SHOULD be as similar as possible to the mechanisms and 234 techniques used to operate OAM in other transport technologies. 236 2.1. Architectural Requirements 238 2.1.1. Scope of OAM 240 The protocol solution(s) developed to meet the requirements 241 identified in this document MUST at least be applicable to point-to- 242 point bidirectional PWs, point-to-point co-routed bidirectional LSPs, 243 and point-to-point bidirectional Sections. Section 2.2 provides 244 additional information with regards to the applicability to point-to- 245 point associated bidirectional LSPs, point-to-point unidirectional 246 LSPs and point-to-multipoint LSPs. 248 The service emulated by a PW may span multiple domains. An LSP may 249 also span multiple domains. The protocol solution(s) MUST be 250 applicable end-to-end and to segments. More generally, it MUST be 251 possible to operate OAM functions on a per domain basis and across 252 multiple domains. 254 Since LSPs may be stacked, the protocol solution(s) MUST be 255 applicable on any LSP, regardless of the label stack depth. 256 Furthermore it MUST be possible to estimate OAM fault and performance 257 metrics of a single PW or LSP segment or of an aggregate of PWs or 258 LSPs segments. 260 2.1.2. Independence 262 The protocol solution(s) SHOULD be independent of the underlying 263 tunnelling or point-to-point technology or transmission media. 265 The protocol solution(s) SHOULD be independent of the service a PW 266 may emulate. 268 Any OAM function operated on a PW, LSP or Section SHOULD be 269 independent of the OAM function(s) operated on a different PW, LSP or 270 Section. In other words, only the OAM functions operated on e.g., a 271 given LSP should be used to achieve the OAM objectives for that LSP. 273 The protocol solution(s) MUST support the capability to be 274 concurrently and independently operated end-to-end and on segments. 275 Therefore, any OAM function applied to segment(s) of a PW or LSP 276 SHOULD be independent of the OAM function(s) operated on the end-to- 277 end PW or LSP. It SHOULD also be possible to distinguish an OAM 278 packet running over a segment of a PW or LSP from another OAM packet 279 running on the end-to-end PW or LSP. 281 Furthermore, any OAM function applied to segment(s) of a PW or LSP 282 SHOULD be independent of the OAM function(s) applied to other 283 segment(s) of the same PW or LSP. 285 Note: Independence should not be understood in terms of isolation as 286 there can be interactions between OAM functions operated on e.g., 287 an LSP, and on another LSP or a PW. 289 2.1.3. Data Plane 291 OAM functions operate in the data plane. OAM packets MUST run in- 292 band; that is, OAM packets for a specific PW, LSP or Section MUST 293 follow the exact same data path as user traffic of that PW, LSP or 294 Section. This is often referred to as fate sharing. 296 It MUST be possible to discriminate user traffic from OAM packets. 297 This includes a means to differentiate OAM packets from user traffic 298 as well as the capability to apply specific treatment to OAM packets, 299 at the nodes processing these OAM packets. 301 As part of the design of OAM protocol solution(s) for MPLS-TP, a 302 mechanism, for enabling the encapsulation and differentiation of OAM 303 messages on a PW, LSP or Section, MUST be provided. Such mechanism 304 SHOULD also support the encapsulation and differentiation of existing 305 IP/MPLS and PW OAM messages. 307 2.1.4. OAM and IP Capabilities 309 There are environments where IP capabilities are present in the data 310 plane. IP/MPLS environments are examples of such environments. 311 There are also environments where IP capabilities may not be present 312 in the data plane. MPLS-TP environments are examples of environments 313 where IP capabilities might or might not be present. 314 Presence or absence of IP capabilities is deployment scenario 315 dependent. 317 It MUST be possible to deploy the OAM functionality in any of these 318 environments. As a result, it MUST be possible to operate OAM 319 functions with or without relying on IP capabilities and it MUST be 320 possible to choose to make use of IP capabilities when these are 321 present. 323 Furthermore, the mechanism required for enabling the encapsulation 324 and differentiation of OAM messages (see Section 2.1.3) MUST support 325 the capability to differentiate OAM messages of an OAM function 326 operated by relying on IP capabilities (e.g., using encapsulation in 327 an IP header) from OAM messages of an OAM function operated without 328 relying on any IP capability. 330 Note that IP capabilities include the capability to form a standard 331 IP header, to encapsulate a payload in an IP header, to parse and 332 analyse the fields of an IP header and to take actions based on the 333 content of these fields. 335 For certain functions, OAM messages need to incorporate 336 identification information (e.g., of source and/or destination 337 nodes). The protocol solution(s) MUST at least support 338 identification information in the form of an IP addressing structure 339 and MUST also be extensible to support additional identification 340 schemes. 342 2.1.5. Interoperability and Interworking 344 It is REQUIRED that OAM interoperability is achieved between distinct 345 domains materializing the environments described in Section 2.1.4. 346 It is also REQUIRED that the first two requirements of Section 2.1.4 347 still hold and MUST still be met when interoperability is achieved. 349 When MPLS-TP is run with IP routing and forwarding capabilities, it 350 MUST be possible to operate any of the existing IP/MPLS and PW OAM 351 protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [5] and VCCV-BFD 352 [14]). 354 2.1.6. Configuration 356 OAM functions MUST operate and be configurable even in the absence of 357 a control plane. Conversely, it SHOULD be possible to configure as 358 well as enable/disable the capability to operate OAM functions as 359 part of connectivity management and it SHOULD also be possible to 360 configure as well as enable/disable the capability to operate OAM 361 functions after connectivity has been established. 363 In the latter case, the customer MUST NOT perceive service 364 degradation as a result of OAM enabling/disabling. Ideally OAM 365 enabling/disabling should take place without introducing any customer 366 impairments (e.g., no customer packet losses). Procedures aimed to 367 prevent any traffic impairment MUST be defined for the enabling/ 368 disabling of OAM functions. 370 Means for configuring OAM functions and for connectivity management 371 are outside the scope of this document. 373 2.2. Functional Requirements 375 Hereafter are listed the required functionalities composing the 376 MPLS-TP OAM toolset. The list may not be exhaustive and as such the 377 OAM mechanisms developed in support of the identified requirements 378 SHALL be extensible and thus SHALL NOT preclude the definition of 379 additional OAM functionalities, in the future. 381 The design of OAM mechanisms for MPLS-TP, MUST allow for the ability 382 to support experimental OAM functions. These functions MUST be 383 disabled by default. 385 The use of any OAM function MUST be optional and it MUST be possible 386 to select the set of OAM function(s) to use on any PW, LSP or 387 Section. 389 It is RECOMMENDED that any protocol solution, meeting one or more 390 functional requirement(s), be the same for PWs, LSPs and Sections. 392 It is RECOMMENDED that any protocol solution, meeting one or more 393 functional requirement(s), effectively provides a fully featured 394 function; that is, a function which is applicable to all the cases 395 identified for that functionality. In that context, protocol 396 solution(s) MUST state their applicability. 398 Unless otherwise stated, the OAM functionalities MUST NOT rely on 399 user traffic; that is, only OAM messages MUST be used to achieve the 400 objectives. 402 For the on-demand OAM functions, the result of which may vary 403 depending on packet size, it SHOULD be possible to perform these 404 functions using different packet sizes. 406 2.2.1. General Requirements 408 If a defect or fault occurs on a PW, LSP or Section, mechanisms MUST 409 be provided to detect it, diagnose it, localize it, and notify the 410 appropriate nodes. Mechanisms SHOULD exist such that corrective 411 actions can be taken. 413 Furthermore, mechanisms MUST be available for a service provider to 414 be aware of a fault or defect affecting the service(s) he provides, 415 even if the fault or defect is located outside of his domain. 417 Protocol solution(s) developed to meet these requirements may rely on 418 information exchange. Information exchange between various nodes 419 involved in the operation of an OAM function SHOULD be reliable such 420 that, for example, defects or faults are properly detected or that 421 state changes are effectively known by the appropriate nodes. 423 2.2.2. Continuity Checks 425 The MPLS-TP OAM toolset MUST provide a function to enable an End 426 Point to monitor the liveness of a PW, LSP or Section. 428 This function SHOULD be performed between End Points of PWs, LSPs and 429 Sections. 431 This function SHOULD be performed pro-actively. 433 The protocol solution(s) developed to perform this function MUST also 434 apply to point-to-point associated bidirectional LSPs, point-to-point 435 unidirectional LSPs and point-to-multipoint LSPs. 437 2.2.3. Connectivity Verifications 439 The MPLS-TP OAM toolset MUST provide a function to enable an End 440 Point to determine whether or not it is connected to specific End 441 Point(s) by means of the expected PW, LSP or Section. 443 This function SHOULD be performed pro-actively between End Points of 444 PWs, LSPs and Sections. 446 This function SHOULD be performed on-demand between End Points and 447 Intermediate Points of PWs and LSPs, and between End Points of PWs, 448 LSPs and Sections. 450 The protocol solution(s) developed to perform this function pro- 451 actively MUST also apply to point-to-point associated bidirectional 452 LSPs, point-to-point unidirectional LSPs and point-to-multipoint 453 LSPs. 455 The protocol solution(s) developed to perform this function on-demand 456 MAY also apply to point-to-point associated bidirectional LSPs, to 457 point-to-point unidirectional LSPs and point-to-multipoint LSPs in 458 case a return path exists. 460 2.2.4. Route Tracing 462 The MPLS-TP OAM toolset MUST provide functionality to enable an End 463 Point to discover the Intermediate (if any) and End Point(s) along a 464 PW, LSP or Section, and more generally to trace the route of a PW, 465 LSP or Section. The information collected MUST include identifiers 466 related to the nodes and interfaces composing that route. 468 This function SHOULD be performed on-demand. 470 This function SHOULD be performed between End Points and Intermediate 471 Points of PWs and LSPs, and between End Points of PWs, LSPs and 472 Sections. 474 The protocol solution(s) developed to perform this function MAY also 475 apply to point-to-point associated bidirectional LSPs, to point-to- 476 point unidirectional LSPs and point-to-multipoint LSPs in case a 477 return path exists. 479 2.2.5. Diagnostic Tests 481 The MPLS-TP OAM toolset MUST provide a function to enable conducting 482 diagnostic tests on a PW, LSP or Section. An example of such 483 diagnostic test consists of performing a loop-back function at a node 484 such that all OAM and data traffic are looped back to the originating 485 End Point. Another example of such diagnostic test consists in 486 estimating the bandwidth of e.g., an LSP. 488 This function SHOULD be performed on-demand. 490 This function SHOULD be performed between End Points and Intermediate 491 Points of PWs and LSPs, and between End Points of PWs, LSPs and 492 Sections. 494 The protocol solution(s) developed to perform this function MAY also 495 apply to point-to-point associated bidirectional LSPs, to point-to- 496 point unidirectional LSPs and point-to-multipoint LSPs in case a 497 return path exists. 499 2.2.6. Lock Instruct 501 The MPLS-TP OAM toolset MUST provide functionality to enable an End 502 Point of a PW, LSP or Section to instruct its associated End Point(s) 503 to lock the PW, LSP or Section. Note that lock corresponds to an 504 administrative status in which it is expected that only test traffic, 505 if any, and OAM (dedicated to the PW, LSP or Section) can be mapped 506 on that PW, LSP or Section. 508 This function SHOULD be performed on-demand. 510 This function SHOULD be performed between End Points of PWs, LSPs and 511 Sections. 513 The protocol solution(s) developed to perform this function MUST also 514 apply to point-to-point associated bidirectional LSPs, point-to-point 515 unidirectional LSPs and point-to-multipoint LSPs. 517 2.2.7. Lock Reporting 519 Based on the tunnelling capabilities of MPLS, there are cases where 520 Intermediate Point(s) of a PW or of an LSP coincide with End Point(s) 521 of another LSP on which the former is mapped/tunnelled. Further, it 522 may happen that the tunnel LSP be out of service as a result of a 523 lock action on that tunnel LSP. By means outside of the scope of 524 this document, the Intermediate Point(s) of the PW or LSP may be 525 aware of this condition. The MPLS-TP OAM toolset MUST provide a 526 function to enable an Intermediate Point of a PW or LSP to report, to 527 an End Point of that same PW or LSP, a lock condition indirectly 528 affecting that PW or LSP. 530 This function SHOULD be performed pro-actively. 532 This function SHOULD be performed between Intermediate Points and End 533 Points of PWs and LSPs. 535 The protocol solution(s) developed to perform this function MUST also 536 apply to point-to-point associated bidirectional LSPs, point-to-point 537 unidirectional LSPs and point-to-multipoint LSPs. 539 2.2.8. Alarm Reporting 541 Based on the tunnelling capabilities of MPLS, there are cases where 542 Intermediate Point(s) of a PW or of an LSP coincide with End Point(s) 543 of another LSP on which the former is mapped/tunnelled. Further, it 544 may happen that the tunnel LSP be out of service as a result of a 545 fault on that tunnel LSP. By means outside of the scope of this 546 document, the Intermediate Point(s) of the PW or LSP may be aware of 547 this condition. The MPLS-TP OAM toolset MUST provide functionality 548 to enable an Intermediate Point of a PW or LSP to report, to an End 549 Point of that same PW or LSP, a fault or defect condition indirectly 550 affecting that PW or LSP. 552 This function SHOULD be performed pro-actively. 554 This function SHOULD be performed between Intermediate Points and End 555 Points of PWs and LSPs. 557 The protocol solution(s) developed to perform this function MUST also 558 apply to point-to-point associated bidirectional LSPs, point-to-point 559 unidirectional LSPs and point-to-multipoint LSPs. 561 2.2.9. Remote Defect Indication 563 The MPLS-TP OAM toolset MUST provide a function to enable an End 564 Point to report, to its associated End Point, a fault or defect 565 condition that it detects on a PW, LSP or Section for which they are 566 the End Points. 568 This function SHOULD be performed pro-actively. 570 This function SHOULD be performed between End Points of PWs, LSPs and 571 Sections. 573 The protocol solution(s) developed to perform this function MUST also 574 apply to point-to-point associated bidirectional LSPs and MAY also 575 apply to point-to-point unidirectional LSPs and point-to-multipoint 576 LSPs in case a return path exists. 578 2.2.10. Client Failure Indication 580 The MPLS-TP OAM toolset MUST provide a function to enable the 581 propagation, from edge to edge of an MPLS-TP network, of information 582 pertaining to a client (i.e., external to the MPLS-TP network) defect 583 or fault condition detected at an End Point of a PW or LSP, if the 584 client layer OAM functionality does not provide an alarm 585 notification/propagation functionality. 587 This function SHOULD be performed pro-actively. 589 This function SHOULD be performed between End Points of PWs and LSPs. 591 The protocol solution(s) developed to perform this function MUST also 592 apply to point-to-point associated bidirectional LSPs, point-to-point 593 unidirectional LSPs and point-to-multipoint LSPs. 595 2.2.11. Packet Loss Measurement 597 The MPLS-TP OAM toolset MUST provide a function to enable the 598 quantification of packet loss ratio over a PW, LSP or Section. 600 The loss of a packet is defined in RFC2680 [6] (see section 2.4). 601 This definition is used here. 603 Packet loss ratio is defined here to be the ratio of the number of 604 user packets lost to the total number of user packets sent during a 605 defined time interval. 607 This function MAY either be performed pro-actively or on-demand. 609 This function SHOULD be performed between End Points of PWs, LSPs and 610 Sections. 612 It SHOULD be possible to rely on user traffic to perform that 613 functionality. 615 The protocol solution(s) developed to perform this function MUST also 616 apply to point-to-point associated bidirectional LSPs, point-to-point 617 unidirectional LSPs and point-to-multipoint LSPs. 619 2.2.12. Packet Delay Measurement 621 The MPLS-TP OAM toolset MUST provide a function to enable the 622 quantification of the one-way, and if appropriate, the two-way, delay 623 of a PW, LSP or Section. 625 o The one-way delay is defined in [7] to be the time elapsed from 626 the start of transmission of the first bit of a packet by an End 627 Point until the reception of the last bit of that packet by the 628 other End Point. 630 o The two-way delay is defined in [8] to be the time elapsed from 631 the start of transmission of the first bit of a packet by an End 632 Point until the reception of the last bit of that packet by the 633 same End Point. 635 Two-way delay may be quantified using data traffic loopback at the 636 remote End Point of the PW, LSP or Section (see Section 2.2.5). 638 Accurate quantification of one-way delay may require clock 639 synchronization, the means for which are outside the scope of this 640 document. 642 This function SHOULD be performed on-demand and MAY be performed pro- 643 actively. 645 This function SHOULD be performed between End Points of PWs, LSPs and 646 Sections. 648 The protocol solution(s) developed to perform this function MUST also 649 apply to point-to-point associated bidirectional LSPs, point-to-point 650 unidirectional LSPs and point-to-multipoint LSPs but only to enable 651 the quantification of the one-way delay. 653 3. Congestion Considerations 655 A mechanism (e.g., rate limiting) MUST be provided to prevent OAM 656 packets from causing congestion in the Packet Switched Network. 658 4. Security Considerations 660 This document, in itself, does not imply any security consideration 661 but OAM, as such, is subject to several security considerations. OAM 662 messages can reveal sensitive information such as passwords, 663 performance data and details about e.g., the network topology. 665 The nature of OAM therefore suggests having some form of 666 authentication, authorization and encryption in place. This will 667 prevent unauthorized access to MPLS-TP equipment and it will prevent 668 third parties from learning about sensitive information about the 669 transport network. 671 OAM systems (network management stations) SHOULD be designed such 672 that OAM functions cannot be accessed without authorization. 674 OAM protocol solutions MUST include the facility for OAM messages to 675 authenticated to prove their origin and to make sure that they are 676 destined for the receiving node. The use of such facilities MUST be 677 configurable. 679 An OAM packet received over a PW, LSP or Section MUST NOT be 680 forwarded beyond the End Point of that PW, LSP or Section, so as to 681 avoid that the OAM packet leaves the current administrative domain. 683 5. IANA Considerations 685 There are no IANA actions required by this draft. 687 6. Acknowledgements 689 The editors gratefully acknowledge the contributions of Matthew 690 Bocci, Italo Busi, Thomas Dietz, Annamaria Fulignoli, Huub van 691 Helvoort, Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, Marc 692 Lasserre, Lieven Levrau, Han Li, Julien Meuric, Philippe Niger, 693 Benjamin Niven-Jenkins, Jing Ruiquan, Nurit Sprecher, Yuji Tochio, 694 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 Packet 724 Loss Metric for IPPM", RFC 2680, September 1999. 726 [7] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay 727 Metric for IPPM", RFC 2679, September 1999. 729 [8] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay 730 Metric for IPPM", RFC 2681, September 1999. 732 7.2. Informative References 734 [9] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A 735 Framework for MPLS in Transport Networks", 736 draft-ietf-mpls-tp-framework-10 (work in progress), 737 February 2010. 739 [10] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on 740 transport requirements for T-MPLS OAM and considerations for 741 the application of IETF MPLS technology", 2008. 743 [11] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. 744 Matsushima, "Operations and Management (OAM) Requirements for 745 Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, 746 February 2006. 748 [12] Allan, D., Busi, I., and B. Niven-Jenkins, "MPLS-TP OAM 749 Framework", draft-ietf-mpls-tp-oam-framework-04 (work in 750 progress), December 2009. 752 [13] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD 753 For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress), 754 June 2008. 756 [14] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 757 Detection (BFD) for the Pseudowire Virtual Circuit Connectivity 758 Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-07 (work in 759 progress), July 2009. 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 M. C. Betts Consulting Ltd. 779 Email: malcolm.betts@rogers.com