idnits 2.17.1 draft-fang-mpls-tp-oam-toolset-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 14, 2011) is 4785 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC 5654' is defined on line 688, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 723, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luyuan Fang 3 Internet Draft Dan Frost 4 Intended status: Informational Cisco Systems 5 Expires: September 14, 2011 Nabil Bitar 6 Verizon 7 Raymond Zhang 8 BT 9 Lei Wang 10 Telenor 11 Kam Lee Yap 12 XO Communications 13 Michael Fargano 14 Qwest 15 John Drake 16 Juniper 17 Thomas Nadeau 19 March 14, 2011 21 MPLS-TP OAM Toolset 22 draft-fang-mpls-tp-oam-toolset-01.txt 24 Abstract 26 This document provides an overview of the MPLS-TP OAM toolset, 27 which consists of MPLS-TP fault management and performance 28 monitoring. This overview includes a brief recap of MPLS-TP OAM 29 requirements and functions, and of the generic mechanisms created 30 in the MPLS data plane to support in-band OAM. The importance of 31 using IANA assigned code point under G-Ach when supporting MPLS-TP 32 OAM is also discussed. The protocol definitions for each individual 33 MPLS-TP OAM tool are specified in separate RFCs or Working Group 34 documents which are referenced by this document. 36 Status of this Memo 38 This Internet-Draft is submitted to IETF in full conformance with 39 the provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six 47 months and may be updated, replaced, or obsoleted by other documents 48 at any time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress. 51 This Internet-Draft will expire on September 14, 2011. 53 Copyright Notice 55 Copyright (c) 2011 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with 63 respect to this document. Code Components extracted from this 64 document must include Simplified BSD License text as described in 65 Section 4.e of the Trust Legal Provisions and are provided without 66 warranty as described in the Simplified BSD License.. 68 Table of Contents 70 1. Introduction ..................................................3 71 2. Terminology ...................................................3 72 3. Brief Overview of MPLS-TP OAM Requirements ....................6 73 3.1. Architectural Requirements .................................6 74 3.2. Functional Requirements ....................................6 75 4. MPLS-TP OAM Mechanisms and Toolset Summary ....................7 76 4.1. In-band OAM Mechanisms .....................................8 77 4.2. Fault Management Toolset ...................................8 78 4.3. Performance Monitoring Toolset ............................10 79 5. OAM Toolset Utilization and Protocol Definitions .............10 80 5.1. Connectivity Check and Connectivity Verification ..........10 81 5.2 Diagnostic Tests and Lock Instruct. .......................11 82 5.3. Lock Reporting ............................................11 83 5.4. Alarm Reporting and Link down Indication ..................12 84 5.5. Remote Defect Indication ..................................12 85 5.6. Packet Loss and Delay Measurement .........................13 86 6. IANA assigned code points under G-Ach ........................14 87 7. Security Considerations ......................................15 88 8. IANA Considerations ..........................................15 89 9. Normative References .........................................15 90 10. Informative References .....................................16 91 11. Authors' Addresses..........................................17 93 Requirements Language 95 Although this document is not a protocol specification, the key 96 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 98 this document are to be interpreted as described in RFC 2119 [RFC 99 2119]. 101 1. Introduction 103 The Operations, Administration, and Maintenance (OAM) Requirements 104 for Transport Profile of Multiprotocol Label Switching (MPLS-TP) 105 networks are defined in RFC 5860 [RFC 5860]. MPLS-TP OAM mechanisms 106 and multiple OAM tools have been developed based on MPLS-TP OAM 107 requirements. 109 This document provides an overview of the MPLS-TP OAM toolset, 110 which consists of MPLS-TP fault management and performance 111 monitoring. This overview includes a brief recap of MPLS-TP OAM 112 requirements and functions, and of the generic mechanisms created 113 in the MPLS data plane to support in-band OAM. The importance of 114 using IANA assigned code point under G-Ach when supporting MPLS-TP 115 OAM is also discussed. 117 The protocol definitions for each individual MPLS-TP OAM tool are 118 specified in separate RFCs or Working Group documents while this 119 document is work in progress, which are referenced by this 120 document. 122 The protocol definitions for each individual MPLS-TP OAM tool are 123 defined in separate RFCs (or Working Group documents while this 124 document is work in progress) referenced by this document. 126 2. Terminology 128 This document uses MPLS-TP OAM specific terminology. 130 Term Definition 131 ---------------------------------------------------- 132 AC Attachment Circuit 134 AIS Alarm indication signal 135 APS Automatic Protection Switching 137 ATM Asynchronous Transfer Mode 139 BFD Bidirectional Forwarding Detection 141 CC Continuity Check 143 CE Customer-Edge device 145 CM Configuration Management 147 CoS Class of Service 149 CV Connectivity Verification 151 FM Fault Management 153 GAL Generic Alert Label 155 G-ACH Generic Associated Channel 157 GMPLS Generalized Multi-Protocol Label Switching 159 LDI Link Down Indication 161 LDP Label Distribution Protocol 163 LER Label Edge Router 165 LKR Lock Report 167 LM Loss Measurement 169 LMEG LSP ME Group 171 LOC Loss of Continuity 173 LSP Label Switched Path 175 LSR Label Switching Router 177 LSME LSP SPME ME 179 LSMEG LSP SPME ME Group 181 ME Maintenance Entity 182 MEG Maintenance Entity Group 184 MEP Maintenance Entity Group End Point 186 MIP Maintenance Entity Group Intermediate Point 188 MPLS MultiProtocol Label Switching 190 NMS Network Management System 192 NTP Network Time Protocol 194 OAM Operations, Administration, and Management 196 PE Provider Edge 198 PM Performance Monitoring 200 PME PW Maintenance Entity 202 PMEG PW ME Group 204 PSME PW SPME ME 206 PSMEG PW SPME ME Group 208 PW Pseudowire 210 QoS Quality of Service 212 RDI Remote Defect Indication 214 SDH Synchronous Digital Hierarchy 216 SLA Service Level Agreement 218 SME Section Maintenance Entity 220 SMEG Section ME Group 222 SONET Synchronous Optical Network 224 SPME Sub-path Maintenance Element 226 S-PE Switching Provider Edge 228 SRLG Shared Risk Link Group 230 TC Traffic Class 231 T-PE Terminating Provider Edge 233 3. Brief Overview of MPLS-TP OAM Requirements 235 This following Architectural and Functional Requirements are 236 defined by RFC 5860. They are captured here for easy reading before 237 discussing the toolset. 239 3.1. Architectural Requirements 241 The MPLS-TP OAM Supports point-to-point bidirectional PWs, point- 242 to-point co-routed bidirectional LSPs, point-to-point bidirectional 243 Sections, point-to-point associated bidirectional LSPs, point-to- 244 point unidirectional LSPs, and point-to-multipoint LSPs. In 245 addition, MPLS-TP OAM supports these LSPs and PWs when they span 246 single domain or multiple domains. 248 The protocol solution(s) SHOULD be independent of the underlying 249 tunneling or point-to-point technology or transmission media. The 250 protocol solution(s) SHOULD be independent of the service a PW may 251 emulate. 253 In-band OAM MUST be implemented. OAM packets for a specific PW, 254 LSP, or Section MUST follow the exact same data path as user 255 traffic of the same. 257 The solutions MUST support OAM functions with or without relying on 258 IP capabilities. 260 It is REQUIRED that OAM interoperability be achieved between 261 distinct domains with different operational models, e.g. with IP or 262 without IP support in the data plane. 264 And OAM functions MUST be configurable even in the absence of a 265 control plane. 267 3.2. Functional Requirements 269 In general, MPLS-TP OAM tools MUST provide functions to detect, 270 diagnose, localize, and notify the faults when occur. The mechanism 271 for correction actions trigged by fault detection SHOULD be 272 provided. 274 The following are the fault detection functional requirements 276 - Continuity Checks: a function to enable an End Point to monitor 277 the liveness of a PW, LSP, or Section. 279 - Connectivity Verifications: a function to enable an End Point to 280 determine whether or not it is connected to specific End Point(s) 281 by means of the expected PW, LSP, or Section. 283 - Route Tracing: the functionality to enable an End Point to 284 discover the Intermediate (if any) and End Point(s) along a PW, 285 LSP, or Section, and more generically to trace the route of a PW, 286 LSP or Section. 288 - Diagnostic Tests: a function to enable conducting diagnostic 289 tests on a PW, LSP, or Section. For example, a loop-back function. 291 - Lock Instruct: the functionality to enable an End Point of a PW, 292 LSP, or Section to instruct its associated End Point(s) to lock the 293 PW, LSP, or Section. 295 - Lock Reporting: a function to enable an Intermediate Point of a 296 PW or LSP to report, to an End Point of that same PW or LSP, a lock 297 condition indirectly affecting that PW or LSP. 299 - Alarm Reporting: the functionality to enable an Intermediate 300 Point of a PW or LSP to report, to an End Point of that same PW or 301 LSP, a fault or defect condition indirectly affecting that PW or 302 LSP. 304 - Remote Defect Indication: a function to enable an End Point to 305 report, to its associated End Point, a fault or defect condition 306 that it detects on a PW, LSP, or Section for which they are the End 307 Points. 309 - Client Failure Indication: a function to enable the propagation, 310 from edge to edge of an MPLS-TP network, of information pertaining 311 to a client fault condition detected at an End Point of a PW or 312 LSP, if the client layer OAM does not provide alarm notification. 314 - Packet Loss Measurement: a function to enable the quantification 315 of packet loss ratio over a PW, LSP, or Section. 317 - Packet Delay Measurement: a function to enable the quantification 318 of the one-way, and if appropriate, the two-way, delay ratio of a 319 PW, LSP, or Section. 321 4. MPLS-TP OAM Mechanisms and Toolset Summary 323 The following subsections provide the summary of MPLS-TP OAM Fault 324 Management and Performance Management toolset, with indication of 325 the corresponding IETF RFCs (or Internet drafts while this document 326 is work in progress) to support the MPLS-TP OAM functions defined 327 in RFC 5860. 329 4.1. In-band OAM Mechanisms 331 To meet the In-band OAM requirements for MPLS-TP, Generic 332 Associated Channel is created [RFC 5586]. It generalizes the 333 applicability of the Pseudowire (PW) Associated Channel Header 334 (ACH) to MPLS Label Switching Paths (LSPs), and Sections. 336 The Generic Associated Label (GAL) [RFC 5586] is defined by 337 assigning one of the reserved MPLS label values to the G-Ach, GAL 338 identifies the presence of the Associated Channel Header following 339 the label stack. 341 The creation of G-Ach and GAL provided the necessary mechanisms for 342 building in-band OAM MPLS-TP toolset. 344 RFC 5718 [RFC 5718] An-In-Band Data Communication Network for the 345 MPLS Transport Profile describes how the G-Ach may be used for 346 Management and Signaling Communication. 348 4.2. Fault Management Toolset 350 The following tables provide the summary of MPLS-TP OAM toolset. 352 Table 1 provides the summary of MPLS-TP OAM Fault Management 353 toolset functions, associated tool/protocol, and the corresponding 354 IETF RFCs or Internet drafts where they are defined. 356 Table 2 provides the Performance Monitoring Functions, associated 357 tool/protocol definitions, and the corresponding IETF RFCs or 358 Internet Drafts where they are defined. 360 The following table provide the Performance Monitoring Functions, 361 protocol definitions, and corresponding RFCs or Internet Drafts. 363 (Editor's note: only RFCs will be referenced in the final version 364 of the document). 366 +----------------------------------------------------------------+ 367 | Proactive Fault Management OAM Toolset | 368 |----------------------------------------------------------------| 369 |OAM Functions |OAM Tools/Protocols | RFCs / IDs | 370 |------------------|------------------------|--------------------| 371 |Continuity Check |Bidirectional Forwarding| draft-ietf-mpls-tp | 372 |(CV) & Continuity |Detection (BFD) | -cc-cv-rdi [cc-cv] | 373 |Verification(CV) | | | 374 |------------------|------------------------|--------------------| 375 |Remote Defect |Bidirectional Forwarding| draft-ietf-mpls-tp | 376 |Indication (RDI) |Detection (BFD) | -cc-cv-rdi [cc-cv] | 377 |------------------|------------------------|--------------------| 378 |Alarm Indication |AIS message under G-Ach | draft-ietf-mpls-tp | 379 |Signal (AIS) | | -fault [fault] | 380 |------------------|------------------------|--------------------| 381 |Link Down |Flag in AIS message | draft-ietf-mpls-tp | 382 |Indication (LDI) | | -fault [fault] | 383 |------------------|------------------------|--------------------| 384 |Lock Report (LKR) |LKR message under G-Ach | draft-ietf-mpls-tp | 385 | | | -fault [fault] | 386 +----------------------------------------------------------------+ 388 Table 1. Proactive Fault Management OAM Toolset 390 +----------------------------------------------------------------+ 391 | On Demand Fault Management OAM Toolset | 392 |----------------------------------------------------------------| 393 |OAM Functions |OAM Tools/Protocols | RFCs / IDs | 394 |------------------|------------------------|--------------------| 395 |Continuity |LSP Ping and BFD | draft-ietf-mpls-tp | 396 |Verification(CV) | | -cc-cv-rdi [cc-cv] | 397 |------------------|------------------------|--------------------| 398 |Diagnostic: |1) In-band Loopback | draft-ietf-mpls-tp | 399 |Loopback, Lock | and Lock Instruct | -li-lb [li-lb] | 400 |and LSP Ping |2) LSP Ping | | 401 |------------------|------------------------|--------------------| 402 |Lock Instruct | In-band lock message | draft-ietf-mpls-tp | 403 |(LI) | in G-Ach | -li-lb [li-lb] | 404 +----------------------------------------------------------------+ 406 Table 2. On Demand Fault Management OAM Toolset 408 4.3. Performance Monitoring Toolset 410 Table 3 provides the Performance Monitoring Fuctions, protocol 411 definitions, and corresponding RFCs or Internet Drafts. 412 +----------------------------------------------------------------+ 413 | Performance Monitoring OAM Toolset | 414 |----------------------------------------------------------------| 415 |OAM Functions |Protocols Definitions | RFCs / IDs | 416 |------------------|------------------------|--------------------| 417 |Packet loss |LM & DM query messages | draft-ietf-mpls-tp | 418 |measurement (LM) | | -loss-delay [lo-de]| 419 |------------------|------------------------| | 420 |Packet delay (DM) |LM & DM query messages | draft-ietf-mpls-tp | 421 |measurement | | -loss-delay | 422 |------------------|------------------------|-profile [tp-lo-de] | 423 |Throughput |derived from Loss | | 424 |measurement |measurement | | 425 |------------------|------------------------| | 426 |Delay Variation |Supported from Delay | | 427 |measurement |measurement | | 428 +----------------------------------------------------------------+ 430 Table 3. Performance Monitoring OAM Toolset 432 5. OAM Toolset Utilization and Protocol Definitions 434 5.1. Connectivity Check and Connectivity Verification 436 Continuity Check (CC) and Proactive Connectivity Verification (CV) 437 functions are used to detect loss of continuity (LOC), and 438 unintended connectivity between two MEPs. 440 Loss of connectivity, mis-merging, mis-connectivity, or unexpected 441 Maintenance Entity Group End Points (MEPs) can be detected using 442 the CC/CV tools. 444 The CC/CV tools are used to support MPLS-TP fault management, 445 performance management, and protection switching. 447 Bidirectional Forwarding Detection (BFD) and LSP Ping are defined 448 to support the CC/CV functions [cc-cv]. 450 BFD control packets are sent by the source MEP to sink MEP. The 451 sink MEP monitors the arrival of the BFD control packets and 452 detects the defect. 454 The interval of BFD control packet can be configured. For example: 456 - 3.3ms is the default interval for protection switching. 457 - 100ms is the default interval for performance monitoring. 458 - 1s is the default interval for fault management. 460 5.2. Diagnostic Tests and Lock Instruct 462 The OAM functions to support diagnostic tests are required in the 463 transport environment. 465 The Loopback mode is defined for management purpose in [li-lb]. The 466 mechanism is provided to Lock and unlock traffic (e.g. data and 467 control traffic) or specific OAM traffic at a specific LSR on the 468 path of the MPLS-TP LSP to allow loop back it to the source by [li- 469 lb]. 471 These diagnostic functions apply to associated bidirectional MPLS- 472 TP LSPs, including MPLS-TP LSPs, bi-directional RSVP-TE tunnels 473 (which is relevant for MPLS-TP dynamic control plane option with 474 GMPLS), and single segment and multi-segment pseudowires. 476 The Lock operation instruction is carried in an MPLS Loopback 477 request message sent from a MEP to a trail-end MEP of the LSP to 478 request that the LSP be taken out of service. In response, the 479 Lock operation reply is carried in a Loopback response message sent 480 from the trail-end MEP back to the originating MEP to report the 481 result. 483 The loopback operations include [li-lb]: 484 - Lock: take an LSP out of service for maintenance. 485 - Unlock: Restore a previously locked LSP to service. 486 - Set_Full_Loopback and Set_OAM_Loopback 487 - Unset_Full_Loopback and Set_OAM_Loopback 489 Operators can use the loopback mode to test the connectivity or 490 performance (loss, delay, delay variation, and throughput) of given 491 LSP upto a specific node on the path of the LSP. 493 5.3. Lock Reporting 495 The Lock Report (LKR) function is used to communicate to the client 496 (sub-) layer MEPs the administrative locking of a server (sub-) 497 layer MEP, and consequential interruption of data traffic 498 forwarding in the client (sub-) layer [fault]. 500 When operator is taking the LSP out of service for maintenance 501 other operational reason, using the LKR function can help to 502 distinguish the condition as administrative locking from defect 503 condition. 505 The Lock Report function would also serve the purpose of alarm 506 suppression in the MPLS-TP network above the level of the Lock is 507 occurred. The receipt of an LKR message MAY be treated as the 508 equivalent of loss of continuity at the client layer [fault]. 510 5.4. Alarm Reporting and Link down Indication 512 Alarm Indication Signal (AIS) message serves the purpose of alarm 513 suppression upon the failure detection in the server (-sub) layer. 514 When the Link Down Indication (RDI) is set, the AIS message MAY be 515 used to trigger recovery mechanisms [fault]. 517 When a server MEP detects the failure, it asserts Loss of 518 Continuity (LOC) or signal fail which sets the flag up to generate 519 OAM packet with AIS message. The AIS message is forwarded to 520 downstream sink MEP in the client layer. This would enable the 521 client layer to suppress the generation of secondary alarms. 523 A Link Down Indication (LDI) flag is defined in the AIS message. 524 The LDI flag is set in the AIS message in response to detecting a 525 fatal failure in the server layer. Receipt of an AIS message with 526 this flag set MAY be interpreted by a MEP as an indication of 527 signal fail at the client layer. [fault] 529 Fault OAM messages are generated by intermediate nodes where an LSP 530 is switched, and propagated to the end points (MEPs). 532 From practical point of view, when both proactive CC functions and 533 LDI are used, one may consider to run the proactive CC functions at 534 a slower rate (e.g. longer BFD hello intervals), and reply on LDI 535 to trigger fast protection switch over upon failure detection in a 536 given LSP. 538 5.5. Remote Defect Indication 540 Remote Defect Indication (RDI) function enables an End Point to 541 report to the other End Point that a fault or defect condition is 542 detected on the PW, LSP, or Section they are the End Points. 544 The RDI OAM function is supported by the use of Bidirectional 545 Forwarding Detection (BFD) Control Packets [cc-cv]. RDI is only 546 used for bidirectional connections and is associated with proactive 547 CC/CV activation. 549 When an end point (MEP) detects a signal failure condition, it sets 550 the flag up by setting the diagnostic field of the BFD control 551 packet to a particular value to indicate the failure condition on 552 the associated PW, LSP, or Section, and transmitting the BFD 553 control packet with the failure flag up to the other end point (its 554 peer MEP). 556 RDI function can be used to facilitate the protection switching by 557 synchronizing the two end points when unidirectional failure occurs 558 and is detected by one end. 560 5.6. Packet Loss and Delay Measurement 562 Packet loss and delay measurement toolset enables operators to 563 measure the quality of the packet transmission over a PW, LSP, or 564 Section. 566 The protocol for MPLS-TP loss and delay measurement functions is 567 defined in [lo-de] as profiled in [tp-lo-de]. These documents 568 specify how to measure Packet Loss, Packet Delay, Packet Delay 569 Variation, and Throughput. 571 The loss and delay protocols have the following characteristics and 572 capabilities: 574 - Support measurement of packet loss, delay and throughput 575 over Label Switched Paths (LSPs), pseudowires, and MPLS 576 sections (links). 578 - The same LM and DM protocols can be used for both 579 continuous/proactive and selective/on-demand measurement. 581 - The LM and DM protocols use a simple query/response model 582 for bidirectional measurement that allows a single node - 583 the querier - to measure the loss or delay in both 584 directions. 586 - The LM and DM protocols use query messages for 587 unidirectional loss and delay measurement. The measurement 588 can either be carried out at the downstream node(s) or at 589 the querier if an out-of-band return path is available. 591 - The LM and DM protocols do not require that the transmit and 592 receive interfaces be the same when performing bidirectional 593 measurement. 595 - The LM protocol supports both 32-bit and 64-bit counters 596 although for simplicity only 32-bit packet counters are 597 currently included in the MPLS-TP profile. 599 - The LM protocol supports measurement in terms of both packet 600 counts and octet counts although for simplicity only packet 601 counters are currently included in the MPLS-TP profile. 603 - The LM protocol can be used to measure channel throughput as 604 well as packet loss. 606 - The DM protocol supports varying the measurement message 607 size in order to measure delays associated with different 608 packet sizes. 610 6. IANA assigned code points under G-Ach 612 OAM toolset/functions defined under G-Ach MUST use IANA assigned 613 code points, using Experimental Code Point under G-Ach is 614 inappropriate and it can lead to interoperability problems and 615 potential Code Point collision in production network. 617 RFC 5586 "MPLS Generic Associated Channel" stated the following in 618 IANA consideration section: A requirement has emerged (see [RFC 619 5860]) to allow for optimizations or extensions to OAM and other 620 control protocols running in an associated channel to be 621 experimented without resorting to the IETF standards process, by 622 supporting experimental code points. This would prevent code points 623 used for such functions from being used from the range allocated 624 through the IETF standards and thus protects an installed base of 625 equipment from potential inadvertent overloading of code points. 626 In order to support this requirement, IANA has changed the code 627 point allocation scheme for the PW Associated Channel as follows: 629 0 - 32751: IETF Review 630 32760 - 32767: Experimental 632 Code points in the experimental range MUST be used according to the 633 guidelines of RFC 3692 [RFC 3692]. Functions using experimental G- 634 Ach code points MUST be disabled by default. 636 The guidelines on the usage of experimental numbers are defined in 637 IETF RFC 3692. As indicated by RFC 3692: The experimental numbers 638 are useful when experimenting new protocols or extending existing 639 protocols in order to test and experiment with the new functions, as 640 part of implementation. RFC 3692 reserves a range of numbers for 641 experimentation when the need of such experimentation has been 642 identified. 644 However, the experimental numbers "are reserved for generic testing 645 purposes, and other implementations may use the same numbers for 646 different experimental uses." "Experimental numbers are intended for 647 experimentation and testing and are not intended for wide or general 648 deployments." "Shipping a product with a specific value pre-enabled 649 would be inappropriate and can lead to interoperability problems 650 when the chosen value collides with a different usage, as it someday 651 surely will." 653 Further more, "it would be inappropriate for a group of vendors, a 654 consortia, or another Standards Development Organization to agree 655 among themselves to use a particular value for a specific purpose 656 and then agree to deploy devices using those values." Experimental 657 numbers are not guaranteed to be unique by definition. There is the 658 risk of code point collision when using Experimental Code Point in 659 production networks. 661 Similar statements can also be found in RFC4929 "Change Process for 662 Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 663 Protocols and Procedures". As described in [RFC 4775], "non- 664 standard extensions, including experimental values, are not to be 665 portrayed as industrial standards whether by an individual vendor, 666 an industry forum, or a standards body." 668 7. Security Considerations 670 The document provides overview of MPLS-TP OAM requirements, 671 functions, protocol, and solution considerations. The actual 672 protocols for the OAM toolset are defined in separate documents and 673 referenced by this document. 675 The general security considerations are provided in Security 676 Framework for MPLS and GMPLS Networks [RFC 5920], and MPLS-TP 677 Security Framework [tp-sec-fr]. 679 8. IANA Considerations 681 This document contains no new IANA considerations. 683 9. Normative References 685 [RFC 5586], M. Bocci, M. Vigoureux, S. Bryant, "MPLS Generic 686 Associated Channel",RFC 5586, June 2009. 688 [RFC 5654], Niven-Jenkins, B., et al, "MPLS-TP Requirements", RFC 689 5654, September 2009. 691 [RFC 5718], D. Beller, and A. Farrel, "An In-Band Data 692 Communication Network For the MPLS Transport Profile", RFC 5718, 693 Jan 2010. 695 [RFC 5860], M. Vigoureux, D. Ward, M. Betts, "Requirements for 696 Operations, Administration, and Maintenance (OAM) in MPLS Transport 697 Networks", RFC 5860, May 2010. 699 [cc-cv] D. Allan, G. Swallow, J. Drake, Proactive Connectivity 700 Verification, Continuity Check and Remote Defect indication for 701 MPLS Transport Profile, draft-ietf-mpls-tp-cc-cv-rdi-03, Feb. 2011. 703 [fault] G. Swallow, A. Fulignoli, M. Vigoureux, MPLS Fault 704 Management OAM, draft-ietf-mpls-tp-fault-01, March 2011. 706 [li-lb] S. Boutros, S. Sivabalan, et,al., MPLS Transport Profile 707 Lock Instruct and Loopback Functions draft-ietf-mpls-tp-li-lb- 708 01.txt, March 2011. 710 [loopback] S. Boutros, S. Sivabalan, G. Swallow, R. Aggarwal, M. 711 Vigoureux, Operating MPLS Transport Profile LSP in Loopback Mode, 712 draft-boutros-mpls-tp-loopback-03.txt, March 2011. 714 [lo-de] D. Frost, S. Bryant, Packet Loss and Delay Measurement for 715 the MPLS Networks, draft-ietf-mpls-loss-delay-01, Feb. 2011. 717 [tp-lo-de] D. Frost, S. Bryant, A Packet Loss and Delay Measurement 718 Profile for MPLS-based Transport Networks, draft-frost-mpls-tp-loss- 719 delay-profile-02, Feb. 2011. 721 10. Informative References 723 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 724 Requirement Levels", BCP 14, RFC 2119, March 1997 726 [RFC 3692] T. Narten, "Assigning Experimental and Testing Numbers 727 Considered Useful", RFC 3692, Jan. 2004. 729 [RFC 4775] S. Bradner, "Procedures for Protocol Extensions and 730 Variations", RFC 4775, Dec. 2006. 732 [RFC 5920] L. Fang, et al, Security Framework for MPLS and GMPLS 733 Networks, July 2010. 735 [MPLS-TP NM REQ] Hing-Kam Lam, Scott Mansfield, Eric Gray, MPLS TP 736 Network Management Requirements, draft-ietf-mpls-tp-nm-req-06.txt, 737 October 2009. 739 [tp-sec-fr] L. Fang, Niven-Jenkins, S. Mansfield, et. Al. MPLS-TP 740 Security Framework, draft-ietf-mpls-tp-security-framework-00, Feb. 741 2011. 743 11. Authors' Addresses 745 Luyuan Fang 746 Cisco Systems 747 111 Wood Avenue South 748 Iselin, NJ 08830 749 USA 750 Email: lufang@cisco.com 752 Dan Frost 753 Cisco Systems 754 Email: danfrost@cisco.com 756 Nabil Bitar 757 Verizon 758 40 Sylvan Road 759 Waltham, MA 02145 760 USA 761 Email: nabil.bitar@verizon.com 763 Raymond Zhang 764 British Telecom 765 BT Center 766 81 Newgate Street 767 London, EC1A 7AJ 768 United Kingdom 769 Email: raymond.zhang@bt.com 771 Lei Wang 772 Telenor 773 Telenor Norway 774 Office Snaroyveien 775 1331 Fornedbu 776 Email: Lei.wang@telenor.com 778 Kam Lee Yap 779 XO Communications 780 13865 Sunrise Valley Drive, 781 Herndon, VA 20171 782 Email: klyap@xo.com 784 Michael Fargano 785 Qwest 786 5325 Zuni St, 224 787 Denver CO 80221-1499 788 Email: Michael.Fargano@qwest.com 790 John Drake 791 Juniper 792 Email: jdrake@juniper.net 794 Thomas Nadeau 795 Email: tnadeau@lucidvision.com