idnits 2.17.1 draft-ietf-l2vpn-ldp-vpls-broadcast-exten-08.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 28, 2014) is 3590 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) 4 Category: Standard Track Frederic Jounay, Orange CH 5 Expires: December 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 June 28, 2014 14 Extension to LDP-VPLS for Ethernet Broadcast and Multicast 15 draft-ietf-l2vpn-ldp-vpls-broadcast-exten-08 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 28, 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 [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 238 [P2MP-PW-REQ]. 240 4. Relevant IETF technologies for the proposed solution 242 The proposed solution relies on [RFC4762] existing mechanisms and 243 complements them with extensions (P2MP LSPs and P2MP PWs) already 244 standardised ([RFC4875]) or currently under development by the IETF 245 ([RFC6388] and [P2MP-PW-LDP]). 247 4.1. P2MP LSPs 249 Similarly to what is defined in [RFC4762] where P2P PWs are 250 multiplexed onto P2P LSPs, before the operator can start deploying 251 P2MP PWs, an appropriate underlying layer made of P2MP LPSs needs to 252 be configured (section 3.2 of [P2MP-PW-REQ]). 254 P2MP LSPs are used to minimise packet replication on specific 255 physical links and to allow P routers in an MPLS domain to be 256 transparent to services (e.g. a P Router will join the P2MP PSN 257 tunnel operation but will have no knowledge of the P2MP PWs, same 258 as [RFC4762]). 260 The mapping of the P2MP LSP over the physical topology is a 261 key component of the bandwidth enhancement exercise and the operator 262 needs to carefully consider where and how these P2MP LSPs should be 263 deployed (see Appendix A for an example of a possible deployment). 265 Once configured, it is then possible to aggregate P2MP PWs over a 266 particular P2MP LSP (similar to [RFC4762]). 268 4.2. P2MP PWs 270 P2MP PWs can be configured statically (e.g. by the operator) or via 271 LDP on top of the P2MP LSPs. This configuration is done on a per PE 272 per VPLS instance basis. 274 In a P2MP PW, the operator decides to connect one Root PE to at least 275 two Leaf PEs (section 3.1 of [P2MP-PW-REQ]). 277 The Root PE is the headend of the P2MP PW (where a big Ethernet 278 multicast/broadcast talker is connected - see example in Appendix A). 280 The Leaf PEs are the endpoints of the P2MP PW (they constitute 281 the receivers where the broadcast/multicast traffic needs to be 282 distributed to). 284 A Root PE may map more than one P2MP PW to a specific VPLS instance. 285 In this case, the Root PE MUST NOT associate a leaf PE to more than 286 one P2MP PW for a specific VPLS instance (this is to avoid a Leaf PE 287 to receive duplicate copies of the same Ethernet frame from different 288 P2MP PWs). 290 P2MP PWs are defined in [P2MP-PW-REQ] and one solution using LDP as 291 the signalling mechanism between PEs is defined in [P2MP-PW-LDP]. 293 5. Proposed extension to [RFC4762] 295 This section updates [RFC4762] by describing the extra rules to be 296 applied within a VPLS when unidirectional P2MP PWs are added to the 297 existing full-mesh of P2P PWs. 299 5.1. VPLS Reference Model 301 Figure 1 shows a topological model (not the physical topology) 302 of a VPLS between four PEs with an arbitrary set of ACs attached to 303 each VSI. 305 +---------+ +---------+ 306 | PE1 | | PE2 | 307 | +---+ | | +---+ | 308 | | | | | | +-------AC4--- 309 | | V | | | | V | | 310 | | | | | | | | 311 ----AC1----+--+ | | Ethernet | | +--+----AC5--- 312 | | S +--+-----PW-----+--+ S | | 313 | | | | | | | | 314 ----AC2----+--+ | | | | | | 315 | | I | | | | I | | 316 | | | | Ethernet | | | | 317 ----AC3----+--+ | | PW +-----+--+ | | 318 | +-+-+ | / | +-+-+ | 319 | | \ | / | | | 320 +----+---\+ / +----+----+ 321 | \ / | 322 Ethernet| \/ |Ethernet 323 PW| /\ |PW 324 | / \Ethernet | 325 +----+---/+ \PW +----+----+ 326 |PE3 | / | \ |PE4 | | 327 | +-+-+ | \ | +-+-+ | 328 ----AC6----+--+ | | \ | | +--+----AC8---- 329 | | V | | +----+--+ V | | 330 | | | | | | | | 331 ----AC7----+--+ | | Ethernet | | +--+----AC9---- 332 | | S +--+-----PW-----+--+ S | | 333 | | | | | | | | 334 | | | | | | | | 335 | | I | | | | I | | 336 | | | | | | | | 337 | | | | | | | | 338 | +---+ | | +---+ | 339 | | | | 340 +---------+ +---------+ 342 Figure 1: Reference Diagram for VPLS 344 Figure 2 shows the proposed extensions to VPLS for Ethernet broadcast 345 and multicast. On top of the topology presented in Figure 2, two 346 P2MP PWs have been added to the existing set of P2P PWs. 348 +---------+ +---------+ 349 | PE1 | | PE2 | 350 | +---+ | | +---+ | 351 | | | | | | +-------AC4--- 352 | | V | | Ethernet | | V | | 353 | | | | P2MP | | | | 354 ----AC1----+--+ | | PW1 | | +--+----AC5--- 355 | | S +--+->--+-->----+--+ S | | 356 | | | | | | | | | 357 ----AC2----+--+ | | | | | | | 358 | | I | | | +->-+--+ I | | 359 | | | | | | | | | | 360 ----AC3----+--+ | | | | | | | | 361 | +---+ | | | | +---+ | 362 | | | | | | 363 +---------+ | | +---------+ 364 | | 365 | | 366 | | 367 | | 368 +---------+ | | +---------+ 369 |PE3 | | | |PE4 | 370 | +---+ | | | | +---+ | 371 ----AC6----+--+ | | +->-----+--+ +--+----AC8---- 372 | | V | | | | | V | | 373 | | | | | | | | | 374 ----AC7----+--+ | | | | | +--+----AC9---- 375 | | S +--+->------+->-+--+ S | | 376 | | | | Ethernet | | | | 377 | | | | P2MP | | | | 378 | | I | | PW2 | | I | | 379 | | | | | | | | 380 | | | | | | | | 381 | +---+ | | +---+ | 382 | | | | 383 +---------+ +---------+ 385 Figure 2: Proposed Extensions to VPLS for Ethernet broadcast/multicast 387 P2MP PW1 is composed of PE1 as the root PE and PE2 and PE4 as leaf 388 PEs. 390 P2MP PW2 is composed of PE3 as the root PE and PE2 and PE4 as leaf 391 PEs. 393 Note that for sake of clarity, Figure 2 does not show the full-mesh 394 of P2P PWs presented in Figure 1. 396 Also note that the solution does not require that P2MP PWs be used on 397 all PEs in the VPLS. For example, PE3 is not leaf of P2MP PW1 and PE1 398 is not leaf of P2MP PW2 and therefore, there is only a P2P PW between 399 PE1 and PE3, and a P2P PW between PE2 and PE4. 401 5.2. Choosing PEs for a specific VPLS to be connected by a P2MP PW 403 This updates section 4.3 of [RFC4762]. 405 VPLS is a full-mesh of P2P PWs and optionally a number of 406 unidirectional P2MP PWs. At the difference of P2P PWs, not all PEs in 407 a VPLS instance need to be connected via P2MP PWs. 409 For each P2MP PW on this VPLS instance: 411 - The operator selects one PE as the Root of the P2MP PW. 413 - The operator also selects two or more PEs belonging to the same 414 VPLS instance to be Leafs of the P2MP PW 416 - Because there is already a full-mesh of bidirectional P2P PWs 417 between all PEs, the P2MP PW is unidirectional only (e.g. from 418 the Root PE to all the Leaf PEs connected to it). 420 - The operator also needs to make sure that there is an active P2MP 421 LSP setup between the Root PE and the Leaf PEs: 423 - If there is already an active P2MP LSP setup between the Root 424 PE and the Leaf PEs, then procedures described in 5.3 can be 425 followed. 427 - If there is no P2MP LSP between the Root PE and the Leaf PEs 428 then the operator needs to create first a P2MP LSP in order for 429 procedures in 5.3 to be followed. Procedures to setup a P2MP LSP 430 will vary based on the technology used and are described in 431 [RFC6388] and [RFC4875]. 433 5.3. Create and associate the P2MP PW to a specific VPLS Instance 435 This updates section 4.3 of [RFC4762]. 437 Once that the endpoints of the P2MP PW have been selected and that 438 there is an active P2MP LSP between them, the operator can then 439 create and associate the P2MP PW to a specific VPLS instance. 440 This activity can be done statically or via LDP [P2MP-PW-LDP]. 442 Because P2MP PWs are used to demultiplex encapsulated Ethernet frames 443 from multiple VPLS instances that are aggregated over the same P2MP 444 transport LSP, it is necessary that a Leaf PE can associate 445 unambiguously a P2MP PW aggregated within a P2MP LSP to both a 446 specific VPLS instance and a Root PE. 448 In the static case, the operator is responsible for configuring all 449 the required information on all PEs belonging to the P2MP PW. 451 In the LDP case, the P2MP PW is initiated by the Root PE by sending a 452 P2MP PW LDP Label Mapping Message to each of the Leaf PEs. 454 This label mapping contains, the VPLS instance the P2MP PW is 455 associated to, the P2MP LSP used to transport the P2MP PW and the 456 P2MP PW MPLS Label. 458 The P2MP PW MPLS Label is upstream assigned and allocated according 459 to the rules in [RFC5331]. 461 The root PE imposes the upstream-assigned label on the outbound 462 packets sent over the P2MP-PW and using this label a Leaf PE can 463 identify the inbound packets arriving over the P2MP PW. 465 Detailed LDP message formats and P2MP PW setup procedures are 466 described in [P2MP-PW-LDP]. 468 5.4. Mapping more than one P2MP PW to a specific VPLS Instance on a 469 specific Root PE 471 The proposed solution allows for a Root PE to map more than one P2MP 472 PW to a specific VPLS instance (see example in Appendix A). 474 However in this case, the Root PE MUST NOT associate a leaf PE to 475 more than one P2MP PW for a specific VPLS instance (this is to avoid 476 a Leaf PE to receive duplicate copies of the same Ethernet frame from 477 different P2MP PWs). 479 5.5. Flooding and Forwarding 481 This section updates section 4.1. of [RFC4762]. 483 A root PE MUST NOT flood frames simultaneously over P2MP PW and P2P 484 PW toward the same leaf PE. 486 For the flooding of an Ethernet broadcast/multicast frame over PWs to 487 remote PEs participating in the VPLS: 489 - If there is P2MP PW towards a remote PE, the P2P PW 490 associated with this remote PE will not be used. One copy 491 of the frame will be forwarded on the P2MP PW for all the 492 remote PEs associated with it. 493 - If there is no P2MP PW towards a remote PE, the P2P PW 494 associated with this remote PE is used. 496 It should be noted that local policy on the Root PE at the operator's 497 operational request can override any decision to flood and forward 498 traffic over a P2MP PW for a VPLS instance. In that case, normal 499 flooding procedures over P2P PWs described in 4.1 of [RFC4762] apply. 501 5.5.1. Flooding and Forwarding for Ethernet unknown unicast 503 In traditional Ethernet switched networks unknown unicast frames are 504 handled the same way as broadcast and multicast Ethernet traffic 505 (e.g. flooding). Similarly, current VPLS standards also handle 506 unknown unicast traffic by flooding it across all P2P PWs. 508 The main purpose of this document is to address Ethernet broadcast 509 and multicast traffic. For Ethernet unknown unicast frames there are 510 two possibilities: 512 (1) forward the unknown unicast traffic on the P2MP PW, same as for 513 Ethernet broadcast and multicast. 514 (2) keep the existing mechanism of [RFC4762] and flood over the mesh 515 of P2P PWs. 517 A Root PE SHOULD support both the above as configurable options per 518 VPLS instance. For a particular VPLS instance where frame reordering 519 is considered unacceptable, option (2) is recommended. 521 5.6. Address Learning 523 This section updates section 4.2. of [RFC4762]. 525 A Leaf PE MUST support the ability to perform MAC address learning 526 for packets received on a P2MP PW. 528 When a Leaf PE receives an Ethernet frame on a P2MP PW it: 529 - First determines the VSI associated to the P2MP PW 530 - Then determines the Root PE of the P2MP PW 531 - Then determines the P2P PW associated with that Root PE 532 - Finally, creates a forwarding state in the VPLS instance for 533 the P2P PW associated with the Root PE with a destination 534 MAC address being the same as the source MAC address being 535 learned. 537 5.7. Loop Free Topology 539 This updates section 4.4. of [RFC4762] 541 Paragraph 2 "must not forward from one PW to another" is applicable 542 to P2MP PW & P2P PW. 544 5.8. Hierarchical VPLS 546 This refers to section 10 and 11 in [RFC4762]. No change is required. 548 5.9 P2MP PW Status 550 In case of a P2MP PW status change to not operational as per 551 [P2MP-PW-LDP], then this should be treated as if this P2MP PW does 552 not exist. 554 6. Local PE Implementation 556 This section is OPTIONAL. 558 As described in section 2.1.1, a PE receiving an IP multicast frame, 559 will forward it to all ACs, including those with no member of the 560 specific IP multicast group attached. 562 Unnecessary traffic consumes bandwidth on the access link and may 563 become a concern from the customer perspective. In some cases, it may 564 also be a security concern as the multicast frame may be forwarded to 565 an endpoint other than the intended destinations. 567 Consequently, the use of some L3 related supplementary information in 568 order to improve bandwidth consumption on the AC may be considered. 569 Enabling L3 snooping on an AC basis only has an impact on the PE 570 where the AC belongs, it does not impact the number of P2MP PW/LSPs 571 used within the carrier's network and the state resources or the 572 maintenance complexity associated with it. 574 Alternatives to L3 snooping such as static configuration of multicast 575 Ethernet addresses & ports / interfaces for example are also 576 possible. 578 7. Security Considerations 580 This document does not introduce any new security issues beyond those 581 already described in [RFC4762]. 583 8. IANA Considerations 585 This document does not require IANA assignment. 587 9. Acknowledgments 589 The authors would like to thank Marc Lasserre, Cesar Garrido, Lucy 590 Yong, Neil Harrison, Samer Salam, Nocolai Leymann, Florin Balus, Olen 591 Stokes, Ali Sajassi, Phil Bedard, Thomas Beckhaus, Linda Dunbar, Max 592 Ng, Asaf Henig, Mark Whalley and Cary Wright for their valuable 593 comments. 595 10. References 597 10.1. Normative References 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, March 1997. 602 [RFC4762] Lasserre & Kompella, "Virtual Private LAN Service (VPLS) 603 Using Label Distribution Protocol (LDP) Signaling", 604 RFC 4762, January 2007. 606 [P2MP-PW-LDP] Sivabalan, et. al, "Signaling Root-Initiated 607 Point-to-Multipoint Pseudowires using LDP", 608 draft-ietf-pwe3-p2mp-pw-04, work in Progress, 609 March 2012. 611 [RFC6388] Wijnands, et. al, "Label Distribution Protocol Extensions 612 for Point-to-Multipoint and Multipoint-to-Multipoint Label 613 Switched Paths", RFC 6388, November 2011. 615 [RFC4875] R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed., 616 "Extensions to Resource Reservation Protocol - Traffic 617 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 618 Switched Paths (LSPs)", RFC 4875, May 2007. 620 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 621 Assignment and Context Specific Label Space", RFC 5331, 622 August 2008. 624 10.2. Informative References 626 [RFC5501] Kamite, et al., "Requirements for Multicast Support in 627 Virtual Private LAN Services", RFC 5501, March 2009. 629 [P2MP-PW-REQ] Jounay, et. al, "Requirements and Framework for 630 Point-to-Multipoint Pseudowires over MPLS PSNs", 631 draft-ietf-pwe3-p2mp-pw-requirements-10, work in 632 progress, June 2014. 634 [RFC7117] Raggarwa, Kamite & Fang, "Multicast in VPLS", RFC 7117, 635 February 2014. 637 [RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for 638 Layer 2 Provider-Provisioned Virtual Private Networks", 639 RFC 4665, September 2006. 641 Author's Addresses 643 Simon Delord (editor) 644 Telstra 645 EMail: simon.delord@gmail.com 647 Raymond Key (editor) 648 EMail: raymond.key@ieee.org 650 Frederic Jounay 651 Orange CH 652 4 rue caudray 1020 Renens 653 Switzerland 654 EMail: frederic.jounay@orange.ch 656 Yuji Kamite 657 NTT Communications Corporation 658 Granpark Tower 659 3-4-1 Shibaura, Minato-ku 660 Tokyo 108-8118 661 Japan 662 EMail: y.kamite@ntt.com 664 Zhihua Liu 665 China Telecom 666 109 Zhongshan Ave. 667 Guangzhou 510630 668 China 669 EMail: zhliu@gsta.com 671 Manuel Paul 672 Deutsche Telekom 673 Winterfeldtstr. 21-27 674 10781 Berlin, Germany 675 EMail: manuel.paul@telekom.de 677 Ruediger Kunze 678 Deutsche Telekom 679 Winterfeldtstr. 21-27 680 10781 Berlin, Germany 681 EMail: ruediger.kunze@telekom.de 683 Mach(Guoyi) Chen 684 Huawei Technology Co., Ltd. 685 Q14 Huawei Campus, No. 156 Beiqing Road 686 Hai-dian District, Beijing 100095 687 China 688 EMail: mach.chen@huawei.com 690 Lizhong Jin 691 EMail: lizho.jin@gmail.com 693 Appendix A. One example for broadcast video delivery 695 This section describes one deployment scenario in relation to 696 broadcast video delivery and how the proposed solution would work. 698 One requirement of the model is that the application needs unicast 699 data exchange (IP unicast transfer or control messages etc.) as a 700 background environment. MAC-learning (and therefore VPLS) is 701 effective to support it. 703 A.1. Broadcast Video Delivery Topology 705 Figure 3 presents the physical topology of one broadcast video 706 deployment. 708 | | | 709 AC AC AC 710 | | | 711 +---+ +---+ +---+ 712 |PE3| |PE4| |PE5| 713 +---+ +---+ +---+ 714 \ | / 715 \ | / +----+ 716 \ | / +---|PE9 |--AC-- 717 \ | / / +----+ 718 Ethernet +---+ +---+ +---+/ +----+ 719 Broadcast->-AC--|PE1|----------|P1 |--------|P3 |------|PE10|--AC-- 720 Source +---+\ /+---+ +---+\ +----+ 721 \ / | | \ +----+ 722 \ / | | +---|PE11|--AC-- 723 \ / | | +----+ 724 \/ | | 725 /\ | | 726 / \ | | +----+ 727 / \ | | +---|PE12|--AC-- 728 / \ | | / +----+ 729 Ethernet +---+/ \+---+ +---+/ +----+ 730 Broadcast->-AC--|PE2|----------|P2 |--------|P4 |------|PE13|--AC-- 731 Source +---+ +---+ +---+\ +----+ 732 / | \ \ +----+ 733 / | \ +---|PE14|--AC-- 734 / | \ +----+ 735 / | \ 736 +---+ +---+ +---+ 737 |PE6| |PE7| |PE8| 738 +---+ +---+ +---+ 739 | | | 740 AC AC AC 741 | | | 743 Figure 3 - Physical Topology for Broadcast video 745 Figure 3 is split in three logical components: 747 - The Core network composed of P1, P2, P3 & P4. These 4 network 748 elements are P routers connected in a ring. 750 - The Data Centers. These are a few large PoPs with high resiliency 751 that hold the video content. PE1 & PE2 are located in one Data 752 Center and are dual-homed to the core network. An Ethernet 753 broadcast source is connected to each PE in the Data Center. 755 - The Aggregation network. The Aggregation network is responsible 756 for aggregating last mile technology towards endusers (direct 757 fiber, GPON, DSL, etc.). PE3, PE4, until PE14 are VPLS PE routers 758 in an aggregation PoP and single-homed to the Core network. 760 There are two different video distribution services organised as 761 follows: 763 - PE1 is connected to PE3, PE4, ... PE14 via VPLS instance-1. 764 - One Ethernet broadcast source is connected to PE1 into VPLS 765 instance-1. 766 - PE2 is connected to PE3, PE4 ...PE14 via VPLS instance-2. 767 - One Ethernet broadcast source is connected to PE2 into VPLS 768 instance-2. 770 A.2. Impact of Physical Topologies on Ethernet Broadcast/multicast 771 replication 773 Following the standard VPLS flooding mechanism, each time PE1 774 receives one broadcast frame from the Ethernet broadcast source on 775 VPLS-1, PE1 will replicate 12 times the incoming frame. 777 Similarly, each time PE2 receives one broadcast frame from the 778 Ethernet broadcast source on VPLS-2, PE2 will replicate 12 times the 779 incoming frame. 781 A.3. Proposed enhancement of Ethernet broadcast/multicast 783 The proposed enhancements are done in three steps: 785 - create P2MP LSPs for the infrastructure. These P2MP LSPs are 786 used to carry one or more P2MP PWs. 788 - create unidirectional P2MP PWs by selectively choosing PEs where 789 the optimisation should occur. 791 - forward Ethernet broadcast/multicast frames onto the P2MP PWs 792 where these P2MP PWs have been created. 794 It is up to the network operator to decide how the distribution of 795 the loading on physical link should occur. 797 Two different examples are presented below. 799 A.3.1. One possible enhancement scenario 801 A.3.1.1. Initial Deployment 803 In this scenario, the operator decides to create the following P2MP 804 LSPs: 806 - PE1->PE3-5 via P1 called LSP1 807 - PE1->PE6-8 via P2 called LSP2 808 - PE1->PE9-11 via P3 called LSP3 810 - PE2->PE3-5 via P1 called LSP4 811 - PE2->PE6-8 via P2 called LSP5 812 - PE2->PE9-11 via P3 called LSP6 814 The operator then creates the following P2MP PWs: 816 - PE1->PE3-5 via P2MP PW1 over LSP1 817 - PE1->PE6-8 via P2MP PW2 over LSP2 818 - PE1->PE9-11 via P2MP PW3 over LSP3 820 - PE2->PE3-5 via P2MP PW4 over LSP4 821 - PE2->PE6-8 via P2MP PW5 over LSP5 822 - PE2->PE9-11 via P2MP PW6 over LSP6 824 There is no P2MP PWs between PE1 and PE12, PE13 and PE14. 825 There is no P2MP PWs between PE2 and PE12, PE13 and PE14. 827 There are several reasons why a P2MP PW may not be available on this 828 part of the network (e.g. PE12, PE13 and PE14), for example: 830 - the hardware/software may not allow the support of the 831 required features (P2MP LSPs and/or P2MP PWs). 832 - the operator does not need to improve multicast/broadcast 833 services there (e.g. no specific bandwidth issue). 834 - the operator is currently under a migration phase where only 835 part of the network is migrated at a time. 837 In this case, when PE1 receives one broadcast frame from the 838 Ethernet broadcast source on VPLS-1: 839 - PE1 sends one copy of the broadcast frame onto P2MP PW1 840 - PE1 sends one copy of the broadcast frame onto P2MP PW2 841 - PE1 sends one copy of the broadcast frame onto P2MP PW3 842 - PE1 sends one copy onto the P2P PW towards PE12 843 - PE1 sends one copy onto the P2P PW towards PE13 844 - PE1 sends one copy onto the P2P PW towards PE14 846 PE1 only replicates 6 copies now (this is an improvement from 12 847 copies if only using P2P PWs). 849 A.3.1.2 Multiple P2MP PWs 851 Let's assume now that a new broadcast service is targeted at covering 852 endusers geographically connected to PE9, PE10 and PE11. 854 For example, this could be a wholesale service, where another carrier 855 with limited footprint for the region covered by PE9, PE10 and PE11 856 is seeking access for deploying its own broadcast application. 858 Based on the proposal in this document, and assuming that the 859 application also needs unicast data exchange, if the new broadcast 860 source is connected to PE1, it is then possible to: 862 - Create a new VPLS instance on PE1, PE9, PE10 and PE11 and a full- 863 mesh of P2P PWs between all 4 PEs. 865 - Build a new P2MP PW, called P2MP PW7 between PE1, PE9, PE10 & PE11 866 that uses the existing P2MP LSP - LSP3. 868 This proposal allows for both P2MP PW3 and P2MP PW7 to be carried 869 through a single MPLS P2MP tunnel, thus, removing the need to 870 maintain state in the network core for individual P2MP PWs. The P 871 routers in the core only need to be aware of the P2MP LSPs. 873 A.3.2. Another possible enhancement scenario 875 In this scenario, the operator decides to create the following two 876 P2MP LSPs: 878 - PE1-> PE3-14 via LSP1: 879 - P1 as a branch towards PE3, PE4, PE5, P2 and P3 880 - P2 as a branch towards PE6, PE7, PE8 and P4 881 - P3 as a branch towards PE9, PE10 and PE11 882 - P4 as a branch towards PE12, PE13 and PE14 884 - PE2-> PE3-14 via LSP2: 885 - P2 as a branch towards PE6, PE7, PE8, P1 and P4 886 - P1 as a branch towards PE3, PE4, PE5 and P3 887 - P3 as a branch towards PE9, PE10 and PE11 888 - P4 as a branch towards PE12, PE13 and PE14 890 The operator then creates the following P2MP PWs: 892 - PE1-> PE3-14 via P2MP PW1 over LSP1 893 - PE2-> PE3-14 via P2MP PW2 over LSP2 895 This case improves the P2P PW scenario as PE1 only replicates a 896 single copy of the broadcast frame received from the Ethernet 897 broadcast source. 899 Copyright Notice 901 Copyright (c) 2014 IETF Trust and the persons identified as the 902 document authors. All rights reserved. 904 This document is subject to BCP 78 and the IETF Trust's Legal 905 Provisions Relating to IETF Documents 906 (http://trustee.ietf.org/license-info) in effect on the date of 907 publication of this document. Please review these documents 908 carefully, as they describe your rights and restrictions with respect 909 to this document. Code Components extracted from this document must 910 include Simplified BSD License text as described in Section 4.e of 911 the Trust Legal Provisions and are provided without warranty as 912 described in the Simplified BSD License.