idnits 2.17.1 draft-ietf-pals-ldp-vpls-broadcast-exten-01.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 (June 5, 2015) is 3248 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Simon Delord (editor), Telstra 3 Internet Draft Raymond Key (editor), AusNet Services 4 Category: Standard Track Frederic Jounay, Orange CH 5 Expires: December 2015 Yuji Kamite, NTT Communications 6 Zhihua Liu, China Telecom 7 Manuel Paul, Deutsche Telekom 8 Ruediger Kunze, Deutsche Telekom 9 Mach Chen, Huawei 10 Lizhong Jin 12 June 5, 2015 14 Extension to LDP-VPLS for Ethernet Broadcast and Multicast 15 draft-ietf-pals-ldp-vpls-broadcast-exten-01 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 5, 2015. 40 Abstract 42 This document proposes a simple extension to LDP-VPLS to improve 43 bandwidth efficiency for Ethernet broadcast/multicast traffic 44 within a carrier's network. It makes use of unidirectional 45 point-to-multipoint PseudoWires to minimise payload frame duplication 46 on physical links. 48 Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in [RFC2119]. 54 Table of Contents 56 1. Introduction.....................................................2 57 2. Problem Statement & Motivation...................................3 58 2.1. Requirements for Broadcast/Multicast Support in VPLS...........3 59 2.2. Motivation.....................................................4 60 2.3. Scope of the proposed solution.................................5 61 3. Terminology......................................................5 62 4. Relevant IETF technologies for the proposed solution.............6 63 4.1. P2MP LSPs......................................................6 64 4.2. P2MP PWs.......................................................6 65 5. Proposed extension to [RFC4762]..................................7 66 5.1. VPLS Reference Model...........................................7 67 5.2. Choosing PEs for a specific VPLS to be connected by a P2MP PW..9 68 5.3. Create and associate the P2MP PW to a specific VPLS instance...9 69 5.4. Mapping more than one P2MP PW to a specific VPLS Instance 70 on a specific root PE.........................................10 71 5.5. Flooding and Forwarding.......................................10 72 5.6. Address Learning..............................................11 73 5.7. Loop Free Topology............................................11 74 5.8. Hierarchical VPLS.............................................11 75 5.9. P2MP PW Status................................................11 76 6. Local PE Implementation.........................................12 77 7. Security Considerations.........................................12 78 8. IANA Considerations.............................................12 79 9. Acknowledgments.................................................12 80 10. References.....................................................13 81 10.1. Normative References.........................................13 82 10.2. Informative References.......................................13 83 Author's Addresses.................................................14 84 Appendix A. One example for broadcast video delivery...............15 86 1. Introduction 88 This document proposes a simple extension to LDP-VPLS [RFC4762] to 89 improve bandwidth efficiency for Ethernet broadcast/multicast traffic 90 within a carrier's network. This bandwidth improvement is achieved by 91 adding to the existing full-mesh of bidirectional point-to-point 92 PseudoWires (P2P PWs) unidirectional point-to-multipoint PseudoWires 93 (P2MP PWs) between selected PEs within a VPLS instance. With P2MP 94 PWs, the ingress PE is not responsible for replicating the payload 95 frame on each P2P PW towards the egress PE, instead the network 96 elements along the physical path participate in the replication 97 process. The replication is done by the underlying point-to-multi- 98 point label switched path. This proposal allows for a large number 99 of P2MP PWs to be carried through a single MPLS P2MP tunnel, thus, 100 it is never necessary to maintain state in the network core for 101 individual P2MP PWs. 103 2. Problem Statement & Motivation 105 2.1. Requirements for Broadcast/Multicast Support in VPLS 107 [RFC5501] provides an in-depth discussion on broadcast/multicast 108 related requirements for VPLS. It highlights two specific issues: 110 - issue A: replication to non-member site. 111 - issue B: replication of PWs on shared physical path. 113 2.1.1. Issue A: replication to non-member site 115 The current standard VPLS is a L2VPN service agnostic to customer's 116 Layer 3 traffic, hence does not maintain any information about IP 117 multicast group membership. Although a Layer 3 IP multicast packet 118 is encapsulated in a Layer 2 Ethernet multicast frame, the current 119 standard VPLS treats Ethernet multicast frame in exactly the same way 120 as Ethernet broadcast frame. There is therefore an issue that 121 multicast traffic is sent to sites with no members. Since the 122 upstream PE does not maintain downstream membership information, it 123 simply floods frames to all downstream PEs, and the downstream PEs 124 forward them to directly connected CEs; however, those CEs might not 125 be the members of any multicast group. 127 There are therefore two elements to Issue A: 129 - the PE to CE section (e.g. the AC), where a CE will receive 130 unintended traffic. 132 - the PE to PE section within a VPLS instance, where a PE will 133 receive multicast traffic even when it has no CE being member of 134 any multicast group. 136 To address the PE to CE part, a PE might have to maintain multicast 137 group information for CEs that are not kept in the existing VPLS 138 solutions. 140 To address the PE to PE part and limit the flooding scope across the 141 backbone, a PE needs to discover multicast group information from 142 other remote PEs. 144 Both elements will present scalability concerns about state resources 145 (memory, CPU, etc.) and their maintenance complexity. 147 Finally, if Layer-3 information is checked for transport, the 148 following [RFC4665] requirement "a L2VPN service SHOULD be agnostic 149 to customer's Layer3 traffic" can no longer be met. 151 2.1.2. Issue B: replication of PWs on shared physical path 153 Issue B on the other hand can still be improved without making use of 154 any Layer-3-related information. 156 Issue B may still be considered acceptable when: 158 - Ethernet broadcast/multicast traffic volume is low; and 159 - The number of replications on each outgoing physical interface for 160 a VPLS instance is small (e.g. not many PEs per VPLS instance). 162 However, with more broadcast/multicast applications (e.g. broadcast 163 TV), Ethernet broadcast/multicast traffic volume may increase to a 164 significant level. Assuming HDTV requires 10Mbps per channel, a 165 bundle of 100 channels will require 1Gbps. 167 Furthermore, as MPLS networks expand from the core towards 168 aggregation/access, more PEs may participate in a single VPLS 169 instance. The number of replications on each outgoing physical 170 interface for a VPLS instance is likely to increase. 172 2.2. Motivation 174 Based on the previous section, it may still be desirable for some 175 carriers to look at improving issue B without having to look at Layer 176 3 information (Issue A). 178 One reason for this is that sometimes there is no L3 data to snoop. 179 Another reason may be that some carriers may not be allowed to look 180 above the L2 header, for example there may be regulatory issues with 181 inspecting the customer payload. Also, some carriers may not want to 182 do L3 snooping as Operations will naturally become more complicated 183 if the number of managed objects (e.g. multicast groups) increases. 185 Another important point is that some carriers may want a manual and 186 granular optimisation process that allows optimizations to certain 187 services or areas but does not impact the rest of the network. For 188 example, the bandwidth improvement process may only be required at 189 specific locations in the network where bandwidth-intensive multicast 190 broadcast Ethernet flows exist. It would also be beneficial if the 191 optimisation process were incrementally deployable, so that the 192 optimisation can still be leveraged even if there are portions of the 193 network that are not able to support the features required by the 194 optimisation process. A potential case would be a VPLS instance 195 composed of both PEs supporting the proposed protocol extension and 196 PEs not supporting it, the enhancement is then achieved between the 197 compliant PEs only. 199 Finally, some carriers may also prefer a deterministic process to an 200 entirely automated path selection algorithm that is network driven. 201 [RFC5501] gives several reasons on why this may be the case: 203 - Accounting for various operator policies where the logical 204 multicast topology within a carrier's network does not change 205 dynamically in conjunction with a customer's multicast routing. 207 - Operations will naturally become more complicated if topology 208 changes occur more frequently. 210 - Troubleshooting will tend to be difficult if a solution supports 211 frequent dynamic membership changes with optimized transport within 212 the carrier's network. 214 [RFC7117] is a solution that looks at solving both Issue A and Issue 215 B. However, [RFC7117] proposes that, even for carriers who currently 216 use [RFC4762] without auto-discovery mechanisms, BGP be introduced. 217 This may also present operational challenges and complexities for 218 some carriers, or this feature may simply not be supported on some of 219 the network elements deployed. 221 2.3. Scope of the proposed solution 223 This draft therefore explores whether there is a way to improve 224 Layer 2 Ethernet broadcast/multicast bandwidth simply and predictably 225 with: 227 - Minimal extension to [RFC4762] and without the need to add BGP 228 (e.g. no auto-discovery) 229 - Minimal impact to existing [RFC4762] deployed networks 230 - Operator driven optimisation (i.e. the operator decides where and 231 how the bandwidth improvement should occur) to minimise the number 232 of states and the potential operational complexities associated 233 with dynamic changes within a carrier's core network. 235 3. Terminology 237 This document uses terminology described in [RFC4762] and [RFC7338]. 239 4. Relevant IETF technologies for the proposed solution 241 The proposed solution relies on [RFC4762] existing mechanisms and 242 complements them with extensions (P2MP LSPs and P2MP PWs) already 243 standardised ([RFC4875]) or currently under development by the IETF 244 ([RFC6388] and [P2MP-PW-LDP]). 246 4.1. P2MP LSPs 248 Similarly to what is defined in [RFC4762] where P2P PWs are 249 multiplexed onto P2P LSPs, before the operator can start deploying 250 P2MP PWs, an appropriate underlying layer made of P2MP LPSs needs to 251 be configured (section 3.2 of [RFC7338]). 253 P2MP LSPs are used to minimise packet replication on specific 254 physical links and to allow P routers in an MPLS domain to be 255 transparent to services (e.g. a P Router will join the P2MP PSN 256 tunnel operation but will have no knowledge of the P2MP PWs, same 257 as [RFC4762]). 259 The mapping of the P2MP LSP over the physical topology is a 260 key component of the bandwidth enhancement exercise and the operator 261 needs to carefully consider where and how these P2MP LSPs should be 262 deployed (see Appendix A for an example of a possible deployment). 264 Once configured, it is then possible to aggregate P2MP PWs over a 265 particular P2MP LSP (similar to [RFC4762]). 267 4.2. P2MP PWs 269 P2MP PWs can be configured statically (e.g. by the operator) or via 270 LDP on top of the P2MP LSPs. This configuration is done on a per PE 271 per VPLS instance basis. 273 In a P2MP PW, the operator decides to connect one Root PE to at least 274 two Leaf PEs (section 3.1 of [RFC7338]). 276 The Root PE is the headend of the P2MP PW (where a big Ethernet 277 multicast/broadcast talker is connected - see example in Appendix A). 279 The Leaf PEs are the endpoints of the P2MP PW (they constitute 280 the receivers where the broadcast/multicast traffic needs to be 281 distributed to). 283 A Root PE may map more than one P2MP PW to a specific VPLS instance. 284 In this case, the Root PE MUST NOT associate a leaf PE to more than 285 one P2MP PW for a specific VPLS instance (this is to avoid a Leaf PE 286 to receive duplicate copies of the same Ethernet frame from different 287 P2MP PWs). 289 P2MP PWs are defined in [RFC7338] and one solution using LDP as 290 the signalling mechanism between PEs is defined in [P2MP-PW-LDP]. 292 5. Proposed extension to [RFC4762] 294 This section updates [RFC4762] by describing the extra rules to be 295 applied within a VPLS when unidirectional P2MP PWs are added to the 296 existing full-mesh of P2P PWs. 298 5.1. VPLS Reference Model 300 Figure 1 shows a topological model (not the physical topology) 301 of a VPLS between four PEs with an arbitrary set of ACs attached to 302 each VSI. 304 +---------+ +---------+ 305 | PE1 | | PE2 | 306 | +---+ | | +---+ | 307 | | | | | | +-------AC4--- 308 | | V | | | | V | | 309 | | | | | | | | 310 ----AC1----+--+ | | Ethernet | | +--+----AC5--- 311 | | S +--+-----PW-----+--+ S | | 312 | | | | | | | | 313 ----AC2----+--+ | | | | | | 314 | | I | | | | I | | 315 | | | | Ethernet | | | | 316 ----AC3----+--+ | | PW +-----+--+ | | 317 | +-+-+ | / | +-+-+ | 318 | | \ | / | | | 319 +----+---\+ / +----+----+ 320 | \ / | 321 Ethernet| \/ |Ethernet 322 PW| /\ |PW 323 | / \Ethernet | 324 +----+---/+ \PW +----+----+ 325 |PE3 | / | \ |PE4 | | 326 | +-+-+ | \ | +-+-+ | 327 ----AC6----+--+ | | \ | | +--+----AC8---- 328 | | V | | +----+--+ V | | 329 | | | | | | | | 330 ----AC7----+--+ | | Ethernet | | +--+----AC9---- 331 | | S +--+-----PW-----+--+ S | | 332 | | | | | | | | 333 | | | | | | | | 334 | | I | | | | I | | 335 | | | | | | | | 336 | | | | | | | | 337 | +---+ | | +---+ | 338 | | | | 339 +---------+ +---------+ 341 Figure 1: Reference Diagram for VPLS 343 Figure 2 shows the proposed extensions to VPLS for Ethernet broadcast 344 and multicast. On top of the topology presented in Figure 2, two 345 P2MP PWs have been added to the existing set of P2P PWs. 347 +---------+ +---------+ 348 | PE1 | | PE2 | 349 | +---+ | | +---+ | 350 | | | | | | +-------AC4--- 351 | | V | | Ethernet | | V | | 352 | | | | P2MP | | | | 353 ----AC1----+--+ | | PW1 | | +--+----AC5--- 354 | | S +--+->--+-->----+--+ S | | 355 | | | | | | | | | 356 ----AC2----+--+ | | | | | | | 357 | | I | | | +->-+--+ I | | 358 | | | | | | | | | | 359 ----AC3----+--+ | | | | | | | | 360 | +---+ | | | | +---+ | 361 | | | | | | 362 +---------+ | | +---------+ 363 | | 364 | | 365 | | 366 | | 367 +---------+ | | +---------+ 368 |PE3 | | | |PE4 | 369 | +---+ | | | | +---+ | 370 ----AC6----+--+ | | +->-----+--+ +--+----AC8---- 371 | | V | | | | | V | | 372 | | | | | | | | | 373 ----AC7----+--+ | | | | | +--+----AC9---- 374 | | S +--+->------+->-+--+ S | | 375 | | | | Ethernet | | | | 376 | | | | P2MP | | | | 377 | | I | | PW2 | | I | | 378 | | | | | | | | 379 | | | | | | | | 380 | +---+ | | +---+ | 381 | | | | 382 +---------+ +---------+ 384 Figure 2: Proposed Extensions to VPLS for Ethernet broadcast/multicast 386 P2MP PW1 is composed of PE1 as the root PE and PE2 and PE4 as leaf 387 PEs. 389 P2MP PW2 is composed of PE3 as the root PE and PE2 and PE4 as leaf 390 PEs. 392 Note that for sake of clarity, Figure 2 does not show the full-mesh 393 of P2P PWs presented in Figure 1. 395 Also note that the solution does not require that P2MP PWs be used on 396 all PEs in the VPLS. For example, PE3 is not leaf of P2MP PW1 and PE1 397 is not leaf of P2MP PW2 and therefore, there is only a P2P PW between 398 PE1 and PE3, and a P2P PW between PE2 and PE4. 400 5.2. Choosing PEs for a specific VPLS to be connected by a P2MP PW 402 This updates section 4.3 of [RFC4762]. 404 VPLS is a full-mesh of P2P PWs and optionally a number of 405 unidirectional P2MP PWs. At the difference of P2P PWs, not all PEs in 406 a VPLS instance need to be connected via P2MP PWs. 408 For each P2MP PW on this VPLS instance: 410 - The operator selects one PE as the Root of the P2MP PW. 412 - The operator also selects two or more PEs belonging to the same 413 VPLS instance to be Leafs of the P2MP PW 415 - Because there is already a full-mesh of bidirectional P2P PWs 416 between all PEs, the P2MP PW is unidirectional only (e.g. from 417 the Root PE to all the Leaf PEs connected to it). 419 - The operator also needs to make sure that there is an active P2MP 420 LSP setup between the Root PE and the Leaf PEs: 422 - If there is already an active P2MP LSP setup between the Root 423 PE and the Leaf PEs, then procedures described in 5.3 can be 424 followed. 426 - If there is no P2MP LSP between the Root PE and the Leaf PEs 427 then the operator needs to create first a P2MP LSP in order for 428 procedures in 5.3 to be followed. Procedures to setup a P2MP LSP 429 will vary based on the technology used and are described in 430 [RFC6388] and [RFC4875]. 432 5.3. Create and associate the P2MP PW to a specific VPLS Instance 434 This updates section 4.3 of [RFC4762]. 436 Once that the endpoints of the P2MP PW have been selected and that 437 there is an active P2MP LSP between them, the operator can then 438 create and associate the P2MP PW to a specific VPLS instance. 439 This activity can be done statically or via LDP [P2MP-PW-LDP]. 441 Because P2MP PWs are used to demultiplex encapsulated Ethernet frames 442 from multiple VPLS instances that are aggregated over the same P2MP 443 transport LSP, it is necessary that a Leaf PE can associate 444 unambiguously a P2MP PW aggregated within a P2MP LSP to both a 445 specific VPLS instance and a Root PE. 447 In the static case, the operator is responsible for configuring all 448 the required information on all PEs belonging to the P2MP PW. 450 In the LDP case, the P2MP PW is initiated by the Root PE by sending a 451 P2MP PW LDP Label Mapping Message to each of the Leaf PEs. 453 This label mapping contains, the VPLS instance the P2MP PW is 454 associated to, the P2MP LSP used to transport the P2MP PW and the 455 P2MP PW MPLS Label. 457 The P2MP PW MPLS Label is upstream assigned and allocated according 458 to the rules in [RFC5331]. 460 The root PE imposes the upstream-assigned label on the outbound 461 packets sent over the P2MP-PW and using this label a Leaf PE can 462 identify the inbound packets arriving over the P2MP PW. 464 Detailed LDP message formats and P2MP PW setup procedures are 465 described in [P2MP-PW-LDP]. 467 5.4. Mapping more than one P2MP PW to a specific VPLS Instance on a 468 specific Root PE 470 The proposed solution allows for a Root PE to map more than one P2MP 471 PW to a specific VPLS instance (see example in Appendix A). 473 However in this case, the Root PE MUST NOT associate a leaf PE to 474 more than one P2MP PW for a specific VPLS instance (this is to avoid 475 a Leaf PE to receive duplicate copies of the same Ethernet frame from 476 different P2MP PWs). 478 5.5. Flooding and Forwarding 480 This section updates section 4.1. of [RFC4762]. 482 A root PE MUST NOT flood frames simultaneously over P2MP PW and P2P 483 PW toward the same leaf PE. 485 For the flooding of an Ethernet broadcast/multicast frame over PWs to 486 remote PEs participating in the VPLS: 488 - If there is P2MP PW towards a remote PE, the P2P PW 489 associated with this remote PE will not be used. One copy 490 of the frame will be forwarded on the P2MP PW for all the 491 remote PEs associated with it. 492 - If there is no P2MP PW towards a remote PE, the P2P PW 493 associated with this remote PE is used. 495 It should be noted that local policy on the Root PE at the operator's 496 operational request can override any decision to flood and forward 497 traffic over a P2MP PW for a VPLS instance. In that case, normal 498 flooding procedures over P2P PWs described in 4.1 of [RFC4762] apply. 500 5.5.1. Flooding and Forwarding for Ethernet unknown unicast 502 In traditional Ethernet switched networks unknown unicast frames are 503 handled the same way as broadcast and multicast Ethernet traffic 504 (e.g. flooding). Similarly, current VPLS standards also handle 505 unknown unicast traffic by flooding it across all P2P PWs. 507 The main purpose of this document is to address Ethernet broadcast 508 and multicast traffic. For Ethernet unknown unicast frames there are 509 two possibilities: 511 (1) forward the unknown unicast traffic on the P2MP PW, same as for 512 Ethernet broadcast and multicast. 513 (2) keep the existing mechanism of [RFC4762] and flood over the mesh 514 of P2P PWs. 516 A Root PE SHOULD support both the above as configurable options per 517 VPLS instance. For a particular VPLS instance where frame reordering 518 is considered unacceptable, option (2) is recommended. 520 5.6. Address Learning 522 This section updates section 4.2. of [RFC4762]. 524 A Leaf PE MUST support the ability to perform MAC address learning 525 for packets received on a P2MP PW. 527 When a Leaf PE receives an Ethernet frame on a P2MP PW it: 528 - First determines the VSI associated to the P2MP PW 529 - Then determines the Root PE of the P2MP PW 530 - Then determines the P2P PW associated with that Root PE 531 - Finally, creates a forwarding state in the VPLS instance for 532 the P2P PW associated with the Root PE with a destination 533 MAC address being the same as the source MAC address being 534 learned. 536 5.7. Loop Free Topology 538 This updates section 4.4. of [RFC4762] 540 Paragraph 2 "must not forward from one PW to another" is applicable 541 to P2MP PW & P2P PW. 543 5.8. Hierarchical VPLS 545 This refers to section 10 and 11 in [RFC4762]. No change is required. 547 5.9 P2MP PW Status 549 In case of a P2MP PW status change to not operational as per 550 [P2MP-PW-LDP], then this should be treated as if this P2MP PW does 551 not exist. 553 6. Local PE Implementation 555 This section is OPTIONAL. 557 As described in section 2.1.1, a PE receiving an IP multicast frame, 558 will forward it to all ACs, including those with no member of the 559 specific IP multicast group attached. 561 Unnecessary traffic consumes bandwidth on the access link and may 562 become a concern from the customer perspective. In some cases, it may 563 also be a security concern as the multicast frame may be forwarded to 564 an endpoint other than the intended destinations. 566 Consequently, the use of some L3 related supplementary information in 567 order to improve bandwidth consumption on the AC may be considered. 568 Enabling L3 snooping on an AC basis only has an impact on the PE 569 where the AC belongs, it does not impact the number of P2MP PW/LSPs 570 used within the carrier's network and the state resources or the 571 maintenance complexity associated with it. 573 Alternatives to L3 snooping such as static configuration of multicast 574 Ethernet addresses & ports / interfaces for example are also 575 possible. 577 7. Security Considerations 579 This document does not introduce any new security issues beyond those 580 already described in [RFC4762]. 582 8. IANA Considerations 584 This document does not require IANA assignment. 586 9. Acknowledgments 588 The authors would like to thank Marc Lasserre, Cesar Garrido, Lucy 589 Yong, Neil Harrison, Samer Salam, Nocolai Leymann, Florin Balus, Olen 590 Stokes, Ali Sajassi, Phil Bedard, Thomas Beckhaus, Linda Dunbar, Max 591 Ng, Asaf Henig, Mark Whalley and Cary Wright for their valuable 592 comments. 594 10. References 596 10.1. Normative References 598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 599 Requirement Levels", BCP 14, RFC 2119, March 1997. 601 [RFC4762] Lasserre & Kompella, "Virtual Private LAN Service (VPLS) 602 Using Label Distribution Protocol (LDP) Signaling", 603 RFC 4762, January 2007. 605 [P2MP-PW-LDP] Sivabalan, et. al, "Signaling Root-Initiated 606 Point-to-Multipoint Pseudowires using LDP", 607 draft-ietf-pwe3-p2mp-pw-04, work in Progress, 608 March 2012. 610 [RFC6388] Wijnands, et. al, "Label Distribution Protocol Extensions 611 for Point-to-Multipoint and Multipoint-to-Multipoint Label 612 Switched Paths", RFC 6388, November 2011. 614 [RFC4875] R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed., 615 "Extensions to Resource Reservation Protocol - Traffic 616 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 617 Switched Paths (LSPs)", RFC 4875, May 2007. 619 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 620 Assignment and Context Specific Label Space", RFC 5331, 621 August 2008. 623 10.2. Informative References 625 [RFC5501] Kamite, et al., "Requirements for Multicast Support in 626 Virtual Private LAN Services", RFC 5501, March 2009. 628 [RFC7338] Jounay, et. al, "Requirements and Framework for 629 Point-to-Multipoint Pseudowires over MPLS PSNs", 630 RFC 7338, September 2014 632 [RFC7117] Raggarwa, Kamite & Fang, "Multicast in VPLS", RFC 7117, 633 February 2014. 635 [RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for 636 Layer 2 Provider-Provisioned Virtual Private Networks", 637 RFC 4665, September 2006. 639 Author's Addresses 641 Simon Delord (editor) 642 Telstra 643 EMail: simon.delord@gmail.com 645 Raymond Key (editor) 646 AusNet Services 647 EMail: raymond.key@ieee.org 649 Frederic Jounay 650 Orange CH 651 4 rue caudray 1020 Renens 652 Switzerland 653 EMail: frederic.jounay@orange.ch 655 Yuji Kamite 656 NTT Communications Corporation 657 Granpark Tower 658 3-4-1 Shibaura, Minato-ku 659 Tokyo 108-8118 660 Japan 661 EMail: y.kamite@ntt.com 663 Zhihua Liu 664 China Telecom 665 109 Zhongshan Ave. 666 Guangzhou 510630 667 China 668 EMail: zhliu@gsta.com 670 Manuel Paul 671 Deutsche Telekom 672 Winterfeldtstr. 21-27 673 10781 Berlin, Germany 674 EMail: manuel.paul@telekom.de 676 Ruediger Kunze 677 Deutsche Telekom 678 Winterfeldtstr. 21-27 679 10781 Berlin, Germany 680 EMail: ruediger.kunze@telekom.de 682 Mach(Guoyi) Chen 683 Huawei Technology Co., Ltd. 684 Q14 Huawei Campus, No. 156 Beiqing Road 685 Hai-dian District, Beijing 100095 686 China 687 EMail: mach.chen@huawei.com 689 Lizhong Jin 690 EMail: lizho.jin@gmail.com 692 Appendix A. One example for broadcast video delivery 694 This section describes one deployment scenario in relation to 695 broadcast video delivery and how the proposed solution would work. 697 One requirement of the model is that the application needs unicast 698 data exchange (IP unicast transfer or control messages etc.) as a 699 background environment. MAC-learning (and therefore VPLS) is 700 effective to support it. 702 A.1. Broadcast Video Delivery Topology 704 Figure 3 presents the physical topology of one broadcast video 705 deployment. 707 | | | 708 AC AC AC 709 | | | 710 +---+ +---+ +---+ 711 |PE3| |PE4| |PE5| 712 +---+ +---+ +---+ 713 \ | / 714 \ | / +----+ 715 \ | / +---|PE9 |--AC-- 716 \ | / / +----+ 717 Ethernet +---+ +---+ +---+/ +----+ 718 Broadcast->-AC--|PE1|----------|P1 |--------|P3 |------|PE10|--AC-- 719 Source +---+\ /+---+ +---+\ +----+ 720 \ / | | \ +----+ 721 \ / | | +---|PE11|--AC-- 722 \ / | | +----+ 723 \/ | | 724 /\ | | 725 / \ | | +----+ 726 / \ | | +---|PE12|--AC-- 727 / \ | | / +----+ 728 Ethernet +---+/ \+---+ +---+/ +----+ 729 Broadcast->-AC--|PE2|----------|P2 |--------|P4 |------|PE13|--AC-- 730 Source +---+ +---+ +---+\ +----+ 731 / | \ \ +----+ 732 / | \ +---|PE14|--AC-- 733 / | \ +----+ 734 / | \ 735 +---+ +---+ +---+ 736 |PE6| |PE7| |PE8| 737 +---+ +---+ +---+ 738 | | | 739 AC AC AC 740 | | | 742 Figure 3 - Physical Topology for Broadcast video 744 Figure 3 is split in three logical components: 746 - The Core network composed of P1, P2, P3 & P4. These 4 network 747 elements are P routers connected in a ring. 749 - The Data Centers. These are a few large PoPs with high resiliency 750 that hold the video content. PE1 & PE2 are located in one Data 751 Center and are dual-homed to the core network. An Ethernet 752 broadcast source is connected to each PE in the Data Center. 754 - The Aggregation network. The Aggregation network is responsible 755 for aggregating last mile technology towards endusers (direct 756 fiber, GPON, DSL, etc.). PE3, PE4, until PE14 are VPLS PE routers 757 in an aggregation PoP and single-homed to the Core network. 759 There are two different video distribution services organised as 760 follows: 762 - PE1 is connected to PE3, PE4, ... PE14 via VPLS instance-1. 763 - One Ethernet broadcast source is connected to PE1 into VPLS 764 instance-1. 765 - PE2 is connected to PE3, PE4 ...PE14 via VPLS instance-2. 766 - One Ethernet broadcast source is connected to PE2 into VPLS 767 instance-2. 769 A.2. Impact of Physical Topologies on Ethernet Broadcast/multicast 770 replication 772 Following the standard VPLS flooding mechanism, each time PE1 773 receives one broadcast frame from the Ethernet broadcast source on 774 VPLS-1, PE1 will replicate 12 times the incoming frame. 776 Similarly, each time PE2 receives one broadcast frame from the 777 Ethernet broadcast source on VPLS-2, PE2 will replicate 12 times the 778 incoming frame. 780 A.3. Proposed enhancement of Ethernet broadcast/multicast 782 The proposed enhancements are done in three steps: 784 - create P2MP LSPs for the infrastructure. These P2MP LSPs are 785 used to carry one or more P2MP PWs. 787 - create unidirectional P2MP PWs by selectively choosing PEs where 788 the optimisation should occur. 790 - forward Ethernet broadcast/multicast frames onto the P2MP PWs 791 where these P2MP PWs have been created. 793 It is up to the network operator to decide how the distribution of 794 the loading on physical link should occur. 796 Two different examples are presented below. 798 A.3.1. One possible enhancement scenario 800 A.3.1.1. Initial Deployment 802 In this scenario, the operator decides to create the following P2MP 803 LSPs: 805 - PE1->PE3-5 via P1 called LSP1 806 - PE1->PE6-8 via P2 called LSP2 807 - PE1->PE9-11 via P3 called LSP3 809 - PE2->PE3-5 via P1 called LSP4 810 - PE2->PE6-8 via P2 called LSP5 811 - PE2->PE9-11 via P3 called LSP6 813 The operator then creates the following P2MP PWs: 815 - PE1->PE3-5 via P2MP PW1 over LSP1 816 - PE1->PE6-8 via P2MP PW2 over LSP2 817 - PE1->PE9-11 via P2MP PW3 over LSP3 819 - PE2->PE3-5 via P2MP PW4 over LSP4 820 - PE2->PE6-8 via P2MP PW5 over LSP5 821 - PE2->PE9-11 via P2MP PW6 over LSP6 823 There is no P2MP PWs between PE1 and PE12, PE13 and PE14. 824 There is no P2MP PWs between PE2 and PE12, PE13 and PE14. 826 There are several reasons why a P2MP PW may not be available on this 827 part of the network (e.g. PE12, PE13 and PE14), for example: 829 - the hardware/software may not allow the support of the 830 required features (P2MP LSPs and/or P2MP PWs). 831 - the operator does not need to improve multicast/broadcast 832 services there (e.g. no specific bandwidth issue). 833 - the operator is currently under a migration phase where only 834 part of the network is migrated at a time. 836 In this case, when PE1 receives one broadcast frame from the 837 Ethernet broadcast source on VPLS-1: 838 - PE1 sends one copy of the broadcast frame onto P2MP PW1 839 - PE1 sends one copy of the broadcast frame onto P2MP PW2 840 - PE1 sends one copy of the broadcast frame onto P2MP PW3 841 - PE1 sends one copy onto the P2P PW towards PE12 842 - PE1 sends one copy onto the P2P PW towards PE13 843 - PE1 sends one copy onto the P2P PW towards PE14 845 PE1 only replicates 6 copies now (this is an improvement from 12 846 copies if only using P2P PWs). 848 A.3.1.2 Multiple P2MP PWs 850 Let's assume now that a new broadcast service is targeted at covering 851 endusers geographically connected to PE9, PE10 and PE11. 853 For example, this could be a wholesale service, where another carrier 854 with limited footprint for the region covered by PE9, PE10 and PE11 855 is seeking access for deploying its own broadcast application. 857 Based on the proposal in this document, and assuming that the 858 application also needs unicast data exchange, if the new broadcast 859 source is connected to PE1, it is then possible to: 861 - Create a new VPLS instance on PE1, PE9, PE10 and PE11 and a full- 862 mesh of P2P PWs between all 4 PEs. 864 - Build a new P2MP PW, called P2MP PW7 between PE1, PE9, PE10 & PE11 865 that uses the existing P2MP LSP - LSP3. 867 This proposal allows for both P2MP PW3 and P2MP PW7 to be carried 868 through a single MPLS P2MP tunnel, thus, removing the need to 869 maintain state in the network core for individual P2MP PWs. The P 870 routers in the core only need to be aware of the P2MP LSPs. 872 A.3.2. Another possible enhancement scenario 874 In this scenario, the operator decides to create the following two 875 P2MP LSPs: 877 - PE1-> PE3-14 via LSP1: 878 - P1 as a branch towards PE3, PE4, PE5, P2 and P3 879 - P2 as a branch towards PE6, PE7, PE8 and P4 880 - P3 as a branch towards PE9, PE10 and PE11 881 - P4 as a branch towards PE12, PE13 and PE14 883 - PE2-> PE3-14 via LSP2: 884 - P2 as a branch towards PE6, PE7, PE8, P1 and P4 885 - P1 as a branch towards PE3, PE4, PE5 and P3 886 - P3 as a branch towards PE9, PE10 and PE11 887 - P4 as a branch towards PE12, PE13 and PE14 889 The operator then creates the following P2MP PWs: 891 - PE1-> PE3-14 via P2MP PW1 over LSP1 892 - PE2-> PE3-14 via P2MP PW2 over LSP2 894 This case improves the P2P PW scenario as PE1 only replicates a 895 single copy of the broadcast frame received from the Ethernet 896 broadcast source. 898 Copyright Notice 900 Copyright (c) 2015 IETF Trust and the persons identified as the 901 document authors. All rights reserved. 903 This document is subject to BCP 78 and the IETF Trust's Legal 904 Provisions Relating to IETF Documents 905 (http://trustee.ietf.org/license-info) in effect on the date of 906 publication of this document. Please review these documents 907 carefully, as they describe your rights and restrictions with respect 908 to this document. Code Components extracted from this document must 909 include Simplified BSD License text as described in Section 4.e of 910 the Trust Legal Provisions and are provided without warranty as 911 described in the Simplified BSD License.