idnits 2.17.1 draft-ietf-l2vpn-ldp-vpls-broadcast-exten-07.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 16, 2014) is 3725 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) == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-p2mp-pw-requirements-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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) 4 Category: Standard Track Frederic Jounay, Orange CH 5 Expires: July 2014 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 January 16, 2014 14 Extension to LDP-VPLS for Ethernet Broadcast and Multicast 15 draft-ietf-l2vpn-ldp-vpls-broadcast-exten-07 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 July 16, 2014. 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 [VPLS-Multicast-BGP] is a solution that looks at solving both Issue A 215 and Issue B. However, [VPLS-Multicast-BGP] proposes that, even for 216 carriers who currently use [RFC4762] without auto-discovery 217 mechanisms, BGP be introduced (section 7). This may also present 218 operational challenges and complexities for some carriers, or this 219 feature may simply not be supported on some of the network elements 220 deployed. 222 2.3. Scope of the proposed solution 224 This draft therefore explores whether there is a way to improve 225 Layer 2 Ethernet broadcast/multicast bandwidth simply and predictably 226 with: 228 - Minimal extension to [RFC4762] and without the need to add BGP 229 (e.g. no auto-discovery) 230 - Minimal impact to existing [RFC4762] deployed networks 231 - Operator driven optimisation (i.e. the operator decides where and 232 how the bandwidth improvement should occur) to minimise the number 233 of states and the potential operational complexities associated 234 with dynamic changes within a carrier's core network. 236 3. Terminology 238 This document uses terminology described in [RFC4762] and 239 [P2MP-PW-REQ]. 241 4. Relevant IETF technologies for the proposed solution 243 The proposed solution relies on [RFC4762] existing mechanisms and 244 complements them with extensions (P2MP LSPs and P2MP PWs) already 245 standardised ([RFC4875]) or currently under development by the IETF 246 ([RFC6388] and [P2MP-PW-LDP]). 248 4.1. P2MP LSPs 250 Similarly to what is defined in [RFC4762] where P2P PWs are 251 multiplexed onto P2P LSPs, before the operator can start deploying 252 P2MP PWs, an appropriate underlying layer made of P2MP LPSs needs to 253 be configured (section 3.2 of [P2MP-PW-REQ]). 255 P2MP LSPs are used to minimise packet replication on specific 256 physical links and to allow P routers in an MPLS domain to be 257 transparent to services (e.g. a P Router will join the P2MP PSN 258 tunnel operation but will have no knowledge of the P2MP PWs, same 259 as [RFC4762]). 261 The mapping of the P2MP LSP over the physical topology is a 262 key component of the bandwidth enhancement exercise and the operator 263 needs to carefully consider where and how these P2MP LSPs should be 264 deployed (see Appendix A for an example of a possible deployment). 266 Once configured, it is then possible to aggregate P2MP PWs over a 267 particular P2MP LSP (similar to [RFC4762]). 269 4.2. P2MP PWs 271 P2MP PWs can be configured statically (e.g. by the operator) or via 272 LDP on top of the P2MP LSPs. This configuration is done on a per PE 273 per VPLS instance basis. 275 In a P2MP PW, the operator decides to connect one Root PE to at least 276 two Leaf PEs (section 3.1 of [P2MP-PW-REQ]). 278 The Root PE is the headend of the P2MP PW (where a big Ethernet 279 multicast/broadcast talker is connected - see example in Appendix A). 281 The Leaf PEs are the endpoints of the P2MP PW (they constitute 282 the receivers where the broadcast/multicast traffic needs to be 283 distributed to). 285 A Root PE may map more than one P2MP PW to a specific VPLS instance. 286 In this case, the Root PE MUST NOT associate a leaf PE to more than 287 one P2MP PW for a specific VPLS instance (this is to avoid a Leaf PE 288 to receive duplicate copies of the same Ethernet frame from different 289 P2MP PWs). 291 P2MP PWs are defined in [P2MP-PW-REQ] and one solution using LDP as 292 the signalling mechanism between PEs is defined in [P2MP-PW-LDP]. 294 5. Proposed extension to [RFC4762] 296 This section updates [RFC4762] by describing the extra rules to be 297 applied within a VPLS when unidirectional P2MP PWs are added to the 298 existing full-mesh of P2P PWs. 300 5.1. VPLS Reference Model 302 Figure 1 shows a topological model (not the physical topology) 303 of a VPLS between four PEs with an arbitrary set of ACs attached to 304 each VSI. 306 +---------+ +---------+ 307 | PE1 | | PE2 | 308 | +---+ | | +---+ | 309 | | | | | | +-------AC4--- 310 | | V | | | | V | | 311 | | | | | | | | 312 ----AC1----+--+ | | Ethernet | | +--+----AC5--- 313 | | S +--+-----PW-----+--+ S | | 314 | | | | | | | | 315 ----AC2----+--+ | | | | | | 316 | | I | | | | I | | 317 | | | | Ethernet | | | | 318 ----AC3----+--+ | | PW +-----+--+ | | 319 | +-+-+ | / | +-+-+ | 320 | | \ | / | | | 321 +----+---\+ / +----+----+ 322 | \ / | 323 Ethernet| \/ |Ethernet 324 PW| /\ |PW 325 | / \Ethernet | 326 +----+---/+ \PW +----+----+ 327 |PE3 | / | \ |PE4 | | 328 | +-+-+ | \ | +-+-+ | 329 ----AC6----+--+ | | \ | | +--+----AC8---- 330 | | V | | +----+--+ V | | 331 | | | | | | | | 332 ----AC7----+--+ | | Ethernet | | +--+----AC9---- 333 | | S +--+-----PW-----+--+ S | | 334 | | | | | | | | 335 | | | | | | | | 336 | | I | | | | I | | 337 | | | | | | | | 338 | | | | | | | | 339 | +---+ | | +---+ | 340 | | | | 341 +---------+ +---------+ 343 Figure 1: Reference Diagram for VPLS 345 Figure 2 shows the proposed extensions to VPLS for Ethernet broadcast 346 and multicast. On top of the topology presented in Figure 2, two 347 P2MP PWs have been added to the existing set of P2P PWs. 349 +---------+ +---------+ 350 | PE1 | | PE2 | 351 | +---+ | | +---+ | 352 | | | | | | +-------AC4--- 353 | | V | | Ethernet | | V | | 354 | | | | P2MP | | | | 355 ----AC1----+--+ | | PW1 | | +--+----AC5--- 356 | | S +--+->--+-->----+--+ S | | 357 | | | | | | | | | 358 ----AC2----+--+ | | | | | | | 359 | | I | | | +->-+--+ I | | 360 | | | | | | | | | | 361 ----AC3----+--+ | | | | | | | | 362 | +---+ | | | | +---+ | 363 | | | | | | 364 +---------+ | | +---------+ 365 | | 366 | | 367 | | 368 | | 369 +---------+ | | +---------+ 370 |PE3 | | | |PE4 | 371 | +---+ | | | | +---+ | 372 ----AC6----+--+ | | +->-----+--+ +--+----AC8---- 373 | | V | | | | | V | | 374 | | | | | | | | | 375 ----AC7----+--+ | | | | | +--+----AC9---- 376 | | S +--+->------+->-+--+ S | | 377 | | | | Ethernet | | | | 378 | | | | P2MP | | | | 379 | | I | | PW2 | | I | | 380 | | | | | | | | 381 | | | | | | | | 382 | +---+ | | +---+ | 383 | | | | 384 +---------+ +---------+ 386 Figure 2: Proposed Extensions to VPLS for Ethernet broadcast/multicast 388 P2MP PW1 is composed of PE1 as the root PE and PE2 and PE4 as leaf 389 PEs. 391 P2MP PW2 is composed of PE3 as the root PE and PE2 and PE4 as leaf 392 PEs. 394 Note that for sake of clarity, Figure 2 does not show the full-mesh 395 of P2P PWs presented in Figure 1. 397 Also note that the solution does not require that P2MP PWs be used on 398 all PEs in the VPLS. For example, PE3 is not leaf of P2MP PW1 and PE1 399 is not leaf of P2MP PW2 and therefore, there is only a P2P PW between 400 PE1 and PE3, and a P2P PW between PE2 and PE4. 402 5.2. Choosing PEs for a specific VPLS to be connected by a P2MP PW 404 This updates section 4.3 of [RFC4762]. 406 VPLS is a full-mesh of P2P PWs and optionally a number of 407 unidirectional P2MP PWs. At the difference of P2P PWs, not all PEs in 408 a VPLS instance need to be connected via P2MP PWs. 410 For each P2MP PW on this VPLS instance: 412 - The operator selects one PE as the Root of the P2MP PW. 414 - The operator also selects two or more PEs belonging to the same 415 VPLS instance to be Leafs of the P2MP PW 417 - Because there is already a full-mesh of bidirectional P2P PWs 418 between all PEs, the P2MP PW is unidirectional only (e.g. from 419 the Root PE to all the Leaf PEs connected to it). 421 - The operator also needs to make sure that there is an active P2MP 422 LSP setup between the Root PE and the Leaf PEs: 424 - If there is already an active P2MP LSP setup between the Root 425 PE and the Leaf PEs, then procedures described in 5.3 can be 426 followed. 428 - If there is no P2MP LSP between the Root PE and the Leaf PEs 429 then the operator needs to create first a P2MP LSP in order for 430 procedures in 5.3 to be followed. Procedures to setup a P2MP LSP 431 will vary based on the technology used and are described in 432 [RFC6388] and [RFC4875]. 434 5.3. Create and associate the P2MP PW to a specific VPLS Instance 436 This updates section 4.3 of [RFC4762]. 438 Once that the endpoints of the P2MP PW have been selected and that 439 there is an active P2MP LSP between them, the operator can then 440 create and associate the P2MP PW to a specific VPLS instance. 441 This activity can be done statically or via LDP [P2MP-PW-LDP]. 443 Because P2MP PWs are used to demultiplex encapsulated Ethernet frames 444 from multiple VPLS instances that are aggregated over the same P2MP 445 transport LSP, it is necessary that a Leaf PE can associate 446 unambiguously a P2MP PW aggregated within a P2MP LSP to both a 447 specific VPLS instance and a Root PE. 449 In the static case, the operator is responsible for configuring all 450 the required information on all PEs belonging to the P2MP PW. 452 In the LDP case, the P2MP PW is initiated by the Root PE by sending a 453 P2MP PW LDP Label Mapping Message to each of the Leaf PEs. 455 This label mapping contains, the VPLS instance the P2MP PW is 456 associated to, the P2MP LSP used to transport the P2MP PW and the 457 P2MP PW MPLS Label. 459 The P2MP PW MPLS Label is upstream assigned and allocated according 460 to the rules in [RFC5331]. 462 The root PE imposes the upstream-assigned label on the outbound 463 packets sent over the P2MP-PW and using this label a Leaf PE can 464 identify the inbound packets arriving over the P2MP PW. 466 Detailed LDP message formats and P2MP PW setup procedures are 467 described in [P2MP-PW-LDP]. 469 5.4. Mapping more than one P2MP PW to a specific VPLS Instance on a 470 specific Root PE 472 The proposed solution allows for a Root PE to map more than one P2MP 473 PW to a specific VPLS instance (see example in Appendix A). 475 However in this case, the Root PE MUST NOT associate a leaf PE to 476 more than one P2MP PW for a specific VPLS instance (this is to avoid 477 a Leaf PE to receive duplicate copies of the same Ethernet frame from 478 different P2MP PWs). 480 5.5. Flooding and Forwarding 482 This section updates section 4.1. of [RFC4762]. 484 A root PE MUST NOT flood frames simultaneously over P2MP PW and P2P 485 PW toward the same leaf PE. 487 For the flooding of an Ethernet broadcast/multicast frame over PWs to 488 remote PEs participating in the VPLS: 490 - If there is P2MP PW towards a remote PE, the P2P PW 491 associated with this remote PE will not be used. One copy 492 of the frame will be forwarded on the P2MP PW for all the 493 remote PEs associated with it. 494 - If there is no P2MP PW towards a remote PE, the P2P PW 495 associated with this remote PE is used. 497 It should be noted that local policy on the Root PE at the operator's 498 operational request can override any decision to flood and forward 499 traffic over a P2MP PW for a VPLS instance. In that case, normal 500 flooding procedures over P2P PWs described in 4.1 of [RFC4762] apply. 502 5.5.1. Flooding and Forwarding for Ethernet unknown unicast 504 In traditional Ethernet switched networks unknown unicast frames are 505 handled the same way as broadcast and multicast Ethernet traffic 506 (e.g. flooding). Similarly, current VPLS standards also handle 507 unknown unicast traffic by flooding it across all P2P PWs. 509 The main purpose of this document is to address Ethernet broadcast 510 and multicast traffic. For Ethernet unknown unicast frames there are 511 two possibilities: 513 (1) forward the unknown unicast traffic on the P2MP PW, same as for 514 Ethernet broadcast and multicast. 515 (2) keep the existing mechanism of [RFC4762] and flood over the mesh 516 of P2P PWs. 518 A Root PE SHOULD support both the above as configurable options per 519 VPLS instance. For a particular VPLS instance where frame reordering 520 is considered unacceptable, option (2) is recommended. 522 5.6. Address Learning 524 This section updates section 4.2. of [RFC4762]. 526 A Leaf PE MUST support the ability to perform MAC address learning 527 for packets received on a P2MP PW. 529 When a Leaf PE receives an Ethernet frame on a P2MP PW it: 530 - First determines the VSI associated to the P2MP PW 531 - Then determines the Root PE of the P2MP PW 532 - Then determines the P2P PW associated with that Root PE 533 - Finally, creates a forwarding state in the VPLS instance for 534 the P2P PW associated with the Root PE with a destination 535 MAC address being the same as the source MAC address being 536 learned. 538 5.7. Loop Free Topology 540 This updates section 4.4. of [RFC4762] 542 Paragraph 2 "must not forward from one PW to another" is applicable 543 to P2MP PW & P2P PW. 545 5.8. Hierarchical VPLS 547 This refers to section 10 and 11 in [RFC4762]. No change is required. 549 5.9 P2MP PW Status 551 In case of a P2MP PW status change to not operational as per 552 [P2MP-PW-LDP], then this should be treated as if this P2MP PW does 553 not exist. 555 6. Local PE Implementation 557 This section is OPTIONAL. 559 As described in section 2.1.1, a PE receiving an IP multicast frame, 560 will forward it to all ACs, including those with no member of the 561 specific IP multicast group attached. 563 Unnecessary traffic consumes bandwidth on the access link and may 564 become a concern from the customer perspective. In some cases, it may 565 also be a security concern as the multicast frame may be forwarded to 566 an endpoint other than the intended destinations. 568 Consequently, the use of some L3 related supplementary information in 569 order to improve bandwidth consumption on the AC may be considered. 570 Enabling L3 snooping on an AC basis only has an impact on the PE 571 where the AC belongs, it does not impact the number of P2MP PW/LSPs 572 used within the carrier's network and the state resources or the 573 maintenance complexity associated with it. 575 Alternatives to L3 snooping such as static configuration of multicast 576 Ethernet addresses & ports / interfaces for example are also 577 possible. 579 7. Security Considerations 581 This document does not introduce any new security issues beyond those 582 already described in [RFC4762]. 584 8. IANA Considerations 586 This document does not require IANA assignment. 588 9. Acknowledgments 590 The authors would like to thank Marc Lasserre, Cesar Garrido, Lucy 591 Yong, Neil Harrison, Samer Salam, Nocolai Leymann, Florin Balus, Olen 592 Stokes, Ali Sajassi, Phil Bedard, Thomas Beckhaus, Linda Dunbar, Max 593 Ng, Asaf Henig, Mark Whalley and Cary Wright for their valuable 594 comments. 596 10. References 598 10.1. Normative References 600 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 601 Requirement Levels", BCP 14, RFC 2119, March 1997. 603 [RFC4762] Lasserre & Kompella, "Virtual Private LAN Service (VPLS) 604 Using Label Distribution Protocol (LDP) Signaling", 605 RFC 4762, January 2007. 607 [P2MP-PW-LDP] Sivabalan, et. al, "Signaling Root-Initiated 608 Point-to-Multipoint Pseudowires using LDP", 609 draft-ietf-pwe3-p2mp-pw-04, work in Progress, 610 March 2012. 612 [RFC6388] Wijnands, et. al, "Label Distribution Protocol Extensions 613 for Point-to-Multipoint and Multipoint-to-Multipoint Label 614 Switched Paths", RFC 6388, November 2011. 616 [RFC4875] R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed., 617 "Extensions to Resource Reservation Protocol - Traffic 618 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 619 Switched Paths (LSPs)", RFC 4875, May 2007. 621 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 622 Assignment and Context Specific Label Space", RFC 5331, 623 August 2008. 625 10.2. Informative References 627 [RFC5501] Kamite, et al., "Requirements for Multicast Support in 628 Virtual Private LAN Services", RFC 5501, March 2009. 630 [P2MP-PW-REQ] Jounay, et. al, "Requirements and Framework for 631 Point-to-Multipoint Pseudowires over MPLS PSNs", 632 draft-ietf-pwe3-p2mp-pw-requirements-06, work in 633 progress, October 2013. 635 [VPLS-Multicast-BGP] Raggarwa, Kamite & Fang, "Multicast in VPLS", 636 draft-ietf-l2vpn-vpls-mcast-16, work in 637 progress, November 2013. 639 [RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for 640 Layer 2 Provider-Provisioned Virtual Private Networks", 641 RFC 4665, September 2006. 643 Author's Addresses 645 Simon Delord (editor) 646 Telstra 647 Email: simon.delord@gmail.com 649 Raymond Key (editor) 650 Email: raymond.key@ieee.org 652 Frederic Jounay 653 Orange CH 654 4 rue caudray 1020 Renens 655 Switzerland 656 Email: frederic.jounay@orange.ch 658 Yuji Kamite 659 NTT Communications Corporation 660 Granpark Tower 661 3-4-1 Shibaura, Minato-ku 662 Tokyo 108-8118 663 Japan 664 Email: y.kamite@ntt.com 666 Zhihua Liu 667 China Telecom 668 109 Zhongshan Ave. 669 Guangzhou 510630 670 China 671 Email: zhliu@gsta.com 673 Manuel Paul 674 Deutsche Telekom 675 Winterfeldtstr. 21-27 676 10781 Berlin, Germany 677 Email: manuel.paul@telekom.de 679 Ruediger Kunze 680 Deutsche Telekom 681 Winterfeldtstr. 21-27 682 10781 Berlin, Germany 683 Email: ruediger.kunze@telekom.de 685 Mach(Guoyi) Chen 686 Huawei Technology Co., Ltd. 687 Q14 Huawei Campus, No. 156 Beiqing Road 688 Hai-dian District, Beijing 100095 689 China 690 Email: mach.chen@huawei.com 692 Lizhong Jin 693 Email: lizho.jin@gmail.com 695 Appendix A. One example for broadcast video delivery 697 This section describes one deployment scenario in relation to 698 broadcast video delivery and how the proposed solution would work. 700 One requirement of the model is that the application needs unicast 701 data exchange (IP unicast transfer or control messages etc.) as a 702 background environment. MAC-learning (and therefore VPLS) is 703 effective to support it. 705 A.1. Broadcast Video Delivery Topology 707 Figure 3 presents the physical topology of one broadcast video 708 deployment. 710 | | | 711 AC AC AC 712 | | | 713 +---+ +---+ +---+ 714 |PE3| |PE4| |PE5| 715 +---+ +---+ +---+ 716 \ | / 717 \ | / +----+ 718 \ | / +---|PE9 |--AC-- 719 \ | / / +----+ 720 Ethernet +---+ +---+ +---+/ +----+ 721 Broadcast->-AC--|PE1|----------|P1 |--------|P3 |------|PE10|--AC-- 722 Source +---+\ /+---+ +---+\ +----+ 723 \ / | | \ +----+ 724 \ / | | +---|PE11|--AC-- 725 \ / | | +----+ 726 \/ | | 727 /\ | | 728 / \ | | +----+ 729 / \ | | +---|PE12|--AC-- 730 / \ | | / +----+ 731 Ethernet +---+/ \+---+ +---+/ +----+ 732 Broadcast->-AC--|PE2|----------|P2 |--------|P4 |------|PE13|--AC-- 733 Source +---+ +---+ +---+\ +----+ 734 / | \ \ +----+ 735 / | \ +---|PE14|--AC-- 736 / | \ +----+ 737 / | \ 738 +---+ +---+ +---+ 739 |PE6| |PE7| |PE8| 740 +---+ +---+ +---+ 741 | | | 742 AC AC AC 743 | | | 745 Figure 3 - Physical Topology for Broadcast video 747 Figure 3 is split in three logical components: 749 - The Core network composed of P1, P2, P3 & P4. These 4 network 750 elements are P routers connected in a ring. 752 - The Data Centers. These are a few large PoPs with high resiliency 753 that hold the video content. PE1 & PE2 are located in one Data 754 Center and are dual-homed to the core network. An Ethernet 755 broadcast source is connected to each PE in the Data Center. 757 - The Aggregation network. The Aggregation network is responsible 758 for aggregating last mile technology towards endusers (direct 759 fiber, GPON, DSL, etc.). PE3, PE4, until PE14 are VPLS PE routers 760 in an aggregation PoP and single-homed to the Core network. 762 There are two different video distribution services organised as 763 follows: 765 - PE1 is connected to PE3, PE4, ... PE14 via VPLS instance-1. 766 - One Ethernet broadcast source is connected to PE1 into VPLS 767 instance-1. 768 - PE2 is connected to PE3, PE4 ...PE14 via VPLS instance-2. 769 - One Ethernet broadcast source is connected to PE2 into VPLS 770 instance-2. 772 A.2. Impact of Physical Topologies on Ethernet Broadcast/multicast 773 replication 775 Following the standard VPLS flooding mechanism, each time PE1 776 receives one broadcast frame from the Ethernet broadcast source on 777 VPLS-1, PE1 will replicate 12 times the incoming frame. 779 Similarly, each time PE2 receives one broadcast frame from the 780 Ethernet broadcast source on VPLS-2, PE2 will replicate 12 times the 781 incoming frame. 783 A.3. Proposed enhancement of Ethernet broadcast/multicast 785 The proposed enhancements are done in three steps: 787 - create P2MP LSPs for the infrastructure. These P2MP LSPs are 788 used to carry one or more P2MP PWs. 790 - create unidirectional P2MP PWs by selectively choosing PEs where 791 the optimisation should occur. 793 - forward Ethernet broadcast/multicast frames onto the P2MP PWs 794 where these P2MP PWs have been created. 796 It is up to the network operator to decide how the distribution of 797 the loading on physical link should occur. 799 Two different examples are presented below. 801 A.3.1. One possible enhancement scenario 803 A.3.1.1. Initial Deployment 805 In this scenario, the operator decides to create the following P2MP 806 LSPs: 808 - PE1->PE3-5 via P1 called LSP1 809 - PE1->PE6-8 via P2 called LSP2 810 - PE1->PE9-11 via P3 called LSP3 812 - PE2->PE3-5 via P1 called LSP4 813 - PE2->PE6-8 via P2 called LSP5 814 - PE2->PE9-11 via P3 called LSP6 816 The operator then creates the following P2MP PWs: 818 - PE1->PE3-5 via P2MP PW1 over LSP1 819 - PE1->PE6-8 via P2MP PW2 over LSP2 820 - PE1->PE9-11 via P2MP PW3 over LSP3 822 - PE2->PE3-5 via P2MP PW4 over LSP4 823 - PE2->PE6-8 via P2MP PW5 over LSP5 824 - PE2->PE9-11 via P2MP PW6 over LSP6 826 There is no P2MP PWs between PE1 and PE12, PE13 and PE14. 827 There is no P2MP PWs between PE2 and PE12, PE13 and PE14. 829 There are several reasons why a P2MP PW may not be available on this 830 part of the network (e.g. PE12, PE13 and PE14), for example: 832 - the hardware/software may not allow the support of the 833 required features (P2MP LSPs and/or P2MP PWs). 834 - the operator does not need to improve multicast/broadcast 835 services there (e.g. no specific bandwidth issue). 836 - the operator is currently under a migration phase where only 837 part of the network is migrated at a time. 839 In this case, when PE1 receives one broadcast frame from the 840 Ethernet broadcast source on VPLS-1: 841 - PE1 sends one copy of the broadcast frame onto P2MP PW1 842 - PE1 sends one copy of the broadcast frame onto P2MP PW2 843 - PE1 sends one copy of the broadcast frame onto P2MP PW3 844 - PE1 sends one copy onto the P2P PW towards PE12 845 - PE1 sends one copy onto the P2P PW towards PE13 846 - PE1 sends one copy onto the P2P PW towards PE14 848 PE1 only replicates 6 copies now (this is an improvement from 12 849 copies if only using P2P PWs). 851 A.3.1.2 Multiple P2MP PWs 853 Let's assume now that a new broadcast service is targeted at covering 854 endusers geographically connected to PE9, PE10 and PE11. 856 For example, this could be a wholesale service, where another carrier 857 with limited footprint for the region covered by PE9, PE10 and PE11 858 is seeking access for deploying its own broadcast application. 860 Based on the proposal in this document, and assuming that the 861 application also needs unicast data exchange, if the new broadcast 862 source is connected to PE1, it is then possible to: 864 - Create a new VPLS instance on PE1, PE9, PE10 and PE11 and a full- 865 mesh of P2P PWs between all 4 PEs. 867 - Build a new P2MP PW, called P2MP PW7 between PE1, PE9, PE10 & PE11 868 that uses the existing P2MP LSP - LSP3. 870 This proposal allows for both P2MP PW3 and P2MP PW7 to be carried 871 through a single MPLS P2MP tunnel, thus, removing the need to 872 maintain state in the network core for individual P2MP PWs. The P 873 routers in the core only need to be aware of the P2MP LSPs. 875 A.3.2. Another possible enhancement scenario 877 In this scenario, the operator decides to create the following two 878 P2MP LSPs: 880 - PE1-> PE3-14 via LSP1: 881 - P1 as a branch towards PE3, PE4, PE5, P2 and P3 882 - P2 as a branch towards PE6, PE7, PE8 and P4 883 - P3 as a branch towards PE9, PE10 and PE11 884 - P4 as a branch towards PE12, PE13 and PE14 886 - PE2-> PE3-14 via LSP2: 887 - P2 as a branch towards PE6, PE7, PE8, P1 and P4 888 - P1 as a branch towards PE3, PE4, PE5 and P3 889 - P3 as a branch towards PE9, PE10 and PE11 890 - P4 as a branch towards PE12, PE13 and PE14 892 The operator then creates the following P2MP PWs: 894 - PE1-> PE3-14 via P2MP PW1 over LSP1 895 - PE2-> PE3-14 via P2MP PW2 over LSP2 897 This case improves the P2P PW scenario as PE1 only replicates a 898 single copy of the broadcast frame received from the Ethernet 899 broadcast source. 901 Copyright Notice 903 Copyright (c) 2014 IETF Trust and the persons identified as the 904 document authors. All rights reserved. 906 This document is subject to BCP 78 and the IETF Trust's Legal 907 Provisions Relating to IETF Documents 908 (http://trustee.ietf.org/license-info) in effect on the date of 909 publication of this document. Please review these documents 910 carefully, as they describe your rights and restrictions with respect 911 to this document. Code Components extracted from this document must 912 include Simplified BSD License text as described in Section 4.e of 913 the Trust Legal Provisions and are provided without warranty as 914 described in the Simplified BSD License.