idnits 2.17.1 draft-ietf-l2vpn-vpms-frmwk-requirements-05.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 (Oct 22, 2012) is 4194 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-l2vpn-vpls-mcast-11 == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-p2mp-pw-requirements-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Kamite 3 Internet-Draft NTT Communications 4 Intended status: Informational F. Jounay 5 Expires: April 25, 2013 Orange CH 6 B. Niven-Jenkins 7 Velocix 8 D. Brungard 9 AT&T 10 L. Jin 11 ZTE 12 Oct 22, 2012 14 Framework and Requirements for Virtual Private Multicast Service (VPMS) 15 draft-ietf-l2vpn-vpms-frmwk-requirements-05.txt 17 Abstract 19 This document provides a framework and service level requirements for 20 Virtual Private Multicast Service (VPMS). VPMS is defined as a Layer 21 2 VPN service that provides point-to-multipoint connectivity for a 22 variety of Layer 2 link layers across an IP or MPLS-enabled PSN. 23 This document outlines architectural service models of VPMS and 24 states generic and high level requirements. This is intended to aid 25 in developing protocols and mechanisms to support VPMS. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 25, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 63 1.2. Scope of This Document . . . . . . . . . . . . . . . . . . 4 64 2. Conventions used in this document . . . . . . . . . . . . . . 5 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. Ethernet Use Case . . . . . . . . . . . . . . . . . . . . 6 69 4.1.1. Ethernet-based multicast stream . . . . . . . . . . . 6 70 4.1.2. Ethernet-based time/frequency synchronization . . . . 7 71 4.2. ATM-based Use Case . . . . . . . . . . . . . . . . . . . . 7 72 4.2.1. ATM-based multicast stream . . . . . . . . . . . . . . 7 73 4.3. TDM-based Use Case . . . . . . . . . . . . . . . . . . . . 8 74 4.3.1. TDM-based multicast stream . . . . . . . . . . . . . . 8 75 5. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 8 76 6. Customer Requirements . . . . . . . . . . . . . . . . . . . . 10 77 6.1. Service Topology . . . . . . . . . . . . . . . . . . . . . 10 78 6.1.1. Point-to-Multipoint Traffic Support . . . . . . . . . 10 79 6.1.2. Reverse Traffic Support . . . . . . . . . . . . . . . 10 80 6.2. Transparency . . . . . . . . . . . . . . . . . . . . . . . 12 81 6.3. Quality of Service (QoS) . . . . . . . . . . . . . . . . . 13 82 6.4. Multi-Source Support . . . . . . . . . . . . . . . . . . . 13 83 6.5. High Availability . . . . . . . . . . . . . . . . . . . . 14 84 6.5.1. Dual-homed Access Support . . . . . . . . . . . . . . 14 85 6.5.2. Single/Dual Traffic Support in Dual-homed Access . . . 17 86 6.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 6.7. Misordering Prevention . . . . . . . . . . . . . . . . . . 17 88 6.8. Failure reporting . . . . . . . . . . . . . . . . . . . . 17 89 7. Service Provider Network Requirements . . . . . . . . . . . . 18 90 7.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 18 91 7.2. Pseudo Wire Signaling and PSN Tunneling . . . . . . . . . 18 92 7.2.1. Point-to-Multipoint Pseudo Wire . . . . . . . . . . . 18 93 7.2.2. PSN Tunneling . . . . . . . . . . . . . . . . . . . . 19 94 7.2.3. Static Solution . . . . . . . . . . . . . . . . . . . 19 95 7.3. Auto-discovery . . . . . . . . . . . . . . . . . . . . . . 19 96 7.4. Activation and Deactivation . . . . . . . . . . . . . . . 21 97 7.5. Inter-AS Support . . . . . . . . . . . . . . . . . . . . . 22 98 7.6. Co-existence with Existing L2VPNs . . . . . . . . . . . . 22 99 7.7. Operation, Administration and Maintenance . . . . . . . . 23 100 7.7.1. Fault Management . . . . . . . . . . . . . . . . . . . 23 101 7.7.2. Testing . . . . . . . . . . . . . . . . . . . . . . . 23 102 7.7.3. Performance Management . . . . . . . . . . . . . . . . 24 103 7.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 24 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 106 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 108 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 109 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 112 1. Introduction 114 1.1. Problem Statement 116 [RFC4664] describes different types of Provider Provisioned Layer 2 117 VPNs (L2 PPVPNs, or L2VPNs). Some of them are widely deployed today, 118 such as Virtual Private Wire Service (VPWS) and Virtual Private LAN 119 Service (VPLS). A VPWS is a VPN service that supplies a Layer 2 (L2) 120 point-to-point service. A VPLS is an L2 service that emulates 121 Ethernet LAN service across a Wide Area Network (WAN). 123 For some use cases described hereafter, there are P2MP (point-to- 124 multipoint) type services for Layer 2 traffic. However, there is no 125 straightforward way to realize them based on the existing L2VPN 126 specifications. 128 In a VPWS, an SP can set up point-to-point connectivity per a pair of 129 CEs but it is not possible to replicate traffic for point-to- 130 multipoint services in the SP's network side. A SP could build 131 multiple Pseudowires (PWs) independently and have the CEs replicate 132 traffic over them, but this is not only inconvenient for the 133 customer, it's a waste of bandwidth resources. 135 In a VPLS, SPs can natively offer multipoint connectivity across 136 their backbone. Although it is seemingly applicable for point-to- 137 multipoint service as well, there remains extra complexity for SPs to 138 filter unnecessary traffic between irrelevant sites (i.e., from a 139 receiver PE to another receiver PE) because VPLS provides multipoint- 140 to-multipoint connectivity between CEs. Moreover, VPLS's MAC-based 141 learning/forwarding operation is unnecessary for some scenarios 142 particularly if customers only need simple unidirectional point-to- 143 multipoint service, or if they require non- Ethernet Layer 2 144 connectivity. 146 Consequently, there is a real need for a solution that natively 147 provides point-to-multipoint service in L2VPN. 149 1.2. Scope of This Document 151 VPMS is defined as a Layer 2 service that provides point-to- 152 multipoint connectivity for a variety of Layer2 link layers across an 153 IP or MPLS-enabled PSN. VPMS is categorized as a class of provider- 154 provisioned Layer 2 Virtual Private Networks (L2VPN). 156 This document introduces a new service framework, reference model and 157 functional requirements for VPMS by extending the existing framework 158 [RFC4664] and requirements [RFC4665] for L2VPNs. 160 The technical specifications are outside the scope of this document. 161 There is no intent to specify solution-specific details. 163 This document provides requirements from both the Service Provider's 164 and the Customer's point of view. 166 2. Conventions used in this document 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [RFC2119] . 172 3. Terminology 174 The content of this document makes use of the terminology defined in 175 [RFC4026]. For readability purposes, we list some of the terms here 176 in addition to some specific terms used in this document. 178 3.1. Acronyms 180 P2P: Point-to-Point 182 P2MP: Point-to-Multipoint 184 PW: Pseudowire 186 VPMS: Virtual Private Multicast Service 188 PE/CE: Provider/Customer Edge 190 P: Provider Router 192 AC: Attachment Circuit 194 PSN: Packet Switched Network 196 SP: Service Provider 198 VPMS instance: A service entity manageable in a VPMS that provides 199 isolated service reachability domain to each CE. It corresponds 200 to a so-called "VPN" as a specific set of sites that allows 201 communication. 203 P2MP connection: A logical entity between PE/ACs in a given VPMS 204 instance that transfers unidirectional traffic transparently from 205 one local ingress AC to one or more remote egress ACs. 207 4. Use Cases 209 4.1. Ethernet Use Case 211 4.1.1. Ethernet-based multicast stream 213 For multicast traffic delivery, there is a requirement to deliver a 214 unidirectional P2MP service in addition to the existing P2P service. 215 The demand is growing to provide private (P2MP native Ethernet) 216 services, for various applications such as IP- based delivery of TV 217 broadcasting, content delivery networks, etc. Moreover, many digital 218 audio/video devices (e.g., MPEG-TS, HD-SDI) that support Ethernet 219 interfaces are becoming available, which will make Ethernet P2MP 220 service more common. Also there are some applications that naturally 221 suited to static transport of VPMS. For example, MPEG-TS/IP/Ethernet 222 in DVB-H is typically static broadcast without any signaling in the 223 upstream direction. VPMS could be a possible solution to provide 224 these kinds of networking connectivity over PSNs. 226 Currently VPLS [RFC4761][RFC4762] is able to give P2MP-type 227 replication for Ethernet traffic. Native VPLS already supports this 228 capability via a full mesh of PWs, and an extension to optimize 229 replication is also proposed [I-D.ietf-l2vpn-vpls-mcast] as an 230 additional feature. However, VPLS by nature requires MAC-based 231 learning and forwarding, which might not be needed in some cases by 232 particular users. Generally, video distribution applications use 233 unidirectional P2MP traffic, but may not always require any added 234 complexity of MAC address management. In addition, VPLS is a service 235 that essentially provides any-to-any connectivity between all CEs in 236 a L2VPN as it emulates a LAN service. However, if only P2MP 237 connectivity is required, the traffic between leaf nodes is not 238 allowed. It might require extra efforts to guarantee this behavior 239 in VPLS. And in some P2MP scenarios there no traffic from leafs to 240 root. In these cases, VPMS is a service that provides much simpler 241 operation. 243 Note that VPMS provides single coverage of receiver membership; that 244 is, there is no distinct differentiation for multiple multicast 245 groups in one VPN. All traffic from a particular Attachment Circuit 246 (AC) will be forwarded toward the same remote receivers, even if the 247 destination MAC address is changed. Basically in VPMS, destination 248 MAC addresses are not used for forwarding, which is significantly 249 different from VPLS. If MAC-based forwarding is preferred (i.e., 250 multicast/unicast differentiation by MAC address), VPLS should be 251 chosen rather than VPMS. 253 4.1.2. Ethernet-based time/frequency synchronization 255 Nowadays there exist several solutions to provide synchronization for 256 time and/or frequency reference by the packet-based technology of 257 Ethernet. For example, PTPv2 (Precision Time Protocol version 2) is 258 a time-transfer protocol defined in the IEEE 1588-2008 standard. It 259 provides precise synchronization of packet-based networks (e.g., 260 Ethernet). It adopts two-way time transfer approach for 261 synchronization. Time transfer protocol may be operated in multicast 262 or unicast mode in both directions, and it is mapped over the 263 Ethernet/IP/UDP protocol stack. 265 Moreover, PTPv2 telecom profile is now discussed in ITU-T that 266 defines a set of capabilities and extensions required to support 267 telecommunication applications. It aims at providing frequency 268 distribution with higher level of accuracy. It allows unicast mode 269 or the mix of unicast/multicast modes for the transmission of the PTP 270 messages. 272 In this aspect, VPMS might be considered as a potential packet-based 273 infrastructure to deliver multicast messages in PTPv2 with efficient 274 forwarding. Note, however, in PTPv2 telecom profile, multicast 275 transport may not always be supported in all the parts of a telecom 276 network because multicast might sometimes generate additional PDV 277 (packet delay variation) compared to unicast. Therefore, VPMS use 278 case and the corresponding solution for this purpose will need more 279 study in the future (e.g., PDV issue to be checked). 281 4.2. ATM-based Use Case 283 4.2.1. ATM-based multicast stream 285 A use case of ATM-based service in VPMS could be to offer the 286 capability for service providers to support IP multicast wholesale 287 services over ATM in case the wholesale customer relies on ATM 288 infrastructure. The P2MP support alleviates the constraint in terms 289 of replication for ATM to support IP multicast services. 291 Another use case of VPMS for ATM is for audio/video stream 292 applications. Today many digital TV broadcasting networks adopt ATM- 293 based distribution systems with point-to-multipoint PVPs/PVCs. The 294 transport network supports replicating ATM cells in transit nodes to 295 efficiently deliver programs to multiple terminals. For migrating 296 such ATM-based networks onto IP/MPLS-based networks, VPMS is 297 considered to be a candidate solution. 299 4.3. TDM-based Use Case 301 4.3.1. TDM-based multicast stream 303 Today the existing VPWS already supports TDM emulation services 304 (SAToP, CESoPSN or TDMoIP). It is a Layer 1 service, not Layer 2 305 service; however, a common architecture is being used since they are 306 all packet-based emulations over a SP's network. VPMS is also 307 considered to be a solution for such TDM applications that require 308 point-to-multipoint topology. 310 One use case is TDM-based multicast stream delivery, like video 311 delivery. That is, data duplication is simply provided by Layer 1, 312 without using upper layer's multicast protocols. 314 5. Reference Model 316 The VPMS reference model is shown in Figure 1. 318 +-----+ AC1 AC2 +-----+ 319 | CE1 |>---+ ------------------------ +--->| CE2 | 320 +-----+ | | VPMS A's P2MP | | +-----+ 321 VPMS A | +------+ Connection +------+ | VPMS A 322 Sender +->|......>...+.......... >......|>-+ Receiver 323 | VPMS | . | VPMS | 324 | PE1 | . | PE2 | 325 +-<|......<.. . ....+.....<......|<-+ 326 | +------+ . . +------+ | 327 +-----+ | | . . | | +-----+ 328 | CE4 |<---+ |Routed . . VPMS B's P2MP +---<| CE3 | 329 +-----+ AC4 |Backbone. . Connection AC3 +-----+ 330 VPMS B | . . | VPMS B 331 Receiver | +-v-----v-+ | Sender 332 ------| . . |------- 333 | . VPMS. | 334 | . PE3 . | 335 +---------+ 336 v v VPMS A: 337 | | Root AC : AC1 338 AC5| |AC6 Leaf AC : AC2, AC5 339 v v VPMS B: 340 +-----+ +-----+ Root AC : AC3 341 | CE5 | | CE6 | Leaf AC : AC4, AC6 342 +-----+ +-----+ 343 VPMS A VPMS B 344 Receiver Receiver 346 Figure 1: Reference Model for VPMS 348 A VPMS instance is defined as a service entity manageable in the VPMS 349 architecture. A single VPMS instance provides an isolated service 350 reachability domain to each CE, so it corresponds to a so-called 351 "VPN" as it allows communication among a specific set of sites. A 352 single VPMS instance provides a unique point-to-multipoint L2VPN 353 service. In Figure 1, there are two VPMS instances shown, VPMS A and 354 VPMS B. In principle, there is no traffic exchange allowed between 355 these different instances, so they are treated as different VPNs. 357 In a VPMS, a single CE-PE link connection is used for transmitting 358 frames for delivery to multiple remote CEs, with point-to-multipoint 359 duplication. The SP's network (PE as well as P) has a role to 360 replicate frames so that the sender's CE does not need to send 361 multiple frames to individual receivers. 363 Like VPWS, an Attachment Circuit (AC) is provided to accommodate CEs 364 in a VPMS. In a VPMS, an AC attached to a VPMS MUST be configured as 365 "root" (sender) or "leaf" (receiver) not both. Any AC is associated 366 with the role of either sending side (Tx) or receiving side (Rx) from 367 the view of the CE. These will be named the root (sender) AC and 368 leaf (receiver) AC respectively. Unless reverse traffic is 369 optionally supported, a root AC does not transmit traffic back to a 370 CE at upstream side, likewise a leaf AC does not receive traffic from 371 a CE at downstream side. In Figure 1, AC1 and AC3 are configured as 372 root ACs while AC2, AC4, AC5 and AC6 are configured as leaf ACs. In 373 VPMS A, CE1 could send traffic via AC1, and CE2 and CE5 could receive 374 the traffic. 376 A CE which is locally connected to a root AC is called a root 377 (sender) CE. Also a CE which is locally connected to a leaf AC is 378 called a leaf (receiver) CE. However, such CEs's roles will not be 379 managed directly in VPMS because the configured AC's role (root or 380 leaf) will automatically determine them. 382 Similarly, a PE which locally accommodates a root AC is called a root 383 (sender) PE. A PE which locally accommodates a leaf AC is called a 384 leaf (receiver) PE. 386 Root AC and leaf ACs are typically located at separate PEs as shown 387 in Figure 1, but it is also allowed that a single PE locally has both 388 a root AC and one or more leaf ACs. 390 Basically there is a one-to-one mapping between an attachment circuit 391 and a VPMS instance. For example, all traffic from CE1 to PE1 392 (through AC1) is mapped to VPMS A (to CE2 and CE5). 394 In a VPMS, P2MP tree-shaped reachability is given from a single root 395 AC to several leaf ACs. This will be named a "P2MP connection" in 396 this VPMS framework. P2MP connection is a logical entity between PE/ 397 ACs in a given VPMS instance that transfers unidirectional traffic 398 transparently from one local ingress AC to one or more remote egress 399 ACs. 401 Similar to other L2VPN mechanisms, the VPMS architecture is based on 402 PWs which may be using through IP or MPLS-enabled PSN tunnels over a 403 routed backbone. That is, every P2MP connection can be instantiated 404 by PW technology that supports P2MP traffic optimization (i.e., P2MP 405 PW. See section 7.2.). P2MP traffic optimization will provide the 406 benefit of traffic replication for high bandwidth efficiency. That 407 is, the sender CE has only to transmit one stream towards the PE and 408 it does not have to replicate traffic. 410 Regarding end-to-end traffic topology between the ACs, a single VPMS 411 instance (i.e., one VPN) may correspond to a single P2MP connection. 412 In Figure 1, VPMS A (one instance) has one P2MP connection (from AC1 413 to AC2 and AC5). However, there is also a case that a single VPMS 414 consists of two or more P2MP connections grouped, which is typically 415 used for multi-source or redundancy. The details are given in 416 section 6.4 and 6.5. 418 VPMS can support various Layer 2 protocol services such as Ethernet, 419 ATM, etc. 421 6. Customer Requirements 423 6.1. Service Topology 425 6.1.1. Point-to-Multipoint Traffic Support 427 A solution MUST support unidirectional point-to-multipoint traffic 428 from a sender CE to multiple receiver CEs. A root CE can send 429 traffic to one or more leaf CEs. Leaf CEs include not only the CEs 430 which are located at remote sites, but also the local CEs which are 431 connected to the same root PE (i.e., when a root AC and some of leaf 432 ACs are co-located). If there is only one receiver in the instance, 433 it is considered equivalent to unidirectional point-to-point traffic. 435 6.1.2. Reverse Traffic Support 437 There are cases where a reverse traffic flow is needed. A root CE 438 may need to receive traffic from leaf CEs. There are some usage 439 scenarios for this, such as stream monitoring through a loopback 440 mechanism, control channels which need feedback communication etc. A 441 possible way to accomplish this is to provide different VPMS 442 instances for reverse traffic, i.e. a root CE is a receiver of 443 another VPMS instance. However, provisioning different VPNs for a 444 particular customer would make its management task more complex. It 445 is desired to have an alternative solution for supporting reverse 446 traffic flow. This section provides additional requirements for this 447 optional capability. 449 Therefore, a VPMS solution MAY support reverse traffic from a leaf AC 450 to a root AC. Each reverse path is basically given in a P2P 451 (unicast) manner. In other words, each leaf of the P2MP tree can 452 individually send back traffic to the root. For this purpose a VPMS 453 instance MAY have more than one reverse P2P connections as network 454 entity; However, such network entities MUST have a common indetifier 455 that enables themselves to be managed together in the same VPN. Thus 456 any PWs used for such connections are expected to be assigned a 457 common VPMS instance ID (i.e., VPN ID). 459 Note, a VPMS does not assume any-to-any multipoint reachability. 460 Therefore, in principle, every leaf AC does not need to exchange 461 traffic directly with other leaf ACs even if reverse traffic is 462 supported. 464 Figure 3 illustrates this kind of scenario, where CE1 is configured 465 as a sender in VPMS A. AC1 is a root AC, and AC2/AC3/AC4 are leaf 466 ACs. P2MP connection is given for traffic in the forward direction. 467 Unidirectional P2P connection is also provided for traffic in the 468 reverse direction, from AC4 to AC1. Other reverse P2P connections 469 can be provided similarly. (from AC2 to AC1 / from AC3 to AC1). 471 In this case, PEs need to deal with two types of traffic, locally- 472 attached CE's sending (Tx) and receiving (Rx) flows. In Figure 3, 473 they are both passing through the same physical PE-CE link (AC1 and 474 AC4 respectively). But it is an implementation matter if Tx and Rx 475 traffic are conveyed on the same physical link or separate links. It 476 is also possible that a root PE multiplexes two ore more reverse 477 traffic from different leaf ACs and transmits it to an upstream CE 478 over the same local physical link. 480 Note, in most implementations of VPWS today, every AC is always 481 considered bidirectional. In contrast, in VPMS, every AC can be 482 chosen unidirectional (if it is a totally unidirectional service), or 483 bidirectional (if reverse traffic is supported). 485 +-----+ <-- Rx (bidirectional) 486 | CE1 |--------------+ 487 +-----+ --> Tx | 488 VPMS A Sender | 489 AC1 | 490 +----------+ VPMS 491 | . . | PE1 492 | . .... | 493 -------| . . |-------- 494 | P2MP +-v------^-+ | 495 Connection . . | 496 (forward) + . | 497 | . . | 498 +------+ . . . . +------+ 499 +-<|......<.. . .. . ......>..... |>-+ 500 | | VPMS | . . | VPMS | | 501 AC2| | PE2 | . . | PE3 | |AC3 502 | +------+ . . +------+ | 503 +-----+ | | . . P2P | | +-----+ 504 | CE2 |<--+ | Routed . . Connection +-->| CE3 | 505 +-----+ <-- | Backbone. . (reverse)| --> +-----+ 506 VPMS A Rx | +-v------^-+ | Rx VPMS A 507 Receiver -------| . . |-------- Receiver 508 | . .... | 509 | . . | VPMS 510 +----------+ PE4 511 AC4| 512 | 513 | <-- Tx +-----+ 514 +--------------------| CE4 | 515 (bidirectional) --> Rx +-----+ 516 VPMS A 517 Receiver 519 Figure 3: Reverse traffic support 521 6.2. Transparency 523 A solution is intended to provide Layer-2 traffic transparency. 524 Transparency SHOULD be supported per VPMS instance basis. In other 525 words, Layer-2 traffic can be transparently transported from a local 526 CE to remote CEs in a given instance. Note, however, if service 527 delimiting fields (VLAN Id in Ethernet, VPI/VCI in ATM, DLCI in FR 528 etc.) are assigned and possibly can be changed by the SP, the Layer-2 529 traffic is not necessarily transparent. It will depend on the SP's 530 choice if they assign it to each AC. Hence, it could be that some of 531 the leaf CEs are receiving traffic that has different delimiting 532 fields than the traffic for the other leaf CEs. 534 The VPMS solution SHOULD NOT require any special packet processing by 535 the end users (CEs). 537 6.3. Quality of Service (QoS) 539 A customer may require that the VPMS service provide guaranteed QoS. 540 In particular, for real time applications which are considered common 541 in point-to-multipoint delivery, delay and loss sensitive traffic 542 MUST be supported. The solution SHOULD provide native QoS techniques 543 for service class differentiation, such as IEEE 802.1p CoS for 544 Ethernet. 546 For bandwidth committed services (e.g., ATM CBR (Constant Bit Rate)), 547 a solution SHOULD guarantee end-to-end bandwidth. It MAY provide 548 flow admission control mechanisms to achieve that. 550 6.4. Multi-Source Support 552 A VPMS solution SHOULD support multiple sources in each VPN. That 553 is, two or more sender CEs can exist in the same VPMS instance. Each 554 sender CE SHOULD be able to be connected to physically separate root 555 PEs, which will facilitate flexible topology design. 557 Additionally, traffic from sender CEs MAY have a common single 558 coverage to receiver CEs, i.e., data from any sources can reach the 559 same group of receivers. For example, in TV provisioning scenario, 560 customers may need to receive two or more TV channels from different 561 sources. In figure 3, suppose there are 7 hosts, CE1 to CE7 which 562 belong to a given VPMS instance A. CE1, CE2 and CE3 are common 563 sources of this VPN, and are attached to different PEs respectively. 564 Traffic from each source can reach the same group of receivers, CE4 565 to CE7. 567 This kind of scenario will require multiple P2MP connections in a 568 single VPMS instance (i.e., VPN). Each P2MP connection's root might 569 be a completely different CE/AC, but leaf CE/ACs are overlapped. 570 Since this is basically the same requirement as dual-homed scenario, 571 see section 6.5.1 for details. 573 VPMS A +-----+ +-----+ VPMS A 574 Sender | CE1 | | CE2 | Sender 575 +-----+ +-----+ 576 | | 577 +-----+ VPMS A v AC1 v AC2 578 | CE3 | Sender +----+ +----+ 579 +-----+ -----|VPMS|-----|VPMS|----- 580 \ | | PE1| | PE2| | 581 \ | +----+ +----+ | 582 \ | | 583 \ AC3 +----+ +----+ 584 +---->|VPMS| |VPMS| AC5 VPMS A 585 | PE3| Routed | PE4|-----+ Receiver 586 +----+ Backbone +----+ | +-----+ 587 / | | \ +-->| CE5 | 588 AC4 / | | \ +-----+ 589 / | | \ AC6 590 +-----+ / | +----+ | \ +-----+ 591 | CE4 |<--+ -----------|VPMS|---------- +->| CE6 | 592 +-----+ | PE5| +-----+ 593 VPMS A +----+ VPMS A 594 Receiver | AC7 Receiver 595 v 596 +-----+ 597 | CE7 | VPMS A 598 +-----+ Receiver 600 Figure 3: Multi-Source support 602 6.5. High Availability 604 A solution MUST provide protection and restoration mechanism for end- 605 to-end services to ensure high availability. 607 There are multiple parts of the connection that can support 608 protection and restoration: (1) CE to PE, (2) between PEs (3) inside 609 core (PSN backbone). It is expected that (3) is fulfilled by 610 existing PSN protection mechanisms (e.g., RSVP-TE FRR). Following 611 subsections covers the requirements for redundancy support for (1) 612 and (2). 614 6.5.1. Dual-homed Access Support 616 A solution MUST allow dual-homed redundant access from a CE to 617 multiple PEs. This if beneficial to support reliable data delivery 618 for customers. Figure 4 provides an example of this access topology. 620 +-----+ 621 | CE1 |--------------+ 622 +-----+ \ 623 VPMS A | | 624 Sender | v AC1 625 (dual-homed)| +----+ 626 | -----|VPMS|-------- 627 | | | PE1| | 628 \ | +----+ | 629 \ AC2 +----+ +----+ AC4 630 +------>|VPMS| |VPMS|------------+ 631 | PE2| Routed | PE3| \ 632 +----+ Backbone +----+\ | 633 AC3 / | | \ AC5 v 634 +-----+ / | | \ +-----+ 635 | CE2 |<-+ | | \ | CE3 | 636 +-----+ | +----+ | \ +-----+ 637 VPMS A ----|VPMS|--------- \ VPMS A 638 Receiver | PE4| | Receiver 639 +----+ | 640 | AC6 v 641 \ +-----+ 642 +--------------->| CE4 | 643 +-----+ 644 VPMS A 645 Receiver 646 (dual-homed) 648 Figure 4: Dual-homing support 650 A solution SHOULD provide a protection mechanism between the 651 redundant PEs to which a CE is dual-homed. This is because when an 652 ingress root PE node fails whole traffic delivery will fail unless a 653 backup root PE is provided, even in case of dual-homed access. 654 Similarly, if an egress leaf PE node fails, traffic toward that CE is 655 never received unless a backup leaf PE is provided. 657 In some cases, the data source is required to be highly reliable 658 since it is often deployed as a centralized server that provides 659 traffic to many receivers. Therefore, there is an additional 660 requirement specifically about redundancy of root-side: each VPMS 661 instance SHOULD be able to have multiple P2MP connections whose roots 662 are located at separate root ACs. Those root ACs can be located at 663 physically separate root PEs, whereas those trees will share common 664 leaf ACs. This means that each P2MP connection has a single root AC, 665 but several P2MP connections can be managed together inside a common 666 VPMS (i.e, VPN). 668 For example, in Figure 5, traffic from root AC1 and AC2 both reach 669 receivers CE3 and CE4 while AC1, AC2, AC3 and AC4 all are associated 670 with a single VPMS instance. This topology is reliable since there 671 are redundant root PE/ACs. At the egress side, PE3 and PE4 select 672 traffic from either root, PE1 or PE2. In this figure, each leaf PE 673 has one leaf AC only (AC3 attached to PE3, and AC4 attached to PE4). 674 Therefore, PEs will need to support PW protection and restoration 675 mechanism so that two redundant P2MP connections are given among 676 common ACs. 678 +-----+ AC2 679 | CE1 |>--------------------------------------------+ 680 +-----+ | 681 AC1v VPMS A | 682 | Sender ----------------------------- | 683 | | VPMS A's P2MP | | 684 | +------+ Connection-2 +------+ | 685 +------->|......>.. .............+..<......|<-+ 686 Tx | VPMS | . . . | VPMS | Tx 687 | PE 1 | . . . | PE 2 | 688 | | . . . | | 689 +------+ . . . +------+ 690 | . . . | 691 VPMS A's P2MP +.. . ...... . | 692 Connection-1 . . . . | 693 | . . . . | 694 | +-v----v-+ +-v----v-+ | 695 ---| . . |---| . . |--- 696 VPMS| . . | | . . |VPMS 697 PE 3| . | | . |PE 4 698 +--------+ +--------+ 699 v v 700 AC3| |AC4 701 v v 702 +-----+ +-----+ 703 | CE3 | | CE4 | 704 +-----+ +-----+ 705 VPMS A VPMS A 706 Receiver Receiver 708 Figure 5: Multiple P2MP connections in Dual-homed Sender 710 6.5.2. Single/Dual Traffic Support in Dual-homed Access 712 When dual-homed access to root PEs is provided, a solution MAY allow 713 a sender CE to transmit just a single copy of the traffic to either 714 one of the two root (ingress) PEs or to transmit a copy of the 715 traffic to both the PEs simultaneously. The latter scenario consumes 716 more resource of CE-PE link than the single traffic scenario, but it 717 is usually applicable when a source device has only a simple 718 forwarding capability without any switchover functionality. In such 719 a dual traffic case, the backup root (ingress) PE SHOULD be able to 720 filter the incoming unnecessary traffic while the other root PE is 721 active if it is needed by SP. In either case, single traffic or dual 722 traffic, the switchover mechanism between root (ingress) PEs will be 723 necessary to handle traffic appropriately in case of failure. 725 In the case of dual-homed access to leaf PEs, a solution MAY allow a 726 receiver CE to receive a single copy of the traffic from either one 727 of the two leaf (egress) PEs, or receive a copy of the traffic from 728 both PEs simultaneously. The dual traffic approach is applicable if 729 CE has fast switchover capability as a receiver by selecting either 730 one of incoming traffic, but note that additional traffic resources 731 are always consumed at PE-CE link of backup side. Specifically in 732 the single traffic case, it might be needed to support switchover 733 mechanism between egress PEs in case of failure. 735 6.6. Security 737 The basic security requirements from the view of customers are raised 738 in section 6.5 of [RFC4665]. It also applies to VPMS. 740 In addition, a VPMS solution MAY have the mechanisms to activate the 741 appropriate filtering capabilities (for example, MAC/VLAN filtering 742 etc.), and it MAY be added with the control mechanism between 743 particular sender/receiver sites inside a VPMS instance. For 744 example, in Figure 1, filtering can be added such that traffic from 745 CE1 to CE4/CE5 is allowed but traffic from CE1 to CE6 is filtered. 747 6.7. Misordering Prevention 749 A solution SHOULD prevent Layer-2 frame misordering when delivering 750 customer traffic under normal conditions. This is often necessary 751 for real-time based applications. 753 6.8. Failure reporting 755 A solution MAY provide information to the customer about failures. 756 For example, if there is a loss of connectivity toward some of the 757 receiver CEs, it is reported to the sender CE. 759 7. Service Provider Network Requirements 761 7.1. Scalability 763 A VPMS solution MUST be designed to scale well with an increase in 764 the number of any of the following metrics: 766 - the number of PEs (per VPMS instance and total in a SP network) 767 - the number of VPMS instances (per PE and total) 768 - the number of root ACs / sender CEs (per PE, VPMS instance and 769 total) 770 - the number of leaf ACs / receiver CEs (per PE, VPMS instance and 771 total) 773 A VPMS solution SHALL document its scalability characteristics in 774 quantitative terms. A solution SHOULD quantify the amount of state 775 that a PE and a P device has to support. 777 The scalability characteristics SHOULD include: 779 - the processing resources required by the control plane in managing 780 PWs (neighborhood or session maintenance messages, keepalives, 781 timers, etc.) 782 - the processing resources required by the control plane in managing 783 PSN tunnels 784 - the memory resources needed for the control plane 785 - other particular elements inherent to each solution that impact 786 scalability 788 7.2. Pseudo Wire Signaling and PSN Tunneling 790 As for data plane format and its processing procedures, VPMS solution 791 MUST support encapsulation scheme that is based on the existing 792 standard PW architecture [RFC3985]. 794 A VPMS solution SHOULD provide an efficient replication that can 795 contribute to optimizing the bandwidth usage required in a SP's 796 network. For supporting efficient replication, it is expected to 797 take advantage of PW and PSN mechanisms that are capable of P2MP 798 traffic. 800 7.2.1. Point-to-Multipoint Pseudo Wire 802 Regarding PW mechanism, [I-D.ietf-pwe3-p2mp-pw-requirements] 803 introduces P2MP PW concept and its requirements, showing two basic 804 approaches of providing replication. One is SS (Single Segment)-PW 805 model that provides replication by PSN tunnel such as P2MP LSP (i.e., 806 by outer label layer), and the other is MS (Multi Segment)-PW model 807 that provides replication by multiple interconnected PWs (i.e., by 808 inner label layer). In either case, end-to-end P2MP topology (i.e., 809 P2MP connection) in VPMS is common from the view of ACs. 810 Requirements as a provider service specified in this document will be 811 commonly applied regardless of P2MP PW's model. 813 It is out of scope of this document how to extend and use PW 814 mechanisms to realize P2MP connections as a solution. For example, 815 it is under the scope of the solution work how to support forward/ 816 reverse traffic by a single PW signaling, coupling multiple PWs, or 817 other ways. 819 7.2.2. PSN Tunneling 821 Today, there are several standardized PSN tunneling schemes and their 822 control plane protocols that support efficient multicast data 823 replication in MPLS, such as P2MP RSVP-TE [RFC4875] and MLDP 824 [RFC6388]. 826 In general, this document does not restrict which control plane 827 protocols should be mandatory. There is no mandatory limitation 828 either, about a particular type of data replication topology in PSN 829 tunneling (point-to-point, point-to-multipoint and multipoint-to- 830 multipoint). 832 In VPMS, the preferred type of PSN tunneling will depend on each 833 deployment scenario. (e.g., which control plane protocol is available 834 in the core and how much of the network resources that operators will 835 want to optimize). The detailed mechanism needs to be specified by 836 solution work. 838 7.2.3. Static Solution 840 VPMS solution MAY support static provisioning for PWs and/or PSN 841 tunneling. Due to some operational reasons, there is a scenario 842 where control plane protocol is not used between PSN nodes. In this 843 case, operators will need to have a different method to set up PWs 844 and/or PSN tunnels (e.g., by manual configuration or other outband 845 interfaces). 847 7.3. Auto-discovery 849 A solution SHOULD support auto-discovery methods that dynamically 850 allow VPMS related information to be discovered by the PEs to 851 minimize the amount of configuration the SP must perform. 853 All of the requirements on discovery described in Section 7.3 of 854 [RFC4665] SHOULD be satisfied in VPMS as well. 856 Auto-discovery will help operators' initial configuration of adding a 857 new VPN (i.e., VPMS instance), adding/deleting new sender/receiver, 858 and so on. 860 The candidate information treated in auto-discovery will be as 861 follows: 863 - Information to indentify the location of each PE, e.g., PE router 864 ID / IP address 865 - Information to identify the VPMS instance, that is, to identify a 866 VPN 867 - Information to identify the type of ACs (root AC or leaf AC) 868 - Information to identify the P2MP connection that binds ACs 869 - Information to show if reverse traffic support is optionally 870 desired 871 - SP-related information (AS number, etc. for an inter-provider 872 case) 874 Following is an example scenario about adding a new leaf PE: suppose 875 there are three PEs in an existing VPMS, PE1, PE2, PE3. PE1 is a 876 root PE and has a AC1. PE2 and PE3 are leaf PEs and have AC2 and 877 AC3. every PE has the association among the information described 878 above. Now a new PE4 having an AC4 is provisioned in the existing 879 VPMS instance and this AC is configured as leaf. This information 880 will be automatically discovered by the other existing remote PEs 881 (i.e., ingress and egress PEs in the same VPMS instance). Once the 882 ingress PE1 discovers this new PE/AC, it can automatically add AC4 as 883 the new leaf of P2MP connection topology according to P2MP PW 884 signaling mechanism. The ingress PE1 will graft a new leaf (PE4) to 885 the already existing P2MP connection which is now created from AC1 to 886 AC2/AC3/AC4. This operation does not require any new configuration 887 at the existing PEs. 889 Another example is about adding a new root PE: suppose there are one 890 root PE (PE1/AC1) and three leaf PEs (PE2/AC2, PE3/AC3 and PE4/AC4). 891 There is an existing P2MP connection from AC1 to AC2/AC3/AC4. Now 892 the operator adds a new root PE/AC (PE5/AC5) for some reasons (e.g., 893 multiple source sites, dual-homed access, root PE redundancy etc.). 894 Then, auto-discovery mechanism advertises this information to all 895 other members PE1/PE2/PE3/PE4, and a new P2MP connection from AC5 to 896 AC2/AC3/AC4 is created by PW signaling. 898 Note that VPMS instance is created when one root AC and at least one 899 leaf AC are added. In principle VPMS requires such minimum 900 provisioning. Hence in dual-homing case of sender, only backup root 901 PE can be dynamically added/deleted to/from VPMS without destroying 902 the VPN. 904 7.4. Activation and Deactivation 906 A solution SHOULD provide a way to activate/deactivate the 907 administrative status of each AC. After initial provisioning, an SP 908 might change connectivity configuration between particular CEs inside 909 a single VPMS instance for operational reasons. This feature will be 910 beneficial to help such a scenario. 912 For example, in Figure 6, AC1, AC3, AC4 and AC5 are initially 913 provisioned for VPMS A. AC2 is not provisioned for any VPMSes. In 914 VPMS A, CE1 is a sender and CE3, CE4 and CE5 are receivers. Traffic 915 will usually flow from CE1 to all receivers, CE3, CE4 and CE5. 916 However, for maintenance operation, application's request (e.g., 917 stream program has changed) or some other reasons, AC4 needs to be 918 set as administratively deactivated. Then it becomes necessary to 919 turn off traffic from PE4 to CE4. This operation must be 920 appropriately distinguished from failure cases. 922 When deactivating a particular site, backbone PSN/PW resources (e.g., 923 admission control of PSN tunnel) MAY be released for that particular 924 direction in order to provide that bandwidth to other services. In 925 Figure 6, AC3 is now administratively activated and receiving 926 traffic. However, if AC3 comes to be administratively deactivated, 927 and if RSVP-TE (including P2P and/or P2MP) is used for backbone PSN, 928 then TE reserved resources from PE1 to PE3 may be released. 930 In addition, a solution SHOULD allow single-sided activation 931 operation at a root (ingress) PE. In some scenarios, operators 932 prefer centralized operation. This is often considered natural for 933 one-way digital audio/video distribution applications: SPs often want 934 to complete their service delivery by a single operation at one 935 source PE, not by multiple operations at many leaf (egress) PEs. 936 Figure 6 illustrates this scenario, where a SP only has to do single- 937 sided operation at PE1 (source) to administratively activate/ 938 deactivate various connections from AC1 to AC3, AC4 and/or AC5. It 939 is not needed to perform operations on PE3 and PE4 directly. 941 +-----+ AC1 942 + CE1 +----------------+ 943 +-----+ | 944 VPMS A Sender | 945 (sending now) v 946 +----+ 947 -----|VPMS|-------- 948 | | PE1| | 949 | +----+ | 950 +----+ +----+ 951 |VPMS| |VPMS| 952 | PE2| Routed | PE3| 953 AC2 +----+ Backbone +----+ AC3 954 (not provisioned) / | | \ 955 +-----+ / | | \ +-----+ 956 + CE2 +<-+ | | +->| CE3 | 957 +-----+ | +----+ | +-----+ 958 (not receiving) ----|VPMS|--------- VPMS A Receiver 959 | PE4| (receiving now) 960 +----+ 961 AC5 / \ AC4 962 +-----+ / \ +-----+ 963 + CE5 +<----------+ +---------------->| CE4 | 964 +-----+ +-----+ 965 VPMS A Receiver VPMS A Receiver 966 (receiving now) (not receiving) 968 AC1: Administratively activated 969 AC2: No VPMS provisioned 970 AC3: Administratively activated 971 AC4: Administratively deactivated 972 AC5: Administratively activated 974 Figure 6: Site activation and deactivation 976 7.5. Inter-AS Support 978 A solution SHOULD support inter-AS scenarios, where there is more 979 than one provider providing a common VPMS instance and VPN. More 980 specifically, it is necessary to consider the case where some of the 981 PEs that compose one VPMS belong to several different ASes. 983 7.6. Co-existence with Existing L2VPNs 985 A solution MUST co-exist with the existing L2VPNs (e.g., VPWS, VPLS) 986 across the same SP's network. A solution MUST NOT impede the 987 operation of auto-discovery and signaling mechanism that are already 988 supported by the PEs for those existing L2VPNs. 990 7.7. Operation, Administration and Maintenance 992 7.7.1. Fault Management 994 7.7.1.1. Fault Detection 996 A solution MUST provide tools that detect reachability failure and 997 traffic looping of data transport in a VPMS instance. If multiple 998 root ACs are supported (i.e., multiple P2MP connections are grouped 999 together into a single VPMS instance), such tools MUST be able to 1000 perform distinguishing each P2MP connection. 1002 7.7.1.2. Fault Notification 1004 A solution MUST provide fault notification and trouble tracking 1005 mechanisms. (e.g. SNMP-trap and syslog that notify fault to remote 1006 NMS.) 1008 In VPMS one point of failure at upstream often affects a number of 1009 downstream PEs and ACs that might raise a notification message. 1010 Hence notification messages MAY be summarized or compressed for 1011 operators' ease of management. 1013 In case of receiver-side failure (leaf PE or its AC), this fault 1014 status SHOULD be able to be monitored at root PE. This will help an 1015 operator to monitor each leaf PE/AC in a centralized manner; that is, 1016 a root PE can collect leaf-side information. How this status is 1017 transferred depends on a solution. 1019 In contrast, in case of sender-side failure (root PE or its AC), this 1020 fault status SHOULD also be able to be monitored at leaf PEs. This 1021 will help an operator to troubleshoot at leaf PEs (i.e., distinguish 1022 local AC's failure from remote root AC's failure easily). 1024 In any case of failure at SP's network, fault information MAY be 1025 notified to the customer. Specifically, such fault MAY trigger 1026 generating customer OAM message toward CEs (e.g., AIS) and/or 1027 shutting down leaf ACs. 1029 7.7.1.3. Fault Isolation 1031 A solution MUST provide diagnostic/troubleshooting tools for data 1032 transport in a VPMS instance. 1034 7.7.2. Testing 1036 A solution MUST provide a mechanism for testing each data 1037 connectivity and verifying the associated information in a VPMS 1038 instance. The connectivity is between a root and all leaf ACs (i.e., 1039 each P2MP connection can be tested). 1041 Operators will run testing before and after service activation. 1042 Testing mechanism SHOULD support end-to-end testing of the data path 1043 used by customer's data. End-to-end testing will have CE-to-CE path 1044 test and PE-to-PE path test. A solution MUST support PE-to-PE path 1045 test and MAY support CE-to-CE path test. In either case the minimum 1046 data path unit for each VPMS is unidirectional, hence if loopback 1047 testing is supported, additional consideration about reverse-path 1048 might also be needed (see section 6.1.2). 1050 If there are multiple P2MP connections for redundancy (active/backup 1051 tree) in a common VPMS (like in Figure 4), testing mechanism MUST be 1052 able to check the connectivity over not only working P2MP connection 1053 but also protecting connection(s). This testing MUST be able to be 1054 performed from a root PE. It MAY also be able to be performed from a 1055 sender CE. 1057 7.7.3. Performance Management 1059 A solution MUST offer mechanisms to monitor traffic performance 1060 parameters and statistics of data traffic in VPMS. 1062 A solution MUST provide access to: 1064 - Traffic statistics (total traffic forwarded, incoming, outgoing, 1065 dropped, etc., by period of time) 1067 A solution SHOULD provide access to: 1069 - Performance information related to traffic usage, e.g., one-way 1070 delay, one-way jitter, one-way loss, delay variations (the 1071 difference of various one-way delay from a particular root PE to 1072 multiple leaf PEs) etc. 1074 All or part of this information SHOULD be made available through 1075 standardized SNMP MIB Modules (Management Information Base). 1077 It is expected that such information can be used for SLA monitoring 1078 between sender and receiver, to give the SP a clear picture of 1079 current service providing to the customer. 1081 7.8. Security 1083 Section 7.6. of [RFC4665] describes common Layer-2 VPN security 1084 requirements from service provider aspect, which also applies to 1085 VPMS. (For example, an SP network MUST be protected against 1086 malformed or maliciously constructed customer traffic, etc.) 1088 This subsection adds VPMS-specific consideration and requirements. 1090 In VPMS, all traffic is transported with multicast duplication in 1091 terms of end-to-end perspective, regardless of customer's individual 1092 protocol. A PE never processes CE's multicast control protocol 1093 (e.g., PIM, IGMP, MLD as Layer-3). Hence, in PE and P, basically the 1094 security threat from malicious customer's C-plane protocol is small. 1096 In VPMS, there is security threat from malicious customers' D-plane 1097 traffic. A PE might receive a high volume of data from a CE. If 1098 there is no safeguard on PE, it will cause excessive replication in 1099 the SP network. Therefore, a VPMS solution SHOULD support traffic 1100 policing to limit the unwanted data traffic. Such a policing 1101 mechanism MUST be configurable per VPN basis, not the total of 1102 various VPNs to isolate malicious customer's traffic from others. 1104 8. Security Considerations 1106 The security requirements common to customers and service providers 1107 are raised in Section 5.5. of [RFC4665], which are fundamental for 1108 all Layer-2 VPN services. VPMS is a variant of Layer-2 VPN, and that 1109 statement also applies to VPMS. 1111 Moreover, in this document, security requirements from the view of 1112 customers are shown in Section 6.5. Security requirements from the 1113 view of providers are shown in Section 7.8. They explain security 1114 considerations that are specific to VPMS. 1116 9. IANA Considerations 1118 This document has no actions for IANA. 1120 10. Acknowledgments 1122 Many thanks to Ichiro Fukuda, Kazuhiro Fujihara, Ukyo Yamaguchi and 1123 Kensuke Shindome for their ideas and feedback in documentation. 1125 The authors gratefully acknowledge the valuable review and comments 1126 provided by Greg Mirsky and Yuji Tochio. 1128 11. References 1129 11.1. Normative References 1131 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1132 Requirement Levels", BCP 14, RFC 2119, March 1997. 1134 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 1135 Edge (PWE3) Architecture", RFC 3985, March 2005. 1137 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 1138 Private Network (VPN) Terminology", RFC 4026, March 2005. 1140 11.2. Informative References 1142 [I-D.ietf-l2vpn-vpls-mcast] 1143 Aggarwal, R., Rekhter, Y., Kamite, Y., and L. Fang, 1144 "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-11 (work 1145 in progress), July 2012. 1147 [I-D.ietf-pwe3-p2mp-pw-requirements] 1148 Bocci, M., Heron, G., and Y. Kamite, "Requirements and 1149 Framework for Point-to-Multipoint Pseudowires over MPLS 1150 PSNs", draft-ietf-pwe3-p2mp-pw-requirements-05 (work in 1151 progress), September 2011. 1153 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 1154 Private Networks (L2VPNs)", RFC 4664, September 2006. 1156 [RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for 1157 Layer 2 Provider-Provisioned Virtual Private Networks", 1158 RFC 4665, September 2006. 1160 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 1161 (VPLS) Using BGP for Auto-Discovery and Signaling", 1162 RFC 4761, January 2007. 1164 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 1165 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 1166 RFC 4762, January 2007. 1168 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1169 "Extensions to Resource Reservation Protocol - Traffic 1170 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1171 Switched Paths (LSPs)", RFC 4875, May 2007. 1173 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 1174 "Label Distribution Protocol Extensions for Point-to- 1175 Multipoint and Multipoint-to-Multipoint Label Switched 1176 Paths", RFC 6388, November 2011. 1178 Authors' Addresses 1180 Yuji Kamite 1181 NTT Communications Corporation 1182 Granpark Tower 1183 3-4-1 Shibaura, Minato-ku 1184 Tokyo 108-8118 1185 Japan 1187 Email: y.kamite@ntt.com 1189 Frederic Jounay 1190 Orange CH 1191 4 rue caudray 1020 Renens 1192 France 1194 Email: frederic.jounay@orange.ch 1196 Ben Niven-Jenkins 1197 Velocix 1198 326 Cambridge Science Park 1199 Milton Road, Cambridge 1200 CB4 0WG 1201 UK 1203 Email: ben@niven-jenkins.co.uk 1205 Deborah Brungard 1206 AT&T 1207 Rm. D1-3C22, 200 S. Laurel Ave. 1208 Middletown, NJ, 07748 1209 USA 1211 Email: dbrungard@att.com 1213 Lizhong Jin 1214 ZTE Corporation 1215 889, Bibo Road 1216 Shanghai, 201203 1217 China 1219 Email: lizhong.jin@zte.com.cn