idnits 2.17.1 draft-fbb-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 2, 2013) is 4131 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-01 == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-p2mp-pw-requirements-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group D. Frost, Ed. 3 Internet-Draft S. Bryant, Ed. 4 Intended status: Informational Cisco Systems 5 Expires: July 6, 2013 M. Bocci, Ed. 6 Alcatel-Lucent 7 L. Berger, Ed. 8 LabN Consulting 9 January 2, 2013 11 A Framework for Point-to-Multipoint MPLS in Transport Networks 12 draft-fbb-mpls-tp-p2mp-framework-06 14 Abstract 16 The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) 17 is the common set of MPLS protocol functions defined to enable the 18 construction and operation of packet transport networks. The MPLS-TP 19 supports both point-to-point and point-to-multipoint transport paths. 20 This document defines the elements and functions of the MPLS-TP 21 architecture applicable specifically to supporting point-to- 22 multipoint transport paths. 24 This document is a product of a joint Internet Engineering Task Force 25 (IETF) / International Telecommunication Union Telecommunication 26 Standardization Sector (ITU-T) effort to include an MPLS Transport 27 Profile within the IETF MPLS and PWE3 architectures to support the 28 capabilities and functionalities of a packet transport network. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 6, 2013. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.2.1. Additional Definitions and Terminology . . . . . . . . 4 67 1.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 68 2. MPLS Transport Profile Point-to-Multipoint Requirements . . . 4 69 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. MPLS-TP Encapsulation and Forwarding . . . . . . . . . . . 6 71 4. Operations, Administration and Maintenance (OAM) . . . . . . . 6 72 5. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 7 73 5.1. Point-to-Multipoint LSP Control Plane . . . . . . . . . . 7 74 5.2. Point-to-Multipoint PW Control Plane . . . . . . . . . . . 7 75 6. Survivability . . . . . . . . . . . . . . . . . . . . . . . . 8 76 7. Network Management . . . . . . . . . . . . . . . . . . . . . . 8 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) 86 is the common set of MPLS protocol functions defined to meet the 87 requirements specified in [RFC5654]. The MPLS-TP Framework [RFC5921] 88 provides an overall introduction to the MPLS-TP and defines the 89 general architecture of the Transport Profile, as well as those 90 aspects specific to point-to-point transport paths. The purpose of 91 this document is to define the elements and functions of the MPLS-TP 92 architecture applicable specifically to supporting point-to- 93 multipoint transport paths. 95 This document is a product of a joint Internet Engineering Task Force 96 (IETF) / International Telecommunication Union Telecommunication 97 Standardization Sector (ITU-T) effort to include an MPLS Transport 98 Profile within the IETF MPLS and PWE3 architectures to support the 99 capabilities and functionalities of a packet transport network. 101 1.1. Scope 103 This document defines the elements and functions of the MPLS-TP 104 architecture related to supporting point-to-multipoint transport 105 paths. The reader is referred to [RFC5921] for those aspects of the 106 MPLS-TP architecture that are generic, or concerned specifically with 107 point-to-point transport paths. 109 1.2. Terminology 111 Term Definition 112 ------- ------------------------------------------ 113 LSP Label Switched Path 114 MPLS-TP MPLS Transport Profile 115 SDH Synchronous Digital Hierarchy 116 ATM Asynchronous Transfer Mode 117 OTN Optical Transport Network 118 OAM Operations, Administration and Maintenance 119 G-ACh Generic Associated Channel 120 GAL G-ACh Label 121 MEP Maintenance End Point 122 MIP Maintenance Intermediate Point 123 APS Automatic Protection Switching 124 SCC Signaling Communication Channel 125 MCC Management Communication Channel 126 EMF Equipment Management Function 127 FM Fault Management 128 CM Configuration Management 129 PM Performance Monitoring 130 LSR Label Switching Router 131 MPLS-TE MPLS Traffic Engineering 132 P2MP Point-to-multipoint 133 PW Pseudowire 135 1.2.1. Additional Definitions and Terminology 137 Detailed definitions and additional terminology may be found in 138 [RFC5921] and [RFC5654]. 140 1.3. Applicability 142 The point-to-multipoint connectivity provided by an MPLS-TP network 143 is based on the point-to-multipoint connectivity provided by MPLS 144 networks. MPLS TE-LSP support is discussed in [RFC4875] and 145 [RFC5332], and PW support is being developed based on 146 [I-D.ietf-pwe3-p2mp-pw-requirements] and 147 [I-D.ietf-l2vpn-vpms-frmwk-requirements]. MPLS-TP point-to- 148 multipoint connectivity is analogous to that provided by traditional 149 transport technologies such as Optical Transport Network (OTN) point- 150 to-multipoint [ref?] and optical drop-and-continue [ref?], and thus 151 supports the same class of traditional applications. 153 2. MPLS Transport Profile Point-to-Multipoint Requirements 155 The requirements for MPLS-TP are specified in [RFC5654], [RFC5860], 156 and [RFC5951]. This section provides a brief summary of point-to- 157 multipoint transport requirements as set out in those documents; the 158 reader is referred to the documents themselves for the definitive and 159 complete list of requirements. 161 o MPLS-TP must support unidirectional point-to-multipoint (P2MP) 162 transport paths. 164 o MPLS-TP must support traffic-engineered point-to-multipoint 165 transport paths. 167 o MPLS-TP must be capable of using P2MP server (sub)layer 168 capabilities as well as P2P server (sub)layer capabilities when 169 supporting P2MP MPLS-TP transport paths. 171 o The MPLS-TP control plane must support establishing all the 172 connectivity patterns defined for the MPLS-TP data plane (i.e., 173 unidirectional P2P, associated bidirectional P2P, co-routed 174 bidirectional P2P, unidirectional P2MP) including configuration of 175 protection functions and any associated maintenance functions. 177 o Recovery techniques used for P2P and P2MP should be identical to 178 simplify implementation and operation. 180 o Unidirectional 1+1 and 1:n protection for P2MP connectivity must 181 be supported. 183 o MPLS-TP recovery in a ring must protect unidirectional P2MP 184 transport paths. 186 3. Architecture 188 The overall architecture of the MPLS Transport Profile is defined in 189 [RFC5921]. The architecture for point-to-multipoint MPLS-TP 190 comprises the following additional elements and functions: 192 o Unidirectional point-to-multipoint Label Switched Paths (LSPs) 194 o Unidirectional point-to-multipoint pseudowires (PWs) 196 o Optional point-to-multipoint LSP and PW control planes 198 o Survivability, network management, and Operations, Administration 199 and Maintenance (OAM) functions for point-to-multipoint PWs and 200 LSPs 202 The following subsections summarise the encapsulation and forwarding 203 of point-to-multipoint traffic within an MPLS-TP network, and the 204 encapsulation options for delivery of traffic to and from MPLS-TP 205 Customer Edge devices when the network is providing a packet 206 transport service. 208 3.1. MPLS-TP Encapsulation and Forwarding 210 Packet encapsulation and forwarding for MPLS-TP point-to-multipoint 211 LSPs is identical to that for MPLS-TE point-to-multipoint LSPs. 212 MPLS-TE point-to-multipoint LSPs were introduced in [RFC4875] and the 213 related data-plane behaviour was further clarified in [RFC5332]. 214 MPLS-TP allows for both upstream-assigned and downstream-assigned 215 labels for use with point-to-multipoint LSPs. 217 Packet encapsulation and forwarding for point-to-multipoint PWs is 218 currently being defined by the PWE3 Working Group 219 [I-D.raggarwa-pwe3-p2mp-pw-encaps]. 221 4. Operations, Administration and Maintenance (OAM) 223 The overall OAM architecture for MPLS-TP is defined in [RFC6371], and 224 P2MP OAM design considerations are described in Section 3.7 of that 225 RFC. 227 All the traffic sent over a P2MP transport path, including OAM 228 packets generated by a MEP, is sent (multicast) from the root to all 229 the leaves, thus every OAM packet is sent to all leaves, and thus can 230 simultaneously instrument all the MEs in a P2MP MEG. If an OAM 231 packet is to be processed by only one leaf, it requires information 232 to indicate to all other leaves that the packet must be discarded. 233 To address a packet to an intermediate node in the tree, TTL based 234 addressing is used to set the radius and addressing information in 235 the OAM payload is used to identify the specific destination node. 237 P2MP paths are unidirectional; therefore, any return path to an 238 originating MEP for on-demand transactions will be out-of-band. Out 239 of band return paths are discussed in Section 3.8 of [RFC5921]. 241 Packet Loss and Delay Measurement for MPLS Networks [RFC6374] already 242 considers the P2MP case and it is not thought that any change is 243 needed to the MPLS-TP profile of [RFC6374] [RFC6375]. 245 [Editor's note: Additional information / text has been published in 246 [I-D.hmk-mpls-tp-p2mp-oam-framework]. The Editors will coordinate 247 with the draft authors to identify which text should be folded into 248 this document and which should remain in a standalone document.] 250 5. Control Plane 252 The framework for the MPLS-TP control plane is provided in [RFC6373]. 253 This document reviews MPLS-TP control plane requirments as well as 254 provides details on how the MPLS-TP control plane satisfies these 255 requirements. Most of the requirements identified in [RFC6373] apply 256 equally to P2P and P2MP transport paths. The key P2MP specific 257 control plane requirements are identified in requirement 6 (P2MP 258 transport paths), 34 (use P2P sub-layers), 49 (common recovery 259 solutions for P2P and P2MP), 59 (1+1 protection), 62 (1:n 260 protection), and 65 (1:n shared mesh recovery). 262 [RFC6373] defines the control plane approach used to support MPLS-TP 263 transport paths. It identifies Generalized MPLS (GMPLS) as the 264 control plane for MPLS-TP Label Switched Paths (LSPs) and Targeted 265 LDP (T-LDP) as the control plane for pseudowires (PWs). MPLS-TP 266 allows that either, or both, LSPs and PWs to be provisioned 267 statically or via a control plane. As noted in [RFC6373]: 269 The PW and LSP control planes, collectively, must satisfy the MPLS-TP 270 control-plane requirements. As with P2P services, when P2MP client 271 services are provided directly via LSPs, all requirements must be 272 satisfied by the LSP control plane. When client services are 273 provided via PWs, the PW and LSP control planes can operate in 274 combination, and some functions may be satisfied via the PW control 275 plane while others are provided to PWs by the LSP control plane. 276 This is particularly noteworthy for P2MP recovery. 278 5.1. Point-to-Multipoint LSP Control Plane 280 The MPLS-TP control plane for point-to-multipoint LSPs uses GMPLS and 281 is based on Resource Reservation Protocol - Traffic Engineering 282 (RSVP-TE) for point-to-multipoint LSPs as defined in [RFC4875]. A 283 detailed listing of how GMPLS satisfies MPLS-TP control plane 284 requirements is provided in [RFC6373]. 286 Per [RFC6373], the definitions of P2MP, [RFC4875], and GMPLS 287 recovery, [RFC4872] and [RFC4873], do not explicitly cover their 288 interactions. MPLS-TP requires a formal definition of recovery 289 techniques for P2MP LSPs. Such a formal definition will be based on 290 existing RFCs and may not require any new protocol mechanisms but, 291 nonetheless, should be documented. Protection of P2MP LSPs is also 292 discussed in [RFC6372] Section 4.7.3. 294 5.2. Point-to-Multipoint PW Control Plane 296 The MPLS-TP control plane for point-to-multipoint PWs uses the LDP 297 P2MP signaling extensions for PWs defined in [I-D.ietf-pwe3-p2mp-pw]. 299 This definition is limited to single segment PWs and is based on LDP 300 [RFC5036] with upstream-assigned labels [RFC5331]. The document does 301 not address recovery of P2MP PWs. Such recovery can be provided via 302 P2MP LSP recovery as generally discussed in [RFC6372]. 303 Alternatively, PW recovery [RFC6718] can be extended to explicitly 304 support recovery of P2MP PWs. 306 6. Survivability 308 The overall survivability architecture for MPLS-TP is defined in 309 [RFC6372], and section 4.7.3 in particular describes the application 310 of linear protection to unidirectional P2MP entities using 1+1 and 311 1:1 protection architecture. The approach is for the root of the 312 P2MP tree to bridge the user traffic to both the working and 313 protection entities. Each sink/leaf MPLS-TP node selects the traffic 314 from one entity according to some predetermined criteria. Fault 315 notification happens from the node idenifying the fault to the root 316 node and from the leaves to the root via an out of band path. In 317 either case the root then selects the protection transport path for 318 traffic transfer. More sophisticated survivability approaches such 319 as partial tree protection and 1:n protection are for further study. 321 The IETF has no experience with P2MP PW survivability as yet, and 322 therefore it is proposed that the P2MP PW survivability will 323 initially rely on the LSP survivability. Further work is needed on 324 this subject, partiularly if a requiremnet emerges to provide 325 survivability for P2MP PWs in an MPLS-TP context. 327 7. Network Management 329 The network management architecture and requirements for MPLS-TP are 330 specified in [RFC5951]. They derive from the generic specifications 331 described in ITU-T G.7710/Y.1701 [G.7710] for transport technologies. 332 They also incorporate the OAM requirements for MPLS Networks 333 [RFC4377] and MPLS-TP Networks [RFC5860] and expand on those 334 requirements to cover the modifications necessary for fault, 335 configuration, performance, and security in a transport network. 337 [Editor's note: Decide what if anything needs to be said about P2MP- 338 specific network management considerations.] 340 Section 3.14 of " Framework for MPLS in Transport Networks" [RFC5921] 341 describe the aspects of network management in the P2P MPLS-TP case. 342 This apply to the P2MP case. 344 8. Security Considerations 346 General security considerations for MPLS-TP are covered in [RFC5921]. 347 Additional security considerations for point-to-multipoint LSPs are 348 provided in [RFC4875]. This document introduces no new security 349 considerations beyond those covered in those documents. 351 9. IANA Considerations 353 IANA considerations resulting from specific elements of MPLS-TP 354 functionality are detailed in the documents specifying that 355 functionality. This document introduces no additional IANA 356 considerations in itself. 358 10. References 360 10.1. Normative References 362 [RFC4872] Lang, J., Rekhter, Y., and 363 D. Papadimitriou, "RSVP-TE 364 Extensions in Support of 365 End-to-End Generalized 366 Multi-Protocol Label 367 Switching (GMPLS) 368 Recovery", RFC 4872, 369 May 2007. 371 [RFC4873] Berger, L., Bryskin, I., 372 Papadimitriou, D., and A. 373 Farrel, "GMPLS Segment 374 Recovery", RFC 4873, 375 May 2007. 377 [RFC4875] Aggarwal, R., 378 Papadimitriou, D., and S. 379 Yasukawa, "Extensions to 380 Resource Reservation 381 Protocol - Traffic 382 Engineering (RSVP-TE) for 383 Point-to-Multipoint TE 384 Label Switched Paths 385 (LSPs)", RFC 4875, 386 May 2007. 388 [RFC5036] Andersson, L., Minei, I., 389 and B. Thomas, "LDP 390 Specification", RFC 5036, 391 October 2007. 393 [RFC5331] Aggarwal, R., Rekhter, Y., 394 and E. Rosen, "MPLS 395 Upstream Label Assignment 396 and Context-Specific Label 397 Space", RFC 5331, 398 August 2008. 400 [RFC5332] Eckert, T., Rosen, E., 401 Aggarwal, R., and Y. 402 Rekhter, "MPLS Multicast 403 Encapsulations", RFC 5332, 404 August 2008. 406 [RFC5654] Niven-Jenkins, B., 407 Brungard, D., Betts, M., 408 Sprecher, N., and S. Ueno, 409 "Requirements of an MPLS 410 Transport Profile", 411 RFC 5654, September 2009. 413 [RFC5921] Bocci, M., Bryant, S., 414 Frost, D., Levrau, L., and 415 L. Berger, "A Framework for 416 MPLS in Transport 417 Networks", RFC 5921, 418 July 2010. 420 [RFC6374] Frost, D. and S. Bryant, 421 "Packet Loss and Delay 422 Measurement for MPLS 423 Networks", RFC 6374, 424 September 2011. 426 [RFC6375] Frost, D. and S. Bryant, "A 427 Packet Loss and Delay 428 Measurement Profile for 429 MPLS-Based Transport 430 Networks", RFC 6375, 431 September 2011. 433 10.2. Informative References 435 [G.7710] "ITU-T Recommendation 436 G.7710/Y.1701 (07/07), 437 "Common equipment 438 management function 439 requirements"", 2005. 441 [I-D.hmk-mpls-tp-p2mp-oam-framework] Koike, Y., Hamano, T., and 442 M. Namiki, "A framework for 443 Point-to-Multipoint MPLS-TP 444 OAM", draft-hmk-mpls-tp- 445 p2mp-oam-framework-01 (work 446 in progress), 447 November 2012. 449 [I-D.ietf-l2vpn-vpms-frmwk-requirements] Kamite, Y., JOUNAY, F., 450 Niven-Jenkins, B., 451 Brungard, D., and L. Jin, 452 "Framework and Requirements 453 for Virtual Private 454 Multicast Service (VPMS)", 455 draft-ietf-l2vpn-vpms- 456 frmwk-requirements-05 (work 457 in progress), October 2012. 459 [I-D.ietf-pwe3-p2mp-pw] Sivabalan, S., Boutros, S., 460 and L. Martini, "Signaling 461 Root-Initiated Point-to- 462 Multipoint Pseudowire using 463 LDP", 464 draft-ietf-pwe3-p2mp-pw-04 465 (work in progress), 466 March 2012. 468 [I-D.ietf-pwe3-p2mp-pw-requirements] Bocci, M., Heron, G., and 469 Y. Kamite, "Requirements 470 and Framework for Point-to- 471 Multipoint Pseudowires over 472 MPLS PSNs", draft-ietf- 473 pwe3-p2mp-pw-requirements- 474 05 (work in progress), 475 September 2011. 477 [I-D.raggarwa-pwe3-p2mp-pw-encaps] Aggarwal, R. and F. JOUNAY, 478 "Point-to-Multipoint 479 Pseudo-Wire Encapsulation", 480 draft-raggarwa-pwe3-p2mp- 481 pw-encaps-01 (work in 482 progress), March 2010. 484 [RFC4377] Nadeau, T., Morrow, M., 485 Swallow, G., Allan, D., and 486 S. Matsushima, "Operations 487 and Management (OAM) 488 Requirements for Multi- 489 Protocol Label Switched 490 (MPLS) Networks", RFC 4377, 491 February 2006. 493 [RFC5860] Vigoureux, M., Ward, D., 494 and M. Betts, "Requirements 495 for Operations, 496 Administration, and 497 Maintenance (OAM) in MPLS 498 Transport Networks", 499 RFC 5860, May 2010. 501 [RFC5951] Lam, K., Mansfield, S., and 502 E. Gray, "Network 503 Management Requirements for 504 MPLS-based Transport 505 Networks", RFC 5951, 506 September 2010. 508 [RFC6371] Busi, I. and D. Allan, 509 "Operations, 510 Administration, and 511 Maintenance Framework for 512 MPLS-Based Transport 513 Networks", RFC 6371, 514 September 2011. 516 [RFC6372] Sprecher, N. and A. Farrel, 517 "MPLS Transport Profile 518 (MPLS-TP) Survivability 519 Framework", RFC 6372, 520 September 2011. 522 [RFC6373] Andersson, L., Berger, L., 523 Fang, L., Bitar, N., and E. 524 Gray, "MPLS Transport 525 Profile (MPLS-TP) Control 526 Plane Framework", RFC 6373, 527 September 2011. 529 [RFC6718] Muley, P., Aissaoui, M., 530 and M. Bocci, "Pseudowire 531 Redundancy", RFC 6718, 532 August 2012. 534 Authors' Addresses 536 Dan Frost (editor) 537 Cisco Systems 539 EMail: danfrost@cisco.com 541 Stewart Bryant (editor) 542 Cisco Systems 544 Phone: 545 Fax: 546 EMail: stbryant@cisco.com 547 URI: 549 Matthew Bocci (editor) 550 Alcatel-Lucent 551 Voyager Place, Shoppenhangers Road 552 Maidenhead, Berks SL6 2PJ 553 United Kingdom 555 EMail: matthew.bocci@alcatel-lucent.com 557 Lou Berger (editor) 558 LabN Consulting 560 Phone: +1-301-468-9228 561 EMail: lberger@labn.net