idnits 2.17.1 draft-ietf-l2vpn-vpms-frmwk-requirements-04.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 (July 11, 2011) is 4674 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-09 == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-p2mp-pw-requirements-04 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: January 12, 2012 France Telecom 6 B. Niven-Jenkins 7 Velocix 8 D. Brungard 9 AT&T 10 L. Jin 11 ZTE 12 July 11, 2011 14 Framework and Requirements for Virtual Private Multicast Service (VPMS) 15 draft-ietf-l2vpn-vpms-frmwk-requirements-04.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 January 12, 2012. 44 Copyright Notice 46 Copyright (c) 2011 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. Reordering 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.3. Auto-discovery . . . . . . . . . . . . . . . . . . . . . . 19 93 7.4. Activation and Deactivation . . . . . . . . . . . . . . . 20 94 7.5. Inter-AS Support . . . . . . . . . . . . . . . . . . . . . 22 95 7.6. Co-existence with Existing L2VPNs . . . . . . . . . . . . 22 96 7.7. Operation, Administration and Maintenance . . . . . . . . 22 97 7.7.1. Fault Management . . . . . . . . . . . . . . . . . . . 22 98 7.7.2. Testing . . . . . . . . . . . . . . . . . . . . . . . 23 99 7.7.3. Performance Management . . . . . . . . . . . . . . . . 23 100 7.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 102 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 103 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 105 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 106 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 109 1. Introduction 111 1.1. Problem Statement 113 [RFC4664] describes different types of Provider Provisioned Layer 2 114 VPNs (L2 PPVPNs, or L2VPNs). Some of them are widely deployed today, 115 such as Virtual Private Wire Service (VPWS) and Virtual Private LAN 116 Service (VPLS). A VPWS is a VPN service that supplies a Layer 2 (L2) 117 point-to-point service. A VPLS is an L2 service that emulates 118 Ethernet LAN service across a Wide Area Network (WAN). 120 For some use cases described hereafter, there are P2MP (point-to- 121 multipoint) type services for Layer 2 traffic. However, there is no 122 straightforward way to realize them based on the existing L2VPN 123 specifications. 125 In a VPWS, a SP can set up point-to-point connectivity per a pair of 126 CEs but it is not possible to replicate traffic for point-to- 127 multipoint services in the SP's network side. A SP could build 128 multiple Pseudowires (PWs) independently and have the CEs replicate 129 traffic over them, but this is not only inconvenient for the 130 customer, it's a waste of bandwidth resources. 132 In a VPLS, SPs can natively offer multipoint connectivity across 133 their backbone. Although it is seemingly applicable for point-to- 134 multipoint service as well, there remains extra complexity for SPs to 135 filter unnecessary traffic between irrelevant sites (i.e., from a 136 receiver PE to another receiver PE) because VPLS provides multipoint- 137 to-multipoint connectivity between CEs. Moreover, VPLS's MAC-based 138 learning/forwarding operation is unnecessary for some scenarios 139 particularly if customers only need simple unidirectional point-to- 140 multipoint service, or if they require non- Ethernet Layer 2 141 connectivity. 143 Consequently, there is a real need for a solution that natively 144 provides point-to-multipoint service in L2VPN. 146 1.2. Scope of This Document 148 VPMS is defined as a Layer 2 service that provides point-to- 149 multipoint connectivity for a variety of Layer2 link layers across an 150 IP or MPLS-enabled PSN. VPMS is categorized as a class of provider- 151 provisioned Layer 2 Virtual Private Networks (L2VPN). 153 This document introduces a new service framework, reference model and 154 functional requirements for VPMS by extending the existing framework 155 [RFC4664] and requirements [RFC4665] for L2VPNs. 157 The technical specifications are outside the scope of this document. 158 There is no intent to specify solution-specific details. 160 This document provides requirements from both the Service Provider's 161 and the Customer's point of view. 163 2. Conventions used in this document 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119] . 169 3. Terminology 171 The content of this document makes use of the terminology defined in 172 [RFC4026]. For readability purposes, we list some of the terms here 173 in addition to some specific terms used in this document. 175 3.1. Acronyms 177 P2P: Point-to-Point 179 P2MP: Point-to-Multipoint 181 PW: Pseudowire 183 VPMS: Virtual Private Multicast Service 185 PE/CE: Provider/Customer Edge 187 P: Provider Router 189 AC: Attachment Circuit 191 PSN: Packet Switched Network 193 SP: Service Provider 195 VPMS instance: A service entity manageable in a VPMS that provides 196 isolated service reachability domain to each CE. It corresponds 197 to a so-called "VPN" as a specific set of sites that allows 198 communication. 200 P2MP connection: A logical entity between PE/ACs in a given VPMS 201 instance that transfers unidirectional traffic transparently from 202 one local ingress AC to one or more remote egress ACs. 204 4. Use Cases 206 4.1. Ethernet Use Case 208 4.1.1. Ethernet-based multicast stream 210 For multicast traffic delivery, there is a requirement to deliver a 211 unidirectional P2MP service in addition to the existing P2P service. 212 The demand is growing to provide private (P2MP native Ethernet) 213 services, for various applications such as IP- based delivery of TV 214 broadcasting, content delivery networks, etc. Moreover, many digital 215 audio/video devices (e.g., MPEG-TS, HD-SDI) that support Ethernet 216 interfaces are becoming available, which will make Ethernet P2MP 217 service more common. Also there are some applications that naturally 218 suited to static transport of VPMS. For example, MPEG-TS/IP/Ethernet 219 in DVB-H is typically static broadcast without any signaling in the 220 upstream direction. VPMS could be a possible solution to provide 221 these kinds of networking connectivity over PSNs. 223 Currently VPLS [RFC4761][RFC4762] is able to give P2MP-type 224 replication for Ethernet traffic. Native VPLS already supports this 225 capability via a full mesh of PWs, and an extension to optimize 226 replication is also proposed [I-D.ietf-l2vpn-vpls-mcast] as an 227 additional feature. However, VPLS by nature requires MAC-based 228 learning and forwarding, which might not be needed in some cases by 229 particular users. Generally, video distribution applications use 230 unidirectional P2MP traffic, but may not always require any added 231 complexity of MAC address management. In addition, VPLS is a service 232 that essentially provides any-to-any connectivity between all CEs in 233 a L2VPN as it emulates a LAN service. However, if only P2MP 234 connectivity is required, the traffic between leaves is not allowed. 235 It might require extra efforts to guarantee this behavior in VPLS. 236 And in some P2MP scenarios there no traffic from leafs to root. In 237 these cases, VPMS is a service that provides much simpler operation. 239 Note that VPMS provides single coverage of receiver membership; that 240 is, there is no distinct differentiation for multiple multicast 241 groups. All traffic from a particular Attachment Circuit (AC) will 242 be forwarded toward the same remote receivers, even if the 243 destination MAC address is changed. Basically in VPMS, destination 244 MAC addresses are not used for forwarding, which is significantly 245 different from VPLS. If MAC-based forwarding is preferred (i.e., 246 multicast/unicast differentiation of MAC address), VPLS should be 247 chosen rather than VPMS. 249 4.1.2. Ethernet-based time/frequency synchronization 251 Nowadays there exist several solutions to provide synchronization for 252 time and/or frequency reference by the packet-based technology of 253 Ethernet. For example, PTPv2 (Precision Time Protocol version 2) is 254 a time-transfer protocol defined in the IEEE 1588-2008 standard. It 255 provides precise synchronization of packet-based networks (e.g., 256 Ethernet). It adopts two-way time transfer approach for 257 synchronization. Time transfer protocol may be operated in multicast 258 or unicast mode in both directions, and it is mapped over the 259 Ethernet/IP/UDP protocol stack. 261 Moreover, PTPv2 telecom profile is now discussed in ITU-T that 262 defines a set of capabilities and extensions required to support 263 telecommunication applications. It aims at providing frequency 264 distribution with higher level of accuracy. It allows unicast mode 265 or the mix of unicast/multicast modes for the transmission of the PTP 266 messages. 268 In this aspect, VPMS might be considered as a potential packet-based 269 infrastructure to deliver multicast messages in PTPv2 with efficient 270 forwarding. Note, however, in PTPv2 telecom profile, multicast 271 transport may not always be supported in all the parts of a telecom 272 network because multicast might sometimes generate additional PDV 273 (packet delay variation) compared to unicast. Therefore, VPMS use 274 case and the corresponding solution for this purpose will need more 275 study in the future (e.g., PDV issue to be checked). 277 4.2. ATM-based Use Case 279 4.2.1. ATM-based multicast stream 281 A use case of ATM-based service in VPMS could be to offer the 282 capability for service providers to support IP multicast wholesale 283 services over ATM in case the wholesale customer relies on ATM 284 infrastructure. The P2MP support alleviates the constraint in terms 285 of replication for ATM to support IP multicast services. 287 Another use case of VPMS for ATM is for audio/video stream 288 applications. Today many digital TV broadcasting networks adopt ATM- 289 based distribution systems with point-to-multipoint PVPs/PVCs. The 290 transport network supports replicating ATM cells in transit nodes to 291 efficiently deliver programs to multiple terminals. For migrating 292 such ATM-based networks onto IP/MPLS-based networks, VPMS is 293 considered to be a candidate solution. 295 4.3. TDM-based Use Case 297 4.3.1. TDM-based multicast stream 299 Today the existing VPWS already supports TDM emulation services 300 (SAToP, CESoPSN or TDMoIP). It is a Layer 1 service, not Layer 2 301 service; however, a common architecture is being used since they are 302 all packet-based emulations over a SP's network. VPMS is also 303 considered to be a solution for such TDM applications that require 304 point-to-multipoint topology. 306 One use case is TDM-based multicast stream delivery, like video 307 delivery. That is, data duplication is simply provided by Layer 1, 308 without using upper layer's multicast protocols. 310 5. Reference Model 312 The VPMS reference model is shown in Figure 1. 314 +-----+ AC1 AC2 +-----+ 315 | CE1 |>---+ ------------------------ +--->| CE2 | 316 +-----+ | | VPMS A's P2MP | | +-----+ 317 VPMS A | +------+ Connection +------+ | VPMS A 318 Sender +->|......>...+.......... >......|>-+ Receiver 319 | VPMS | . | VPMS | 320 | PE1 | . | PE2 | 321 +-<|......<.. . ....+.....<......|<-+ 322 | +------+ . . +------+ | 323 +-----+ | | . . | | +-----+ 324 | CE4 |<---+ |Routed . . VPMS B's P2MP +---<| CE3 | 325 +-----+ AC4 |Backbone. . Connection AC3 +-----+ 326 VPMS B | . . | VPMS B 327 Receiver | +-v-----v-+ | Sender 328 ------| . . |------- 329 | . VPMS. | 330 | . PE3 . | 331 +---------+ 332 v v VPMS A: 333 | | Root AC : AC1 334 AC5| |AC6 Leaf AC : AC2, AC5 335 v v VPMS B: 336 +-----+ +-----+ Root AC : AC3 337 | CE5 | | CE6 | Leaf AC : AC4, AC6 338 +-----+ +-----+ 339 VPMS A VPMS B 340 Receiver Receiver 342 Figure 1: Reference Model for VPMS 344 A VPMS instance is defined as a service entity manageable in the VPMS 345 architecture. A single VPMS instance provides an isolated service 346 reachability domain to each CE, so it corresponds to a so-called 347 "VPN" as it allows communication among a specific set of sites. A 348 single VPMS instance provides a unique point-to-multipoint L2VPN 349 service. In Figure 1, there are two VPMS instances shown, VPMS A and 350 VPMS B. In principle, there is no traffic exchange allowed between 351 these different instances, so they are treated as different VPNs. 353 In a VPMS, a single CE-PE link connection is used for transmitting 354 frames for delivery to multiple remote CEs, with point-to-multipoint 355 duplication. The SP's network (PE as well as P) has a role to 356 replicate frames so that the sender's CE does not need to send 357 multiple frames to individual receivers. 359 Like VPWS, an Attachment Circuit (AC) is provided to accommodate CEs 360 in a VPMS. In a VPMS, an AC attached to a VPMS MUST be configured as 361 "root" (sender) or "leaf" (receiver) not both. Any AC is associated 362 with the role of either sending side (Tx) or receiving side (Rx) from 363 the view of the CE. These will be named the root (sender) AC and 364 leaf (receiver) AC respectively. Unless reverse traffic is 365 optionally supported, a root AC does not transmit traffic back to a 366 CE at upstream side, likewise a leaf AC does not receive traffic from 367 a CE at downstream side. In Figure 1, AC1 and AC3 are configured as 368 root ACs while AC2, AC4, AC5 and AC6 are configured as leaf ACs. In 369 VPMS A, CE1 could send traffic via AC1, and CE2 and CE5 could receive 370 the traffic. 372 A CE which is locally connected to a root AC is called a root 373 (sender) CE. Also a CE which is locally connected to a leaf AC is 374 called a leaf (receiver) CE. However, such CEs's roles will not be 375 managed directly in VPMS because the configured AC's role (root or 376 leaf) will automatically determine them. 378 Similarly, a PE which locally accommodates a root AC is called a root 379 (sender) PE. A PE which locally accommodates a leaf AC is called a 380 leaf (receiver) PE. 382 Root AC and leaf ACs are typically located at separate PEs as shown 383 in Figure 1, but it is also allowed that a single PE locally has both 384 a root AC and one or more leaf ACs. 386 Basically there is a one-to-one mapping between an attachment circuit 387 and a VPMS instance. For example, all traffic from CE1 to PE1 388 (through AC1) is mapped to VPMS A (to CE2 and CE5). 390 In a VPMS, P2MP tree-shaped reachability is given from a single root 391 AC to several leaf ACs. This will be named a "P2MP connection" in 392 this VPMS framework. P2MP connection is a logical entity between PE/ 393 ACs in a given VPMS instance that transfers unidirectional traffic 394 transparently from one local ingress AC to one or more remote egress 395 ACs. 397 Similar to other L2VPN mechanisms, the VPMS architecture is based on 398 PWs which may be using through IP or MPLS-enabled PSN tunnels over a 399 routed backbone. That is, every P2MP connection can be instantiated 400 by PW technology that supports P2MP traffic optimization (i.e., P2MP 401 PW. See section 7.2.). P2MP traffic optimization will provide the 402 benefit of traffic replication for high bandwidth efficiency. That 403 is, the sender CE has only to transmit one stream towards the PE and 404 it does not have to replicate traffic. 406 Regarding end-to-end traffic topology between the ACs, a single VPMS 407 instance (i.e., one VPN) may correspond to a single P2MP connection. 408 In Figure 1, VPMS A (one instance) has one P2MP connection (from AC1 409 to AC2 and AC5). However, there is also a case that a single VPMS 410 consists of two or more P2MP connections grouped, which is typically 411 used for multi-source or redundancy. The details are given in 412 section 6.4 and 6.5. 414 VPMS can support various Layer 2 protocol services such as Ethernet, 415 ATM, etc. 417 6. Customer Requirements 419 6.1. Service Topology 421 6.1.1. Point-to-Multipoint Traffic Support 423 A solution MUST support unidirectional point-to-multipoint traffic 424 from a sender CE to multiple receiver CEs. A root CE can send 425 traffic to one or more leaf CEs. Leaf CEs include not only the CEs 426 which are located at remote sites, but also the local CEs which are 427 connected to the same root PE (i.e., when a root AC and some of leaf 428 ACs are co-located). If there is only one receiver in the instance, 429 it is considered equivalent to unidirectional point-to-point traffic. 431 6.1.2. Reverse Traffic Support 433 There are cases where a reverse traffic flow is needed. A root CE 434 may need to receive traffic from leaf CEs. There are some usage 435 scenarios for this, such as stream monitoring through a loopback 436 mechanism, control channels which need feedback communication etc. A 437 possible way to accomplish this is to provide different VPMS 438 instances for reverse traffic, i.e. a root CE is a receiver of 439 another VPMS instance. However, provisioning different VPNs for a 440 particular customer would make its management task more complex. It 441 is desired to have an alternative solution for supporting reverse 442 traffic flow. This section provides additional requirements for this 443 optional capability. 445 Therefore, a VPMS solution MAY support reverse traffic from a leaf AC 446 to a root AC. Each reverse path is basically given in a P2P 447 (unicast) manner. In other words, each leaf of the P2MP tree can 448 individually send back traffic to the root. For this purpose a VPMS 449 instance MAY have more than one reverse P2P connections as network 450 entity; However, such network entities MUST have a common indetifier 451 that enables themselves to be managed together in the same VPN. Thus 452 any PWs used for such connections are expected to be assigned a 453 common VPMS instance ID (i.e., VPN ID). 455 Note, a VPMS does not assume any-to-any multipoint reachability. 456 Therefore, in principle, every leaf AC does not need to exchange 457 traffic directly with other leaf ACs even if reverse traffic is 458 supported. 460 Figure 3 illustrates this kind of scenario, where CE1 is configured 461 as a sender in VPMS A. AC1 is a root AC, and AC2/AC3/AC4 are leaf 462 ACs. P2MP connection is given for traffic in the forward direction. 463 Unidirectional P2P connection is also provided for traffic in the 464 reverse direction, from AC4 to AC1. Other reverse P2P connections 465 can be provided similarly. (from AC2 to AC1 / from AC3 to AC1). 467 In this case, PEs need to deal with two types of traffic, locally- 468 attached CE's sending (Tx) and receiving (Rx) flows. In Figure 3, 469 they are both passing through the same physical PE-CE link (AC1 and 470 AC4 respectively). But it is an implementation matter if Tx and Rx 471 traffic are conveyed on the same physical link or separate links. It 472 is also possible that a root PE multiplexes two ore more reverse 473 traffic from different leaves and transmits it to an upstream CE over 474 the same local physical link. 476 Note, in most implementations of VPWS today, every AC is always 477 considered bidirectional. In contrast, in VPMS, every AC can be 478 chosen unidirectional (if it is a totally unidirectional service), or 479 bidirectional (if reverse traffic is supported). 481 +-----+ <-- Rx (bidirectional) 482 | CE1 |--------------+ 483 +-----+ --> Tx | 484 VPMS A Sender | 485 AC1 | 486 +----------+ VPMS 487 | . . | PE1 488 | . .... | 489 -------| . . |-------- 490 | P2MP +-v------^-+ | 491 Connection . . | 492 (forward) + . | 493 | . . | 494 +------+ . . . . +------+ 495 +-<|......<.. . .. . ......>..... |>-+ 496 | | VPMS | . . | VPMS | | 497 AC2| | PE2 | . . | PE3 | |AC3 498 | +------+ . . +------+ | 499 +-----+ | | . . P2P | | +-----+ 500 | CE2 |<--+ | Routed . . Connection +-->| CE3 | 501 +-----+ <-- | Backbone. . (reverse)| --> +-----+ 502 VPMS A Rx | +-v------^-+ | Rx VPMS A 503 Receiver -------| . . |-------- Receiver 504 | . .... | 505 | . . | VPMS 506 +----------+ PE4 507 AC4| 508 | 509 | <-- Tx +-----+ 510 +--------------------| CE4 | 511 (bidirectional) --> Rx +-----+ 512 VPMS A 513 Receiver 515 Figure 3: Reverse traffic support 517 6.2. Transparency 519 A solution is intended to provide Layer-2 traffic transparency. 520 Transparency SHOULD be supported per VPMS instance basis. In other 521 words, Layer-2 traffic can be transparently transported from a local 522 CE to remote CEs in a given instance. Note, however, if service 523 delimiting fields (VLAN Id in Ethernet, VPI/VCI in ATM, DLCI in FR 524 etc.) are assigned by the SP, the Layer-2 traffic is not necessarily 525 transparent. It will depend on the SP's choice if they assign it to 526 each AC. Hence, it could be that some of the leaf CEs are receiving 527 traffic that has different delimiting fields than the traffic for the 528 other leaf CEs. Hence, it could be that some of receiver CEs are 529 getting traffic with different delimiting fields than the other 530 receiver CEs. 532 The VPMS solution SHOULD NOT require any special packet processing by 533 the end users (CEs). 535 6.3. Quality of Service (QoS) 537 A customer may require that the VPMS service provide guaranteed QoS. 538 In particular, for real time applications which are considered common 539 in point-to-multipoint delivery, delay and loss sensitive traffic 540 MUST be supported. The solution SHOULD provide native QoS techniques 541 for service class differentiation, such as IEEE 802.1p CoS for 542 Ethernet. 544 For bandwidth committed services (e.g., ATM CBR), a solution SHOULD 545 guarantee end-to-end bandwidth. It MAY provide flow admission 546 control mechanisms to achieve that. 548 6.4. Multi-Source Support 550 A VPMS solution SHOULD support multiple sources in each VPN. That 551 is, two or more sender CEs can exist in the same VPMS instance. Each 552 sender CE SHOULD be able to be connected to physically separate root 553 PEs, which will facilitate flexible topology design. 555 Additionally, traffic from sender CEs MAY have a common single 556 coverage to receiver CEs, i.e., data from any sources can reach the 557 same group of receivers. For example, in TV provisioning scenario, 558 customers may need to receive two or more TV channels from different 559 sources. In figure 3, suppose there are 7 hosts, CE1 to CE7 which 560 belong to a given VPMS instance A. CE1, CE2 and CE3 are common 561 sources of this VPN, and are attached to different PEs respectively. 562 Traffic from each source can reach the same group of receivers, CE4 563 to CE7. 565 This kind of scenario will require multiple P2MP connections in a 566 single VPMS instance (i.e., VPN). Each P2MP connection's root might 567 be a completely different CE/AC, but leaf CE/ACs are overlapped. 568 Since this is basically the same requirement as dual-homed scenario, 569 see section 6.5.1 for details. 571 VPMS A +-----+ +-----+ VPMS A 572 Sender | CE1 | | CE2 | Sender 573 +-----+ +-----+ 574 | | 575 +-----+ VPMS A v AC1 v AC2 576 | CE3 | Sender +----+ +----+ 577 +-----+ -----|VPMS|-----|VPMS|----- 578 \ | | PE1| | PE2| | 579 \ | +----+ +----+ | 580 \ | | 581 \ AC3 +----+ +----+ 582 +---->|VPMS| |VPMS| AC5 VPMS A 583 | PE3| Routed | PE4|-----+ Receiver 584 +----+ Backbone +----+ | +-----+ 585 / | | \ +-->| CE5 | 586 AC4 / | | \ +-----+ 587 / | | \ AC6 588 +-----+ / | +----+ | \ +-----+ 589 | CE4 |<--+ -----------|VPMS|---------- +->| CE6 | 590 +-----+ | PE5| +-----+ 591 VPMS A +----+ VPMS A 592 Receiver | AC7 Receiver 593 v 594 +-----+ 595 | CE7 | VPMS A 596 +-----+ Receiver 598 Figure 3: Multi-Source support 600 6.5. High Availability 602 A solution MUST provide protection and restoration mechanism for end- 603 to-end services to ensure high availability. 605 There are multiple parts of the connection that can support 606 protection and restoration: (1) CE to PE, (2) between PEs (3) inside 607 core (PSN backbone). It is expected that (3) is fulfilled by 608 existing PSN protection mechanisms (e.g., RSVP-TE FRR). Following 609 subsections covers the requirements for redundancy support for (1) 610 and (2). 612 6.5.1. Dual-homed Access Support 614 A solution MUST allow dual-homed redundant access from a CE to 615 multiple PEs. This if beneficial to support reliable data delivery 616 for customers. Figure 4 provides an example of this access topology. 618 +-----+ 619 | CE1 |--------------+ 620 +-----+ \ 621 VPMS A | | 622 Sender | v AC1 623 (dual-homed)| +----+ 624 | -----|VPMS|-------- 625 | | | PE1| | 626 \ | +----+ | 627 \ AC2 +----+ +----+ AC4 628 +------>|VPMS| |VPMS|------------+ 629 | PE2| Routed | PE3| \ 630 +----+ Backbone +----+\ | 631 AC3 / | | \ AC5 v 632 +-----+ / | | \ +-----+ 633 | CE2 |<-+ | | \ | CE3 | 634 +-----+ | +----+ | \ +-----+ 635 VPMS A ----|VPMS|--------- \ VPMS A 636 Receiver | PE4| | Receiver 637 +----+ | 638 | AC6 v 639 \ +-----+ 640 +--------------->| CE4 | 641 +-----+ 642 VPMS A 643 Receiver 644 (dual-homed) 646 Figure 4: Dual-homing support 648 A solution SHOULD provide a protection mechanism between the 649 redundant PEs to which a CE is dual-homed. This is because when an 650 ingress root PE node fails whole traffic delivery will fail unless a 651 backup root PE is provided, even in case of dual-homed access. 652 Similarly, if an egress leaf PE node fails, traffic toward that CE is 653 never received unless a backup leaf PE is provided. 655 In some cases, the data source is required to be highly reliable 656 since it is often deployed as a centralized server that provides 657 traffic to many receivers. Therefore, there is an additional 658 requirement specifically about redundancy of root-side: each VPMS 659 instance SHOULD be able to have multiple P2MP connections whose roots 660 are located at separate root ACs. Those root ACs can be located at 661 physically separate root PEs, whereas those trees will share common 662 leaf ACs. This means that each P2MP connection has a single root AC, 663 but several P2MP connections can be managed together inside a common 664 VPN. 666 For example, in Figure 5, traffic from root AC1 and AC2 both reach 667 receivers CE3 and CE4 while AC1, AC2, AC3 and AC4 all are associated 668 with a single VPMS instance. This topology is reliable since there 669 are redundant root PE/ACs. At the egress side, PE3 and PE4 select 670 traffic from either root, PE1 or PE2. In this figure, each leaf PE 671 has one leaf AC only (AC3 attached to PE3, and AC4 attached to PE4). 672 Therefore, PEs will need to support PW protection and restoration 673 mechanism so that two redundant P2MP connections are given among 674 common ACs. 676 +-----+ AC2 677 | CE1 |>--------------------------------------------+ 678 +-----+ | 679 AC1v VPMS A | 680 | Sender ----------------------------- | 681 | | VPMS A's P2MP | | 682 | +------+ Connection-2 +------+ | 683 +------->|......>.. .............+..<......|<-+ 684 Tx | VPMS | . . . | VPMS | Tx 685 | PE 1 | . . . | PE 2 | 686 | | . . . | | 687 +------+ . . . +------+ 688 | . . . | 689 VPMS A's P2MP +.. . ...... . | 690 Connection-1 . . . . | 691 | . . . . | 692 | +-v----v-+ +-v----v-+ | 693 ---| . . |---| . . |--- 694 VPMS| . . | | . . |VPMS 695 PE 3| . | | . |PE 4 696 +--------+ +--------+ 697 v v 698 AC3| |AC4 699 v v 700 +-----+ +-----+ 701 | CE3 | | CE4 | 702 +-----+ +-----+ 703 VPMS A VPMS A 704 Receiver Receiver 706 Figure 5: Multiple P2MP connections in Dual-homed Sender 708 6.5.2. Single/Dual Traffic Support in Dual-homed Access 710 When dual-homed access to root PEs is provided, a solution MAY allow 711 a sender CE to transmit just a single copy of the traffic to either 712 one of the two root (ingress) PEs or to transmit a copy of the 713 traffic to both the PEs simultaneously. The latter scenario consumes 714 more resource of CE-PE link than the single traffic scenario, but it 715 is usually applicable when a source device has only a simple 716 forwarding capability without any switchover functionality. In such 717 a dual traffic case, the backup root (ingress) PE SHOULD be able to 718 filter the incoming unnecessary traffic while the other root PE is 719 active if it is needed by SP. In either case, single traffic or dual 720 traffic, the switchover mechanism between root (ingress) PEs will be 721 necessary to handle traffic appropriately in case of failure. 723 In the case of dual-homed access to leaf PEs, a solution MAY allow a 724 receiver CE to receive a single copy of the traffic from either one 725 of the two leaf (egress) PEs, or receive a copy of the traffic from 726 both PEs simultaneously. The dual traffic approach is applicable if 727 CE has fast switchover capability as a receiver by selecting either 728 one of incoming traffic, but note that additional traffic resources 729 are always consumed at PE-CE link of backup side. Specifically in 730 the single traffic case, it might be needed to support switchover 731 mechanism between egress PEs in case of failure. 733 6.6. Security 735 The basic security requirements from the view of customers are raised 736 in section 6.5 of [RFC4665]. It also applies to VPMS. 738 In addition, a VPMS solution MAY have the mechanisms to activate the 739 appropriate filtering capabilities (for example, MAC/VLAN filtering 740 etc.), and it MAY be added with the control mechanism between 741 particular sender/receiver sites inside a VPMS instance. For 742 example, in Figure 1, filtering can be added such that traffic from 743 CE1 to CE4/CE5 is allowed but traffic from CE1 to CE6 is filtered. 745 6.7. Reordering Prevention 747 A solution SHOULD prevent Layer-2 frame reordering when delivering 748 customer traffic under normal conditions. 750 6.8. Failure reporting 752 A solution MAY provide information to the customer about failures. 753 For example, if there is a loss of connectivity toward some of the 754 receiver CEs, it is reported to the sender CE. 756 7. Service Provider Network Requirements 758 7.1. Scalability 760 A VPMS solution MUST be designed to scale well with an increase in 761 the number of any of the following metrics: 763 - the number of PEs (per VPMS instance and total in a SP network) 764 - the number of VPMS instances (per PE and total) 765 - the number of root ACs / sender CEs (per PE, VPMS instance and 766 total) 767 - the number of leaf ACs / receiver CEs (per PE, VPMS instance and 768 total) 770 A VPMS solution SHALL document its scalability characteristics in 771 quantitative terms. A solution SHOULD quantify the amount of state 772 that a PE and a P device has to support. 774 The scalability characteristics SHOULD include: 776 - the processing resources required by the control plane in managing 777 PWs (neighborhood or session maintenance messages, keepalives, 778 timers, etc.) 779 - the processing resources required by the control plane in managing 780 PSN tunnels 781 - the memory resources needed for the control plane 782 - other particular elements inherent to each solution that impact 783 scalability 785 7.2. Pseudo Wire Signaling and PSN Tunneling 787 A VPMS solution SHOULD provide an efficient replication that can 788 contribute to optimizing the bandwidth usage required in a SP's 789 network. For supporting efficient replication, it is expected to 790 take advantage of PW and PSN mechanisms that are capable of P2MP 791 traffic. 793 Regarding PW mechanism, [I-D.ietf-pwe3-p2mp-pw-requirements] 794 introduces P2MP PW concept and its requirements, showing two basic 795 approaches of providing replication. One is SS (Single Segment)-PW 796 model that provides replication by PSN tunnel such as P2MP LSP (i.e., 797 by outer label layer), and the other is MS (Multi Segment)-PW model 798 that provides replication by multiple interconnected PWs (i.e., by 799 inner label layer). In either case, end-to-end P2MP topology (i.e., 800 P2MP connection) in VPMS is common from the view of ACs. 801 Requirements as a provider service specified in this document will be 802 commonly applied regardless of P2MP PW's signaling model. 804 It is out of scope of this document how to extend and use PW 805 mechanisms to realize P2MP connections. For example, it is under the 806 scope of the solution work how to support forward/reverse traffic 807 e.g., by a single PW signaling, coupling multiple PWs, or other ways. 809 This document does not raise any specific requirements for particular 810 PSN tunneling schemes (point-to-point, point-to-multipoint and 811 multipoint-to-multipoint) that are applied to VPMS. The actual type 812 of PSN tunnel used in VPMS will be dependent on individual deployment 813 scenarios (e.g., which PSN protocol is available in the core and how 814 much of the network resources that operators will want to optimize). 816 7.3. Auto-discovery 818 A solution SHOULD support auto-discovery methods that dynamically 819 allow VPMS related information to be discovered by the PEs to 820 minimize the amount of configuration the SP must perform. 822 All of the requirements on discovery described in Section 7.3 of 823 [RFC4665] SHOULD be satisfied in VPMS as well. 825 Auto-discovery will help operators' initial configuration of adding a 826 new VPN (i.e., VPMS instance), adding/deleting new sender/receiver, 827 and so on. 829 The candidate information treated in auto-discovery will be as 830 follows: 832 - Information to indentify the location of each PE, e.g., PE router 833 ID / IP address 834 - Information to identify the VPMS instance, that is, to identify a 835 VPN 836 - Information to identify the type of ACs (root AC or leaf AC) 837 - Information to identify the P2MP connection that binds ACs 838 - Information to show if reverse traffic support is optionally 839 desired 840 - SP-related information (AS number, etc. for an inter-provider 841 case) 843 Following is an example scenario about adding a new leaf PE: suppose 844 there are three PEs in an existing VPMS, PE1, PE2, PE3. PE1 is a 845 root PE and has a AC1. PE2 and PE3 are leaves and have AC2 and AC3. 846 every PE has the association among the information described above. 847 Now a new PE4 having an AC4 is provisioned in the existing VPMS 848 instance and this AC is configured as leaf. This information will be 849 automatically discovered by the other existing remote PEs (i.e., 850 ingress and egress PEs in the same VPMS instance). Once the ingress 851 PE1 discovers this new PE/AC, it can automatically add AC4 as the new 852 leaf of P2MP connection topology according to P2MP PW signaling 853 mechanism. The ingress PE1 will graft a new leaf (PE4) to the 854 already existing P2MP connection which is now created from AC1 to 855 AC2/AC3/AC4. This operation does not require any new configuration 856 at the existing PEs. 858 Another example is about adding a new root PE: suppose there are one 859 root PE (PE1/AC1) and three leaf PEs (PE2/AC2, PE3/AC3 and PE4/AC4). 860 There is an existing P2MP connection from AC1 to AC2/AC3/AC4. Now 861 the operator adds a new root PE/AC (PE5/AC5) for some reasons (e.g., 862 multiple source sites, dual-homed access, root PE redundancy etc.). 863 Then, auto-discovery mechanism advertises this information to all 864 other members PE1/PE2/PE3/PE4, and a new P2MP connection from AC5 to 865 AC2/AC3/AC4 is created by PW signaling. 867 Note that VPMS instance is created when one root AC and at least one 868 leaf AC are added. In principle VPMS requires such minimum 869 provisioning. Hence in dual-homing case of sender, only backup root 870 PE can be dynamically added/deleted to/from VPMS without destroying 871 the VPN. 873 7.4. Activation and Deactivation 875 A solution SHOULD provide a way to activate/deactivate the 876 administrative status of each AC. After initial provisioning, an SP 877 might change connectivity configuration between particular CEs inside 878 a single VPMS instance for operational reasons. This feature will be 879 beneficial to help such a scenario. 881 For example, in Figure 6, AC1, AC3, AC4 and AC5 are initially 882 provisioned for VPMS A. AC2 is not provisioned for any VPMSes. In 883 VPMS A, CE1 is a sender and CE3, CE4 and CE5 are receivers. Traffic 884 will usually flow from CE1 to all receivers, CE3, CE4 and CE5. 885 However, for maintenance operation, application's request (e.g., 886 stream program has changed) or some other reasons, AC4 needs to be 887 set as administratively deactivated. Then it becomes necessary to 888 turn off traffic from PE4 to CE4. This operation must be 889 appropriately distinguished from failure cases. 891 When deactivating a particular site, backbone PSN/PW resources (e.g., 892 admission control of PSN tunnel) MAY be released for that particular 893 direction in order to provide that bandwidth to other services. In 894 Figure 6, AC3 is now administratively activated and receiving 895 traffic. However, if AC3 comes to be administratively deactivated, 896 and if RSVP-TE (including P2P and/or P2MP) is used for backbone PSN, 897 then TE reserved resources from PE1 to PE3 may be released. 899 In addition, a solution SHOULD allow single-sided activation 900 operation at a root (ingress) PE. In some scenarios, operators 901 prefer centralized operation. This is often considered natural for 902 one-way digital audio/video distribution applications: SPs often want 903 to complete their service delivery by a single operation at one 904 source PE, not by multiple operations at many leaf (egress) PEs. 905 Figure 6 illustrates this scenario, where a SP only has to do single- 906 sided operation at PE1 (source) to administratively activate/ 907 deactivate various connections from AC1 to AC3, AC4 and/or AC5. It 908 is not needed to perform operations on PE3 and PE4 directly. 910 +-----+ AC1 911 + CE1 +----------------+ 912 +-----+ | 913 VPMS A Sender | 914 (sending now) v 915 +----+ 916 -----|VPMS|-------- 917 | | PE1| | 918 | +----+ | 919 +----+ +----+ 920 |VPMS| |VPMS| 921 | PE2| Routed | PE3| 922 AC2 +----+ Backbone +----+ AC3 923 (not provisioned) / | | \ 924 +-----+ / | | \ +-----+ 925 + CE2 +<-+ | | +->| CE3 | 926 +-----+ | +----+ | +-----+ 927 (not receiving) ----|VPMS|--------- VPMS A Receiver 928 | PE4| (receiving now) 929 +----+ 930 AC5 / \ AC4 931 +-----+ / \ +-----+ 932 + CE5 +<----------+ +---------------->| CE4 | 933 +-----+ +-----+ 934 VPMS A Receiver VPMS A Receiver 935 (receiving now) (not receiving) 937 AC1: Administratively activated 938 AC2: No VPMS provisioned 939 AC3: Administratively activated 940 AC4: Administratively deactivated 941 AC5: Administratively activated 943 Figure 6: Site activation and deactivation 945 7.5. Inter-AS Support 947 A solution SHOULD support inter-AS scenarios, where there is more 948 than one provider providing a common VPMS instance and VPN. More 949 specifically, it is necessary to consider the case where some of the 950 PEs that compose one VPMS belong to several different ASes. 952 7.6. Co-existence with Existing L2VPNs 954 A solution MUST co-exist with the existing L2VPNs (e.g., VPWS, VPLS) 955 across the same SP's network. A solution MUST NOT impede the 956 operation of auto-discovery and signaling mechanism that are already 957 supported by the PEs for those existing L2VPNs. 959 7.7. Operation, Administration and Maintenance 961 7.7.1. Fault Management 963 7.7.1.1. Fault Detection 965 A solution MUST provide tools that detect reachability failure and 966 traffic looping of data transport in a VPMS instance. If multiple 967 root ACs are supported (i.e., multiple P2MP connections are grouped 968 together into a single VPMS instance), such tools MUST be able to 969 perform distinguishing each P2MP connection. 971 7.7.1.2. Fault Notification 973 A solution MUST provide fault notification and trouble tracking 974 mechanisms. (e.g. SNMP-trap and syslog that notify fault to remote 975 NMS.) 977 In VPMS one point of failure at upstream often affects a number of 978 downstream PEs and ACs that might raise a notification message. 979 Hence notification messages MAY be summarized or compressed for 980 operators' ease of management. 982 In case of receiver-side failure (leaf PE or its AC), this fault 983 status SHOULD be able to be monitored at root PE. This will help an 984 operator to monitor each leaf PE/AC in a centralized manner; that is, 985 a root PE can collect leaf-side information. How this status is 986 transferred depends on a solution. 988 In contrast, in case of sender-side failure (root PE or its AC), this 989 fault status SHOULD also be able to be monitored at leaf PEs. This 990 will help an operator to troubleshoot at leaf PEs (i.e., distinguish 991 local AC's failure from remote root AC's failure easily). 993 In any case of failure at SP's network, fault information MAY be 994 notified to the customer. Specifically, such fault MAY trigger 995 generating customer OAM message toward CEs (e.g., AIS) and/or 996 shutting down leaf ACs. 998 7.7.1.3. Fault Isolation 1000 A solution MUST provide diagnostic/troubleshooting tools for data 1001 transport in a VPMS instance. 1003 7.7.2. Testing 1005 A solution MUST provide a mechanism for testing each data 1006 connectivity and verifying the associated information in a VPMS 1007 instance. The connectivity is between a root and all leaf ACs (i.e., 1008 each P2MP connection can be tested). 1010 Operators will run testing before and after service activation. 1011 Testing mechanism SHOULD support end-to-end testing of the data path 1012 used by customer's data. End-to-end testing will have CE-to-CE path 1013 test and PE-to-PE path test. A solution MUST support PE-to-PE path 1014 test and MAY support CE-to-CE path test. In either case the minimum 1015 data path unit for each VPMS is unidirectional, hence if loopback 1016 testing is supported, additional consideration about reverse-path 1017 might also be needed (see section 6.1.2). 1019 If there are multiple P2MP connections for redundancy (active/backup 1020 tree) in a common VPMS (like in Figure 4), testing mechanism MUST be 1021 able to check the connectivity over not only working P2MP connection 1022 but also protecting connection(s). This testing MUST be able to be 1023 performed from a root PE. It MAY also be able to be performed from a 1024 sender CE. 1026 7.7.3. Performance Management 1028 A solution MUST offer mechanisms to monitor traffic performance 1029 parameters and statistics of data traffic in VPMS. 1031 A solution MUST provide access to: 1033 - Traffic statistics (total traffic forwarded, incoming, outgoing, 1034 dropped, etc., by period of time) 1036 A solution SHOULD provide access to: 1038 - Performance information related to traffic usage, e.g., one-way 1039 delay, one-way jitter, one-way loss, delay variations (the 1040 difference of various one-way delay from a particular root PE to 1041 multiple leaf PEs) etc. 1043 All or part of this information SHOULD be made available through 1044 standardized SNMP MIB Modules (Management Information Base). 1046 It is expected that such information can be used for SLA monitoring 1047 between sender and receiver, to give the SP a clear picture of 1048 current service providing to the customer. 1050 7.8. Security 1052 Section 7.6. of [RFC4665] describes common Layer-2 VPN security 1053 requirements from service provider aspect, which also applies to 1054 VPMS. (For example, an SP network MUST be protected against 1055 malformed or maliciously constructed customer traffic, etc.) 1057 This subsection adds VPMS-specific consideration and requirements. 1059 In VPMS, all traffic is transported with multicast duplication in 1060 terms of end-to-end perspective, regardless of customer's individual 1061 protocol. A PE never processes CE's multicast control protocol 1062 (e.g., PIM, IGMP, MLD as Layer-3). Hence, in PE and P, basically the 1063 security threat from malicious customer's C-plane protocol is small. 1065 In VPMS, there is security threat from malicious customers' D-plane 1066 traffic. A PE might receive a high volume of data from a CE. If 1067 there is no safeguard on PE, it will cause excessive replication in 1068 the SP network. Therefore, a VPMS solution SHOULD support traffic 1069 policing to limit the unwanted data traffic. Such a policing 1070 mechanism MUST be configurable per VPN basis, not the total of 1071 various VPNs to isolate malicious customer's traffic from others. 1073 8. Security Considerations 1075 The security requirements common to customers and service providers 1076 are raised in Section 5.5. of [RFC4665], which are fundamental for 1077 all Layer-2 VPN services. VPMS is a variant of Layer-2 VPN, and that 1078 statement also applies to VPMS. 1080 Moreover, in this document, security requirements from the view of 1081 customers are shown in Section 6.5. Security requirements from the 1082 view of providers are shown in Section 7.8. They explain security 1083 considerations that are specific to VPMS. 1085 9. IANA Considerations 1087 This document has no actions for IANA. 1089 10. Acknowledgments 1091 Many thanks to Ichiro Fukuda, Kazuhiro Fujihara, Ukyo Yamaguchi and 1092 Kensuke Shindome for their ideas and feedback in documentation. 1094 The authors gratefully acknowledge the valuable review and comments 1095 provided by Greg Mirsky and Yuji Tochio. 1097 11. References 1099 11.1. Normative References 1101 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1102 Requirement Levels", BCP 14, RFC 2119, March 1997. 1104 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 1105 Private Network (VPN) Terminology", RFC 4026, March 2005. 1107 11.2. Informative References 1109 [I-D.ietf-l2vpn-vpls-mcast] 1110 Aggarwal, R., Kamite, Y., and L. Fang, "Multicast in 1111 VPLS", draft-ietf-l2vpn-vpls-mcast-09 (work in progress), 1112 July 2011. 1114 [I-D.ietf-pwe3-p2mp-pw-requirements] 1115 Heron, G., Wang, L., Aggarwal, R., Vigoureux, M., Bocci, 1116 M., Jin, L., JOUNAY, F., Niger, P., Kamite, Y., DeLord, 1117 S., and L. Martini, "Requirements and Framework for Point- 1118 to-Multipoint Pseudowire", 1119 draft-ietf-pwe3-p2mp-pw-requirements-04 (work in 1120 progress), July 2011. 1122 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 1123 Private Networks (L2VPNs)", RFC 4664, September 2006. 1125 [RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for 1126 Layer 2 Provider-Provisioned Virtual Private Networks", 1127 RFC 4665, September 2006. 1129 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 1130 (VPLS) Using BGP for Auto-Discovery and Signaling", 1131 RFC 4761, January 2007. 1133 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 1134 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 1135 RFC 4762, January 2007. 1137 Authors' Addresses 1139 Yuji Kamite 1140 NTT Communications Corporation 1141 Granpark Tower 1142 3-4-1 Shibaura, Minato-ku 1143 Tokyo 108-8118 1144 Japan 1146 Email: y.kamite@ntt.com 1148 Frederic Jounay 1149 France Telecom 1150 2, avenue Pierre-Marzin 1151 22307 Lannion Cedex 1152 France 1154 Email: frederic.jounay@orange-ftgroup.com 1156 Ben Niven-Jenkins 1157 Velocix 1158 326 Cambridge Science Park 1159 Milton Road, Cambridge 1160 CB4 0WG 1161 UK 1163 Email: ben@niven-jenkins.co.uk 1165 Deborah Brungard 1166 AT&T 1167 Rm. D1-3C22, 200 S. Laurel Ave. 1168 Middletown, NJ, 07748 1169 USA 1171 Email: dbrungard@att.com 1172 Lizhong Jin 1173 ZTE Corporation 1174 889, Bibo Road 1175 Shanghai, 201203 1176 China 1178 Email: lizhong.jin@zte.com.cn