idnits 2.17.1 draft-xia-mpls-tp-p2mp-oam-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 53 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 27, 2010) is 5021 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-mpls-tp-oam-requirements' is defined on line 1020, but no explicit reference was found in the text == Unused Reference: 'RFC5586' is defined on line 1046, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-farrel-mpls-tp-mip-mep-map-02 == Outdated reference: A later version (-03) exists of draft-he-mpls-tp-csf-02 == Outdated reference: A later version (-15) exists of draft-ietf-mpls-ldp-p2mp-10 == Outdated reference: A later version (-18) exists of draft-ietf-mpls-p2mp-lsp-ping-10 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-cc-cv-rdi-01 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-tp-fault-02 == Outdated reference: A later version (-01) exists of draft-ietf-mpls-tp-lsp-ping-bfd-procedures-00 == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-static-pw-status-00 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-tp-oam-analysis-02 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-tp-oam-framework-07 Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group L. Xia 3 Internet-Draft M. xiao 4 Intended status: Informational X. Dai 5 Expires: January 28, 2011 J. Yang 6 ZTE Corporation 7 July 27, 2010 9 MPLS-TP P2MP OAM analysis 10 draft-xia-mpls-tp-p2mp-oam-analysis-00 12 Abstract 14 This document attempts to analyze MPLS-TP P2MP OAM implementations 15 and related problems by combining with MPLS-TP P2MP network 16 characteristics and the MPLS-TP OAM requirements. We give a specific 17 analysis to some key issues in P2MP scenarios. And we analyze every 18 MPLS-TP OAM function in P2MP scenarios and give guidelines or 19 recommendations. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 28, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Movitation and Scope . . . . . . . . . . . . . . . . . . . 3 57 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 59 1.4. MPLS P2MP signaling technology overview . . . . . . . . . 5 60 1.5. MPLS-TP P2MP OAM requirements and current solutions . . . 5 61 2. P2MP key issues . . . . . . . . . . . . . . . . . . . . . . . 9 62 2.1. Scalability issue . . . . . . . . . . . . . . . . . . . . 9 63 2.2. Return path . . . . . . . . . . . . . . . . . . . . . . . 9 64 2.3. P2MP Node Identifier TLV . . . . . . . . . . . . . . . . . 9 65 2.4. TTL setting and handle . . . . . . . . . . . . . . . . . . 10 66 2.5. Bud node analysis . . . . . . . . . . . . . . . . . . . . 11 67 2.6. SPME OAM in P2MP . . . . . . . . . . . . . . . . . . . . . 13 68 2.7. Locally independence requirements . . . . . . . . . . . . 13 69 2.8. Per-interface MIP/MEP . . . . . . . . . . . . . . . . . . 13 70 3. P2MP OAM Functions Analysis . . . . . . . . . . . . . . . . . 14 71 3.1. Continuity Check and Pro-active Connectivity 72 Verification and Remote Defect Indication . . . . . . . . 14 73 3.2. Alarm Reporting and Lock Reporting . . . . . . . . . . . . 15 74 3.3. On-demand Connectivity Verification and Route Tracing . . 16 75 3.4. Diagnostic Tests . . . . . . . . . . . . . . . . . . . . . 17 76 3.4.1. Throughput Estimation . . . . . . . . . . . . . . . . 17 77 3.4.2. Data Plane Loopback . . . . . . . . . . . . . . . . . 18 78 3.5. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 19 79 3.6. Client Failure Indication . . . . . . . . . . . . . . . . 19 80 3.7. Packet Loss Measurement . . . . . . . . . . . . . . . . . 20 81 3.8. Packet Delay Measurement . . . . . . . . . . . . . . . . . 20 82 4. P2MP PW analysis . . . . . . . . . . . . . . . . . . . . . . . 20 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 23 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 91 1. Introduction 93 1.1. Movitation and Scope 95 MPLS-TP OAM provides efficient and reliable methods for fault 96 management and performance monitoring. It also can help operators to 97 meet the SLAs while reducing their operational costs. 99 [RFC5654] in general, and [RFC5860] in particular define a set of 100 requirements for OAM functionality applied to MPLS-TP Label Switched 101 Paths (LSPs) (network infrastructure) and Pseudowires (PWs) 102 (services). [I-D.ietf-mpls-tp-oam-analysis] has given an analysis to 103 those existing OAM tools defined for MPLS and in ITU-T, including LSP 104 Ping, MPLS BFD, VCCV, and Y.1731. It has identified which tools need 105 to be extended to comply with the MPLS-TP OAM requirements, and which 106 new tools need to be defined. 108 Based on above documents, some drafts concerning specific OAM tool 109 have been worked out. Including 110 [I-D.ietf-mpls-tp-lsp-ping-bfd-procedures], 111 [I-D.ietf-mpls-tp-cc-cv-rdi], 112 [I-D.nitinb-mpls-tp-lsp-ping-extensions], etc. 114 The current situation is that these above drafts mainly focus on the 115 analysis and implementation of P2P OAM, and they do not have enough 116 in-depth analysis with respect to P2MP OAM. 118 Then this document attempts to analyze MPLS-TP P2MP OAM 119 implementations and related problems by combining with MPLS-TP P2MP 120 network characteristics and the MPLS-TP OAM requirements. Solutions 121 are provided for some problems, and others need further study. 123 This document is arranged as follows: first, an overview of MPLS P2MP 124 technology and MPLS-TP P2MP OAM requirements with current solutions, 125 which is given as a starting point for following discussion; 126 secondly, from the structure point of view, a specific analysis is 127 given to some key issues; finally, from a functional perspective, 128 every MPLS-TP P2MP OAM function is analyzed and guidelines or 129 recommendations are given. 131 1.2. Conventions 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 1.3. Abbreviations 139 ACH: Associated Channel Header 141 BFD: Bidirectional Forwarding Detection 143 CC: Continuity Check 145 CRC: Cyclic Redundancy Check 147 CV: Connectivity Verification 149 DM: Packet Delay Measurement 151 LB: Loopback 153 LDP: Label Distribution Protocol 155 LM: Loss Measurement 157 LSP: Label Switched Path 159 MEG: Maintenance Entity Group 161 MEP: Maintenance Entity Group End Point 163 MIP: Maintenance Entity Group Intermediate Point 165 MPLS-TP: MPLS Transport Profile 167 OAM: Operations, Administration and Maintenance 169 P2P: Point to Point 171 P2MP: Point to MultiPoint 173 PW: PseudoWire 175 RSVP-TE: Resource Reservation Protocol-Traffic Engineering 177 SLA: Service Level Agreement 179 SPME: Sub-Path Maintenance Element 181 TLV: Type Length Value 183 VCCV: Virtual Circuit Connection Verification 185 1.4. MPLS P2MP signaling technology overview 187 P2MP service is used to deliver data from a single source to one or 188 more receivers. This service can be simply supported by combination 189 of P2P LSPs. But the fully efficient way (mainly refer to bandwidth 190 consumption, numbers of used LSPs) to support P2MP service is using 191 P2MP LSP. P2MP LSP has only one ingress LSR,but may have one or more 192 egress LSRs. Data traffic is efficiently replicated in branch LSRs. 193 Signaling requirements for the P2MP TE LSPs can refer to [RFC4461]. 195 Currently, there are two kinds of signaling protocol mechanisms to 196 build P2MP LSP: 198 1. Extensions to RSVP-TE protocol for P2MP TE LSPs([RFC4875]):This 199 solution relies on the semantics of the Resource Reservation 200 Protocol (RSVP) that RSVP-TE inherits for building P2MP LSPs. It 201 doesn't require a multicast routing protocol in the Service 202 Provider core. A P2MP LSP is comprised of multiple source-to- 203 leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between the 204 ingress and egress LSRs and are appropriately combined by the 205 branch LSRs using RSVP semantics to result in a P2MP TE LSP. One 206 Path message may signal one or multiple S2L sub-LSPs for a single 207 P2MP LSP. Hence the S2L sub-LSPs belonging to a P2MP LSP can be 208 signaled using one Path message or split across multiple Path 209 messages. 211 2. LDP Extensions for P2MP and MP2MP LSPs([I-D.ietf-mpls-ldp-p2mp]): 212 These extensions are also referred to as mLDP Multicast LDP. mLDP 213 constructs the P2MP or MP2MP LSPs without interacting with or 214 relying upon any other multicast tree construction protocol. 215 Leaf nodes initiate P2MP LSP setup and tear-down. Leaf nodes 216 also install forwarding state to deliver the traffic received on 217 a P2MP LSP to wherever it needs to go. Transit nodes install 218 MPLS forwarding state and propagate the P2MP LSP setup (and tear- 219 down) toward the root. The root node installs forwarding state 220 to map traffic into the P2MP LSP. 222 MPLS-TP decides to build P2MP TE LSP by using RSVP-TE signaling 223 protocol in Control Plane or by static configuration in Management 224 Plane. LDP Extensions for P2MP is outside the scope of this 225 document. 227 1.5. MPLS-TP P2MP OAM requirements and current solutions 229 MPLS-TP OAM is running on Data Plane. So, its implementation 230 mechanism must be based on the characteristics of the data plane. 231 The basic characteristics of the data plane in P2MP network is a 232 unidirectional tree topology. Data traffic is sent from the only one 233 ingress LSR, and replicated in branch LSRs, received by all (one or 234 more) egress LSRs. 236 MPLS P2MP OAM requirements([RFC4687]) analyzes from various 237 functional point of view, including Detection and Diagnosis of LSP 238 Defects, Path Characterization, SLA Measurement, Frequency of OAM 239 Execution, Alarm Suppression, Fault Notification, etc. It gives the 240 general requirements and related high-level analysis about OAM 241 implementations in P2MP MPLS network. 243 MPLS-TP OAM Requirements ([RFC5860]) analyzes the OAM requirements in 244 MPLS-TP network from the architectural and functional these two 245 aspects. The table below gives a summary about P2MP part in this 246 document: 248 +-----------+------------+-----------+---------------+---------+-----------+ 249 | Item | pro-active | on-demand | path type | P2MP | out of | 250 | | | | | | band | 251 | | | | | | return | 252 | | | | | | path | 253 | | | | | | for | 254 | | | | | | P2MP | 255 +-----------+------------+-----------+---------------+---------+-----------+ 256 | CC | support | no | E2E | support | no need | 257 | | | support | | | | 258 | | | | | | | 259 +-----------+------------+-----------+---------------+---------+-----------+ 260 | CV | support | support | pro-active: | support | on-demand | 261 | | | | E2E, | | need | 262 | | | | on-demand:E2E | | | 263 | | | | or E2I | | | 264 +-----------+------------+-----------+---------------+---------+-----------+ 265 | Route | no | support | E2E or E2I | support | need | 266 | Tracing, | support | | | | | 267 | Diagnostic| | | | | | 268 | Tests | | | | | | 269 | | | | | | | 270 +-----------+------------+-----------+---------------+---------+-----------+ 271 | Lock | support | no | I2E | support | no need | 272 | Reporting,| | support | | | | 273 | Alarm | | | | | | 274 | Reporting | | | | | | 275 | | | | | | | 276 +-----------+------------+-----------+---------------+---------+-----------+ 277 | Remote | support | no | E2E | support | need | 278 | Defect | | support | | | | 279 | Indication| | | | | | 280 | | | | | | | 281 +-----------+------------+-----------+---------------+---------+-----------+ 282 | Client | support | no | E2E | support | no need | 283 | Failure | | support | | | | 284 | Indication| | | | | | 285 | | | | | | | 286 +-----------+------------+-----------+---------------+---------+-----------+ 287 | Packet | support | support | E2E | support | no need | 288 | Loss | | | | | | 289 |Measurement| | | | | | 290 | | | | | | | 291 +-----------+------------+-----------+---------------+---------+-----------+ 292 | Packet | support | support | E2E | one way | no need | 293 | Delay | | | | delay: | | 294 |Measurement| | | | support | | 295 | | | | | two way | | 296 | | | | | delay | | 297 | | | | | : no | | 298 | | | | | support | | 299 | | | | | | | 300 +-----------+------------+-----------+---------------+---------+-----------+ 302 Figure 1: MPLS_TP P2MP OAM requirements table 304 Notes: 306 1) The abbreviations in column "path type" of E2E, E2I, I2E means 307 separately end point to end point, end point to intermediate 308 point, intermediate point to end point; 310 2) Out of band return path for P2MP: P2MP LSP is an unidirectional 311 path from the ingress node to all of the egress nodes in Data 312 Plane. So the return path here referred does not exist in Data 313 Plane. It mainly refers to the Control Plane or IP routing 314 return path. It is usually called out of band return path. 316 MPLS-TP OAM analysis document ([I-D.ietf-mpls-tp-oam-analysis]) 317 analyzes the current OAM tools defined for MPLS and ITU-T, and gives 318 the conclusions about whether existing OAM tools can be used to meet 319 the MPLS-TP OAM requirements, and identify which tools need to be 320 extended to comply with the requirements and which new tools need to 321 be defined. Based on this document, many specific OAM tools 322 implementation documents have been produced. The table below gives a 323 summary of OAM tools implementation which is also applied to P2MP 324 scenario: 326 +--------------+-----------------+-----------------+----------------+ 327 | Items | Recommendations | Gaps | Solutions | 328 +--------------+-----------------+-----------------+----------------+ 329 | Pro-active | Extend MPLS BFD | MPLS BFD | use ACH for | 330 | CC-V, Remote | to fully | requires IP | non-IP | 331 | Defect | support | encapsulation | encapsulation | 332 | Indication | |-----------------+----------------| 333 | | | For CV, basic | define a new | 334 | | | BFD's | type ACH and a | 335 | | | limitation of | new TLV | 336 | | | locally unique | carrying the | 337 | | | (to each node) | unique source | 338 | | | session | MEP Identifier | 339 | | | identifiers | | 340 +--------------+-----------------+-----------------+----------------+ 341 | On-demand | Extend LSP Ping | LSP Ping | use ACH for | 342 | CV, Route | to fully | requires IP | non-IP | 343 | Tracing | support | encapsulation | encapsulation | 344 | | |-----------------+----------------| 345 | | | How to arrive | Proper setting | 346 | | | intermediate | of the TTL | 347 | | | node | value | 348 | | |-----------------+----------------| 349 | | | Global | Add new | 350 | | | identifiers for | type TLVs | 351 | | | Source Address, | | 352 | | | MEP, MIP etc | | 353 +--------------+-----------------+-----------------+----------------+ 354 | Lock | Extend LSP Ping | PDU and | Refer to | 355 | Instruct | to support | procedure | Y.1731 | 356 | | | definition | | 357 +--------------+-----------------+-----------------+----------------+ 358 | Alarm | Define a new | PDU and | Refer to | 359 | Reporting, | PDU which will | procedure | Y.1731 | 360 | Lock | be transmitted | definition | | 361 | Reporting, | over G-ACH to | | | 362 | Diagnostic | support | | | 363 | Tests, | | | | 364 | Packet Loss | | | | 365 | Measurement, | | | | 366 | Packet Delay | | | | 367 | Measurement | | | | 368 +--------------+-----------------+-----------------+----------------+ 369 | Client | Use PWE3 tool | PDU and | Define new | 370 | Failure | to propagate | procedure | | 371 | Indication | Client Fail | definition | | 372 | | Indication via | | | 373 | | an ACH | | | 374 +--------------+-----------------+-----------------+----------------+ 376 Figure 2: MPLS-TP P2MP OAM tools implementation summary table 378 2. P2MP key issues 380 2.1. Scalability issue 382 Scalability is a key requirement in P2MP network. Since the number 383 of egresses for a single P2MP LSP is unknown and not bounded by any 384 small number, it follows that all mechanisms defined for OAM support 385 MUST scale well with the number of egresses and the complexity of the 386 path of the LSP. So, P2MP OAM mechanisms MUST be designed to scale 387 well with an increase in the number of any of the sink MEPs and MIPs. 389 Scalability is a high-level and general requirement. How to achieve 390 it needs further study on every specific OAM tool. 392 2.2. Return path 394 P2MP LSP is inherently an unidirectional path from the ingress node 395 to all of the egress nodes in Data Plane. And in band return path 396 does not exist in Data Plane. So, it can not directly support the 397 OAM mechanism which needs to return a confirmation message. For 398 example, On-demand CV, Route Tracing, etc. In this case, we have 399 three general solutions: 401 1. Out of band return path: It mainly refers to the Control Plane or 402 IP routing return path; 404 2. In band return path: Building a P2P LSP from an egress node to 405 ingress node in Data Plane to be the in band return path; 407 3. Extending existed OAM tools to run without the support of return 408 path. This solution needs further study. 410 2.3. P2MP Node Identifier TLV 412 P2MP Node Identifier TLV here means the TLV attribute that was 413 brought in the OAM packet, and contains enough information to 414 uniquely identify the destination MEP or MIP node. It is also called 415 P2MP Responder Identifier TLV in [I-D.ietf-mpls-p2mp-lsp-ping]. 417 In a P2MP LSP, the ingress node can be the only one source MEP, all 418 the branch nodes in the middle of the P2MP tree can be the MIPs, all 419 of the bud nodes can be both sink MEPs and MIPs, all egress nodes can 420 be sink MEPS. 422 In general, OAM packets sent from the source MEP, through the Data 423 Plane, forwarded to all sink MEPs, should be processed by each sink 424 MEPs. If the OAM packets are required to be processed only by one or 425 a group of designated sink MEPs, but not all sink MEPs, then a new 426 extending mechanism--- P2MP Node Identifier TLV can achieve it. 428 An OAM packet transmitted by the source MEP can carry a number of 429 P2MP Node Identifier TLVs, corresponding to a group of designated 430 sink MEPs. This OAM packet is forwarded through Data Plane, to reach 431 all sink MEPs. Sink MEPs can use those P2MP Node Identifier TLVs 432 carried in the OAM packet to decide how to process this OAM packet. 433 A sink MEP will process the OAM packet only when it matches a P2MP 434 Node Identifier TLV in the OAM packet, or else it should discard the 435 OAM packet. Of course, if an OAM packet does not carry any P2MP Node 436 Identifier TLV, it should be processed by all sink MEPs. 438 The P2MP Node Identifier TLV only has meaning on an OAM message which 439 is sent from source MEP to sink MEPs. If present on a return OAM 440 message, it SHOULD be ignored. 442 Sometimes, OAM packets need to be processed by one or a group of 443 designated MIPs. In this case, except for P2MP Node Identifier TLV, 444 but also needs TTL together to locate the designated MIPs. Section 445 2.4 will give a more detailed description about it. 447 One possibility is that the number of sink MEPs or MIPS which need to 448 process an OAM packet is too large to carry all P2MP Node Identifier 449 TLVs in an OAM packet. In order to handle this problem, source MEP 450 can set the max number of P2MP Node Identifier TLVs in an OAM packet 451 and transmit the OAM packet for several times. 453 The TLV format based on IP address and the details of using it are 454 defined in [I-D.ietf-mpls-p2mp-lsp-ping], the non-IP definition needs 455 further study. 457 2.4. TTL setting and handle 459 In the case of MPLS-TP P2P LSP,when an OAM packet needs to be 460 processed by a MIP, it must properly set the TTL value to be the hop 461 number from the MEP to MIP, together with the only Node Identifier 462 TLV carried in the OAM packet to verify the validity of the 463 destination MIP. 465 P2MP LSP also has the same requirement. There are three cases when 466 an OAM packet transmitted from the source MEP needs to be processed 467 by one or a group of MIPs in the P2MP LSP, as follow: 469 1. Case one: Destination is one MIP. After properly setting the TTL 470 value and the P2MP Node Identifier TLV carried in the OAM packet, 471 the source MEP sends the OAM packet out, and then the OAM packet 472 is terminated in those MIPs whose hop number from the source MEP 473 is equal to the setting of TTL value. These MIPs decide whether 474 to process the OAM packet by checking the P2MP Node Identifier 475 TLV in the OAM packet. At last, only one MIP will process the 476 OAM packet and other MIPs should discard the OAM packet. 478 2. Case two: Destination is a group of MIPs which have the same hop 479 number from the source MEP. The TTL setting and processing is 480 similar with case one, the only difference is that the OAM packet 481 needs to carry more than one P2MP Node Identifier TLVs or no P2MP 482 Node Identifier TLV(aimed to all MIPs with the same TTL value). 483 At last, these group(or all) MIPs will process the OAM packet and 484 other MIPs should discard the OAM packet. 486 3. Case three: Destination includes a group of MIPs which have the 487 different hop number from the source MEP. In this case, the 488 source MEP must construct more than one OAM packets with 489 different TTL value, the destination of every OAM packet is a 490 group of MIPs which have the same hop number from the source MEP. 491 Every OAM packet can carry more than one P2MP Node Identifier 492 TLVs. 494 The above process solutions have a premise that the source MEP 495 already knew the hop number between itself and each designated MIP. 497 In above process, one possibility is that some sink MEPs may have 498 less hop number from the source MEP than the TTL value setted in the 499 OAM packet. In this case, how to process the OAM packet is nothing 500 to do with the TTL value, and the OAM packet must be terminated in 501 the sink MEPs. When the OAM packet carrys the Node Identifier TLVs, 502 the sink MEPs will discard the OAM packet because of the mismatch of 503 the P2MP Node Identifier TLV. If not, [I-D.ietf-mpls-p2mp-lsp-ping] 504 has provided a solution of a new "Respond Only If TTL Expired" flag 505 to reduce extraneous responses from sink MEPs. 507 2.5. Bud node analysis 509 In a P2MP LSP, the bud node can be not only a MIP, but also a sink 510 MEP. 512 As a MIP, the bud node should forward all the OAM packets whose 513 destination is the downstream MIPs or sink MEPs. At the same time as 514 a sink MEP, the bud node must do a copy of every OAM packet it 515 received to handle. 517 We can describe a bud node function logically in the below figure: 519 -------------------------- 520 | | | | 521 | |->| MEP | | 522 | | ----------- | 523 | | | 524 | | -----| 525 | | copy ->-| |->---- 526 | | | | Out | 527 | ^ | | i/f | 528 | | ---- | -----| 529 |----- | f | | | 530 | MIP | | o | | -----| 531 | | | r |- | | 532 ----->-| In |->-| w |--->-| Out |->---- 533 | i/f | | a |- | i/f | 534 |----- | r | | -----| 535 | | d | | | 536 | ---- | -----| 537 | | | | 538 | ->-| Out |->---- 539 | | i/f | 540 | -----| 541 -------------------------- 543 Figure 3: Bud node logic function 545 From the figure above, we can see that the MEP in bud node gets a 546 copy of the OAM packet it received to handle. This copy of OAM 547 packet is nothing to do with the OAM packets forward to downstream 548 nodes of the bud node. So, the defects such as LOC of CC or 549 unintended connectivity between two MEPs (e.g. mismerging or 550 misconnection or unexpected MEP) of CV and so on, found by the MEP in 551 the bud node are also nothing to do with the downstream nodes of the 552 bud node. 554 In general, although the bud node takes two roles of MIP and sink 555 MEP, but these two functions are still running independent of each 556 other. the OAM processing results of MEP can not in turn affect the 557 MIP operation. 559 2.6. SPME OAM in P2MP 561 SPME OAM in P2P LSP scenarios is intended to be used for monitoring 562 the behavior of a portion of a P2P LSP or a set of co-routed P2P 563 LSPs. It is implemented by means of setting the two end nodes of the 564 SPME to be MEPs and utilizing label stack to support multiple layer 565 operation. 567 Similarly, SPME OAM can also be used in P2MP LSP tree scenarios, 568 intended to be used for monitoring the behavior of a sub-tree of a 569 P2MP LSP tree. In this case, it needs to set the root and all leaf 570 nodes of the sub-tree to be MEPs, and still utilizes label stack to 571 support multiple layer operation. And the sub-tree SPME OAM MEG is 572 independent of the P2MP LSP tree OAM MEG. The OAM packet belong to 573 the latter MEG is considered a common data packet in former MEG and 574 should be forwarded in Data Plane without any OAM operations. The 575 OAM packet belong to the former MEG is only forwarded and performs 576 OAM operation between MEPs of itself, and will not leak to the latter 577 MEG. 579 More complex, if a sub-tree exists in more than one P2MP LSP trees, 580 it is preferred to implement only a sub-tree SPME OAM MEG for this 581 sub-tree. This sub-tree SPME OAM MEG can provide monitoring for all 582 P2MP LSP trees. So it does not need to have a sub-tree SPME OAM MEG 583 for every above P2MP LSP tree. Specially, when the middle portion 584 multiplexing rate of multiple P2MP LSPs is relatively high, the 585 method is particularly applicable. 587 2.7. Locally independence requirements 589 A P2MP LSP tree may contain many branches and sub-trees. From 590 scalability point of view, it requires that the partial changes 591 happened in a sub-tree only affect this sub-tree OAM functions and 592 can not affect the OAM functions of the other part of the P2MP LSP. 593 These partial changes include the add, delete, modification of the 594 sub-tree or the leafs. 596 This issue needs more examples to perform a more in-depth analysis! 598 2.8. Per-interface MIP/MEP 600 Per-interface MIP/MEP model is the extended and enhancement 601 definition of the two basic concepts of MIP and MEP. Compare to the 602 traditional Per-node MIP/MEP model, MIP and MEP can be defined and 603 run on the in interface or out interface of a node. Because of the 604 more precise location of MIP and MEP, per-interface MIP/MEP model can 605 provide more effective and more precise OAM functions such as a 606 proactive continuity check, proactive on-demand connectivity 607 verification, on-demand route tracing, on-demand loss measurement, 608 on-demand delay measurement and diagnostic test than per-node MIP/MEP 609 model. 611 [I-D.koike-ietf-mpls-tp-oam-maintenance-points] provides the 612 requirements and definitions of the Per-interface MIP/MEP model and 613 its implementations in every OAM function. 614 [I-D.farrel-mpls-tp-mip-mep-map] describes a way of forming OAM 615 messages so that they can be targeted at incoming MIPs and outgoing 616 MIPs, forwarded correctly through the "switch fabric", and handled 617 efficiently in optimized node implementations where there is no 618 distinction between the incoming and outgoing MIP. The contents of 619 these two documents can all directly apply to P2MP scenarios. 621 As for P2MP scenarios, the Per-interface MIP model in branch node 622 needs focus attention and study. Branch node has one in 623 interface,more than one out interfaces. They can all be set to be 624 MIPs so that get more precise fault location or performance 625 monitoring information than traditional Per-node model. 627 3. P2MP OAM Functions Analysis 629 3.1. Continuity Check and Pro-active Connectivity Verification and 630 Remote Defect Indication 632 As specified in [I-D.ietf-mpls-tp-oam-framework]: 634 o CC(Continuity Check) monitors the integrity of the continuity of 635 the path for any loss of continuity defect by pro-actively 636 sending OAM packet. 638 o Pro-active CV(Connectivity Verification) monitors the integrity 639 of the routing of the path between sink and source for any 640 connectivity issues by pro-actively sending OAM packet. 642 o RDI(Remote Defect Indication) enables an End Point to report, to 643 its associated End Point, a fault or defect condition that it 644 detects on a path. 646 According to [I-D.ietf-mpls-tp-oam-analysis], they can all be fully 647 supported by Extending MPLS BFD. 649 Currently, [I-D.ietf-mpls-tp-cc-cv-rdi] has already given the 650 definitions and descriptions of how MPLS BFD supports the above three 651 pro-active OAM functions. 653 RDI requires bidirectional path support. So, RDI cannot be supported 654 directly in P2MP scenario because of the inherently unidirectional 655 characteristics of P2MP, unless an out of band return path from sink 656 MEP to source MEP exists. 658 For CC and pro-active CV,below is a comparison between the P2MP LSP 659 and P2P LSP: 661 o Source MEP: Only one source MEP per LSP. The format and 662 semantics of the extended MPLS BFD packet for P2P LSP CC and pro- 663 active CV function do not need any changes to identify the source 664 MEP in the P2MP LSP. So the implementation of this two OAM 665 functions in the source MEP has no difference between the P2MP 666 LSP and the P2P LSP. 668 o Sink MEP: Only one sink MEP in a P2P LSP. P2MP LSP is extended 669 to have one or more sink MEPs. However, each sink MEP of the 670 P2MP LSP can run the OAM packets receiving and LSP defects 671 detection of the CC and pro-active CV function independently, and 672 exactly the same as the sink MEP of P2P LSP. 674 o The transmission of the OAM packet: P2MP LSP inherently supports 675 to forward the OAM packet from source MEP to all sink MEPs in 676 Data Plane. Since each sink MEP runs the OAM function 677 independently from each other,the CC and pro-active CV function 678 in P2MP LSP can be considered a group of OAM functions 679 independently and simultaneously running between the source MEP 680 and each sink MEP. In this respect, there is no essential 681 difference between P2MP LSP and the P2P LSP. 683 In summary, the definition and implementation of the CC and pro- 684 active CV in [I-D.ietf-mpls-tp-cc-cv-rdi] can be applied directly on 685 the P2MP LSP. 687 3.2. Alarm Reporting and Lock Reporting 689 The MPLS-TP Alarm Indication Signal (AIS) message is generated in 690 response to detecting defects in the server layer. 692 The MPLS-TP Locked Report (LKR) message is generated when a server 693 layer entity has been administratively locked to communicate that 694 condition to inform the client layer entities. 696 These two kinds of OAM messages are immediately sent to the client 697 MEPs by inserting them into the affected paths in the direction 698 opposite to the detecting MEP's peer server MEP(s) after they are 699 once generated. Their primary purpose is to suppress alarms in the 700 MPLS-TP layer network above the level at which the defect occurs. 701 The AIS message MAY be used to trigger recovery mechanisms. 703 These two OAM functions are all inter-layer functions. For P2MP LSP 704 scenario, there are two kinds of situations: 706 o P2MP LSP as a client layer: The server layer which carries it is 707 Section layer, or P2MP/P2P LSP SPME sub-layer. These two server 708 layers have exactly the same treatment to the messages. Next, 709 Section layer is introduced as an example. Section monitoring is 710 running between two directly connected nodes, intention to detect 711 bidirectional defects or administrative locking between them. 712 When a node has detected above events, AIS or LKR messages will 713 be immediately generated in the node and inserted into P2MP LSP 714 client layer. Because the P2MP LSP is unidirectional, these two 715 kinds of OAM messages are also unidirectional. They are 716 forwarded along the direction of the P2MP LSP to notify the 717 defect or administrative locking to all downstream sink MEPs of 718 the node. These messages can suppress alarms in the downstream 719 sink MEPs. The AIS message MAY be used to trigger recovery 720 mechanisms. 722 o P2MP LSP as a server layer: The client layer carried above it can 723 be PW, LSP, IP, etc layer. In this case, the sink MEPs of the 724 P2MP LSP are the intermediate point of the above client layer. 725 The defect or administrative locking of the unidirectional P2MP 726 LSP detected in the sink MEPs will cause the generation of AIS or 727 LKR messages and inserted them into the client layer. These 728 messages are forwarded along the direction of the P2MP LSP to 729 notify the defect or administrative locking to the end MEP of the 730 client layer. These messages can suppress alarms in the end MEP 731 of the client layer. The AIS message MAY be used to trigger 732 recovery mechanisms. 734 The above contents analysis the AIS and LKR implementation in P2MP 735 LSP. In general, the current AIS and LKR 736 mechanism([I-D.ietf-mpls-tp-fault]) can apply to P2MP LSP without 737 problem. 739 3.3. On-demand Connectivity Verification and Route Tracing 741 On-demand CV(Connectivity Verification) enables an End Point to 742 determine whether or not it is connected to specific End Point(s) by 743 means of the expected PW, LSP or Section, or is connected to specific 744 Intermediate Point(s) by means of the expected PW, LSP. 746 On-demand Route Tracing enables an End Point to discover the 747 Intermediate (if any) and End Point(s) along a PW, LSP or Section, 748 and more generally to trace the route of a PW, LSP or Section. The 749 information collected MUST include identifiers related to the nodes 750 and interfaces composing that route. 752 According to the OAM analysis, they can all be fully supported by 753 Extending LSP Ping. 755 Currently, [I-D.nitinb-mpls-tp-lsp-ping-extensions] has already given 756 the definitions and descriptions of how LSP Ping supports the above 757 two on-demand OAM functions. 759 The process of these two OAM functions is basically the same, the 760 echo request message is generated in source MEP, forwarded to the 761 destination sink MEPs or MIPs. They return echo response with result 762 after some processes. So, these two OAM functions all need return 763 path. Because P2MP LSP is a unidirectional LSP without in band 764 return path by itself, the return path is a key issue of these two 765 OAM functions. The analysis about return path discussed in section 766 2.2 is applicable here. 768 On-demand CV function send OAM messages from source MEP to any MIPs 769 or sink MEPs by using P2MP Node Indentifier TLV and proper TTL value. 770 These OAM packets carry the TLVs(including source address TLV, MEP/ 771 MIP id TLV, etc) for connectivity verification. The destination 772 nodes(MIPs or sink MEPs) use these TLVs for connectivity verification 773 and return response message with result to source MEP. 775 Route Tracing is implemented by using Downstream Detailed Mapping 776 TLV. This TLV can be used for transit, branch or bud node to return 777 multiple Return Codes for different downstream paths. 779 [I-D.ietf-mpls-p2mp-lsp-ping] has defined an extended LSP Ping 780 mechanism for supporting MPLS P2MP scenarios. Whether this mechanism 781 can be directly applied to MPLS-TP P2MP scenarios without problem or 782 some new problems generated to be resolved needs further study. 784 3.4. Diagnostic Tests 786 3.4.1. Throughput Estimation 788 As specified in [I-D.ietf-mpls-tp-oam-framework], throughput 789 estimation is an on-demand out-of-service function, which allows 790 verifying the bandwidth/throughput of an MPLS-TP transport path (LSP 791 or PW) before it is put in-service. Throughput estimation is 792 performed between MEPs and can be performed in one-way or two-way 793 modes. 795 When applied to P2MP transport path, only one-way throughput 796 estimation can be performed in case a return path exists. Also note 797 that there are two options for throughput estimation on P2MP 798 transport path, one is that respective throughput result can be 799 obtained for each ME between the root and each specific leaf, another 800 one is that only one throughput result can be obtained for the MEG 801 between the root and all leaves. Just like throughput estimation in 802 P2P transport path, two simple measurement methods can be used to 803 estimate throughput in P2MP transport path, one is binary search 804 method and another one is to increase sending rate (up to the 805 theoretical maximum) of OAM test packets in fixed step until OAM test 806 packets begin to drop. 808 For the option 1 that respective throughput result can be obtained 809 for each ME, the two measurement methods mentioned above can be used 810 in different way. When the binary search method is used, each 811 independent throughput estimation process will be needed for each ME 812 between the root and each specific leaf, which requires the source 813 MEP to send a single OAM packet which contains sufficient information 814 to identify a target leaf, and therefore is processed only by the 815 target leaf and ignored by the other leaves. When the other method 816 described above is used, only one throughput estimation process will 817 be needed and also the individual throughput result will be obtained 818 for each ME, also note that with this method the precision of 819 measurement result is lower compared with the binary search method. 821 For the option 2 that only one throughput result can be obtained for 822 the MEG, the two measurement methods mentioned above can be used in 823 the same way. When the binary search method is used, like the other 824 method that increase sending rate in fixed step, only one throughput 825 estimation process will be needed for the MEG between the root and 826 all leaves, which requires the source MEP to send a single OAM packet 827 to all leaves and is processed by all leaves at the same time, and 828 packet loss will be judged by emerging packet loss at any leaf. 830 3.4.2. Data Plane Loopback 832 As specified in [I-D.ietf-mpls-tp-oam-framework], data plane loopback 833 is an out-of-service function, which permits all traffic (including 834 user data and OAM except for the OAM used for this function) 835 originated at the ingress of a transport path or inserted by the test 836 equipment to be looped back in the direction of the point of origin 837 by an interface at either an intermediate node or a terminating node. 839 Due to the specific function mechanism of data plane loopback, this 840 function is applicable to co-routed bidirectional path when it's 841 performed at an intermediate node, and applicable to co-routed 842 bidirectional or associated bidirectional path when it's performed at 843 an end node. So with P2MP path, it's only applicable at a leaf node 844 in case an associated bidirectional path exists. Also note that when 845 this function is performed with P2MP path, at any time only one leaf 846 node can be set as loopback mode, otherwise the root can't 847 distinguish from which leaf the received traffic is looped back. 849 3.5. Lock Instruct 851 Lock Instruct function is a command which allows a MEP to instruct 852 its peer MEP(s) to put a MPLS-TP transport path into a locked 853 condition. This function allows single-side and two side provisions, 854 only the former requires a lock instruct message be sent to the peer 855 MEP(s). 857 For a P2MP transport path, there may be no return path to the lock 858 instruct request MEP. So no response message is needed in this case, 859 or can sends a response via a control plane protocol if the control 860 plane exists. Under this situation, the peer MEP(s) should always 861 accept the lock instruction. 863 Currently, there is no standardized mechanism defined in the IETF to 864 support this function. 866 In general, the recommendation is to define a new tool and PDU to 867 support Lock Instruct. Some material useful for this scope can be 868 found in [I-D.boutros-mpls-tp-loopback] and 869 [I-D.dai-mpls-tp-lock-instruct]. 871 3.6. Client Failure Indication 873 The CFI function is used to propagate the information of a client's 874 defect or fault condition through the MPLS-TP network from edge to 875 edge in case the client layer OAM functionality does not provide an 876 alarm notification function. This defect or fault is detected at and 877 end point of a PW or LSP. 879 when used on a P2MP transport path, if this defect is detected by the 880 root node, this CFI message will be sent through this P2MP path to 881 all the leaves, and mapped to the associted ACs; however, if this 882 defect is detected by a leaf node, this condition should also be 883 propagated to the root node, so this requires a P2P return path from 884 this leaf node to the root node. 886 Static PW status([I-D.ietf-pwe3-static-pw-status]) can be used to 887 perform this function on a PW . However, the peer node shoud 888 identify it's a fault on the AC or on the PW. There is no mechanism 889 defined in IETF to support this functionality for P2MP LSP. 891 So, It needs to define a new tool and PDU to support this 892 functionality for CFI function in MPLS-TP P2MP scenarios. Some 893 material useful for this scope can be found in [I-D.he-mpls-tp-csf] 894 and [I-D.ietf-pwe3-static-pw-status]. 896 3.7. Packet Loss Measurement 898 LM(Loss Measurement) is an OAM toolset which provides a function to 899 enable the quantification of packet loss ratio over a PW, LSP or 900 Section. 902 The Implementation of LM function in P2MP LSP is similar to which in 903 P2P LSP. The source MEP send LM query messages periodically to all 904 sink MEPs, every sink MEP uses a group of related counter values to 905 calculate its own packet loss ratio. So, the LM mechanism defined 906 and described in [I-D.frost-mpls-tp-loss-delay] can be directly 907 applied to MPLS-TP P2MP LSP. 909 The existed problems of LM function in P2P LSP such as message loss 910 and packet misorder conditions and congestion also exist and are more 911 serious in P2MP LSP. These questions all need a unified solution 912 with P2P LSP. 914 For P2MP LSP, there is a specific requirement to support LM function 915 in designated egress node of a P2MP LSP. This requirement can be 916 implemented by setting proper P2MP Node Identifier TLV. 918 3.8. Packet Delay Measurement 920 DM(Delay Measurement) is an OAM toolset which provides a function to 921 enable the quantification of the one-way, and if appropriate, the 922 two-way, delay of a PW, LSP or Section. 924 Unidirectional P2MP LSP can only implement one-way DM function. The 925 mechanism is similar to which in P2P LSP. The source MEP send DM 926 query messages with timestamp of sending time to all sink MEPs, every 927 sink MEP can use the timestamp and the receiving time to calculate 928 its own one-way delay. One-way DM function requires that the clocks 929 of source MEP and all sink MEPs be synchronized. So, the on-way DM 930 mechanism defined and described in [I-D.frost-mpls-tp-loss-delay] can 931 be directly applied to MPLS-TP P2MP LSP. 933 Like LM function, there is a specific requirement to support DM 934 function in designated egress node of a P2MP LSP. This requirement 935 can be implemented by setting proper P2MP Node Identifier TLV. 937 4. P2MP PW analysis 939 To be added in a later version of this document. 941 5. IANA Considerations 943 To be added in a later version of this document. 945 6. Security Considerations 947 To be added in a later version of this document. 949 7. Acknowledgements 951 To be added in a later version of this document. 953 8. References 955 8.1. Normative References 957 [I-D.boutros-mpls-tp-loopback] 958 Boutros, S., Sivabalan, S., Swallow, G., Ward, D., Bryant, 959 S., Pignataro, C., Aggarwal, R., Bitar, N., Vigoureux, M., 960 Busi, I., Levrau, L., and L. Ciavaglia, "Operating MPLS 961 Transport Profile LSP in Loopback Mode", 962 draft-boutros-mpls-tp-loopback-03 (work in progress), 963 March 2010. 965 [I-D.dai-mpls-tp-lock-instruct] 966 Dai, X., Bo, W., and J. Yang, "MPLS-TP Lock Instruction", 967 draft-dai-mpls-tp-lock-instruct-00 (work in progress), 968 October 2009. 970 [I-D.farrel-mpls-tp-mip-mep-map] 971 Farrel, A. and H. Endo, "Handling MPLS-TP OAM Packets 972 Targeted at Internal MIPs", 973 draft-farrel-mpls-tp-mip-mep-map-02 (work in progress), 974 July 2010. 976 [I-D.frost-mpls-tp-loss-delay] 977 Frost, D. and S. Bryant, "Packet Loss and Delay 978 Measurement for the MPLS Transport Profile", 979 draft-frost-mpls-tp-loss-delay-02 (work in progress), 980 June 2010. 982 [I-D.he-mpls-tp-csf] 983 Jia, H., Li, H., and E. Bellagamba, "Indication of Client 984 Failure in MPLS-TP", draft-he-mpls-tp-csf-02 (work in 985 progress), July 2010. 987 [I-D.ietf-mpls-ldp-p2mp] 988 Minei, I., Kompella, K., Wijnands, I., and B. Thomas, 989 "Label Distribution Protocol Extensions for Point-to- 990 Multipoint and Multipoint-to-Multipoint Label Switched 991 Paths", draft-ietf-mpls-ldp-p2mp-10 (work in progress), 992 July 2010. 994 [I-D.ietf-mpls-p2mp-lsp-ping] 995 Yasukawa, S., Farrel, A., Ali, Z., Swallow, G., Nadeau, 996 T., and S. Saxena, "Detecting Data Plane Failures in 997 Point-to-Multipoint Multiprotocol Label Switching (MPLS) - 998 Extensions to LSP Ping", draft-ietf-mpls-p2mp-lsp-ping-10 999 (work in progress), March 2010. 1001 [I-D.ietf-mpls-tp-cc-cv-rdi] 1002 Allan, D., Drake, J., Swallow, G., Boutros, S., Sivabalan, 1003 S., and D. Ward, "Proactive Connection Verification, 1004 Continuity Check and Remote Defect indication for MPLS 1005 Transport Profile", draft-ietf-mpls-tp-cc-cv-rdi-01 (work 1006 in progress), July 2010. 1008 [I-D.ietf-mpls-tp-fault] 1009 Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., 1010 Ward, D., Bryant, S., and S. Sivabalan, "MPLS Fault 1011 Management OAM", draft-ietf-mpls-tp-fault-02 (work in 1012 progress), July 2010. 1014 [I-D.ietf-mpls-tp-lsp-ping-bfd-procedures] 1015 Bahadur, N., Aggarwal, R., Ward, D., Nadeau, T., Sprecher, 1016 N., and Y. Weingarten, "LSP-Ping and BFD encapsulation 1017 over ACH", draft-ietf-mpls-tp-lsp-ping-bfd-procedures-00 1018 (work in progress), March 2010. 1020 [I-D.ietf-mpls-tp-oam-requirements] 1021 Vigoureux, M. and D. Ward, "Requirements for OAM in MPLS 1022 Transport Networks", 1023 draft-ietf-mpls-tp-oam-requirements-06 (work in progress), 1024 March 2010. 1026 [I-D.ietf-pwe3-static-pw-status] 1027 Martini, L., Swallow, G., and M. Bocci, "Pseudowire Status 1028 for Static Pseudowires", 1029 draft-ietf-pwe3-static-pw-status-00 (work in progress), 1030 February 2010. 1032 [I-D.nitinb-mpls-tp-lsp-ping-extensions] 1033 Bahadur, N., Aggarwal, R., Boutros, S., and E. Gray, "LSP- 1034 Ping extensions for MPLS-TP", 1035 draft-nitinb-mpls-tp-lsp-ping-extensions-01 (work in 1036 progress), February 2010. 1038 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1039 Requirement Levels", BCP 14, RFC 2119, March 1997. 1041 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1042 "Extensions to Resource Reservation Protocol - Traffic 1043 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1044 Switched Paths (LSPs)", RFC 4875, May 2007. 1046 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 1047 Associated Channel", RFC 5586, June 2009. 1049 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 1050 and S. Ueno, "Requirements of an MPLS Transport Profile", 1051 RFC 5654, September 2009. 1053 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 1054 Operations, Administration, and Maintenance (OAM) in MPLS 1055 Transport Networks", RFC 5860, May 2010. 1057 8.2. Informative References 1059 [I-D.ietf-mpls-tp-oam-analysis] 1060 Sprecher, N., Bellagamba, E., and Y. Weingarten, "MPLS-TP 1061 OAM Analysis", draft-ietf-mpls-tp-oam-analysis-02 (work in 1062 progress), July 2010. 1064 [I-D.ietf-mpls-tp-oam-framework] 1065 Allan, D., Busi, I., Niven-Jenkins, B., Fulignoli, A., 1066 Hernandez-Valencia, E., Levrau, L., Mohan, D., Sestito, 1067 V., Sprecher, N., Helvoort, H., Vigoureux, M., Weingarten, 1068 Y., and R. Winter, "MPLS-TP OAM Framework", 1069 draft-ietf-mpls-tp-oam-framework-07 (work in progress), 1070 July 2010. 1072 [I-D.koike-ietf-mpls-tp-oam-maintenance-points] 1073 Paul, M. and Y. Koike, "MPLS-TP OAM Maintenance Points", 1074 draft-koike-ietf-mpls-tp-oam-maintenance-points-01 (work 1075 in progress), March 2010. 1077 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 1078 Multipoint Traffic-Engineered MPLS Label Switched Paths 1079 (LSPs)", RFC 4461, April 2006. 1081 [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, 1082 "Operations and Management (OAM) Requirements for Point- 1083 to-Multipoint MPLS Networks", RFC 4687, September 2006. 1085 Authors' Addresses 1087 Liang Xia 1088 ZTE Corporation 1090 Email: xia.liang2@zte.com.cn 1092 Min Xiao 1093 ZTE Corporation 1095 Email: xiao.min2@zte.com.cn 1097 XueHui Dai 1098 ZTE Corporation 1100 Email: dai.xuehui@zte.com.cn 1102 Jian Yang 1103 ZTE Corporation 1105 Email: yang_jian@zte.com.cn