idnits 2.17.1 draft-ietf-mpls-tp-oam-framework-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([12]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 3, 2009) is 5257 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC4379' on line 1887 == Unused Reference: '3' is defined on line 2001, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 2004, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 2053, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 2067, 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 (-12) exists of draft-ietf-mpls-tp-framework-06 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-tp-identifiers-00 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-oam-requirements-03 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-tp-oam-analysis-00 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 2 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 B. Niven-Jenkins (Ed) 4 BT 5 D. Allan (Ed) 6 Ericsson 8 Expires: June 2010 December 3, 2009 10 MPLS-TP OAM Framework 11 draft-ietf-mpls-tp-oam-framework-03.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) is 47 based on a profile of the MPLS and pseudowire (PW) procedures as 48 specified in the MPLS Traffic Engineering (MPLS-TE), pseudowire (PW) 49 and multi-segment PW (MS-PW) architectures complemented with 50 additional Operations, Administration and Maintenance (OAM) 51 procedures for fault, performance and protection-switching management 52 for packet transport applications that do not rely on the presence of 53 a control plane. 55 This document describes a framework to support a comprehensive set of 56 OAM procedures that fulfills the MPLS-TP OAM requirements [12]. 58 This document is a product of a joint Internet Engineering Task Force 59 (IETF) / International Telecommunications Union Telecommunications 60 Standardization Sector (ITU-T) effort to include an MPLS Transport 61 Profile within the IETF MPLS and PWE3 architectures to support the 62 capabilities and functionalities of a packet transport network. 64 Table of Contents 66 1. Introduction..................................................5 67 1.1. Contributing Authors.....................................5 68 1.2. Editors Issues...........................................6 69 2. Conventions used in this document.............................8 70 2.1. Terminology..............................................8 71 2.2. Definitions..............................................9 72 3. Functional Components........................................11 73 3.1. Maintenance Entity and Maintenance Entity Group.........12 74 3.2. MEG End Points (MEPs)...................................15 75 3.3. MEG Intermediate Points (MIPs)..........................18 76 3.4. Server MEPs.............................................19 77 3.5. Path Segment Tunnels and Tandem Connection Monitoring...20 78 4. Reference Model..............................................20 79 4.1. MPLS-TP Section Monitoring..............................22 80 4.2. MPLS-TP LSP End-to-End Monitoring.......................23 81 4.3. MPLS-TP LSP Path Segment Tunnel Monitoring..............24 82 4.4. MPLS-TP PW Monitoring...................................26 83 4.5. MPLS-TP MS-PW Path Segment Tunnel Monitoring............26 84 5. OAM Functions for proactive monitoring.......................27 85 5.1. Continuity Check and Connectivity Verification..........28 86 5.1.1. Defects identified by CC-V.........................29 87 5.1.2. Consequent action..................................30 88 5.1.3. Configuration considerations.......................31 89 5.1.4. Applications for proactive CC-V....................32 90 5.2. Remote Defect Indication................................33 91 5.2.1. Configuration considerations.......................33 92 5.2.2. Applications for Remote Defect Indication..........34 93 5.3. Alarm Reporting.........................................34 94 5.4. Lock Reporting..........................................35 95 5.5. Packet Loss Monitoring..................................35 96 5.5.1. Configuration considerations.......................36 97 5.5.2. Applications for Packet Loss Monitoring............36 98 5.6. Client Signal Failure Indication........................37 99 5.6.1. Configuration considerations.......................37 100 5.6.2. Applications for Client Signal Failure Indication..37 101 5.7. Delay Measurement.......................................38 102 5.7.1. Configuration considerations.......................38 103 5.7.2. Applications for Delay Measurement.................39 104 6. OAM Functions for on-demand monitoring.......................39 105 6.1. Connectivity Verification...............................39 106 6.1.1. Configuration considerations.......................40 107 6.2. Packet Loss Monitoring..................................41 108 6.2.1. Configuration considerations.......................41 109 6.2.2. Applications for On-demand Packet Loss Monitoring..41 110 6.3. Diagnostic..............................................41 111 6.4. Route Tracing...........................................42 112 6.5. Delay Measurement.......................................43 113 6.5.1. Configuration considerations.......................43 114 6.5.2. Applications for Delay Measurement.................44 115 6.6. Lock Instruct...........................................44 116 7. Security Considerations......................................44 117 8. IANA Considerations..........................................44 118 9. Acknowledgments..............................................45 119 10. References..................................................46 120 10.1. Normative References...................................46 121 10.2. Informative References.................................46 123 Editors' Note: 125 This Informational Internet-Draft is aimed at achieving IETF 126 Consensus before publication as an RFC and will be subject to an IETF 127 Last Call. 129 [RFC Editor, please remove this note before publication as an RFC and 130 insert the correct Streams Boilerplate to indicate that the published 131 RFC has IETF Consensus.] 133 1. Introduction 135 As noted in [8], MPLS-TP defines a profile of the MPLS-TE and (MS-)PW 136 architectures defined in RFC 3031 [2], RFC 3985 [5] and [7] which is 137 complemented with additional OAM mechanisms and procedures for alarm, 138 fault, performance and protection-switching management for packet 139 transport applications. 141 In line with [13], existing MPLS OAM mechanisms will be used wherever 142 possible and extensions or new OAM mechanisms will be defined only 143 where existing mechanisms are not sufficient to meet the 144 requirements. 146 The MPLS-TP OAM framework defined in this document provides a 147 comprehensive set of OAM procedures that satisfy the MPLS-TP OAM 148 requirements [12]. In this regard, it defines similar OAM 149 functionality as for existing SONET/SDH and OTN OAM mechanisms (e.g. 150 [16]). 152 The MPLS-TP OAM framework is applicable to both LSPs and (MS-)PWs and 153 supports co-routed and bidirectional p2p transport paths as well as 154 unidirectional p2p and p2mp transport paths. 156 This document is a product of a joint Internet Engineering Task Force 157 (IETF) / International Telecommunications Union Telecommunications 158 Standardization Sector (ITU-T) effort to include an MPLS Transport 159 Profile within the IETF MPLS and PWE3 architectures to support the 160 capabilities and functionalities of a packet transport network. 162 1.1. Contributing Authors 164 Dave Allan, Italo Busi, Ben Niven-Jenkins, Annamaria Fulignoli, 165 Enrique Hernandez-Valencia, Lieven Levrau, Dinesh Mohan, Vincenzo 166 Sestito, Nurit Sprecher, Huub van Helvoort, Martin Vigoureux, Yaacov 167 Weingarten, Rolf Winter 169 1.2. Editors Issues 171 Editor's Note: 173 This section is to be removed prior to submission to the RFC editor. 175 1) ME architecture needs further discussion/clarification 177 Agreement (call 24 November): 179 o Co-routed bidirectional p2p transport entity: one bidirectional 180 ME 182 o Associated bidirectional p2p transport entity: two 183 unidirectional MEs 185 o Unidirectional p2p transport entity: one unidirectional ME 187 o Unidirectional p2mp (with N leaves) transport entity: N 188 unidirectional ME 190 Clarify that in a p2mp transport entity all the traffic (including 191 OAM packets) is sent (multicast) from the root to all the leaves. As 192 a consequence: 194 o To send an OAM packet to all leaves, it is required to send a 195 single OAM packet that will be delivered by the forwarding plane 196 to all the leaves and processed by all the leaves. 198 o To send an OAM packet to a single leaf, it is required to send a 199 single OAM packet that will be delivered by the forwarding plane 200 to all the leaves and processed only by the target leaf and 201 ignored by the other leaves. 203 o In order to send an OAM packet to M leaves (i.e., a subset of 204 all the leaves), the current working assumption is to send M 205 different (multicast) OAM packets targeted to each individual 206 leaf in the group of M leaves. Better mechanisms are under 207 investigation and might be added in future versions of this 208 draft. 210 2) Use of terms LTCME and PTCME, should these be genericised for 211 PSTs. 213 Agreement (call 24 November): the editors of the framework document 214 will make sure that the framework document is aligned with the 215 decision to use the term PST. This document will be aligned with this 216 decision. 218 3) CV refers to using an ME ID for misbranching detection. This does 219 not align with p2mp LSPs where a CV would then be required to 220 carry all the MEs in the MEG. 222 Agreement (call 24 November): we are going to use the term MEG ID in 223 the document. ME ID has been used in older versions of the document 224 and its use is legacy. 226 For pro-active CC-V (both p2p and p2mp), the globally unique MEP ID 227 information needs to be carried: section on pro-active CC-V needs to 228 be updated accordingly. 230 4) Discussions of PW monitoring and PW tandem connection monitoring 231 seem to be rendered out of scope by the layering decision at 232 Hiroshima. 234 Discussion points (call 24 November) - No agreement reached on this 235 issue 237 PW OAM architecture: based on the architecture defined in this 238 document using MEP and MIPs 240 PW TCM concept: just a specific application of the architecture of 241 the TP-LSP (1:1 mapped with the monitored PW) carrying a PW segment 242 in the MS-PW architecture. 244 Generic clarifications (to be added) [terminology based on RFC 5654]: 246 o before a TCM is setup, we can have a concatenated LSP 247 segment. After the TCM (that is a TP-LSP) is setup, we have a 248 single LSP segment between the TCM end-points; 250 o before a TCM is setup, we can have a concatenated PW segment. 251 After the TCM (that is a TP-LSP) is setup, we have a single 252 PW segment between the TCM end-points. 254 Problems with PW TCM are the implications of removing S-PEs from the 255 PW path. Need further discussion. It is not obvious to Dave that 256 removing an LSR from a path can be done hitlessly either ... by 257 slipping a PST under it ... 259 Action (Italo): check which requirements cannot be met if PW TCM 260 between non-adjacent PEs cannot be supported and whether this is a 261 showstopper issue or not. 263 Action (Italo): describe the PW TCM as an LSP and circulate the 264 description to the mailing list for review. If needed, another call 265 will be setup to finalize the discussion. 267 5) Concerns have been raised against the idea of having MIPs capable 268 to generate spontaneous messages. AIS/Lock Indication packets are 269 generated by the adaptation functions. This point needs 270 clarifying. 272 6) Presence or absence of MIPs is a bizarre point. At least one MIP 273 in every node is addressed by TTL, and gaps in the enablement of 274 MIPs would produce spurious test results. A convention of "MIPs 275 exist at any node on a transport path that has a return path to a 276 source MEP" would make sense vs. discussing manual 277 enable/disable/configuration of MIPs. 279 Note - the annotated text ("If the set of MIPs is actually sparse 280 (i.e. not every hop is a MIP), then it has to be intermediate nodes 281 to do some operations") needs further clarification. 283 7) Discussions in Hiroshima and subsequent calls have suggested use 284 of alternative return paths "if available", not all of which will 285 be GAL/GACH encapsulated? This point needs clarifying. 287 8) Data plane loopback 289 Action (17 November): check on the mailing list (both ITU-T and IETF 290 to get inputs from both types of operators). 292 9) Review the draft to check that all the known implications related 293 to the support of p2mp transport paths have been described. 295 10)Given layering discussion in Hiroshima, it is not very clear 296 whether MPLS TP is a sub layer network within the MPLS layer 297 network or a layer network by its own. This issue should be 298 resolved in the context of the MPLS TP Framework draft but has 299 impacts on this draft as well. 301 2. Conventions used in this document 303 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 304 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 305 document are to be interpreted as described in RFC-2119 [1]. 307 2.1. Terminology 309 AC Attachment Circuit 310 DBN Domain Border Node 312 FDI Forward Defect Indication 314 LER Label Edge Router 316 LME LSP Maintenance Entity 318 LSP Label Switched Path 320 LSR Label Switch Router 322 LPSTME LSP packet segment tunnel ME 324 ME Maintenance Entity 326 MEG Maintenance Entity Group 328 MEP Maintenance Entity Group End Point 330 MIP Maintenance Entity Group Intermediate Point 332 PHB Per-hop Behavior 334 PME PW Maintenance Entity 336 PPSTME PW path segment tunnel ME 338 PST Path Segment Tunnel 340 PSN Packet Switched Network 342 PW Pseudowire 344 SLA Service Level Agreement 346 SME Section Maintenance Entity 348 2.2. Definitions 350 Note - the definitions in this section are intended to be in line 351 with ITU-T recommendation Y.1731 in order to have a common, 352 unambiguous terminology. They do not however intend to imply a 353 certain implementation but rather serve as a framework to describe 354 the necessary OAM functions for MPLS-TP. 356 Domain Border Node (DBN): An LSP intermediate MPLS-TP node (LSR) that 357 is at the boundary of an MPLS-TP OAM domain. Such a node may be 358 present on the edge of two domains or may be connected by a link to 359 an MPLS-TP node in another OAM domain. 361 Maintenance Entity (ME): Some portion of a transport path that 362 requires management bounded by two points, and the relationship 363 between those points to which maintenance and monitoring operations 364 apply (details in section 3.1). 366 Maintenance Entity Group (MEG): The set of one or more maintenance 367 entities that maintain and monitor a transport path in an OAM domain. 369 MEP: A MEG end point (MEP) is capable of initiating (MEP Source) and 370 terminating (MEP Sink) OAM messages for fault management and 371 performance monitoring. MEPs reside at the boundaries of an ME 372 (details in section 3.2). 374 MEP Source: A MEP acts as MEP source for an OAM message when it 375 originates and inserts the message into the transport path for its 376 associated MEG. 378 MEP Sink: A MEP acts as a MEP sink for an OAM message when it 379 terminates and processes the messages received from its associated 380 MEG. 382 MIP: A MEG intermediate point (MIP) terminates and processes OAM 383 messages and may generate OAM messages in reaction to received OAM 384 messages. It never generates unsolicited OAM messages itself. A MIP 385 resides within an MEG between MEPs (details in section 3.2). 387 OAM domain: A domain, as defined in [11], whose entities are grouped 388 for the purpose of keeping the OAM confined within that domain. 390 Note - within the rest of this document the term "domain" is used to 391 indicate an "OAM domain" 393 OAM flow: Is the set of all OAM messages originating with a specific 394 MEP that instrument one direction of a MEG. 396 OAM information element: An atomic piece of information exchanged 397 between MEPs in MEG used by an OAM application. 399 OAM Message: One or more OAM information elements that when exchanged 400 between MEPs or between MEPs and MIPs performs some OAM functionality 401 (e.g. connectivity verification) 402 OAM Packet: A packet that carries one or more OAM messages (i.e. OAM 403 information elements). 405 Path: See Transport Path 407 Signal Fail: A condition declared by a MEP when the data forwarding 408 capability associated with a transport path has failed, e.g. loss of 409 continuity. 411 Tandem Connection: A tandem connection is an arbitrary part of a 412 transport path that can be monitored (via OAM) independent of the 413 end-to-end monitoring (OAM). The tandem connection may also include 414 the forwarding engine(s) of the node(s) at the boundaries of the 415 tandem connection. 417 This document uses the terms defined in RFC 5654 [11]. 419 This document uses the term 'Per-hop Behavior' as defined in [14]. 421 3. Functional Components 423 MPLS-TP defines a profile of the MPLS and PW architectures ([2], [5] 424 and [7]) that is designed to transport service traffic where the 425 characteristics of information transfer between the transport path 426 endpoints can be demonstrated to comply with certain performance and 427 quality guarantees. In order to verify and maintain these performance 428 and quality guarantees, there is a need to not only apply OAM 429 functionality on a transport path granularity (e.g. LSP or MS-PW), 430 but also on arbitrary parts of transport paths, defined as Tandem 431 Connections, between any two arbitrary points along a path. 433 In order to describe the required OAM functionality, this document 434 introduces a set of high-level functional components. [Note - 435 discussion in Munich -tues concluded that TCM not possible with PWs - 436 can monitor a single PW segment - but attempting to monitor more than 437 one segment converts the PW into an LSP and therefore the intervening 438 SPEs are unable to see the PW as a PW due to the differences in how 439 OAM flows are disambiguated.] [editors: if true this IMO is a huge 440 problem as the one place I would really want TCM is a multi-domain 441 MS-PW, else I have to control plane peer at two layers, pending 442 resolution of discussion item 4 in section 1.2] 444 When a control plane is not present, the management plane configures 445 these functional components. Otherwise they can be configured either 446 by the management plane or by the control plane. 448 These functional components should be instantiated when the path is 449 created by either the management plane or by the control plane (if 450 present). Some components may be instantiated after the path is 451 initially created (e.g. PST). 453 [Dave: are we discussing the same issue for LSP PSTs as for PWs, an 454 S-PE cannot easily be removed, certainly not hitlessly, how is an LSP 455 different?] 457 3.1. Maintenance Entity and Maintenance Entity Group 459 MPLS-TP OAM operates in the context of Maintenance Entities (MEs) 460 that are a relationship between two points of a point to point 461 transport path or a root and a leaf of a point to multipoint 462 transport path to which maintenance and monitoring operations apply. 463 These two points are called Maintenance Entity Group (MEG) End Points 464 (MEPs). In between these two points zero or more intermediate points, 465 called Maintenance Entity Group Intermediate Points (MIPs), MAY exist 466 and can be shared by more than one ME in a MEG. 468 The MEPs that form an MEG are configured and managed to limit the 469 scope of an OAM flow within the MEG that the MEPs belong to (i.e. 470 within the domain of the transport path or segment, in the specific 471 sub-layer of the MPLS layer network, that is being monitored and 472 managed). A misbranching fault may cause OAM packets to be delivered 473 to a MEP that is not in the MEG of origin. 475 The abstract reference model for an ME with MEPs and MIPs is 476 described in Figure 1 below: 478 +-+ +-+ +-+ +-+ 479 |A|----|B|----|C|----|D| 480 +-+ +-+ +-+ +-+ 482 Figure 1 ME Abstract Reference Model 484 The instantiation of this abstract model to different MPLS-TP 485 entities is described in section 4. In this model, nodes A, B, C and 486 D can be LER/LSR for an LSP or the {S|T}-PEs for a MS-PW. MEPs reside 487 in nodes A and D while MIPs reside in nodes B and C. The links 488 connecting adjacent nodes can be physical links, or sub-layer 489 LSPs/PSTs. 491 This functional model defines the relationships between all OAM 492 entities from a maintenance perspective, to allow each Maintenance 493 Entity to monitor and manage the layer network under its 494 responsibility and to localize problems efficiently. 496 [Editor's note - MEG are sub-layers. Need to check the document for 497 consistency with this agreement] 499 An MPLS-TP maintenance entity group can cover either the whole end- 500 to-end path or a path segment tunnel supporting some portion of the 501 transport path. A Maintenance Entity Group may be defined to monitor 502 the transport path for fault and/or performance management. 504 In case of associated bi-directional paths, two independent 505 Maintenance Entities are defined to independently monitor each 506 direction. This has implications for transactions that terminate at 507 or query a MIP as a return path from MIP to source MEP does not exist 508 in a unidirectional ME. 510 The following properties apply to all MPLS-TP MEGs: 512 o They can be nested but not overlapped, e.g. an MEG may cover a 513 segment or a concatenated segment of another MEG, and may also 514 include the forwarding engine(s) of the node(s) at the edge(s) of 515 the segment or concatenated segment, but all its MEPs and MIPs are 516 no longer part of the encompassing MEG. It is possible that MEPs 517 of nested MEGs reside on a single node. 519 o Each OAM flow is associated with a single Maintenance Entity 520 Group. 522 o OAM packets that instrument a particular direction of an LSP are 523 subject to the same forwarding treatment (i.e. fate share) as the 524 data traffic and in some cases may be required to have common 525 queuing discipline E2E with the class of traffic monitored. OAM 526 packets can be distinguished from the data traffic using the GAL 527 and ACH constructs [9] for LSP and Section or the ACH construct 528 [6]and [9] for (MS-)PW. 530 [Editor's note: A key point in the definition of an ME is the end- 531 points are defined by location of the logical function MEP 533 Later in the framework we will discuss the precision with which we 534 can identify the location of a MEP/MIP i.e, ingress i/f, egress i/f 535 or node. 537 We need to distinguish between the point of interception of an OAM 538 msg and the point where the action takes place. 540 Action: look at the text in the framework document regarding the 541 location of the functional components (MEPs and MIPs).] 543 [Editors' note: Somewhere we need to distinguish between the OAM 544 control function and the OAM measurement function. i.e. we set up a 545 loop back (a control function, in which case the OAM message may be 546 intercepted and actioned anywhere convenient), and the measurement 547 function (i.e. looping the packet to determine that it reached a 548 particular part of the network) which needs to be actioned at a 549 precisely know and stipulated point in the network/equipment. 551 Action (Dave) - add some text on the subject.] 553 Note that not all functionality / processing of an OAM pkt needs to 554 take place at the point of measurement. [editors: this comment is not 555 clear. For discussion during revision call] 557 [Editors' note - Address this comment while addressing the control 558 and measurement issue above. 560 We considered that an OAM function can be decomposed into the 561 following components 563 - Instruction or command 565 - Execution 567 - Addressing (node, interface etc) is ttl/LSP enough - do we need 568 sub-addressing to cause execution on a specific component in the 569 node - i.e. egress interface 571 - Response via OAM 573 - Reporting to mgt interface] 575 [Editor's note: the MPLS-TP framework will describe how it is 576 possible to inject OAM packets on intermediate nodes. We need to 577 describe how this capability is used within the OAM framework and to 578 reference to the MPLS-TP framework for the description of this 579 capability] 581 Another OAM construct is referred to as Maintenance Entity Group, 582 which is a collection of one or more MEs that belongs to the same 583 transport path and that are maintained and monitored as a group. 585 A use case for an MEG with more than one ME is point-to-multipoint 586 OAM. The reference model for the p2mp MEG is represented in Figure 2. 588 +-+ 589 /--|D| 590 / +-+ 591 +-+ 592 /--|C| 593 +-+ +-+/ +-+\ +-+ 594 |A|----|B| \--|E| 595 +-+ +-+\ +-+ +-+ 596 \--|F| 597 +-+ 599 Figure 2 Reference Model for p2mp MEG 601 In case of p2mp transport paths, the OAM operations are independent 602 for each ME (A-D, A-E and A-F): 604 o Fault conditions - some faults may impact more than one ME 605 depending from where the failure is located 607 o Packet loss - packet dropping may impact more than one ME 608 depending from where the packets are lost 610 o Packet delay - depending on different paths 612 Each leaf (i.e. D, E and F) terminates OAM flows to monitor the ME 613 from itself and the root while the root (i.e. A) generates OAM 614 messages common to all the MEs of the p2mp MEG. Nodes B and C MAY 615 implement a MIP in the corresponding MEG. 617 3.2. MEG End Points (MEPs) 619 MEG End Points (MEPs) are the source and sink points of an MEG. In 620 the context of an MPLS-TP LSP, only LERs can implement MEPs while in 621 the context of a path segment tunnel (PST) both LERs and LSRs can 622 implement MEPs that contribute to the overall monitoring 623 infrastructure for the transport path. Regarding MPLS-TP PW, only T- 624 PEs can implement MEPs while for PSTs supporting a PW both T-PEs and 625 S-PEs can implement MEPs. In the context of MPLS-TP Section, any 626 MPLS-TP NE can implement a MEP. 628 [Munich: See note about PW Tandem monitoring earlier, and whether a 629 PW can be a tandem connection - for further discussion (discussion 630 point 4 in section 1.2)] 632 MEPs are responsible for activating and controlling all of the OAM 633 functionality for the MEG. A MEP is capable of originating and 634 terminating OAM messages for fault management and performance 635 monitoring. These OAM messages are encapsulated into an OAM packet 636 using the G-ACh as defined in RFC 5586 [9]: in this case the G-ACh 637 message is an OAM message and the channel type indicates an OAM 638 message. A MEP terminates all the OAM packets it receives from the 639 MEG it belongs to. The MEG the OAM packet belongs to is inferred from 640 the MPLS or PW label.[Editors: given the discussion about alternative 641 return paths, is a GAL/GaCH always present ...?. For discussion on 642 the IETF review calls] 644 Once an MEG is configured, the operator can configure which OAM 645 functions to use on the MEG but the MEPs are always enabled. A node 646 at the edge of an MEG always supports a MEP. 648 MEPs terminate all OAM packets received from the associated transport 649 path or path segment tunnel [Editors: the PST definition in the 650 framework should be augmented to clarity that the clients of a PST 651 should always be LSPs or PWs]. As the MEP corresponds to the 652 termination of the forwarding path for an MEG at the given sub-level, 653 OAM packets never "leaks" outside of a MEG in a fault free 654 implementation. 656 A MEP of an MPLS-TP transport path (Section, LSP or PW) coincides 657 with transport path termination and monitors it for failures or 658 performance degradation (e.g. based on packet counts) in an end-to- 659 end scope. Note that both MEP source and MEP sink coincide with 660 transport paths' source and sink terminations. 662 The MEPs of a path segment tunnel are not necessarily coincident with 663 the termination of the MPLS-TP transport path (LSP or PW) and monitor 664 some portion of the transport path for failures or performance 665 degradation (e.g. based on packet counts) only within the boundary of 666 the MEG for the path segment tunnel. 668 An MPLS-TP MEP sink passes a fault indication to its client 669 (sub-)layer network as a consequent action of fault detection. 671 It may occur that the MEPs of a path segment tunnel are set on both 672 sides of the forwarding engine such that the MEG is entirely internal 673 to the node. 675 Note that a MEP can only exist at the beginning and end of a 676 sub-layer i.e. an LSP or PW. If we need to monitor some portion of 677 that LSP or PW [editor: mention of PW in this context needs to be 678 revised after agreement on discussion point 4 in section 1.2], a new 679 sub-layer in the form of a path segment tunnel MUST be created which 680 permits MEPs and an associated MEG to be created. 682 [Editor: We need to describe the migration process for adding a path 683 segment tunnel.] 685 [Editor's note: Update the draft to capture the agreements below 686 after the discussion points 5, 6 and 7 in section 1.2 are resolved 687 (to maintain consistency): 689 We have the case of a MIP sending msg to a MEP. To do this it uses 690 the LSP label - i.e. the top label of the stack at that point. 691 [editors: move and clarify in section 3.3 - for further discuss. 693 If the set of MIPs is actually sparse (i.e. not every hop is a MIP), 694 then it has to be intermediate nodes to do some operations.] 696 Agreement (10 November): An intermediate node can send an OAM packet. 698 Clarify that we need to provide enough bandwidth on the transport 699 paths to support OAM traffic (throughout the framework document). 701 From IETF point of view no distinction between MIPs and adaptation 702 functions. 704 Lou question about how triggered response OAM packets are sent by 705 MIPs/MEPs. 707 Agreement (call 17 November): 709 o bidirectional co-routed: MUST support and SHOULD use the 710 reverse path. It MAY use any other available return path if 711 requested by the OAM message triggering the reply. Clarify 712 that using the reverse path checks both forward and backward 713 directions while other return paths check only the forward 714 direction. 716 o unidirectional p2p and p2mp: no ability to support triggered 717 response OAM message unless other return paths are available 719 o associated bidirectional: MEPs like co-routed; MIPs like 720 unidirectional 722 Agreement (call 17 November) to use as a working assumption the same 723 MEP/MIP model in MS-PW OAM architecture. In order to validate this 724 working assumption we need to understand how to describe the PW 725 Status information: this information is propagated on a hop-by-hop 726 basis between adjacent PEs using LDP (dynamic PW segments) or ACH 727 Status PW (static PW segments).] 729 3.3. MEG Intermediate Points (MIPs) 731 A MEG Intermediate Point (MIP) is a point between the MEPs of an MEG. 733 A MIP is capable of reacting to some OAM packets and forwarding all 734 the other OAM packets while ensuring fate sharing with data plane 735 packets. However, a MIP does not initiate [unsolicited OAM - editors: 736 this text was removed in the commented .rtf document from Munich but 737 not tracked as a revision, validate this change after MIP/MEP 738 discussion (discussion point 5 in section 1.2)] packets, but may be 739 addressed by OAM packets initiated by one of the MEPs of the MEG. A 740 MIP can generate OAM packets only in response to OAM packets that are 741 sent on the MEG it belongs to. 743 An intermediate node within a point-to-point MEG can either: 745 o not support MPLS-TP OAM (i.e. no MIPs per node) 747 o support per-node MIP (i.e. a single MIP per node) 749 o support per-interface MIP (i.e. two MIPs per node on both sides of 750 the forwarding engine) 752 [Editor's note - Need to describe MIPs for p2mp MEGs] 754 [Editor's note - Add a Figure to describe how the two options can be 755 support] 757 A node at the edge of an MEG can also support a MEP and a 758 per-interface MIP at the two sides of the forwarding engine. 760 When sending an OAM packet to a MIP, the source MEP should set the 761 TTL field to indicate the number of hops necessary to reach the node 762 where the MIP resides. It is always assumed that the "pipe"/"short 763 pipe" model of TTL handling is used by the MPLS transport profile. 765 The source MEP should also include Target MIP information in the OAM 766 packets sent to a MIP to allow proper identification of the MIP 767 within the node. The MEG the OAM packet is associated with is 768 inferred from the MPLS label. 770 Once an MEG is configured, the operator can enable/disable the MIPs 771 on the nodes within the MEG. [Editors': review this paragraph after 772 discussion point 6 in section 1.2 is resolved] 774 3.4. Server MEPs 776 A server MEP is a MEP of an MEG that is either: 778 o defined in a layer network that is "below", which is to say 779 encapsulates and transports the MPLS-TP layer network being 780 referenced, or 782 o defined in a sub-layer of the MPLS-TP layer network that is 783 "below" which is to say encapsulates and transports the sub-layer 784 being referenced. 786 A server MEP can coincide with a MIP or a MEP in the client (MPLS-TP) 787 layer network. 789 [Editors' note: review the text above pending discussion of whether 790 MPLS-TP is a sub-layer network within the MPLS layer network or a 791 layer network by its own (discussion point 10 in section 1.2)] 793 A server MEP also interacts with the client/server adaptation 794 function between the client (MPLS-TP) (sub-)layer network and the 795 server (sub-)layer network. The adaptation function maintains state 796 on the mapping of MPLS-TP transport paths that are setup over that 797 server layer's transport path. 799 For example, a server MEP can be either: 801 o A termination point of a physical link (e.g. 802.3), an SDH VC or 802 OTN ODU, for the MPLS-TP Section layer network, defined in section 803 4.1; 805 o An MPLS-TP Section MEP for MPLS-TP LSPs, defined in section 4.2; 807 o An MPLS-TP LSP MEP for MPLS-TP PWs, defined in section 4.4; 809 o An MPLS-TP PST MEP for higher-level PSTs, defined in section 4.3; 811 o An MPLS-TP PW Tandem Connection MEP for higher-level PTCMEs, 812 defined in section 4.5. [Editor: update this bullet after the 813 discussion on PW TCM (discussion point 4 in section 1.2)] 815 The server MEP can run appropriate OAM functions for fault detection 816 within the server (sub-)layer network, and provides a fault 817 indication to its client MPLS-TP layer network. Server MEP OAM 818 functions are outside the scope of this document. 820 3.5. Path Segment Tunnels and Tandem Connection Monitoring 822 Path segment tunnels (PSTs) are instantiated to provide monitoring of 823 a portion of a set of co-routed transport paths. Path segment tunnels 824 can also be employed to meet the requirement to provide tandem 825 connection monitoring (TCM). 827 TCM for a given portion of a transport path is implemented by first 828 creating a path segment tunnel that that has a 1:1 association with 829 portion of the transport path that is to be uniquely monitored. This 830 means there is direct correlation between all FM and PM information 831 gathered for the PST AND the monitored portion of the E2E path. The 832 PST is monitored using normal LSP monitoring. 834 There are a number of implications to this approach: 836 1) The PST would use the uniform model of EXP code point copying 837 between sub-layers for diffserv such that the E2E markings and 838 PHB treatment for the transport path was preserved by the PST. 840 2) The PST would use the pipe model for TTL handling such that MIP 841 addressing for the E2E entity would be not be impacted by the 842 presence of the PST. 844 3) PM statistics need to be adjusted for the encapsulation overhead 845 of the additional PST sub-layer. 847 4. Reference Model 849 The reference model for the MPLS-TP framework builds upon the concept 850 of an MEG, and its associated MEPs and MIPs, to support the 851 functional requirements specified in [12]. 853 The following MPLS-TP MEGs are specified in this document: 855 o A Section Maintenance Entity Group (SME), allowing monitoring and 856 management of MPLS-TP Sections (between MPLS LSRs). 858 o A LSP Maintenance Entity Group (LME), allowing monitoring and 859 management of an end-to-end LSP (between LERs). 861 o A PW Maintenance Entity Group (PME), allowing monitoring and 862 management of an end-to-end SS/MS-PWs (between T-PEs). 864 o A PST Maintenance Entity Group (PSTME), allowing monitoring and 865 management of a path segment tunnel (between any LERs/LSRs along 866 an LSP). 868 o A MS-PW Tandem Connection Maintenance Entity (PTCME), allowing 869 monitoring and management of a PW Tandem Connection (between any 870 T-PEs/S-PEs along the (MS-)PW) [Editors': update this bullet after 871 resolution of PW TCM discussion (discussion point 4 in section 872 1.2] 874 The MEGs specified in this MPLS-TP framework are compliant with the 875 architecture framework for MPLS-TP MS-PWs [7] and LSPs [2]. 877 Hierarchical LSPs are also supported in the form of path segment 878 tunnels. In this case, each LSP Tunnel in the hierarchy is a 879 different sub-layer network that can be monitored, independently from 880 higher and lower level LSP tunnels in the hierarchy, on an end-to-end 881 basis (from LER to LER) by a PSTME. It is possible to monitor a 882 portion of a hierarchical LSP by instantiating a hierarchical PSTME 883 between any LERs/LSRs along the hierarchical LSP. 885 Native |<------------------- MS-PW1Z ------------------->| Native 886 Layer | | Layer 887 Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service 888 (AC1) V V LSP V V LSP V V LSP V V (AC2) 889 +----+ +-+ +----+ +----+ +-+ +----+ 890 +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ 891 | | | |=========| |=========| |=========| | | | 892 | CE1|---|........PW13.......|...PW3X..|........PWXZ.......|---|CE2 | 893 | | | |=========| |=========| |=========| | | | 894 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 895 +----+ +-+ +----+ +----+ +-+ +----+ 896 . . . . 897 | | | | 898 |<---- Domain 1 --->| |<---- Domain Z --->| 899 ^------------------- PW1Z PME -------------------^ 900 ^---- PW13 PPSTME---^ ^---- PWXZ PPSTME---^ 901 ^---------^ ^---------^ 902 PSN13 LME PSNXZ LME 904 ^---^ ^---^ ^---------^ ^---^ ^---^ 905 Sec12 Sec23 Sec3X SecXY SecYZ 906 SME SME SME SME SME 908 TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3 909 TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z 911 ^---^ ME ^ MEP ==== LSP .... PW 913 Figure 3 Reference Model for the MPLS-TP OAM Framework 915 Figure 3 depicts a high-level reference model for the MPLS-TP OAM 916 framework. The figure depicts portions of two MPLS-TP enabled network 917 domains, Domain 1 and Domain Z. In Domain 1, LSR1 is adjacent to LSR2 918 via the MPLS Section Sec12 and LSR2 is adjacent to LSR3 via the MPLS 919 Section Sec23. Similarly, in Domain Z, LSRX is adjacent to LSRY via 920 the MPLS Section SecXY and LSRY is adjacent to LSRZ via the MPLS 921 Section SecYZ. In addition, LSR3 is adjacent to LSRX via the MPLS 922 Section 3X. 924 Figure 3 also shows a bi-directional MS-PW (PW1Z) between AC1 on TPE1 925 and AC2 on TPEZ. The MS-PW consists of three bi-directional PW 926 Segments: 1) PW13 segment between T-PE1 and S-PE3 via the bi- 927 directional PSN13 LSP, 2) PW3X segment between S-PE3 and S-PEX, via 928 the bi-directional PSN3X LSP, and 3) PWXZ segment between S-PEX and 929 T-PEZ via the bi-directional PSNXZ LSP. 931 The MPLS-TP OAM procedures that apply to an MEG of a given transport 932 path are expected to operate independently from procedures on other 933 MEGs of the same transport path and certainly MEGs of other transport 934 paths. Yet, this does not preclude that multiple MEGs may be affected 935 simultaneously by the same network condition, for example, a fiber 936 cut event. 938 Note that there are no constrains imposed by this OAM framework on 939 the number, or type (p2p, p2mp, LSP or PW), of MEGs that may be 940 instantiated on a particular node. In particular, when looking at 941 Figure 3, it should be possible to configure one or more MEPs on the 942 same node if that node is the endpoint of one or more MEGs. 944 Figure 3 does not describe a PW3X PPSTME because typically PSTs are 945 used to monitor an OAM domain (like PW13 and PWXZ PPSTMEs) rather 946 than the segment between two OAM domains. However the OAM framework 947 does not pose any constraints on the way PSTs are instantiated as 948 long as they are not overlapping. 950 The subsections below define the MEGs specified in this MPLS-TP OAM 951 architecture framework document. Unless otherwise stated, all 952 references to domains, LSRs, MPLS Sections, LSPs, pseudowires and 953 MEGs in this section are made in relation to those shown in Figure 3. 955 4.1. MPLS-TP Section Monitoring 957 An MPLS-TP Section ME (SME) is an MPLS-TP maintenance entity intended 958 to an MPLS Section as defined in [11]. An SME may be configured on 959 any MPLS section. SME OAM packets must fate share with the user data 960 packets sent over the monitored MPLS Section. 962 An SME is intended to be deployed for applications where it is 963 preferable to monitor the link between topologically adjacent (next 964 hop in this layer network) MPLS (and MPLS-TP enabled) LSRs rather 965 than monitoring the individual LSP or PW segments traversing the MPLS 966 Section and the server layer technology does not provide adequate OAM 967 capabilities. 969 |<------------------- MS-PW1Z ------------------->| 970 | | 971 | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | 972 V V LSP V V LSP V V LSP V V 973 +----+ +-+ +----+ +----+ +-+ +----+ 974 +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ 975 | |AC1| |=========| |=========| |=========| |AC2| | 976 | CE1|---|........PW13.......|...PW3X..|.......PWXZ........|---|CE2 | 977 | | | |=========| |=========| |=========| | | | 978 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 979 +----+ +-+ +----+ +----+ +-+ +----+ 980 ^--^ ^--^ ^---------^ ^---^ ^---^ 981 Sec12 Sec23 Sec3X SecXY SecYZ 982 SME SME SME SME SME 984 Figure 4 Reference Example of MPLS-TP Section MEs (SME) 986 Figure 4 shows 5 Section MEs configured in the path between AC1 and 987 AC2: 989 1. Sec12 ME associated with the MPLS Section between LSR 1 and LSR 2, 991 2. Sec23 ME associated with the MPLS Section between LSR 2 and LSR 3, 993 3. Sec3X ME associated with the MPLS Section between LSR 3 and LSR X, 995 4. SecXY ME associated with the MPLS Section between LSR X and LSR Y, 996 and 998 5. SecYZ ME associated with the MPLS Section between LSR Y and LSR Z. 1000 4.2. MPLS-TP LSP End-to-End Monitoring 1002 An MPLS-TP LSP ME (LME) is an MPLS-TP maintenance entity intended to 1003 monitor an end-to-end LSP between two LERs. An LME may be configured 1004 on any MPLS LSP. LME OAM packets must fate share with user data 1005 packets sent over the monitored MPLS-TP LSP. 1007 An LME is intended to be deployed in scenarios where it is desirable 1008 to monitor an entire LSP between its LERs, rather than, say, 1009 monitoring individual PWs. 1011 |<------------------- MS-PW1Z ------------------->| 1012 | | 1013 | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | 1014 V V LSP V V LSP V V LSP V V 1015 +----+ +-+ +----+ +----+ +-+ +----+ 1016 +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ 1017 | |AC1| |=========| |=========| |=========| |AC2| | 1018 | CE1|---|........PW13.......|...PW3X..|........PWXZ.......|---|CE2 | 1019 | | | |=========| |=========| |=========| | | | 1020 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 1021 +----+ +-+ +----+ +----+ +-+ +----+ 1022 ^---------^ ^---------^ 1023 PSN13 LME PSNXZ LME 1025 Figure 5 Examples of MPLS-TP LSP MEs (LME) 1027 Figure 5 depicts 2 LMEs configured in the path between AC1 and AC2: 1028 1) the PSN13 LME between LER 1 and LER 3, and 2) the PSNXZ LME 1029 between LER X and LER Y. Note that the presence of a PSN3X LME in 1030 such a configuration is optional, hence, not precluded by this 1031 framework. For instance, the SPs may prefer to monitor the MPLS-TP 1032 Section between the two LSRs rather than the individual LSPs. 1034 4.3. MPLS-TP LSP Path Segment Tunnel Monitoring 1036 An MPLS-TP LSP Path Segment Tunnel ME (LPSTME) is an MPLS-TP 1037 maintenance entity intended to monitor an arbitrary part of an LSP 1038 between a given pair of LSRs independently from the end-to-end 1039 monitoring (LME). An LPSTMEE can monitor an LSP segment or 1040 concatenated segment and it may also include the forwarding engine(s) 1041 of the node(s) at the edge(s) of the segment or concatenated segment. 1043 Multiple LPSTMEs MAY be configured on any LSP. The LSRs that 1044 terminate the LPSTME may or may not be immediately adjacent at the 1045 MPLS-TP layer. LPSTME OAM packets must fate share with the user data 1046 packets sent over the monitored LSP segment. 1048 A LPSTME can be defined between the following entities: 1050 o LER and any LSR of a given LSP. 1052 o Any two LSRs of a given LSP. 1054 An LPSTME is intended to be deployed in scenarios where it is 1055 preferable to monitor the behaviour of a part of an LSP or set of 1056 LSPs rather than the entire LSP itself, for example when there is a 1057 need to monitor a part of an LSP that extends beyond the 1058 administrative boundaries of an MPLS-TP enabled administrative 1059 domain. 1061 |<--------------------- PW1Z -------------------->| 1062 | | 1063 | |<--------------PSN1Z LSP-------------->| | 1064 | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | 1065 V V S-LSP V V S-LSP V V S-LSP V V 1066 +----+ +-+ +----+ +----+ +-+ +----+ 1067 +----+ | PE1| | | |DBN3| |DBNX| | | | PEZ| +----+ 1068 | |AC1| |=======================================| |AC2| | 1069 | CE1|---|......................PW1Z.......................|---|CE2 | 1070 | | | |=======================================| | | | 1071 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 1072 +----+ +-+ +----+ +----+ +-+ +----+ 1073 . . . . 1074 | | | | 1075 |<---- Domain 1 --->| |<---- Domain Z --->| 1077 ^---------^ ^---------^ 1078 PSN13 LPSTME PSNXZ LPSTME 1079 ^---------------------------------------^ 1080 PSN1Z LME 1082 DBN: Domain Border Node 1084 Figure 6 MPLS-TP LSP Path Segment Tunnel ME (LPSTME) 1086 Figure 6 depicts a variation of the reference model in Figure 3 where 1087 there is an end-to-end PSN LSP (PSN1Z LSP) between PE1 and PEZ. PSN1Z 1088 LSP consists of, at least, three LSP Concatenated Segments: PSN13, 1089 PSN3X and PSNXZ. In this scenario there are two separate LTCMEs 1090 configured to monitor the PSN1Z LSP: 1) a LPSTME monitoring the PSN13 1091 LSP Concatenated Segment on Domain 1 (PSN13 LPSTME), and 2) a LPSTME 1092 monitoring the PSNXZ LSP Concatenated Segment on Domain Z (PSNXZ 1093 LPSTME). 1095 It is worth noticing that LPSTMEs can coexist with the LME monitoring 1096 the end-to-end LSP and that LPSTME MEPs and LME MEPs can be 1097 coincident in the same node (e.g. PE1 node supports both the PSN1Z 1098 LME MEP and the PSN13 LPSTME MEP). 1100 4.4. MPLS-TP PW Monitoring 1102 An MPLS-TP PW ME (PME) is an MPLS-TP maintenance entity intended to 1103 monitor a SS-PW or MS-PW between a pair of T-PEs. A PME MAY be 1104 configured on any SS-PW or MS-PW. PME OAM packets must fate share 1105 with the user data packets sent over the monitored PW. 1107 A PME is intended to be deployed in scenarios where it is desirable 1108 to monitor an entire PW between a pair of MPLS-TP enabled T-PEs 1109 rather than monitoring the LSP aggregating multiple PWs between PEs. 1111 |<------------------- MS-PW1Z ------------------->| 1112 | | 1113 | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | 1114 V V LSP V V LSP V V LSP V V 1115 +----+ +-+ +----+ +----+ +-+ +----+ 1116 +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ 1117 | |AC1| |=========| |=========| |=========| |AC2| | 1118 | CE1|---|........PW13.......|...PW3X..|........PWXZ.......|---|CE2 | 1119 | | | |=========| |=========| |=========| | | | 1120 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 1121 +----+ +-+ +----+ +----+ +-+ +----+ 1123 ^---------------------PW1Z PME--------------------^ 1125 Figure 7 MPLS-TP PW ME (PME) 1127 Figure 7 depicts a MS-PW (MS-PW1Z) consisting of three segments: 1128 PW13, PW3X and PWXZ and its associated end-to-end PME (PW1Z PME). 1130 4.5. MPLS-TP MS-PW Path Segment Tunnel Monitoring 1132 [Editors' note: revise this section after the discussion on PW TCM is 1133 closed (discussion item 4 in section 1.2)] 1135 An MPLS-TP MS-PW Path Segment Tunnel Monitoring ME (PPSTME) is an 1136 MPLS-TP maintenance entity intended to monitor an arbitrary part of 1137 an MS-PW between a given pair of PEs independently from the end-to- 1138 end monitoring (PME). A PPSTME can monitor a PW segment or 1139 concatenated segment and it may also include the forwarding engine(s) 1140 of the node(s) at the edge(s) of the segment or concatenated segment. 1142 Multiple PPSTMEs MAY be configured on any MS-PW. The PEs may or may 1143 not be immediately adjacent at the MS-PW layer. PPSTME OAM packets 1144 fate share with the user data packets sent over the monitored PW 1145 Segment. 1147 A PPSTME can be defined between the following entities: 1149 o T-PE and any S-PE of a given MS-PW 1151 o Any two S-PEs of a given MS-PW. It can span several PW segments. 1153 A PPSTME is intended to be deployed in scenarios where it is 1154 preferable to monitor the behaviour of a part of a MS-PW rather than 1155 the entire end-to-end PW itself, for example to monitor an MS-PW 1156 Segment within a given network domain of an inter-domain MS-PW. 1158 |<------------------- MS-PW1Z ------------------->| 1159 | | 1160 | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | 1161 V V LSP V V LSP V V LSP V V 1162 +----+ +-+ +----+ +----+ +-+ +----+ 1163 +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ 1164 | |AC1| |=========| |=========| |=========| |AC2| | 1165 | CE1|---|........PW13.......|...PW3X..|........PWXZ.......|---|CE2 | 1166 | | | |=========| |=========| |=========| | | | 1167 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 1168 +----+ +-+ +----+ +----+ +-+ +----+ 1170 ^---- PW1 PPSTME----^ ^---- PW5 PPSTME----^ 1171 ^---------------------PW1Z PME--------------------^ 1173 Figure 8 MPLS-TP MS-PW Path Segment Tunnel Monitoring (PPSTME) 1175 Figure 8 depicts the same MS-PW (MS-PW1Z) between AC1 and AC2 as in 1176 Figure 7. In this scenario there are two separate PPSTMEs configured 1177 to monitor MS-PW1Z: 1) a PPSTME monitoring the PW13 MS-PW Segment on 1178 Domain 1 (PW13 PPSTME), and 2) a PTCME monitoring the PWXZ MS-PW 1179 Segment on Domain Z with (PWXZ PPSTME). 1181 It is worth noticing that PPSTMEs can coexist with the PME monitoring 1182 the end-to-end MS-PW and that PPSTME MEPs and PME MEPs can be 1183 coincident in the same node (e.g. TPE1 node supports both the PW1Z 1184 PME MEP and the PW13 PPSTME MEP). 1186 5. OAM Functions for proactive monitoring 1188 [Editors' note: at the beginning of each section, reference the 1189 section in the OAM Requirements document and explicitly list 1190 additional detailed requirements wrt the OAM Requirements document] 1191 In this document, proactive monitoring refers to OAM operations that 1192 are either configured to be carried out periodically and continuously 1193 or preconfigured to act on certain events such as alarm signals. 1195 5.1. Continuity Check and Connectivity Verification 1197 Proactive Continuity Check functions are used to detect a loss of 1198 continuity defect (LOC) between two MEPs in an MEG. 1200 Proactive Connectivity Verification functions are used to detect an 1201 unexpected connectivity defect between two MEGs (e.g. mismerging or 1202 misconnection), as well as unexpected connectivity within the MEG 1203 with an unexpected MEP. 1205 Both functions are based on the (proactive) generation of OAM packets 1206 by the source MEP that are processed by the sink MEP. As a 1207 consequence these two functions are grouped together into Continuity 1208 Check and Connectivity Verification (CC-V) OAM packets. 1210 In order to perform pro-active Connectivity Verification function, 1211 each CC-V OAM packet MUST also include a globally unique Source MEP 1212 identifier. When used to perform only pro-active Continuity Check 1213 function, the CC-V OAM packet MAY not include any globally unique 1214 Source MEP identifier identifier. Different formats of MEP 1215 identifiers are defined in [10] to address different environments. 1216 When MPLS-TP is deployed in transport network environments where IP 1217 addressing is not used in the forwarding plane, the ICC-based format 1218 for MEP identification is used. When MPLS-TP is deployed in IP-based 1219 environment, the IP-based MEP identification is used. 1221 As a consequence, it is not possible to detect misconnections between 1222 two MEGs monitored only for Continuity while it is possible to detect 1223 any misconnection between two MEGs monitored for Continuity and 1224 Connectivity or between an MEG monitored for Continuity and 1225 Connectivity and one MEG monitored only for Continuity. 1227 [Editor's note - Rephrase the previous paragraph: describe the four 1228 cases.] 1230 CC-V OAM packets MUST be transmitted at a regular, operator's 1231 configurable, rate. The default CC-V transmission periods are 1232 application dependent (see section 5.1.4). 1234 Proactive CC-V OAM packets are transmitted with the "minimum loss 1235 probability PHB" within a single network operator. This PHB is 1236 configurable on network operator's basis. PHBs can be translated at 1237 the network borders by the same function that translates it for user 1238 data traffic. 1240 [Editor's note - Describe the relation between the previous paragraph 1241 and the fate sharing requirement. Need to clarify also in the 1242 requirement document that for proactive CC-V the fate sharing is 1243 related to the forwarding behavior and not to the QoS behavior] 1245 In a bidirectional point-to-point transport path, when a MEP is 1246 enabled to generate pro-active CC-V OAM packets with a configured 1247 transmission rate, it also expects to receive pro-active CC-V OAM 1248 packets from its peer MEP at the same transmission rate as a common 1249 SLA applies to all components of the transport path. In a 1250 unidirectional transport path (either point-to-point or point-to- 1251 multipoint), only the source MEP is enabled to generate CC-V OAM 1252 packets and only the sink MEP is configured to expect these packets 1253 at the configured rate. 1255 MIPs, as well as intermediate nodes not supporting MPLS-TP OAM, are 1256 transparent to the pro-active CC-V information and forward these pro- 1257 active CC-V OAM packets as regular data packets. 1259 It is desirable to not generate spurious alarms during initialization 1260 or tear down; hence the following procedures are recommended. At 1261 initialization, the MEP source function (generating pro-active CC-V 1262 packets) should be enabled prior to the corresponding MEP sink 1263 function (detecting continuity and connectivity defects). When 1264 disabling the CC-V proactive functionality, the MEP sink function 1265 should be disabled prior to the corresponding MEP source function. 1267 5.1.1. Defects identified by CC-V 1269 Pro-active CC-V functions allow a sink MEP to detect the defect 1270 conditions described in the following sub-sections. For all of the 1271 described defect cases, the sink MEP SHOULD notify the equipment 1272 fault management process of the detected defect. 1274 5.1.1.1. Loss Of Continuity defect 1276 When proactive CC-V is enabled, a sink MEP detects a loss of 1277 continuity (LOC) defect when it fails to receive pro-active CC-V OAM 1278 packets from the peer MEP. 1280 o Entry criteria: if no pro-active CC-V OAM packets from the peer 1281 MEP (i.e. with the correct globally unique Source MEP identifier) 1282 are received within the interval equal to 3.5 times the receiving 1283 MEP's configured CC-V reception period. 1285 o Exit criteria: a pro-active CC-V OAM packet from the peer MEP 1286 (i.e. with the correct globally unique Source MEP identifier) is 1287 received. 1289 5.1.1.2. Mis-connectivity defect 1291 When a pro-active CC-V OAM packet is received, a sink MEP identifies 1292 a mis-connectivity defect (e.g. mismerge, misconnection or unintended 1293 looping) with its peer source MEP when the received packet carries an 1294 incorrect globally unique Source MEP identifier. 1296 o Entry criteria: the sink MEP receives a pro-active CC-V OAM packet 1297 with an incorrect globally unique Source MEP identifier. 1299 o Exit criteria: the sink MEP does not receive any pro-active CC-V 1300 OAM packet with an incorrect globally unique Source MEP identifier 1301 for an interval equal at least to 3.5 times the longest 1302 transmission period of the pro-active CC-V OAM packets received 1303 with an incorrect globally unique Source MEP identifier since this 1304 defect has been raised. This requires the OAM message to self 1305 identify the CC-V periodicity as not all MEPs can be expected to 1306 have knowledge of all MEGs. 1308 5.1.1.3. Period Misconfiguration defect 1310 If pro-active CC-V OAM packets are received with a correct globally 1311 unique Source MEP identifier but with a transmission period different 1312 than the locally configured reception period, then a CV period mis- 1313 configuration defect is detected. 1315 o Entry criteria: a MEP receives a CC-V pro-active packet with 1316 correct globally unique Source MEP identifier but with a Period 1317 field value different than its own CC-V configured transmission 1318 period. 1320 o Exit criteria: the sink MEP does not receive any pro-active CC-V 1321 OAM packet with a correct globally unique Source MEP identifier 1322 and an incorrect transmission period for an interval equal at 1323 least to 3.5 times the longest transmission period of the pro- 1324 active CC-V OAM packets received with a correct globally unique 1325 Source MEP identifier and an incorrect transmission period since 1326 this defect has been raised. 1328 5.1.2. Consequent action 1330 [editors: IMO this would be better folded into the specific defect 1331 types, If agreed I will edit accordingly] 1332 A sink MEP that detects one of the defect conditions defined in 1333 section 5.1.1 MUST perform the following consequent actions. Some of 1334 these consequent actions SHOULD be enabled/disabled by the operator 1335 depending upon the application used (see section 5.1.4). 1337 If a MEP detects an unexpected globally unique Source MEP Identifier, 1338 it MUST block all the traffic (including also the user data packets) 1339 that it receives from the misconnected transport path. 1341 If a MEP detects LOC defect that is not caused by a period 1342 mis-configuration, it SHOULD block all the traffic (including also 1343 the user data packets) that it receives from the transport path, if 1344 this consequent action has been enabled by the operator. 1346 It is worth noticing that the OAM requirements document [12] 1347 recommends that CC-V proactive monitoring is enabled on every MEG in 1348 order to reliably detect connectivity defects. However, CC-V 1349 proactive monitoring MAY be disabled by an operator on an MEG. In the 1350 event of a misconnection between a transport path that is pro- 1351 actively monitored for CC-V and a transport path which is not, the 1352 MEP of the former transport path will detect a LOC defect 1353 representing a connectivity problem (e.g. a misconnection with a 1354 transport path where CC-V proactive monitoring is not enabled) 1355 instead of a continuity problem, with a consequent wrong traffic 1356 delivering. For these reasons, the traffic block consequent action is 1357 applied even when a LOC condition occurs. This block consequent 1358 action MAY be disabled through configuration. This deactivation of 1359 the block action may be used for activating or deactivating the 1360 monitoring when it is not possible to synchronize the function 1361 activation of the two peer MEPs. 1363 If a MEP detects a LOC defect (section 5.1.1.1), a mis-connectivity 1364 defect (section 5.1.1.2) or a period misconfiguration defect (section 1365 5.1.1.3), it MUST declare a signal fail condition at the transport 1366 path level. 1368 [Editor's note - Transport equipment also performs defect correlation 1369 (as defined in G.806) in order to properly report failures to the 1370 transport NMS]. The current working assumption, to be further 1371 investigated, is that defect correlations are outside the scope of 1372 this document and to be defined in ITU-T documents.] 1374 5.1.3. Configuration considerations 1376 At all MEPs inside a MEG, the following configuration information 1377 needs to be configured when a proactive CC-V function is enabled: 1379 o MEG ID; the MEG identifier to which the MEP belongs; 1381 o MEP-ID; the MEP's own identity inside the MEG; 1383 o list of peer MEPs inside the MEG. For a point-to-point MEG the 1384 list would consist of the single peer MEP ID from which the OAM 1385 packets are expected. In case of the root MEP of a p2mp MEG, the 1386 list is composed by all the leaf MEP IDs inside the MEG. In case 1387 of the leaf MEP of a p2mp MEG, the list is composed by the root 1388 MEP ID (i.e. each leaf MUST know the root MEP ID from which it 1389 expect to receive the CC-V OAM packets). 1391 o transmission rate; the default CC-V transmission periods are 1392 application dependent (see section 5.1.4) 1394 Note that the reception period is the same as the configured 1395 transmission rate. 1397 o PHB; it identifies the per-hop behaviour of CC-V packet. Proactive 1398 CC-V packets are transmitted with the "minimum loss probability 1399 PHB" previously configured within a single network operator. This 1400 PHB is configurable on network operator's basis. PHBs can be 1401 translated at the network borders. 1403 For statically provisioned transport paths the above information are 1404 statically configured; for dynamically established transport paths 1405 the configuration information are signaled via the control plane. 1407 5.1.4. Applications for proactive CC-V 1409 CC-V is applicable for fault management, performance monitoring, or 1410 protection switching applications. 1412 o Fault Management: default transmission period is 1s (i.e. 1413 transmission rate of 1 packet/second). 1415 o Performance Monitoring: default transmission period is 100ms (i.e. 1416 transmission rate of 10 packets/second). Performance monitoring is 1417 only relevant when the transport path is defect free. CC-V 1418 contributes to the accuracy of PM statistics by permitting the 1419 defect free periods to be properly distinguished. 1421 o Protection Switching: default transmission period is 3.33ms (i.e. 1422 transmission rate of 300 packets/second), in order to achieve sub- 1423 50ms the CC-V defect entry criteria should resolve in less than 1424 10msec, and complete a protection switch within a subsequent 1425 period of 50 msec. 1427 It SHOULD be possible for the operator to configure these 1428 transmission rates for all applications, to satisfy his internal 1429 requirements. 1431 In addition, the operator should be able to define the consequent 1432 action to be performed for each of these applications. 1434 5.2. Remote Defect Indication 1436 The Remote Defect Indication (RDI) is an indicator that is 1437 transmitted by a MEP to communicate to its peer MEPs that a signal 1438 fail condition exists. RDI is only used for bidirectional 1439 connections and is associated with proactive CC-V activation. The RDI 1440 indicator is piggy-backed onto the CC-V packet. 1442 When a MEP detects a signal fail condition (e.g. in case of a 1443 continuity or connectivity defect), it should begin transmitting an 1444 RDI indicator to its peer MEP. The RDI information will be included 1445 in all pro-active CC-V packets that it generates for the duration of 1446 the signal fail condition's existence. 1448 [Editor's note - Add some forward compatibility information to cover 1449 the case where future OAM mechanisms that contributes to the signal 1450 fail detection (and RDI generation) are defined.] 1452 A MEP that receives the packets with the RDI information should 1453 determine that its peer MEP has encountered a defect condition 1454 associated with a signal fail. 1456 MIPs as well as intermediate nodes not supporting MPLS-TP OAM are 1457 transparent to the RDI indicator and forward these proactive CC-V 1458 packets that include the RDI indicator as regular data packets, i.e. 1459 the MIP should not perform any actions nor examine the indicator. 1461 When the signal fail defect condition clears, the MEP should clear 1462 the RDI indicator from subsequent transmission of pro-active CC-V 1463 packets. A MEP should clear the RDI defect upon reception of a pro- 1464 active CC-V packet from the source MEP with the RDI indicator 1465 cleared. 1467 5.2.1. Configuration considerations 1469 In order to support RDI indication, this may be a unique OAM message 1470 or an OAM information element embedded in a CV message. In this case 1471 the RDI transmission rate and PHB of the OAM packets carrying RDI 1472 should be the same as that configured for CC-V. 1474 5.2.2. Applications for Remote Defect Indication 1476 RDI is applicable for the following applications: 1478 o Single-ended fault management - A MEP that receives an RDI 1479 indication from its peer MEP, can report a far-end defect 1480 condition (i.e. the peer MEP has detected a signal fail condition 1481 in the traffic direction from the MEP that receives the RDI 1482 indication to the peer MEP that has sent the RDI information). 1484 o Contribution to far-end performance monitoring - The indication of 1485 the far-end defect condition is used as a contribution to the 1486 bidirectional performance monitoring process. 1488 5.3. Alarm Reporting 1490 The Alarm Reporting function relies upon an Alarm Indication Signal 1491 (AIS) message used to suppress alarms following detection of defect 1492 conditions at the server (sub-)layer. 1494 o A server MEP that detects a signal fail conditions in the server 1495 (sub-)layer, will notify the MPLS-TP client (sub-)layer adaptation 1496 function, which can generate packets with AIS information in a 1497 direction opposite to its peers MEPs to allow the suppression of 1498 secondary alarms at the MEP in the client (sub-)layer. 1500 A server MEP is responsible for notifying the MPLS-TP layer network 1501 adaptation function upon fault detection in the server layer network 1502 to which the server MEP is associated. 1504 Only the client layer adaptation function at an intermediate node 1505 will issue MPLS-TP packets with AIS information. Upon receiving 1506 notification of a signal fail condition the adaptation function 1507 SHOULD immediately start transmitting periodic packets with AIS 1508 information. These periodic packets, with AIS information, continue 1509 to be transmitted until the signal fail condition is cleared. 1511 Upon receiving a packet with AIS information an MPLS-TP MEP enters an 1512 AIS defect condition and suppresses loss of continuity alarms 1513 associated with its peer MEP. A MEP resumes loss of continuity alarm 1514 generation upon detecting loss of continuity defect conditions in the 1515 absence of AIS condition. 1517 For example, let's consider a fiber cut between LSR 1 and LSR 2 in 1518 the reference network of Figure 3. Assuming that all the MEGs 1519 described in Figure 3 have pro-active CC-V enabled, a LOC defect is 1520 detected by the MEPs of Sec12 SME, PSN13 LME, PW1 PTCME and PW1Z PME, 1521 however in transport network only the alarm associate to the fiber 1522 cut needs to be reported to NMS while all these secondary alarms 1523 should be suppressed (i.e. not reported to the NMS or reported as 1524 secondary alarms). 1526 If the fiber cut is detected by the MEP in the physical layer (in 1527 LSR2), LSR2 can generate the proper alarm in the physical layer and 1528 suppress the secondary alarm associated with the LOC defect detected 1529 on Sec12 SME. As both MEPs reside within the same node, this process 1530 does not involve any external protocol exchange. Otherwise, if the 1531 physical layer has not enough OAM capabilities to detect the fiber 1532 cut, the MEP of Sec12 SME in LSR2 will report a LOC alarm. 1534 In both cases, the MEP of Sec12 SME in LSR 2 notifies the adaptation 1535 function for PSN13 LME that then generates AIS packets on the PSN13 1536 LME in order to allow its MEP in LSR3 to suppress the LOC alarm. LSR3 1537 can also suppress the secondary alarm on PW13 PPSTME because the MEP 1538 of PW13 PPSTME resides within the same node as the MEP of PSN13 LME. 1539 The MEP of PW13 PPSTME in LSR3 also notifies the adaptation function 1540 for PW1Z PME that then generates AIS packets on PW1Z PME in order to 1541 allow its MEP in LSRZ to suppress the LOC alarm. 1543 The generation of AIS packets for each MEG in the client (sub-)layer 1544 is configurable (i.e. the operator can enable/disable the AIS 1545 generation). 1547 AIS packets are transmitted with the "minimum loss probability PHB" 1548 within a single network operator. This PHB is configurable on network 1549 operator's basis. 1551 A MIP is transparent to packets with AIS information and therefore 1552 does not require any information to support AIS functionality. 1554 5.4. Lock Reporting 1556 To be incorporated in a future revision of this document 1558 5.5. Packet Loss Monitoring 1560 Packet Loss Monitoring (LM) is one of the capabilities supported by 1561 the MPLS-TP Performance Monitoring (PM) function in order to 1562 facilitate reporting of QoS information for a transport path. LM is 1563 used to exchange counter values for the number of ingress and egress 1564 packets transmitted and received by the transport path monitored by a 1565 pair of MEPs. 1567 Proactive LM is performed by periodically sending LM OAM packets from 1568 a MEP to a peer MEP and by receiving LM OAM packets from the peer MEP 1569 (if a bidirectional transport path) during the life time of the 1570 transport path. Each MEP performs measurements of its transmitted and 1571 received packets. These measurements are then transactionally 1572 correlated with the peer MEP in the ME to derive the impact of packet 1573 loss on a number of performance metrics for the ME in the MEG. The LM 1574 transactions are issued such that the OAM packets will experience the 1575 same queuing discipline as the measured traffic while transiting 1576 between the MEPs in the ME. 1578 For a MEP, near-end packet loss refers to packet loss associated with 1579 incoming data packets (from the far-end MEP) while far-end packet 1580 loss refers to packet loss associated with egress data packets 1581 (towards the far-end MEP). 1583 5.5.1. Configuration considerations 1585 In order to support proactive LM, the transmission rate and PHB 1586 associated with the LM OAM packets originating from a MEP need be 1587 configured as part of the LM provisioning procedures. LM OAM packets 1588 should be transmitted with the PHB that yields the lowest packet loss 1589 performance among the PHB Scheduling Classes or Ordered Aggregates 1590 (see RFC 3260 [15]) in the monitored transport path for the relevant 1591 network domain(s). 1593 5.5.2. Applications for Packet Loss Monitoring 1595 LM is relevant for the following applications: 1597 o Single or double-end performance monitoring: determination of the 1598 packet loss performance of a transport path for Service Level 1599 Agreement (SLA) verification purposes. 1601 o Single or double-end performance monitoring: determination of the 1602 packet loss performance of a PHB Scheduling Class or Ordered 1603 Aggregate within a transport path. 1605 o Contribution to service unable time. Both near-end and far-end 1606 packet loss measurements contribute to performance metrics such as 1607 near-end severely errored seconds (Near-End SES) and far-end 1608 severely errored seconds (Far-End SES) respectively, which 1609 together contribute to unavailable time, in a manner similar to 1610 Recommendation G.826 [19] and Recommendation G.7710 [20]. 1612 5.6. Client Signal Failure Indication 1614 The Client Signal Failure Indication (CSF) function is used to help 1615 process client defects and propagate a client signal defect condition 1616 from the process associated with the local attachment circuit where 1617 the defect was detected (typically the source adaptation function for 1618 the local client interface) to the process associated with the far- 1619 end attachment circuit (typically the source adaptation function for 1620 the far-end client interface) for the same transmission path in case 1621 the client of the transmission path does not support a native 1622 defect/alarm indication mechanism, e.g. FDI/AIS. 1624 [Editor's note - The need to support this function on the LSP layer 1625 (and not only at the PW layer) needs to be further investigated. 1626 Pending discussion on MPLS-TP clients in the main framework 1627 document.] 1629 A source MEP starts transmitting a CSF indication to its peer MEP 1630 when it receives a local client signal defect notification via its 1631 local CSF function. Mechanisms to detect local client signal fail 1632 defects are technology specific. 1634 A sink MEP that has received a CSF indication report this condition 1635 to its associated client process via its local CSF function. 1636 Consequent actions toward the client attachment circuit are 1637 technology specific. 1639 Either there needs to be a 1:1 correspondence between the client and 1640 the MEG, or when multiple clients are multiplexed over a transport 1641 path, the CSF message requires additional information to permit the 1642 client instance to be identified. 1644 5.6.1. Configuration considerations 1646 In order to support CSF indication, the CSF transmission rate and PHB 1647 of the CSF OAM message/information element should be configured as 1648 part of the CSF configuration. 1650 5.6.2. Applications for Client Signal Failure Indication 1652 CSF is applicable for the following applications: 1654 o Single-ended fault management - A MEP that receives a CSF 1655 indication from its peer MEP, can report a far-end client defect 1656 condition (i.e. the peer MEP has been informed of local client 1657 signal fail condition in the traffic direction from the client to 1658 the peer MEP that transmitted the CSF). 1660 o Contribution to far-end performance monitoring - The indication of 1661 the far-end defect condition may be used to account on network 1662 operator contribution to the bidirectional performance monitoring 1663 process. 1665 CSF supports the application described in Appendix VIII of ITU-T 1666 G.806 [18]. 1668 5.7. Delay Measurement 1670 Delay Measurement (DM) is one of the capabilities supported by the 1671 MPLS-TP PM function in order to facilitate reporting of QoS 1672 information for a transport path. Specifically, pro-active DM is used 1673 to measure the long-term packet delay and packet delay variation in 1674 the transport path monitored by a pair of MEPs. 1676 Proactive DM is performed by sending periodic DM OAM packets from a 1677 MEP to a peer MEP and by receiving DM OAM packets from the peer MEP 1678 (if a bidirectional transport path) during a configurable time 1679 interval. 1681 Pro-active DM can be operated in two ways: 1683 o One-way: a MEP sends DM OAM packet to its peer MEP containing all 1684 the required information to facilitate one-way packet delay and/or 1685 one-way packet delay variation measurements at the peer MEP. Note 1686 that this requires synchronized precision time at either MEP by 1687 means outside the scope of this framework. 1689 o Two-way: a MEP sends DM OAM packet with a DM request to its peer 1690 MEP, which replies with a DM OAM packet as a DM response. The 1691 request/response DM OAM packets containing all the required 1692 information to facilitate two-way packet delay and/or two-way 1693 packet delay variation measurements from the viewpoint of the 1694 source MEP. 1696 5.7.1. Configuration considerations 1698 In order to support pro-active DM, the transmission rate and PHB 1699 associated with the DM OAM packets originating from a MEP need be 1700 configured as part of the DM provisioning procedures. DM OAM packets 1701 should be transmitted with the PHB that yields the lowest packet loss 1702 performance among the PHB Scheduling Classes or Ordered Aggregates 1703 (see RFC 3260 [15]) in the monitored transport path for the relevant 1704 network domain(s). 1706 5.7.2. Applications for Delay Measurement 1708 DM is relevant for the following applications: 1710 o Single or double-end performance monitoring: determination of the 1711 delay performance of a transport path for SLA verification 1712 purposes. 1714 o Single or double-end performance monitoring: determination of the 1715 delay performance of a PHB Scheduling Class or Ordered Aggregate 1716 within a transport path 1718 6. OAM Functions for on-demand monitoring 1720 [Editors' note: at the beginning of each section, reference the 1721 section in the OAM Requirements document and explicitly list 1722 additional detailed requirements wrt the OAM Requirements document] 1724 In contrast to proactive monitoring, on-demand monitoring is 1725 initiated manually and for a limited amount of time, usually for 1726 operations such as e.g. diagnostics to investigate into a defect 1727 condition. 1729 6.1. Connectivity Verification 1731 In order to preserve network resources, e.g. bandwidth, processing 1732 time at switches, it may be preferable to not use proactive CC-V. In 1733 order to perform fault management functions, network management may 1734 invoke periodic on-demand bursts of on-demand CV packets. 1736 Use of on-demand CV is dependent on the existence of a bi-directional 1737 MEG, because it requires the presence of a return path in the data 1738 plane.[Editors': needs to be revised on the basis of the return path 1739 discussion (discussion item 7 in section 1.2] 1741 [Editor's note - Clarify in the sentence above and within the 1742 paragraph that on-demand CV requires a return path to send back the 1743 reply to on-demand CV packets] 1745 An additional use of on-demand CV would be to detect and locate a 1746 problem of connectivity when a problem is suspected or known based on 1747 other tools. In this case the functionality will be triggered by the 1748 network management in response to a status signal or alarm 1749 indication. 1751 On-demand CV is based upon generation of on-demand CV packets that 1752 should uniquely identify the MEG that is being checked. The on- 1753 demand functionality may be used to check either an entire MEG (end- 1754 to-end) or between a MEP to a specific MIP. This functionality may 1755 not be available for associated bidirectional paths as the MIP may 1756 not have a return path to the source MEP for the on-demand CV 1757 transaction. 1759 On-demand CV may generate a one-time burst of on-demand CV packets, 1760 or be used to invoke periodic, non-continuous, bursts of on-demand CV 1761 packets. The number of packets generated in each burst is 1762 configurable at the MEPs, and should take into account normal packet- 1763 loss conditions. 1765 When invoking a periodic check of the MEG, the source MEP should 1766 issue a burst of on-demand CV packets that uniquely identifies the 1767 MEG being verified. The number of packets and their transmission 1768 rate should be pre-configured and known to both the source MEP and 1769 the target MEP or MIP. The source MEP should use the TTL field to 1770 indicate the number of hops necessary, when targeting a MIP and use 1771 the default value when performing an end-to-end check [IB => This is 1772 quite generic for addressing packets to MIPs and MEPs so it is better 1773 to move this text in section 2]. The target MEP/MIP shall return a 1774 reply on-demand CV packet for each packet received. If the expected 1775 number of on-demand CV reply packets is not received at source MEP, 1776 the LOC defect state is entered. 1778 [Editor's note - We need to add some text for the usage of on-demand 1779 CV with different packet sizes, e.g. to discover MTU problems.] 1781 6.1.1. Configuration considerations 1783 For on-demand CV the MEP should support the configuration of the 1784 number of packets to be transmitted/received in each burst of 1785 transmissions and their packet size. The transmission rate should be 1786 configured between the different nodes. 1788 In addition, when the CV packet is used to check connectivity toward 1789 a target MIP, the number of hops to reach the target MIP should be 1790 configured. 1792 The PHB of the on-demand CV packets should be configured as well. 1794 [Editor's note - We need to be better define the reason for such 1795 configuration] 1797 6.2. Packet Loss Monitoring 1799 On-demand Packet Loss (LM) is one of the capabilities supported by 1800 the MPLS-TP Performance Monitoring function in order to facilitate 1801 diagnostic of QoS performance for a transport path. As proactive LM, 1802 on-demand LM is used to exchange counter values for the number of 1803 ingress and egress packets transmitted and received by the transport 1804 path monitored by a pair of MEPs. 1806 On-demand LM is performed by periodically sending LM OAM packets from 1807 a MEP to a peer MEP and by receiving LM OAM packets from the peer MEP 1808 (if a bidirectional transport path) during a pre-defined monitoring 1809 period. Each MEP performs measurements of its transmitted and 1810 received packets. These measurements are then correlated evaluate the 1811 packet loss performance metrics of the transport path. 1813 6.2.1. Configuration considerations 1815 In order to support on-demand LM, the beginning and duration of the 1816 LM procedures, the transmission rate and PHB associated with the LM 1817 OAM packets originating from a MEP must be configured as part of the 1818 on-demand LM provisioning procedures. LM OAM packets should be 1819 transmitted with the PHB that yields the lowest packet loss 1820 performance among the PHB Scheduling Classes or Ordered Aggregates 1821 (see RFC 3260 [15]) in the monitored transport path for the relevant 1822 network domain(s). 1824 6.2.2. Applications for On-demand Packet Loss Monitoring 1826 On-demand LM is relevant for the following applications: 1828 o Single-end performance monitoring: diagnostic of the packet loss 1829 performance of a transport path for SLA trouble shooting purposes. 1831 o Single-end performance monitoring: diagnostic of the packet loss 1832 performance of a PHB Scheduling Class or Ordering Aggregate within 1833 a transport path for QoS trouble shooting purposes. 1835 6.3. Diagnostic 1837 To be incorporated in a future revision of this document 1839 [Editors' note: describe an OAM tool for throughput estimation (out- 1840 of-service): works in one-way and two-way modes] 1842 [Editors' note: Need further investigation about the need to support 1843 a data-plane loopback. If needed, which layer does have to support 1844 this function (i.e. the MPLS-TP layer or its server layer?) It is 1845 also needed to understand whether it is needed to specify where this 1846 data-plane loopback takes place within the equipment] 1848 [Munich: Need to describe the two types of loopback - LBM/LBR and 1849 traffic loopback enhanced with variable sized packets in the on 1850 demand cases. 1852 One objective of diags is fault location, we need to make clear how 1853 we apply the tools to fault location. 1855 At the top of each section we need to describe the detailed 1856 requirements and then in the rest of the section describe how it is 1857 met.] 1859 6.4. Route Tracing 1861 [Editors' note: The framework needs to say what you need to trace and 1862 not how you do it (remove the description of the solution).] 1864 [Editors' note: Need to investigate if we need both tracing options: 1865 describe why and a sketch of the two options and their properties. 1867 Possible reasons for both options: 1869 o TTL incremental tells whether the CP is correct or not 1871 o the second one (path discovery) is ... 1873 Action: check on the mailing list the need to support both modes of 1874 operations.] 1876 After e.g. provisioning an MPLS-TP LSP or for trouble shooting 1877 purposes, it is often necessary to trace a route covered by an ME 1878 from a source MEP to the sink MEP including all the MIPs in-between. 1879 The route tracing function is providing this functionality. Based on 1880 the fate sharing requirement of OAM flows, i.e. OAM packets receive 1881 the same forwarding treatment as data packet, route tracing is a 1882 basic means to perform CV and, to a much lesser degree, CC. For this 1883 function to work properly, a return path must be present. 1885 Route tracing might be implemented in different ways and this 1886 document does not preclude any of them. Route trace could be 1887 implemented e.g. by an MPLS traceroute-like function [RFC4379]. 1888 However, route tracing should always return the full list of MIPs and 1889 the peer MEP in it answer(s). In case a defect exist, the route trace 1890 function needs to be able to detect it and stop automatically 1891 returning the incomplete list of OAM entities that it was able to 1892 trace. 1894 The configuration of the route trace function must at least support 1895 the setting of the trace depth (number of hops)_and the number of 1896 trace attempts before it gives up. Default setting need to be 1897 configurable by the operator, too. 1899 6.5. Delay Measurement 1901 Delay Measurement (DM) is one of the capabilities supported by the 1902 MPLS-TP PM function in order to facilitate reporting of QoS 1903 information for a transport path. Specifically, on-demand DM is used 1904 to measure packet delay and packet delay variation in the transport 1905 path monitored by a pair of MEPs during a pre-defined monitoring 1906 period. 1908 On-Demand DM is performed by sending periodic DM OAM packets from a 1909 MEP to a peer MEP and by receiving DM OAM packets from the peer MEP 1910 (if a bidirectional transport path) during a configurable time 1911 interval. 1913 On-demand DM can be operated in two ways: 1915 o One-way: a MEP sends DM OAM packet to its peer MEP containing all 1916 the required information to facilitate one-way packet delay and/or 1917 one-way packet delay variation measurements at the peer MEP. 1919 o Two-way: a MEP sends DM OAM packet with a DM request to its peer 1920 MEP, which replies with an DM OAM packet as a DM response. The 1921 request/response DM OAM packets containing all the required 1922 information to facilitate two-way packet delay and/or two-way 1923 packet delay variation measurements from the viewpoint of the 1924 source MEP. 1926 6.5.1. Configuration considerations 1928 In order to support on-demand DM, the beginning and duration of the 1929 DM procedures, the transmission rate and PHB associated with the DM 1930 OAM packets originating from a MEP need be configured as part of the 1931 LM provisioning procedures. DM OAM packets should be transmitted with 1932 the PHB that yields the lowest packet delay performance among the PHB 1933 Scheduling Classes or Ordering Aggregates (see RFC 3260 [15]) in the 1934 monitored transport path for the relevant network domain(s). 1936 In order to verify different performances between long and short 1937 packets (e.g., due to the processing time), it SHOULD be possible for 1938 the operator to configure of the on-demand OAM DM packet. 1940 6.5.2. Applications for Delay Measurement 1942 DM is relevant for the following applications: 1944 o Single or double-end performance monitoring: determination of the 1945 packet delay and/or delay variation performance of a transport 1946 path for SLA verification purposes. 1948 o Single or double-end performance monitoring: determination of the 1949 packet delay and/or delay variation a PHB Scheduling Class or 1950 Ordering Aggregate within a transport path 1952 o Contribution to service unable time. Packet delay measurements may 1953 contribute to performance metrics such as near-end severely 1954 errored seconds (Near-End SES) and far-end severely errored 1955 seconds (Far-End SES), which together contribute to unavailable 1956 time. 1958 6.6. Lock Instruct 1960 To be incorporated in a future revision of this document 1962 7. Security Considerations 1964 A number of security considerations are important in the context of 1965 OAM applications. 1967 OAM traffic can reveal sensitive information such as passwords, 1968 performance data and details about e.g. the network topology. The 1969 nature of OAM data therefore suggests to have some form of 1970 authentication, authorization and encryption in place. This will 1971 prevent unauthorized access to vital equipment and it will prevent 1972 third parties from learning about sensitive information about the 1973 transport network. 1975 Mechanisms that the framework does not specify might be subject to 1976 additional security considerations. 1978 8. IANA Considerations 1980 No new IANA considerations. 1982 9. Acknowledgments 1984 The authors would like to thank all members of the teams (the Joint 1985 Working Team, the MPLS Interoperability Design Team in IETF and the 1986 T-MPLS Ad Hoc Group in ITU-T) involved in the definition and 1987 specification of MPLS Transport Profile. 1989 This document was prepared using 2-Word-v2.0.template.dot. 1991 10. References 1993 10.1. Normative References 1995 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1996 Levels", BCP 14, RFC 2119, March 1997 1998 [2] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label 1999 Switching Architecture", RFC 3031, January 2001 2001 [3] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032, 2002 January 2001 2004 [4] Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in 2005 Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, 2006 January 2003 2008 [5] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge 2009 (PWE3) Architecture", RFC 3985, March 2005 2011 [6] Nadeau, T., Pignataro, S., "Pseudowire Virtual Circuit 2012 Connectivity Verification (VCCV): A Control Channel for 2013 Pseudowires", RFC 5085, December 2007 2015 [7] Bocci, M., Bryant, S., "An Architecture for Multi-Segment 2016 Pseudo Wire Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw- 2017 arch-05 (work in progress), September 2008 2019 [8] Bocci, M., et al., "A Framework for MPLS in Transport 2020 Networks", draft-ietf-mpls-tp-framework-06 (work in progress), 2021 October 2009 2023 [9] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R., 2024 "MPLS Generic Associated Channel", RFC 5586, June 2009 2026 [10] Swallow, G., Bocci, M., "MPLS-TP Identifiers", draft-ietf-mpls- 2027 tp-identifiers-00 (work in progress), November 2009 2029 10.2. Informative References 2031 [11] Niven-Jenkins, B., Brungard, D., Betts, M., sprecher, N., Ueno, 2032 S., "MPLS-TP Requirements", RFC 5654, September 2009 2034 [12] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in 2035 MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements- 2036 03 (work in progress), August 2009 2038 [13] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, Y., 2039 "MPLS-TP OAM Analysis", draft-ietf-mpls-tp-oam-analysis-00 2040 (work in progress), November 2009 2042 [14] Nichols, K., Blake, S., Baker, F., Black, D., "Definition of 2043 the Differentiated Services Field (DS Field) in the IPv4 and 2044 IPv6 Headers", RFC 2474, December 1998 2046 [15] Grossman, D., "New terminology and clarifications for 2047 Diffserv", RFC 3260, April 2002. 2049 [16] ITU-T Recommendation G.707/Y.1322 (01/07), "Network node 2050 interface for the synchronous digital hierarchy (SDH)", January 2051 2007 2053 [17] ITU-T Recommendation G.805 (03/00), "Generic functional 2054 architecture of transport networks", March 2000 2056 [18] ITU-T Recommendation G.806 (01/09), "Characteristics of 2057 transport equipment - Description methodology and generic 2058 functionality ", January 2009 2060 [19] ITU-T Recommendation G.826 (12/02), "End-to-end error 2061 performance parameters and objectives for international, 2062 constant bit-rate digital paths and connections", December 2002 2064 [20] ITU-T Recommendation G.7710 (07/07), "Common equipment 2065 management function requirements", July 2007 2067 [21] ITU-T Recommendation Y.2611 (06/12), " High-level architecture 2068 of future packet-based networks", 2006 2070 Authors' Addresses 2072 Dave Allan (Editor) 2073 Ericsson 2075 Email: david.i.allan@ericsson.com 2077 Italo Busi (Editor) 2078 Alcatel-Lucent 2080 Email: Italo.Busi@alcatel-lucent.com 2081 Ben Niven-Jenkins (Editor) 2082 BT 2084 Email: benjamin.niven-jenkins@bt.com 2086 Contributing Authors' Addresses 2088 Annamaria Fulignoli 2089 Ericsson 2091 Email: annamaria.fulignoli@ericsson.com 2093 Enrique Hernandez-Valencia 2094 Alcatel-Lucent 2096 Email: Enrique.Hernandez@alcatel-lucent.com 2098 Lieven Levrau 2099 Alcatel-Lucent 2101 Email: Lieven.Levrau@alcatel-lucent.com 2103 Dinesh Mohan 2104 Nortel 2106 Email: mohand@nortel.com 2108 Vincenzo Sestito 2109 Alcatel-Lucent 2111 Email: Vincenzo.Sestito@alcatel-lucent.com 2113 Nurit Sprecher 2114 Nokia Siemens Networks 2116 Email: nurit.sprecher@nsn.com 2117 Huub van Helvoort 2118 Huawei Technologies 2120 Email: hhelvoort@huawei.com 2122 Martin Vigoureux 2123 Alcatel-Lucent 2125 Email: Martin.Vigoureux@alcatel-lucent.com 2127 Yaacov Weingarten 2128 Nokia Siemens Networks 2130 Email: yaacov.weingarten@nsn.com 2132 Rolf Winter 2133 NEC 2135 Email: Rolf.Winter@nw.neclab.eu