idnits 2.17.1 draft-ietf-mpls-tp-p2mp-framework-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 17, 2014) is 3744 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-hmk-mpls-tp-p2mp-oam-framework-03 == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-p2mp-pw-requirements-06 -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group D. Frost 3 Internet-Draft Blue Sun 4 Intended status: Informational S. Bryant 5 Expires: July 21, 2014 Cisco Systems 6 M. Bocci 7 Alcatel-Lucent 8 L. Berger 9 LabN Consulting 10 January 17, 2014 12 A Framework for Point-to-Multipoint MPLS in Transport Networks 13 draft-ietf-mpls-tp-p2mp-framework-06 15 Abstract 17 The Multiprotocol Label Switching Transport Profile is the common set 18 of MPLS protocol functions defined to enable the construction and 19 operation of packet transport networks. The MPLS-TP supports both 20 point-to-point and point-to-multipoint transport paths. This 21 document defines the elements and functions of the MPLS-TP 22 architecture applicable specifically to supporting point-to- 23 multipoint transport paths. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 21, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2.1. Additional Definitions and Terminology . . . . . . . 3 63 1.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 64 2. MPLS-TP P2MP Requirements . . . . . . . . . . . . . . . . . . 4 65 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. MPLS-TP Encapsulation and Forwarding . . . . . . . . . . 6 67 4. Operations, Administration and Maintenance . . . . . . . . . 6 68 5. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5.1. P2MP LSP Control Plane . . . . . . . . . . . . . . . . . 7 70 5.2. P2MP PW Control Plane . . . . . . . . . . . . . . . . . . 8 71 6. Survivability . . . . . . . . . . . . . . . . . . . . . . . . 8 72 7. Network Management . . . . . . . . . . . . . . . . . . . . . 8 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 10.2. Informative References . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the 82 common set of MPLS protocol functions defined to meet the 83 requirements specified in [RFC5654]. The MPLS-TP Framework [RFC5921] 84 provides an overall introduction to the MPLS-TP and defines the 85 general architecture of the Transport Profile, as well as those 86 aspects specific to point-to-point transport paths. The purpose of 87 this document is to define the elements and functions of the MPLS-TP 88 architecture applicable specifically to supporting point-to- 89 multipoint transport paths. 91 1.1. Scope 93 This document defines the elements and functions of the MPLS-TP 94 architecture related to supporting point-to-multipoint transport 95 paths. The reader is referred to [RFC5921] for those aspects of the 96 MPLS-TP architecture that are generic, or concerned specifically with 97 point-to-point transport paths. 99 1.2. Terminology 101 Term Definition 102 ------- --------------------------------------------------- 103 CE Customer Edge 104 LSP Label Switched Path 105 LSR Label Switching Router 106 MEG Maintenance Entity Group 107 MEP Maintenance Entity Group End Point 108 MIP Maintenance Entity Group Intermediate Point 109 MPLS-TE MPLS Traffic Engineering 110 MPLS-TP MPLS Transport Profile 111 OAM Operations, Administration, and Maintenance 112 OTN Optical Transport Network 113 P2MP Point-to-multipoint 114 PW Pseudowire 115 RSVP-TE Resource Reservation Protocol - Traffic Engineering 116 SDH Synchronous Digital Hierarchy 117 tLDP Targeted LDP 119 1.2.1. Additional Definitions and Terminology 121 Detailed definitions and additional terminology may be found in 122 [RFC5921] and [RFC5654]. 124 1.3. Applicability 126 The point-to-multipoint connectivity provided by an MPLS-TP network 127 is based on the point-to-multipoint connectivity provided by MPLS 128 networks. Traffic Engineered P2MP LSP support is discussed in 129 [RFC4875] and [RFC5332], and P2MP PW support is being developed based 130 on [I-D.ietf-pwe3-p2mp-pw-requirements] and 131 [I-D.ietf-l2vpn-vpms-frmwk-requirements]. MPLS-TP point-to- 132 multipoint connectivity is analogous to that provided by traditional 133 transport technologies such as Optical Transport Network point-to- 134 multipoint [G.798] and drop-and-continue [G.780], and thus supports 135 the same class of traditional applications, e.g., video distribution. 137 The scope of this document is limited to point-to-multipoint 138 functions and it does not discuss multipoint-to-multipoint support. 140 2. MPLS-TP P2MP Requirements 142 The requirements for MPLS-TP are specified in [RFC5654], [RFC5860], 143 and [RFC5951]. This section provides a brief summary of point-to- 144 multipoint transport requirements as set out in those documents; the 145 reader is referred to the documents themselves for the definitive and 146 complete list of requirements. This summary does not include the 147 [RFC2119] conformance language used in original documents as this 148 document is not authoritative. 150 From [RFC5654]: 152 o MPLS-TP must support traffic-engineered point-to-multipoint 153 transport paths. 155 o MPLS-TP must support unidirectional point-to-multipoint transport 156 paths. 158 o MPLS-TP must be capable of using P2MP server (sub)layer 159 capabilities as well as P2P server (sub)layer capabilities when 160 supporting P2MP MPLS-TP transport paths. 162 o The MPLS-TP control plane must support establishing all the 163 connectivity patterns defined for the MPLS-TP data plane (i.e., 164 unidirectional P2P, associated bidirectional P2P, co-routed 165 bidirectional P2P, unidirectional P2MP) including configuration of 166 protection functions and any associated maintenance functions. 168 o Recovery techniques used for P2P and P2MP should be identical to 169 simplify implementation and operation. 171 o Unidirectional 1+1 and 1:n protection for P2MP connectivity must 172 be supported. 174 o MPLS-TP recovery in a ring must protect unidirectional P2MP 175 transport paths. 177 From [RFC5860]: 179 o The protocol solution(s) developed to perform the following OAM 180 functions must also apply to point-to-point associated 181 bidirectional LSPs, point-to-point unidirectional LSPs, and point- 182 to-multipoint LSPs: 184 * Continuity Check 186 * Connectivity Verification, proactive 187 * Lock Instruct 189 * Lock Reporting 191 * Alarm Reporting 193 * Client Failure Indication 195 * Packet Loss Measurement 197 * Packet Delay Measurement 199 o The protocol solution(s) developed to perform the following OAM 200 functions may also apply to point-to-point associated 201 bidirectional LSPs, point-to-point unidirectional LSPs, and point- 202 to-multipoint LSPs: 204 * Connectivity Verification, on-demand 206 * Route Tracing 208 * Diagnostic Tests 210 * Remote Defect Indication 212 From [RFC5951]: 214 o For unidirectional (P2P and point-to-multipoint (P2MP)) 215 connection, proactive measurement of packet loss and loss ratio is 216 required. 218 o For a unidirectional (P2P and P2MP) connection, on-demand 219 measurement of delay measurement is required. 221 3. Architecture 223 The overall architecture of the MPLS-TP is defined in [RFC5921]. The 224 architecture for point-to-multipoint MPLS-TP comprises the following 225 additional elements and functions: 227 o Unidirectional point-to-multipoint LSPs 229 o Unidirectional point-to-multipoint PWs 231 o Optional point-to-multipoint LSP and PW control planes 233 o Survivability, network management, and Operations, Administration 234 and Maintenance functions for point-to-multipoint PWs and LSPs 236 The following subsections summarise the encapsulation and forwarding 237 of point-to-multipoint traffic within an MPLS-TP network, and the 238 encapsulation options for delivery of traffic to and from MPLS-TP CE 239 devices when the network is providing a packet transport service. 241 3.1. MPLS-TP Encapsulation and Forwarding 243 Packet encapsulation and forwarding for MPLS-TP point-to-multipoint 244 LSPs is identical to that for MPLS-TE point-to-multipoint LSPs. 245 MPLS-TE point-to-multipoint LSPs were introduced in [RFC4875] and the 246 related data-plane behaviour was further clarified in [RFC5332]. 247 MPLS-TP allows for both upstream-assigned and downstream-assigned 248 labels for use with point-to-multipoint LSPs. 250 Packet encapsulation and forwarding for point-to-multipoint PWs has 251 been discussed within the PWE3 Working Group 252 [I-D.raggarwa-pwe3-p2mp-pw-encaps], but such definition is for 253 further study. 255 4. Operations, Administration and Maintenance 257 The requirements for MPLS-TP OAM are specified in [RFC5860]. The 258 overall OAM architecture for MPLS-TP is defined in [RFC6371], and 259 P2MP OAM design considerations are described in Section 3.7 of that 260 RFC. 262 All the traffic sent over a P2MP transport path, including OAM 263 packets generated by a MEP, is sent (multicast) from the root towards 264 all the leaves, and thus may be processed by all the MIPs and MEPs 265 associated with a P2MP MEG. If an OAM packet is to be processed by 266 only a specific leaf, it requires information to indicate to all 267 other leaves that the packet must be discarded. To address a packet 268 to an intermediate node in the tree, TTL based addressing is used to 269 set the radius and additional information in the OAM payload is used 270 to identify the specific destination. It is worth noting that a MIP 271 and MEP may be instantiated on a single node when it is both a branch 272 and leaf node. 274 P2MP paths are unidirectional; therefore, any return path to an 275 originating MEP for on-demand transactions will be out-of-band. Out 276 of band return paths are discussed in Section 3.8 of [RFC5921]. 278 A more detailed discussion of P2MP OAM considerations can be found in 279 [I-D.hmk-mpls-tp-p2mp-oam-framework]. 281 5. Control Plane 283 The framework for the MPLS-TP control plane is provided in [RFC6373]. 284 This document reviews MPLS-TP control plane requirements as well as 285 provides details on how the MPLS-TP control plane satisfies these 286 requirements. Most of the requirements identified in [RFC6373] apply 287 equally to P2P and P2MP transport paths. The key P2MP specific 288 control plane requirements are: 290 o requirement 6 (P2MP transport paths), 292 o requirement 34 (use P2P sub-layers), 294 o requirement 49 (common recovery solutions for P2P and P2MP), 296 o requirement 59 (1+1 protection), 298 o requirement 62 (1:n protection), 300 o and requirement 65 (1:n shared mesh recovery). 302 [RFC6373] defines the control plane approach used to support MPLS-TP 303 transport paths. It identifies GMPLS as the control plane for MPLS- 304 TP LSPs tLDP as the control plane for PWs. MPLS-TP allows that 305 either, or both, LSPs and PWs to be provisioned statically or via a 306 control plane. As noted in [RFC6373]: 308 The PW and LSP control planes, collectively, must satisfy the MPLS-TP 309 control-plane requirements. As with P2P services, when P2MP client 310 services are provided directly via LSPs, all requirements must be 311 satisfied by the LSP control plane. When client services are 312 provided via PWs, the PW and LSP control planes can operate in 313 combination, and some functions may be satisfied via the PW control 314 plane while others are provided to PWs by the LSP control plane. 315 This is particularly noteworthy for P2MP recovery. 317 5.1. P2MP LSP Control Plane 319 The MPLS-TP control plane for P2MP LSPs uses GMPLS and is based on 320 RSVP-TE for P2MP LSPs as defined in [RFC4875]. A detailed listing of 321 how GMPLS satisfies MPLS-TP control plane requirements is provided in 322 [RFC6373]. 324 [RFC6373]notes that recovery techniques for Traffic Engineered P2MP 325 LSPs are not formally defined, and such that a definition is needed. 326 A formal definition will be based on existing RFCs and may not 327 require any new protocol mechanisms but, nonetheless, should be 328 documented. GMPLS recovery is defined in [RFC4872] and [RFC4873]. 329 Protection of P2MP LSPs is also discussed in [RFC6372] Section 4.7.3. 331 5.2. P2MP PW Control Plane 333 The MPLS-TP control plane for P2MP PWs should be based on the LDP 334 control protocol used for point-to-point PWs [RFC4447], with updates 335 as required for P2MP applications. A detailed specification of the 336 control plane for P2MP PWs is for further study. 338 6. Survivability 340 The overall survivability architecture for MPLS-TP is defined in 341 [RFC6372], and section 4.7.3 in particular describes the application 342 of linear protection to unidirectional P2MP entities using 1+1 and 343 1:1 protection architecture. For 1+1, the approach is for the root 344 of the P2MP tree to bridge the user traffic to both the working and 345 protection entities. Each sink/leaf MPLS-TP node selects the traffic 346 from one entity according to some predetermined criteria. For 1:1, 347 the source/root MPLS-TP node needs to identify the existence of a 348 fault condition impacting delivery to any of the leaves. Fault 349 notification happens from the node identifying the fault to the root 350 node via an out of band path. The root then selects the protection 351 transport path for traffic transfer. More sophisticated 352 survivability approaches such as partial tree protection and 1:n 353 protection are for further study. 355 The IETF has no experience with P2MP PW survivability as yet, and 356 therefore it is proposed that the P2MP PW survivability will 357 initially rely on the LSP survivability. Further work is needed on 358 this subject, particularly if a requirement emerges to provide 359 survivability for P2MP PWs in an MPLS-TP context. 361 7. Network Management 363 An overview of network management considerations for MPLS-TP can be 364 found in Section 3.14 of "Framework for MPLS in Transport Networks" 365 [RFC5921]. The provided description applies equally to P2MP 366 transport paths. 368 The network management architecture and requirements for MPLS-TP are 369 specified in [RFC5951]. They derive from the generic specifications 370 described in ITU-T G.7710/Y.1701 [G.7710] for transport technologies. 371 They also incorporate the OAM requirements for MPLS Networks 372 [RFC4377] and MPLS-TP Networks [RFC5860] and expand on those 373 requirements to cover the modifications necessary for fault, 374 configuration, performance, and security in a transport network. 375 [RFC5951] covers all MPLS-TP connection types, including P2MP. 377 [RFC6639] provides the MIB-based architecture for MPLS-TP. It 378 reviews the interrelationships between different non MPLS-TP specific 379 MIB modules that can be leveraged for MPLS-TP network management, and 380 identifies areas where additional MIB modules are required. While 381 the document does not consider P2MP transport paths, it does provide 382 a foundation for an analysis of areas where MIB module modification 383 and addition may be needed to fully support P2MP transport paths. 384 There has also been work in the MPLS working group on a P2MP specific 385 MIB, [I-D.ietf-mpls-p2mp-te-mib]. 387 8. Security Considerations 389 General security considerations for MPLS-TP are covered in [RFC5921]. 390 Additional security considerations for P2MP LSPs are provided in 391 [RFC4875]. This document introduces no new security considerations 392 beyond those covered in those documents. 394 9. IANA Considerations 396 There are no requests for IANA actions in this document. 398 10. References 400 10.1. Normative References 402 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 403 Extensions in Support of End-to-End Generalized Multi- 404 Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 405 2007. 407 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 408 "GMPLS Segment Recovery", RFC 4873, May 2007. 410 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 411 "Extensions to Resource Reservation Protocol - Traffic 412 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 413 Switched Paths (LSPs)", RFC 4875, May 2007. 415 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 416 Multicast Encapsulations", RFC 5332, August 2008. 418 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 419 and S. Ueno, "Requirements of an MPLS Transport Profile", 420 RFC 5654, September 2009. 422 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 423 Berger, "A Framework for MPLS in Transport Networks", RFC 424 5921, July 2010. 426 10.2. Informative References 428 [G.7710] ITU-T Recommendation G.7710/Y.1701 (07/2007), "Common 429 equipment management function requirements", 2007. 431 [G.780] ITU-T Recommendation G.780//Y.1351 (07/2010), "Terms and 432 definitions for synchronous digital hierarchy (SDH) 433 networks", 2010. 435 [G.798] ITU-T Recommendation G.798 (10/2010), "Characteristics of 436 optical transport network hierarchy equipment functional 437 blocks", 2010. 439 [I-D.hmk-mpls-tp-p2mp-oam-framework] 440 Koike, Y., Hamano, T., and M. Namiki, "Framework for 441 Point-to-Multipoint MPLS-TP OAM", draft-hmk-mpls-tp-p2mp- 442 oam-framework-03 (work in progress), October 2013. 444 [I-D.ietf-l2vpn-vpms-frmwk-requirements] 445 Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D., 446 and L. Jin, "Framework and Requirements for Virtual 447 Private Multicast Service (VPMS)", draft-ietf-l2vpn-vpms- 448 frmwk-requirements-05 (work in progress), October 2012. 450 [I-D.ietf-mpls-p2mp-te-mib] 451 Farrel, A., Yasukawa, S., and T. Nadeau, "Point-to- 452 Multipoint Multiprotocol Label Switching (MPLS) Traffic 453 Engineering (TE) Management Information Base (MIB) 454 module", draft-ietf-mpls-p2mp-te-mib-09 (work in 455 progress), April 2009. 457 [I-D.ietf-pwe3-p2mp-pw-requirements] 458 JOUNAY, F., Kamite, Y., Heron, G., and M. Bocci, 459 "Requirements and Framework for Point-to-Multipoint 460 Pseudowires over MPLS PSNs", draft-ietf-pwe3-p2mp-pw- 461 requirements-06 (work in progress), October 2013. 463 [I-D.raggarwa-pwe3-p2mp-pw-encaps] 464 Aggarwal, R. and F. JOUNAY, "Point-to-Multipoint Pseudo- 465 Wire Encapsulation", draft-raggarwa-pwe3-p2mp-pw-encaps-01 466 (work in progress), March 2010. 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, March 1997. 471 [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. 472 Matsushima, "Operations and Management (OAM) Requirements 473 for Multi-Protocol Label Switched (MPLS) Networks", RFC 474 4377, February 2006. 476 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 477 Heron, "Pseudowire Setup and Maintenance Using the Label 478 Distribution Protocol (LDP)", RFC 4447, April 2006. 480 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 481 Operations, Administration, and Maintenance (OAM) in MPLS 482 Transport Networks", RFC 5860, May 2010. 484 [RFC5951] Lam, K., Mansfield, S., and E. Gray, "Network Management 485 Requirements for MPLS-based Transport Networks", RFC 5951, 486 September 2010. 488 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 489 Maintenance Framework for MPLS-Based Transport Networks", 490 RFC 6371, September 2011. 492 [RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS- 493 TP) Survivability Framework", RFC 6372, September 2011. 495 [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. 496 Gray, "MPLS Transport Profile (MPLS-TP) Control Plane 497 Framework", RFC 6373, September 2011. 499 [RFC6639] King, D. and M. Venkatesan, "Multiprotocol Label Switching 500 Transport Profile (MPLS-TP) MIB-Based Management 501 Overview", RFC 6639, June 2012. 503 Authors' Addresses 505 Dan Frost 506 Blue Sun 508 EMail: frost@mm.st 510 Stewart Bryant 511 Cisco Systems 513 EMail: stbryant@cisco.com 514 Matthew Bocci 515 Alcatel-Lucent 516 Voyager Place, Shoppenhangers Road 517 Maidenhead, Berks SL6 2PJ 518 United Kingdom 520 EMail: matthew.bocci@alcatel-lucent.com 522 Lou Berger 523 LabN Consulting 525 Phone: +1-301-468-9228 526 EMail: lberger@labn.net