idnits 2.17.1 draft-hmk-mpls-tp-p2mp-oam-framework-04.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 10 instances of too long lines in the document, the longest one being 10 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 (January 31, 2014) is 3731 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '11' is mentioned on line 314, but not defined -- No information found for draft-mpls-tp-p2mp-framework - is the name correct? == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-p2mp-pw-requirements-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group K.Arai, Ed. 2 Y.Koike 3 Internet Draft T.Hamano 4 M.Namiki 5 NTT 6 Intended status: Informational 8 Expires: July 30, 2014 January 31, 2014 10 Framework for Point-to-Multipoint MPLS-TP OAM 11 draft-hmk-mpls-tp-p2mp-oam-framework-04.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with 16 the provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on July 30, 2014. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Abstract 53 The MPLS transport profile (MPLS-TP) is being standardized to enable 54 carrier-grade packet transport. 56 This document discusses and specifies the P2MP framework primarily 57 related to OAM and related management in MPLS-TP networks. This 58 document mainly refers to RFC5654 and RFC6371. The main focus is on 59 the details that are not covered or not clarified in relevant RFCs 60 such as RFC5654, RFC5860, RFC5921, RFC5951, RFC6371, and draft-mpls- 61 tp-p2mp-framework. 63 Note: This I-D was made and updated including the discussions in 64 ITU-T SG15, which were described in Liaison Statements such as 65 (https://datatracker.ietf.org/liaison/1235/) 67 This document is a product of a joint Internet Engineering Task 68 Force (IETF) / International Telecommunications Union 69 Telecommunications Standardization Sector (ITU-T) effort to include 70 an MPLS Transport Profile within the IETF MPLS and PWE3 71 architectures to support the capabilities and functionalities of a 72 packet transport network. 74 Table of Contents 76 1. Introduction ................................................ 3 77 2. Conventions used in this document............................ 4 78 2.1. Terminology ............................................ 4 79 2.2. Definitions ............................................ 5 80 3. P2MP OAM and management...................................... 5 81 3.1. General aspects of architecture ......................... 5 82 3.1.1. Return path ........................................ 5 83 3.1.2. M-leaves management scenario in P2MP path........... 6 84 3.1.3. Refinement of existing requirements on P2MP transport 85 path ..................................................... 7 86 3.1.4. Addition and removal of branch tree in P2MP transport 87 path ..................................................... 8 88 3.2. General aspects of P2MP OAM............................. 8 89 3.3. OAM functions for proactive monitoring ................. 11 90 3.3.1. Continuity Check and Connectivity Verification(CC-V)11 91 3.3.2. Remote Defect Indication .......................... 12 92 3.3.3. Alarm Reporting ................................... 12 93 3.3.4. Lock Reporting .................................... 12 94 3.3.5. Packet Loss Measurement ........................... 12 95 3.3.6. Packet Delay Measurement .......................... 12 96 3.3.7. Client Failure Indication ......................... 12 97 3.4. OAM functions for on-demand monitoring ................. 12 98 3.4.1. Connectivity verification ......................... 12 99 3.4.2. Packet loss measurement ........................... 13 100 3.4.3. Diagnostic tests .................................. 13 101 3.4.4. Route Tracing ..................................... 13 102 3.4.5. Packet delay measurement .......................... 13 103 3.5. OAM functions for administration control ............... 13 104 3.5.1. Lock Instruct ..................................... 13 105 4. Layer Models ............................................... 14 106 5. Applicable Scenarios........................................ 15 107 6. Security Considerations..................................... 15 108 7. IANA Considerations ........................................ 15 109 8. References ................................................. 15 110 8.1. Normative References................................... 15 111 8.2. Informative References................................. 15 112 9. Acknowledgments ............................................ 16 114 1. Introduction 116 The demand for P2MP traffic is expected to quickly increase due to 117 the increase in new services such as IP-TV,compressed & uncompressed 118 video distribution, and smart TV. In light of the global trend in 119 improving energy efficiency as well as general network cost 120 reduction, a point-to-multipoint (P2MP) transport function in MPLS- 121 TP could be one of the solutions for providing these services from 122 the perspective of efficient use of network resources. 124 RFC5654[1] defines the following requirements that are specific to 125 P2MP. 127 - Traffic-engineered point-to-multipoint (P2MP) transport 128 paths.(item 6). 129 - Unidirectional point-to-multipoint(P2MP) transport paths (item 8) 130 - Being capable of using P2MP server (sub)layer capabilities when 131 supporting P2MP MPLS-TP transport paths(item 40) 132 - The MPLS-TP control plane MUST support establishing all the 133 connectivity patterns defined for the MPLS-TP data plane (i.e. 134 unidirectional P2MP) including the configuration of protection 135 functions and any associated maintenance functions.(item 50) 136 - Unidirectional 1+1 protection for P2MP connectivity (item 65 C) 137 - Unidirectional 1:n protection for P2MP connectivity(item 67 B) 138 - MPLS-TP recovery in a ring MUST protect unidirectional P2MP 139 transport paths.(item 95) 141 RFC5860 [2] defines MPLS-TP OAM requirements including those for 142 unidirectional P2MP transport paths. With a unidirectional P2MP 143 transport path, two cases are assumed as per Section 3.3 of 144 RFC6371[3]. One is when no return path exists or not used and the 145 other is when an "out-of-band" return path exists and used. 147 In I-D[4], only a summary of various items specific to MPLS-TP P2MP 148 framework. For example, according to the editor's note, this section 149 will contain a summary of P2MP OAM, as described in RFC6371 [3], 150 which defines the overall OAM architecture for MPLS-TP. 152 Therefore, this draft intends to specify details of a P2MP framework 153 that complements P2MP requirements and the framework of existing 154 RFCs, particularly in terms of OAM, management, and recovery. 156 Note: MPLS-TP functions that are applicable specifically to P2MP 157 transport paths are outside the scope of RFC5921. 159 2. Conventions used in this document 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC-2119 [1]. 165 2.1. Terminology 167 EMS Element management system 169 LSP Label Switched Path 170 NE Network Element 172 NMS Network Management System 174 2.2. Definitions 176 None 178 3. P2MP OAM and management 180 3.1. General aspects of architecture 182 3.1.1. Return path 184 The support of P2MP OAM on the data path should be independent of 185 the availability of a return path or the mechanism that supports the 186 return path. Basically, only unidirectional P2MP is supported in 187 MPLS-TP. This means that an "in-band" return path is out of the 188 scope of MPLS-TP requirements. In this section, two cases, with out- 189 band return path and without return path, are considered basic and 190 the requirements that should be met when return paths exist should 191 be independently specified in other document, if needed. 193 P2MP considerations are described in Section 3.7 of RFC6371. The RFC 194 has already described some requirements with out-band return path(s). 195 On the other hand, even if there is no return path, most OAM 196 requirements in RFC5860 can be met by supporting the management 197 interface through which EMS/NMS can retrieve the received OAM 198 packets. 200 The "return path" may be considered to be directed to the entity 201 that originally requested the measurements because this may not be 202 the head end of the P2MP connection. Therefore, the following return 203 path should be distinctly differentiated. 205 RP-N: A return path to the EMS/NMS through the management 206 interface (RP-N) (this case is referred to as that in which no 207 return path exists) 209 RP-HE: A return path to a head end (root) of a P2MP path using any 210 kind of out-of-band path (this case is referred to as that in 211 which an out-of-band return path exists) 213 The interpretation of return path usually corresponds to RP-HE. 214 These two kinds of return paths may be applied at the same time, 215 depending on the situations. 217 3.1.2. M-leaves management scenario in P2MP path 219 Generally, a function to monitor only the subset leaves of a P2MP 220 transport path is required to appropriately monitor the status of 221 P2MP transport paths. The supplemental requirements are as follows. 223 1) M-leaves management, which enables NMS to perform OAM functions 224 at a set of leaves on a P2MP transport path, must be supported. 226 2) M-leaves must be selectable by the operator or administrator 227 using NMS. 229 3) M-leaves management should be independently enabled/disabled in 230 each OAM function. 232 4) In M-leave monitoring, one scenario should be selected to avoid 233 future interoperability problems between related entities (NE, 234 EMS, and NMS). 236 There are four scenarios considered in MPLS-TP networks that consist 237 of NEs, EMS, and NMS. 239 In scenario 1, OAM protocol extension is necessary. OAM packets sent 240 from the source MEP must include a subset of leaf-MEPs. A sink MEP 241 determines if it should be notified of the management process within 242 an NE based on the leaf-IDs included in the OAM packet. However, 243 this is not supported in RFC6371. 245 In scenario 2, OAM packets that are supported in RFC6371 and are 246 targeted at all leaves can be utilized. As a result, no extension is 247 necessary in the P2MP OAM protocol. On the other hand, a subset of 248 M-leave/sink MEPs must be configured at an EMS from an NMS. In 249 addition, a pre-configuration of a subset of M-leave/sink MEPs is 250 needed at related NEs from the EMS. Only the notification-enabled M- 251 leaves/nodes notify the EMS of its monitoring results. 253 In scenario 3, OAM packets that are supported in RFC6371 and are 254 targeted at all leaves can also be utilized. There is no P2MP OAM 255 protocol extension. On the other hand, NMS configuration on M- 256 leaves/sink MEPs is needed. In addition, a subset of M-leave/sink 257 MEPs must be configured at the EMS from the NMS. However, no pre- 258 configuration of a subset of M-leaves/NEs is needed. 260 In scenario 4, OAM packets that are supported in RFC6371 and are 261 targeted at all leaves can also be utilized. There is no P2MP OAM 262 protocol extension. Only NMS configuration on M-leaves/sink MEPs is 263 needed. A configuration of a subset of M-leave/sink MEPs at the EMS 264 from the NMS is not necessary. No pre-configuration of a subset of 265 M-leaves/NEs is needed. 267 Considering some negative impacts such as the efficient use of a 268 data communication network (DCN), insufficient manageability of 269 network element (NE), traffic congestion at EMS/NMS, and heavy load 270 for OAM packet processes at EMS/NMS, scenario 2 is required in 271 MPLS-TP p2mp network. 273 3.1.3. Refinement of existing requirements on P2MP transport path 275 MPLS-TP RFCs are sufficiently mature in terms of the requirements 276 and framework of MPLS-TP P2P. On the other hand, in terms of MPLS-TP 277 P2MP, some parts of MPLS-TP RFCs and Recommendations could be 278 refined and clarified. 280 (R1) CV requirement of RFC5860 282 CV is ambiguously defined in RFC5860 "MPLS-TP OAM requirement". 283 According to this definition of RFC5860, it seems to be source-MEP 284 oriented and not correct in P2MP. 286 Current text: The MPLS-TP OAM toolset MUST provide a function to 287 enable an End Point to determine whether or not it is connected to 288 specific End Point(s) by means of the expected PW, LSP, or Section. 290 In unidirectional P2MP, the source MEP cannot determine whether or 291 not it is connected to specific End Point(s). Therefore, in P2MP, 292 the definition of connectivity verification should be corrected in 293 P2MP framework draft and OAM Recommendation as follows. 295 Proposed text: The MPLS-TP OAM toolset MUST provide a function to 296 enable a sink End Point to determine whether or not it is connected 297 to a specific source End Point by means of the expected PW or LSP. 299 (R2) CC Requirement of RFC6371 301 According to RFC6371, it is assumed that CC means that CC OAM packet 302 does not include either a source MEP or destination MEP. Only 303 unidirectional P2MP is supported in MPLS-TP, so the continuity of 304 the CC OAM packets are received by sink MEPs, and a sink MEP should 305 notify the equipment fault management process of the detected defect. 306 However, the following current text doesn't correctly describe the 307 unidirectional feature that is specific to P2MP transport path. 308 Therefore, the requirement should be modified. 310 Current text in RFC: Proactive Continuity Check functions, as 311 required in Section 2.2.2 of RFC 5860 [11], are used to detect a 312 loss of continuity (LOC) defect between two MEPs in an MEG. 313 Proactive Connectivity Verification functions, as required in 314 Section 2.2.3 of RFC 5860 [11], are used to detect an unexpected 315 connectivity defect between two MEGs (e.g., mismerging or 316 misconnection), as well as unexpected connectivity within the MEG 317 with an unexpected MEP. 319 Proposed text: Proactive Continuity Check functions, as required in 320 Section 2.2.2 of RFC5860, are used to detect a loss of continuity 321 (LOC) defect from the source MEP to sink MEP(s). Proactive 322 Connectivity Verification functions, as required in Section 2.2.3 of 323 RFC5860, are used to detect an unexpected connectivity defect from 324 the source MEP to sink MEP(s) (e.g., mismerging or misconnection), 325 as well as unexpected connectivity within MEG with an unexpected 326 source MEP. 328 (R3) Optional requirements on CC-V OAM packets 330 In a P2MP transport path, it is highly desirable that in order to 331 save OAM bandwidth consumption, CV, when used, be linked with CC 332 into CC-V OAM packets. 334 3.1.4. Addition and removal of branch tree in P2MP transport path 336 When additional branches, in other words, additional destination NEs 337 (leaves) need to be added to an existing transport path after a 338 connection service is provided via the P2MP path, an operator must 339 be capable of adding a new branch tree to the P2MP transport path 340 flexibly from any point on the path without service interruption. 341 The reason is that merging and crossover of the P2MP LSP branch tree 342 must be rejected because it is not efficient in terms of network 343 resources. As a result, the following requirement must be supported 344 in the MPLS-TP P2MP transport path. 346 3.2. General aspects of P2MP OAM 348 P2MP transport paths are unidirectional; therefore, there is 349 generally no in-band return path as in the MPLS-TP transport path 350 per se. However, there are basically two approaches for handling OAM 351 requirements in P2MP MPLS-TP. 353 The first one is used to report the results of the 354 monitoring/measurement of OAM packets from the OAM target node to 355 the EMS/NMS when the NMS usually instantiates OAM functions and 356 requires the results of OAM monitoring functions. This approach is 357 called RP-N. The second approach is the return path to a root 358 (source MEP) of a P2MP path using different methods such as a 359 unidirectional p2p transport paths, and other technology-layers, 360 such as IP, Ethernet, and OTN, when an NE within which a root MEP 361 resides instantiates OAM functions or receive results of OAM 362 monitoring functions. This approach is called as RP-HE. The 363 following requirements are supported in terms of network elements 364 when considering RP-N. 366 1. OAM functions of a MEG of a P2MP transport path should be 367 configurable using the EMS/NMS. 369 2. Source nodes at which the source MEP reside and OAM packets are 370 generated should receive OAM related information such as 371 enabling/disabling OAM functions and setting/changing OAM 372 attributes from the EMS/NMS on a P2MP transport path. 374 3. Sink nodes at which targeting MIPs or MEPs reside and OAM packets 375 are parsed should report OAM related information such as OAM 376 monitoring results and consequent OAM actions to the EMS/NMS. 378 4. Each OAM function of a P2MP transport path should be able to be 379 independently configured using the EMS/NMS based on the 380 classification of OAM functional requirements in RFC5860. 382 5. An on-demand OAM function must be able to perform an OAM function 383 for only a specific target MIP or MEP as well as all MEPs in a 384 P2MP transport path, as specified in Section 3.7 of RFC6371[3]. 386 6. To manage M leaves(i.e., subset of all leaves) in an on-demand OAM 387 function from the EMS/NMS, a unified mechanism must be provided. 389 Note: Currently, sending an OAM packet that is targeted at a 390 subset of M leaves by using an aggregating mechanism such as an 391 OAM packet including several MIP or MEP identifiers is out of the 392 scope of RFC6371[3] as described in Section 3.7 of that document. 394 7. Mismatches of configuration information between a root MEP and any 395 leaf-MEP, at which proactive or on-demand monitoring is enabled, 396 should be detected as a configuration mismatch alarm and be 397 reported to the EMS/NMS by parsing received OAM packets, 398 particularly when a static setting is applied. 400 Generally when each OAM function is enabled, as described in Section 401 5.1 of RFC6371[3], the source MEP function should be enabled prior 402 to the corresponding sink MEPs' function. 404 Regarding configuration considerations, the following are additional 405 requirements for unidirectional P2MP transport path, particularly 406 when RP-HE does not exist. 408 8. The configuration of each OAM function between the source MEP and 409 sink MEP(s) in an MEG of a transport path should be able to be 410 synchronized using the NMS, when a new P2MP transport path is set. 412 9. OAM functions of a newly added/deleted branch transport path from 413 any point of an existing transport path must be able to be 414 configured and enabled/disabled on a newly integrated/combined 415 P2MP transport path without affecting client traffic to existing 416 end points of the P2MP transport path other than the added/removed 417 branch transport path. 419 10. The configuration of newly added/removed specific sink 420 MEP(s)to the existing source MEP in the MEG in proactive 421 monitoring should be able to be synchronized with that of the 422 source MEP by using the NMS. 424 11. The EMS/NMS should provide a tool for manually configuring 425 consistent values of each piece of configuration information to a 426 root MEP and all the related leaf MEPs in a MEG of a P2MP 427 transport path for both pro-active and on-demand OAM functions. 429 12. Mismatches of configuration information between a leaf MEP and 430 any other leaf MEP(s) or a root MEP and leaf MEP(s), at which 431 proactive monitoring will be enabled, should be able to be 432 detected through the configuration management process of the 433 EMS/NMS as a configuration mismatch alarm or notification without 434 receiving OAM packets from a source MEP(before OAM functions are 435 enabled). 437 Note: This requirement is not necessary if the EMS/NMS provides a 438 tool to manually configure a consistent value of each piece of 439 configuration information to a root MEP. 441 13. The enabling or disabling of proactive OAM functions and 442 configuration mismatch alarms of the OAM functions must be 443 independently configurable at each leaf-MEP as well as on all the 444 leaf MEPs on a P2MP transport path, considering maintenances or a 445 case in which one or more leaf MEPs is newly added or removed 446 later. 448 14. Mismatches of configuration information between a leaf MEP and 449 any other leaf MEP(s) or a root MEP and leaf MEP(s), at which on- 450 demand OAM monitoring is enabled, must be detected as a 451 configuration management process before conducting OAM functions. 453 3.3. OAM functions for proactive monitoring 455 The proactive OAM functions are used to detect a fault/defect or to 456 automatically reports a change in the status of a transport path. 458 3.3.1. Continuity Check and Connectivity Verification(CC-V) 460 The continuity Check function enables one or more leaf MEPs on a 461 unidirectional P2MP transport path to monitor the continuity of OAM 462 packets from root MEP and detect one or more loss of continuity(LOC) 463 defects between the root MEP and leaf MEPs. 465 The connectivity verification function enables one or more leaf MEPs 466 on a P2MP transport path to monitor the connectivity of OAM packets 467 from a specific root MEP and detect an unexpected connectivity 468 defect between two MEGs(two P2MP transport paths) 470 As described in Sections 2.2.2 and 2.2.3 of RFC5860[2], CC-V MUST be 471 supported even when RP-HE does not exist. 473 As described in RFC6371[3], CC-V OAM packets are used for a P2MP 474 transport path. Defect detection mechanisms in P2MP transport paths 475 are the same as those of the P2MP transport path specified in 476 section 5.1.1 of RFC6371 [3]. That is, loss of continuity(LoC) 477 defect, mis-connectivity defect, period mis-configuration defect and 478 unexpected encapsulation defect. Entry and exit criteria are also 479 the same as those of the P2MP transport paths in RFC6371 [3]. 480 However, in a P2MP transport path, all the leaf MEPs that detect a 481 defect must be indentified and differentiated from a normal leaf 482 MEP(s), which does not detect a defect. 484 Configuration is specified in Section 5.1.3 of RFC6371[3]. The 485 following configuration information must be configured: MEG-ID, MEP- 486 ID, list of the other MEPs in the MEG that are different between the 487 root MEP and leaf MEP, PHB for E-LSP and transmission rate. 489 Consequent actions of a unidirectional P2MP transport path are also 490 covered in Section 5.1.2 of RFC6371 [3]. Operators should be able to 491 enable/disable each consequent action. 493 All MEPs inside a MEG need to be configured and retain the 494 information when a proactive OAM function is enabled, as described 495 in Section 5.1.3 of RFC6371[3]. If there is no RP-HE, it is premised 496 that the EMS/NMS exists. Therefore, the above parameters are 497 statically configured. 499 3.3.2. Remote Defect Indication 501 This OAM function is not available on a P2MP transport path when 502 return paths do not exist. This OAM function can be implemented only 503 in RP-HE. However, the return path is out of the scope of MPLS-TP 504 requirements. 506 3.3.3. Alarm Reporting 508 FFS 510 3.3.4. Lock Reporting 512 For further study(FFS) 514 3.3.5. Packet Loss Measurement 516 FFS 518 3.3.6. Packet Delay Measurement 520 FFS 522 3.3.7. Client Failure Indication 524 FFS 526 3.4. OAM functions for on-demand monitoring 528 3.4.1. Connectivity verification 530 The connectivity verification function enables one or more leaf MEPs 531 on a P2MP transport path to monitor the connectivity of OAM packets 532 from a specific root MEP and detect an unexpected connectivity 533 defect between two MEGs (two P2MP transport paths) 534 1. Connectivity verification functions MUST be supported when return 535 paths in a unidirectional P2MP transport path do not exist. 537 As described in RFC6371 [3], CC-V OAM packets are used for a P2MP 538 transport path. Defect detection mechanisms in P2MP transport paths 539 are the same as those of the P2MP transport path specified in 540 section 5.1 of RFC6371. That is, loss of continuity defect, mis- 541 connectivity defect, period mis-configuration defect and unexpected 542 encapsulation defect. Entry and exit criteria are also the same as 543 those of the P2MP transport path in RFC6371 [3]. Moreover, 544 consequent actions of a unidirectional P2MP transport path are also 545 covered in Section 5.1.2 of the RFC [3] 547 Regarding configuration consideration, the following additional 548 requirements on a unidirectional P2MP transport path when a return 549 path does not exist. 551 3.4.2. Packet loss measurement 553 FFS 555 3.4.3. Diagnostic tests 557 Diagnostic test functions MUST be supported when a return path in 558 a unidirectional P2MP transport path doesn't exist. 560 Other requirements are ffs. 562 3.4.4. Route Tracing 564 Route tracing function MUST be supported when a return path in a 565 unidirectional P2MP transport path doesn't exist. 567 Other requirements are ffs. 569 3.4.5. Packet delay measurement 571 FFS 573 3.5. OAM functions for administration control 575 3.5.1. Lock Instruct 577 FFS. 579 4. Layer Models 581 Generally, MPLS-TP technology consists of two technical basis: one 582 is LSP and the other is Pseudowire (PW). In PW, two types of multi- 583 segment PW are supported: one is single-segment PW(SS-PW) and multi- 584 segment PW(MS-SW). Considering the combination of those technologies, 585 there are a few types of combinations considered in layering models 586 of MPLS-TP. Fig.1 shows those examples. 588 ------------ ------------ ------------ 589 Channel layer | P2MP SS-PW | | P2MP MS-PW | | P2MP MS-PW | 590 ------------ ------------ ------------ 591 Path layer | P2MP LSP | | P2P LSP | | P2MP LSP | 592 ------------ ------------ ------------ 593 Server layer | P2P any | | P2P any | | P2P any | 594 ------------ ------------ ------------ 595 Model 1 Moldel 2 Model 3 597 Figure 1 : Examples of Layer models in P2MP MPLS-T 599 In principal, server layer is provided by any technologies such as 600 Ethernet, OTN and MPLS-TP in P2P link. On the other hand, channel layer 601 and path layer are provided by PW and LSP and both technologies support 602 P2MP as well as P2P in current MPLS technology. From the perspective, 603 three possible models are described in Fig.1. 605 There are still some discussion on which model should be adopted in 606 MPLS-TP. The key issue is on some ambiguity of the boundary of PW 607 function and LSP function. This OAM framework draft firstly focuses on 608 Model 1, in which P2MP SS-PW is applied in a channel layer and P2MP LSP 609 is applied in a path layer. Model 2 and Model 3 are for further study. 610 Regarding P2MP PW, as shown in [4], P2MP PW survivability has not been 611 discussed yet. P2MP PW requirements are being developed in [5]. 613 5. Applicable Scenarios 615 P2MP MPLS-TP LSP could be applied not only to point to multi-point 616 topology networks, but also to p2mp portions which constructs multi- 617 point to multi-point services. Those requirements are being developed 618 in 619 [6]. OAM functions described in this document can be utilized for 620 meeting those requirements. 622 6. Security Considerations 624 This document does not raise any particular security considerations. 626 7. IANA Considerations 628 There are no IANA actions required by this draft. 630 8. References 632 8.1. Normative References 634 [1] Niven-Jenkins, B., et all, "Requirements of an MPLS Transport 635 Profile", RFC5654, September 2009 637 [2] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in 638 MPLS Transport Networks", RFC5860, May 2010 640 [3] Busi, I., Dave, A. , "Operations, Administration and 641 Maintenance Framework for MPLS-based Transport Networks ", 642 RFC6371, September 2011 644 [4] Frost, Dan.,et all, "A Framework for Point-to-Multipoint MPLS 645 in Transport Networks", draft-mpls-tp-p2mp-framework-06, 646 January 2014 648 8.2. Informative References 650 [5] Bocci, M., Heron, G., and Y. Kamite, "Requirements and 651 Framework for Point-to-Multipoint Pseudowires over MPLS PSNs", 652 draft-ietf-pwe3-p2mp-pw-requirements-06 (work in progress), October 653 2013. 655 [6] Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D., and L. 656 Jin, "Framework and Requirements for Virtual Private Multicast 657 Service (VPMS)", draft-ietf-l2vpn-vpms-frmwk-requirements-05 (work 658 in progress), October 2012 660 9. Acknowledgments 662 The author would like to thank all members (including MPLS-TP 663 steering committee, the Joint Working Team, the MPLS-TP Ad Hoc Group 664 in ITU-T) involved in the definition and specification of MPLS 665 Transport Profile. 667 This document was prepared using 2-Word-v2.0.template.dot. 669 Authors' Addresses 671 Takafumi Hamano 672 NTT 673 hamano.takafumi@lab.ntt.co.jp 675 Masatoshi Namiki 676 NTT 677 namiki.masatoshi@lab.ntt.co.jp 679 Kaoru Arai 680 NTT 681 arai.kaoru@lab.ntt.co.jp 683 Yoshinori Koike 684 NTT 685 Email: koike.yoshinori@lab.ntt.co.jp