idnits 2.17.1 draft-vigoureux-mpls-tp-oam-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 811. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 817. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2008) is 5772 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group M. Vigoureux (Editor) 2 Internet Draft Alcatel-Lucent 3 Intended status: Informational 4 Expires: January 2009 D. Ward (Editor) 5 Cisco Systems, Inc. 7 M. Betts (Editor) 8 Nortel Networks 10 July 7, 2008 12 Requirements for OAM in MPLS Transport Networks 13 draft-vigoureux-mpls-tp-oam-requirements-00 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress". 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on January 7, 2009. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document specifies requirements for OAM (Operations and 46 Management) functionality in MPLS networks that are used for packet 47 transport services and network operations. The use of the term MPLS 48 in this document refers to both MPLS PSNs and pseudowire 49 technologies. 51 These requirements are derived from the set of requirements specified 52 by ITU-T and first published in the ITU-T Supplement Y.Sup4 [6]. 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119 [1]. 60 Table of Contents 62 1. Introduction...................................................3 63 1.1. Terminology...............................................3 64 1.2. Definitions...............................................4 65 1.3. Context and Motivations...................................5 66 1.3.1. Transport Profile of MPLS............................5 67 1.3.2. Motivations..........................................6 68 2. OAM Requirements...............................................7 69 2.1. Architectural Requirements................................8 70 2.2. Functional Requirements...................................9 71 2.3. Performance Requirements.................................12 72 3. Security Considerations.......................................12 73 4. Congestion Considerations.....................................12 74 5. IANA Considerations...........................................12 75 6. Acknowledgments...............................................13 76 APPENDIX A : OAM Functions Information.........................14 77 A.1. Continuity Check.........................................14 78 A.2. Connectivity Verification................................14 79 A.3. Alarm Suppression........................................14 80 A.4. Lock Indication..........................................15 81 A.5. Packet Loss Measurement..................................15 82 A.6. Diagnostic Test..........................................15 83 A.7. Trace-route..............................................15 84 A.8. Delay Measurement........................................16 85 A.9. Remote Defect Indication.................................16 86 A.10. Client Signal Fail......................................16 87 APPENDIX B : Mapping between RFC 4377, Y.Sup4 and this document17 88 7. References....................................................18 89 7.1. Normative References.....................................18 90 7.2. Informative References...................................18 91 Authors' Addresses...............................................18 92 Contributing Authors' Addresses..................................19 93 Intellectual Property Statement..................................20 94 Disclaimer of Validity...........................................21 96 1. Introduction 98 This document specifies requirements for OAM (Operations and 99 Management) functionality in MPLS networks that are used for packet 100 transport services and network operations. The use of the term MPLS 101 in this document refers to both MPLS PSNs and pseudowire 102 technologies. 104 These requirements may be met by one or more toolsets. The definition 105 or selection of these toolsets is outside the scope of this document. 107 1.1. Terminology 109 AC Attachment Circuit 111 CSF Client Signal Fail 113 FCAPS Fault, Configuration, Accounting, Performance, Security 115 LER Label Edge Router 117 LSP Label Switch Path 119 LSR Label Switching Router 121 ME Maintenance Entity 123 MEP Maintenance End Point 125 MIP Maintenance Intermediate Point 127 MP Maintenance Point 129 MS-PW Multi Segment Pseudowire 131 OAM Operations and Management 133 PE Provider Edge 135 PSN Packet Switched Network 136 PW Pseudowire 138 SLA Service Level Agreement 140 SS-PW Single Segment Pseudowire 142 S-PE Switching Provider Edge 144 T-PE Terminating Provider Edge 146 TCME Tandem Connection Maintenance Entity 148 1.2. Definitions 150 In this document we refer to a fault as the inability of a function 151 to perform a required action. This does not include an inability due 152 to preventive maintenance, lack of external resources, or planned 153 actions. See also ITU-T G.806 [3]. 155 In this document we refer to a defect to as the situation for which 156 density of anomalies has reached a level where the ability to perform 157 a required function has been interrupted. See also ITU-T G.806 [3]. 159 In this document, we refer to MPLS Transport Profile (MPLS-TP) as a 160 set of MPLS functions used to support packet transport services and 161 network operations. 163 In this document we refer to a MPLS Section as a network segment 164 between two LSRs that are immediately adjacent at the MPLS layer. 166 OAM packets can be inserted and extracted at various reference 167 points, referred to as Maintenance Points (MP). These MPs are further 168 characterized with regard to their position along the entity being 169 monitored. The MPs can be end-points (Maintenance End Point, MEP) or 170 intermediate points (Maintenance Intermediate Point, MIP). A MEP is 171 capable of initiating and terminating OAM packets for fault 172 management and performance monitoring. A MIP is capable of reacting 173 to some OAM packets but does not initiate OAM packets. Therefore, 174 LERs and T-PEs can be MEPs while LSRs and S-PEs can be MIPs. In case 175 of Tandem Connection Maintenance Entity (defined below), LSRs and S- 176 PEs can be MEPs. 178 This document defines the following Maintenance Entities: 180 o The PW Maintenance Entity, corresponding to end-to-end PW 181 monitoring (between T-PEs). 183 o The LSP Maintenance Entity, corresponding to end-to-end LSP 184 monitoring (between LERs). 186 o The Tandem Connection Maintenance Entity (TCME), corresponding to 187 one or more segment(s) of a PW or to a segment (a.k.a. sub-path) 188 of a LSP. 189 Note that: 190 - A TCME could be defined between the two T-PEs of a SS-PW but 191 there is no specific relevance to define such a TCME as it 192 corresponds to the PW Maintenance Entity. 193 - A TCME can be defined between a T-PE and any S-PE (and vice- 194 versa) or between any two S-PEs on a given MS-PW. A TCME can span 195 several PW segments, i.e. the PEs (T-PEs or S-PEs) where MEPs are 196 located need not be adjacent on the MS-PW. 197 - A TCME can be defined between a LER and any LSR (and vice-versa) 198 or between any two LSRs, for that LSP. These points (LERs, LSRs) 199 where MEPS are located do not need to be adjacent on the LSP. A 200 TCME defined between the two LERs of a LSP corresponds to the LSP 201 Maintenance Entity. 202 - The LSP or MS-PW segment(s) that the TCME covers may however be 203 dependant on administrative boundaries in case the LSP or the MS- 204 PW spans multiple domains. 205 - End-points of a TCME are MEPs, not MIPs. 207 A Maintenance Entity can be viewed as the association of two (or 208 more) Maintenance End Points that should be provisioned and managed. 209 Each OAM flow is associated to a unique ME. MEPs of a given ME 210 generate and/or terminate the OAM messages associated to the ME. 212 The monitoring of a Maintenance Entity can only be performed at 213 points where the Label associated with the Maintenance Entity is the 214 top most label of the stack. 216 TCMEs MAY be nested but MUST NOT overlap. 218 1.3. Context and Motivations 220 1.3.1. Transport Profile of MPLS 222 This section does not give any requirement on MPLS-TP. Its sole 223 intent is to describe the context in which the OAM requirements could 224 fit and is for information only. The authors intend to move it to 225 another draft at a later stage. 227 A transport network must provide a means to commit, to the client 228 signal, the quality of service and availability objectives. These 229 objectives can be expressed in the form of a Service Level Agreement 230 (SLA). A transport network must also provide a means to monitor 231 compliance to an agreed quality of service. 233 Two important attributes of MPLS-TP (as in any transport network 234 technology) are that 236 o it is independent from both client and server networks. That is, 237 demarcation points exist between MPLS-TP and the customer layer, 238 and between MPLS-TP and the underlying tunnelling or point-to- 239 point technology. 241 o it is consistent with existing transport network operations and 242 management models [8]. 244 The purpose of a transport network is to transparently carry client 245 signals (i.e. the stream of client PDUs or client bits), across the 246 network, between ingress and egress (typically over several nodes). A 247 key characteristic of transport networks is their ability to monitor 248 and therefore maintain the integrity of the client signal between 249 ingress and egress ports of the transport network. 251 Networks deploying MPLS-TP are configured so as not to use specific 252 MPLS capabilities such as ECMP, label merging (i.e. for mp2p 253 purposes) and PHP. In the case of bidirectional connectivity, the 254 forward and backward directions are congruent (i.e. they follow the 255 same path and the pairing relationship between the forward and the 256 backward directions is known in each node traversed by bidirectional 257 LSPs). 259 Just as for other transport technologies and associated transport 260 networks, the presence of a distributed control plane in support of 261 network operations is optional, and the absence of such control plane 262 should not affect the ability to operate the network and to use MPLS- 263 TP forwarding, OAM and protection capabilities. 265 Finally, some MPLS-TP specific recovery mechanisms are independent of 266 a control plane. They rely on OAM capabilities such as APS to trigger 267 protection switching in the absence of a control plane. 269 1.3.2. Motivations 271 In the context of MPLS Transport Profile the rationales for OAM 272 mechanisms are twofold as they can serve as: 274 o As a network-oriented mechanism (used by a transport network 275 operator) to monitor his network infrastructure and to implement 276 internal mechanisms in order to enhance the general behaviour and 277 the level of performances of his network (e.g. protection 278 mechanism in case of node or link failure). For example fault 279 localization is typically associated to this use case. 281 o As a service-oriented mechanism (used by a transport service 282 provider) to monitor his offered services to end customers it 283 order to be able to react rapidly in case of a problem and to be 284 able to verify some of the SLA parameters (i.e. performance 285 monitoring) negotiated with the end customer. A transport service 286 could be provided over several networks or administrative domains 287 that may not be all owned and managed by the transport service 288 provider. 290 More generally, OAM is an important and fundamental functionality in 291 transport networks as it contributes to 293 o the reduction of operational complexity and costs, by allowing 294 efficient and automatic detection, localisation, handling, and 295 diagnosis of defects, and by minimizing service interruptions, 296 operational repair times, and operational resources. 298 o the enhancement of network availability, by ensuring that defects 299 resulting in misdirected customer traffic are detected/diagnosed 300 and can lead to appropriate consequent actions minimizing the 301 number of defects that are not detected automatically before a 302 customer reports the problem. 304 o meet service and performance objectives, by running OAM 305 functionality which allows SLA verification in a multi-maintenance 306 domain environment and allows the determination of service 307 degradation due to, for example, packet delay or packet loss. 309 This is achieved through the support of FCAPS functionality, as 310 described in ITU-T M.3400 [2], itself relying on OAM related 311 information. 313 2. OAM Requirements 315 This section lists the requirements by which the OAM functionality of 316 MPLS-TP should abide. Some requirements for this application are 317 similar to some of those listed in RFC 4377 [7]. 319 The requirements listed below may be met by one or more toolsets, the 320 definition or selection of these toolsets is outside the scope of 321 this document. However, it is required that the specified solution 322 MUST inter-work with the existing MPLS and PW OAM toolset. 324 2.1. Architectural Requirements 326 OAM functions SHOULD be independent of the underlying tunnelling or 327 point-to-point technology. 329 OAM functions SHOULD be independent of the service a pseudowire may 330 emulate (e.g. Ethernet). 332 The set of OAM functions operated on each Maintenance Entity SHOULD 333 be independent one from another. The set of OAM functions must be a 334 self-sufficient set that does not require external capabilities to 335 achieve the OAM objectives. 336 Note that independence should not be understood here in terms of 337 isolation but in terms of separate running processes. There should be 338 one OAM process running per Maintenance Entity but different OAM 339 running processes could interact (e.g. alarm summarization). 341 OAM functions MUST operate and be configurable even in the absence of 342 a control plane. Conversely, OAM functions SHOULD be configurable as 343 part of connectivity (LSP or PW) management. Note that means for 344 configuring OAM functions and connectivity management are outside the 345 scope of this document. 347 The service emulated by a single segment of multi-segment pseudowire 348 may span multiple domains. The LSP itself, supporting the pseudo- 349 wire(s), may span multiple domains. It MUST be possible to perform 350 OAM functions on a per domain basis and across multiple domains. 351 Furthermore, in case of a fault or defect on the service, means MUST 352 be available for the service provider to be informed of the fault 353 even if the fault is located outside its domain. 355 OAM functions operate at the data plane. OAM packets MUST run in- 356 band. That is, OAM packets for a specific destination MUST follow the 357 same data path as data traffic for this destination. This is known as 358 fate sharing. 360 It MUST be possible to discriminate data traffic from OAM packets. 361 This includes a means to differentiate OAM packets from data traffic 362 as well as the capability to apply specific treatment to OAM packets. 364 OAM functionality MUST NOT be dependent on IP routing and forwarding 365 capabilities as these may not be available in networks where MPLS-TP 366 is deployed. 368 OAM functions MUST be able to be used for PWs and LSPs and Section. 369 Furthermore, since LSPs MAY be stacked, OAM functions MUST be able to 370 be run at each network layer (i.e. any level of the label stack). 372 OAM functions MUST be applicable to bidirectional point-to-point 373 connections, and a subset of these OAM functions MUST be applicable 374 to unidirectional point-to-point and point-to-multipoint connections. 375 This subset is based on the nature of both the OAM functions and the 376 connections to which they can apply. The tables below (Table 1 and 377 Table 2) summarize the applicability of OAM functions. 379 OAM functions SHOULD continue to meet their objectives regardless of 380 congestion conditions. See also ITU-T Y.1541 [4]. 382 2.2. Functional Requirements 384 In cases where the OAM of the native service of an AC or a PW type 385 does not provide mechanisms to propagate failure conditions 386 information, while a downstream indication of such state is needed, 387 MPLS-TP OAM SHOULD provide mechanisms for propagating AC failures and 388 their clearance across a MPLS-TP domain. 390 If a defect or fault occurs, mechanisms MUST be provided to detect 391 it, diagnose it, localize it, and notify the appropriate entities. 392 Corrective actions SHOULD be taken according to the type of defect or 393 fault. 395 In the case of the PW Maintenance Entity, OAM mechanisms provided 396 SHOULD ensure that customers do not have to detect faults. The OAM 397 functions SHOULD allow the service provider to automatically detect 398 and notify the faults associated with a PW Maintenance Entity. 400 An alarm suppression and summarization mechanism MUST be provided. 401 For example, a fault detected at the LSP level MUST NOT trigger 402 various alarms at the PW level. 404 The following two tables describe the required OAM functions 405 constituting the MPLS-TP OAM toolset for Fault Management and 406 Performance Management applications. In these tables, MEP stands for 407 monitoring from MEP to MEP, MIP stands for monitoring from MEP to 408 MIP, U stands for unidirectional, B stands for bidirectional. Crosses 409 (x) indicate a required function, numbers indicate a required 410 function while pointing to a footnote providing additional details. 412 Appendix A provides a short description of the OAM functions 413 typically supported in ITU-T defined transport networks. It is the 414 expectation that MPLS-TP will provide an equivalent set. 416 +-------------------------------------------+ 417 | Fault Management | 418 |-------------------------------------------| 419 | on-demand | proactive | 420 |---------------------+----------+----------| 421 | MEP | MIP | MEP | MIP | 422 |----------+----------+----------+----------| 423 | P2P |P2MP| P2P |P2MP| P2P |P2MP| P2P |P2MP| 424 |-----+----+----------+----------+-----+----| 425 |U |B | U |U |B | U |U |B | U |U |B | U | 426 +---------------------+--+--+----+--+--+----+--+--+----+--+--+----| 427 |continuity check | |x | | |x | |x |x | x | | | | 428 |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| 429 |connectivity verif. | |x | | |x | |x |x | x | | | | 430 |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| 431 |alarm suppression | | | | | | |x |x | x | | | | 432 |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| 433 |lock indication | | | | | | |x |x | x | | | | 434 |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| 435 |packet loss meas. | | | | | | |x |2 | x | | | | 436 |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| 437 |diagnostic test |x |1 | x | | | | | | | | | | 438 |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| 439 |trace-route | |x | | |x | | | | | | | | 440 |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| 441 |delay measurement | | | | | | | | | | | | | 442 |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| 443 |remote defect indic. | | | | | | | |x | | | | | 444 +---------------------+-------------------------------------------+ 446 1: unidirectional and bidirectional test 448 2: in both directions of the bi-directional connection 450 Table 1 : OAM Functions for Fault Management 451 +-------------------------------------------+ 452 | Performance Management | 453 |-------------------------------------------| 454 | on-demand | proactive | 455 |---------------------+----------+----------| 456 | MEP | MIP | MEP | MIP | 457 |----------+----------+----------+----------| 458 | P2P |P2MP| P2P |P2MP| P2P |P2MP| P2P |P2MP| 459 |-----+----+----------+----------+-----+----| 460 |U |B | U |U |B | U |U |B | U |U |B | U | 461 +---------------------+--+--+----+--+--+----+--+--+----+--+--+----| 462 |continuity check | | | | | | |x |x | x | | | | 463 |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| 464 |connectivity verify. | | | | | | |x |x | x | | | | 465 |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| 466 |alarm suppression | | | | | | | | | | | | | 467 |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| 468 |lock indication | | | | | | | | | | | | | 469 |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| 470 |packet loss meas. | |1 | | | | |x |3 | x | | | | 471 |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| 472 |diagnostic test | | | | | | | | | | | | | 473 |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| 474 |trace-route | | | | | | | | | | | | | 475 |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| 476 |delay measurement |x |2 |x | | | | | | | | | | 477 |---------------------+--+--+----+--+--+----+--+--+----+--+--+----| 478 |remote defect indic. | | | | | | | |x | | | | | 479 +---------------------+-------------------------------------------+ 481 1: single-ended packet loss measurements 483 2: one-way and two-way packet delay measurements 485 3: in both directions of the bi-directional connection 487 Table 2 : OAM Functions for Performance Management 489 Note: In case a misconnection is detected, proactive Performance 490 Management MUST be suspended until the misconnection has been 491 repaired; i.e. all request/response OAM needs to be treated with 492 caution as it cannot be assumed to function reliably, e.g. if traffic 493 is leaking in a unidirectional sense with no return path. 495 The use of OAM functions SHOULD be optional for the operator. A 496 network operator SHOULD be able to choose which OAM functions to use 497 and which Maintenance Entity to apply them to. However, it is 498 recommended that connectivity verification is performed on every 499 Maintenance Entity in order to reliably detect connectivity defects. 501 OAM functions such as Continuity Check (CC) and Connectivity 502 Verification (CV) MUST NOT rely on user traffic. Dedicated OAM CV and 503 CC flows SHOULD be used to detect continuity and connectivity 504 defects. See also ITU-T G.806 [3]. 506 As part of the design of OAM mechanisms for MPLS-TP, a mechanism MUST 507 be provided enabling the realization of a channel for general purpose 508 signalling, e.g. for control, management and OAM information, that is 509 associated with the data plane paths. 511 The design of OAM mechanisms for MPLS-TP MUST allow the ability to 512 support vendor specific and experimental OAM functions. 514 Finally, the OAM mechanisms in support of these requirements SHALL be 515 extensible and thus SHALL NOT preclude additional OAM functions in 516 the future. 518 2.3. Performance Requirements 520 To be incorporated in a future revision of this document 522 3. Security Considerations 524 Mechanisms SHOULD be provided to ensure that unauthorized access is 525 prevented from triggering any OAM function. 527 OAM messages MAY be authenticated. 529 An OAM packet for a Maintenance Entity MUST NOT leak out of the ME, 530 i.e. go beyond the terminating MEP. 532 Architectural aspects for security concerning MPLS-TP are described 533 in Clause 13 of ITU-T G.8110.1 [5]. 535 4. Congestion Considerations 537 A mechanism (e.g. rate limiting) MUST be provided to prevent OAM 538 messages from causing congestion in the PSN. 540 5. IANA Considerations 542 There are no IANA actions required by this draft. 544 6. Acknowledgments 546 The authors would like to thank all members of the teams (the Joint 547 Working Team, the MPLS Interoperability Design Team in IETF and the 548 T-MPLS Ad Hoc Group in ITU-T) involved in the definition and 549 specification of MPLS Transport Profile. 551 APPENDIX A : OAM Functions Information 553 This Appendix provides a short description of the OAM functions 554 typically supported in ITU-T defined transport networks. 556 A.1. Continuity Check 558 Continuity Check (CC) is a function that is used to detect loss of 559 continuity between MEPs. 561 CC is useful for applications like Fault Management, Performance 562 Monitoring and Protection Switching, etc. 564 CC should be supported both in pro-active and on-demand modes. In 565 pro-active mode it may be supported for both bidirectional and 566 unidirectional connections. 568 In on-demand mode, CC should be supported for bidirectional 569 connections both between MEPs and between a MEP and a particular MIP 570 along the connection. 572 A.2. Connectivity Verification 574 Connectivity Verification (CV) is a function that is used to check 575 connectivity between MEPs in a single maintenance domain. 577 CV should be supported both in pro-active and on-demand modes. In 578 pro-active mode it may be supported for both unidirectional and bi- 579 directional connections. 581 In on-demand mode, CV should be supported for bidirectional 582 connections both between MEPs and between a MEP and a particular MIP 583 along the connection. 585 A.3. Alarm Suppression 587 Alarm Suppression is a function that is used by a server layer MEP to 588 notify a failure condition to its client layer MEP(s) in order to 589 suppress alarms that may be generated by maintenance domains of the 590 client layer as a result of the failure condition in the server 591 layer. 593 Alarm Suppression should be supported in proactive mode only, for all 594 both unidirectional and bi-directional connections. 596 A.4. Lock Indication 598 Lock Indication is a function that is used to indicate an 599 administrative locking of a server layer MEP which may result in 600 consequential interruption of data traffic forwarding towards the 601 client layer MEP(s) expecting this traffic. The reception of a Lock 602 Indication allows a MEP to differentiate between a defect condition 603 and an administrative locking action at the server layer MEP. 605 Lock indication should be supported in pro-active mode only. 607 A.5. Packet Loss Measurement 609 Packet Loss Measurement is a function that is used to measure packet 610 loss ratio between a pair of MEPs. Packet Loss Ratio is the ratio of 611 the service packets not delivered to the total number of service 612 packets transmitted during a set time interval. The number of service 613 packets not delivered is the difference between the number of service 614 packets transmitted by the source node and the number of service 615 packets received at the destination node. 617 Packet loss Measurements can be performed by a MEP to measure near- 618 end packet loss on unidirectional connections and near-end and far- 619 end packet loss on bidirectional connections. Where, near-end packet 620 loss refers to packet loss associated with ingress data packets while 621 far-end packet loss refers to packet loss associated with egress data 622 packets. 624 The measurement of packet loss ratio should be supported in pro- 625 active mode for both unidirectional and bi-directional connections. 627 A.6. Diagnostic Test 629 A diagnostic test is a function that is used between MEPs to verify 630 bandwidth throughput, packet loss, bit errors, etc. 632 This function may be used in on-demand mode for either unidirectional 633 or bi-directional connections. 635 A.7. Trace-route 637 Trace-route is a function that is used to determine the route of a 638 connection across the MPLS transport network. 640 Trace-route should be supported in on-demand mode for bi-directional 641 connections between a pair of MEPs or between a MEP and a MIP. 643 A.8. Delay Measurement 645 Delay Measurement is a function that is used to measure one-way or 646 two-way delay of a packet transmission between a pair of MEPs. Where, 648 o One-way packet delay is the time elapsed from the start of 649 transmission of the first bit of the packet by a source node until 650 the reception of the first bit of that packet by the destination 651 node. 653 o Two-way packet delay is the time elapsed from the start of 654 transmission of the first bit of the packet by a source node until 655 the reception of the last bit of the loop-backed packet by the 656 same source node, when the loopback is performed at the packet's 657 destination node. 659 This function may be used in on-demand mode. 661 A.9. Remote Defect Indication 663 Remote Defect Indication (RDI) is a function that used by a MEP to 664 notify its peer MEP of a detection of a defect on a bi-directional 665 connection between them. 667 This function should be supported in pro-active mode. 669 A.10. Client Signal Fail 671 Client Signal Fail function (CSF) is used to propagate a Client 672 Failure indication to the far-end sink when alarm suppression in the 673 client layer is not supported. Upon receiving a packet with CSF 674 information a MEP detects a client-layer failure condition and 675 notifies its client-layer. 677 Upon receiving signal fail indication from its client-layer the MEP 678 should immediately start transmitting periodic packets with CSF 679 information. A MEP should continue to transmit periodic packets with 680 CSF information until the client-layer failure indication is removed. 682 Transmission of packets with CSF information can be enabled or 683 disabled on a MEP. 685 APPENDIX B : Mapping between RFC 4377, Y.Sup4 and this document 687 To be defined at a later stage. 689 7. References 691 7.1. Normative References 693 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 694 Levels", BCP 14, RFC 2119, March 1997 696 [2] ITU-T Recommendation M.3400 (2000), TMN management functions 698 [3] ITU-T Recommendation G.806 (2006), Characteristics of transport 699 equipment - Description methodology and generic functionality 701 [4] ITU-T Recommendation Y.1541 (2006), Network performance 702 objectives for IP-based services 704 [5] ITU-T Recommendation G.8110.1/Y.1370.1 (2007), Architecture of 705 Transport MPLS (T-MPLS) Layer Network 707 [6] ITU-T Supplement Y.Sup4 (2008), Transport Requirements for T- 708 MPLS OAM and considerations for the application of IETF MPLS 709 Technology 711 7.2. Informative References 713 [7] Nadeau, T., et al., "Operations and Management (OAM) 714 Requirements for Multi-Protocol Label Switched (MPLS) 715 Networks", RFC 4377, February 2006 717 [8] Response to liaisons on G.8110.1 (from ITU-T SG 15 to IETF) 718 https://datatracker.ietf.org/liaison/265/ 720 Authors' Addresses 722 Martin Vigoureux 723 Alcatel-Lucent 725 Email: martin.vigoureux@alcatel-lucent.com 727 David Ward 728 Cisco Systems, Inc. 730 Email: dward@cisco.com 731 Malcolm Betts 732 Nortel Networks 734 Email: betts01@nortel.com 736 Contributing Authors' Addresses 738 Matthew Bocci 739 Alcatel-Lucent 741 Email: matthew.bocci@alcatel-lucent.co.uk 743 Italo Busi 744 Alcatel-Lucent 746 Email: italo.busi@alcatel-lucent.it 748 Huub van Helvoort 749 Huawei Technologies Co.Ltd. 751 Email: hhelvoort@huawei.com 753 Marc Lasserre 754 Alcatel-Lucent 756 Email: mlasserre@alcatel-lucent.com 758 Lieven Levrau 759 Alcatel-Lucent 761 Email: llevrau@alcatel-lucent.com 763 Han Li 764 China Mobile Communications Corporation (CMCC) 765 Email: lihan@chinamobile.com 766 Julien Meuric 767 Orange 769 Email: julien.meuric@orange-ftgroup.com 771 Philippe Niger 772 Orange 774 Email: philippe.niger@orange-ftgroup.com 776 Jing Ruiquan 777 China Telecom 778 Email: jingrq@ctbri.com.cn 780 Nurit Sprecher 781 Nokia-Siemens Networks 783 Email: nurit.sprecher@nsn.com 785 Yuji Tochio 786 Fujitsu 788 Email: tochio@jp.fujitsu.com 790 Yaacov Weingarten 791 Nokia-Siemens Networks 793 Email: yaacov.weingarten@nsn.com 795 Intellectual Property Statement 797 The IETF takes no position regarding the validity or scope of any 798 Intellectual Property Rights or other rights that might be claimed to 799 pertain to the implementation or use of the technology described in 800 this document or the extent to which any license under such rights 801 might or might not be available; nor does it represent that it has 802 made any independent effort to identify any such rights. Information 803 on the procedures with respect to rights in RFC documents can be 804 found in BCP 78 and BCP 79. 806 Copies of IPR disclosures made to the IETF Secretariat and any 807 assurances of licenses to be made available, or the result of an 808 attempt made to obtain a general license or permission for the use of 809 such proprietary rights by implementers or users of this 810 specification can be obtained from the IETF on-line IPR repository at 811 http://www.ietf.org/ipr. 813 The IETF invites any interested party to bring to its attention any 814 copyrights, patents or patent applications, or other proprietary 815 rights that may cover technology that may be required to implement 816 this standard. Please address the information to the IETF at ietf- 817 ipr@ietf.org. 819 Disclaimer of Validity 821 This document and the information contained herein are provided on an 822 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 823 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 824 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 825 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 826 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 827 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 829 Copyright Statement 831 Copyright (C) The IETF Trust (2008). 833 This document is subject to the rights, licenses and restrictions 834 contained in BCP 78, and except as set forth therein, the authors 835 retain all their rights. 837 Acknowledgment 839 Funding for the RFC Editor function is currently provided by the 840 Internet Society.