idnits 2.17.1 draft-ietf-l2vpn-vpls-mcast-reqts-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Jan 15, 2009) is 5578 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-mpls-ldp-p2mp-05 -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Kamite, Ed. 3 Internet-Draft NTT Communications 4 Intended status: Informational Y. Wada 5 Expires: July 19, 2009 NTT 6 Y. Serbest 7 AT&T 8 T. Morin 9 France Telecom 10 L. Fang 11 Cisco Systems, Inc. 12 Jan 15, 2009 14 Requirements for Multicast Support in Virtual Private LAN Services 15 draft-ietf-l2vpn-vpls-mcast-reqts-07.txt 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 19, 2009. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. 52 Abstract 54 This document provides functional requirements for network solutions 55 that support multicast over Virtual Private LAN Service (VPLS). It 56 specifies requirements both from the end user and service provider 57 standpoints. It is intended that potential solutions will use these 58 requirements as guidelines. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.2. Scope of this document . . . . . . . . . . . . . . . . . . 5 65 2. Conventions used in this document . . . . . . . . . . . . . . 5 66 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 68 3. Problem Statements . . . . . . . . . . . . . . . . . . . . . . 7 69 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.2. Multicast Scalability . . . . . . . . . . . . . . . . . . 7 71 3.3. Application Considerations . . . . . . . . . . . . . . . . 8 72 3.3.1. Two Perspectives of the Service . . . . . . . . . . . 9 73 4. General Requirements . . . . . . . . . . . . . . . . . . . . . 9 74 4.1. Scope of Transport . . . . . . . . . . . . . . . . . . . . 10 75 4.1.1. Traffic Types . . . . . . . . . . . . . . . . . . . . 10 76 4.1.2. Multicast Packet Types . . . . . . . . . . . . . . . . 10 77 4.1.3. MAC Learning Consideration . . . . . . . . . . . . . . 12 78 4.2. Static Solutions . . . . . . . . . . . . . . . . . . . . . 12 79 4.3. Backward Compatibility . . . . . . . . . . . . . . . . . . 12 80 5. Customer Requirements . . . . . . . . . . . . . . . . . . . . 12 81 5.1. CE-PE protocol . . . . . . . . . . . . . . . . . . . . . . 12 82 5.1.1. Layer-2 Aspect . . . . . . . . . . . . . . . . . . . . 12 83 5.1.2. Layer-3 Aspect . . . . . . . . . . . . . . . . . . . . 13 84 5.2. Multicast Domain . . . . . . . . . . . . . . . . . . . . . 14 85 5.3. Quality of Service (QoS) . . . . . . . . . . . . . . . . . 14 86 5.4. SLA Parameters Measurement . . . . . . . . . . . . . . . . 15 87 5.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 5.5.1. Isolation from Unicast . . . . . . . . . . . . . . . . 15 89 5.5.2. Access Control . . . . . . . . . . . . . . . . . . . . 16 90 5.5.3. Policing and Shaping on Multicast . . . . . . . . . . 16 91 5.6. Access Connectivity . . . . . . . . . . . . . . . . . . . 16 92 5.7. Multi-Homing . . . . . . . . . . . . . . . . . . . . . . . 16 93 5.8. Protection and Restoration . . . . . . . . . . . . . . . . 16 94 5.9. Minimum MTU . . . . . . . . . . . . . . . . . . . . . . . 16 95 5.10. Frame Reordering Prevention . . . . . . . . . . . . . . . 17 96 5.11. Fate-Sharing between Unicast and Multicast . . . . . . . . 17 97 6. Service Provider Network Requirements . . . . . . . . . . . . 18 98 6.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 18 99 6.1.1. Trade-off of Optimality and State Resource . . . . . . 18 100 6.1.2. Key Metrics for Scalability . . . . . . . . . . . . . 19 101 6.2. Tunneling Requirements . . . . . . . . . . . . . . . . . . 20 102 6.2.1. Tunneling Technologies . . . . . . . . . . . . . . . . 20 103 6.2.2. MTU of MDTunnel . . . . . . . . . . . . . . . . . . . 20 104 6.3. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 21 105 6.4. Discovering Related Information . . . . . . . . . . . . . 21 106 6.5. Operation, Administration and Maintenance . . . . . . . . 21 107 6.5.1. Activation . . . . . . . . . . . . . . . . . . . . . . 21 108 6.5.2. Testing . . . . . . . . . . . . . . . . . . . . . . . 22 109 6.5.3. Performance Management . . . . . . . . . . . . . . . . 22 110 6.5.4. Fault Management . . . . . . . . . . . . . . . . . . . 23 111 6.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 24 112 6.6.1. Security Threat Analysis . . . . . . . . . . . . . . . 24 113 6.6.2. Security Requirements . . . . . . . . . . . . . . . . 25 114 6.7. Hierarchical VPLS support . . . . . . . . . . . . . . . . 27 115 6.8. L2VPN Wholesale . . . . . . . . . . . . . . . . . . . . . 27 116 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 117 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 118 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 119 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 120 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 121 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 124 1. Introduction 126 1.1. Background 128 VPLS (Virtual Private LAN Service) is a provider service that 129 emulates the full functionality of a traditional Local Area Network 130 (LAN). VPLS interconnects several customer LAN segments over a 131 packet switched network (PSN) backbone, creating a multipoint-to- 132 multipoint Ethernet VPN. For customers, their remote LAN segments 133 behave as one single LAN. 135 In a VPLS, the provider network emulates a learning bridge, and 136 forwarding takes place based on Ethernet MAC learning. Hence, a VPLS 137 requires MAC address learning/aging on a per PW (Pseudo Wire) basis, 138 where forwarding decisions treat the PW as a "bridge port". 140 VPLS is a Layer-2 service. However, it provides two applications 141 from the customer's point of view: 143 - LAN Routing application: providing connectivity between customer 144 routers 145 - LAN Switching application: providing connectivity between 146 customer Ethernet switches 148 Thus, in some cases, customers across MAN/WAN have transparent 149 Layer-2 connectivity while their main goal is to run Layer-3 150 applications within their routing domain. As a result, different 151 requirements arise from their variety of applications. 153 Originally, PEs (Provider Edges) in VPLS transport broadcast/ 154 multicast Ethernet frames by replicating all multicast/broadcast 155 frames received from an AC to all PW's corresponding to a particular 156 VSI. Such a technique has the advantage of keeping the P (Provider 157 Router) and PE devices completely unaware of IP multicast-specific 158 issues. Obviously, however, it has quite a few scalability drawbacks 159 in terms of bandwidth consumption, which will lead to increased cost 160 in large-scale deployment. 162 Meanwhile, there is a growing need for support of multicast-based 163 services such as IP TV. This commercial trend makes it necessary for 164 most VPLS deployments to support multicast more efficiently than 165 before. It is also necessary as customer routers are now likely to 166 be running IP multicast protocols and those routers and connected to 167 switches that will be handling large amounts of multicast traffic. 169 Therefore, it is desirable to have more efficient techniques to 170 support IP multicast over VPLS. 172 1.2. Scope of this document 174 This document provides functional requirements for network solutions 175 that support IP multicast in VPLS [RFC4761] [RFC4762]. It identifies 176 requirements that MAY apply to the existing base VPLS architecture in 177 order to optimize IP multicast. It also complements the generic L2 178 VPN requirements document [RFC4665], by specifying additional 179 requirements specific to the deployment of IP multicast in VPLS. 181 The technical specifications are outside the scope of this document. 182 There is no intent to either specify solution-specific details in 183 this document or application-specific requirements. Also, this 184 document does NOT aim to express multicast-inferred requirements that 185 are not specific to VPLS. It does NOT aim to express any 186 requirements for native Ethernet specifications, either. 188 This document is proposed as a solution guideline and a checklist of 189 requirements for solutions, by which we will evaluate how each 190 solution satisfies the requirements. 192 This document clarifies the needs from both VPLS customer as well as 193 provider standpoints and formulates the problems that should be 194 addressed by technical solutions while staying solution agnostic. 196 A technical solution and corresponding service which supports this 197 document's requirements are hereinafter called a "multicast VPLS". 199 2. Conventions used in this document 201 2.1. Terminology 203 The reader is assumed to be familiar with the terminology, reference 204 models and taxonomy defined in [RFC4664] and [RFC4665]. For 205 readability purposes, we repeat some of the terms here. 207 Moreover, we also propose some other terms needed when IP multicast 208 support in VPLS is discussed. 210 - ASM: Any Source Multicast. One of the two multicast service 211 models where each corresponding service can have an arbitrary 212 number of senders. 214 - G: denotes a multicast group. 216 - MDTunnel: Multicast Distribution Tunnel, the means by which the 217 customer's multicast traffic will be conveyed across the SP 218 network. This is meant in a generic way: such tunnels can be 219 point-to-point, point-to-multipoint or multipoint-to-multipoint. 220 Although this definition may seem to assume that distribution 221 tunnels are unidirectional, the wording encompasses bi-directional 222 tunnels as well. 224 - Multicast Channel: In the multicast SSM (Source Specific 225 Multicast) model [RFC4607], a "multicast channel" designates 226 traffic from a specific source S to a multicast group G. Also 227 denominated as "(S,G)". 229 - Multicast domain: An area in which multicast data is transmitted. 230 In this document, this term has a generic meaning which can refer 231 to Layer-2 and Layer-3. Generally, the Layer-3 multicast domain 232 is determined by the Layer-3 multicast protocol used to establish 233 reachability between all potential receivers in the corresponding 234 domain. The Layer-2 multicast domain can be the same as the 235 Layer-2 broadcast domain (i.e., VLAN), but it may be restricted to 236 being smaller than the Layer-2 broadcast domain if an additional 237 control protocol is used. 239 - CE: Customer Edge Device. 241 - PE: Provider Edge. 243 - P: Provider Router. 245 - S: denotes a multicast source. 247 - SP: Service Provider. 249 - SSM: Source Specific Multicast. One of the two multicast service 250 models where each corresponding service relies upon the use of a 251 single source. 253 - U-PE/N-PE: The device closest to the customer/user is called User 254 facing PE (U-PE) and the device closest to the core network is 255 called Network facing PE (N-PE). 257 - VPLS instance: A service entity manageable in VPLS architecture. 258 All CE devices participating in a single VPLS instance appear to 259 be on the same LAN, composing a VPN across the SP's network. A 260 VPLS instance corresponds to a group of VSIs that are 261 interconnected using PWs (Pseudo Wires). 263 - VSI: Virtual Switching Instance. VSI is a logical entity in a PE 264 that maps multiple ACs (Attachment Circuits) to multiple PWs 265 (Pseudo Wires). The VSI is populated in much the same way as a 266 standard bridge populates its forwarding table. Each PE device 267 may have multiple VSIs, where each VSI belongs to a different VPLS 268 instance. 270 2.2. Conventions 272 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 273 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 274 document are to be interpreted as described in [RFC2119] . 276 3. Problem Statements 278 3.1. Motivation 280 Today, many kinds of IP multicast services are becoming available. 281 Over their Layer-2 VPN service, particularly over VPLS, customers 282 would often like to operate their multicast applications to remote 283 sites. Also, VPN service providers using an IP-based networks expect 284 that such Layer-2 network infrastructure will efficiently support 285 multicast data traffic. 287 However, VPLS has a shortcoming as it relates to multicast 288 scalability as mentioned below because of the replication mechanisms 289 intrinsic to the original architecture. Accordingly, the primary 290 goal for technical solutions is to solve this issue partially or 291 completely, and provide efficient ways to support IP multicast 292 services over VPLS. 294 3.2. Multicast Scalability 296 In VPLS, replication occurs at an ingress PE (in H-VPLS case, at 297 N-PE) when a CE sends (1) Broadcast, (2) Multicast or (3) Unknown 298 destination unicast. There are two well known issues with this 299 approach: 301 Issue A: Replication to non-member site 303 In case (1) and (3), the upstream PE has to transmit packets to 304 all of the downstream PEs which belong to the common VPLS 305 instance. You cannot decrease the number of members, so this is 306 basically an inevitable situation for most VPLS deployments. 308 In case (2), however, there is an issue that multicast traffic is 309 sent to sites with no members. Usually this is caused when the 310 upstream PE does not maintain downstream membership information. 311 The upstream PE simply floods frames to all downstream PEs, and 312 the downstream PEs forward them to directly connected CEs; 313 however, those CEs might not be the members of any multicast 314 group. From the perspective of customers, they might suffer from 315 pressure on their own resources due to unnecessary traffic. From 316 the perspective of SPs, they would not like wasteful over- 317 provisioning to cover such traffic. 319 Issue B: Replication of PWs on shared physical path 321 In VPLS, a VSI associated with each VPLS instance behaves as a 322 logical emulated bridge which can transport Ethernet across the 323 PSN backbone using PWs. In principle, PWs are designed for 324 unicast traffic. 326 In all cases (1), (2) and (3), Ethernet frames are replicated on 327 one or more PWs that belong to that VSI. This replication is 328 often inefficient in terms of bandwidth usage if those PWs are 329 traversing shared physical links in the backbone. 331 For instance, suppose there are 20 remote PEs belonging to a 332 particular VPLS instance, and all PWs happen to be traversing over 333 the same link from one local PE to its next-hop P. In this case, 334 even if a CE sends 50Mbps to the local PE, the total bandwidth of 335 that link will be to 1000Mbps. 337 Note that while traditional 802.1D Ethernet switches replicate 338 broadcast/multicast flows once at most per output interface, VPLS 339 often needs to transmit one or more flows duplicated over the same 340 output interface. 342 From the perspective of customers, there is no serious issue 343 because they do not know what happens in the core. However, from 344 the perspective of SPs, unnecessary replication brings the risk of 345 resource exhaustion when the number of PWs increases. 347 In both issues A and B, these undesirable situations will become 348 obvious with the wide-spread use of IP multicast applications by 349 customers. Naturally the problem will become more serious as the 350 number of sites grows. In other words, there are concerns over the 351 scalability of multicast in VPLS today. 353 3.3. Application Considerations 354 3.3.1. Two Perspectives of the Service 356 When it comes to IP multicast over VPLS, there are two different 357 aspects in terms of service provisioning. They are closely related 358 to the functional requirements from two technical standpoints: 359 Layer-2 and Layer-3. 361 - Native Ethernet service aspect 363 This aspect mainly affects Ethernet network service operators. 364 Their main interest is to solve the issue that existing VPLS 365 deployments cannot always handle multicast/broadcast frames 366 efficiently. 368 Today, wide-area Ethernet services are becoming popular, and VPLS 369 can be utilized to provide wide-area LAN services. As customers 370 come to use various kinds of content distribution applications 371 which use IP multicast (or other protocols which lead to 372 multicast/broadcast in the Ethernet layer), the total amount of 373 traffic will also grow. In addition, considerations of OAM, 374 security and other related points in multicast in view of Layer-2 375 are important as well. 377 In such circumstances, the native VPLS specification would not 378 always be satisfactory if multicast traffic is more dominant in 379 total resource utilization than before. The scalability issues 380 mentioned in the previous section are expected to be solved. 382 - IP multicast service aspect 384 This aspect mainly affects both IP service providers and end 385 users. Their main interest is to provide IP multicast services 386 transparently but effectively by means of VPLS as a network 387 infrastructure. 389 SPs might expect VPLS as an access/metro network to deliver 390 multicast traffic (such as Triple-play (Video, Voice, Data) and 391 Multicast IP VPNs) in an efficient way. 393 4. General Requirements 395 We assume the basic requirements for VPLS written in [RFC4665] are 396 fulfilled if there is no special reference in this document. 398 4.1. Scope of Transport 400 4.1.1. Traffic Types 402 4.1.1.1. Multicast and Broadcast 404 As described before, any solution is expected to have mechanisms for 405 efficient transport of IP multicast. Multicast is related to both 406 issues A and B (see section 3.2.); however, broadcast is related to 407 issue B only because it does not need membership control. 409 - A multicast VPLS solution SHOULD attempt to solve both issues (A) 410 and (B), if possible. However, since some applications prioritize 411 solving one issue over the other, the solution MUST identify which 412 issue (A or B) it is attempting to solve. The solution SHOULD 413 provide a basis for evaluating how well it solves the issue(s) it 414 is targeting, if it is providing an approximate solution. 416 4.1.1.2. Unknown Destination Unicast 418 Unknown destination MAC unicast requires flooding, but its 419 characteristics are quite different from multicast/broadcast. When 420 the unicast MAC address is learned, the PE changes its forwarding 421 behavior from flooding over all PWs into sending over one PW. 422 Thereby it will require different technical studies from multicast/ 423 broadcast, which is out of scope of this document. 425 4.1.2. Multicast Packet Types 427 Ethernet multicast is used for conveying Layer-3 multicast data. 428 When IP multicast is encapsulated by an Ethernet frame, the IP 429 multicast group address is mapped to the Ethernet destination MAC 430 address. In IPv4, the mapping uses the lower 23 bits of the (32bit) 431 IPv4 multicast address and places them as the lower 23 bits of a 432 destination MAC address with the fixed header of 01-00-5E in hex. 433 Since this mapping is ambiguous (i.e., there is a multiplicity of 1 434 Ethernet address to 32 IPv4 addresses), MAC-based forwarding is not 435 ideal for IP multicast because some hosts might possibly receive 436 packets they are not interested in, which is inefficient in traffic 437 delivery and has an impact on security. On the other hand, if the 438 solution tracks IP addresses rather than MAC addresses, this concern 439 can be prevented. The drawback of this approach is, however, that 440 the network administration becomes slightly more complicated. 442 Ethernet multicast is also used for Layer-2 control frames. For 443 example, BPDU (Bridge Protocol Data Unit) for IEEE 802.1D Spanning 444 Tree uses a multicast destination MAC address (01-80-C2-00-00-00). 445 Also some of IEEE 802.1ag [802.1ag] Connectivity Fault Management 446 (CFM) messages use a multicast destination MAC address dependent on 447 their message type and application. From the perspective of IP 448 multicast, however, it is necessary in VPLS to flood such control 449 frames to all participating CEs, without requiring any membership 450 controls. 452 As for a multicast VPLS solution, it can only use Ethernet-related 453 information, if you stand by the strict application of the basic 454 requirement: "a L2VPN service SHOULD be agnostic to customer's Layer 455 3 traffic [RFC4665]." This means no Layer-3 information should be 456 checked for transport. However, it is obvious this is an impediment 457 to solve Issue A. 459 Consequently, a multicast VPLS can be allowed to make use of some 460 Layer-3-related supplementary information in order to improve 461 transport efficiency. In fact, today's LAN switch implementations 462 often support such approaches and snoop upper layer protocols and 463 examine IP multicast memberships (e.g., PIM snooping and IGMP/MLD 464 snooping [RFC4541]). This will implicitly suggest that VPLS may 465 adopt similar techniques although this document does NOT state 466 Layer-3 snooping is mandatory. If such an approach is taken, careful 467 consideration of Layer-3 state maintenance is necessary. In 468 addition, note that snooping approaches sometimes have disadvantages 469 in the system's transparency; that is, one particular protocol's 470 snooping solution might hinder other (especially future) protocol's 471 working (e.g., an IGMPv2-snooping switch vs. a new IGMPv3-snooping 472 one). Also, note that there are potential alternatives to snooping: 473 - Static configuration of multicast Ethernet addresses and ports/ 474 interfaces 475 - Multicast control protocol based on Layer-2 technology which 476 signals mappings of multicast addresses to ports/interfaces, such 477 as GARP/GMRP[802.1D], CGMP[CGMP] and RGMP[RFC3488]. 479 On the basis described above, general requirements about packet types 480 are given as follows: 482 - A solution SHOULD support a way to facilitate IP multicast 483 forwarding of the customers. It MAY observe Layer-3 information 484 (i.e., multicast routing protocols and state) to the degree 485 necessary, but any information irrelevant to multicast transport 486 SHOULD NOT be consulted. 488 - In a solution, Layer-2 control frames (e.g., BPDU, 802.1ag CFM) 489 SHOULD be flooded to all PE/CEs in a common VPLS instance. A 490 solution SHOULD NOT change or limit the flooding scope to remote 491 PE/CEs in terms of end-point reachability. 493 - In a solution, Layer-2 frames that encapsulate Layer-3 multicast 494 control packets (e.g., PIM, IGMP(for IPv4), MLD(for IPv6)) MAY be 495 flooded only to relevant members, with the goal of limiting 496 flooding scope. However, Layer-2 frames that encapsulate other 497 Layer-3 control packets (e.g., OSPF, ISIS) SHOULD be flooded to 498 all PE/CEs in a VPLS instance. 500 4.1.3. MAC Learning Consideration 502 In a common VPLS architecture, MAC learning is carried out by PEs 503 based on the incoming frame's source MAC address, independently of 504 the destination MAC address (i.e., regardless of whether it is 505 unicast, multicast or broadcast). This is the case with multicast 506 VPLS solution's environment too. In this document, the improvement 507 of MAC learning scalability is beyond the scope. It will be covered 508 in the future work. 510 4.2. Static Solutions 512 A solution SHOULD allow static configuration to account for various 513 operator policies, where the logical multicast topology does not 514 change dynamically in conjunction with a customer's multicast 515 routing. 517 4.3. Backward Compatibility 519 A solution SHOULD be backward compatible with the existing VPLS 520 solution. It SHOULD allow a case where a common VPLS instance is 521 composed of both PEs supporting the solution and PEs not supporting 522 it, and the multicast optimization (both forwarding and receiving) is 523 achieved between the compliant PEs. 525 Note again that the existing VPLS solutions already have a simple 526 flooding capability. Thus this backward compatibility will give 527 customers and SPs the improved efficiency of multicast forwarding 528 incrementally as the solution is deployed. 530 5. Customer Requirements 532 5.1. CE-PE protocol 534 5.1.1. Layer-2 Aspect 536 A solution SHOULD allow transparent operation of Ethernet control 537 protocols employed by customers (e.g. Spanning Tree Protocol 538 [802.1D]) and their seamless operation with multicast data transport. 540 Solutions MAY examine Ethernet multicast control frames for the 541 purpose of efficient dynamic transport (e.g. GARP/GMRP [802.1D]). 542 However, solutions MUST NOT assume all CEs are always running such 543 protocols (typically in the case where a CE is a router and is not 544 aware of Layer-2 details). 546 A whole Layer-2 multicast frame (whether for data or control) SHOULD 547 NOT be altered from a CE to CE(s) EXCEPT for the VLAN Id field, 548 ensuring that it is transparently transported. If VLAN Ids are 549 assigned by the SP, they can be altered. Note, however, when VLAN 550 Ids are changed, Layer-2 protocols may be broken in some cases, such 551 as Multiple Spanning Tree [802.1s]. Also if the Layer-2 frame is 552 encapsulating Layer-3 multicast control packet (e.g., PIM/IGMP) and 553 customers allow it to be regenerated at PE (aka proxy: see section 554 5.1.2.), then the MAC address for that frame MAY be altered to the 555 minimum necessary (e.g., use PE's own MAC address as a source). 557 5.1.2. Layer-3 Aspect 559 Again, a solution MAY examine customer's Layer-3 multicast protocol 560 packets for the purpose of efficient and dynamic transport. If it 561 does, supported protocols SHOULD include: 563 o PIM-SM [RFC4601], PIM-SSM [RFC4607], bidirectional PIM [RFC5015] 564 and PIM-DM [RFC3973] 565 o IGMP (v1[RFC1112], v2[RFC2236] and v3[RFC3376]) (for IPv4 566 solutions) 567 o Multicast Listener Discovery Protocol (MLD) (v1[RFC2710] and 568 v2[RFC3810]) (for IPv6 solutions). 570 A solution MUST NOT require any special Layer-3 multicast protocol 571 packet processing by the end users. However, it MAY require some 572 configuration changes (e.g., turning explicit tracking on/off in 573 PIM). 575 A whole Layer-3 multicast packet (whether for data or control), which 576 is encapsulated inside a Layer-2 frame, SHOULD NOT be altered from a 577 CE to CE(s), ensuring that it is transparently transported. However, 578 as for Layer-3 multicast control (like PIM Join/Prune/Hello and IGMP 579 Query/Report packet), it MAY be altered to the minimum necessary if 580 such partial non-transparency is acceptable from point of view of the 581 multicast service. Similarly, a PE MAY consume such Layer-3 582 multicast control packets and regenerate an entirely new packet if 583 partial non-transparency is acceptable with legitimate reason for 584 customers (aka proxy). 586 5.2. Multicast Domain 588 As noted in Section 2.1., the term "multicast domain" is used in a 589 generic context for Layer-2 and Layer-3. 591 A solution SHOULD NOT alter customer multicast domains' boundaries. 592 It MUST ensure that the provided Ethernet multicast domain always 593 encompasses the corresponding customer Layer-3 multicast domain. 595 A solution SHOULD optimize those domains' coverage sizes, i.e., a 596 solution SHOULD ensure that unnecessary traffic is not sent to CEs 597 with no members. Ideally, the provided domain size will be close to 598 that of the customer's Layer-3 multicast membership distribution; 599 however, it is OPTIONAL to achieve such absolute optimality from the 600 perspective of Layer-3. 602 If a customer uses VLANs and a VLAN Id as a service delimiter (i.e., 603 each VPLS instance is represented by a unique customer VLAN tag 604 carried by a frame through the UNI port), a solution MUST support 605 separate multicast domains per VLAN Id. Note that if VLAN Id 606 translation is provided (i.e., if a customer VLAN at one site is 607 mapped into a different customer VLAN at a different site), multicast 608 domains will be created per set of VLAN Ids which are associated with 609 translation. 611 If a customer uses VLANs but a VLAN Id is not a service delimiter 612 (i.e., the VPN disregards customer VLAN Ids), a solution MAY provide 613 separate multicast domains per VLAN Id. A SP is not required to 614 provide separate multicast domains per VLAN IDs, but it may be 615 considered beneficial to do so. 617 A solution MAY build multicast domains based on Ethernet MAC 618 addresses. It MAY also build multicast domains based on the IP 619 addresses inside Ethernet frames. That is, PEs in each VPLS instance 620 might control forwarding behavior and provide different multicast 621 frame reachability depending on each MAC/IP destination address 622 separately. If IP multicast channels are fully considered in a 623 solution, the provided domain size will be closer to actual channel 624 reachability. 626 5.3. Quality of Service (QoS) 628 Customers require that multicast quality of service MUST be at least 629 on par with what exists for unicast traffic. Moreover, as multicast 630 is often used to deliver high quality services such as TV broadcast, 631 delay/jitter/loss sensitive traffic MUST be supported over multicast 632 VPLS. 634 To accomplish this, the solution MAY have additional features to 635 support high QoS such as bandwidth reservation and flow admission 636 control. Also multicast VPLS deployment SHALL benefit from IEEE 637 802.1p CoS techniques [802.1D] and DiffServ [RFC2475] mechanisms. 639 Moreover, multicast traffic SHOULD NOT affect the QoS that unicast 640 traffic receives and vice versa. That is, separation of multicast 641 and unicast traffic in terms of QoS is necessary. 643 5.4. SLA Parameters Measurement 645 Since SLA parameters are part of the service sold to customers, they 646 simply want to verify their application performance by measuring the 647 parameters SP(s) provide. 649 Multicast specific characteristics that may be monitored are, for 650 instance, multicast statistics per stream (e.g. total/incoming/ 651 outgoing/dropped traffic by period of time), one-way delay, jitter 652 and group join/leave delay (time to start receiving traffic from a 653 multicast group across the VPN since join/leave was issued). An 654 operator may also wish to compare the difference in one-way delay for 655 a solitary multicast group/stream from a single, source PE to 656 multiple receiver PEs. 658 A solution SHOULD provide these parameters with Ethernet multicast 659 group level granularity. (For example, multicast MAC address will be 660 one of those entries for classifying flows with statistics, delay and 661 so on.) However, if a solution is aimed at IP multicast transport 662 efficiency, it MAY support IP multicast level granularity. (For 663 example, multicast IP address/channel will be entries for latency 664 time.) 666 In order to monitor them, standard interfaces for statistics 667 gathering SHOULD also be provided (e.g., standard SNMP MIB Modules). 669 5.5. Security 671 A solution MUST provide customers with architectures that give the 672 same level of security both for unicast and multicast. 674 5.5.1. Isolation from Unicast 676 Solutions SHOULD NOT affect any forwarding information base, 677 throughput or resiliency etc. of unicast frames; that is, they SHOULD 678 provide isolation from unicast. 680 5.5.2. Access Control 682 A solution MAY filter multicast traffic inside a VPLS, upon the 683 request of an individual customer, (for example, MAC/VLAN filtering, 684 IP multicast channel filtering, etc.). 686 5.5.3. Policing and Shaping on Multicast 688 A solution SHOULD support policing and shaping multicast traffic on a 689 per customer basis and on a per AC (Attachment Circuit) basis. This 690 is intended to prevent multicast traffic from exhausting resources 691 for unicast inside a common customer's VPN. This might also be 692 beneficial for QoS separation (see section 5.3). 694 5.6. Access Connectivity 696 First and foremost various physical connectivity types described in 697 [RFC4665] MUST be supported. 699 5.7. Multi-Homing 701 A multicast VPLS MUST allow a situation in which a CE is dual-homed 702 to two different SPs via diverse access networks -- one is supporting 703 multicast VPLS but the other is not supporting it, (because it is an 704 existing VPLS or 802.1Q/QinQ network). 706 5.8. Protection and Restoration 708 A multicast VPLS infrastructure SHOULD allow redundant paths to 709 assure high availability. 711 Multicast forwarding restoration time MUST NOT be greater than the 712 time it takes a customer's Layer-3 multicast protocols to detect a 713 failure in the VPLS infrastructure. For example, if a customer uses 714 PIM with default configuration, hello hold timer is 105 seconds, and 715 solutions are required to restore a failure no later than this 716 period. To achieve this, a solution might need to support providing 717 alternative multicast paths. 719 Moreover, if multicast forwarding was not successfully restored 720 (e.g., in case of no redundant paths), a solution MAY raise alarms to 721 provide outage notification to customers before such a hold timer 722 expires. 724 5.9. Minimum MTU 726 Multicast applications are often sensitive to packet fragmentation 727 and reassembly, so the requirement to avoid fragmentation might be 728 stronger than the existing VPLS solution. 730 A solution SHOULD provide customers with enough committed minimum MTU 731 (i.e., service MTU) for multicast Ethernet frames to ensure that IP 732 fragmentation between customer sites never occurs. It MAY give 733 different MTU sizes to multicast and unicast. 735 5.10. Frame Reordering Prevention 737 A solution SHOULD attempt to prevent frame reordering when delivering 738 customer multicast traffic. Likewise, for unicast and unknown 739 unicast traffic, it SHOULD attempt not to increase the likelihood of 740 reordering compared with existing VPLS solutions. 742 It is to be noted that delivery of out-of-order frames is not 743 avoidable in certain cases. Specifically if a solution adopts some 744 MDTunnels (see section 6.2.1) and dynamically selects them for 745 optimized delivery (e.g., switching from one aggregate tree to 746 another), end-to-end data delivery is prone to be out-of-order. This 747 fact can be considered a trade-off between bandwidth optimization and 748 network stability. Therefore, such a solution is expected to promote 749 awareness about this kind of drawback. 751 5.11. Fate-Sharing between Unicast and Multicast 753 In native Ethernet, multicast and unicast connectivity are often 754 managed together. For instance, 802.1ag CFM Continuity Check message 755 is forwarded by multicast as a periodic heartbeat, but it is supposed 756 to check the "whole" traffic continuity regardless of unicast or 757 multicast, at the same time. Hence, the aliveness of unicast and 758 multicast is naturally coupled (i.e., fate-shared) in this customer's 759 environment. 761 A multicast VPLS solution may decouple the path that a customer's 762 unicast and multicast traffic follow through a SP's backbone, in 763 order to provide the most optimal path for multicast data traffic. 764 This may cause concern among some multicast VPLS customers who desire 765 that, during a failure in the SP's network, both unicast and 766 multicast traffic fail concurrently. 768 Therefore, there will be an additional requirement that makes both 769 unicast and multicast connectivity coupled. This means that if 770 either one of them have a failure, the other is also disabled. If 771 one of the services (either unicast or multicast) becomes 772 operational, the other is also activated simultaneously. 774 - It SHOULD be identified if the solution can provide customers with 775 fate-sharing between unicast and multicast connectivity for their 776 LAN switching application. It MAY have a configurable mechanism 777 for SPs to provide that on behalf of customers, e.g., aliveness 778 synchronization, but its use is OPTIONAL. 780 This policy will benefit customers. Some customers would like to 781 detect failure soon at CE side and restore full connectivity by 782 switching over to their backup line, rather than to keep poor half 783 connectivity (i.e., either unicast or multicast being in fail). Even 784 if either unicast or multicast is kept alive, it is just 785 disadvantageous to the customer's application protocols which need 786 both traffic. Fate-sharing policy contributes to preventing such a 787 complicated situation. 789 Note that how serious this issue is depends on each customer's stance 790 in Ethernet operation. If all CEs are IP routers i.e., if VPLS is 791 provided for LAN routing application, the customer might not care 792 about it because both unicast and multicast connectivity is assured 793 in IP layer. If the CE routers are running an IGP (e.g., OSPF/IS-IS) 794 and a multicast routing protocol (e.g., PIM), then aliveness of both 795 the unicast and multicast paths will be detected by the CEs. This 796 does not guarantee that unicast and multicast traffic are to follow 797 the same path in the SP's backbone network, but does mitigate this 798 issue to some degree. 800 6. Service Provider Network Requirements 802 6.1. Scalability 804 The existing VPLS architecture has major advantages in scalability. 805 For example, P-routers are free from maintaining customers' 806 information because customer traffic is encapsulated in PSN tunnels. 807 Also a PW's split-horizon technique can prevent loops, making PE 808 routers free from maintaining complicated spanning trees. 810 However, a multicast VPLS needs additional scalability considerations 811 related to its expected enhanced mechanisms. [RFC3809] lists common 812 L2VPN sizing and scalability requirements and metrics, which are 813 applicable in multicast VPLS too. Accordingly, this section deals 814 with specific requirements related to scalability. 816 6.1.1. Trade-off of Optimality and State Resource 818 A solution needs to improve the scalability of multicast as is shown 819 in section 3: 821 Issue A: Replication to non-member site. 822 Issue B: Replication of PWs on shared physical path. 824 For both issues, the optimization of physical resources (i.e. link 825 bandwidth usage and router duplication performance) will become a 826 major goal. However, there is a trade-off between optimality and 827 state resource consumption. 829 In order to solve Issue A, a PE might have to maintain multicast 830 group information for CEs which was not kept in the existing VPLS 831 solutions. This will present scalability concerns about state 832 resources (memory, CPU, etc.) and their maintenance complexity. 834 In order to solve Issue B, PE and P routers might have to have 835 knowledge of additional membership information for remote PEs, and 836 possibly additional tree topology information, when they are using 837 point-to-multipoint techniques (PIM tree, P2MP-LSP, etc.). 839 Consequently, the scalability evaluation of multicast VPLS solutions 840 needs a careful trade-off analysis between bandwidth optimality and 841 state resource consumption. 843 6.1.2. Key Metrics for Scalability 845 (Note: This part has a number of similar characteristics to 846 requirements for Layer 3 Multicast VPN [RFC4834].) 848 A multicast VPLS solution MUST be designed to scale well with an 849 increase in the number of any of the following metrics: 851 - the number of PEs 852 - the number of VPLS instances (total and per PE) 853 - the number of PEs and sites in any VPLS instance 854 - the number of client VLAN Ids 855 - the number of client Layer-2 MAC multicast groups 856 - the number of client Layer-3 multicast channels (groups or source- 857 groups) 858 - the number of PWs and PSN Tunnels (MDTunnels) (total and per PE) 860 Each multicast VPLS solution SHALL document its scalability 861 characteristics in quantitative terms. A solution SHOULD quantify 862 the amount of state that a PE and a P device has to support. 864 The scalability characteristics SHOULD include: 866 - the processing resources required by the control plane in managing 867 PWs (neighborhood or session maintenance messages, keepalives, 868 timers, etc.) 869 - the processing resources required by the control plane in managing 870 PSN tunnels 871 - the memory resources needed for the control plane 872 - the amount of protocol information transmitted to manage a 873 multicast VPLS (e.g. signaling throughput) 874 - the amount of Layer-2/Layer-3 multicast information a P/PE router 875 consumes (e.g. traffic rate of join/leave, keepalives etc.) 876 - the number of multicast IP addresses used (if IP multicast in ASM 877 mode is proposed as a multicast distribution tunnel) 878 - other particular elements inherent to each solution that impact 879 scalability 881 Another metric for scalability is operational complexity. Operations 882 will naturally become more complicated if the number of managed 883 objects (e.g., multicast groups) increases, or the topology changes 884 occur more frequently. A solution SHOULD note the factors which lead 885 to additional operational complexity. 887 6.2. Tunneling Requirements 889 6.2.1. Tunneling Technologies 891 A MDTunnel denotes a multicast distribution tunnel. This is a 892 generic term for tunneling where customer multicast traffic is 893 carried over a provider's network. In the L2VPN service context, it 894 will correspond to a PSN tunnel. 896 A solution SHOULD be able to use a range of tunneling technologies, 897 including point-to-point (unicast oriented) and point-to-multipoint/ 898 multipoint-to-multipoint (multicast oriented). For example, today 899 there are many kinds of protocols for tunneling such as L2TP, IP, 900 (including multicast IP trees), MPLS (including P2MP-LSP [RFC4875] 901 and P2MP/MP2MP-LSP [I-D.ietf-mpls-ldp-p2mp] ), etc. 903 Note that which variant, point-to-point, point-to-multipoint or 904 multipoint-to-multipoint, is used depends largely on the trade-offs 905 mentioned above and the targeted network and applications. 906 Therefore, this document does not mandate any specific protocols. A 907 solution, however, SHOULD state reasonable criteria if it adopts a 908 specific kind of tunneling protocol. 910 6.2.2. MTU of MDTunnel 912 From the view of a SP, it is not acceptable to have fragmentation/ 913 reassembly so often while packets are traversing a MDTunnel. 915 Therefore, a solution SHOULD support a method that provides the 916 minimum path MTU of the MDTunnel in order to accommodate the service 917 MTU. 919 6.3. Robustness 921 Multicast VPLS solutions SHOULD avoid single points of failures or 922 propose technical solutions that make it possible to implement a 923 failover mechanism. 925 6.4. Discovering Related Information 927 The operation of a multicast VPLS solution SHALL be as light as 928 possible and providing automatic configuration and discovery SHOULD 929 be considered a high priority. 931 Therefore, in addition to the L2VPN discovery requirements in 932 [RFC4665], a multicast VPLS solution SHOULD provide a method that 933 dynamically allows multicast membership information to be discovered 934 by PEs if the solution supports (A), as defined in section 3.2. This 935 means, a PE needs to discover multicast membership (e.g., join group 936 addresses) that is controlled dynamically from the sites connected to 937 that PE. In addition, a PE needs to discover such information 938 automatically from other remote PEs as well in order to limit 939 flooding scope across the backbone. 941 6.5. Operation, Administration and Maintenance 943 6.5.1. Activation 945 The activation of multicast enhancement in a solution MUST be 946 possible: 948 o with a VPLS instance granularity 949 o with an Attachment Circuit granularity (i.e., with a PE-CE 950 Ethernet port granularity, or with a VLAN Id granularity when it 951 is a service delimiter) 953 Also it SHOULD be possible: 955 o with a CE granularity (when multiple CEs of a same VPN are 956 associated with a common VPLS instance) 957 o with a distinction between multicast reception and emission 958 o with a multicast MAC address granularity 959 o with a customer IP multicast group and/or channel granularity 960 (when Layer-3 information is consulted) 962 Also it MAY be possible: 964 o with a VLAN Id granularity when it is not a service delimiter 966 6.5.2. Testing 968 A solution MUST provide a mechanism for testing multicast data 969 connectivity and verifying the associated information. Examples that 970 SHOULD be supported which are specific to multicast are: 972 - Testing connectivity per multicast MAC address 973 - Testing connectivity per multicast Layer-3 group/channel 974 - Verifying data plane and control plane integrity (e.g. PW, 975 MDTunnel) 976 - Verifying multicast membership-relevant information (e.g. 977 multicast MAC-addresses/PW-ports associations, Layer-3 group 978 associations) 980 Operators usually want to test if an end-to-end multicast user's 981 connectivity is OK before and after activation. Such end-to-end 982 multicast connectivity checking SHOULD enable the end-to-end testing 983 of the data path used by that customer's multicast data packets. 984 Specifically, end-to-end checking will have CE-to-CE path test and 985 PE-to-PE path test. A solution MUST support PE-to-PE path test and 986 MAY support CE-to-CE path test. 988 Also operators will want to make use of a testing mechanism for 989 diagnosis and troubleshooting. In particular, a solution SHOULD be 990 able to monitor information describing how client multicast traffic 991 is carried over the SP network. Note that if a solution supports 992 frequent dynamic membership changes with optimized transport, 993 troubleshooting within the SP's network will tend to be difficult. 995 6.5.3. Performance Management 997 Mechanisms to monitor multicast specific parameters and statistics 998 MUST be offered to the SP. 1000 (Note: This part has a number of similar characteristics to 1001 requirements for Layer 3 Multicast VPN [RFC4834].) 1003 A solution MUST provide SPs with access to: 1005 - Multicast traffic statistics (total traffic forwarded, incoming, 1006 outgoing, dropped, etc., by period of time) 1008 A solution SHOULD provide access to: 1010 - Information about a customer's multicast resource usage (the 1011 amount of multicast state and throughput) 1012 - Performance information related to multicast traffic usage, e.g., 1013 one-way delay, jitter, loss, delay variations (the difference in 1014 one-way delay for a solitary multicast group/stream from a single, 1015 source PE to multiple receiver PEs) etc. 1016 - Alarms when limits are reached on such resources 1017 - Statistics on decisions related to how client traffic is carried 1018 on MDTunnels (e.g. "How much traffic was switched onto a 1019 multicast tree dedicated to such groups or channels") 1020 - Statistics on parameters that could help the provider to evaluate 1021 its optimality/state trade-off 1023 All or part of this information SHOULD be made available through 1024 standardized SNMP MIB Modules (Management Information Base). 1026 6.5.4. Fault Management 1028 A multicast VPLS solution needs to consider those management steps 1029 taken by SPs below: 1031 o Fault detection 1032 A solution MUST provide tools that detect group membership/ 1033 reachability failure and traffic looping for multicast 1034 transport. It is anticipated that such tools are coordinated 1035 with the testing mechanisms mentioned in 6.5.2. 1037 In particular, such mechanisms SHOULD be able to detect a 1038 multicast failure quickly, (on par with unicast cases). It 1039 SHOULD also avoid situations where multicast traffic has been 1040 in a failure state for a relatively long time while unicast 1041 traffic remains operational. If such a situation were to 1042 occur, it would end up causing problems with customer 1043 applications that depend on a combination of unicast and 1044 multicast forwarding. 1046 With multicast, there may be many receivers associated with a 1047 particular mulitcast stream/group. As the number of receivers 1048 increases, the number of places (typically nearest the 1049 receivers) required to detect a fault will increase 1050 proportionately. This raises concerns over the scalability of 1051 fault detection in large multicast deployments. Consequently, 1052 a fault detection solution SHOULD scale well; in particular, a 1053 solution should consider key metrics for scalability as 1054 described in section 6.1.2. 1056 o Fault notification 1057 A solution MUST also provide fault notification and trouble 1058 tracking mechanisms. (e.g. SNMP-trap and syslog.) 1060 In case of multicast, one point of failure often affects a 1061 number of downstream routers/receivers that might be able to 1062 raise a notification. Hence notification messages MAY be 1063 summarized or compressed for operators' ease of management. 1065 o Fault isolation 1066 A solution MUST provide diagnostic/troubleshooting tools for 1067 multicast as well. Also it is anticipated that such tools are 1068 coordinated with the testing mechanisms mentioned in 6.5.2. 1070 In particular, a solution needs to correctly identify the area 1071 inside a multicast group impacted by the failure. A solution 1072 SHOULD be able to diagnose if an entire multicast group is 1073 faulty or if some specific destinations are still alive. 1075 6.6. Security 1077 6.6.1. Security Threat Analysis 1079 In multicast VPLS, there is a concern that one or more customer nodes 1080 (presumably untrusted) might cause multicast-related attacks to the 1081 SP network. There is a danger that it might compromise some 1082 components which belong to the whole system. 1084 This subsection states possible security threats relevant to the 1085 system and which are protected against and which are not. 1087 General security consideration about a base VPLS (as part of L2VPNs) 1088 is referred to [RFC4665]. Following is the threat analysis list 1089 which is inherent to multicast VPLS. 1091 (a) Attack by huge amount of multicast control packets. 1092 There is a threat that a CE joins too many multicast groups and 1093 causes Denial of Service (DoS). This is caused by sending a large 1094 number of packets join/prune messages in short time and/or putting 1095 a large variety of group addresses in join/prune messages. This 1096 attack will waste PE's control resources (e.g., CPU, memory) which 1097 examine customer control messages (for solving issue A in section 1098 3.2.) and it will not continue expected services for other trusted 1099 customers. 1101 (b) Attack by invalid/malformed multicast control packets. 1102 There is a threat that a CE sends invalid or malformed control 1103 packets that might corrupt PE, which will cause DoS attack. In 1104 particular, a CE might be spoofing legitimate source/group IP 1105 multicast addresses in such control packets (in PIM, IGMP etc.) 1106 and source/destination MAC addresses as Layer-2 frame. 1108 (c) Attack by rapid state change of multicast. 1109 If a malicious CE changes multicast state by sending control 1110 packets in an extremely short period, this might affect PE's 1111 control resources (e.g., CPU, memory) to follow such state 1112 changes. Besides, it might also affect PE/P's control resources 1113 if MDTunnel inside the core is dynamically created in conjunction 1114 with customer's multicast group. 1116 (d) Attack by high volume of multicast/broadcast data traffic. 1117 A malicious CE might send very high volume of multicast and/or 1118 broadcast data to a PE. If that PE does not provide any 1119 safeguards, it will cause excessive replication in SP network and 1120 the bandwidth resources for other trusted customers might be 1121 exhausted. 1123 (e) Attack by high volume of unknown destination unicast data 1124 traffic. 1125 A malicious CE can send a high volume of unknown unicast to a PE. 1126 Generally according to VPLS architecture, that PE must flood such 1127 unknown traffic to all correspond PEs in the same VPN. A variety 1128 of unknown destinations and huge amount of such frames might cause 1129 excess traffic in SP network unless there is an appropriate 1130 safeguard provided. 1132 6.6.2. Security Requirements 1134 Based on the analysis in the previous subsection, the security 1135 requirements from the SP's perspective are shown as follows. 1137 A SP network MUST be invulnerable to malformed or maliciously 1138 constructed customer traffic. This applies to both multicast data 1139 packets and multicast control packets. 1141 Moreover, because multicast, broadcast, and unknown-unicast need more 1142 resources than unicast, a SP network MUST have safeguards against 1143 unwanted or malicious multicast traffic. This applies to both 1144 multicast data packets and multicast control packets. 1146 Specifically, a multicast VPLS solution SHOULD have mechanisms to 1147 protect a SP network from: 1149 (1) invalid multicast MAC addresses 1150 (2) invalid multicast IP addresses 1151 (3) malformed Ethernet multicast control protocol frames 1152 (4) malformed IP multicast control protocol packets 1153 (5) high volumes of 1154 * valid/invalid customer control packets 1155 * valid/invalid customer data packets (broadcast/multicast/ 1156 unknown-unicast) 1158 Depending each solution's actual approach to tackle with issue A and 1159 B or both (see section 3.2.), there are relationships to be 1160 highlighted about each item's importance listed above. First off, 1161 protection against (3) and (4) becomes significantly important if a 1162 solution supports solving issue A, and PEs are processing customer's 1163 Ethernet/IP multicast control messages from CE. Moreover protection 1164 against (2) should also be much focused because PIM/IGMP snooping 1165 will usually require that PE's data forwarding be based on IP 1166 addresses. By contrast, however, if a solution is solving only issue 1167 B, not A, then PEs might never process customer's multicast control 1168 messages at all, and they do not perform IP address-based forwarding, 1169 but does native Ethernet forwarding. If so, there is relatively less 1170 danger about (2)(3)(4) compared to the first case. 1172 The following are a few additional guidelines in detail. 1174 For protecting against threat (a), a solution SHOULD support to 1175 impose some bounds on the quantity of state used by a VPN to be 1176 imposed in order to prevent state resource exhaustion (i.e., lack 1177 of memory, CPU etc.). In this case, the bounds MUST be 1178 configurable per VPN basis, not total of various VPNs so that SP 1179 can isolate the resorce waste that is caused by any malicious 1180 customer. 1182 For protecting against threat (d) and (e), a solution SHOULD 1183 support to perform traffic policing to limit the unwanted data 1184 traffic shown above. In this case, while policing MAY be 1185 configurable to the sum of unicast, multicast, broadcast and 1186 unknown unicast traffic, it SHOULD also be configurable to each 1187 such type of traffic individually in order to prevent physical 1188 resource exhaustion (i.e., lack of bandwidth and degradation of 1189 throughput). If the policing limit is configured on total traffic 1190 only, there will be a concern that one customer's huge multicast 1191 might close other irrelevant unicast traffic. If it can be 1192 configured individually, this concern will be avoided. Moreover, 1193 such a policing mechanism MUST be configurable per VPN basis, not 1194 total of various VPNs to isolate malicious customer's traffic from 1195 others. 1197 For protecting against threat (c), a solution SHOULD be able to 1198 limit frequent changes of group membership by customers. For 1199 example, PEs might support a dampening mechanism that throttles 1200 their multicast state changes if the customers are changing too 1201 excessively. Also if MDTunnel is provided being tightly coupled 1202 to dynamic changes of customer's multicast domain, it is also 1203 effective to delay building the tunnel when customer's state is 1204 changed frequently. 1206 Protecting against threat (b) might not be an easy task. 1207 Generally, checking the legitimacy of customer's IP multicast 1208 control packets will eventually require the authentication between 1209 PE and CE in Layer-3; however, L2VPN (including VPLS) by its 1210 nature does not usually assume Layer-3-based security mechanism 1211 supported at PE-CE level. 1212 The ramification of this fact is that there remains possibility 1213 that a PE's control plain might be badly affected by corrupted 1214 multicast control packets that the PE is examining. Hence each PE 1215 implementation will need to make an effort to minimize this impact 1216 from malicious customers and isolate it from other trusted 1217 customers as much as possible. 1218 Nevertheless, it is possible to mitigate this threat to some 1219 degree. For example, a PE MAY support a filter mechanism about 1220 MAC and IP addresses in Layer-2/Layer-3 header and a filter 1221 mechanism about source/group addresses in the multicast join/prune 1222 messages. This will help a PE to validate customers' control 1223 messages, to a certain extent. 1225 6.7. Hierarchical VPLS support 1227 A VPLS multicast solution SHOULD allow a hierarchical VPLS (H-VPLS) 1228 [RFC4762] service model. In other words, a solution is expected to 1229 operate seamlessly with existing hub and spoke PW connectivity. 1231 Note that it is also important to take into account the case of 1232 redundant spoke connections between U-PEs and N-PEs. 1234 6.8. L2VPN Wholesale 1236 A solution MUST allow a situation where one SP is offering L2VPN 1237 services to another SP. One example here is a wholesale model where 1238 one VPLS interconnects other SPs' VPLS or 802.1D network islands. 1239 For customer SP, their multicast forwarding can be optimized by 1240 making use of multicast VPLS in the wholesaler SP. 1242 7. Security Considerations 1244 Security concerns and requirements for a base VPLS solution are 1245 described in [RFC4665]. 1247 In addition, there are security considerations specific to multicast 1248 VPLS. Thus a set of security issues have been identified that MUST 1249 be addressed when considering the design and deployment of multicast 1250 VPLS. Such issues have been described in Section 5.5 and 6.6. 1252 In particular, security requirements from the view of customers are 1253 shown in Section 5.5. Security requirements from the view of 1254 providers are shown in Section 6.6. Section 6.6.1 conducts security 1255 threat analysis about the provider's whole system. Section 6.6.2 1256 explains how each threat can be addressed or mitigated. 1258 8. IANA Considerations 1260 This document has no actions for IANA. 1262 9. Acknowledgments 1264 The authors thank the contributors of [RFC4834] since the structure 1265 and content of this document were, for some sections, largely 1266 inspired by [RFC4834]. 1268 The authors also thank Yuichi Ikejiri, Jerry Ash, Bill Fenner, Vach 1269 Kompella, Shane Amante, Ben Niven-Jenkins and Venu Hemige for their 1270 valuable reviews and feedbacks. 1272 10. References 1274 10.1. Normative References 1276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1277 Requirement Levels", BCP 14, RFC 2119, March 1997. 1279 [RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for 1280 Layer 2 Provider-Provisioned Virtual Private Networks", 1281 RFC 4665, September 2006. 1283 10.2. Informative References 1285 [802.1D] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 Edition 1286 (Revision and redesignation of ISO/IEC 10038:98), "Part 1287 3: Media Access Control (MAC) Bridges", ISO/IEC 15802-3:, 1288 1998. 1290 [802.1ag] IEEE, "Virtual Bridge Local Area Networks: Connectivity 1291 Fault Management (Work in Progress)", 2007. 1293 [802.1s] IEEE Std 802.1s-2002, "Virtual Bridged Local Area 1294 Networks- Amendment 3: Multiple Spanning Trees", 2002. 1296 [CGMP] Farinacci, D., Tweedly, A., and T. Speakman, "Cisco Group 1297 Management Protocol (CGMP)", 1298 ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt , 1996/ 1299 1997. 1301 [I-D.ietf-mpls-ldp-p2mp] 1302 Minei, I., "Label Distribution Protocol Extensions for 1303 Point-to-Multipoint and Multipoint-to-Multipoint Label 1304 Switched Paths", draft-ietf-mpls-ldp-p2mp-05 (work in 1305 progress), June 2008. 1307 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1308 RFC 1112, August 1989. 1310 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 1311 2", RFC 2236, November 1997. 1313 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1314 and W. Weiss, "An Architecture for Differentiated 1315 Services", RFC 2475, December 1998. 1317 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1318 Listener Discovery (MLD) for IPv6", RFC 2710, 1319 October 1999. 1321 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1322 Thyagarajan, "Internet Group Management Protocol, Version 1323 3", RFC 3376, October 2002. 1325 [RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group 1326 Management Protocol (RGMP)", RFC 3488, February 2003. 1328 [RFC3809] Nagarajan, A., "Generic Requirements for Provider 1329 Provisioned Virtual Private Networks (PPVPN)", RFC 3809, 1330 June 2004. 1332 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1333 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1335 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 1336 Independent Multicast - Dense Mode (PIM-DM): Protocol 1337 Specification (Revised)", RFC 3973, January 2005. 1339 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 1340 "Considerations for Internet Group Management Protocol 1341 (IGMP) and Multicast Listener Discovery (MLD) Snooping 1342 Switches", RFC 4541, May 2006. 1344 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1345 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1346 Protocol Specification (Revised)", RFC 4601, August 2006. 1348 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1349 IP", RFC 4607, August 2006. 1351 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 1352 Private Networks (L2VPNs)", RFC 4664, September 2006. 1354 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 1355 (VPLS) Using BGP for Auto-Discovery and Signaling", 1356 RFC 4761, January 2007. 1358 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 1359 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 1360 RFC 4762, January 2007. 1362 [RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3 1363 Provider-Provisioned Virtual Private Networks (PPVPNs)", 1364 RFC 4834, April 2007. 1366 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1367 "Extensions to Resource Reservation Protocol - Traffic 1368 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1369 Switched Paths (LSPs)", RFC 4875, May 2007. 1371 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1372 "Bidirectional Protocol Independent Multicast (BIDIR- 1373 PIM)", RFC 5015, October 2007. 1375 Authors' Addresses 1377 Yuji Kamite (editor) 1378 NTT Communications Corporation 1379 Granpark Tower 1380 3-4-1 Shibaura, Minato-ku 1381 Tokyo 108-8118 1382 Japan 1384 Email: y.kamite@ntt.com 1386 Yuichiro Wada 1387 NTT 1388 3-9-11 Midori-cho 1389 Musashino-shi 1390 Tokyo 180-8585 1391 Japan 1393 Email: wada.yuichiro@lab.ntt.co.jp 1395 Yetik Serbest 1396 AT&T Labs 1397 9505 Arboretum Blvd. 1398 Austin, TX 78759 1399 USA 1401 Email: yetik_serbest@labs.att.com 1403 Thomas Morin 1404 France Telecom R&D 1405 2, avenue Pierre-Marzin 1406 22307 Lannion Cedex 1407 France 1409 Email: thomas.morin@francetelecom.com 1411 Luyuan Fang 1412 Cisco Systems, Inc. 1413 300 Beaver Brook Road 1414 Boxborough, MA 01719 1415 USA 1417 Email: lufang@cisco.com