idnits 2.17.1 draft-ietf-mpls-tp-oam-framework-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 21, 2010) is 5118 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-mpls-tp-identifiers-01 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-tp-oam-analysis-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: October 21, 2010 April 21, 2010 10 MPLS-TP OAM Framework 11 draft-ietf-mpls-tp-oam-framework-06.txt 13 Abstract 15 Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS- 16 TP) is based on a profile of the MPLS and pseudowire (PW) 17 procedures as specified in the MPLS Traffic Engineering (MPLS- 18 TE), PW and multi-segment PW (MS-PW) architectures complemented 19 with additional Operations, Administration and Maintenance (OAM) 20 procedures for fault, performance and protection-switching 21 management for packet transport applications that do not rely on 22 the presence of a control plane. 24 This document describes a framework to support a comprehensive 25 set of OAM procedures that fulfill the MPLS-TP OAM requirements. 27 This document is a product of a joint Internet Engineering Task 28 Force (IETF) / International Telecommunications Union 29 Telecommunication Standardization Sector (ITU-T) effort to 30 include an MPLS Transport Profile within the IETF MPLS and PWE3 31 architectures to support the capabilities and functionalities of 32 a packet transport network as defined by the ITU-T. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance 37 with the provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet 40 Engineering Task Force (IETF), its areas, and its working 41 groups. Note that other groups may also distribute working 42 documents as Internet-Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six 45 months and may be updated, replaced, or obsoleted by other 46 documents at any time. It is inappropriate to use Internet- 47 Drafts as reference material or to cite them other than as "work 48 in progress". 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/ietf/1id-abstracts.txt. 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html. 56 This Internet-Draft will expire on October 21, 2010. 58 Copyright Notice 60 Copyright (c) 2010 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with 68 respect to this document. Code Components extracted from this 69 document must include Simplified BSD License text as described 70 in Section 4.e of the Trust Legal Provisions and are provided 71 without warranty as described in the BSD License. 73 Table of Contents 75 1. Introduction...................................................5 76 1.1. Contributing Authors......................................6 77 2. Conventions used in this document..............................6 78 2.1. Terminology...............................................6 79 2.2. Definitions...............................................7 80 3. Functional Components..........................................9 81 3.1. Maintenance Entity and Maintenance Entity Group...........9 82 3.2. Nested MEGs: Path Segment Tunnels and Tandem Connection 83 Monitoring....................................................11 84 3.3. MEG End Points (MEPs)....................................13 85 3.4. MEG Intermediate Points (MIPs)...........................15 86 3.5. Server MEPs..............................................17 87 3.6. Configuration Considerations.............................18 88 3.7. P2MP considerations......................................18 89 4. Reference Model...............................................19 90 4.1. MPLS-TP Section Monitoring (SME).........................21 91 4.2. MPLS-TP LSP End-to-End Monitoring (LME)..................22 92 4.3. MPLS-TP PW Monitoring (PME)..............................23 93 4.4. MPLS-TP LSP Path Segment Tunnel Monitoring (LPSTME)......23 94 4.5. MPLS-TP MS-PW Path Segment Tunnel Monitoring (PPSTME)....25 95 4.6. Fate sharing considerations for multilink................26 96 5. OAM Functions for proactive monitoring........................27 97 5.1. Continuity Check and Connectivity Verification...........28 98 5.1.1. Defects identified by CC-V..........................29 99 5.1.2. Consequent action...................................31 100 5.1.3. Configuration considerations........................32 101 5.2. Remote Defect Indication.................................33 102 5.2.1. Configuration considerations........................34 103 5.3. Alarm Reporting..........................................34 104 5.4. Lock Reporting...........................................35 105 5.5. Packet Loss Measurement..................................36 106 5.5.1. Configuration considerations........................37 107 5.5.2. Sampling skew.......................................37 108 5.5.3. Multilink issues....................................37 109 5.6. Packet Delay Measurement.................................37 110 5.6.1. Configuration considerations........................38 111 5.7. Client Failure Indication................................38 112 5.7.1. Configuration considerations........................39 113 6. OAM Functions for on-demand monitoring........................39 114 6.1. Connectivity Verification................................40 115 6.1.1. Configuration considerations........................41 116 6.2. Packet Loss Measurement..................................41 117 6.2.1. Configuration considerations........................42 118 6.2.2. Sampling skew.......................................42 119 6.2.3. Multilink issues....................................42 121 6.3. Diagnostic Tests.........................................42 122 6.3.1. Throughput Estimation...............................42 123 6.3.2. Data plane Loopback.................................43 124 6.4. Route Tracing............................................44 125 6.4.1. Configuration considerations........................44 126 6.5. Packet Delay Measurement.................................45 127 6.5.1. Configuration considerations........................45 128 7. OAM Functions for administration control......................46 129 7.1. Lock Instruct............................................46 130 7.1.1. Locking a transport path............................46 131 7.1.2. Unlocking a transport path..........................46 132 8. Security Considerations.......................................47 133 9. IANA Considerations...........................................47 134 10. Acknowledgments..............................................48 135 11. References...................................................49 136 11.1. Normative References....................................49 137 11.2. Informative References..................................49 139 Editors' Note: 141 This Informational Internet-Draft is aimed at achieving IETF 142 Consensus before publication as an RFC and will be subject to an 143 IETF Last Call. 145 [RFC Editor, please remove this note before publication as an 146 RFC and insert the correct Streams Boilerplate to indicate that 147 the published RFC has IETF Consensus.] 149 1. Introduction 151 As noted in [5], the multi protocol label switching (MPLS) 152 transport profile (MPLS-TP) defines a profile of the MPLS- 153 Traffic Engineering (MPLS-TE) and Multi-segment Pseudo Wire 154 (MS-PW) architectures defined in RFC 3031 [1], RFC 3985 [2] and 155 RFC 5659 [4] which is complemented with additional OAM 156 mechanisms and procedures for alarm, fault, performance and 157 protection-switching management for packet transport 158 applications. 160 In line with [10], existing MPLS OAM mechanisms will be used 161 wherever possible and extensions or new OAM mechanisms will be 162 defined only where existing mechanisms are not sufficient to 163 meet the requirements. Extensions do not deprecate support for 164 existing MPLS OAM capabilities. 166 The MPLS-TP OAM framework defined in this document provides a 167 comprehensive set of OAM procedures that satisfy the MPLS-TP OAM 168 requirements [8]. In this regard, it defines similar OAM 169 functionality as for existing SONET/SDH and OTN OAM mechanisms 170 (e.g. [13]). 172 The MPLS-TP OAM framework is applicable to both LSPs and 173 (MS-)PWs and supports co-routed and associated bidirectional p2p 174 transport paths as well as unidirectional p2p and p2mp transport 175 paths. 177 This document is a product of a joint Internet Engineering Task 178 Force (IETF) / International Telecommunication Union 179 Telecommunication Standardization Sector (ITU-T) effort to 180 include an MPLS Transport Profile within the IETF MPLS and PWE3 181 architectures to support the capabilities and functionalities of 182 a packet transport network as defined by the ITU-T. 184 1.1. Contributing Authors 186 Dave Allan, Italo Busi, Ben Niven-Jenkins, Annamaria Fulignoli, 187 Enrique Hernandez-Valencia, Lieven Levrau, Dinesh Mohan, 188 Vincenzo Sestito, Nurit Sprecher, Huub van Helvoort, Martin 189 Vigoureux, Yaacov Weingarten, Rolf Winter 191 2. Conventions used in this document 193 2.1. Terminology 195 AC Attachment Circuit 197 DBN Domain Border Node 199 LER Label Edge Router 201 LME LSP Maintenance Entity Group 203 LSP Label Switched Path 205 LSR Label Switching Router 207 LPSTME LSP path segment tunnel ME Group 209 ME Maintenance Entity 211 MEG Maintenance Entity Group 213 MEP Maintenance Entity Group End Point 215 MIP Maintenance Entity Group Intermediate Point 217 PHB Per-hop Behavior 219 PME PW Maintenance Entity Group 221 PPSTME PW path segment tunnel ME Group 223 PST Path Segment Tunnel 225 PW Pseudowire 227 SLA Service Level Agreement 229 SME Section Maintenance Entity Group 231 2.2. Definitions 233 Note - the definitions in this section are aligned with ITU-T 234 recommendation Y.1731 in order to have a common, unambiguous 235 terminology. They do not however intend to imply a certain 236 implementation but rather serve as a framework to describe the 237 necessary OAM functions for MPLS-TP. 239 Data plane loopback: it is an out-of-service test where an 240 interface at either an intermediate or terminating node in a 241 path is placed into a data plane loopback state, such that all 242 traffic (including user data and OAM) received on the looped 243 back interface is sent on the reverse direction of the transport 244 path. 246 Domain Border Node (DBN): An LSP intermediate MPLS-TP node (LSR) 247 that is at the boundary of an MPLS-TP OAM domain. Such a node 248 may be present on the edge of two domains or may be connected by 249 a link to an MPLS-TP node in another OAM domain. 251 Down MEP: A MEP residing in a node that receives OAM packets 252 from, and transmits them towards, the direction of a server 253 layer. 255 In-Service: the administrative status of a transport path when 256 it is unlocked. 258 Intermediate Node: An intermediate node transits traffic for an 259 LSP or a PW. An intermediate node may originate OAM flows 260 directed to downstream intermediate nodes or MEPs. 262 Loopback: see data plane loopback and OAM loopback definitions. 264 Maintenance Entity (ME): Some portion of a transport path that 265 requires management bounded by two points, and the relationship 266 between those points to which maintenance and monitoring 267 operations apply (details in section 3.1). 269 Maintenance Entity Group (MEG): The set of one or more 270 maintenance entities that maintain and monitor a transport path 271 in an OAM domain. 273 MEP: A MEG end point (MEP) is capable of initiating (MEP Source) 274 and terminating (MEP Sink) OAM messages for fault management and 275 performance monitoring. MEPs define the boundaries of an ME 276 (details in section 3.3). 278 MEP Source: A MEP acts as MEP source for an OAM message when it 279 originates and inserts the message into the transport path for 280 its associated MEG. 282 MEP Sink: A MEP acts as a MEP sink for an OAM message when it 283 terminates and processes the messages received from its 284 associated MEG. 286 MIP: A MEG intermediate point (MIP) terminates and processes OAM 287 messages and may generate OAM messages in reaction to received 288 OAM messages. It never generates unsolicited OAM messages 289 itself. A MIP resides within a MEG between MEPs (details in 290 section 3.3). 292 OAM domain: A domain, as defined in [5], whose entities are 293 grouped for the purpose of keeping the OAM confined within that 294 domain. 296 Note - within the rest of this document the term "domain" is 297 used to indicate an "OAM domain" 299 OAM flow: Is the set of all OAM messages originating with a 300 specific MEP source that instrument one direction of a MEG. 302 OAM information element: An atomic piece of information 303 exchanged between MEPs in MEG used by an OAM application. 305 OAM loopback: it is the capability of a node to intercepts some 306 specific OAM packets and to generate a reply back to their 307 sender. OAM loopback can work in-service and can support 308 different OAM functions (e.g., bidirectional on-demand 309 connectivity verification). 311 OAM Message: One or more OAM information elements that when 312 exchanged between MEPs or between MEPs and MIPs performs some 313 OAM functionality (e.g. connectivity verification) 315 OAM Packet: A packet that carries one or more OAM messages (i.e. 316 OAM information elements). 318 Out-of-Service: the administrative status of a transport path 319 when it is locked. When a path is in a locked condition, it is 320 blocked from carrying client traffic. 322 Path Segment: It is either a segment or a concatenated segment, 323 as defined in RFC 5654 [5]. 325 Signal Fail: A condition declared by a MEP when the data 326 forwarding capability associated with a transport path has 327 failed, e.g. loss of continuity. See also [9]. 329 Tandem Connection: A tandem connection is an arbitrary part of a 330 transport path that can be monitored (via OAM) independent of 331 the end-to-end monitoring (OAM). The tandem connection may also 332 include the forwarding engine(s) of the node(s) at the 333 boundaries of the tandem connection. 335 Up MEP: A MEP residing in a node that transmits OAM packets 336 towards, and receives them from, the direction of the forwarding 337 engine. 339 This document uses the terms defined in RFC 5654 [5]. 341 This document uses the term 'Per-hop Behavior' as defined in 342 [11]. 344 This document uses the term LSP to indicate either a service LSP 345 or a transport LSP (as defined in [5]). 347 3. Functional Components 349 MPLS-TP defines a profile of the MPLS and PW architectures ([1], 350 [2] and [4]) that is required to transport service traffic where 351 the characteristics of information transfer between the 352 transport path endpoints can be demonstrated to comply with 353 certain performance and quality guarantees. 355 In order to describe the required OAM functionality, this 356 document introduces a set of high-level functional components. 358 3.1. Maintenance Entity and Maintenance Entity Group 360 MPLS-TP OAM operates in the context of Maintenance Entities 361 (MEs) that are a relationship between any two points of a 362 transport path to which maintenance and monitoring operations 363 apply. The collection of one or more MEs that belongs to the 364 same transport path and that are maintained and monitored as a 365 group are known as a maintenance entity group (MEG) and the two 366 points that define a maintenance entity are called Maintenance 367 Entity Group (MEG) End Points (MEPs). In between these two 368 points zero or more intermediate points, called Maintenance 369 Entity Group Intermediate Points (MIPs), can exist and can be 370 shared by more than one ME in a MEG. 372 The abstract reference model for an ME with MEPs and MIPs is 373 described in Figure 1 below: 375 +-+ +-+ +-+ +-+ 376 |A|----|B|----|C|----|D| 377 +-+ +-+ +-+ +-+ 379 Figure 1 ME Abstract Reference Model 381 The instantiation of this abstract model to different MPLS-TP 382 entities is described in section 4. In this model, nodes A, B, C 383 and D can be LER/LSR for an LSP or the {S|T}-PEs for a MS-PW. 384 MEPs reside in nodes A and D while MIPs reside in nodes B and C 385 and may reside in A and D. The links connecting adjacent nodes 386 can be physical links, (sub-)layer LSPs/PSTs, or serving layer 387 paths. 389 This functional model defines the relationships between all OAM 390 entities from a maintenance perspective, to allow each 391 Maintenance Entity to monitor and manage the (sub-)layer network 392 under its responsibility and to localize problems efficiently. 394 An MPLS-TP Maintenance Entity Group may be defined to monitor 395 the transport path for fault and/or performance management. 397 The MEPs that form a MEG are configured and managed to limit the 398 scope of an OAM flow within the MEG that the MEPs belong to 399 (i.e. within the domain of the transport path that is being 400 monitored and managed). A misbranching fault may cause OAM 401 packets to be delivered to a MEP that is not in the MEG of 402 origin. 404 In case of unidirectional point-to-point transport paths, a 405 single unidirectional Maintenance Entity is defined to monitor 406 it. 408 In case of associated bi-directional point-to-point transport 409 paths, two independent unidirectional Maintenance Entities are 410 defined to independently monitor each direction. This has 411 implications for transactions that terminate at or query a MIP, 412 as a return path from MIP to source MEP does not necessarily 413 exist in the MEG. 415 In case of co-routed bi-directional point-to-point transport 416 paths, a single bidirectional Maintenance Entity is defined to 417 monitor both directions congruently. 419 In case of unidirectional point-to-multipoint transport paths, a 420 single unidirectional Maintenance entity for each leaf is 421 defined to monitor the transport path from the root to that 422 leaf. 424 The reference model for the p2mp MEG is represented in Figure 2. 426 +-+ 427 /--|D| 428 / +-+ 429 +-+ 430 /--|C| 431 +-+ +-+/ +-+\ +-+ 432 |A|----|B| \--|E| 433 +-+ +-+\ +-+ +-+ 434 \--|F| 435 +-+ 437 Figure 2 Reference Model for p2mp MEG 439 In case of p2mp transport paths, the OAM operations are 440 independent for each ME (A-D, A-E and A-F): 442 o Fault conditions - some faults may impact more than one ME 443 depending from where the failure is located; 445 o Packet loss - packet dropping may impact more than one ME 446 depending from where the packets are lost; 448 o Packet delay - will be unique per ME. 450 Each leaf (i.e. D, E and F) terminates OAM flows to monitor the 451 ME from itself and the root while the root (i.e. A) generates 452 OAM messages common to all the MEs of the p2mp MEG. All nodes 453 may implement a MIP in the corresponding MEG. 455 3.2. Nested MEGs: Path Segment Tunnels and Tandem Connection 456 Monitoring 458 In order to verify and maintain performance and quality 459 guarantees, there is a need to not only apply OAM functionality 460 on a transport path granularity (e.g. LSP or MS-PW), but also on 461 arbitrary parts of transport paths, defined as Tandem 462 Connections, between any two arbitrary points along a transport 463 path. 465 Path segment tunnels (PSTs), as defined in [5], are instantiated 466 to provide monitoring of a portion of a set of co-routed 467 transport paths (LSPs or MS-PWs). Path segment tunnels can also 468 be employed to meet the requirement to provide tandem connection 469 monitoring (TCM). 471 TCM for a given path segment of a transport path is implemented 472 by creating a path segment tunnel that has a 1:1 association 473 with the path segment of the transport path that is to be 474 uniquely monitored. This means that the PST used to provide TCM 475 can carry only one and only one transport path thus allowing 476 direct correlation between all fault management and performance 477 monitoring information gathered for the PST and the monitored 478 path segment of the end-to-end transport path. The PST is 479 monitored using normal LSP monitoring. 481 There are a number of implications to this approach: 483 1) The PST would use the uniform model of TC code point copying 484 between sub-layers for diffserv such that the E2E markings 485 and PHB treatment for the transport path was preserved by the 486 PST. 488 2) The PST would use the pipe model for TTL handling such that 489 MIP addressing for the E2E entity would be not be impacted by 490 the presence of the PST. 492 3) PM statistics need to be adjusted for the encapsulation 493 overhead of the additional PST sub-layer. 495 A PST is instantiated to create a MEG that monitors a path 496 segment of a transport path (LSP or PW). The endpoints of the 497 PST are MEPs and limit the scope of an OAM flow within the MEG 498 the MEPs belong to (i.e. within the domain of the PST that is 499 being monitored and managed). 501 The following properties apply to all MPLS-TP MEGs: 503 o They can be nested but not overlapped, e.g. a MEG may cover a 504 segment or a concatenated segment of another MEG, and may 505 also include the forwarding engine(s) of the node(s) at the 506 edge(s) of the segment or concatenated segment. However when 507 MEGs are nested, the MEPs and MIPs in the nested MEG are no 508 longer part of the encompassing MEG. 510 o It is possible that MEPs of nested MEGs reside on a single 511 node but again implemented in such a way that they do not 512 overlap. 514 o Each OAM flow is associated with a single Maintenance Entity 515 Group. 517 o OAM packets that instrument a particular direction of a 518 transport path are subject to the same forwarding treatment 519 (i.e. fate share) as the data traffic and in some cases may 520 be required to have common queuing discipline E2E with the 521 class of traffic monitored. OAM packets can be distinguished 522 from the data traffic using the GAL and ACH constructs [6] 523 for LSP and Section or the ACH construct [3]and [6] for 524 (MS-)PW. 526 o When a PST is instantiated after the transport path has been 527 instantiated the addressing of the MIPs will change. 529 3.3. MEG End Points (MEPs) 531 MEG End Points (MEPs) are the source and sink points of a MEG. 532 In the context of an MPLS-TP LSP, only LERs can implement MEPs 533 while in the context of a path segment tunnel (PST) LSRs for the 534 MPLS-TP LSP can be LERs for PSTs that contribute to the overall 535 monitoring infrastructure for the transport path. Regarding 536 MPLS-TP PW, only T-PEs can implement MEPs while for PSTs 537 supporting a PW both T-PEs and S-PEs can implement MEPs. In the 538 context of MPLS-TP Section, any MPLS-TP LSR can implement a MEP 539 for a serving (sub-)layer PST. 541 MEPs are responsible for activating and controlling all of the 542 proactive and on demand monitoring OAM functionality for the 543 MEG. There is a separate class of server layer originated 544 notifications (such as LKR and AIS) that are originated by 545 intermediate nodes. A MEP is capable of originating and 546 terminating OAM messages for fault management and performance 547 monitoring. These OAM messages are encapsulated into an OAM 548 packet using the G-ACh as defined in RFC 5586 [6]: in this case 549 the G-ACh message is an OAM message and the channel type 550 indicates an OAM message. A MEP terminates all the OAM packets 551 it receives from the MEG it belongs to. The MEG the OAM packet 552 belongs to is inferred from the MPLS or PW label or, in case of 553 MPLS-TP section, the MPLS-TP port the OAM packet has been 554 received with the GAL at the top of the label stack. 556 OAM packets may require the use of an available "out-of-band" 557 return path (as defined in [5]). In such cases sufficient 558 information is required in the originating transaction such that 559 the OAM reply packet can be constructed (e.g. IP address). 561 Each OAM solution will further detail its applicability as a 562 pro-active or on-demand measurement as well as its usage when: 564 o the "in-band" return path exists and it is used; 566 o an "out-of-band" return path exists and it is used; 568 o any return path does not exist or is not used. 570 Once a MEG is configured, the operator can configure which 571 proactive OAM functions to use on the MEG but the MEPs are 572 always enabled. A node at the edge of a MEG always supports a 573 MEP. 575 MEPs terminate all OAM packets received from the associated MEG. 576 As the MEP corresponds to the termination of the forwarding path 577 for a MEG at the given (sub-)layer, OAM packets never leak 578 outside of a MEG in a properly configured fault free 579 implementation. 581 A MEP of an MPLS-TP transport path coincides with transport path 582 termination and monitors it for failures or performance 583 degradation (e.g. based on packet counts) in an end-to-end 584 scope. Note that both MEP source and MEP sink coincide with 585 transport paths' source and sink terminations. 587 The MEPs of a path segment tunnel are not necessarily coincident 588 with the termination of the MPLS-TP transport path and monitor a 589 path segment of the transport path for failures or performance 590 degradation (e.g. based on packet counts) only within the 591 boundary of the MEG for the path segment tunnel. 593 An MPLS-TP MEP sink passes a fault indication to its client 594 (sub-)layer network as a consequent action of fault detection. 596 A node at the edge of a MEG can either support per-node MEP or 597 per-interface MEP(s). A per-node MEP resides in an unspecified 598 location within the node while a per-interface MEP resides on a 599 specific side of the forwarding engine. In particular a per- 600 interface MEP is called "Up MEP" or "Down MEP" depending on its 601 location relative to the forwarding engine. 603 Source node Destination node 604 ------------------------ ------------------------ 605 | | | | 606 |----- -----| |----- -----| 607 | MEP | | | | | | MEP | 608 | | ---- | | | | ---- | | 609 | In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out | 610 | i/f | ---- | i/f | | i/f | ---- | i/f | 611 |----- -----| |----- -----| 612 | | | | 613 ------------------------ ------------------------ 614 (1) (2) 616 Figure 3 Example of per-interface Up MEPs 618 Figure 3 describes two examples of per-interface Up MEPs: an Up 619 Source MEP in a source node (case 1) and an Up Sink MEP in a 620 destination node (case 2). 622 The usage of per-interface Up MEPs extends the coverage of the 623 ME for both fault and performance monitoring closer to the edge 624 of the domain and allows the isolation of failures or 625 performance degradation to being within a node or either the 626 link or interfaces. 628 Each OAM solution will further detail the implications when used 629 with per-interface or per-node MEPs, if necessary. 631 It may occur that the Up MEPs of a path segment tunnel are set 632 on both sides of the forwarding engine such that the MEG is 633 entirely internal to the node. 635 Note that a MEP can only exist at the beginning and end of a 636 (sub-)layer in MPLS-TP. If there is a need to monitor some 637 portion of that LSP or PW, a new sub-layer in the form of a path 638 segment tunnel is created which permits MEPs and an associated 639 MEG to be created. 641 In the case where an intermediate node sends a message to a MEP, 642 it uses the top label of the stack at that point. 644 3.4. MEG Intermediate Points (MIPs) 646 A MEG Intermediate Point (MIP) is a function located at a point 647 between the MEPs of a MEG for a PW, LSP or PST. 649 A MIP is capable of reacting to some OAM packets and forwarding 650 all the other OAM packets while ensuring fate sharing with data 651 plane packets. However, a MIP does not initiate unsolicited OAM 652 packets, but may be addressed by OAM packets initiated by one of 653 the MEPs of the MEG. A MIP can generate OAM packets only in 654 response to OAM packets that are sent on the MEG it belongs to. 656 An intermediate node within a MEG can either: 658 o support per-node MIP (i.e. a single MIP per node in an 659 unspecified location within the node); 661 o support per-interface MIP (i.e. two or more MIPs per node on 662 both sides of the forwarding engine). 664 Intermediate node 665 ------------------------ 666 | | 667 |----- -----| 668 | MIP | | MIP | 669 | | ---- | | 670 ->-| In |->-| FW |->-| Out |->- 671 | i/f | ---- | i/f | 672 |----- -----| 673 | | 674 ------------------------ 675 Figure 4 Example of per-interface MIPs 677 Figure 4 describes an example of two per-interface MIPs at an 678 intermediate node of a point-to-point MEG. 680 The usage of per-interface MIPs allows the isolation of failures 681 or performance degradation to being within a node or either the 682 link or interfaces. 684 When sending an OAM packet to a MIP, the source MEP should set 685 the TTL field to indicate the number of hops necessary to reach 686 the node where the MIP resides. It is always assumed that the 687 "pipe"/"short pipe" model of TTL handling is used by the MPLS 688 transport profile. 690 The source MEP should also include Target MIP information in the 691 OAM packets sent to a MIP to allow proper identification of the 692 MIP within the node. The MEG the OAM packet is associated with 693 is inferred from the MPLS label. 695 A node at the edge of a MEG can also support per-interface Up 696 MEPs and per-interface MIPs on either side of the forwarding 697 engine. 699 Once a MEG is configured, the operator can enable/disable the 700 MIPs on the nodes within the MEG. All the intermediate nodes and 701 possibly the end nodes host MIP(s). Local policy allows them to 702 be enabled per function and per MEG. The local policy is 703 controlled by the management system, which may delegate it to 704 the control plane. 706 3.5. Server MEPs 708 A server MEP is a MEP of a MEG that is either: 710 o defined in a layer network that is "below", which is to say 711 encapsulates and transports the MPLS-TP layer network being 712 referenced, or 714 o defined in a sub-layer of the MPLS-TP layer network that is 715 "below" which is to say encapsulates and transports the sub- 716 layer being referenced. 718 A server MEP can coincide with a MIP or a MEP in the client 719 (MPLS-TP) (sub-)layer network. 721 A server MEP also interacts with the client/server adaptation 722 function between the client (MPLS-TP) (sub-)layer network and 723 the server (sub-)layer network. The adaptation function 724 maintains state on the mapping of MPLS-TP transport paths that 725 are setup over that server (sub-)layer's transport path. 727 For example, a server MEP can be either: 729 o A termination point of a physical link (e.g. 802.3), an SDH 730 VC or OTN ODU, for the MPLS-TP Section layer network, defined 731 in section 4.1; 733 o An MPLS-TP Section MEP for MPLS-TP LSPs, defined in section 734 4.2; 736 o An MPLS-TP LSP MEP for MPLS-TP PWs, defined in section 4.3; 738 o An MPLS-TP PST MEP used for LSP path segment monitoring, as 739 defined in section 4.4, for MPLS-TP LSPs or higher-level PSTs 740 providing LSP path segment monitoring; 742 o An MPLS-TP PST MEP used for PW path segment monitoring, as 743 defined in section 4.5, for MPLS-TP PWs or higher-level PSTs 744 providing PW path segment monitoring. 746 The server MEP can run appropriate OAM functions for fault 747 detection within the server (sub-)layer network, and provides a 748 fault indication to its client MPLS-TP layer network. Server MEP 749 OAM functions are outside the scope of this document. 751 3.6. Configuration Considerations 753 When a control plane is not present, the management plane 754 configures these functional components. Otherwise they can be 755 configured either by the management plane or by the control 756 plane. 758 Local policy allows to disable the usage of any available "out- 759 of-band" return path, as defined in [5], to generate OAM reply 760 packets, irrespectively on what is requested by the node 761 originating the OAM packet triggering the request. 763 PSTs are usually instantiated when the transport path is created 764 by either the management plane or by the control plane (if 765 present). Sometimes PST can be instantiated after the transport 766 path is initially created (e.g. PST). 768 3.7. P2MP considerations 770 All the traffic sent over a p2mp transport path, including OAM 771 packets generated by a MEP, is sent (multicast) from the root to 772 all the leaves. As a consequence: 774 o To send an OAM packet to all leaves, the source MEP can 775 send a single OAM packet that will be delivered by the 776 forwarding plane to all the leaves and processed by all the 777 leaves. 779 o To send an OAM packet to a single leaf, the source MEP 780 sends a single OAM packet that will be delivered by the 781 forwarding plane to all the leaves but contains sufficient 782 information to identify a target leaf, and therefore is 783 processed only by the target leaf and ignored by the other 784 leaves. 786 o To send an OAM packet to a single MIP, the source MEP sends 787 a single OAM packet with the TTL field indicating the 788 number of hops necessary to reach the node where the MIP 789 resides. This packet will be delivered by the forwarding 790 plane to all intermediate nodes at the same TTL distance of 791 the target MIP and to any leaf that is located at a shorter 792 distance. The OAM message must contain sufficient 793 information to identify the target MIP and therefore is 794 processed only by the target MIP. The source MEP should 795 also include Target MIP information in the OAM packet to 796 allow proper identification of the node and the MIP the OAM 797 packet is addressed to. 799 o In order to send an OAM packet to M leaves (i.e., a subset 800 of all the leaves), the source MEP sends M different OAM 801 packets targeted to each individual leaf in the group of M 802 leaves. Better mechanisms are outside the scope of this 803 document. 805 P2MP paths are unidirectional, therefore any return path to a 806 source MEP for on demand transactions will be out of band. A 807 mechanism to scope the set of MEPs or MIPs expected to respond 808 to a given "on demand" transaction is useful as it relieves the 809 source MEP of the requirement to filter and discard undesired 810 responses as normally TTL exhaust will address all MIPs at a 811 given distance from the source, and failure to exhaust TTL will 812 address all MEPs. 814 4. Reference Model 816 The reference model for the MPLS-TP framework builds upon the 817 concept of a MEG, and its associated MEPs and MIPs, to support 818 the functional requirements specified in [8]. 820 The following MPLS-TP MEGs are specified in this document: 822 o A Section Maintenance Entity Group (SME), allowing monitoring 823 and management of MPLS-TP Sections (between MPLS LSRs). 825 o An LSP Maintenance Entity Group (LME), allowing monitoring 826 and management of an end-to-end LSP (between LERs). 828 o A PW Maintenance Entity Group (PME), allowing monitoring and 829 management of an end-to-end SS/MS-PWs (between T-PEs). 831 o An LSP Path Segment Tunnel ME Group (LPSTME), allowing 832 monitoring and management of a path segment tunnel (between 833 any LERs/LSRs along an LSP). 835 o A PW Path Segment Tunnel ME Group (PPSTME), allowing 836 monitoring and management of an MPLS-TP path segment tunnel 837 (between any T-PEs/S-PEs along the (MS-)PW). 839 The MEGs specified in this MPLS-TP framework are compliant with 840 the architecture framework for MPLS-TP MS-PWs [4] and LSPs [1]. 842 Hierarchical LSPs are also supported in the form of path segment 843 tunnels. In this case, each LSP in the hierarchy is a different 844 sub-layer network that can be monitored, independently from 845 higher and lower level LSPs in the hierarchy, on an end-to-end 846 basis (from LER to LER) by a PSTME. It is possible to monitor a 847 portion of a hierarchical LSP by instantiating a hierarchical 848 PSTME between any LERs/LSRs along the hierarchical LSP. 850 Native |<------------------- MS-PW1Z ------------------->| Native 851 Layer | | Layer 852 Service | |<-LSP13->| |<-LSP3X->| |<-LSPXZ->| | Service 853 (AC1) V V LSP V V LSP V V LSP V V (AC2) 854 +----+ +-+ +----+ +----+ +-+ +----+ 855 +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ 856 | | | |=========| |=========| |=========| | | | 857 | CE1|---|........PW13.......|...PW3X..|........PWXZ.......|---|CE2 | 858 | | | |=========| |=========| |=========| | | | 859 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 860 +----+ +-+ +----+ +----+ +-+ +----+ 861 . . . . 862 | | | | 863 |<---- Domain 1 --->| |<---- Domain Z --->| 864 ^------------------- PW1Z PME -------------------^ 865 ^---- PW13 PPSTME---^ ^---- PWXZ PPSTME---^ 866 ^---------^ ^---------^ 867 LSP13 LME LSPXZ LME 868 ^---^ ^---^ ^---------^ ^---^ ^---^ 869 Sec12 Sec23 Sec3X SecXY SecYZ 870 SME SME SME SME SME 872 TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3 873 TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z 875 ^---^ ME ^ MEP ==== LSP .... PW 877 Figure 5 Reference Model for the MPLS-TP OAM Framework 879 Figure 5 depicts a high-level reference model for the MPLS-TP 880 OAM framework. The figure depicts portions of two MPLS-TP 881 enabled network domains, Domain 1 and Domain Z. In Domain 1, 882 LSR1 is adjacent to LSR2 via the MPLS Section Sec12 and LSR2 is 883 adjacent to LSR3 via the MPLS Section Sec23. Similarly, in 884 Domain Z, LSRX is adjacent to LSRY via the MPLS Section SecXY 885 and LSRY is adjacent to LSRZ via the MPLS Section SecYZ. In 886 addition, LSR3 is adjacent to LSRX via the MPLS Section 3X. 888 Figure 5 also shows a bi-directional MS-PW (PW1Z) between AC1 on 889 TPE1 and AC2 on TPEZ. The MS-PW consists of three bi-directional 890 PW path segments: 1) PW13 path segment between T-PE1 and S-PE3 891 via the bi-directional LSP13 LSP, 2) PW3X path segment between 892 S-PE3 and S-PEX, via the bi-directional LSP3X LSP, and 3) PWXZ 893 path segment between S-PEX and T-PEZ via the bi-directional 894 LSPXZ LSP. 896 The MPLS-TP OAM procedures that apply to a MEG are expected to 897 operate independently from procedures on other MEGs. Yet, this 898 does not preclude that multiple MEGs may be affected 899 simultaneously by the same network condition, for example, a 900 fiber cut event. 902 Note that there are no constrains imposed by this OAM framework 903 on the number, or type (p2p, p2mp, LSP or PW), of MEGs that may 904 be instantiated on a particular node. In particular, when 905 looking at Figure 3, it should be possible to configure one or 906 more MEPs on the same node if that node is the endpoint of one 907 or more MEGs. 909 Figure 5 does not describe a PW3X PPSTME because typically PSTs 910 are used to monitor an OAM domain (like PW13 and PWXZ PPSTMEs) 911 rather than the segment between two OAM domains. However the OAM 912 framework does not pose any constraints on the way PSTs are 913 instantiated as long as they are not overlapping. 915 The subsections below define the MEGs specified in this MPLS-TP 916 OAM architecture framework document. Unless otherwise stated, 917 all references to domains, LSRs, MPLS Sections, LSPs, 918 pseudowires and MEGs in this section are made in relation to 919 those shown in Figure 5. 921 4.1. MPLS-TP Section Monitoring (SME) 923 An MPLS-TP Section ME (SME) is an MPLS-TP maintenance entity 924 intended to an MPLS Section as defined in [5]. An SME may be 925 configured on any MPLS section. SME OAM packets must fate share 926 with the user data packets sent over the monitored MPLS Section. 928 An SME is intended to be deployed for applications where it is 929 preferable to monitor the link between topologically adjacent 930 (next hop in this layer network) MPLS (and MPLS-TP enabled) LSRs 931 rather than monitoring the individual LSP or PW path segments 932 traversing the MPLS Section and the server layer technology does 933 not provide adequate OAM capabilities. 935 Figure 5 shows 5 Section MEs configured in the network between 936 AC1 and AC2: 938 1. Sec12 ME associated with the MPLS Section between LSR 1 and 939 LSR 2, 941 2. Sec23 ME associated with the MPLS Section between LSR 2 and 942 LSR 3, 944 3. Sec3X ME associated with the MPLS Section between LSR 3 and 945 LSR X, 947 4. SecXY ME associated with the MPLS Section between LSR X and 948 LSR Y, and 950 5. SecYZ ME associated with the MPLS Section between LSR Y and 951 LSR Z. 953 4.2. MPLS-TP LSP End-to-End Monitoring (LME) 955 An MPLS-TP LSP ME (LME) is an MPLS-TP maintenance entity 956 intended to monitor an end-to-end LSP between two LERs. An LME 957 may be configured on any MPLS LSP. LME OAM packets must fate 958 share with user data packets sent over the monitored MPLS-TP 959 LSP. 961 An LME is intended to be deployed in scenarios where it is 962 desirable to monitor an entire LSP between its LERs, rather 963 than, say, monitoring individual PWs. 965 Figure 5 depicts 2 LMEs configured in the network between AC1 966 and AC2: 1) the LSP13 LME between LER 1 and LER 3, and 2) the 967 LSPXZ LME between LER X and LER Y. Note that the presence of a 968 LSP3X LME in such a configuration is optional, hence, not 969 precluded by this framework. For instance, the SPs may prefer to 970 monitor the MPLS-TP Section between the two LSRs rather than the 971 individual LSPs. 973 4.3. MPLS-TP PW Monitoring (PME) 975 An MPLS-TP PW ME (PME) is an MPLS-TP maintenance entity intended 976 to monitor a SS-PW or MS-PW between a pair of T-PEs. A PME can 977 be configured on any SS-PW or MS-PW. PME OAM packets must fate 978 share with the user data packets sent over the monitored PW. 980 A PME is intended to be deployed in scenarios where it is 981 desirable to monitor an entire PW between a pair of MPLS-TP 982 enabled T-PEs rather than monitoring the LSP aggregating 983 multiple PWs between PEs. 985 |<------------------- MS-PW1Z ------------------->| 986 | | 987 | |<-LSP13->| |<-LSP3X->| |<-LSPXZ->| | 988 V V LSP V V LSP V V LSP V V 989 +----+ +-+ +----+ +----+ +-+ +----+ 990 +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ 991 | |AC1| |=========| |=========| |=========| |AC2| | 992 | CE1|---|........PW13.......|...PW3X..|........PWXZ.......|---|CE2 | 993 | | | |=========| |=========| |=========| | | | 994 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 995 +----+ +-+ +----+ +----+ +-+ +----+ 997 ^---------------------PW1Z PME--------------------^ 999 Figure 6 MPLS-TP PW ME (PME) 1001 Figure 6 depicts a MS-PW (MS-PW1Z) consisting of three path 1002 segments: PW13, PW3X and PWXZ and its associated end-to-end PME 1003 (PW1Z PME). 1005 4.4. MPLS-TP LSP Path Segment Tunnel Monitoring (LPSTME) 1007 An MPLS-TP LSP Path Segment Tunnel ME (LPSTME) is an MPLS-TP LSP 1008 with associated maintenance entity intended to monitor an 1009 arbitrary part of an LSP between the pair of MEPs instantiated 1010 for the PST independent from the end-to-end monitoring (LME). An 1011 LPSTMEE can monitor an LSP segment or concatenated segment and 1012 it may also include the forwarding engine(s) of the node(s) at 1013 the edge(s) of the segment or concatenated segment. 1015 Multiple LPSTMEs can be configured on any LSP. The LSRs that 1016 terminate the LPSTME may or may not be immediately adjacent at 1017 the MPLS-TP layer. LPSTME OAM packets must fate share with the 1018 user data packets sent over the monitored LSP path segment. 1020 A LPSTME can be defined between the following entities: 1022 o The end node and any intermediate node of a given LSP. 1024 o Any two intermediate nodes of a given LSP. 1026 An LPSTME is intended to be deployed in scenarios where it is 1027 preferable to monitor the behaviour of a part of an LSP or set 1028 of LSPs rather than the entire LSP itself, for example when 1029 there is a need to monitor a part of an LSP that extends beyond 1030 the administrative boundaries of an MPLS-TP enabled 1031 administrative domain. 1033 |<--------------------- PW1Z -------------------->| 1034 | | 1035 | |<--------------LSP1Z LSP-------------->| | 1036 | |<-LSP13->| |<-LSP3X->| |<-LSPXZ->| | 1037 V V S-LSP V V S-LSP V V S-LSP V V 1038 +----+ +-+ +----+ +----+ +-+ +----+ 1039 +----+ | PE1| | | |DBN3| |DBNX| | | | PEZ| +----+ 1040 | |AC1| |=======================================| |AC2| | 1041 | CE1|---|......................PW1Z.......................|---|CE2 | 1042 | | | |=======================================| | | | 1043 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 1044 +----+ +-+ +----+ +----+ +-+ +----+ 1045 . . . . 1046 | | | | 1047 |<---- Domain 1 --->| |<---- Domain Z --->| 1049 ^---------^ ^---------^ 1050 LSP13 LPSTME LSPXZ LPSTME 1051 ^---------------------------------------^ 1052 LSP1Z LME 1054 DBN: Domain Border Node 1056 Figure 7 MPLS-TP LSP Path Segment Tunnel ME (LPSTME) 1058 Figure 7 depicts a variation of the reference model in Figure 5 1059 where there is an end-to-end LSP (LSP1Z) between PE1 and PEZ. 1060 LSP1Z consists of, at least, three LSP Concatenated Segments: 1061 LSP13, LSP3X and LSPXZ. In this scenario there are two separate 1062 LPSTMEs configured to monitor the LSP1Z: 1) a LPSTME monitoring 1063 the LSP13 Concatenated Segment on Domain 1 (LSP13 LPSTME), and 1064 2) a LPSTME monitoring the LSPXZ Concatenated Segment on Domain 1065 Z (LSPXZ LPSTME). 1067 It is worth noticing that LPSTMEs can coexist with the LME 1068 monitoring the end-to-end LSP and that LPSTME MEPs and LME MEPs 1069 can be coincident in the same node (e.g. PE1 node supports both 1070 the LSP1Z LME MEP and the LSP13 LPSTME MEP). 1072 4.5. MPLS-TP MS-PW Path Segment Tunnel Monitoring (PPSTME) 1074 An MPLS-TP MS-PW Path Segment Tunnel Monitoring ME (PPSTME) is 1075 an MPLS-TP maintenance entity intended to monitor an arbitrary 1076 part of an MS-PW between a given pair of PEs independently from 1077 the end-to-end monitoring (PME). A PPSTME can monitor a PW 1078 segment or concatenated segment and it may also include the 1079 forwarding engine(s) of the node(s) at the edge(s) of the 1080 segment or concatenated segment. 1082 S-PE placement is typically dictated by considerations other 1083 than OAM. S-PEs will frequently reside at operational boundaries 1084 such as the transition from distributed (CP) to centralized 1085 (NMS) control or at a routing area boundary. As such the 1086 architecture would superficially appear not to have the 1087 flexibility that arbitrary placement of PST segments would 1088 imply. More arbitrary placement of MEs for a PW would require 1089 additional hierarchical components, beyond the PSTs between PEs 1090 Multiple PPSTMEs can be configured on any MS-PW. The PEs may or 1091 may not be immediately adjacent at the MS-PW layer. PPSTME OAM 1092 packets fate share with the user data packets sent over the 1093 monitored PW path Segment. 1095 A PPSTME can be defined between the following entities: 1097 o T-PE and any S-PE of a given MS-PW 1099 o Any two S-PEs of a given MS-PW. It can span several PW 1100 segments. 1102 A PPSTME is intended to be deployed in scenarios where it is 1103 preferable to monitor the behaviour of a part of a MS-PW rather 1104 than the entire end-to-end PW itself, for example to monitor an 1105 MS-PW path segment within a given network domain of an inter- 1106 domain MS-PW. 1108 |<------------------- MS-PW1Z ------------------->| 1109 | | 1110 | |<-LSP13->| |<-LSP3X->| |<-LSPXZ->| | 1111 V V LSP V V LSP V V LSP V V 1112 +----+ +-+ +----+ +----+ +-+ +----+ 1113 +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ 1114 | |AC1| |=========| |=========| |=========| |AC2| | 1115 | CE1|---|........PW13.......|...PW3X..|........PWXZ.......|---|CE2 | 1116 | | | |=========| |=========| |=========| | | | 1117 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 1118 +----+ +-+ +----+ +----+ +-+ +----+ 1120 ^---- PW1 PPSTME----^ ^---- PW5 PPSTME----^ 1121 ^---------------------PW1Z PME--------------------^ 1123 Figure 8 MPLS-TP MS-PW Path Segment Tunnel Monitoring (PPSTME) 1125 Figure 8 depicts the same MS-PW (MS-PW1Z) between AC1 and AC2 as 1126 in Figure 6. In this scenario there are two separate PPSTMEs 1127 configured to monitor MS-PW1Z: 1) a PPSTME monitoring the PW13 1128 MS-PW path segment on Domain 1 (PW13 PPSTME), and 2) a PPSTME 1129 monitoring the PWXZ MS-PW path segment on Domain Z with (PWXZ 1130 PPSTME). 1132 It is worth noticing that PPSTMEs can coexist with the PME 1133 monitoring the end-to-end MS-PW and that PPSTME MEPs and PME 1134 MEPs can be coincident in the same node (e.g. TPE1 node supports 1135 both the PW1Z PME MEP and the PW13 PPSTME MEP). 1137 4.6. Fate sharing considerations for multilink 1139 Multilink techniques are in use today and are expected to 1140 continue to be used in future deployments. These techniques 1141 include Ethernet Link Aggregations [14], the use of Link 1142 Bundling for MPLS [13] where the option to spread traffic over 1143 component links is supported and enabled. While the use of Link 1144 Bundling can be controlled at the MPLS-TP layer, use of Link 1145 Aggregation (or any server layer specific multilink) is not 1146 necessarily under control of the MPLS-TP layer. Other techniques 1147 may emerge in the future. These techniques share in common the 1148 characteristic that an LSP may be spread over a set of component 1149 links and therefore be reordered but no flow within the LSP is 1150 reordered (except when very infrequent and minimally disruptive 1151 load rebalancing occurs). 1153 The use of multilink techniques may be prohibited or permitted 1154 in any particular deployment. If multilink techniques are used, 1155 the deployment can be considered to be only partially MPLS-TP 1156 compliant, however this is unlikely to prevent its use. 1158 The implications for OAM is that not all components of a 1159 multilink will be exercised, independent server layer OAM being 1160 required to exercise the aggregated link components. This has 1161 further implications for MIP and MEP placement, as per-interface 1162 MIPs or "down" MEPs on a multilink interface are akin to a layer 1163 violation, as they instrument at the granularity of the server 1164 layer. The implications for reduced OAM loss measurement 1165 functionality is documented in sections 5.5.3 and 6.2.3. 1167 5. OAM Functions for proactive monitoring 1169 In this document, proactive monitoring refers to OAM operations 1170 that are either configured to be carried out periodically and 1171 continuously or preconfigured to act on certain events such as 1172 alarm signals. 1174 Proactive monitoring is frequently "in-service" monitoring. The 1175 control and measurement implications are: 1177 1. Proactive monitoring for a MEG is typically configured at 1178 transport path creation time. 1180 2. The operational characteristics of in-band measurement 1181 transactions (e.g., CV, LM etc.) are configured at the MEPs. 1183 3. Server layer events are reported by transactions originating 1184 at intermediate nodes. 1186 4. The measurements resulting from proactive monitoring are 1187 typically only reported outside of the MEG as unsolicited 1188 notifications for "out of profile" events, such as faults or 1189 loss measurement indication of excessive impairment of 1190 information transfer capability. 1192 5. The measurements resulting from proactive monitoring may be 1193 periodically harvested by an EMS/NMS. 1195 For statically provisioned transport paths the above information 1196 is statically configured; for dynamically established transport 1197 paths the configuration information is signaled via the control 1198 plane or configured via the management plane. 1200 The operator enables/disables some of the consequent actions 1201 defined in section 5.1.2. 1203 5.1. Continuity Check and Connectivity Verification 1205 Proactive Continuity Check functions, as required in section 1206 2.2.2 of [8], are used to detect a loss of continuity defect 1207 (LOC) between two MEPs in a MEG. 1209 Proactive Connectivity Verification functions, as required in 1210 section 2.2.3 of [8], are used to detect an unexpected 1211 connectivity defect between two MEGs (e.g. mismerging or 1212 misconnection), as well as unexpected connectivity within the 1213 MEG with an unexpected MEP. 1215 Both functions are based on the (proactive) generation of OAM 1216 packets by the source MEP that are processed by the sink MEP. As 1217 a consequence these two functions are grouped together into 1218 Continuity Check and Connectivity Verification (CC-V) OAM 1219 packets. 1221 In order to perform pro-active Connectivity Verification 1222 function, each CC-V OAM packet also includes a globally unique 1223 Source MEP identifier. When used to perform only pro-active 1224 Continuity Check function, the CC-V OAM packet will not include 1225 any globally unique Source MEP identifier. Different formats of 1226 MEP identifiers are defined in [7] to address different 1227 environments. When MPLS-TP is deployed in transport network 1228 environments where IP addressing is not used in the forwarding 1229 plane, the ICC-based format for MEP identification is used. When 1230 MPLS-TP is deployed in IP-based environment, the IP-based MEP 1231 identification is used. 1233 As a consequence, it is not possible to detect misconnections 1234 between two MEGs monitored only for continuity as neither the 1235 OAM message type nor OAM message content provides sufficient 1236 information to disambiguate an invalid source. To expand: 1238 o For CC leaking into a CC monitored MEG - undetectable 1240 o For CV leaking into a CC monitored MEG - presence of 1241 additional Source MEP identifier allows detecting the fault 1243 o For CC leaking into a CV monitored MEG - lack of additional 1244 Source MEP identifier allows detecting the fault. 1246 o For CV leaking into a CV monitored MEG - different Source MEP 1247 identifier permits fault to be identified. 1249 CC-V OAM packets are transmitted at a regular, operator's 1250 configurable, rate. The default CC-V transmission periods are 1251 application dependent (see section 5.1.3). 1253 Proactive CC-V OAM packets are transmitted with the "minimum 1254 loss probability PHB" within the transport path (LSP, PW) they 1255 are monitoring. This PHB is configurable on network operator's 1256 basis. PHBs can be translated at the network borders by the same 1257 function that translates it for user data traffic. The 1258 implication is that CC-V fate shares with much of the forwarding 1259 implementation, but not all aspects of PHB processing are 1260 exercised. Either on demand tools are used for finer grained 1261 fault finding or an implementation may utilize a CC-V flow per 1262 PHB with the entire E-LSP fate sharing with any individual PHB. 1264 In a bidirectional point-to-point transport path, when a MEP is 1265 enabled to generate pro-active CC-V OAM packets with a 1266 configured transmission rate, it also expects to receive pro- 1267 active CC-V OAM packets from its peer MEP at the same 1268 transmission rate as a common SLA applies to all components of 1269 the transport path. In a unidirectional transport path (either 1270 point-to-point or point-to-multipoint), only the source MEP is 1271 enabled to generate CC-V OAM packets and only the sink MEP is 1272 configured to expect these packets at the configured rate. 1274 MIPs, as well as intermediate nodes not supporting MPLS-TP OAM, 1275 are transparent to the pro-active CC-V information and forward 1276 these pro-active CC-V OAM packets as regular data packets. 1278 During path setup and tear down, situations arise where CC-V 1279 checks would give rise to alarms, as the path is not fully 1280 instantiated. In order to avoid these spurious alarms the 1281 following procedures are recommended. At initialization, the MEP 1282 source function (generating pro-active CC-V packets) should be 1283 enabled prior to the corresponding MEP sink function (detecting 1284 continuity and connectivity defects). When disabling the CC-V 1285 proactive functionality, the MEP sink function should be 1286 disabled prior to the corresponding MEP source function. 1288 5.1.1. Defects identified by CC-V 1290 Pro-active CC-V functions allow a sink MEP to detect the defect 1291 conditions described in the following sub-sections. For all of 1292 the described defect cases, the sink MEP should notify the 1293 equipment fault management process of the detected defect. 1295 5.1.1.1. Loss Of Continuity defect 1297 When proactive CC-V is enabled, a sink MEP detects a loss of 1298 continuity (LOC) defect when it fails to receive pro-active CC-V 1299 OAM packets from the peer MEP. 1301 o Entry criteria: if no pro-active CC-V OAM packets from the 1302 peer MEP with the correct encapsulation (and in the case of 1303 CV, this includes the requirement to have a correct globally 1304 unique Source MEP identifier) are received within the 1305 interval equal to 3.5 times the receiving MEP's configured 1306 CC-V reception period. 1308 o Exit criteria: a pro-active CC-V OAM packet from the peer MEP 1309 with the correct encapsulation (and again in the case of CV, 1310 with the correct globally unique Source MEP identifier) is 1311 received. 1313 5.1.1.2. Mis-connectivity defect 1315 When a pro-active CC-V OAM packet is received, a sink MEP 1316 identifies a mis-connectivity defect (e.g. mismerge, 1317 misconnection or unintended looping) with its peer source MEP 1318 when the received packet carries an incorrect globally unique 1319 Source MEP identifier. 1321 o Entry criteria: the sink MEP receives a pro-active CC-V OAM 1322 packet with an incorrect globally unique Source MEP 1323 identifier. 1325 o Exit criteria: the sink MEP does not receive any pro-active 1326 CC-V OAM packet with an incorrect globally unique Source MEP 1327 identifier for an interval equal at least to 3.5 times the 1328 longest transmission period of the pro-active CC-V OAM 1329 packets received with an incorrect globally unique Source MEP 1330 identifier since this defect has been raised. This requires 1331 the OAM message to self identify the CC-V periodicity as not 1332 all MEPs can be expected to have knowledge of all MEGs. 1334 5.1.1.3. Period Misconfiguration defect 1336 If pro-active CC-V OAM packets are received with a correct 1337 globally unique Source MEP identifier but with a transmission 1338 period different than the locally configured reception period, 1339 then a CV period mis-configuration defect is detected. 1341 o Entry criteria: a MEP receives a CC-V pro-active packet with 1342 correct globally unique Source MEP identifier but with a 1343 Period field value different than its own CC-V configured 1344 transmission period. 1346 o Exit criteria: the sink MEP does not receive any pro-active 1347 CC-V OAM packet with a correct globally unique Source MEP 1348 identifier and an incorrect transmission period for an 1349 interval equal at least to 3.5 times the longest transmission 1350 period of the pro-active CC-V OAM packets received with a 1351 correct globally unique Source MEP identifier and an 1352 incorrect transmission period since this defect has been 1353 raised. 1355 5.1.2. Consequent action 1357 A sink MEP that detects one of the defect conditions defined in 1358 section 5.1.1 performs the following consequent actions. 1360 If a MEP detects an unexpected globally unique Source MEP 1361 Identifier, it blocks all the traffic (including also the user 1362 data packets) that it receives from the misconnected transport 1363 path. 1365 If a MEP detects LOC defect that is not caused by a period 1366 mis-configuration, it should block all the traffic (including 1367 also the user data packets) that it receives from the transport 1368 path, if this consequent action has been enabled by the 1369 operator. 1371 It is worth noticing that the OAM requirements document [8] 1372 recommends that CC-V proactive monitoring be enabled on every 1373 MEG in order to reliably detect connectivity defects. However, 1374 CC-V proactive monitoring can be disabled by an operator for a 1375 MEG. In the event of a misconnection between a transport path 1376 that is pro-actively monitored for CC-V and a transport path 1377 which is not, the MEP of the former transport path will detect a 1378 LOC defect representing a connectivity problem (e.g. a 1379 misconnection with a transport path where CC-V proactive 1380 monitoring is not enabled) instead of a continuity problem, with 1381 a consequent wrong traffic delivering. For these reasons, the 1382 traffic block consequent action is applied even when a LOC 1383 condition occurs. This block consequent action can be disabled 1384 through configuration. This deactivation of the block action may 1385 be used for activating or deactivating the monitoring when it is 1386 not possible to synchronize the function activation of the two 1387 peer MEPs. 1389 If a MEP detects a LOC defect (section 5.1.1.1), a 1390 mis-connectivity defect (section 5.1.1.2) or a period 1391 misconfiguration defect (section 5.1.1.3), it declares a signal 1392 fail condition at the transport path level. 1394 5.1.3. Configuration considerations 1396 At all MEPs inside a MEG, the following configuration 1397 information needs to be configured when a proactive CC-V 1398 function is enabled: 1400 o MEG ID; the MEG identifier to which the MEP belongs; 1402 o MEP-ID; the MEP's own identity inside the MEG; 1404 o list of peer MEPs inside the MEG. For a point-to-point MEG 1405 the list would consist of the single peer MEP ID from which 1406 the OAM packets are expected. In case of the root MEP of a 1407 p2mp MEG, the list is composed by all the leaf MEP IDs inside 1408 the MEG. In case of the leaf MEP of a p2mp MEG, the list is 1409 composed by the root MEP ID (i.e. each leaf needs to know the 1410 root MEP ID from which it expect to receive the CC-V OAM 1411 packets). 1413 o PHB; it identifies the per-hop behaviour of CC-V packet. 1414 Proactive CC-V packets are transmitted with the "minimum loss 1415 probability PHB" previously configured within a single 1416 network operator. This PHB is configurable on network 1417 operator's basis. PHBs can be translated at the network 1418 borders. 1420 o transmission rate; the default CC-V transmission periods are 1421 application dependent (depending on whether they are used to 1422 support fault management, performance monitoring, or 1423 protection switching applications): 1425 o Fault Management: default transmission period is 1s (i.e. 1426 transmission rate of 1 packet/second). 1428 o Performance Monitoring: default transmission period is 1429 100ms (i.e. transmission rate of 10 packets/second). 1430 Performance monitoring is only relevant when the 1431 transport path is defect free. CC-V contributes to the 1432 accuracy of PM statistics by permitting the defect free 1433 periods to be properly distinguished. 1435 o Protection Switching: default transmission period is 1436 3.33ms (i.e. transmission rate of 300 packets/second), in 1437 order to achieve sub-50ms the CC-V defect entry criteria 1438 should resolve in less than 10msec, and complete a 1439 protection switch within a subsequent period of 50 msec. 1440 It is also possible to lengthen the transmission period 1441 to 10ms (i.e. transmission rate of 100 packets/second): 1442 in this case the CC-V defect entry criteria resolves is 1443 longer (i.e. 30msec). 1445 It should be possible for the operator to configure these 1446 transmission rates for all applications, to satisfy his internal 1447 requirements. 1449 Note that the reception period is the same as the configured 1450 transmission rate. 1452 For statically provisioned transport paths the above information 1453 are statically configured; for dynamically established transport 1454 paths the configuration information are signaled via the control 1455 plane. 1457 The operator should be able to enable/disable some of the 1458 consequent actions defined in section 5.1.2. 1460 5.2. Remote Defect Indication 1462 The Remote Defect Indication (RDI) function, as required in 1463 section 2.2.9 of [8], is an indicator that is transmitted by a 1464 MEP to communicate to its peer MEPs that a signal fail condition 1465 exists. RDI is only used for bidirectional connections and is 1466 associated with proactive CC-V activation. The RDI indicator is 1467 piggy-backed onto the CC-V packet. 1469 When a MEP detects a signal fail condition (e.g. in case of a 1470 continuity or connectivity defect), it should begin transmitting 1471 an RDI indicator to its peer MEP. The RDI information will be 1472 included in all pro-active CC-V packets that it generates for 1473 the duration of the signal fail condition's existence. 1475 A MEP that receives the packets with the RDI information should 1476 determine that its peer MEP has encountered a defect condition 1477 associated with a signal fail. 1479 MIPs as well as intermediate nodes not supporting MPLS-TP OAM 1480 are transparent to the RDI indicator and forward these proactive 1481 CC-V packets that include the RDI indicator as regular data 1482 packets, i.e. the MIP should not perform any actions nor examine 1483 the indicator. 1485 When the signal fail defect condition clears, the MEP should 1486 clear the RDI indicator from subsequent transmission of pro- 1487 active CC-V packets. A MEP should clear the RDI defect upon 1488 reception of a pro-active CC-V packet from the source MEP with 1489 the RDI indicator cleared. 1491 5.2.1. Configuration considerations 1493 In order to support RDI indication, this may be a unique OAM 1494 message or an OAM information element embedded in a CV message. 1495 In this case the RDI transmission rate and PHB of the OAM 1496 packets carrying RDI should be the same as that configured for 1497 CC-V. 1499 5.3. Alarm Reporting 1501 The Alarm Reporting function, as required in section 2.2.8 of 1502 [8], relies upon an Alarm Indication Signal (AIS) message to 1503 suppress alarms following detection of defect conditions at the 1504 server (sub-)layer. 1506 When a server MEP asserts signal fail, the MPLS-TP client 1507 (sub-)layer adaptation function generates packets with AIS 1508 information in the downstream direction to allow the suppression 1509 of secondary alarms at the MEP in the client (sub-)layer. 1511 The generation of packets with AIS information starts 1512 immediately when the server MEP asserts signal fail. These 1513 periodic packets, with AIS information, continue to be 1514 transmitted until the signal fail condition is cleared. 1516 Upon receiving a packet with AIS information an MPLS-TP MEP 1517 enters an AIS defect condition and suppresses loss of continuity 1518 alarms associated with its peer MEP. A MEP resumes loss of 1519 continuity alarm generation upon detecting loss of continuity 1520 defect conditions in the absence of AIS condition. 1522 For example, let's consider a fiber cut between LSR 1 and LSR 2 1523 in the reference network of Figure 5. Assuming that all the MEGs 1524 described in Figure 5 have pro-active CC-V enabled, a LOC defect 1525 is detected by the MEPs of Sec12 SME, LSP13 LME, PW1 PPSTME and 1526 PW1Z PME, however in transport network only the alarm associate 1527 to the fiber cut needs to be reported to NMS while all these 1528 secondary alarms should be suppressed (i.e. not reported to the 1529 NMS or reported as secondary alarms). 1531 If the fiber cut is detected by the MEP in the physical layer 1532 (in LSR2), LSR2 can generate the proper alarm in the physical 1533 layer and suppress the secondary alarm associated with the LOC 1534 defect detected on Sec12 SME. As both MEPs reside within the 1535 same node, this process does not involve any external protocol 1536 exchange. Otherwise, if the physical layer has not enough OAM 1537 capabilities to detect the fiber cut, the MEP of Sec12 SME in 1538 LSR2 will report a LOC alarm. 1540 In both cases, the MEP of Sec12 SME in LSR 2 notifies the 1541 adaptation function for LSP13 LME that then generates AIS 1542 packets on the LSP13 LME in order to allow its MEP in LSR3 to 1543 suppress the LOC alarm. LSR3 can also suppress the secondary 1544 alarm on PW13 PPSTME because the MEP of PW13 PPSTME resides 1545 within the same node as the MEP of LSP13 LME. The MEP of PW13 1546 PPSTME in LSR3 also notifies the adaptation function for PW1Z 1547 PME that then generates AIS packets on PW1Z PME in order to 1548 allow its MEP in LSRZ to suppress the LOC alarm. 1550 The generation of AIS packets for each MEG in the MPLS-TP client 1551 (sub-)layer is configurable (i.e. the operator can 1552 enable/disable the AIS generation). 1554 AIS packets are transmitted with the "minimum loss probability 1555 PHB" within a single network operator. This PHB is configurable 1556 on network operator's basis. 1558 A MIP is transparent to packets with AIS information and 1559 therefore does not require any information to support AIS 1560 functionality. 1562 5.4. Lock Reporting 1564 The Lock Reporting function, as required in section 2.2.7 of 1565 [8], relies upon a Locked Report (LKR) message used to suppress 1566 alarms following administrative locking action in the server 1567 (sub-)layer. 1569 When a server MEP is locked or receives a lock report, the 1570 MPLS-TP client (sub-)layer adaptation function generates packets 1571 with LKR information in both directions to allow the suppression 1572 of secondary alarms at the MEPs in the client (sub-)layer. 1574 The generation of packets with LKR information starts 1575 immediately when the server MEP is locked. These periodic 1576 packets, with LKR information, continue to be transmitted until 1577 the locked condition is cleared. 1579 Upon receiving a packet with LKR information an MPLS-TP MEP 1580 enters an LKR defect condition and suppresses loss of continuity 1581 alarm associated with its peer MEP. A MEP resumes loss of 1582 continuity alarm generation upon detecting loss of continuity 1583 defect conditions in the absence of LKR condition. 1585 The generation of LKR packets for each MEG in the MPLS-TP client 1586 (sub-)layer is configurable (i.e. the operator can 1587 enable/disable the LKR generation). 1589 LKR packets are transmitted with the "minimum loss probability 1590 PHB" within a single network operator. This PHB is configurable 1591 on network operator's basis. 1593 A MIP is transparent to packets with LKR information and 1594 therefore does not require any information to support LKR 1595 functionality. 1597 5.5. Packet Loss Measurement 1599 Packet Loss Measurement (LM) is one of the capabilities 1600 supported by the MPLS-TP Performance Monitoring (PM) function in 1601 order to facilitate reporting of QoS information for a transport 1602 path as required in section 2.2.11 of [8]. LM is used to 1603 exchange counter values for the number of ingress and egress 1604 packets transmitted and received by the transport path monitored 1605 by a pair of MEPs. 1607 Proactive LM is performed by periodically sending LM OAM packets 1608 from a MEP to a peer MEP and by receiving LM OAM packets from 1609 the peer MEP (if a bidirectional transport path) during the life 1610 time of the transport path. Each MEP performs measurements of 1611 its transmitted and received packets. These measurements are 1612 then transactionally correlated with the peer MEP in the ME to 1613 derive the impact of packet loss on a number of performance 1614 metrics for the ME in the MEG. The LM transactions are issued 1615 such that the OAM packets will experience the same queuing 1616 discipline as the measured traffic while transiting between the 1617 MEPs in the ME. 1619 In order to support proactive LM, the transmission rate and PHB 1620 associated with the LM OAM packets originating from a MEP need 1621 be configured as part of the LM provisioning procedures. LM OAM 1622 packets are transmitted with the same PHB class that the LM is 1623 intended to measure. If that PHB is not an ordered aggregate 1624 where the ordering constraint is all packets with the PHB class 1625 being delivered in order, LM can produce inconsistent results. 1627 For a MEP, near-end packet loss refers to packet loss associated 1628 with incoming data packets (from the far-end MEP) while far-end 1629 packet loss refers to packet loss associated with egress data 1630 packets (towards the far-end MEP). 1632 5.5.1. Configuration considerations 1634 In order to support proactive LM, the transmission rate and PHB 1635 associated with the LM OAM packets originating from a MEP need 1636 be configured as part of the LM provisioning procedures. LM OAM 1637 packets should be transmitted with the same PHB class that the 1638 LM is intended to measure. If that PHB is not an ordered 1639 aggregate where the ordering constraint is all packets with the 1640 PHB being delivered in order, LM can produce inconsistent 1641 results. 1643 5.5.2. Sampling skew 1645 If an implementation makes use of a hardware forwarding path 1646 which operates in parallel with an OAM processing path, whether 1647 hardware or software based, the packet and byte counts may be 1648 skewed if one or more packets can be processed before the OAM 1649 processing samples counters. If OAM is implemented in software 1650 this error can be quite large. 1652 5.5.3. Multilink issues 1654 If multilink is used at the LSP ingress or egress, there may be 1655 no single packet processing engine where to inject or extract a 1656 LM packet as an atomic operation to which accurate packet and 1657 byte counts can be associated with the packet. 1659 In the case where multilink is encountered in the LSP path, the 1660 reordering of packets within the LSP can cause inaccurate LM 1661 results. 1663 5.6. Packet Delay Measurement 1665 Packet Delay Measurement (DM) is one of the capabilities 1666 supported by the MPLS-TP PM function in order to facilitate 1667 reporting of QoS information for a transport path as required in 1668 section 2.2.12 of [8]. Specifically, pro-active DM is used to 1669 measure the long-term packet delay and packet delay variation in 1670 the transport path monitored by a pair of MEPs. 1672 Proactive DM is performed by sending periodic DM OAM packets 1673 from a MEP to a peer MEP and by receiving DM OAM packets from 1674 the peer MEP (if a bidirectional transport path) during a 1675 configurable time interval. 1677 Pro-active DM can be operated in two ways: 1679 o One-way: a MEP sends DM OAM packet to its peer MEP containing 1680 all the required information to facilitate one-way packet 1681 delay and/or one-way packet delay variation measurements at 1682 the peer MEP. Note that this requires synchronized precision 1683 time at either MEP by means outside the scope of this 1684 framework. 1686 o Two-way: a MEP sends DM OAM packet with a DM request to its 1687 peer MEP, which replies with a DM OAM packet as a DM 1688 response. The request/response DM OAM packets containing all 1689 the required information to facilitate two-way packet delay 1690 and/or two-way packet delay variation measurements from the 1691 viewpoint of the source MEP. 1693 5.6.1. Configuration considerations 1695 In order to support pro-active DM, the transmission rate and PHB 1696 associated with the DM OAM packets originating from a MEP need 1697 be configured as part of the DM provisioning procedures. DM OAM 1698 packets should be transmitted with the PHB that yields the 1699 lowest packet loss performance among the PHB Scheduling Classes 1700 or Ordered Aggregates (see RFC 3260 [12]) in the monitored 1701 transport path for the relevant network domain(s). 1703 5.7. Client Failure Indication 1705 The Client Failure Indication (CFI) function, as required in 1706 section 2.2.10 of [8], is used to help process client defects 1707 and propagate a client signal defect condition from the process 1708 associated with the local attachment circuit where the defect 1709 was detected (typically the source adaptation function for the 1710 local client interface) to the process associated with the far- 1711 end attachment circuit (typically the source adaptation function 1712 for the far-end client interface) for the same transmission path 1713 in case the client of the transport path does not support a 1714 native defect/alarm indication mechanism, e.g. AIS. 1716 A source MEP starts transmitting a CFI indication to its peer 1717 MEP when it receives a local client signal defect notification 1718 via its local CSF function. Mechanisms to detect local client 1719 signal fail defects are technology specific. 1721 A sink MEP that has received a CFI indication report this 1722 condition to its associated client process via its local CFI 1723 function. Consequent actions toward the client attachment 1724 circuit are technology specific. 1726 Either there needs to be a 1:1 correspondence between the client 1727 and the MEG, or when multiple clients are multiplexed over a 1728 transport path, the CFI message requires additional information 1729 to permit the client instance to be identified. 1731 5.7.1. Configuration considerations 1733 In order to support CFI indication, the CFI transmission rate 1734 and PHB of the CFI OAM message/information element should be 1735 configured as part of the CFI configuration. 1737 6. OAM Functions for on-demand monitoring 1739 In contrast to proactive monitoring, on-demand monitoring is 1740 initiated manually and for a limited amount of time, usually for 1741 operations such as e.g. diagnostics to investigate into a defect 1742 condition. 1744 On-demand monitoring covers a combination of "in-service" and 1745 "out-of-service" monitoring functions. The control and 1746 measurement implications are: 1748 1. A MEG can be directed to perform an "on-demand" functions at 1749 arbitrary times in the lifetime of a transport path. 1751 2. "out-of-service" monitoring functions may require a-priori 1752 configuration of both MEPs and intermediate nodes in the MEG 1753 (e.g., data plane loopback) and the issuance of notifications 1754 into client layers of the transport path being removed from 1755 service (e.g., lock-reporting) 1757 3. The measurements resulting from on-demand monitoring are 1758 typically harvested in real time, as these are frequently 1759 craftsperson initiated and attended. These do not necessarily 1760 require different harvesting mechanisms that that for 1761 harvesting proactive monitoring telemetry. 1763 The functions that are exclusive out-of-service are those 1764 described in section 6.3. The remainder are applicable to both 1765 in-service and out-of-service transport paths. 1767 6.1. Connectivity Verification 1769 In order to preserve network resources, e.g. bandwidth, 1770 processing time at switches, it may be preferable to not use 1771 proactive CC-V. In order to perform fault management functions, 1772 network management may invoke periodic on-demand bursts of on- 1773 demand CV packets, as required in section 2.2.3 of [8]. 1775 Use of on-demand CV is dependent on the existence of either a 1776 bi-directional ME, or an associated return ME, or the 1777 availability of an out of band return path because it requires 1778 the ability for target MIPs and MEPs to direct responses to the 1779 originating MEPs. 1781 An additional use of on-demand CV would be to detect and locate 1782 a problem of connectivity when a problem is suspected or known 1783 based on other tools. In this case the functionality will be 1784 triggered by the network management in response to a status 1785 signal or alarm indication. 1787 On-demand CV is based upon generation of on-demand CV packets 1788 that should uniquely identify the MEG that is being checked. 1789 The on-demand functionality may be used to check either an 1790 entire MEG (end-to-end) or between a MEP to a specific MIP. This 1791 functionality may not be available for associated bidirectional 1792 transport paths or unidirectional paths, as the MIP may not have 1793 a return path to the source MEP for the on-demand CV 1794 transaction. 1796 On-demand CV may generate a one-time burst of on-demand CV 1797 packets, or be used to invoke periodic, non-continuous, bursts 1798 of on-demand CV packets. The number of packets generated in 1799 each burst is configurable at the MEPs, and should take into 1800 account normal packet-loss conditions. 1802 When invoking a periodic check of the MEG, the source MEP should 1803 issue a burst of on-demand CV packets that uniquely identifies 1804 the MEG being verified. The number of packets and their 1805 transmission rate should be pre-configured and known to both the 1806 source MEP and the target MEP or MIP. The source MEP should use 1807 the mechanisms defined in sections 3.3 and 3.4 when sending an 1808 on-demand CV packet to a target MEP or target MIP respectively. 1809 The target MEP/MIP shall return a reply on-demand CV packet for 1810 each packet received. If the expected number of on-demand CV 1811 reply packets is not received at source MEP, the LOC defect 1812 state is entered. 1814 On demand CV should have the ability to carry padding such that 1815 a variety of MTU sizes can be originated to verify the MTU 1816 capacity of the transport path. 1818 6.1.1. Configuration considerations 1820 For on-demand CV the MEP should support the configuration of the 1821 number of packets to be transmitted/received in each burst of 1822 transmissions and their packet size. The transmission rate 1823 should be configured between the different nodes. 1825 In addition, when the CV packet is used to check connectivity 1826 toward a target MIP, the number of hops to reach the target MIP 1827 should be configured. 1829 The PHB of the on-demand CV packets should be configured as 1830 well. This permits the verification of correct operation of QoS 1831 queuing as well as connectivity. 1833 6.2. Packet Loss Measurement 1835 On-demand Packet Loss Measurement (LM) is one of the 1836 capabilities supported by the MPLS-TP Performance Monitoring 1837 function in order to facilitate diagnostic of QoS performance 1838 for a transport path, as required in section 2.2.11 of [8]. As 1839 proactive LM, on-demand LM is used to exchange counter values 1840 for the number of ingress and egress packets transmitted and 1841 received by the transport path monitored by a pair of MEPs. 1843 On-demand LM is performed by periodically sending LM OAM packets 1844 from a MEP to a peer MEP and by receiving LM OAM packets from 1845 the peer MEP (if a bidirectional transport path) during a pre- 1846 defined monitoring period. Each MEP performs measurements of its 1847 transmitted and received packets. These measurements are then 1848 correlated evaluate the packet loss performance metrics of the 1849 transport path. 1851 Use of packet loss measurement in an out-of-service transport 1852 path requires a traffic source such as a tester. 1854 6.2.1. Configuration considerations 1856 In order to support on-demand LM, the beginning and duration of 1857 the LM procedures, the transmission rate and PHB associated with 1858 the LM OAM packets originating from a MEP must be configured as 1859 part of the on-demand LM provisioning procedures. LM OAM packets 1860 should be transmitted with the PHB that yields the lowest packet 1861 loss performance among the PHB Scheduling Classes or Ordered 1862 Aggregates (see RFC 3260 [12]) in the monitored transport path 1863 for the relevant network domain(s). 1865 6.2.2. Sampling skew 1867 If an implementation makes use of a hardware forwarding path 1868 which operates in parallel with an OAM processing path, whether 1869 hardware or software based, the packet and byte counts may be 1870 skewed if one or more packets can be processed before the OAM 1871 processing samples counters. If OAM is implemented in software 1872 this error can be quite large. 1874 6.2.3. Multilink issues 1876 Multi-link Issues are as described in section 5.5.3. 1878 6.3. Diagnostic Tests 1880 6.3.1. Throughput Estimation 1882 Throughput estimation is an on-demand out-of-service function, 1883 as required in section 2.2.5 of [8], that allows verifying the 1884 bandwidth/throughput of an MPLS-TP transport path (LSP or PW) 1885 before it is put in-service. 1887 Throughput estimation is performed between MEPs and can be 1888 performed in one-way or two-way modes. 1890 This test is performed by sending OAM test packets at increasing 1891 rate (up to the theoretical maximum), graphing the percentage of 1892 OAM test packets received and reporting the rate at which OAM 1893 test packets begin to drop. In general, this rate is dependent 1894 on the OAM test packet size. 1896 When configured to perform such tests, a MEP source inserts OAM 1897 test packets with test information with specified throughput, 1898 packet size and transmission patterns. 1900 For one-way test, remote MEP sink receives the OAM test packets 1901 and calculates the packet loss. For two-way test, the remote MEP 1902 loopbacks the OAM test packets back to original MEP and the 1903 local MEP sink calculates the packet loss. However, a two-way 1904 test will return the minimum of available throughput in the two 1905 directions. Alternatively it is possible to run two individual 1906 one-way tests to get a distinct measurement in the two 1907 directions. 1909 6.3.1.1. Configuration considerations 1911 Throughput estimation is an out-of-service tool. The diagnosed 1912 MEG should be put into a Lock status before the diagnostic test 1913 is started. 1915 A MEG can be put into a Lock status either via NMS action or 1916 using the Lock Instruct OAM tool as defined in section 7. 1918 At the transmitting MEP, provisioning is required for a test 1919 signal generator, which is associated with the MEP. At a 1920 receiving MEP, provisioning is required for a test signal 1921 detector which is associated with the MEP. 1923 A MIP is transparent to the OAM test packets sent for throught 1924 estimation and therefore does not require any provisioning to 1925 support MPLS-TP throughput estimation. 1927 6.3.1.2. Limited OAM processing rate 1929 If an implementation is able to process payload at much higher 1930 data rates than OAM packets, then accurate measurement of 1931 throughput using OAM packets is not achievable. Whether OAM 1932 packets can be processed at the same rate as payload is 1933 implementation dependent. 1935 6.3.1.3. Multilink considerations 1937 If multilink is used, then it may not be possible to perform 1938 throughput measurement, as the throughput test may not have a 1939 mechanism for utilizing more than one component link of the 1940 aggregated link. 1942 6.3.2. Data plane Loopback 1944 Data plane loopback is an out-of-service function, as required 1945 in section 2.2.5 of [8], that permits all traffic (including 1946 user data and OAM) originated at the ingress of a transport path 1947 or inserted by the test equipment to be looped back in the 1948 direction of the point of origin by an interface at either an 1949 intermediate node or a terminating node. TTL is decremented 1950 normally during this process. 1952 If the loopback function is to be performed at an intermediate 1953 node it is only applicable to co-routed bi-directional paths. If 1954 the loopback is to be performed end to end, it is applicable to 1955 both co-routed bi-directional or associated bi-directional 1956 paths. 1958 Where a node implements data plane loopback capability and 1959 whether it implements more than one point is implementation 1960 dependent. 1962 6.4. Route Tracing 1964 It is often necessary to trace a route covered by a MEG from a 1965 source MEP to the sink MEP including all the MIPs in-between 1966 after e.g., provisioning an MPLS-TP transport path or for 1967 trouble shooting purposes, it. 1969 The route tracing function, as required in section 2.2.4 of [8], 1970 is providing this functionality. Based on the fate sharing 1971 requirement of OAM flows, i.e. OAM packets receive the same 1972 forwarding treatment as data packet, route tracing is a basic 1973 means to perform connectivity verification and, to a much lesser 1974 degree, continuity check. For this function to work properly, a 1975 return path must be present. 1977 Route tracing might be implemented in different ways and this 1978 document does not preclude any of them. 1980 Route tracing should always discover the full list of MIPs and 1981 of the peer MEPs. In case a defect exist, the route trace 1982 function needs to be able to detect it and stop automatically 1983 returning the incomplete list of OAM entities that it was able 1984 to trace. 1986 6.4.1. Configuration considerations 1988 The configuration of the route trace function must at least 1989 support the setting of the number of trace attempts before it 1990 gives up. 1992 6.5. Packet Delay Measurement 1994 Packet Delay Measurement (DM) is one of the capabilities 1995 supported by the MPLS-TP PM function in order to facilitate 1996 reporting of QoS information for a transport path, as required 1997 in section 2.2.12 of [8]. Specifically, on-demand DM is used to 1998 measure packet delay and packet delay variation in the transport 1999 path monitored by a pair of MEPs during a pre-defined monitoring 2000 period. 2002 On-Demand DM is performed by sending periodic DM OAM packets 2003 from a MEP to a peer MEP and by receiving DM OAM packets from 2004 the peer MEP (if a bidirectional transport path) during a 2005 configurable time interval. 2007 On-demand DM can be operated in two ways: 2009 o One-way: a MEP sends DM OAM packet to its peer MEP containing 2010 all the required information to facilitate one-way packet 2011 delay and/or one-way packet delay variation measurements at 2012 the peer MEP. 2014 o Two-way: a MEP sends DM OAM packet with a DM request to its 2015 peer MEP, which replies with an DM OAM packet as a DM 2016 response. The request/response DM OAM packets containing all 2017 the required information to facilitate two-way packet delay 2018 and/or two-way packet delay variation measurements from the 2019 viewpoint of the source MEP. 2021 6.5.1. Configuration considerations 2023 In order to support on-demand DM, the beginning and duration of 2024 the DM procedures, the transmission rate and PHB associated with 2025 the DM OAM packets originating from a MEP need be configured as 2026 part of the LM provisioning procedures. DM OAM packets should be 2027 transmitted with the PHB that yields the lowest packet delay 2028 performance among the PHB Scheduling Classes or Ordering 2029 Aggregates (see RFC 3260 [12]) in the monitored transport path 2030 for the relevant network domain(s). 2032 In order to verify different performances between long and short 2033 packets (e.g., due to the processing time), it should be 2034 possible for the operator to configure of the on-demand OAM DM 2035 packet. 2037 7. OAM Functions for administration control 2039 7.1. Lock Instruct 2041 Lock Instruct (LKI) function, as required in section 2.2.6 of 2042 [8], is a command allowing a MEP to instruct the peer MEP(s) to 2043 put the MPLS-TP transport path into a locked condition. 2045 This function allows single-side provisioning for 2046 administratively locking (and unlocking) an MPLS-TP transport 2047 path. 2049 Note that it is also possible to administratively lock (and 2050 unlock) an MPLS-TP transport path using two-side provisioning, 2051 where the NMS administratively put both MEPs into ad 2052 administrative lock condition. In this case, the LKI function is 2053 not required/used. 2055 7.1.1. Locking a transport path 2057 A MEP, upon receiving a single-side administrative lock command 2058 from NMS, sends an LKI request OAM packet to its peer MEP(s). It 2059 also puts the MPLS-TP transport path into a locked and notify 2060 its client (sub-)layer adaptation function upon the locked 2061 condition. 2063 A MEP, upon receiving an LKI request from its peer MEP, can 2064 accept or not the instruction and replies to the peer MEP with 2065 an LKI reply OAM packet indicating whether it has accepted or 2066 not the instruction. 2068 If the lock instruction has been accepted, it also puts the 2069 MPLS-TP transport path into a locked and notify its client 2070 (sub-)layer adaptation function upon the locked condition. 2072 Note that if the client (sub-)layer is also MPLS-TP, Lock 2073 Reporting (LKR) generation at the client MPLS-TP (sub-)layer is 2074 started, as described in section 5.4. 2076 7.1.2. Unlocking a transport path 2078 A MEP, upon receiving a single-side administrative unlock 2079 command from NMS, sends an LKI removal request OAM packet to its 2080 peer MEP(s). 2082 The peer MEP, upon receiving an LKI removal request, can accept 2083 or not the removal instruction and replies with an LKI removal 2084 reply OAM packet indicating whether it has accepted or not the 2085 instruction. 2087 If the lock removal instruction has been accepted, it also 2088 clears the locked condition on the MPLS-TP transport path and 2089 notify this event to its client (sub-)layer adaptation function. 2091 The MEP that has initiated the LKI clear procedure, upon 2092 receiving a positive LKI removal reply, also clears the locked 2093 condition on the MPLS-TP transport path and notify this event to 2094 its client (sub-)layer adaptation function. 2096 Note that if the client (sub-)layer is also MPLS-TP, Lock 2097 Reporting (LKR) generation at the client MPLS-TP (sub-)layer is 2098 terminated, as described in section 5.4. 2100 8. Security Considerations 2102 A number of security considerations are important in the context 2103 of OAM applications. 2105 OAM traffic can reveal sensitive information such as passwords, 2106 performance data and details about e.g. the network topology. 2107 The nature of OAM data therefore suggests to have some form of 2108 authentication, authorization and encryption in place. This will 2109 prevent unauthorized access to vital equipment and it will 2110 prevent third parties from learning about sensitive information 2111 about the transport network. However it should be observed that 2112 the combination of all permutations of unique MEP to MEP, MEP to 2113 MIP, and intermediate system originated transactions mitigates 2114 against the practical establishment and maintenance of a large 2115 number of security associations per MEG. 2117 For this reason it is assumed that the network is physically 2118 secured against man in the middle attacks. Further, this 2119 document describes OAM functions that, if a man in the middle 2120 attack was possible, could be exploited to significantly disrupt 2121 proper operation of the network. 2123 Mechanisms that the framework does not specify might be subject 2124 to additional security considerations. 2126 9. IANA Considerations 2128 No new IANA considerations. 2130 10. Acknowledgments 2132 The authors would like to thank all members of the teams (the 2133 Joint Working Team, the MPLS Interoperability Design Team in 2134 IETF and the Ad Hoc Group on MPLS-TP in ITU-T) involved in the 2135 definition and specification of MPLS Transport Profile. 2137 The editors gratefully acknowledge the contributions of Adrian 2138 Farrel, Yoshinori Koike, Luca Martini, Yuji Tochio and Manuel 2139 Paul for the definition of per-interface MIPs and MEPs. 2141 The editors gratefully acknowledge the contributions of Malcolm 2142 Betts, Yoshinori Koike, Xiao Min, and Maarten Vissers for the 2143 lock report and lock instruction description. 2145 The authors would also like to thank Loa Andersson, Malcolm 2146 Betts, Stewart Bryant, Rui Costa, Xuehui Dai, John Drake, Adrian 2147 Farrel, Liu Gouman, Feng Huang, Yoshionori Koike, George 2148 Swallow, Yuji Tochio, Curtis Villamizar, Maarten Vissers and 2149 Xuequin Wei for their comments and enhancements to the text. 2151 This document was prepared using 2-Word-v2.0.template.dot. 2153 11. References 2155 11.1. Normative References 2157 [1] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol 2158 Label Switching Architecture", RFC 3031, January 2001 2160 [2] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge 2161 (PWE3) Architecture", RFC 3985, March 2005 2163 [3] Nadeau, T., Pignataro, S., "Pseudowire Virtual Circuit 2164 Connectivity Verification (VCCV): A Control Channel for 2165 Pseudowires", RFC 5085, December 2007 2167 [4] Bocci, M., Bryant, S., "An Architecture for Multi-Segment 2168 Pseudo Wire Emulation Edge-to-Edge", RFC 5659, October 2169 2009 2171 [5] Niven-Jenkins, B., Brungard, D., Betts, M., sprecher, N., 2172 Ueno, S., "MPLS-TP Requirements", RFC 5654, September 2009 2174 [6] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, 2175 R., "MPLS Generic Associated Channel", RFC 5586, June 2009 2177 [7] Swallow, G., Bocci, M., "MPLS-TP Identifiers", draft-ietf- 2178 mpls-tp-identifiers-01 (work in progress), April 2010 2180 [8] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM 2181 in MPLS Transport Networks", draft-ietf-mpls-tp-oam- 2182 requirements-06 (work in progress), March 2010 2184 [9] ITU-T Recommendation G.806 (01/09), "Characteristics of 2185 transport equipment - Description methodology and generic 2186 functionality ", January 2009 2188 11.2. Informative References 2190 [10] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, 2191 Y., "MPLS-TP OAM Analysis", draft-ietf-mpls-tp-oam- 2192 analysis-01 (work in progress), March 2010 2194 [11] Nichols, K., Blake, S., Baker, F., Black, D., "Definition 2195 of the Differentiated Services Field (DS Field) in the 2196 IPv4 and IPv6 Headers", RFC 2474, December 1998 2198 [12] Grossman, D., "New terminology and clarifications for 2199 Diffserv", RFC 3260, April 2002. 2201 [13] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 2202 MPLS Traffic Engineering (TE)", RFC 4201, October 2005 2204 [14] IEEE Standard 802.1AX-2008, "IEEE Standard for Local and 2205 Metropolitan Area Networks - Link Aggregation", November 2206 2008 2208 Authors' Addresses 2210 Dave Allan 2211 Ericsson 2213 Email: david.i.allan@ericsson.com 2215 Italo Busi 2216 Alcatel-Lucent 2218 Email: Italo.Busi@alcatel-lucent.com 2220 Ben Niven-Jenkins 2221 BT 2223 Email: benjamin.niven-jenkins@bt.com 2225 Annamaria Fulignoli 2226 Ericsson 2228 Email: annamaria.fulignoli@ericsson.com 2230 Enrique Hernandez-Valencia 2231 Alcatel-Lucent 2233 Email: Enrique.Hernandez@alcatel-lucent.com 2235 Lieven Levrau 2236 Alcatel-Lucent 2238 Email: Lieven.Levrau@alcatel-lucent.com 2239 Dinesh Mohan 2240 Nortel 2242 Email: mohand@nortel.com 2244 Vincenzo Sestito 2245 Alcatel-Lucent 2247 Email: Vincenzo.Sestito@alcatel-lucent.com 2249 Nurit Sprecher 2250 Nokia Siemens Networks 2252 Email: nurit.sprecher@nsn.com 2254 Huub van Helvoort 2255 Huawei Technologies 2257 Email: hhelvoort@huawei.com 2259 Martin Vigoureux 2260 Alcatel-Lucent 2262 Email: Martin.Vigoureux@alcatel-lucent.com 2264 Yaacov Weingarten 2265 Nokia Siemens Networks 2267 Email: yaacov.weingarten@nsn.com 2269 Rolf Winter 2270 NEC 2272 Email: Rolf.Winter@nw.neclab.eu