idnits 2.17.1 draft-ietf-mpls-tp-oam-requirements-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (August 31, 2009) is 5352 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. '2' ** Obsolete normative reference: RFC 4379 (ref. '3') (Obsoleted by RFC 8029) == Outdated reference: A later version (-12) exists of draft-ietf-mpls-tp-framework-03 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-tp-oam-framework-01 Summary: 2 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: March 4, 2010 Cisco Systems, Inc. 6 M. Betts, Ed. 7 Huawei 8 August 31, 2009 10 Requirements for OAM in MPLS Transport Networks 11 draft-ietf-mpls-tp-oam-requirements-03 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 4, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document lists architectural and functional requirements for the 50 Operations, Administration and Maintenance of MPLS Transport Profile. 51 These requirements apply to pseudowires, Label Switched Paths, and 52 Sections. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 3 58 1.2. Requirements Language and Terminology . . . . . . . . . . 4 59 2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Architectural Requirements . . . . . . . . . . . . . . . . 5 61 2.1.1. Scope of OAM . . . . . . . . . . . . . . . . . . . . . 5 62 2.1.2. Independence . . . . . . . . . . . . . . . . . . . . . 6 63 2.1.3. OAM and IP Capabilities . . . . . . . . . . . . . . . 6 64 2.1.4. Interoperability and Interworking . . . . . . . . . . 7 65 2.1.5. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7 66 2.1.6. Configuration . . . . . . . . . . . . . . . . . . . . 7 67 2.2. Functional Requirements . . . . . . . . . . . . . . . . . 8 68 2.2.1. General Requirements . . . . . . . . . . . . . . . . . 8 69 2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 9 70 2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 9 71 2.2.4. Diagnostic Tests . . . . . . . . . . . . . . . . . . . 9 72 2.2.5. Route Tracing . . . . . . . . . . . . . . . . . . . . 10 73 2.2.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . 10 74 2.2.7. Lock Reporting . . . . . . . . . . . . . . . . . . . . 11 75 2.2.8. Alarm Reporting . . . . . . . . . . . . . . . . . . . 11 76 2.2.9. Remote Defect Indication . . . . . . . . . . . . . . . 12 77 2.2.10. Client Failure Indication . . . . . . . . . . . . . . 12 78 2.2.11. Packet Loss Measurement . . . . . . . . . . . . . . . 12 79 2.2.12. Packet Delay Measurement . . . . . . . . . . . . . . . 13 80 3. Congestion Considerations . . . . . . . . . . . . . . . . . . 13 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 86 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 In the context of MPLS Transport Profile (MPLS-TP, see [5] and [6]), 92 the rationales for Operations, Administration and Maintenance (OAM) 93 are twofold as it can serve: 95 o as a network-oriented functionality, used by a transport network 96 operator to monitor his network infrastructure and to implement 97 internal mechanisms in order to enhance the general behaviour and 98 the level of performance of his network (e.g., protection 99 mechanism in case of node or link failure). As an example, fault 100 localization is typically associated with this use case. 102 o as a service-oriented functionality, used by a transport service 103 provider to monitor services offered to end customers in order to 104 be able to react rapidly in case of a problem and to be able to 105 verify some of the Service Level Agreements (SLAs) parameters 106 (e.g., using performance monitoring) negotiated with the end 107 customers. Note that a transport service could be provided over 108 several networks or administrative domains that may not all be 109 owned and managed by the same transport service provider. 111 More generally, OAM is an important and fundamental functionality in 112 transport networks as it contributes to: 114 o the reduction of operational complexity and costs, by allowing for 115 efficient and automatic detection, localisation, handling and 116 diagnosis of defects, as well as by minimizing service 117 interruptions and operational repair times. 119 o the enhancement of network availability, by ensuring that defects, 120 for example resulting in misdirected customer traffic, and faults, 121 are detected, diagnosed and dealt with before a customer reports 122 the problem. 124 o meeting service and performance objectives, as the OAM 125 functionality allows for SLA verification in a multi-maintenance 126 domain environment and allows for the determination of service 127 degradation due, for example, to packet delay or packet loss. 129 1.1. Scope of this Document 131 This document lists architectural and functional requirements for the 132 OAM functionality of MPLS-TP. These requirements apply to 133 pseudowires (PWs), Label Switched Paths (LSPs) and Sections. 135 These requirements are derived from the set of requirements specified 136 by ITU-T and published in the ITU-T Supplement Y.Sup4 [7]. 138 By covering transport specificities, these requirements complement 139 those identified in RFC 4377 [8], yet some requirements may be 140 similar. 142 This document only lists architectural and functional OAM 143 requirements. It does not detail the implications of their 144 applicability to the various types (e.g., point-to-point, point-to- 145 multipoint, unidirectional, bidirectional ...) of PWs, LSPs and 146 Sections. Furthermore, this document does not provide requirements 147 on how the protocol solution(s) should behave to achieve the 148 functional objectives. Please see [9] for further information. 150 Note that the OAM functions identified in this document may be used 151 for fault management, performance monitoring and/or protection 152 switching applications. For example, connectivity verification can 153 be used for fault management by detecting failure conditions, but may 154 also be used for performance monitoring through its contribution to 155 the evaluation of performance metrics (e.g., unavailability time). 156 Nevertheless, it is outside the scope of this document to specify 157 which function should be used for which application. 159 1.2. Requirements Language and Terminology 161 Although this document is not a protocol specification, the key words 162 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 163 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be 164 interpreted as described in RFC 2119 [1] and are to be interpreted as 165 instructions to the protocol designers producing solutions that 166 satisfy the requirements set out in this document. 168 In this document we refer to the inability of a function to perform a 169 required action, as a fault. This does not include an inability due 170 to preventive maintenance, lack of external resources, or planned 171 actions. See also ITU-T G.806 [2]. 173 In this document we refer to the situation in which the density of 174 anomalies has reached a level where the ability to perform a required 175 function has been interrupted, as a defect. See also ITU-T G.806 176 [2]. 178 In this document we refer to a Label Edge Router (LER), for a given 179 LSP or Section, and to a PW Terminating Provider Edge (T-PE), for a 180 given PW, as an End Point. Further, we refer to a Label Switching 181 Router (LSR), for a given LSP, and to a PW Switching Provider Edge 182 (S-PE), for a given PW, as an Intermediate Point. This document does 183 not make a distinction between End Points (e.g., source and 184 destination) as it can be inferred from the context of the sentences. 186 In this document we use the term "node" as a general reference to End 187 Points and Intermediate Points. 189 In this document we refer to both segment and concatenated segments 190 as segments (see [6] for definitions relating to the term "segment" 191 as well as for other definitions relating to MPLS-TP). 193 In this document we refer to both single segment PWs and multi- 194 segment PWs as PWs. 196 In this document we refer to both bidirectional associated LSPs and 197 bidirectional co-routed LSPs as bidirectional LSPs. 199 2. OAM Requirements 201 This section lists the requirements by which the OAM functionality of 202 MPLS-TP should abide. 204 The requirements listed below may be met by one or more OAM 205 protocols; the definition or selection of these protocols is outside 206 the scope of this document. 208 2.1. Architectural Requirements 210 2.1.1. Scope of OAM 212 The protocol solution(s) developed to meet the requirements 213 identified in this document MUST at least be applicable to point-to- 214 point bidirectional PWs, point-to-point co-routed bidirectional LSPs, 215 and point-to-point bidirectional Sections. Section 2.2 provides 216 additional information with regards to the applicability to point-to- 217 point associated bidirectional LSPs, point-to-point undirectional 218 LSPs and point-to-multipoint LSPs. 220 The service emulated by a PW may span multiple domains. An LSP may 221 also span multiple domains. The protocol solution(s) MUST be 222 applicable end-to-end and to segments. More generally, it MUST be 223 possible to operate OAM functions on a per domain basis and across 224 multiple domains. 226 Since LSPs may be stacked, the protocol solution(s) MUST be 227 applicable on any LSP, regardless of the label stack depth. 228 Furthermore it MUST be possible to estimate OAM fault and performance 229 metrics of a single PW or LSP segment or of an aggregate of PWs or 230 LSPs segments. 232 2.1.2. Independence 234 The protocol solution(s) SHOULD be independent of the underlying 235 tunnelling or point-to-point technology or transmission media. 237 The protocol solution(s) SHOULD be independent of the service a PW 238 may emulate. 240 Any OAM function operated on a PW, LSP or Section SHOULD be 241 independent of the OAM function(s) operated on a different PW, LSP or 242 Section. In other words, only the OAM functions operated on e.g., a 243 given LSP should be used to achieve the OAM objectives for that LSP. 245 The protocol solution(s) MUST support the capability to be 246 concurrently and independently operated end-to-end and on segments. 247 Therefore, any OAM function applied to segment(s) of a PW or LSP 248 SHOULD be independent of the OAM function(s) operated on the end-to- 249 end PW or LSP. It SHOULD also be possible to distinguish an OAM 250 packet running over a segment of a PW or LSP from another OAM packet 251 running on the end-to-end PW or LSP. 253 Furthermore, any OAM function applied to segment(s) of a PW or LSP 254 SHOULD be independent of the OAM function(s) applied to other 255 segment(s) of the same PW or LSP. 257 Note: Independence should not be understood in terms of isolation as 258 there can be interactions between OAM functions operated on e.g., 259 an LSP, and on another LSP or a PW. 261 2.1.3. OAM and IP Capabilities 263 The OAM functionality may be deployed in various environments. 265 o In some environments (e.g., IP/MPLS environments), IP routing and 266 forwarding capabilities are inherently present in the data plane. 268 o In some environments (e.g., MPLS-TP environments), IP routing and 269 forwarding capabilities may not necessarily be present in the data 270 plane. 272 In the former case, it MUST be possible to operate the OAM functions 273 by relying on IP routing and forwarding capabilities (e.g., 274 encapsulation in IP header for (de)multiplexing purposes) while in 275 the latter case it MUST be possible to operate the OAM functions 276 without relying on IP routing and forwarding capabilities. 278 For certain functions, OAM messages need to incorporate 279 identification information (e.g., of source and/or destination 280 nodes). The protocol solution(s) MUST at least support 281 identification information in the form of an IP addressing structure 282 and MUST also be extensible to support additional identification 283 schemes. 285 2.1.4. Interoperability and Interworking 287 It is REQUIRED that OAM interoperability is achieved between distinct 288 domains materializing the environments described in Section 2.1.3. 289 It is also REQUIRED that the first two requirements of Section 2.1.3 290 still hold and MUST still be met when interoperability is achieved. 292 When MPLS-TP is run with IP routing and forwarding capabilities, it 293 MUST be possible to operate any of the existing IP/MPLS and PW OAM 294 protocols (e.g., LSP-Ping [3], MPLS-BFD [10], VCCV [4] and VCCV-BFD 295 [11]). 297 2.1.5. Data Plane 299 OAM functions operate in the data plane. OAM packets MUST run in- 300 band; that is, OAM packets for a specific PW, LSP or Section MUST 301 follow the exact same data path as user traffic of that PW, LSP or 302 Section. This is often referred to as fate sharing. 304 It MUST be possible to discriminate user traffic from OAM packets. 305 This includes a means to differentiate OAM packets from user traffic 306 as well as the capability to apply specific treatment to OAM packets, 307 at the nodes processing these OAM packets. 309 As part of the design of OAM protocol solution(s) for MPLS-TP, a 310 mechanism, for enabling the encapsulation and differentiation of OAM 311 messages on a PW, LSP or Section, MUST be provided. Such mechanism 312 SHOULD also support the encapsulation and differentiation of existing 313 IP/MPLS and PW OAM messages. 315 2.1.6. Configuration 317 OAM functions MUST operate and be configurable even in the absence of 318 a control plane. Conversely, it SHOULD be possible to configure as 319 well as enable/disable the capability to operate OAM functions as 320 part of connectivity management and it SHOULD also be possible to 321 configure as well as enable/disable the capability to operate OAM 322 functions after connectivity has been established. 324 In the latter case, the customer MUST NOT perceive service 325 degradation as a result of OAM enabling/disabling. Ideally OAM 326 enabling/disabling should take place without introducing any customer 327 impairments (e.g., no customer packet losses). Procedures aimed to 328 prevent any traffic impairment MUST be defined for the enabling/ 329 disabling of OAM functions. 331 Means for configuring OAM functions and for connectivity management 332 are outside the scope of this document. 334 2.2. Functional Requirements 336 Hereafter are listed the required functionalities composing the 337 MPLS-TP OAM toolset. The list may not be exhaustive and as such the 338 OAM mechanisms developed in support of the identified requirements 339 SHALL be extensible and thus SHALL NOT preclude the definition of 340 additional OAM functionalities, in the future. 342 The design of OAM mechanisms for MPLS-TP, MUST allow for the ability 343 to support experimental OAM functions. These functions MUST be 344 disabled by default. 346 The use of any OAM function MUST be optional and it MUST be possible 347 to select the set of OAM function(s) to use on any PW, LSP or 348 Section. 350 It is RECOMMENDED that any protocol solution, meeting one or more 351 functional requirement(s), be the same for PWs, LSPs and Sections. 353 It is RECOMMENDED that any protocol solution, meeting one or more 354 functional requirement(s), effectively provides a fully featured 355 function; that is, a function which is applicable to all the cases 356 identified for that functionality. In that context, protocol 357 solution(s) MUST state their applicability. 359 Unless otherwise stated, the OAM functionalities MUST NOT rely on 360 user traffic; that is, only OAM messages MUST be used to achieve the 361 objectives. 363 2.2.1. General Requirements 365 If a defect or fault occurs on a PW, LSP or Section, mechanisms MUST 366 be provided to detect it, diagnose it, localize it, and notify the 367 appropriate nodes. Mechanisms SHOULD exist such that corrective 368 actions can be taken. 370 Furthermore, mechanisms MUST be available for a service provider to 371 be aware of a fault or defect affecting the service(s) he provides, 372 even if the fault or defect is located outside of his domain. 374 Protocol solution(s) developed to meet these requirements may rely on 375 information exchange. Information exchange between various nodes 376 involved in the operation of an OAM function SHOULD be reliable such 377 that, for example, defects or faults are properly detected or that 378 state changes are effectively known by the appropriate nodes. 380 2.2.2. Continuity Checks 382 The MPLS-TP OAM toolset MUST provide a function to enable an End 383 Point to determine whether or not it receives traffic on a PW, LSP or 384 Section. 386 This function SHOULD be performed between End Points of PWs, LSPs and 387 Sections. 389 This function SHOULD be performed pro-actively. 391 The protocol solution(s) developed to perform this function MUST also 392 apply to point-to-point associated bidirectional LSPs, point-to-point 393 unidirectional LSPs and point-to-multipoint LSPs. 395 2.2.3. Connectivity Verifications 397 The MPLS-TP OAM toolset MUST provide a function to enable an End 398 Point of a PW, LSP or Section to determine whether or not the 399 connectivity provided to an other node through a PW, LSP or Section 400 is effective (i.e., that a packet sent on that PW, LSP or Section, 401 reaches the expected node). 403 This function SHOULD be performed pro-actively between End Points of 404 PWs, LSPs and Sections. 406 This function SHOULD be performed on-demand between End Points and 407 Intermediate Points of PWs and LSPs, and between End Points of PWs, 408 LSPs and Sections. 410 The protocol solution(s) developed to perform this function pro- 411 actively MUST also apply to point-to-point associated bidirectional 412 LSPs, point-to-point unidirectional LSPs and point-to-multipoint 413 LSPs. 415 The protocol solution(s) developed to perform this function on-demand 416 MAY also apply to point-to-point associated bidirectional LSPs, to 417 point-to-point unidirectional LSPs and point-to-multipoint LSPs in 418 case a return path exists. 420 2.2.4. Diagnostic Tests 422 The MPLS-TP OAM toolset MUST provide a function to enable conducting 423 diagnostic tests on a PW, LSP or Section. An example of such 424 diagnostic test consists in looping the traffic at an Intermediate 425 Point back to the originating End Point. Another example of such 426 diagnostic test consists in estimating the bandwidth of e.g., an LSP. 428 This function SHOULD be performed on-demand. 430 This function SHOULD be performed between End Points and Intermediate 431 Points of PWs and LSPs, and between End Points of PWs, LSPs and 432 Sections. 434 The protocol solution(s) developed to perform this function MAY also 435 apply to point-to-point associated bidirectional LSPs, to point-to- 436 point unidirectional LSPs and point-to-multipoint LSPs in case a 437 return path exists. 439 2.2.5. Route Tracing 441 The MPLS-TP OAM toolset MUST provide functionality to enable an End 442 Point to discover the Intermediate (if any) and End Point(s) along a 443 PW, LSP or Section, and more generally to trace the route of a PW, 444 LSP or Section. The information collected MUST include identifiers 445 related to the nodes and interfaces composing that route. 447 This function SHOULD be performed on-demand. 449 This function SHOULD be performed between End Points and Intermediate 450 Points of PWs and LSPs, and between End Points of PWs, LSPs and 451 Sections. 453 The protocol solution(s) developed to perform this function MAY also 454 apply to point-to-point associated bidirectional LSPs, to point-to- 455 point unidirectional LSPs and point-to-multipoint LSPs in case a 456 return path exists. 458 2.2.6. Lock Instruct 460 The MPLS-TP OAM toolset MUST provide functionality to enable an End 461 Point of a PW, LSP or Section to instruct its associated End Point(s) 462 to lock the PW, LSP or Section. Note that lock corresponds to an 463 administrative status in which it is expected that only test traffic, 464 if any, and OAM (dedicated to the PW, LSP or Section) can be mapped 465 on that PW, LSP or Section. 467 This function SHOULD be performed on-demand. 469 This function SHOULD be performed between End Points of PWs, LSPs and 470 Sections. 472 The protocol solution(s) developed to perform this function MUST also 473 apply to point-to-point associated bidirectional LSPs, point-to-point 474 unidirectional LSPs and point-to-multipoint LSPs. 476 2.2.7. Lock Reporting 478 Based on the tunnelling capabilities of MPLS, there are cases where 479 Intermediate Point(s) of a PW or of an LSP coincide with End Point(s) 480 of another LSP on which the former is mapped/tunnelled. Further, it 481 may happen that the tunnel LSP be out of service as a result of a 482 lock action on that tunnel LSP. By means outside of the scope of 483 this document, the Intermediate Point(s) of the PW or LSP may be 484 aware of this condition. The MPLS-TP OAM toolset MUST provide a 485 function to enable an Intermediate Point of a PW or LSP to report, to 486 an End Point of that same PW or LSP, a lock condition indirectly 487 affecting that PW or LSP. 489 This function SHOULD be performed pro-actively. 491 This function SHOULD be performed between Intermediate Points and End 492 Points of PWs and LSPs. 494 The protocol solution(s) developed to perform this function MUST also 495 apply to point-to-point associated bidirectional LSPs, point-to-point 496 unidirectional LSPs and point-to-multipoint LSPs. 498 2.2.8. Alarm Reporting 500 Based on the tunnelling capabilities of MPLS, there are cases where 501 Intermediate Point(s) of a PW or of an LSP coincide with End Point(s) 502 of another LSP on which the former is mapped/tunnelled. Further, it 503 may happen that the tunnel LSP be out of service as a result of a 504 fault on that tunnel LSP. By means outside of the scope of this 505 document, the Intermediate Point(s) of the PW or LSP may be aware of 506 this condition. The MPLS-TP OAM toolset MUST provide functionality 507 to enable an Intermediate Point of a PW or LSP to report, to an End 508 Point of that same PW or LSP, a fault or defect condition indirectly 509 affecting that PW or LSP. 511 This function SHOULD be performed pro-actively. 513 This function SHOULD be performed between Intermediate Points and End 514 Points of PWs and LSPs. 516 The protocol solution(s) developed to perform this function MUST also 517 apply to point-to-point associated bidirectional LSPs, point-to-point 518 unidirectional LSPs and point-to-multipoint LSPs. 520 2.2.9. Remote Defect Indication 522 The MPLS-TP OAM toolset MUST provide a function to enable an End 523 Point to report, to its associated End Point, a fault or defect 524 condition that it detects on a PW, LSP or Section for which they are 525 the End Points. 527 This function SHOULD be performed pro-actively. 529 This function SHOULD be performed between End Points of PWs, LSPs and 530 Sections. 532 The protocol solution(s) developed to perform this function MUST also 533 apply to point-to-point associated bidirectional LSPs and MAY also 534 apply to point-to-point unidirectional LSPs and point-to-multipoint 535 LSPs in case a return path exists. 537 2.2.10. Client Failure Indication 539 The MPLS-TP OAM toolset MUST provide a function to enable the 540 propagation, from edge to edge of an MPLS-TP network, of information 541 pertaining to a client (i.e., external to the MPLS-TP network) defect 542 or fault condition detected at an End Point of a PW or LSP, if the 543 client layer OAM functionality does not provide an alarm 544 notification/propagation functionality. 546 This function SHOULD be performed pro-actively. 548 This function SHOULD be performed between End Points of PWs and LSPs. 550 The protocol solution(s) developed to perform this function MUST also 551 apply to point-to-point associated bidirectional LSPs, point-to-point 552 unidirectional LSPs and point-to-multipoint LSPs. 554 2.2.11. Packet Loss Measurement 556 The MPLS-TP OAM toolset MUST provide a function to enable the 557 quantification of packet loss ratio over a PW, LSP or Section. 559 Note that packet loss ratio is the ratio of the user packets not 560 delivered to the total number of user packets transmitted during a 561 defined time interval. The number of user packets not delivered is 562 the difference between the number of user packets transmitted by an 563 End Point and the number of user packets received at an End Point. 565 This function MAY either be performed pro-actively or on-demand. 567 This function SHOULD be performed between End Points of PWs, LSPs and 568 Sections. 570 It SHOULD be possible to rely on user traffic to perform that 571 functionality. 573 The protocol solution(s) developed to perform this function MUST also 574 apply to point-to-point associated bidirectional LSPs, point-to-point 575 unidirectional LSPs and point-to-multipoint LSPs. 577 2.2.12. Packet Delay Measurement 579 The MPLS-TP OAM toolset MUST provide a function to enable the 580 quantification of the one-way, and if appropriate, the two-way, delay 581 of a PW, LSP or Section. 583 o One-way delay is the time elapsed from the start of transmission 584 of the first bit of a packet by an End Point until the reception 585 of the last bit of that packet by the other End Point. 587 o Two-way delay is the time elapsed from the start of transmission 588 of the first bit of a packet by a End Point until the reception of 589 the last bit of that packet by the same End Point, when loopback 590 is performed at the other End Point. 592 This function SHOULD be performed on-demand and MAY be performed pro- 593 actively. 595 This function SHOULD be performed between End Points of PWs, LSPs and 596 Sections. 598 The protocol solution(s) developed to perform this function MUST also 599 apply to point-to-point associated bidirectional LSPs, point-to-point 600 unidirectional LSPs and point-to-multipoint LSPs but only to enable 601 the quantification of the one-way delay. 603 3. Congestion Considerations 605 A mechanism (e.g., rate limiting) MUST be provided to prevent OAM 606 packets from causing congestion in the Packet Switched Network. 608 4. Security Considerations 610 This document, in itself, does not imply any security consideration 611 but OAM, as such, is subject to several security considerations. OAM 612 messages can reveal sensitive information such as passwords, 613 performance data and details about e.g., the network topology. 615 The nature of OAM therefore suggests having some form of 616 authentication, authorization and encryption in place. This will 617 prevent unauthorized access to MPLS-TP equipment and it will prevent 618 third parties from learning about sensitive information about the 619 transport network. 621 In general, mechanisms SHOULD be provided to ensure that OAM 622 functions cannot be accessed unauthorized. 624 Further, OAM messages MAY be authenticated to prove their origin and 625 to make sure that they are destined for the receiving node. 627 An OAM packet received over a PW, LSP or Section MUST NOT be 628 forwarded beyond the End Point of that PW, LSP or Section, so as to 629 avoid that the OAM packet leaves the current administrative domain. 631 5. IANA Considerations 633 There are no IANA actions required by this draft. 635 6. Acknowledgements 637 The editors gratefully acknowledge the contributions of Matthew 638 Bocci, Italo Busi, Thomas Dietz, Annamaria Fulignoli, Huub van 639 Helvoort, Wataru Imajuku, Marc Lasserre, Lieven Levrau, Han Li, 640 Julien Meuric, Philippe Niger, Benjamin Niven-Jenkins, Jing Ruiquan, 641 Nurit Sprecher, Yuji Tochio, Satoshi Ueno and Yaacov Weingarten. 643 The authors would like to thank all members of the teams (the Joint 644 Working Team, the MPLS Interoperability Design Team in IETF and the 645 MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and 646 specification of MPLS-TP. 648 7. References 650 7.1. Normative References 652 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 653 Levels", BCP 14, RFC 2119, March 1997. 655 [2] ITU-T Recommendation G.806, "Characteristics of transport 656 equipment - Description methodology and generic functionality", 657 2009. 659 [3] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label 660 Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 662 [4] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 663 Connectivity Verification (VCCV): A Control Channel for 664 Pseudowires", RFC 5085, December 2007. 666 7.2. Informative References 668 [5] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in 669 Transport Networks", draft-ietf-mpls-tp-framework-03 (work in 670 progress), August 2009. 672 [6] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and 673 S. Ueno, "MPLS-TP Requirements", 674 draft-ietf-mpls-tp-requirements-10 (work in progress), 675 August 2009. 677 [7] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on 678 transport requirements for T-MPLS OAM and considerations for 679 the application of IETF MPLS technology", 2008. 681 [8] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. 682 Matsushima, "Operations and Management (OAM) Requirements for 683 Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, 684 February 2006. 686 [9] Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM Framework and 687 Overview", draft-ietf-mpls-tp-oam-framework-01 (work in 688 progress), July 2009. 690 [10] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD 691 For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress), 692 June 2008. 694 [11] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 695 Detection (BFD) for the Pseudowire Virtual Circuit 696 Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-07 697 (work in progress), July 2009. 699 Authors' Addresses 701 Martin Vigoureux (editor) 702 Alcatel-Lucent 703 Route de Villejust 704 Nozay, 91620 705 France 707 Email: martin.vigoureux@alcatel-lucent.com 709 David Ward (editor) 710 Cisco Systems, Inc. 711 170 W. Tasman Dr. 712 San Jose, CA 95134 713 USA 715 Email: dward@cisco.com 717 Malcolm Betts (editor) 718 Huawei 720 Email: malcolm.betts@huawei.com