idnits 2.17.1 draft-busi-mpls-tp-oam-framework-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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 975. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 952. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 959. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 965. 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 : ---------------------------------------------------------------------------- ** There are 38 instances of too long lines in the document, the longest one being 85 characters in excess of 72. ** The abstract seems to contain references ([10]), 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 == Line 352 has weird spacing: '...k. The figur...' == Line 375 has weird spacing: '...tecture frame...' == Line 429 has weird spacing: '... rather than,...' == Line 474 has weird spacing: '...trative bound...' -- 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 (October 27, 2008) is 5661 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '3' is defined on line 846, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 849, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-arch-05 == Outdated reference: A later version (-01) exists of draft-blb-mpls-tp-framework-00 == Outdated reference: A later version (-01) exists of draft-vigoureux-mpls-tp-oam-requirements-00 == Outdated reference: A later version (-07) exists of draft-sprecher-mpls-tp-oam-analysis-02 Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group I. Busi (Ed) 2 Internet Draft Alcatel-Lucent 3 Intended status: Informational 4 Expires: April 2009 B. Niven-Jenkins (Ed) 5 BT 7 October 27, 2008 9 MPLS-TP OAM Framework and Overview 10 draft-busi-mpls-tp-oam-framework-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-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 April 27, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) is 43 based on a profile of the MPLS and pseudowire (PW) procedures as 44 specified in the MPLS Traffic Engineering (MPLS-TE), pseudowire (PW) 45 and multi-segment PW (MS-PW) architectures complemented with 46 additional Operations, Administration and Maintenance (OAM) 47 procedures for fault, performance and protection-switching management 48 for packet transport applications that do not rely on the presence of 49 a control plane. 51 This document provides a framework for supporting the MPLS-TP OAM 52 requirements .[10] in a manner that admits a comprehensive set of OAM 53 procedures. 55 Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC 2119 .[1]. 61 Table of Contents 63 1. Introduction...................................................3 64 1.1. Contributing Authors......................................3 65 1.2. Terminology...............................................3 66 1.3. Definitions...............................................4 67 2. Functional Components..........................................4 68 2.1. Maintenance Entity........................................5 69 2.2. Maintenance End Points (MEPs).............................6 70 2.3. Maintenance Intermediate Points (MIPs)....................6 71 2.4. Server MEPs...............................................6 72 3. Reference Model................................................7 73 3.1. MPLS-TP Section Monitoring................................9 74 3.2. MPLS-TP LSP End-to-End Monitoring........................10 75 3.3. MPLS-TP LSP Tandem Connection Monitoring.................11 76 3.4. MPLS-TP PW Monitoring....................................12 77 3.5. MPLS-TP MS-PW Tandem Connection Monitoring...............12 78 4. OAM Functions for pro-active monitoring.......................13 79 4.1. Continuity Check and Connectivity Verification...........13 80 4.1.1. Applications for proactive CC & CV function.........15 81 4.2. Remote Defect Indication.................................15 82 4.2.1. Configuration considerations........................15 83 4.2.2. Applications for Remote Defect Indication...........16 84 4.3. Alarm Suppression........................................16 85 4.4. Lock Indication..........................................17 86 4.5. Packet Loss Measurement..................................17 87 4.6. Client Signal Fail.......................................17 88 5. OAM Functions for on-demand monitoring........................17 89 5.1. Continuity Check and Connectivity Verification...........17 90 5.1.1. Configuration considerations........................18 92 5.2. Packet Loss Measurement..................................18 93 5.3. Diagnostic Test..........................................18 94 5.4. Trace routing............................................18 95 5.5. Packet Delay Measurement.................................18 96 6. OAM Protocols Overview........................................18 97 7. Security Considerations.......................................18 98 8. IANA Considerations...........................................19 99 9. Acknowledgments...............................................19 100 10. References...................................................19 101 10.1. Normative References....................................19 102 10.2. Informative References..................................20 103 Authors' Addresses...............................................20 104 Contributing Authors' Addresses..................................20 105 Intellectual Property Statement..................................21 106 Disclaimer of Validity...........................................22 108 1. Introduction 110 As noted in the architecture for MPLS-TP .[8] the overall 111 architecture framework for MPLS-TP is based on a profile of the MPLS 112 and PW procedures as specified in the MPLS-TE and (MS-)PW 113 architectures defined in RFC 3031 .[2], RFC 3985 .[5] and .[6] 114 complemented with additional OAM procedures for fault, performance 115 and protection-switching management for packet transport applications 116 that do not rely on the presence of a control plane. 118 In line with .[11], existing MPLS OAM mechanisms will be used 119 wherever possible and new OAM mechanisms will be defined only where 120 existing mechanisms are not sufficient to meet the requirements. 122 The MPLS-TP OAM framework must satisfy the MPLS-TP OAM requirements . 123 [10] in a manner that provides for a comprehensive set of OAM 124 procedures. In this regard, it is similar to existing SONET/SDH and 125 OTH OAM mechanisms (e.g. .[12]). 127 1.1. Contributing Authors 129 Italo Busi, Ben Niven-Jenkins, Annamaria Fulignoli, Enrique 130 Hernandez-Valencia, Lieven Levrau, Dinesh Mohan, Vincenzo Sestito, 131 Nurit Sprecher, Huub van Helvoort, Martin Vigoureux, Yaacov 132 Weingarten 134 1.2. Terminology 136 LME LSP Maintenance Entity 137 ME Maintenance Entity 139 MEP Maintenance End Point 141 MIP Maintenance Intermediate Point 143 PME PW Maintenance Entity 145 SME Section Maintenance Entity 147 TCME Tandem Connection Maintenance Entity 149 TPME Tandem PW Maintenance Entity 151 1.3. Definitions 153 MPLS Section: to be added in a future revision of this document. 155 OAM flow: to be added in a future revision of this document. 157 Tandem Connection: A tandem connection corresponds to a segment of a 158 path. This may be either a segment of an LSP (i.e. a sub-path), or 159 one or more segment(s) of a PW. 161 2. Functional Components 163 MPLS-TP OAM operates in the context of Maintenance Entities (MEs). A 164 Maintenance Entity can be viewed as the association of two (or more) 165 Maintenance End Points (MEPs), see below. The MEPS that form an ME 166 should be configured and managed to limit the OAM responsibilities of 167 an OAM flow within a network or sub-network in the specific layer 168 network that is being monitored and managed. Each OAM flow is 169 associated to a unique ME. 171 Each MEP within an ME resides at the boundaries of that ME. An ME may 172 also include a set of zero or more Maintenance Intermediate Points 173 (MIPs), which reside within the Maintenance Entity. 175 A MEP is capable of initiating and terminating OAM messages for fault 176 management and performance monitoring. 178 A MIP is capable of generating OAM messages only in reaction to 179 received OAM packets. 181 This functional model defines the relationships between all OAM 182 entities from a maintenance perspective, to allow each Maintenance 183 Entity to monitor and manage the layer network under its 184 responsibility and easily localize problems. 186 MEPs and MIPs are configured either via the management plane and/or 187 the control plane, and they are associated with a particular 188 Maintenance Entity. 190 2.1. Maintenance Entity 192 A Maintenance Entity can be viewed as the association of two (or 193 more) Maintenance End Points (MEPs). The MEPs that form an ME should 194 be configured and managed to limit the OAM responsibilities of an OAM 195 flow within a network or sub-network, or a transport path or segment, 196 in the specific layer network that is being monitored and managed. 197 Any maintenance point in between the two MEPs is a Maintenance 198 Intermediate Points (MIP). 200 A Maintenance Entity may be defined to monitor and manage bi- 201 directional or unidirectional point-to-point connectivity or point- 202 to-multipoint connectivity in an MPLS-TP layer network. 204 MPLS-TP OAM functions are designed to be applied either on an end-to- 205 end basis, e.g., between the LERs of a given LSP or T-PEs of a given 206 PW, or on a per tandem connection basis, e.g., between any LER/LSR of 207 a given LSP or any T-PE/S-PE of a given PW. 209 The end points of a tandem connection are MEPs because the tandem 210 connection is by definition a Maintenance Entity. 212 Therefore, in the context of MPLS-TP LSP or PW Maintenance Entity 213 (defined below) LERs and T-PEs can be MEPs while LSRs and S-PEs can 214 be MIPs. In the case of Tandem Connection Maintenance Entity (defined 215 below), LSRs and S-PEs can be either MEPs or MIPs. 217 The following properties apply to all MPLS-TP MEs: 219 o OAM entities can be nested but not overlapped. 221 o Each OAM flow is associated to a unique Maintenance Entity. 223 o OAM packets are subject to the same forwarding treatment (e.g. 224 fate share) as the data traffic, but they can be distinguished 225 from the data traffic using the GAL and GE-ACH constructs .[9] for 226 LSP and the PW-ACH construct .[6] for (MS-)PW. 228 2.2. Maintenance End Points (MEPs) 230 Maintenance End Points (MEPs) are the end points of a pre-configured 231 (through the management or control planes) ME. MEPs are responsible 232 for activating and controlling all of the OAM functionality for the 233 ME. A MEP may initiate an OAM packet to be transferred to its 234 corresponding MEP, or to an intermediate MIP that is part of the ME. 236 A MEP terminates all the OAM packets that it receives corresponding 237 to its ME and does not forward them further along the path. 239 All OAM packets coming to a MEP source are tunnelled via label 240 stacking and are not processed within the ME as they belong either to 241 the client network layers or to an higher TCM level. 243 A MEP in a tandem connection is not coincident with the termination 244 of the MPLS-TP transport path (LSP or PW), though it can monitor its 245 connectivity (e.g. count packets). A MEP of an MPLS-TP network 246 transport path is coincident with transport path termination and 247 monitors its connectivity (e.g. count packets). 249 MPLS-TP MEP notifies a fault indication to the MPLS-TP client layer 250 network. 252 2.3. Maintenance Intermediate Points (MIPs) 254 A Maintenance Intermediate Point (MIP) is a point between the two 255 MEPs in an ME that is capable of reacting to some OAM packets and 256 forwarding all OAM packets while ensuring fate sharing with data 257 plane packets. A MIP belongs to only one ME. 259 A MIP does not initiate OAM packets, but may be addressed by OAM 260 packets initiated by one of the MEPs of the ME. A MIP can generate 261 OAM packets only in reaction to OAM packets that are sent on the ME 262 it belongs to. 264 MIPs are unaware of any OAM flows running between MEPs or between 265 MEPs and other MIPs. MIPs can only receive and process OAM packets 266 addressed to the MIP itself. 268 A MIP takes no action on the MPLS-TP transport path. 270 2.4. Server MEPs 272 A server MEP is a MEP of an ME that is defined in a layer network 273 below the MPLS-TP layer network being referenced. A server MEP 274 coincides with either a MIP or a MEP in the client (MPLS-TP) layer 275 network. 277 For example, a server MEP can be either: 279 o A termination point of a physical link (e.g. 802.3), an SDH VC or 280 OTH ODU for the MPLS-TP Section layer network, defined in section 281 .3.1. ; 283 o An MPLS-TP Section MEP for MPLS-TP LSPs, defined in section .3.2. 284 ; 285 o An MPLS-TP LSP MEP for MPLS-TP PWs, defined in section .3.4. ; 287 o An MPLS-TP TCM MEP for higher-level TCMs, defined in sections . 288 3.3. and .3.5. 290 The server MEP can run appropriate OAM functions for fault detection, 291 and notifies a fault indication to the MPLS-TP layer network. 293 3. Reference Model 295 The reference model for MPLS-TP OAM framework builds upon the concept 296 of an ME, and its associated MEPs and MIPs, to support the functional 297 requirements specified in .[10]. 299 The following MPLS-TP MEs are specified in this document: 301 o A Section Maintenance Entity (SME), allowing monitoring and 302 management of MPLS-TP Sections (between MPLS LSRs). 304 o A LSP Maintenance Entity (LME), allowing monitoring and management 305 of an end-to-end LSP (between LERs). 307 o A PW Maintenance Entity (PME), allowing monitoring and management 308 of an end-to-end SS/MS-PWs (between T-PEs). 310 o An LSP Tandem Connection Maintenance Entity (TLME), allowing 311 monitoring and management of an LSP Tandem Connection (or LSP 312 Segment) between any LER/LSR along the LSP. 314 o A MS-PW Tandem Connection Maintenance Entity (TPME), allows 315 monitoring and management of a SS/MS-PW Tandem Connection (or PW 316 Segment) between any T-PE/S-PE along the (MS-)PW. 318 The MEs specified in this MPLS-TP framework are intended to be 319 compliant with the architecture framework for MS-PWs .[7] and MPLS 320 LSPs .[2]. 322 Native |<-------------------- PW15 --------------------->| Native 323 Layer | | Layer 324 Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service 325 (AC1) V V LSP V V LSP V V LSP V V (AC2) 326 +----+ +-+ +----+ +----+ +-+ +----+ 327 +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ 328 | | | |=========| |=========| |=========| | | | 329 | CE1|--------|........PW1........|...PW3...|........PW5........|-------|CE2 | 330 | | | |=========| |=========| |=========| | | | 331 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 332 +----+ +-+ +----+ +----+ +-+ +----+ 334 |<- Subnetwork 123->| |<- Subnetwork XYZ->| 336 .------------------- PW15 PME -------------------. 337 .----- PW1 TPME ----. .---- PW5 TPME -----. 338 .---------. .---------. 339 PSN13 LME PSNXZ LME 341 .--. .--. .--------. .--. .--. 342 Sec12 SME Sec23 SME Sec3X SME SecXY SME SecYZ SME 344 TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3 345 TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z 347 .---. ME . MEP ==== LSP .... PW 349 Figure 1: Reference Model for the MPLS-TP OAM Framework 351 Figure 1 depicts a high-level reference model for the MPLS-TP OAM 352 framework. The figure depicts portions of two MPLS-TP enabled 353 subnetworks, Subnetwork 123 and Subnetwork XYZ. In Subnetwork 123, 354 LSR 1 is adjacent to LSR 2 via the MPLS Section Sec12 and LSR2 is 355 adjacent to LSR3 via the MPLS Section Sec23. Similarly, In Subnetwork 356 XYZ, LSR X is adjacent to LSR Y via the MPLS Section SecXY and LSR Y 357 is adjacent to LSR Z via the MPLS Section SecYZ. In addition, LSR 3 358 is adjacent to LSR X via the MPLS Section 3X. 360 Figure 1 also shows a bi-directional MS-PW (PW15) between AC1 on LSR 361 1 (TPE1) and AC2 on LSR Z (TPEZ). The MS-PW consists of 3 bi- 362 directional PW Segments: 1) PW Segment 1 (PW1) between LSR 1 (TPE1) 363 and LSR 3 (SPE3) via the bi-directional PSN13 LSP, 2) PW Segment 3 364 (PW3) between LSR 3 (SPE3) and LSR X (SPEX), and 3) PW Segment 5 365 (PW5) between LSR X (SPEX) and LSR Z (TPEZ) via the bi-directional 366 PSNXZ LSP. 368 The MPLS-TP OAM procedures that apply to an instance of given ME are 369 expected to operate independently from procedures on other instances 370 of the same ME and certainly of other MEs. Yet, this does not 371 preclude that multiple MEs may be affected simultaneously by the same 372 network condition, for example, a fiber cut event. 374 The subsections below define the MEs specified in this MPLS-TP OAM 375 architecture framework document. Unless otherwise stated, all 376 references to subnetworks, LSRs, MPLS Sections, LSP, pseudowires and 377 MEs in this Section are made in relation to those shown in Figure 1. 379 3.1. MPLS-TP Section Monitoring 381 An MPLS-TP Section ME (SME) is an MPLS-TP maintenance entity intended 382 to monitor the forwarding behaviour of an MPLS Section as defined in 383 .[9]. An SME may be configured on any MPLS section. SME OAM packets 384 fate share with the user data packets sent over the monitored MPLS 385 Section. 387 An SME is intended to be deployed for applications where it is 388 preferable to monitor the link between the topologically adjacent 389 MPLS (and MPLS-TP enabled) LSRs rather than monitoring the individual 390 LSP or PW segments traversing the MPLS Section. A representative 391 application is collecting link-level PM statistics at the node-to- 392 node interfaces (NNI) in MPLS-TP sub-network domains. 394 |<-------------------- PW15 --------------------->| 395 | | 396 | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | 397 V V LSP V V LSP V V LSP V V 398 +----+ +-+ +----+ +----+ +-+ +----+ 399 +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ 400 | | AC1 | |=========| |=========| |=========| | AC2 | | 401 | CE1|--------|........PW1........|...PW3...|........PW5........|-------|CE2 | 402 | | | |=========| |=========| |=========| | | | 403 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 404 +----+ +-+ +----+ +----+ +-+ +----+ 406 .--. .--. .--------. .--. .--. 407 Sec12 SME Sec23 SME Sec3X SME SecXY SME SecYZ SME 409 Figure 2: Example of MPLS-TP Section MEs (SME) 411 Figure 2 shows 5 Section MEs configured in the path between AC1 and 412 AC2: 1) Sec12 ME associated with the MPLS Section between LSR 1 and 413 LSR 2, 2) Sec23 ME associated with the MPLS Section between LSR 2 and 414 LSR 3, 3) Sec3X ME associated with the MPLS Section between LSR 3 and 415 LSR X, 4) SecXY ME associated with the MPLS Section between LSR X and 416 LSR Y, and 5) SecYZ ME associated with the MPLS Section between LSR Y 417 and LSR Z. 419 3.2. MPLS-TP LSP End-to-End Monitoring 421 An MPLS-TP LSP ME (LME) is an MPLS-TP maintenance entity intended to 422 monitor the forwarding behaviour of an end-to-end LSP between two 423 (e.g., a point-to-point LSP) or more (e.g., a point-to-multipoint 424 LSP) LERs. An LME may be configured on any MPLS LSP. LME OAM packets 425 fate share with user data packets sent over the monitored MPLS LSP. 427 An LME is intended to be deployed in scenarios where it is desirable 428 to monitor the forwarding behaviour of an entire LSP between a pair 429 of MPLS LERs, rather than, say, monitoring individual PWs. A 430 representative application is collecting PM statistics of PSN LSP 431 that is being used to provide a "tunnelling services" for a number of 432 other LSPs. 434 |<-------------------- PW15 --------------------->| 435 | | 436 | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | 437 V V LSP V V LSP V V LSP V V 438 +----+ +-+ +----+ +----+ +-+ +----+ 439 +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ 440 | | AC1 | |=========| |=========| |=========| | AC2 | | 441 | CE1|--------|........PW1........|...PW3...|........PW5........|-------|CE2 | 442 | | | |=========| |=========| |=========| | | | 443 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 444 +----+ +-+ +----+ +----+ +-+ +----+ 446 .---------. .---------. 447 PSN13 LME PSNXZ LME 449 Figure 3: Examples of MPLS-TP LSP MEs (LME) 451 Figure 3 depicts 2 LMEs configured in the path between AC1 and AC2: 452 1) the PSN13 LME between LER 1 and LER 3, and 2) the PSNXZ LME 453 between LER X and LER Y. 455 3.3. MPLS-TP LSP Tandem Connection Monitoring 457 An MPLS-TP LSP Tandem Connection Monitoring ME (TLME) is an MPLS-TP 458 maintenance entity intended to monitor the forwarding behaviour of an 459 LSP Segment between a given pair of LSRs. Multiple TLME MAY BE 460 configured on any LSP Segment. The LSR may or may not be immediately 461 adjacent at the MPLS layer. TLME OAM packets fate share with the user 462 data packets sent over the monitored LSP segment. 464 A TLME can be defined between the following entities: 466 o LER and any LSR of a given LSP. 468 o Any two LSRs of a given LSP. 470 A TLME is intended to be deployed in scenarios where it is preferable 471 to monitor the behaviour of a segment of an LSP rather than the 472 entire LSP itself. A representative application is when there is a 473 need to monitor a segment of an LSP that extends beyond the 474 administrative boundaries of an MPLS-TP enabled administrative 475 domain. 477 |<--------------------- PW15 -------------------->| 478 | | 479 | |<--------------PSN1Z LSP-------------->| | 480 | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | 481 V V S-LSP V V S-LSP V V S-LSP V V 482 +----+ +-+ +----+ +----+ +-+ +----+ 483 +----+ | PE1| | | | PB3| | PBX| | | | PEZ| +----+ 484 | | AC1 | |=======================================| | AC2 | | 485 | CE1|--------|......................PW15.......................|-------|CE2 | 486 | | | |=======================================| | | | 487 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 488 +----+ +-+ +----+ +----+ +-+ +----+ 490 .--------. .---------. 491 PSN13 TLME PSNXZ TLME 493 PB: Provider Border LSR 495 Figure 4: MPLS-TP LSP Tandem Conection Monitoring ME (TLME) 497 Figure 4 depicts a variation of the reference model in Figure 1 where 498 there is an end-to-end PSN LSP (PSN1Z LSP) between PE1 and PEZ. PSN1Z 499 LSP consists of, at least, three stitched LSP Segments: PSN13, PSN3X 500 and PSNXZ. In this scenario there are two separate TLMEs configured 501 to monitor the forwarding behaviour of the PSN1Z LSP: 1) a TLME 502 monitoring the PSN13 LSP Segment on Subnetwork 123 (PSN13 TLME), and 503 2) a TLME monitoring the PSNXZ LSP Segment on Subnetwork XYZ (PSNXZ 504 TLME). 506 3.4. MPLS-TP PW Monitoring 508 An MPLS-TP PW ME (PME) is an MPLS-TP maintenance entity intended to 509 monitor the end-to-end forwarding behaviour of a SS-PW or MS-PW 510 between a pair of T-PEs. A PME MAY be configured on any SS-PW or MS- 511 PW. PME OAM packets fate share with the user data packets sent over 512 the monitored PW. 514 A PME is intended to be deployed in scenarios where it is desirable 515 to monitor the forwarding behaviour of an entire PW between a pair of 516 MPLS-TP enabled T-PEs rather than monitoring the LSP aggregating 517 multiple PWs between PEs. A representative application is on either 518 SS-PW or MS-PW used to emulate traffic for which an SLA with QoS 519 commitments may apply (e.g., an emulated DS1/E1 or the emulated CBR 520 connection of an ATM VCC/VPC). 522 |<-------------------- PW15 --------------------->| 523 | | 524 | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | 525 V V LSP V V LSP V V LSP V V 526 +----+ +-+ +----+ +----+ +-+ +----+ 527 +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ 528 | | AC1 | |=========| |=========| |=========| | AC2 | | 529 | CE1|--------|........PW1........|...PW3...|........PW5........|-------|CE2 | 530 | | | |=========| |=========| |=========| | | | 531 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 532 +----+ +-+ +----+ +----+ +-+ +----+ 534 .---------------------PW15 PME--------------------. 536 Figure 5: MPLS-TP PW ME (PME) 538 Figure 5 depicts a MS-PW (PW15) consisting of three segments: PW1, 539 PW3 and PW5 and its associated end-to-end PME (PW15 PME). 541 3.5. MPLS-TP MS-PW Tandem Connection Monitoring 543 An MPLS-TP MS-PW Tandem Connection Monitoring ME (TPME) is an MPLS-TP 544 maintenance entity intended to monitor the forwarding behaviour of 545 one or more MS-PW segments between a given pair of PEs. Multiple 546 TPMEs MAY be configured on any sub-path of a MS-PW. The PEs may or 547 may not be immediately adjacent at the MS-PW layer. TPME OAM packets 548 fate share with the user data packets sent over the monitored MS-PW 549 Segment. 551 A TPME can be defined between the following entities: 553 o T-PE and any S-PE of a given MS-PW 555 o Any two S-PEs of a given MS-PW. It can span several PW 556 segments. 558 A TPME is intended to be deployed in scenarios where it is preferable 559 to monitor the behaviour of a segment of a MS-PW rather than the 560 entire end-to-end PW itself. A representative application is to 561 collect PM statistics for the MS-PW Segment within a given network 562 domain of an inter-domain PW. 564 |<-------------------- PW15 --------------------->| 565 | | 566 | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | 567 V V LSP V V LSP V V LSP V V 568 +----+ +-+ +----+ +----+ +-+ +----+ 569 +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ 570 | | AC1 | |=========| |=========| |=========| | AC2 | | 571 | CE1|--------|........PW1........|...PW3...|........PW5........|-------|CE2 | 572 | | | |=========| |=========| |=========| | | | 573 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 574 +----+ +-+ +----+ +----+ +-+ +----+ 576 .-----PW1 TPME------. .------PW5 TPME------. 578 Figure 6: MPLS-TP MS-PW Tandem Connection Monitoring (TPME) 580 Figure 6 depicts the same MS-PW (PW15) between AC1 and AC2 as in 581 Figure 5. In this scenario there are two separate TPMEs configured to 582 monitor the forwarding behaviour of PW15: 1) a TPME monitoring the 583 PW1 MS-PW Segment on Subnetwork 123 (PW1 TPME), and 2) a TPME 584 monitoring the PW4 MS-PW Segment on Subnetwork XYZ with (PW5 TPME). 586 4. OAM Functions for pro-active monitoring 588 4.1. Continuity Check and Connectivity Verification 590 Proactive Continuity Check (CC) and Connectivity Verification (CV) 591 function is used to detect loss of continuity (LOC), unintended 592 connectivity between two MEs (e.g. mismerging or misconnection) as 593 well as unintended connectivity within the ME with an unexpected MEP. 595 Proactive CC & CV is based upon the generation of OAM CC/CV packets, 596 carrying a unique ME identifier, at a regular configurable timing 597 rate and the detection of LOC when these packets do not arrive. If 598 the received ME identifier does not match the expected ME identifier, 599 a connectivity defect has occurred. The default CC/CV transmission 600 periods are application dependent (see section .4.1.1. ) 602 For statically provisioned connections, the transmission period and 603 the ME identifier are statically configured at both MEPs. For 604 dynamically established connections, the transmission period and the 605 ME identifier are signaled via the control plane. 607 In a bidirectional point-to-point connection, when a MEP is enabled 608 to generate CC/CV packets with a configured transmission period, it 609 also expects to receive CC/CV packets from its peer MEP with the same 610 transmission period. In a unidirectional connection (point-to-point 611 or point-to-multipoint), only the source MEP is enabled to generate 612 packets with CC/CV information. This MEP does not expect to receive 613 any packets with CC/CV information from its peer MEPs in the ME. 615 MIPs as well as intermediate nodes not supporting MPLS-TP OAM are 616 transparent to the pro-active CC/CV information and forward pro- 617 active CC/CV packets as regular data packets. 619 When CC & CV is enabled, a MEP periodically transmits CC/CV packets 620 with frequency of the configured transmission period. 622 If no CC/CV packets from a peer MEP are received within the interval 623 equal to 3.5 times the transmission period, loss of continuity (LOC) 624 defect with the peer MEP is detected. 626 When a CC/CV packet is received, a MEP is capable to detect a 627 mis-connectivity defect (e.g. mismerge or misconnection) with another 628 ME when either: 630 o It is enabled to received CC/CV packets and the received CC/CV 631 packet carries an incorrect ME identifier 633 o It is not enabled to receive CC/CV packets 635 If CC/CV packets are received with a transmission period different 636 than expected, CC/CV period mis-configuration defect is detected. 638 A receiving MEP notifies the equipment fault management process when 639 it detects the above defect conditions. 641 4.1.1. Applications for proactive CC & CV function 643 CC & CV is applicable for fault management, performance monitoring, 644 or protection switching applications. 646 o Fault Management: default transmission period is 1s (i.e. 647 transmission rate of 1 packet/second) 649 o Performance Monitoring: default transmission period is 100ms (i.e. 650 transmission rate of 10 packets/second) 652 o Protection Switching: in order to achieve sub-50ms recovery time 653 the default transmission period is 3.33ms (i.e. transmission rate 654 of 300 packets/second) although a transmission period of 10ms can 655 also be used. In some cases, when a slower recovery time is 656 acceptable, it is also possible to relax the transmission period. 658 4.2. Remote Defect Indication 660 The Remote Defect Indication (RDI) is an indicator that is 661 transmitted by a MEP to communicate to its peer MEPs that a signal 662 fail condition exists. RDI is only used for bidirectional 663 connections and is associated with proactive CC & CV packet 664 generation. 666 A MEP that has identified a signal fail related defect should include 667 the RDI in all OAM CC/CV packets that it generates for the duration 668 of the defect condition existence. A MEP that receives the packets 669 with the RDI information should determine that its peer MEP has 670 encountered a defect condition associated with a signal fail. MIPs 671 should be transparent to the RDI indicator and should forward packets 672 that include the indicator, i.e. the MIP should not perform any 673 actions nor examine the indicator. 675 When the signal condition clears, the MEP should clear the RDI 676 indicator from subsequent transmission of OAM CC/CV packets. Peer 677 MEP, that have set the RDI condition, should clear the condition upon 678 reception of a packet from the source MEP with the RDI indicator 679 cleared. 681 4.2.1. Configuration considerations 683 In order to support RDI indication, the RDI transmission rate and PHB 684 of the MEP should be configured as part of the CC & CV configuration. 686 4.2.2. Applications for Remote Defect Indication 688 RDI is applicable for the following applications: 690 o Single-ended fault management - A receiving MEP detects the RDI 691 defect condition, which when correlated with other defect 692 conditions in the receiving MEP may become a fault case. 694 o Contribution to far-end performance monitoring - The indication of 695 the far-end defect condition is used as input to the performance 696 monitoring process. 698 4.3. Alarm Suppression 700 Alarm Indication Signal function (AIS) is used to suppress alarms 701 following detection of defect conditions at the server (sub) layer. 703 o Packets with AIS information can be issued at a MEP, including a 704 Server MEP, upon detecting defect conditions. 706 A server MEP is responsible for notifying the MPLS-TP layer network 707 MEP upon fault detection in the server layer network to which the 708 server MEP is associated. 710 Only Server MEPs can issue MPLS-TP packets with AIS information. Upon 711 detection of a signal fail condition the Server MEP can immediately 712 start transmitting packets with AIS information periodically. A 713 Server MEP continues to transmit periodic packets with AIS 714 information until the signal fail condition is cleared. 716 Upon receiving a packet with AIS information a MEP detects an AIS 717 defect condition and suppresses loss of continuity alarms associated 718 with all its peer MEPs. A MEP resumes loss of continuity alarm 719 generation upon detecting loss of continuity defect conditions in the 720 absence of AIS condition. 722 Specific configuration information required by a MEP to support AIS 723 transmission is the following: 725 o PHB - identifies the per-hop behaviour of packet with AIS 726 information. 728 A MIP is transparent to packets with AIS information and therefore 729 does not require any information to support AIS functionality. 731 4.4. Lock Indication 733 To be incorporated in a future revision of this document 735 4.5. Packet Loss Measurement 737 To be incorporated in a future revision of this document 739 4.6. Client Signal Fail 741 To be incorporated in a future revision of this document 743 5. OAM Functions for on-demand monitoring 745 5.1. Continuity Check and Connectivity Verification 747 In order to preserve network resources, e.g. bandwidth, processing 748 time at switches, it may be preferable to not use continual pro- 749 active CC & CV. In order to perform fault management functions 750 network management may invoke periodic on-demand bursts of CC & CV 751 packets. Use of on-demand CC & CV is dependent on the existence of a 752 bi-directional connection ME. 754 An additional use of on-demand CC & CV would be to detect and locate 755 a problem of connectivity when a problem is suspected or known based 756 on other tools. In this case the functionality will be triggered by 757 the network management in response to a status signal or alarm 758 indication. 760 On-demand CC & CV is based upon generation of OAM CC & CV packets 761 that should uniquely identify the ME that is being checked. The on- 762 demand functionality may be used to check either an entire ME (end- 763 to-end) or between a MEP to a specific MIP. 765 On-demand CC & CV may generate a one-time burst of OAM CC/CV packets, 766 or be used to invoke periodic, non-continuous, bursts of OAM CC/CV 767 packets. The number of packets generated in each burst is 768 configurable at the MEPs, and should take into account normal packet- 769 loss conditions. 771 When invoking a periodic check of the ME, the source MEP should issue 772 a burst of OAM CC/CV packets that uniquely identifies the ME being 773 verified. The number of packets and their transmission rate should 774 be pre-configured and known to both the source MEP and the target MEP 775 or MIP. The source MEP should use the TTL field to indicate the 776 number of hops necessary, when targeting a MIP and use the default 777 value when performing an end-to-end. The target MEP/MIP shall return 778 a reply OAM CC/CV packet for each packet received. If the expected 779 number of OAM CC/CV reply packets is not received at source MEP, a 780 LOC state is detected. 782 When a connectivity problem is detected (e.g. via a pro-active CC&CV 783 OAM tool), on demand CC&CV tool can be used to check the path. The 784 series should check CC&CV from MEP to peer MEP on the path, and if a 785 fault is discovered, by lack of response, then additional checks may 786 be performed to each of the intermediate MIP to locate the fault. 788 5.1.1. Configuration considerations 790 For on-demand CC & CV the MEP should support configuration of number 791 of packets to be transmitted/received in each burst of transmissions 792 and the transmission rate should be either pre-configured or 793 negotiated between the different nodes. 795 In addition, when the CC & CV packet is checking connectivity toward 796 a target MIP, the number of hops to reach the target MIP should be 797 configured. 799 The PHB of the CC & CV packets should be configured as well. 801 5.2. Packet Loss Measurement 803 To be incorporated in a future revision of this document 805 5.3. Diagnostic Test 807 To be incorporated in a future revision of this document 809 5.4. Trace routing 811 To be incorporated in a future revision of this document 813 5.5. Packet Delay Measurement 815 To be incorporated in a future revision of this document 817 6. OAM Protocols Overview 819 To be incorporated in a future revision of this document 821 7. Security Considerations 823 To be incorporated in a future revision of this document 825 8. IANA Considerations 827 To be incorporated in a future revision of this document 829 9. Acknowledgments 831 The authors would like to thank all members of the teams (the Joint 832 Working Team, the MPLS Interoperability Design Team in IETF and the 833 T-MPLS Ad Hoc Group in ITU-T) involved in the definition and 834 specification of MPLS Transport Profile. 836 10. References 838 10.1. Normative References 840 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 841 Levels", BCP 14, RFC 2119, March 1997 843 [2] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label 844 Switching Architecture", RFC 3031, January 2001 846 [3] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032, 847 January 2001 849 [4] Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in 850 Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, 851 January 2003 853 [5] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge 854 (PWE3) Architecture", RFC 3985, March 2005 856 [6] Nadeau, T., Pignataro, S., "Pseudowire Virtual Circuit 857 Connectivity Verification (VCCV): A Control Channel for 858 Pseudowires", RFC 5085, December 2007 860 [7] Bocci, M., Bryant, S., "An Architecture for Multi-Segment 861 Pseudo Wire Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw- 862 arch-05 (work in progress), September 2008 864 [8] Bocci, M., et al., " A Framework for MPLS in Transport 865 Networks", draft-blb-mpls-tp-framework-00 (work in progress), 866 July 2008 868 [9] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R., 869 " MPLS Generic Associated Channel ", draft-bocci-mpls-tp-gach- 870 gal-00, October 2008 872 10.2. Informative References 874 [10] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in 875 MPLS Transport Networks", draft-vigoureux-mpls-tp-oam- 876 requirements-00, July 2008 878 [11] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, Y., " 879 MPLS-TP OAM Analysis", draft-sprecher-mpls-tp-oam-analysis-02 880 (work in progress), September 2008 882 [12] ITU-T Recommendation G.707/Y.1322 (01/07), " Network node 883 interface for the synchronous digital hierarchy (SDH)", 2007 885 Authors' Addresses 887 Italo Busi (Editor) 888 Alcatel-Lucent 890 Email: italo.busi@alcatel-lucent.it 892 Ben Niven-Jenkins (Editor) 893 BT 895 Email: benjamin.niven-jenkins@bt.com 897 Contributing Authors' Addresses 899 Annamaria Fulignoli 900 Ericsson 902 Email: annamaria.fulignoli@ericsson.com 904 Enrique Hernandez-Valencia 905 Alcatel-Lucent 907 Email: enrique@alcatel-lucent.com 909 Lieven Levrau 910 Alcatel-Lucent 912 Email: llevrau@alcatel-lucent.com 913 Dinesh Mohan (Editor) 914 Nortel 916 Email: mohand@nortel.com 918 Vincenzo Sestito 919 Alcatel-Lucent 921 Email: vincenzo.sestito@alcatel-lucent.it 923 Nurit Sprecher 924 Nokia Siemens Networks 926 Email: nurit.sprecher@nsn.com 928 Huub van Helvoort 929 Huawei Technologies 931 Email: hhelvoort@huawei.com 933 Martin Vigoureux 934 Alcatel-Lucent 936 Email: martin.vigoureux@alcatel-lucent.fr 938 Yaacov Weingarten 939 Nokia Siemens Networks 941 Email: yaacov.weingarten@nsn.com 943 Intellectual Property Statement 945 The IETF takes no position regarding the validity or scope of any 946 Intellectual Property Rights or other rights that might be claimed to 947 pertain to the implementation or use of the technology described in 948 this document or the extent to which any license under such rights 949 might or might not be available; nor does it represent that it has 950 made any independent effort to identify any such rights. Information 951 on the procedures with respect to rights in RFC documents can be 952 found in BCP 78 and BCP 79. 954 Copies of IPR disclosures made to the IETF Secretariat and any 955 assurances of licenses to be made available, or the result of an 956 attempt made to obtain a general license or permission for the use of 957 such proprietary rights by implementers or users of this 958 specification can be obtained from the IETF on-line IPR repository at 959 http://www.ietf.org/ipr. 961 The IETF invites any interested party to bring to its attention any 962 copyrights, patents or patent applications, or other proprietary 963 rights that may cover technology that may be required to implement 964 this standard. Please address the information to the IETF at ietf- 965 ipr@ietf.org. 967 Disclaimer of Validity 969 This document and the information contained herein are provided on an 970 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 971 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 972 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 973 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 974 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 975 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 977 Copyright Statement 979 Copyright (C) The IETF Trust (2008). 981 This document is subject to the rights, licenses and restrictions 982 contained in BCP 78, and except as set forth therein, the authors 983 retain all their rights. 985 Acknowledgment 987 Funding for the RFC Editor function is currently provided by the 988 Internet Society.