idnits 2.17.1 draft-ietf-mpls-tp-oam-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 36 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The abstract seems to contain references ([11]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 672 has weird spacing: '...tecture frame...' == Line 763 has weird spacing: '...segment or c...' == Line 860 has weird spacing: '... an arbitra...' -- The document date (July 13, 2009) is 5395 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'Root' on line 432 -- Looks like a reference, but probably isn't: 'Leaf' on line 432 == Unused Reference: '3' is defined on line 1645, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1648, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1691, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1714, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-arch-05 == Outdated reference: A later version (-12) exists of draft-ietf-mpls-tp-framework-01 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-tp-requirements-09 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-oam-requirements-02 == Outdated reference: A later version (-07) exists of draft-sprecher-mpls-tp-oam-analysis-04 Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group I. Busi (Ed) 2 Internet Draft Alcatel-Lucent 3 Intended status: Informational 4 B. Niven-Jenkins (Ed) 5 BT 7 Expires: January 2010 July 13, 2009 9 MPLS-TP OAM Framework 10 draft-ietf-mpls-tp-oam-framework-01.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents in effect on the date of 39 publication of this document (http://trustee.ietf.org/license-info). 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. 43 Abstract 45 Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) is 46 based on a profile of the MPLS and pseudowire (PW) procedures as 47 specified in the MPLS Traffic Engineering (MPLS-TE), pseudowire (PW) 48 and multi-segment PW (MS-PW) architectures complemented with 49 additional Operations, Administration and Maintenance (OAM) 50 procedures for fault, performance and protection-switching management 51 for packet transport applications that do not rely on the presence of 52 a control plane. 54 This document provides a framework that supports a comprehensive set 55 of OAM procedures that fulfills the MPLS-TP OAM requirements [11]. 57 Table of Contents 59 1. Introduction.................................................3 60 1.1. Contributing Authors....................................4 61 2. Conventions used in this document............................4 62 2.1. Terminology.............................................4 63 2.2. Definitions.............................................5 64 3. Functional Components........................................7 65 3.1. Maintenance Entity......................................9 66 3.2. Point-to-multipoint scenario............................9 67 3.3. Maintenance End Points (MEPs)..........................10 68 3.4. Maintenance Intermediate Points (MIPs).................12 69 3.5. Server MEPs............................................12 70 4. Reference Model.............................................13 71 4.1. MPLS-TP Section Monitoring.............................15 72 4.2. MPLS-TP LSP End-to-End Monitoring......................16 73 4.3. MPLS-TP LSP Tandem Connection Monitoring...............17 74 4.4. MPLS-TP PW Monitoring..................................19 75 4.5. MPLS-TP MS-PW Tandem Connection Monitoring.............19 76 5. OAM Functions for pro-active monitoring.....................21 77 5.1. Continuity Check and Connectivity Verification.........21 78 5.1.1. Defects identified by CC-V........................22 79 5.1.1.1. Loss Of Continuity defect....................22 80 5.1.1.2. Mis-connectivity defect......................22 81 5.1.1.3. MEP misconfiguration defect..................23 82 5.1.1.4. Period Misconfiguration defect...............23 83 5.1.2. Consequent action.................................23 84 5.1.3. Configuration considerations......................24 85 5.1.4. Applications for proactive CC-V...................25 86 5.2. Remote Defect Indication...............................26 87 5.2.1. Configuration considerations......................26 88 5.2.2. Applications for Remote Defect Indication.........26 89 5.3. Alarm Reporting........................................27 90 5.4. Lock Reporting.........................................28 91 5.5. Lock Indication........................................29 92 5.6. Packet Loss............................................29 93 5.6.1. Configuration considerations......................29 94 5.6.2. Applications for Packet Loss......................30 95 5.7. Client Failure Indication..............................30 96 5.7.1. Configuration considerations......................31 97 5.7.2. Applications for Remote Defect Indication.........31 98 5.8. Delay Measurement......................................31 99 5.8.1. Configuration considerations......................32 100 5.8.2. Applications for Packet Loss......................32 101 6. OAM Functions for on-demand monitoring......................32 102 6.1. Connectivity Verification..............................32 103 6.1.1. Configuration considerations......................33 104 6.2. Packet Loss............................................34 105 6.2.1. Configuration considerations......................34 106 6.2.2. Applications for On-demand Packet Loss............34 107 6.3. Diagnostic.............................................34 108 6.4. Route Tracing..........................................35 109 6.5. Delay Measurement......................................35 110 6.5.1. Configuration considerations......................35 111 6.5.2. Applications for Delay Measurement................35 112 6.6. Lock Instruct..........................................36 113 7. Security Considerations.....................................36 114 8. IANA Considerations.........................................36 115 9. Acknowledgments.............................................36 116 10. References.................................................37 117 10.1. Normative References..................................37 118 10.2. Informative References................................37 120 1. Introduction 122 As noted in [8], MPLS-TP defines a profile of the MPLS-TE and (MS-)PW 123 architectures defined in RFC 3031 [2], RFC 3985 [5] and [7] 124 complemented with additional OAM procedures for fault, performance 125 and protection-switching management for packet transport 126 applications. 128 [Editor's note - The draft needs to be reviewed to ensure support of 129 OAM for p2mp transport paths] 131 In line with [12], existing MPLS OAM mechanisms will be used wherever 132 possible and extensions or new OAM mechanisms will be defined only 133 where existing mechanisms are not sufficient to meet the 134 requirements. 136 The MPLS-TP OAM framework defined in this document provides a 137 comprehensive set of OAM procedures that satisfy the MPLS-TP OAM 138 requirements [11]. In this regard, it is similar to existing 139 SONET/SDH and OTH OAM mechanisms (e.g. [16]). 141 1.1. Contributing Authors 143 Italo Busi, Ben Niven-Jenkins, Annamaria Fulignoli, Enrique 144 Hernandez-Valencia, Lieven Levrau, Dinesh Mohan, Vincenzo Sestito, 145 Nurit Sprecher, Huub van Helvoort, Martin Vigoureux, Yaacov 146 Weingarten, Rolf Winter 148 2. Conventions used in this document 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC-2119 [1]. 154 2.1. Terminology 156 DBN Domain Border Node 158 LME LSP Maintenance Entity 160 LTCME LSP Tandem Connection Maintenance Entity 162 [Editor's note - Difference or similarity between tandem connection 163 monitoring (TCM)_and Path Segment Tunnel (PST) need to be defined and 164 agreed] 166 ME Maintenance Entity 168 [Editor's note - There is a need to define whether to support OAM on 169 p2mp transport path there is a need to introduce the MEG concept] 171 MEP Maintenance End Point 173 MIP Maintenance Intermediate Point 175 PHB Per-hop Behavior 177 PME PW Maintenance Entity 179 PTCME PW Tandem Connection Maintenance Entity 181 SME Section Maintenance Entity 183 2.2. Definitions 185 ME: The collection of MEPs and MIPs and their association (details in 186 section 3.1). 188 MEP: A MEP is capable of initiating (MEP Source) and terminating (MEP 189 Sink) OAM messages for fault management and performance monitoring. 190 MEPs reside at the boundaries of an ME (details in section 3.3). 192 MEP Source: A MEP acts as MEP source for the OAM messages that it 193 originates and inserts into its associated ME. 195 MEP Sink: A MEP acts as a MEP sink for the OAM messages that it 196 terminates and processes from its associated ME. 198 MIP: A MIP terminates and processes OAM messages and generates OAM 199 messages in reaction to received OAM messages. A MIP resides within a 200 ME between MEPs (details in section 3.4). 202 OAM domain: A domain, as defined in [10], whose entities are grouped 203 for the purpose of keeping the OAM confined within that domain. 205 Note - within the rest of this document the term "domain" is used to 206 indicate an "OAM domain" 208 OAM flow: An OAM flow is a flow of OAM packets between a pair of MEPs 209 or a MEP and a MIP that is used to monitor and maintain a ME 210 [Editor's note - a MEG depending on what we decide for this point]. 211 An OAM flow is associated to a unique ME and contains the OAM 212 monitoring, signalling and notification messages necessary to monitor 213 and maintain that ME. The exact mix of message types in an OAM flow 214 will be dependent on the technology being monitored and the exact 215 deployment scenario of that technology (e.g. some deployments may 216 proactively monitor the connectivity of all transport paths whereas 217 other deployments may only reactively monitor transport paths). 219 OAM Message: An OAM information element that performs some OAM 220 functionality (e.g. continuity check and connectivity verification) 222 OAM Packet: A packet that carries one or more OAM messages (i.e. OAM 223 information elements). 225 Path: See Transport Path 227 Signal Fail: A condition when the data associated with a transport 228 path has failed in the sense that a defect condition (not being a 229 degraded defect) is detected. 231 Tandem Connection: A tandem connection is an arbitrary part of a 232 transport path that can be monitored (via OAM) independently from the 233 end-to-end monitoring (OAM). It may be a monitored segment or a 234 monitored concatenated segment of a transport path. The tandem 235 connection may also include the forwarding engine(s) of the node(s) 236 at the edge(s) of the segment or concatenated segment. 238 The following terms are defined in [10] as follows: 240 Associated bidirectional path: A path that supports traffic flow in 241 both directions but which is constructed from a pair of 242 unidirectional paths (one for each direction) which are associated 243 with one another at the path's ingress/egress points. The forward 244 and backward directions are setup, monitored and protected 245 independently. As a consequence they may or may not follow the same 246 route (links and nodes) across the network. 248 Concatenated Segment: A serial-compound link connection as defined in 249 G.805 [17]. A concatenated segment is a contiguous part of an LSP or 250 multi-segment PW that comprises a set of segments and their 251 interconnecting nodes in sequence. See also "Segment". 253 Co-routed bidirectional path: A path where the forward and backward 254 directions follow the same route (links and nodes) across the 255 network. Both directions are setup, monitored and protected as a 256 single entity. A transport network path is typically co-routed. 258 Layer network: Layer network is defined in G.805 [17]. A layer 259 network provides for the transfer of client information and 260 independent operation of the client OAM. A Layer Network may be 261 described in a service context as follows: one layer network may 262 provide a (transport) service to higher client layer network and may, 263 in turn, be a client to a lower layer network. A layer network is a 264 logical construction somewhat independent of arrangement or 265 composition of physical network elements. A particular physical 266 network element may topologically belong to more than one layer 267 network, depending on the actions it takes on the encapsulation 268 associated with the logical layers (e.g. the label stack), and thus 269 could be modeled as multiple logical elements. A layer network may 270 consist of one or more sublayers. Section 1.3 provides a more 271 detailed overview of what constitutes a layer network. For 272 additional explanation of how layer networks relate to the OSI 273 concept of layering see Appendix I of Y.2611 [19]. 275 Section Layer Network: A section layer is a server layer (which may 276 be MPLS-TP or a different technology) which provides for the transfer 277 of the section layer client information between adjacent nodes in the 278 transport path layer or transport service layer. A section layer may 279 provide for aggregation of multiple MPLS-TP clients. Note that G.805 280 [17] defines the section layer as one of the two layer networks in a 281 transmission media layer network. The other layer network is the 282 physical media layer network. 284 Path: See Transport Path 286 Segment: A link connection as defined in G.805 [17]. A segment is the 287 part of an LSP that traverses a single link or the part of a PW that 288 traverses a single link (i.e. that connects a pair of adjacent 289 {Switching|Terminating} Provider Edges). See also "Concatenated 290 Segment". 292 Sublayer: Sublayer is defined in G.805 [17]. The distinction between 293 a layer network and a sublayer is that a sublayer is not directly 294 accessible to clients outside of its encapsulating layer network and 295 offers no direct transport service for a higher layer (client) 296 network 298 Transport Path Layer: A (sub-)layer network that provides 299 point-to-point or point-to-multipoint transport paths. It provides 300 independent (of the client) OAM when transporting its clients. 302 Unidirectional path: A path that supports traffic flow in only one 303 direction. 305 The term 'Domain Border Node' is defined in [14] as follows: 307 Domain Border Node: To be defined 309 [Editor's note - There is no definition of Domain Border Node in RFC 310 5151] 312 The term 'Per-hop Behavior' is defined in [13] as follows: 314 Per-hop Behavior: a description of the externally observable 315 forwarding treatment applied at a differentiated services-compliant 316 node to a behavior aggregate. 318 3. Functional Components 320 MPLS-TP defines a profile of the MPLS and PW architectures ([2], [5] 321 and [7]) that is designed to transport service traffic complying with 322 certain performance and quality requirements. In order to verify and 323 maintain these performance and quality requirements, there is a need 324 to not only apply OAM functionality on a transport path granularity 325 (e.g. LSP or MS-PW), but also on arbitrary parts of transport paths, 326 defined as Tandem Connections, between any two arbitrary points along 327 a path. 329 MPLS-TP OAM operates in the context of Maintenance Entities (MEs). 331 A Maintenance Entity is the collection of two (or more) Maintenance 332 End Points (MEPs) and their association. The MEPs that form an ME are 333 configured and managed to limit the scope of an OAM flow within the 334 ME the MEPs belong to (i.e. within the domain of the transport path 335 or segment, in the specific layer network, that is being monitored 336 and managed). 338 An example of an ME with more than two MEPs is a point-to-multipoint 339 ME monitoring a point-to-multipoint transport path (or point-to- 340 multipoint tandem connection). 342 Each MEP resides at the boundaries of the ME that they are part of. 343 An ME may also include a set of zero or more Maintenance Intermediate 344 Points (MIPs), which reside within the Maintenance Entity, between 345 the MEPs. 347 MEPs and MIPs are associated with only one Maintenance Entity. 349 The abstract reference model for a ME with MEPs and MIPs is described 350 in Figure 1 below: 352 +-+ +-+ +-+ +-+ 353 |A|----|B|----|C|----|D| 354 +-+ +-+ +-+ +-+ 356 Figure 1 ME Abstract Reference Model 358 The instantiation of this abstract model to different MPLS-TP 359 entities is described in section 4. In this model, nodes A, B, C and 360 D can be LER/LSR for an LSP or the {S|T}-PEs for a MS-PW. Nodes A and 361 D are MEPs while B and C are MIPs. The links connecting adjacent 362 nodes can be either physical links or lower-level LSPs. 364 This functional model defines the relationships between all OAM 365 entities from a maintenance perspective, to allow each Maintenance 366 Entity to monitor and manage the layer network under its 367 responsibility and to localize problems efficiently. 369 When a control plane is not present, the management plane configures 370 MEPs and MIPs. Otherwise they can be configured either by the 371 management plane or by the control plane. 373 3.1. Maintenance Entity 375 A Maintenance Entity may be defined to monitor for fault and 376 performance management unidirectional point-to-point or point-to- 377 multipoint transport paths or tandem connections, or co-routed 378 bidirectional point-to-point transport paths and tandem connections 379 in an MPLS-TP layer network. 381 In case of associated bi-directional paths, two independent 382 Maintenance Entities are define to independently monitor each 383 direction. 385 An MPLS-TP maintenance entity can be either the whole end-to-end 386 transport path or a Tandem Connection of the transport path. 388 The following properties apply to all MPLS-TP MEs: 390 o They can be nested but not overlapped, e.g. a ME may cover a 391 segment or a concatenated segment of another ME, and may also 392 include the forwarding engine(s) of the node(s) at the edge(s) of 393 the segment or concatenated segment, but all its MEPs and MIPs are 394 no longer part of the encompassing ME. It is possible that MEPs of 395 nested MEs reside on a single node. 397 o Each OAM flow is associated with a single Maintenance Entity. 399 o OAM packets are subject to the same forwarding treatment (e.g. 400 fate share) as the data traffic, but they can be distinguished 401 from the data traffic using the GAL and ACH constructs [9] for LSP 402 and the ACH construct [6]and [9] for (MS-)PW. 404 3.2. Point-to-multipoint scenario 406 The reference model for the p2mp scenario is represented in Figure 4. 408 +-+ 409 /--|D| 410 / +-+ 411 +-+ 412 /--|C| 413 +-+ +-+/ +-+\ +-+ 414 |A|----|B| \--|E| 415 +-+ +-+\ +-+ +-+ 416 \--|F| 417 +-+ 419 Figure 2 Reference Model for p2mp 421 In case of p2mp transport paths, the OAM measurements are different 422 for each [Root, Leaf] relationship (A-D, A-E and A-F): 424 o Fault conditions - depending from where the failure is located 426 o Packet loss - depending from where the packets are lost 428 o Packet delay - depending on different paths 430 Each leaf (i.e. D, E and F) terminates OAM messages to monitor its 431 own [Root, Leaf] relationship while the root (i.e. A) generates OAM 432 messages to monitor all the [Root, Leaf] relationships of p2mp 433 transport path. 435 [Editor's note - Further considerations regarding the p2mp case will 436 be added in a future version of this document] 438 3.3. Maintenance End Points (MEPs) 440 Maintenance End Points (MEPs) are the end points of a ME. 442 In the context of an MPLS-TP LSP, only LERs can be MEPs while in the 443 context of an LSP Tandem Connection both LERs and LSRs can be MEPs. 445 In the context of MPLS-TP PW, only T-PEs can be MEPs while in the 446 context of a PW Tandem Connection both T-PEs and S-PEs can be MIPs. 448 MEPs are responsible for activating and controlling all of the OAM 449 functionality for the ME. A MEP is capable of initiating and 450 terminating OAM messages for fault management and performance 451 monitoring. 453 MEPs prevent OAM packets corresponding to a ME from leaking outside 454 that ME: 456 o A MEP sink terminates all the OAM packets that it receives 457 corresponding to its ME and does not forward them further along 458 the path. If the pro-active CC-V OAM tool detects an unintended 459 connectivity, all traffic on the path is blocked (i.e. all 460 received packets are dropped, including user-data packets). 462 [Editor's note - Need to discuss whether to keep the last sentence in 463 the bullet above regarding the MEP behavior in case of 464 misconnections] 466 o A MEP source tunnels all the OAM packets that it receives, 467 upstream from the associated ME, via label stacking. These packets 468 are not processed within the ME as they belong to another ME. 470 [Editor's - Need to rephrase the bullet above to clarify what it 471 actually means] 473 MPLS-TP MEP passes a fault indication to its client (sub-)layer 474 network. 476 A MEP of a tandem connection is not necessarily coincident with the 477 termination of the MPLS-TP transport path (LSP or PW). Within the 478 boundary of the tandem connection it can monitor the MPLS-TP 479 transport path for failures or performance degradation (e.g. count 480 packets). 482 [Editor's note - The MEP of a TCM monitors the transport paths' 483 connectivity within the scope of the TCM. This means that failures or 484 performance degradations within the TCM are detected by the TCM MEP 485 while failures or performance degradations outside the TCM are not 486 detected by the TCM MEP. 488 Improve the text above to explain this concept.] 490 A MEP of an MPLS-TP transport path coincides with transport path 491 termination and monitors it for failures or performance degradation 492 (e.g. based on packet counts) in an end-to-end scope. Note that both 493 MEP source and MEP sink coincide with transport paths' source and 494 sink terminations. 496 [Editor's note - Add some text regarding MEP identification as well 497 as about what a MEP should do if it receives an unexpected OAM 498 packet] 500 3.4. Maintenance Intermediate Points (MIPs) 502 A Maintenance Intermediate Point (MIP) is a point between the two 503 MEPs in an ME. 505 In the context of an MPLS-TP LSP and LSP Tandem Connections, LSRs can 506 be MIPs. 508 In the context of MPLS-TP PW and PW Tandem Connection, S-PEs can be 509 MIPs. 511 A MIP is capable of reacting to some OAM packets and forwarding all 512 the other OAM packets while ensuring fate sharing with data plane 513 packets. 515 A MIP does not initiate unsolicited OAM packets, but may be addressed 516 by OAM packets initiated by one of the MEPs of the ME. A MIP can 517 generate OAM packets only in response to OAM packets that are sent on 518 the ME it belongs to. 520 [Editor's note - It is needed to provide an high-level description 521 about how this is achieved (e.g. TTL expiry).] 523 MIPs are unaware of any OAM flows running between MEPs or between 524 MEPs and other MIPs. MIPs can only receive and process OAM packets 525 addressed to the MIP itself. 527 A MIP takes no action on the MPLS-TP transport path. 529 [Editor's note - Add some text regarding MIP identification as well 530 as about what a MIP should do if it receives an unexpected OAM 531 packet] 533 3.5. Server MEPs 535 A server MEP is a MEP of an ME that is either: 537 o defined in a layer network below the MPLS-TP layer network being 538 referenced, or 540 o defined in a sub-layer of the MPLS-TP layer network that is below 541 the sub-layer being referenced. 543 A server MEP can coincide with a MIP or a MEP in the client (MPLS-TP) 544 layer network. 546 A server MEP provides also client/server adaptation function between 547 the client (MPLS-TP) layer network and the server layer network. As a 548 consequence the server MEP is aware of the MPLS-TP transport paths 549 that are setup over that server layer's transport path. 551 For example, a server MEP can be either: 553 o A termination point of a physical link (e.g. 802.3), an SDH VC or 554 OTH ODU for the MPLS-TP Section layer network, defined in section 555 4.1; 557 o An MPLS-TP Section MEP for MPLS-TP LSPs, defined in section 4.2; 559 o An MPLS-TP LSP MEP for MPLS-TP PWs, defined in section 4.4; 561 o An MPLS-TP LSP Tandem Connection MEP for higher-level LTCMEs, 562 defined in section 4.3; 564 o An MPLS-TP PW Tandem Connection MEP for higher-level PTCMEs, 565 defined in section 4.5. 567 The server MEP can run appropriate OAM functions for fault detection 568 within the server (sub-)layer network, and notifies a fault 569 indication to its client MPLS-TP layer network. Server MEP OAM 570 functions are outside the scope of this document. 572 4. Reference Model 574 The reference model for the MPLS-TP framework builds upon the concept 575 of an ME, and its associated MEPs and MIPs, to support the functional 576 requirements specified in [11]. 578 The following MPLS-TP MEs are specified in this document: 580 o A Section Maintenance Entity (SME), allowing monitoring and 581 management of MPLS-TP Sections (between MPLS LSRs). 583 o A LSP Maintenance Entity (LME), allowing monitoring and management 584 of an end-to-end LSP (between LERs). 586 o A PW Maintenance Entity (PME), allowing monitoring and management 587 of an end-to-end SS/MS-PWs (between T-PEs). 589 o An LSP Tandem Connection Maintenance Entity (LTCME), allowing 590 monitoring and management of an LSP Tandem Connection between any 591 LER/LSR along the LSP. 593 o A MS-PW Tandem Connection Maintenance Entity (PTCME), allows 594 monitoring and management of a SS/MS-PW Tandem Connection between 595 any T-PE/S-PE along the (MS-)PW. 597 The MEs specified in this MPLS-TP framework are compliant with the 598 architecture framework for MPLS MS-PWs [7] and MPLS LSPs [2]. 600 Hierarchical LSPs are also supported. In this case, each LSP Tunnel 601 in the hierarchy is a different sub-layer network that can be 602 monitored independently from higher and lower level LSP tunnels in 603 the hierarchy, end-to-end (from LER to LER) by an LME. Tandem 604 Connection monitoring via LTCME are applicable on each LSP Tunnel in 605 the hierarchy. 607 Native |<------------------- MS-PW1Z ------------------->| Native 608 Layer | | Layer 609 Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service 610 (AC1) V V LSP V V LSP V V LSP V V (AC2) 611 +----+ +-+ +----+ +----+ +-+ +----+ 612 +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ 613 | | | |=========| |=========| |=========| | | | 614 | CE1|--------|........PW13.......|...PW3X..|........PWXZ.......|-------|CE2 | 615 | | | |=========| |=========| |=========| | | | 616 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 617 +----+ +-+ +----+ +----+ +-+ +----+ 618 . . . . 619 | | | | 620 |<---- Domain 1 --->| |<---- Domain Z --->| 621 .------------------- PW1Z PME -------------------. 622 .---- PW13 PTCME ---. .---- PWXZ PTCME ---. 623 .---------. .---------. 624 PSN13 LME PSNXZ LME 626 .---. .---. .---------. .---. .---. 627 Sec12 Sec23 Sec3X SecXY SecYZ 628 SME SME SME SME SME 630 TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3 631 TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z 633 .---. ME . MEP ==== LSP .... PW 635 Figure 3 Reference Model for the MPLS-TP OAM Framework 637 Figure 3 depicts a high-level reference model for the MPLS-TP OAM 638 framework. The figure depicts portions of two MPLS-TP enabled network 639 domains, Domain 1 and Domain Z. In Domain 1, LSR1 is adjacent to LSR2 640 via the MPLS Section Sec12 and LSR2 is adjacent to LSR3 via the MPLS 641 Section Sec23. Similarly, in Domain Z, LSRX is adjacent to LSRY via 642 the MPLS Section SecXY and LSRY is adjacent to LSRZ via the MPLS 643 Section SecYZ. In addition, LSR3 is adjacent to LSRX via the MPLS 644 Section 3X. 646 Figure 3 also shows a bi-directional MS-PW (PW1Z) between AC1 on TPE1 647 and AC2 on TPEZ. The MS-PW consists of three bi-directional PW 648 Segments: 1) PW13 segment between T-PE1 and S-PE3 via the bi- 649 directional PSN13 LSP, 2) PW3X segment between S-PE3 and S-PEX, and 650 3) PWXZ segment between S-PEX and T-PEZ via the bi-directional PSNXZ 651 LSP. 653 The MPLS-TP OAM procedures that apply to an instance of a given ME 654 are expected to operate independently from procedures on other 655 instances of the same ME and certainly of other MEs. Yet, this does 656 not preclude that multiple MEs may be affected simultaneously by the 657 same network condition, for example, a fibre cut event. 659 Note that there are no constrains imposed by this OAM framework on 660 the number, or type, of MEs that may be instantiated on a particular 661 node. In particular, when looking at Figure 1, it should be possible 662 to configure one or more MEPs on the same node if that node is the 663 endpoint of one or more MEs. 665 Figure 3 does not describe a PW3X PTCME because typically TCMs are 666 used to monitor an OAM domain (like PW13 and PWXZ PTCMEs) rather 667 than the segment between two OAM domains. However the OAM framework 668 does not pose any constraints on the way TCM are instantiated as long 669 as they are not overlapping. 671 The subsections below define the MEs specified in this MPLS-TP OAM 672 architecture framework document. Unless otherwise stated, all 673 references to domains, LSRs, MPLS Sections, LSP, pseudowires and MEs 674 in this Section are made in relation to those shown in Figure 3. 676 4.1. MPLS-TP Section Monitoring 678 An MPLS-TP Section ME (SME) is an MPLS-TP maintenance entity intended 679 to monitor the forwarding behaviour of an MPLS Section as defined in 680 [10]. An SME may be configured on any MPLS section. SME OAM packets 681 fate share with the user data packets sent over the monitored MPLS 682 Section. 684 [Editor's note - Is OAM monitoring only the forwarding behaviour? If 685 not, we need to clarify what it is monitoring] 687 An SME is intended to be deployed for applications where it is 688 preferable to monitor the link between topologically adjacent (next 689 hop in this layer network) MPLS (and MPLS-TP enabled) LSRs rather 690 than monitoring the individual LSP or PW segments traversing the MPLS 691 Section and the server layer technology does not provide adequate OAM 692 capabilities. 694 |<------------------- MS-PW1Z ------------------->| 695 | | 696 | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | 697 V V LSP V V LSP V V LSP V V 698 +----+ +-+ +----+ +----+ +-+ +----+ 699 +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ 700 | | AC1 | |=========| |=========| |=========| | AC2 | | 701 | CE1|--------|........PW13.......|...PW3X..|.......PWXZ........|-------|CE2 | 702 | | | |=========| |=========| |=========| | | | 703 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 704 +----+ +-+ +----+ +----+ +-+ +----+ 706 .--. .--. .--------. .--. .--. 707 Sec12 Sec23 Sec3X SecXY SecYZ 708 SME SME SME SME SME 710 Figure 4 Reference Example of MPLS-TP Section MEs (SME) 712 Figure 4 shows 5 Section MEs configured in the path between AC1 and 713 AC2: 1) Sec12 ME associated with the MPLS Section between LSR 1 and 714 LSR 2, 2) Sec23 ME associated with the MPLS Section between LSR 2 and 715 LSR 3, 3) Sec3X ME associated with the MPLS Section between LSR 3 and 716 LSR X, 4) SecXY ME associated with the MPLS Section between LSR X and 717 LSR Y, and 5) SecYZ ME associated with the MPLS Section between LSR Y 718 and LSR Z. 720 4.2. MPLS-TP LSP End-to-End Monitoring 722 An MPLS-TP LSP ME (LME) is an MPLS-TP maintenance entity intended to 723 monitor the forwarding behaviour of an end-to-end LSP between two 724 (e.g., a point-to-point LSP) or more (e.g., a point-to-multipoint 725 LSP) LERs. An LME may be configured on any MPLS LSP. LME OAM packets 726 fate share with user data packets sent over the monitored MPLS-TP 727 LSP. 729 An LME is intended to be deployed in scenarios where it is desirable 730 to monitor the forwarding behaviour of an entire LSP between its 731 LERs, rather than, say, monitoring individual PWs. 733 |<------------------- MS-PW1Z ------------------->| 734 | | 735 | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | 736 V V LSP V V LSP V V LSP V V 737 +----+ +-+ +----+ +----+ +-+ +----+ 738 +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ 739 | | AC1 | |=========| |=========| |=========| | AC2 | | 740 | CE1|--------|........PW13.......|...PW3X..|........PWXZ.......|-------|CE2 | 741 | | | |=========| |=========| |=========| | | | 742 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 743 +----+ +-+ +----+ +----+ +-+ +----+ 745 .---------. .---------. 746 PSN13 LME PSNXZ LME 748 Figure 5 Examples of MPLS-TP LSP MEs (LME) 750 Figure 5 depicts 2 LMEs configured in the path between AC1 and AC2: 751 1) the PSN13 LME between LER 1 and LER 3, and 2) the PSNXZ LME 752 between LER X and LER Y. Note that the presence of a PSN3X LME in 753 such a configuration is optional, hence, not precluded by this 754 framework. For instance, the SPs may prefer to monitor the MPLS-TP 755 Section between the two LSRs rather than the individual LSPs. 757 4.3. MPLS-TP LSP Tandem Connection Monitoring 759 An MPLS-TP LSP Tandem Connection Monitoring ME (LTCME) is an MPLS-TP 760 maintenance entity intended to monitor the forwarding behaviour of an 761 arbitrary part of an LSP between a given pair of LSRs independently 762 from the end-to-end monitoring (LME). An LTCME can monitor an LSP 763 segment or concatenated segment and it may also include the 764 forwarding engine(s) of the node(s) at the edge(s) of the segment or 765 concatenated segment. 767 Multiple LTCMEs MAY be configured on any LSP. The LSRs that terminate 768 the LTCME may or may not be immediately adjacent at the MPLS-TP 769 layer. LTCME OAM packets fate share with the user data packets sent 770 over the monitored LSP segment. 772 A LTCME can be defined between the following entities: 774 o LER and any LSR of a given LSP. 776 o Any two LSRs of a given LSP. 778 An LTCME is intended to be deployed in scenarios where it is 779 preferable to monitor the behaviour of a part of an LSP rather than 780 the entire LSP itself, for example when there is a need to monitor a 781 part of an LSP that extends beyond the administrative boundaries of 782 an MPLS-TP enabled administrative domain. 784 Note that LTCMEs are equally applicable to hierarchical LSPs. 786 |<--------------------- PW1Z -------------------->| 787 | | 788 | |<--------------PSN1Z LSP-------------->| | 789 | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | 790 V V S-LSP V V S-LSP V V S-LSP V V 791 +----+ +-+ +----+ +----+ +-+ +----+ 792 +----+ | PE1| | | |DBN3| |DBNX| | | | PEZ| +----+ 793 | | AC1 | |=======================================| | AC2 | | 794 | CE1|--------|......................PW1Z.......................|-------|CE2 | 795 | | | |=======================================| | | | 796 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 797 +----+ +-+ +----+ +----+ +-+ +----+ 798 . . . . 799 | | | | 800 |<---- Domain 1 --->| |<---- Domain Z --->| 802 .---------. .---------. 803 PSN13 LTCME PSNXZ LTCME 804 .---------------------------------------. 805 PSN1Z LME 807 DBN: Domain Border Node 809 Figure 6 MPLS-TP LSP Tandem Connection Monitoring ME (LTCME) 811 Figure 6 depicts a variation of the reference model in Figure 3 where 812 there is an end-to-end PSN LSP (PSN1Z LSP) between PE1 and PEZ. PSN1Z 813 LSP consists of, at least, three stitched LSP Segments: PSN13, PSN3X 814 and PSNXZ. In this scenario there are two separate LTCMEs configured 815 to monitor the forwarding behaviour of the PSN1Z LSP: 1) a LTCME 816 monitoring the PSN13 LSP Segment on Domain 1 (PSN13 LTCME), and 2) a 817 LTCME monitoring the PSNXZ LSP Segment on Domain Z (PSNXZ LTCME). 819 It is worth noticing that LTCMEs can coexist with the LME monitoring 820 the end-to-end LSP and that LTCME MEPs and LME MEPs can be coincident 821 in the same node (e.g. PE1 node supports both the PSN1Z LME MEP and 822 the PSN13 LTCME MEP). 824 4.4. MPLS-TP PW Monitoring 826 An MPLS-TP PW ME (PME) is an MPLS-TP maintenance entity intended to 827 monitor the end-to-end forwarding behaviour of a SS-PW or MS-PW 828 between a pair of T-PEs. A PME MAY be configured on any SS-PW or MS- 829 PW. PME OAM packets fate share with the user data packets sent over 830 the monitored PW. 832 A PME is intended to be deployed in scenarios where it is desirable 833 to monitor the forwarding behaviour of an entire PW between a pair of 834 MPLS-TP enabled T-PEs rather than monitoring the LSP aggregating 835 multiple PWs between PEs. 837 |<------------------- MS-PW1Z ------------------->| 838 | | 839 | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | 840 V V LSP V V LSP V V LSP V V 841 +----+ +-+ +----+ +----+ +-+ +----+ 842 +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ 843 | | AC1 | |=========| |=========| |=========| | AC2 | | 844 | CE1|--------|........PW13.......|...PW3X..|........PWXZ.......|-------|CE2 | 845 | | | |=========| |=========| |=========| | | | 846 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 847 +----+ +-+ +----+ +----+ +-+ +----+ 849 .---------------------PW1Z PME--------------------. 851 Figure 7 MPLS-TP PW ME (PME) 853 Figure 7 depicts a MS-PW (MS-PW1Z) consisting of three segments: 854 PW13, PW3X and PWXZ and its associated end-to-end PME (PW1Z PME). 856 4.5. MPLS-TP MS-PW Tandem Connection Monitoring 858 An MPLS-TP MS-PW Tandem Connection Monitoring ME (PTCME) is an MPLS- 859 TP maintenance entity intended to monitor the forwarding behaviour of 860 an arbitrary part of an MS-PW between a given pair of PEs 861 independently from the end-to-end monitoring (PME). An PTCME can 862 monitor a PW segment or concatenated segment and it may alos include 863 the forwarding engine(s) of the node(s) at the edge(s) of the segment 864 or concatenated segment. 866 Multiple PTCMEs MAY be configured on any MS-PW. The PEs may or may 867 not be immediately adjacent at the MS-PW layer. PTCME OAM packets 868 fate share with the user data packets sent over the monitored PW 869 Segment. 871 A PTCME can be defined between the following entities: 873 o T-PE and any S-PE of a given MS-PW 875 o Any two S-PEs of a given MS-PW. It can span several PW segments. 877 A PTCME is intended to be deployed in scenarios where it is 878 preferable to monitor the behaviour of a part of a MS-PW rather than 879 the entire end-to-end PW itself, for example to monitor an MS-PW 880 Segment within a given network domain of an inter-domain MS-PW. 882 |<------------------- MS-PW1Z ------------------->| 883 | | 884 | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | 885 V V LSP V V LSP V V LSP V V 886 +----+ +-+ +----+ +----+ +-+ +----+ 887 +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ 888 | | AC1 | |=========| |=========| |=========| | AC2 | | 889 | CE1|--------|........PW13.......|...PW3X..|........PWXZ.......|-------|CE2 | 890 | | | |=========| |=========| |=========| | | | 891 +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ 892 +----+ +-+ +----+ +----+ +-+ +----+ 894 .---- PW1 PTCME ----. .---- PW5 PTCME ----. 895 .---------------------PW1Z PME--------------------. 897 Figure 8 MPLS-TP MS-PW Tandem Connection Monitoring (PTCME) 899 Figure 8 depicts the same MS-PW (MS-PW1Z) between AC1 and AC2 as in 900 Figure 7. In this scenario there are two separate PTCMEs configured 901 to monitor the forwarding behaviour of MS-PW1Z: 1) a PTCME monitoring 902 the PW13 MS-PW Segment on Domain 1 (PW13 PTCME), and 2) a PTCME 903 monitoring the PWXZ MS-PW Segment on Domain Z with (PWXZ PTCME). 905 It is worth noticing that PTCMEs can coexist with the PME monitoring 906 the end-to-end MS-PW and that PTCME MEPs and PME MEPs can be 907 coincident in the same node (e.g. TPE1 node supports both the PW1Z 908 PME MEP and the PW13 PTCME MEP). 910 5. OAM Functions for pro-active monitoring 912 5.1. Continuity Check and Connectivity Verification 914 [Editor's note - There is a need to decide whether pro-active CC and 915 CV functions need to be combined in the same tool or separated into 916 different tools. This version of the document combines the two 917 functions. Future versions will be aligned with the decision taken 918 about whether to combine or not CC and CV.] 920 Proactive Continuity Check and Connectivity Verification (CC-V) 921 functions are used to detect a loss of continuity (LOC), an 922 unexpected connectivity between two MEs (e.g. mismerging or 923 misconnection), as well as unexpected connectivity within the ME with 924 an unexpected MEP. 926 Execution of proactive CC-V is based on the (proactive) generation of 927 CC-V OAM packets by the source MEP that are processed by the sink 928 MEP. Each CC-V OAM packet MUST include a globally unique ME 929 identifier, and MUST be transmitted at a regular, operator's 930 configurable, rate. The default CC-V transmission periods are 931 application dependent (see section 5.1.4). 933 Proactive CC-V OAM packets are transmitted with the "minimum loss 934 probability PHB" within a single network operator. This PHB is 935 configurable on network operator's basis. PHBs can be translated at 936 the network borders. 938 [Editor's note - Describe the relation between the previous paragraph 939 and the fate sharing requirement. Need to clarify also in the 940 requirement document that for proactive CC-V the fate sharing is 941 related to the forwarding behavior and not to the QoS behavior] 943 In a bidirectional point-to-point transport path, when a MEP is 944 enabled to generate pro-active CC-V OAM packets with a configured 945 transmission rate, it also expects to receive pro-active CC-V OAM 946 packets from its peer MEP at the same transmission rate. In a 947 unidirectional transport path (either point-to-point or point-to- 948 multipoint), only the source MEP is enabled to generate CC-V OAM 949 packets and only the sink MEP is configured to expect these packets 950 at the configured rate. 952 MIPs, as well as intermediate nodes not supporting MPLS-TP OAM, are 953 transparent to the pro-active CC-V information and forward these pro- 954 active CC-V OAM packets as regular data packets. 956 To initialize the proactive CC-V monitoring on a configured ME 957 without affecting traffic, the MEP source function (generating pro- 958 active CC-V packets) should be enabled prior to the corresponding MEP 959 sink function (detecting continuity and connectivity defects). When 960 disabling the CC-V proactive functionality, the MEP sink function 961 should be disabled prior to the corresponding MEP source function. 963 5.1.1. Defects identified by CC-V 965 Pro-active CC-V functions allow a sink MEP to detect the following 966 defect conditions. 968 For all of these defect cases, the sink MEP SHOULD notify the 969 equipment fault management process of the detected defect. 971 [Editor's note - Investigate whether in case there is a 972 misconfiguration on the minimum loss probability PHB on the two MEPs 973 a defect can be useful to notify the misconfiguration to the 974 operator.] 976 5.1.1.1. Loss Of Continuity defect 978 When proactive CC-V is enabled, a sink MEP detects a loss of 979 continuity (LOC) defect when it fails to receive pro-active CC-V OAM 980 packets from the peer MEP. 982 o Entry criteria: if no pro-active CC-V OAM packets from the peer 983 MEP (i.e. with the correct ME and peer MEP identifiers) are 984 received within the interval equal to 3.5 times the receiving 985 MEP's configured CC-V transmission period. 987 o Exit criteria: a pro-active CC-V OAM packet from the peer MEP 988 (i.e. with the correct ME and peer MEP identifiers) is received. 990 5.1.1.2. Mis-connectivity defect 992 When a pro-active CC-V OAM packet is received, a sink MEP identifies 993 a mis-connectivity defect (e.g. mismerge or misconnection) with its 994 peer source MEP when the received packet carries an incorrect ME 995 identifier. 997 o Entry criteria: the sink MEP receives a pro-active CC-V OAM packet 998 with an incorrect ME ID. 1000 o Exit criteria: the sink MEP does not receive any pro-active CC-V 1001 OAM packet with an incorrect ME ID for an interval equal at least 1002 to 3.5 times the longest transmission period of the pro-active 1003 CC-V OAM packets received with an incorrect ME ID since this 1004 defect has been raised. 1006 5.1.1.3. MEP misconfiguration defect 1008 When a pro-active CC-V packet is received, a sink MEP identifies a 1009 MEP misconfiguration defect with its peer source MEP when the 1010 received packet carries a correct ME Identifier but an unexpected 1011 peer MEP Identifier which includes the MEP's own MEP Identifier. 1013 o Entry criteria: the sink MEP receives a CC-V pro-active packet 1014 with correct ME ID but with unexpected MEP ID. 1016 o Exit criteria: the sink MEP does not receive any pro-active CC-V 1017 OAM packet with a correct ME ID and unexpected MEP ID for an 1018 interval equal at least to 3.5 times the longest transmission 1019 period of the pro-active CC-V OAM packets received with a correct 1020 ME ID and unexpected MEP ID since this defect has been raised. 1022 5.1.1.4. Period Misconfiguration defect 1024 If pro-active CC-V OAM packets is received with a correct ME and MEP 1025 identifiers but with a transmission period different than its own 1026 configured transmission period, then a CC-V period mis-configuration 1027 defect is detected 1029 o Entry criteria: a MEP receives a CC-V pro-active packet with 1030 correct ME ID and MEP ID but with a Period field value different 1031 than its own CC-V configured transmission period. 1033 o Exit criteria: the sink MEP does not receive any pro-active CC-V 1034 OAM packet with a correct ME and MEP IDs and an incorrect 1035 transmission period for an interval equal at least to 3.5 times 1036 the longest transmission period of the pro-active CC-V OAM packets 1037 received with a correct ME and MEP IDs and an incorrect 1038 transmission period since this defect has been raised. 1040 5.1.2. Consequent action 1042 A sink MEP that detects one of the defect conditions defined in 1043 section 5.1.1 MUST perform the following consequent actions. Some of 1044 these consequent actions SHOULD be enabled/disabled by the operator 1045 depending upon the application used (see section 5.1.4). 1047 If a MEP detects an unexpected ME Identifier, or an unexpected MEP, 1048 it MUST block all the traffic (including also the user data packets) 1049 that it receives from the misconnected transport path. 1051 If a MEP detects LOC defect and the CC-V monitoring is enabled it 1052 SHOULD block all the traffic (including also the user data packets) 1053 that it receives from the transport path if this consequent action 1054 has been enabled by the operator. 1056 It is worth noticing that the OAM requirements document [11] 1057 recommends that CC-V proactive monitoring is enabled on every ME in 1058 order to reliably detect connectivity defects. However, CC-V 1059 proactive monitoring MAY be disabled by an operator on a ME. In the 1060 event of a misconnection between a transport path that is pro- 1061 actively monitored for CC-V and a transport path which is not, the 1062 MEP of the former transport path will detect a LOC defect 1063 representing a connectivity problem (e.g. a misconnection with a 1064 transport path where CC-V proactive monitoring is not enabled) 1065 instead of a continuity problem, with a consequent wrong traffic 1066 delivering. For these reasons, the traffic block consequent action is 1067 applied even when a LOC condition occurs. This block consequent 1068 action MAY be disabled through configuration. This deactivation of 1069 the block action, may be used for activating or deactivating the 1070 monitoring when it is not possible to synchronize the function 1071 activation of the two peer MEPs. 1073 If a MEP detects a LOC defect, an unexpected ME Identifier, or an 1074 unexpected MEP it MUST declare a signal fail condition at the 1075 transport path level. 1077 If a MEP detects an Unexpected Period defect it SHOULD declare a 1078 signal fail condition at the transport path level. 1080 [Editor's note - Transport equipment also performs defect correlation 1081 (as defined in G.806) in order to properly report failures to the 1082 transport NSM. The current working assumption, to be further 1083 investigated, is that defect correlations are outside the scope of 1084 this document and to be defined in ITU-T documents.] 1086 5.1.3. Configuration considerations 1088 At all MEPs inside a ME, the following configuration information need 1089 to be configured when pro-active CC-V function is enabled: 1091 o ME ID; the ME identifier to which the MEP belongs; 1093 o MEP-ID; the MEP's own identity inside the ME; 1094 o list of peer MEPs inside the ME. For a point-to-point ME the list 1095 would consist of the single peer MEP ID from which the OAM packets 1096 are expected. In case of the root MEP of a p2mp ME, the list is 1097 composed by all the leaf MEP IDs inside the ME. In case of the 1098 leaf MEP of a p2mp ME, the list is composed by the root MEP ID 1099 (i.e. each leaf MUST know the root MEP ID from which it expect to 1100 receive the CC-V OAM packets). 1102 o transmission rate; the default CC-V transmission periods are 1103 application dependent (see section 5.1.4) 1105 o PHB; it identifies the per-hop behaviour of CC-V packet. Proactive 1106 CC-V packets are transmitted with the "minimum loss probability 1107 PHB" previously configured within a single network operator. This 1108 PHB is configurable on network operator's basis. PHBs can be 1109 translated at the network borders. 1111 For statically provisioned transport paths the above information are 1112 statically configured; for dynamically established transport paths 1113 the configuration information are signaled via the control plane. 1115 5.1.4. Applications for proactive CC-V 1117 CC-V is applicable for fault management, performance monitoring, or 1118 protection switching applications. 1120 o Fault Management: default transmission period is 1s (i.e. 1121 transmission rate of 1 packet/second) 1123 o Performance Monitoring: default transmission period is 100ms (i.e. 1124 transmission rate of 10 packets/second) 1126 o Protection Switching: in order to achieve sub-50ms recovery time 1127 the default transmission period is 3.33ms (i.e. transmission rate 1128 of 300 packets/second) although a transmission period of 10ms can 1129 also be used. In some cases, when a slower recovery time is 1130 acceptable, it is also possible to lengthen the transmission rate. 1132 It SHOULD be possible for the operator to configure these 1133 transmission rates for all applications, to satisfy his internal 1134 requirements. 1136 In addition, the operator should be able to define the consequent 1137 action to be performed for each of these applications. 1139 5.2. Remote Defect Indication 1141 The Remote Defect Indication (RDI) is an indicator that is 1142 transmitted by a MEP to communicate to its peer MEPs that a signal 1143 fail condition exists. RDI is only used for bidirectional 1144 connections and is associated with proactive CC-V activation. The RDI 1145 indicator is piggy-backed onto the CC-V packet. 1147 When a MEP detects a signal fail condition (e.g. in case of a 1148 continuity or connectivity defect or an AIS condition is detected), 1149 it should begin transmitting an RDI indicator to its peer MEP. The 1150 RDI information will be included in all pro-active CC-V packets that 1151 it generates for the duration of the signal fail condition's 1152 existence. 1154 [Editor's note - Add some forward compatibility information to cover 1155 the case where future OAM mechanisms that contributes to the signal 1156 fail detection (and RDI generation) are defined.] 1158 A MEP that receives the packets with the RDI information should 1159 determine that its peer MEP has encountered a defect condition 1160 associated with a signal fail. 1162 MIPs as well as intermediate nodes not supporting MPLS-TP OAM are 1163 transparent to the RDI indicator and forward these proactive CC-V 1164 packets that include the RDI indicator as regular data packets, i.e. 1165 the MIP should not perform any actions nor examine the indicator. 1167 When the signal fail defect condition clears, the MEP should clear 1168 the RDI indicator from subsequent transmission of pro-active CC-V 1169 packets. A MEP should clear the RDI defect upon reception of a pro- 1170 active CC-V packet from the source MEP with the RDI indicator 1171 cleared. 1173 5.2.1. Configuration considerations 1175 In order to support RDI indication, the RDI transmission rate and PHB 1176 of the MEP should be configured as part of the CC-V configuration. 1178 5.2.2. Applications for Remote Defect Indication 1180 RDI is applicable for the following applications: 1182 o Single-ended fault management - A MEP that receives an RDI 1183 indication from its peer MEP, can report a far-end defect 1184 condition (i.e. the peer MEP has detected a signal fail condition 1185 in the traffic direction from the MEP that receives the RDI 1186 indication to the peer MEP that has sent the RDI information). 1188 o Contribution to far-end performance monitoring - The indication of 1189 the far-end defect condition is used as a contribution to the 1190 bidirectional performance monitoring process. 1192 5.3. Alarm Reporting 1194 Alarm Reporting function relies upon an Alarm Indication Signal (AIS) 1195 message used to suppress alarms following detection of defect 1196 conditions at the server (sub) layer. 1198 o A server MEP that detects a signal fail conditions in the server 1199 (sub-)layer, can generate packets with AIS information in a 1200 direction opposite to its peers MEPs to allow the suppression of 1201 secondary alarms at the MEP in the client (sub-)layer. 1203 A server MEP is responsible for notifying the MPLS-TP layer network 1204 MEP upon fault detection in the server layer network to which the 1205 server MEP is associated. 1207 Only Server MEPs can issue MPLS-TP packets with AIS information. Upon 1208 detection of a signal fail condition the Server MEP can immediately 1209 start transmitting periodic packets with AIS information. These 1210 periodic packets, with AIS information, continue to be transmitted 1211 until the signal fail condition is cleared. 1213 Upon receiving a packet with AIS information an MPLS-TP MEP detects 1214 an AIS defect condition and suppresses loss of continuity alarms 1215 associated with all its peer MEPs. A MEP resumes loss of continuity 1216 alarm generation upon detecting loss of continuity defect conditions 1217 in the absence of AIS condition. 1219 For example, let's consider a fiber cut between LSR 1 and LSR 2 in 1220 the reference network of Figure 3. Assuming that all the MEs 1221 described in Figure 3 have pro-active CC-V enabled, a LOC defect is 1222 detected by the MEPs of Sec12 SME, PSN13 LME, PW1 PTCME and PW1Z PME, 1223 however in transport network only the alarm associate to the fiber 1224 cut needs to be reported to NMS while all these secondary alarms 1225 should be suppressed (i.e. not reported to the NMS or reported as 1226 secondary alarms). 1228 If the fiber cut is detected by the MEP in the physical layer (in 1229 LSR2), LSR2 can generate the proper alarm in the physical layer and 1230 suppress the secondary alarm associated with the LOC defect detected 1231 on Sec12 SME. As both MEPs reside within the same node, this process 1232 does not involve any external protocol exchange. Otherwise, if the 1233 physical layer has not enough OAM capabilities to detect the fiber 1234 cut, the MEP of Sec12 SME in LSR2 will report a LOC alarm. 1236 In both cases, the MEP of Sec12 SME in LSR 2 generates AIS packets on 1237 the PSN13 LME in order to allow its MEP in LSR3 to suppress the LOC 1238 alarm. 1240 LSR3 can also suppress the secondary alarm on PW1 PTCME because the 1241 MEP of PW1 PTCME resides within the same node as the MEP of PSN13 1242 LME. 1244 The MEP of PW1 PTCME in LSR3 also generates AIS packets on PW1Z PME 1245 in order to allow its MEP in LSRZ to suppress the LOC alarm. 1247 The generation of AIS packets for each MEs in the client (sub-)layer 1248 is configurable (i.e. the operator can enable/disable the AIS 1249 generation). 1251 AIS packets are transmitted with the "minimum loss probability PHB" 1252 within a single network operator. This PHB is configurable on network 1253 operator's basis. 1255 A MIP is transparent to packets with AIS information and therefore 1256 does not require any information to support AIS functionality. 1258 5.4. Lock Reporting 1260 [Editor's note - Requirements for Lock Indication and Lock Reporting 1261 are still under discussion in draft-ietf-mpls-tp-oam-requirement-02. 1263 Lock Indication is not required by draft-ietf-mpls-tp-oam- 1264 requirement-02 This section will be aligned according to the final 1265 decision regarding the requirement.] 1266 To be incorporated in a future revision of this document 1268 5.5. Lock Indication 1270 [Editor's note - Requirements for Lock Indication and Lock Reporting 1271 are still under discussion in draft-ietf-mpls-tp-oam-requirement-02. 1273 Lock Indication is not required by draft-ietf-mpls-tp-oam- 1274 requirement-02 This section will be aligned according to the final 1275 decision regarding the requirement.] 1277 The Locked Indication Signal (LIS) is used to propagate an 1278 administrative locking of a source MEP and consequential interruption 1279 of data forwarding towards the sink MEP. It allows a sink MEP 1280 receiving LIS to differentiate between a defect condition and an 1281 administrative locking action at the source MEP. An example 1282 application that requires administrative locking of a MEP is the out- 1283 of-service test. 1285 5.6. Packet Loss 1287 Packet Loss (LM) is one of the capabilities supported by the MPLS-TP 1288 Performance Monitoring (PM) function in order to facilitate reporting 1289 of QoS information for a transport path. LM is used to exchange 1290 counter values for the number of ingress and egress packets 1291 transmitted and received by the transport path monitored by a pair of 1292 MEPs. 1294 Pro-active LM is performed by periodically sending LM OAM packets 1295 from a MEP to a peer MEP and by receiving LM OAM packets from the 1296 peer MEP (if a bidirectional transport path) during the life time of 1297 the transport path. Each MEP performs measurements of its transmitted 1298 and received packets. These measurements are then correlated to 1299 derive the impact of packet loss on a number of performance metrics 1300 for the transport path. 1302 For a MEP, near-end packet loss refers to packet loss associated with 1303 incoming data packets (from the far-end MEP) while far-end packet 1304 loss refers to packet loss associated with egress data packets 1305 (towards the far-end MEP). 1307 5.6.1. Configuration considerations 1309 In order to support pro-active LM, the transmission rate and PHB 1310 associated with the LM OAM packets originating from a MEP need be 1311 configured as part of the LM provisioning procedures. LM OAM packets 1312 should be transmitted with the PHB that yields the lowest packet loss 1313 performance among the PHB Scheduling Classes or Ordered Aggregates 1314 (see RFC 3260 [14]) in the monitored transport path for the relevant 1315 network domain(s). 1317 5.6.2. Applications for Packet Loss 1319 LM is relevant for the following applications: 1321 o Single or double-end performance monitoring: determination of the 1322 packet loss performance of a transport path for SLS verification 1323 purposes. 1325 o Single or double-end performance monitoring: determination of the 1326 packet loss performance of a PHB Scheduling Class or Ordered 1327 Aggregate within a transport path 1329 o Contribution to service unable time. Both near-end and far-end 1330 packet loss measurements contribute to performance metrics such as 1331 near-end severely errored seconds (Near-End SES) and far-end 1332 severely errored seconds (Far-End SES) respectively, which 1333 together contribute to unavailable time, in a manner similar to 1334 Recommendation G.826 [19] and Recommendation G.7710 [20]. 1336 5.7. Client Failure Indication 1338 The Client Failure Indication (CSF) function is used to help process 1339 client defects and propagate a client signal defect condition from 1340 the process associated with the local attachment circuit where the 1341 defect was detected (typically the source adaptation function for the 1342 local client interface) to the process associated with the far-end 1343 attachment circuit (typically the source adaptation function for the 1344 far-end client interface) for the same transmission path in case the 1345 client of the transmission path does not support a native 1346 defect/alarm indication mechanism, e.g. FDI/AIS. 1348 A source MEP starts transmitting a CSF indication to its peer MEP 1349 when it receives a local client signal defect notification via its 1350 local CSF function. Mechanisms to detect local client signal fail 1351 defects are technology specific. 1353 A sink MEP that has received a CSF indication report this condition 1354 to its associated client process via its local CSF function. 1355 Consequent actions toward the client attachment circuit are 1356 technology specific. 1358 5.7.1. Configuration considerations 1360 In order to support RCSF indication, the CSF transmission rate and 1361 PHB of the CSF OAM packet should be configured as part of the CSF 1362 configuration. 1364 5.7.2. Applications for Remote Defect Indication 1366 CSF is applicable for the following applications: 1368 o Single-ended fault management - A MEP that receives a CSF 1369 indication from its peer MEP, can report a far-end client defect 1370 condition (i.e. the peer MEP has been informed of local client 1371 signal fail condition in the traffic direction from the client to 1372 the peer MEP that transmitted the CSF). 1374 o Contribution to far-end performance monitoring - The indication of 1375 the far-end defect condition may be used to account on network 1376 operator contribution to the bidirectional performance monitoring 1377 process. 1379 CSF supports the application described in Appendix VIII of ITU-T 1380 G.806 [18]. 1382 5.8. Delay Measurement 1384 Delay Measurement (DM) is one of the capabilities supported by the 1385 MPLS-TP PM function in order to facilitate reporting of QoS 1386 information for a transport path. Specifically, pro-active DM is used 1387 to measure the long-term packet delay and packet delay variation in 1388 the transport path monitored by a pair of MEPs. 1390 Pro-active DM is performed by sending periodic DM OAM packets from a 1391 MEP to a peer MEP and by receiving DM OAM packets from the peer MEP 1392 (if a bidirectional transport path) during a configurable time 1393 interval. 1395 Pro-active DM can be operated in two ways: 1397 o One-way: a MEP sends DM OAM packet to its peer MEP containing all 1398 the required information to facilitate one-way packet delay and/or 1399 one-way packet delay variation measurements at the peer MEP. 1401 o Two-way: a MEP sends DM OAM packet with a DM request to its peer 1402 MEP, which replies with an DM OAM packet as a DM response. The 1403 request/response DM OAM packets containing all the required 1404 information to facilitate two-way packet delay and/or two-way 1405 packet delay variation measurements from the viewpoint of the 1406 source MEP. 1408 5.8.1. Configuration considerations 1410 In order to support pro-active DM, the transmission rate and PHB 1411 associated with the DM OAM packets originating from a MEP need be 1412 configured as part of the LM provisioning procedures. DM OAM packets 1413 should be transmitted with the PHB that yields the lowest packet loss 1414 performance among the PHB Scheduling Classes or Ordered Aggregates 1415 (see RFC 3260 [14]) in the monitored transport path for the relevant 1416 network domain(s). 1418 5.8.2. Applications for Packet Loss 1420 DM is relevant for the following applications: 1422 o Single or double-end performance monitoring: determination of the 1423 delay performance of a transport path for SLS verification 1424 purposes. 1426 o Single or double-end performance monitoring: determination of the 1427 delay performance of a PHB Scheduling Class or Ordered Aggregate 1428 within a transport path 1430 6. OAM Functions for on-demand monitoring 1432 6.1. Connectivity Verification 1434 In order to preserve network resources, e.g. bandwidth, processing 1435 time at switches, it may be preferable to not use pro-active CC-V. 1436 In order to perform fault management functions network management may 1437 invoke periodic on-demand bursts of on-demand CV packets. Use of on- 1438 demand CV is dependent on the existence of a bi-directional 1439 connection ME, because it requires the presence of a return path in 1440 the data plane. 1442 [Editor's note - Clarify in the sentence above and within the 1443 paragraph that on-demand CV requires a return path to send back the 1444 reply to on-demand CV packets] 1446 An additional use of on-demand CV would be to detect and locate a 1447 problem of connectivity when a problem is suspected or known based on 1448 other tools. In this case the functionality will be triggered by the 1449 network management in response to a status signal or alarm 1450 indication. 1452 On-demand CV is based upon generation of on-demand CV packets that 1453 should uniquely identify the ME that is being checked. The on-demand 1454 functionality may be used to check either an entire ME (end-to-end) 1455 or between a MEP to a specific MIP. 1457 On-demand CV may generate a one-time burst of on-demand CV packets, 1458 or be used to invoke periodic, non-continuous, bursts of on-demand CV 1459 packets. The number of packets generated in each burst is 1460 configurable at the MEPs, and should take into account normal packet- 1461 loss conditions. 1463 When invoking a periodic check of the ME, the source MEP should issue 1464 a burst of on-demand CV packets that uniquely identifies the ME being 1465 verified. The number of packets and their transmission rate should 1466 be pre-configured and known to both the source MEP and the target MEP 1467 or MIP. The source MEP should use the TTL field to indicate the 1468 number of hops necessary, when targeting a MIP and use the default 1469 value when performing an end-to-end check [IB => This is quite 1470 generic for addressing packets to MIPs and MEPs so it is better to 1471 move this text in section 2]. The target MEP/MIP shall return a 1472 reply on-demand CV packet for each packet received. If the expected 1473 number of on-demand CV reply packets is not received at source MEP, a 1474 LOC state is detected. 1476 [Editor's note - We need to add some text for the usage of on-demand 1477 CV with different packet sizes, e.g. to discover MTU problems.] 1479 When a connectivity problem is detected (e.g. via a pro-active CC-V 1480 OAM tool), on demand CV tool can be used to check the path. The 1481 series should check CV from MEP to peer MEP on the path, and if a 1482 fault is discovered, by lack of response, then additional checks may 1483 be performed to each of the intermediate MIP to locate the fault. 1485 6.1.1. Configuration considerations 1487 For on-demand CV the MEP should support configuration of number of 1488 packets to be transmitted/received in each burst of transmissions and 1489 their packet size. The transmission rate should be either pre- 1490 configured or negotiated between the different nodes. 1492 In addition, when the CV packet is used to check connectivity toward 1493 a target MIP, the number of hops to reach the target MIP should be 1494 configured. 1496 The PHB of the on-demand CV packets should be configured as well. 1498 [Editor's note - We need to be better define the reason for such 1499 configuration] 1501 6.2. Packet Loss 1503 On-demand Packet Loss (LM) is one of the capabilities supported by 1504 the MPLS-TP Performance Monitoring function in order to facilitate 1505 diagnostic of QoS performance for a transport path. As Pro-active LM, 1506 on-demand LM is used to exchange counter values for the number of 1507 ingress and egress packets transmitted and received by the transport 1508 path monitored by a pair of MEPs. 1510 On-demand LM is performed by periodically sending LM OAM packets from 1511 a MEP to a peer MEP and by receiving LM OAM packets from the peer MEP 1512 (if a bidirectional transport path) during a pre-defined monitoring 1513 period. Each MEP performs measurements of its transmitted and 1514 received packets. These measurements are then correlated evaluate the 1515 packet loss performance metrics of the transport path. 1517 6.2.1. Configuration considerations 1519 In order to support on-demand LM, the beginning and duration of the 1520 LM procedures,the transmission rate and PHB associated with the LM 1521 OAM packets originating from a MEP must be configured as part of the 1522 on-demand LM provisioning procedures. LM OAM packets should be 1523 transmitted with the PHB that yields the lowest packet loss 1524 performance among the PHB Scheduling Classes or Ordered Aggregates 1525 (see RFC 3260 [14]) in the monitored transport path for the relevant 1526 network domain(s). 1528 6.2.2. Applications for On-demand Packet Loss 1530 On-demand LM is relevant for the following applications: 1532 o Single-end performance monitoring: diagnostic of the packet loss 1533 performance of a transport path for SLS trouble shooting purposes. 1535 o Single-end performance monitoring: diagnostic of the packet loss 1536 performance of a PHB Scheduling Class or Ordering Aggregate within 1537 a transport path for QoS trouble shooting purposes. 1539 6.3. Diagnostic 1541 To be incorporated in a future revision of this document 1543 6.4. Route Tracing 1545 To be incorporated in a future revision of this document 1547 6.5. Delay Measurement 1549 Delay Measurement (DM) is one of the capabilities supported by the 1550 MPLS-TP PM function in order to facilitate reporting of QoS 1551 information for a transport path. Specifically, on-demand DM is used 1552 to measure packet delay and packet delay variation in the transport 1553 path monitored by a pair of MEPs during a pre-defined monitoring 1554 period. 1556 On-Demand DM is performed by sending periodic DM OAM packets from a 1557 MEP to a peer MEP and by receiving DM OAM packets from the peer MEP 1558 (if a bidirectional transport path) during a configurable time 1559 interval. 1561 On-demand DM can be operated in two ways: 1563 o One-way: a MEP sends DM OAM packet to its peer MEP containing all 1564 the required information to facilitate one-way packet delay and/or 1565 one-way packet delay variation measurements at the peer MEP. 1567 o Two-way: a MEP sends DM OAM packet with a DM request to its peer 1568 MEP, which replies with an DM OAM packet as a DM response. The 1569 request/response DM OAM packets containing all the required 1570 information to facilitate two-way packet delay and/or two-way 1571 packet delay variation measurements from the viewpoint of the 1572 source MEP. 1574 6.5.1. Configuration considerations 1576 In order to support on-demand DM, the beginning and duration of the 1577 DM procedures, the transmission rate and PHB associated with the DM 1578 OAM packets originating from a MEP need be configured as part of the 1579 LM provisioning procedures. DM OAM packets should be transmitted with 1580 the PHB that yields the lowest packet delay performance among the PHB 1581 Scheduling Classes or Ordering Aggregates (see RFC 3260 [14]) in the 1582 monitored transport path for the relevant network domain(s). 1584 6.5.2. Applications for Delay Measurement 1586 DM is relevant for the following applications: 1588 o Single or double-end performance monitoring: determination of the 1589 packet delay and/or delay variation performance of a transport 1590 path for SLS verification purposes. 1592 o Single or double-end performance monitoring: determination of the 1593 packet delay and/or delay variation a PHB Scheduling Class or 1594 Ordering Aggregate within a transport path 1596 o Contribution to service unable time. Packet delay measurements may 1597 contribute to performance metrics such as near-end severely 1598 errored seconds (Near-End SES) and far-end severely errored 1599 seconds (Far-End SES), which together contribute to unavailable 1600 time. 1602 6.6. Lock Instruct 1604 To be incorporated in a future revision of this document 1606 7. Security Considerations 1608 A number of security considerations important in the context of OAM 1609 applications. 1611 OAM traffic can reveal sensitive information such as passwords, 1612 performance data and details about e.g. the network topology. The 1613 nature of OAM data therefore suggests to have some form of 1614 authentication, authorization and encryption in place. This will 1615 prevent unauthorized access to vital equipment and it will prevent 1616 third parties from learning about sensitive information about the 1617 transport network. 1619 Mechanisms that the framework does not specify might be subject to 1620 additional security considerations. 1622 8. IANA Considerations 1624 No new IANA considerations. 1626 9. Acknowledgments 1628 The authors would like to thank all members of the teams (the Joint 1629 Working Team, the MPLS Interoperability Design Team in IETF and the 1630 T-MPLS Ad Hoc Group in ITU-T) involved in the definition and 1631 specification of MPLS Transport Profile. 1633 This document was prepared using 2-Word-v2.0.template.dot. 1635 10. References 1637 10.1. Normative References 1639 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1640 Levels", BCP 14, RFC 2119, March 1997 1642 [2] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label 1643 Switching Architecture", RFC 3031, January 2001 1645 [3] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032, 1646 January 2001 1648 [4] Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in 1649 Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, 1650 January 2003 1652 [5] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge 1653 (PWE3) Architecture", RFC 3985, March 2005 1655 [6] Nadeau, T., Pignataro, S., "Pseudowire Virtual Circuit 1656 Connectivity Verification (VCCV): A Control Channel for 1657 Pseudowires", RFC 5085, December 2007 1659 [7] Bocci, M., Bryant, S., "An Architecture for Multi-Segment 1660 Pseudo Wire Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw- 1661 arch-05 (work in progress), September 2008 1663 [8] Bocci, M., et al., "A Framework for MPLS in Transport 1664 Networks", draft-ietf-mpls-tp-framework-01 (work in progress), 1665 June 2009 1667 [9] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R., 1668 "MPLS Generic Associated Channel ", RFC 5586, June 2009 1670 10.2. Informative References 1672 [10] Niven-Jenkins, B., Brungard, D., Betts, M., sprecher, N., Ueno, 1673 S., "MPLS-TP Requirements", draft-ietf-mpls-tp-requirements-09 1674 (work in progress), June 2009 1676 [11] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in 1677 MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements- 1678 02 (work in progress), June 2009 1680 [12] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, Y., 1681 "MPLS-TP OAM Analysis", draft-sprecher-mpls-tp-oam-analysis-04 1682 (work in progress), May 2009 1684 [13] Nichols, K., Blake, S., Baker, F., Black, D., "Definition of 1685 the Differentiated Services Field (DS Field) in the IPv4 and 1686 IPv6 Headers", RFC 2474, December 1998 1688 [14] Grossman, D., "New terminology and clarifications for 1689 Diffserv", RFC 3260, April 2002. 1691 [15] Farrel, A., Ayyangar, A., Vasseur, JP., "Inter-Domain MPLS and 1692 GMPLS Traffic Engineering -- Resource Reservation Protocol- 1693 Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 1694 2008 1696 [16] ITU-T Recommendation G.707/Y.1322 (01/07), "Network node 1697 interface for the synchronous digital hierarchy (SDH)", January 1698 2007 1700 [17] ITU-T Recommendation G.805 (03/00), "Generic functional 1701 architecture of transport networks", March 2000 1703 [18] ITU-T Recommendation G.806 (01/09), "Characteristics of 1704 transport equipment - Description methodology and generic 1705 functionality ", January 2009 1707 [19] ITU-T Recommendation G.826 (12/02), "End-to-end error 1708 performance parameters and objectives for international, 1709 constant bit-rate digital paths and connections", December 2002 1711 [20] ITU-T Recommendation G.7710 (07/07), "Common equipment 1712 management function requirements", July 2007 1714 [21] ITU-T Recommendation Y.2611 (06/12), " High-level architecture 1715 of future packet-based networks", 2006 1717 Authors' Addresses 1719 Italo Busi (Editor) 1720 Alcatel-Lucent 1722 Email: Italo.Busi@alcatel-lucent.it 1723 Ben Niven-Jenkins (Editor) 1724 BT 1726 Email: benjamin.niven-jenkins@bt.com 1728 Contributing Authors' Addresses 1730 Annamaria Fulignoli 1731 Ericsson 1733 Email: annamaria.fulignoli@ericsson.com 1735 Enrique Hernandez-Valencia 1736 Alcatel-Lucent 1738 Email: enrique@alcatel-lucent.com 1740 Lieven Levrau 1741 Alcatel-Lucent 1743 Email: llevrau@alcatel-lucent.com 1745 Dinesh Mohan 1746 Nortel 1748 Email: mohand@nortel.com 1750 Vincenzo Sestito 1751 Alcatel-Lucent 1753 Email: vincenzo.sestito@alcatel-lucent.it 1755 Nurit Sprecher 1756 Nokia Siemens Networks 1758 Email: nurit.sprecher@nsn.com 1759 Huub van Helvoort 1760 Huawei Technologies 1762 Email: hhelvoort@huawei.com 1764 Martin Vigoureux 1765 Alcatel-Lucent 1767 Email: martin.vigoureux@alcatel-lucent.fr 1769 Yaacov Weingarten 1770 Nokia Siemens Networks 1772 Email: yaacov.weingarten@nsn.com 1774 Rolf Winter 1775 NEC 1777 Email: Rolf.Winter@nw.neclab.eu