idnits 2.17.1 draft-ietf-l2vpn-vpms-frmwk-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Jan 19, 2009) is 5568 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-04 == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-p2mp-pw-requirements-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: July 23, 2009 France Telecom 6 B. Niven-Jenkins 7 BT 8 D. Brungard 9 AT&T 10 L. Jin 11 Nokia Siemens Networks 12 Jan 19, 2009 14 Framework and Requirements for Virtual Private Multicast Service (VPMS) 15 draft-ietf-l2vpn-vpms-frmwk-requirements-00.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on July 23, 2009. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. 52 Abstract 54 This document provides a framework and service level requirements for 55 Virtual Private Multicast Service (VPMS). VPMS is defined as a Layer 56 2 VPN service that provides point-to-multipoint connectivity for a 57 variety of Layer 2 link layers across an IP or MPLS-enabled PSN. 58 This document outlines architectural service models of VPMS and 59 states generic and high level requirements. This is intended to aid 60 in developing protocols and mechanisms to support VPMS. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 66 1.2. Scope of This Document . . . . . . . . . . . . . . . . . . 4 67 2. Conventions used in this document . . . . . . . . . . . . . . 5 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4.1. Ethernet Use Case . . . . . . . . . . . . . . . . . . . . 5 72 4.2. ATM-based Use Case . . . . . . . . . . . . . . . . . . . . 6 73 4.3. TDM-based Use Case . . . . . . . . . . . . . . . . . . . . 7 74 5. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 8 75 6. Customer Requirements . . . . . . . . . . . . . . . . . . . . 10 76 6.1. Service Topology . . . . . . . . . . . . . . . . . . . . . 10 77 6.1.1. Point-to-Multipoint Support . . . . . . . . . . . . . 10 78 6.1.2. Multiple Source Support . . . . . . . . . . . . . . . 10 79 6.1.3. Reverse Traffic Support . . . . . . . . . . . . . . . 11 80 6.2. Transparency . . . . . . . . . . . . . . . . . . . . . . . 13 81 6.3. Quality of Service (QoS) . . . . . . . . . . . . . . . . . 14 82 6.4. Protection and Restoration . . . . . . . . . . . . . . . . 14 83 6.4.1. Dual-homed Access Support . . . . . . . . . . . . . . 14 84 6.4.2. Single/Dual Traffic Support in Dual-homed Access . . . 14 85 6.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 6.6. Reordering Prevention . . . . . . . . . . . . . . . . . . 16 87 6.7. Failure reporting . . . . . . . . . . . . . . . . . . . . 16 88 7. Service Provider Network Requirements . . . . . . . . . . . . 16 89 7.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 16 90 7.2. Pseudo Wire Signaling and PSN Tunneling . . . . . . . . . 16 91 7.3. Discovering VPMS Related Information . . . . . . . . . . . 17 92 7.4. Activation and Deactivation . . . . . . . . . . . . . . . 18 93 7.5. Inter-AS Support . . . . . . . . . . . . . . . . . . . . . 19 94 7.6. Co-existence with Existing L2VPNs . . . . . . . . . . . . 19 95 7.7. Operation, Administration and Maintenance . . . . . . . . 20 96 7.7.1. Fault Management . . . . . . . . . . . . . . . . . . . 20 97 7.7.2. Testing . . . . . . . . . . . . . . . . . . . . . . . 21 98 7.7.3. Performance Management . . . . . . . . . . . . . . . . 21 99 7.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 21 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 102 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 103 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 104 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 105 11.2. Informative References . . . . . . . . . . . . . . . . . . 22 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 108 1. Introduction 110 1.1. Problem Statement 112 [RFC4664] describes different types of Provider Provisioned Layer 2 113 VPNs (L2 PPVPNs, or L2VPNs); Some of them are widely deployed today, 114 such as Virtual Private Wire Service (VPWS) and Virtual Private LAN 115 Service (VPLS). A VPWS is a VPN service that supplies a Layer 2 (L2) 116 point-to-point service. A VPLS is an L2 service that emulates 117 Ethernet LAN service across a Wide Area Network (WAN). 119 For some use cases described hereafter, there are P2MP (point-to- 120 multipoint) type services for Layer 2 traffic. However, there is no 121 straightforward way to realize them based on the existing L2VPN 122 specifications. 124 In a VPWS, a SP can set up point-to-point connectivity per a pair of 125 CEs but it is not possible to replicate traffic for point-to- 126 multipoint services in the SP's network side. A SP could build 127 multiple PWs independently and have the CEs replicate traffic over 128 them, but this is not only inconvenient for the customer, it's a 129 waste of bandwidth resources. 131 In a VPLS, SPs can natively offer multipoint connectivity across 132 their backbone. Although it is seemingly applicable for point-to- 133 multipoint service as well, there remains extra complexity for SPs to 134 filter unnecessary traffic between irrelevant sites (i.e., from a 135 receiver PE to another receiver PE) because VPLS provides multipoint- 136 to-multipoint connectivity between CEs. Moreover, VPLS's MAC-based 137 learning/forwarding operation is unnecessary for some scenarios 138 particularly if customers only need simple unidirectional point-to- 139 multipoint service, or if they require non- Ethernet Layer 2 140 connectivity. 142 Consequently, there is a real need for a solution that natively 143 provides point-to-multipoint service in L2VPN. 145 1.2. Scope of This Document 147 VPMS is defined as a Layer 2 service that provides point-to- 148 multipoint connectivity for a variety of Layer2 link layers across an 149 IP or MPLS-enabled PSN. VPMS is categorized as a class of provider- 150 provisioned Layer 2 Virtual Private Networks (L2VPN). 152 This document introduces a new service framework, reference model and 153 functional requirements for VPMS by extending the existing framework 154 [RFC4664] and requirements [RFC4665] for L2VPNs. 156 The technical specifications are outside the scope of this document. 157 There is no intent to specify solution-specific details. 159 This document provides requirements from both the Service Provider's 160 and the Customer's point of view. 162 2. Conventions used in this document 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119] . 168 3. Terminology 170 The content of this document makes use of the terminology defined in 171 [RFC4026]. For readability purposes, we list some of the terms here 172 in addition to some specific terms used in this document. 174 3.1. Acronyms 176 P2P: Point-to-Point 178 P2MP: Point-to-Multipoint 180 PW: Pseudowire 182 VPMS: Virtual Private Multicast Service 184 PE/CE: Provider/Customer Edge 186 P: Provider Router 188 AC: Attachment Circuit 190 PSN: Packet Switched Network 192 SP: Service Provider 194 4. Use Cases 196 4.1. Ethernet Use Case 198 For multicast traffic delivery, there is a requirement to deliver a 199 unidirectional P2MP service in addition to the existing P2P service. 200 The demand is growing to provide private (P2MP native Ethernet) 201 services, for various applications such as IP- based delivery of TV 202 broadcasting, content delivery networks, etc. Moreover, many digital 203 audio/video devices (e.g., MPEG-TS, HD-SDI) that supports Ethernet 204 interfaces are becoming available, which will make Ethernet P2MP 205 service more common. Also there are some applications that naturally 206 suited to static transport of VPMS. For example, MPEG-TS/IP/ 207 Ethernet in DVB-H is typically static broadcast without any signaling 208 in the upstream direction. VPMS could be a possible solution to 209 provide these kinds of networking connectivity over PSNs. 211 Currently VPLS [RFC4761][RFC4762] is able to give P2MP-type 212 replication for Ethernet traffic. Native VPLS already supports this 213 capability via a full mesh of PWs, and an extension to optimize 214 replication is also proposed [I-D.ietf-l2vpn-vpls-mcast] as an 215 additional feature. However, VPLS by nature requires MAC-based 216 learning and forwarding, which might not be needed in some cases by 217 particular users. Generally, video distribution applications use 218 unidirectional P2MP traffic, but may not always require any added 219 complexity of MAC address management. In addition, VPLS is a service 220 that essentially provides any-to-any connectivity between all CEs in 221 a L2VPN as it emulates a LAN service. However, if only P2MP 222 connectivity is required, the traffic between different receivers is 223 not always needed, and traffic from receiver to sender is not always 224 needed, either. In these cases, VPMS is a service that provides much 225 simpler operation. 227 Note that VPMS provides single coverage of receiver membership; that 228 is, there is no distinct differentiation for multiple multicast 229 groups. All traffic from a particular Attachment Circuit (AC) will 230 be forwarded toward the same remote receivers, even if the 231 destination MAC address is changed. Basically in VPMS, destination 232 MAC addresses are not used for forwarding, which is significantly 233 different from VPLS. If MAC-based forwarding is preferred (i.e., 234 multicast/unicast differentiation of MAC address), VPLS should be 235 chosen rather than VPMS. 237 4.2. ATM-based Use Case 239 A use case of ATM-based service in VPMS could be to offer the 240 capability for service providers to support IP multicast wholesale 241 services over ATM in case the wholesale customer relies on ATM 242 infrastructure. The P2MP support alleviates the constraint in terms 243 of replication for ATM to support IP multicast services. 245 Another use case of VPMS for ATM is for audio/video stream 246 applications. Today many digital TV broadcasting networks adopt ATM- 247 based distribution systems with point-to-multipoint PVPs/PVCs. The 248 transport network supports replicating ATM cells in transit nodes to 249 efficiently deliver programs to multiple terminals. For migrating 250 such ATM-based networks onto IP/MPLS-based networks, VPMS is 251 considered to be a candidate solution. 253 4.3. TDM-based Use Case 255 Today the existing VPWS already supports TDM emulation services 256 (SAToP, CESoPSN or TDMoIP). It is a Layer 1 service, not Layer 2 257 service; however, a common architecture is being used since they are 258 all packet-based emulations over a SP's network. VPMS is also 259 considered to be a solution for such TDM applications that require 260 point-to-multipoint topology. 262 In a PSN environment, the existing VPWS allows support for 2G/3G 263 mobile backhauling (e.g. TDM traffic for GSM's Abis interface, ATM 264 traffic for Release 99 UMTS's Iub interface). Currently, the Mobile 265 backhauling architecture is always built as a star topology between 266 the 2G/3G controller (e.g. BSC or RNC) and the 2G/3G Base Stations 267 (BTS or NodeB). Therefore VPWSes (P2P services) are used between 268 each Base Station and their corresponding controller and nothing more 269 is required. 271 As far as synchronization in a PSN environment is concerned, 272 different mechanisms can be considered to provide frequency and phase 273 clock required in the 2G/3G Mobile environment to guarantee mobile 274 handover and strict QoS. One of them consists of using Adaptive 275 Clock Distribution and Recovery. With this method a Master element 276 distributes a reference clock at protocol level by regularly sending 277 TDM PW packets (SAToP, CESoPSN or TDMoIP) to Slave elements. This 278 process is based on the fact that the volume of transmitted data 279 arrival is considered as an indication of the source frequency that 280 could be used by the Slave element to recover the source clock 281 frequency. Consequently, with the current methods, the PE connected 282 to the Master must setup and maintain as many VPWS (P2P) as their are 283 Slave elements, and the Master has to replicate the traffic. A 284 better solution to deliver the clock frequency would be to use a VPMS 285 which supports P2MP traffic. This may scale better than P2P services 286 (VPWS) with regards to the forwarding plane at the Master since the 287 traffic is no longer replicated to individual VPWSes (P2P) but only 288 to the AC associated to the VPMS (P2MP). It may ease the 289 provisioning process since only one source endpoint must be 290 configured at the Ingress PE. This alleviated provisioning process 291 would simplify the introduction of new Base Stations. The main gain 292 would be to avoid replication on the Master and hence save bandwidth 293 consumed by the synchronization traffic which typically requires the 294 highest level of QoS. This kind of traffic will be competing with 295 equivalent QOS traffic like VoIP, which is why it is significant to 296 save the slightest bandwidth. 298 5. Reference Model 300 The VPMS reference model is shown in Figure 1. 302 +-----+ AC1 AC2 +-----+ 303 | CE1 |>---+ ------------------------ +--->| CE2 | 304 +-----+ | | | | +-----+ 305 VPMS A | +------+ VPMS A +------+ | VPMS A 306 Sender +->|......>...+.......... >......|>-+ Receiver 307 | VPMS | . | VPMS | 308 | PE1 | . VPMS B | PE2 | 309 +-<|......<.. . ....+.....<......|<-+ 310 | +------+ . . +------+ | 311 +-----+ | | . . | | +-----+ 312 | CE4 |<---+ |Routed . . | +---| CE3 | 313 +-----+ AC4 |Backbone. . | AC3 +-----+ 314 VPMS B | . . | VPMS B 315 Receiver | +-v-----v-+ | Sender 316 ------| . . |------- 317 | . VPMS. | 318 | . PE3 . | 319 +---------+ 320 v v 321 | | 322 AC5| |AC6 323 v v 324 +-----+ +-----+ 325 | CE5 | | CE6 | 326 +-----+ +-----+ 327 VPMS A VPMS B 328 Receiver Receiver 330 Figure 1: Reference Model for VPMS 332 A VPMS instance is defined as a service entity manageable in VPMS 333 architecture. A single VPMS instance provides isolated service 334 reachability domain to each CE, so it corresponds to a so-called 335 "VPN" as a specific set of sites that allows communication. A single 336 VPMS instance provides a unique unidirectional point-to-multipoint 337 L2VPN service. In Figure 1, there are two VPMS instances shown, VPMS 338 A and VPMS B. In principle, there is no traffic exchange allowed 339 between these different instances, so they are treated as different 340 VPNs. 342 In a VPMS, a single CE-PE connection is used for transmitting frames 343 for delivery to multiple remote CEs, with point-to-multipoint 344 duplication. The SP's network (PE as well as P) has a role to 345 duplicate frames so that the traffic source does not need to send 346 multiple frames to individual receivers. 348 Like VPWS, an Attachment Circuit (AC) is provided to accommodate CEs 349 in a VPMS. In a VPMS, an AC attached to a VPMS MUST be configured as 350 "sender" or "receiver" not both. That is, any AC is associated with 351 the role of either sending side (Tx) or receiving side (Rx) from the 352 view of the CE. Thus every AC deals with unidirectional traffic 353 flows. A sender AC does not have a capability of transmitting the 354 traffic back to a CE at upstream side. Likewise a receiver AC does 355 not have a capability of receive the traffic from a CE at downstream 356 side. In Figure 1, AC1 and AC3 are configured as senders while AC2, 357 AC4, AC5 and AC6 are configured as receivers. In VPMS A, CE1 could 358 send traffic via AC1, but CE2 and CE5 could not send back traffic. 360 A CE which is locally connected to a sender AC is called a sender CE. 361 Also a CE which is locally connected to a receiver AC is called a 362 receiver CE. However, such CEs's roles will not be managed directly 363 in VPMS because the configured AC's role (sender or receiver) will 364 automatically determine them. 366 Basically there is a one-to-one mapping between an attachment circuit 367 and a VPMS instance. For example, all traffic from CE1 to PE1 368 (thorough AC1) is mapped to VPMS A (to CE2 and CE5). 370 In a VPMS, PEs will be connected by PW technology which may include 371 P2MP traffic optimization (i.e., P2MP PW. See section 7.2.). P2MP 372 traffic optimization will provide the benefit of traffic replication 373 for high bandwidth efficiency. The sender CE has only to transmit 374 one stream towards the PE and it does not have to replicate traffic. 375 Also routed backbone provides IP or MPLS-enabled PSN tunnels for 376 transporting the PW traffic. 378 Regarding end-to-end traffic topology between the PEs, a single VPMS 379 instance (i.e., one VPN) may correspond to a single unidirectional 380 P2MP PW topology. In Figure 1, VPMS A (one instance) has a single 381 P2MP PW topology (from PE1 to PE2 and PE3). However, there is also a 382 case that a single VPMS consists of two or more P2MP PW topology 383 grouped which is typically used for redundancy. The details are 384 given in section 6.1.2. 386 VPMS can support various Layer 2 protocol services such as Ethernet, 387 ATM, etc. 389 6. Customer Requirements 391 6.1. Service Topology 393 6.1.1. Point-to-Multipoint Support 395 A solution MUST support unidirectional point-to-multipoint 396 connectivity from a sender to multiple receivers. A sender CE is 397 assured to send traffic to one or more receiver CEs. Receiver CEs 398 include not only the CEs which are located at remote sites, but also 399 the local CEs which are connected to the same sender-side PE. If 400 there is only one receiver in the instance, it is considered 401 equivalent to unidirectional point-to-point traffic. 403 6.1.2. Multiple Source Support 405 A solution MUST support multiple sender topologies in one VPMS 406 instance, where a common receiver group is reachable from two or more 407 senders. This means that a solution needs to support having multiple 408 P2MP topologies in the backbone whose roots are located apart in a 409 common service. In other words, each P2MP topology MUST only have a 410 single sender, however multiple P2MP topologies can be grouped 411 together into a single VPMS instance. For example, in Figure 2, 412 traffic from sender CE1 and CE2 both reach receivers CE3 and CE4 413 while CE1, CE2, CE3 and CE4 all are associated with a single service. 414 This topology is useful for increasing service reliability by 415 redundant sources. Note that every receiver has only to have one AC 416 connected to each PE to receive traffic. (in Figure 2, AC3 and AC4 417 respectively). Thus a solution will also need to support protection 418 and restoration mechanism combining these multiple P2MP topologies. 419 (See section 6.4 too). 421 +-----+ AC1 AC2+-----+ 422 | CE1 |>-+ ---------------------------- +-<| CE2 | 423 +-----+ | | | | +-----+ 424 VPMS A | +------+ +------+ | VPMS A 425 Sender +->|......>.. .............+..<......|<-+ Sender 426 Tx | VPMS | . . . | VPMS | Tx 427 | PE 1 | . . . | PE 2 | 428 | | . . . | | 429 +------+ . . . +------+ 430 | . . . | 431 | +.. . ...... . | 432 | . . . . | 433 | . . . . | 434 | +-v----v-+ +-v----v-+ | 435 ---| . . |---| . . |--- 436 VPMS| . . | | . . |VPMS 437 PE 3| . | | . |PE 4 438 +--------+ +--------+ 439 v v 440 AC3| |AC4 441 v v 442 +-----+ +-----+ 443 | CE3 | | CE4 | 444 +-----+ +-----+ 445 VPMS A VPMS A 446 Receiver Receiver 448 Figure 2: Multiple source support 450 6.1.3. Reverse Traffic Support 452 There are cases where a reverse traffic flow is necessary. A sender 453 CE might sometimes want to receive traffic from a receiver CE. There 454 are some usage scenarios for this, such as stream monitoring through 455 a loopback mechanism, control channels which need feedback 456 communication etc. The simplest way to accomplish this is to provide 457 different VPMS instances for reverse traffic, i.e. a sender CE is a 458 receiver of another VPMS instance. 460 Figure 3 illustrates this kind of reverse traffic scenario, where CE1 461 is configured as a sender in VPMS A and a receiver in VPMS B. VPMS B 462 is used for reverse traffic. Note that a closed single network here 463 is composed of two VPMS instances. In operational terms, CE1 and CE4 464 belong to the same closed "VPN" by administrative policy (e.g., CE1, 465 CE2, CE3 and CE4 are the devices in one enterprise's intranet 466 network). 468 Such bi-directional instances can be easily created if two distinct 469 ACs are provisioned for sending and receiving exclusively (e.g., if 470 VLAN id in dot1Q tagged frame is a service delimiter, different VLAN 471 ids are uniquely allocated for Tx and Rx). This approach is 472 acceptable if a receiver CE device can change Layer 2 interface 473 appropriately in data transmitting and receiving. 475 Meanwhile it is also true that this might be considered a limitation 476 in some deployment scenarios. If a CE is an IP router or Ethernet 477 bridge, reverse traffic is normally expected to be received on the 478 same interface as forward traffic on the receiver CE. (i.e., the same 479 VLAN id is to be used for reverse traffic if the AC supports dot1Q 480 tagged frames.) 482 Therefore, in a VPMS solution, both of the two type of ACs, sending 483 (Tx) and receiving (Rx), SHOULD be allowed to be placed in the same 484 physical/virtual circuit. In Figure 3, suppose AC5 of VPMS A is 485 provisioned as {VLAN id = 100, direction= Rx}. It is expected that 486 operators can provision AC6 of VPMS B in the same physical port as 487 {VLAN id = 100, direction = Tx}. That is, the combination between 488 VLAN id and the flow direction is now considered to be a service 489 delimiter. 491 Note, in most implementations of VPWS today, every AC is always 492 considered bidirectional and a unique Layer 2 header/circuit (ATM 493 VPI/VCI, an Ethernet port, a VLAN etc.) is considered the service 494 delimiter. In contrast in VPMS, every AC is considered 495 unidirectional and traffic direction is an additional element to 496 identify a unique AC. 498 +-----+ <-- Rx VPMS B 499 | CE1 |<----------------+ 500 +-----+--------------+ | 501 VPMS A Sender --> Tx VPMS A| | 502 VPMS B Receiver AC1 v ^ AC2 503 +----------+ VPMS 504 | . . | PE1 505 | . ... | 506 -------| . . |-------- 507 | +-v------^-+ | 508 | . . | 509 | + . | 510 +------+ . . . . +------+ 511 +-<|......<.. . .. . ......>..... |>-+ 512 | | VPMS | . . | VPMS | | 513 AC3| | PE2 | . . | PE3 | |AC4 514 | +------+ . . +------+ | 515 +-----+ | | . . | | +-----+ 516 | CE2 |<--+ | Routed . . | +-->| CE3 | 517 +-----+ <-- | Backbone. . | --> +-----+ 518 VPMS A Rx | +-v------^-+ | Rx VPMS A 519 Receiver -------| . . |-------- Receiver 520 | . ... | 521 | . . | VPMS 522 +----------+ PE4 523 AC5v ^AC6 524 | | <-- Tx VPMS B +-----+ 525 | +----------------<| CE4 | 526 +------------------->+-----+ 527 --> Rx VPMS A VPMS A Receiver 528 VPMS B Sender 530 Figure 3: Reverse traffic support 532 6.2. Transparency 534 A solution is intended to provide Layer 2 traffic transparency. 535 Transparency SHOULD be honoured per VPMS instance basis. In other 536 words, Layer 2 traffic can be transparently transported from a sender 537 CE to receiver CEs in a given instance. Note, however, if service 538 delimiting fields (VLAN Id in Ethernet, VPI/VCI in ATM, DLCI in FR 539 etc.) are assigned by SP, they are not transparent. It depends on 540 SP's choice if they are assigned at each AC. Hence it could be that 541 some of receiver CEs are getting traffic with different delimiting 542 fields than the other receiver CEs. 544 VPMS solution SHOULD NOT require any special packet processing by the 545 end users (CEs). 547 6.3. Quality of Service (QoS) 549 A customer may require that the VPMS service provide the guaranteed 550 QoS. In particular, for real time applications which are considered 551 common in point-to-multipoint delivery, delay and loss sensitive 552 traffic MUST be supported. The solution SHOULD provide native QoS 553 techniques for service class differentiation, such as IEEE 802.1p CoS 554 for Ethernet. 556 For bandwidth committed services (e.g., ATM CBR), a solution SHOULD 557 guarantee end-to-end bandwidth. It MAY provide flow admission 558 control mechanisms to achieve that. 560 6.4. Protection and Restoration 562 A solution MUST provide protection and restoration mechanism for end- 563 to-end services. 565 6.4.1. Dual-homed Access Support 567 A solution MUST allow dual-homed redundant access from a CE to 568 multiple PEs. Additionally, a solution SHOULD provide protection 569 mechanism between the different PEs to which a CE is attached. This 570 is because when an ingress PE node fails whole traffic delivery will 571 fail unless a backup sender PE is provided, even in case of dual- 572 homed access. Similarly, if an egress PE node fails, traffic toward 573 that CE is never received unless a backup egress PE is provided. 574 Figure 4 is an example for this access topology. 576 6.4.2. Single/Dual Traffic Support in Dual-homed Access 578 When dual-homed access to sender PEs is provided, a solution MAY 579 allow a sender CE to transmit just a single copy of the traffic to 580 either one of the two sender PEs, or to transmit a copy of the 581 traffic to both the PEs simultaneously. The latter scenario consumes 582 more resource of CE-PE link than the single traffic scenario, but it 583 is usually applicable when a source device has only a simple 584 forwarding capability without any switchover functionality. In the 585 dual traffic case, the backup ingress PE SHOULD be able to filter the 586 incoming unnecessary traffic while active PE is working. Also in 587 either case, single traffic or dual traffic, the protection mechanism 588 of ingress PEs described in the previous subsection will be necessary 589 to handle the traffic appropriately. 591 In the case of dual-homed access to receiver PEs, a solution MAY 592 allow a receiver CE to receive a single copy of the traffic from 593 either one of the two egress PEs, or receive a copy of the traffic 594 from both PEs simultaneously. The dual traffic approach is 595 applicable if CE has fast switchover capability as a receiver by 596 selecting either one of incoming traffic, but note that additional 597 traffic resources are always consumed at PE-CE link of backup side. 598 Specifically in the single traffic case, it might be needed to 599 support switchover mechanism between egress PEs in failure. 601 +-----+ 602 | CE1 |--------------+ 603 +-----+ \ 604 VPMS A | | 605 Sender | v AC1 606 (dual-homed)| +----+ 607 | -----|VPMS|-------- 608 | | | PE1| | 609 \ | +----+ | 610 \ AC2 +----+ +----+ AC4 611 +------>|VPMS| |VPMS|------------+ 612 | PE2| Routed | PE3| \ 613 +----+ Backbone +----+\ | 614 AC3 / | | \ AC5 v 615 +-----+ / | | \ +-----+ 616 | CE2 |<-+ | | \ | CE3 | 617 +-----+ | +----+ | \ +-----+ 618 VPMS A ----|VPMS|--------- \ VPMS A 619 Receiver | PE4| | Receiver 620 +----+ | 621 | AC6 v 622 \ +-----+ 623 +--------------->| CE4 | 624 +-----+ 625 VPMS A 626 Receiver 627 (dual-homed) 629 Figure 4: Dual homing support 631 6.5. Security 633 The basic security requirement raised in Section 6.5 of [RFC4665] 634 also applies to VPMS. 636 In addition, a VPMS solution MAY have the mechanisms to activate the 637 appropriate filtering capabilities (for example, MAC/VLAN filtering 638 etc.), and it MAY be added with the filtering control mechanism 639 between particular sender/receiver sites inside a VPMS instance. For 640 example, in Figure 1, filtering can be added such that traffic from 641 CE1 to CE4 and CE5 is allowed but traffic from CE1 to CE6 is 642 filtered. 644 6.6. Reordering Prevention 646 A solution SHOULD prevent Layer 2 frame reordering when delivering 647 customer traffic under normal conditions. 649 6.7. Failure reporting 651 A solution MAY provide information to the customer about failures. 652 For example, if there is a loss of connectivity toward some of the 653 receiver CEs, it is reported to the sender CE. 655 7. Service Provider Network Requirements 657 7.1. Scalability 659 A VPMS solution MUST be designed to scale well with an increase in 660 the number of any of the following metrics: 662 - the number of PEs (per VPMS instance and total in a SP network) 663 - the number of VPMS instances (per PE and total) 664 - the number of sender CEs (per PE, VPMS instance and total) 665 - the number of receiver CEs (per PE, VPMS instance and total) 667 A VPMS solution SHALL document its scalability characteristics in 668 quantitative terms. A solution SHOULD quantify the amount of state 669 that a PE and a P device has to support. 671 The scalability characteristics SHOULD include: 673 - the processing resources required by the control plane in managing 674 PWs (neighborhood or session maintenance messages, keepalives, 675 timers, etc.) 676 - the processing resources required by the control plane in managing 677 PSN tunnels 678 - the memory resources needed for the control plane 679 - other particular elements inherent to each solution that impact 680 scalability 682 7.2. Pseudo Wire Signaling and PSN Tunneling 684 A VPMS solution SHOULD provide an efficient replication that can 685 contribute to optimizing the bandwidth usage required in a SP's 686 network. For supporting efficient replication, it is expected to 687 take advantage of PW and PSN mechanisms that are capable of P2MP 688 traffic. 690 Regarding PW mechanism, [I-D.ietf-pwe3-p2mp-pw-requirements] 691 introduces P2MP PW concept and its requirements, showing two basic 692 approaches of providing replication. One is SS (Single Segment)-PW 693 model that provides replication by PSN tunnel such as P2MP LSP (i.e., 694 by outer label layer), and the other is MS (Multi Segment)-PW model 695 that provides replication by multiple interconnected PWs (i.e., by 696 inner label layer). In either case, end-to-end P2MP topology in VPMS 697 is common from the view of PEs and ACs. Requirements as a provider 698 service specified in this document will be commonly applied 699 regardless of P2MP PW's signaling model. 701 This document does not raise any specific requirements for particular 702 PSN tunneling schemes (point-to-point, point-to-multipoint and 703 multipoint-to-multipoint) that is applied only to VPMS. The actual 704 type of PSN tunnel used in VPMS will be dependent on individual 705 deployment scenarios (e.g., which PSN protocol is available now in 706 the core and how much network resources operators will want to 707 optimize). 709 7.3. Discovering VPMS Related Information 711 A solution SHOULD support auto-discovery methods that dynamically 712 allow VPMS information to be discovered by the PEs to minimize the 713 amount of configuration the SP must perform. 715 All of the requirements on discovery described in Section 7.3 of 716 [RFC4665] SHOULD be satisfied in VPMS as well. 718 Auto-discovery will help operators' initial configuration of adding a 719 new VPN (i.e., VPMS instance), adding/deleting new sender/receiver, 720 and so on. 722 The information related to remote sites will be as follows: 724 - Information to identify the VPMS instance 725 - PE router ID / IP address as location information 726 - Information to identify Attachment Circuits and their associated 727 group information to compose a unique service (i.e., VPMS 728 instance). 729 - AC role in each VPMS (Sender or Receiver) 730 - SP-related information (AS number, etc. for an inter-provider 731 case) 733 Following is an example scenario: by default, every PE will have the 734 association among the information described above. Suppose a new PE 735 having an AC is provisioned in the existing VPMS instance and this AC 736 is configured as receiver. This information will be automatically 737 discovered by the other existing remote PEs (i.e., ingress and egress 738 PEs in the same VPMS instance). Once the ingress PE discovers this 739 new PE/AC, it can automatically add it as the new leaf of P2MP 740 topology according to P2MP PW signaling mechanism. This operation 741 does not require any new configuration at the existing PEs. 743 7.4. Activation and Deactivation 745 This section raises generic requirements for handling related 746 information about remote sites after the initial provisioning to ease 747 the total operation of VPMS. 749 A solution SHOULD provide a way to activate/deactivate the 750 administrative status of each CE/AC. After initial provisioning, a 751 SP might change connectivity configuration between particular CEs 752 inside a single VPMS instance for operational reasons. This feature 753 will be beneficial to help such a scenario. 755 For example, in Figure 5, CE1, CE3, CE4 and CE5 (and their ACs) are 756 initially provisioned for VPMS A. CE2 is not provisioned for any 757 VPMSes. In VPMS A, CE1 is a sender and CE3, CE4 and CE5 are 758 receivers. Traffic will usually flow from CE1 to all receivers, CE3, 759 CE4 and CE5. However, for maintenance operation, application's 760 request (e.g., stream program has changed) or some other reasons, CE4 761 needs to be set as administratively deactivated. Then it becomes 762 necessary to turn off traffic from PE4 to CE4. This operation must 763 be appropriately distinguished from failure cases. 765 When deactivating a particular site, backbone PSN/PW resources (e.g., 766 admission control of PSN tunnel) MAY be released for that particular 767 direction in order to provide that bandwidth to other services. In 768 Figure 5, CE3 is now administratively activated and receiving 769 traffic. However, if CE3 comes to be administratively deactivated, 770 and if RSVP-TE (including P2P and/or P2MP) is used for backbone PSN, 771 then TE reserved resources from PE1 to PE3 may be released. 773 In addition, a solution SHOULD allow single-sided activation 774 operation at a sender PE. In some scenarios, operators prefer 775 centralized operation. This is often considered natural for one-way 776 digital audio/video distribution applications: SPs often want to 777 complete their service delivery by a single operation at one source 778 PE, not by multiple operations at many receiver PEs. Figure 5 779 illustrates this scenario, where a SP only has to do single-sided 780 operation at PE1 (source) to administratively activate/deactivate 781 various connections from AC1 to AC3, AC4 and/or AC5. It is not 782 needed to perform operations on PE3 and PE4 directly. 784 +-----+ AC1 785 + CE1 +----------------+ 786 +-----+ | 787 VPMS A Sender | 788 (sending now) v 789 +----+ 790 -----|VPMS|-------- 791 | | PE1| | 792 | +----+ | 793 +----+ +----+ 794 |VPMS| |VPMS| 795 | PE2| Routed | PE3| 796 +----+ Backbone +----+ 797 AC2 / | | \ AC3 798 +-----+ / | | \ +-----+ 799 + CE2 +<-+ | | +->| CE3 | 800 +-----+ | +----+ | +-----+ 801 (not provisioned) ----|VPMS|--------- VPMS A Receiver 802 | PE4| (receiving now) 803 +----+ 804 AC5 / \ AC4 805 +-----+ / \ +-----+ 806 + CE5 +<----------+ +---------------->| CE4 | 807 +-----+ +-----+ 808 VPMS A Receiver VPMS A Receiver 809 (receiving now) (not receiving) 811 CE1/AC1: Administratively activated 812 CE2/AC2: No VPMS provisioned 813 CE3/AC3: Administratively activated 814 CE4/AC4: Administratively deactivated 815 CE5/AC5: Administratively activated 817 Figure 5: Site activation and deactivation 819 7.5. Inter-AS Support 821 A solution SHOULD support inter-AS scenarios, where there is more 822 than one provider providing a common VPMS instance and VPN. More 823 specifically, it is necessary to consider the case where some of the 824 PEs that compose one VPMS belong to several different ASes. 826 7.6. Co-existence with Existing L2VPNs 828 A solution MUST co-exist with the existing L2VPNs (e.g., VPWS, VPLS) 829 across the same SP's network. A solution MUST NOT impede the 830 operation of auto-discovery and signalling mechanism that are already 831 supported by the PEs for those existing L2VPNs. 833 7.7. Operation, Administration and Maintenance 835 7.7.1. Fault Management 837 7.7.1.1. Fault Detection 839 A solution MUST provide tools that detect reachability failure and 840 traffic looping of P2MP transport in a VPMS instance. If multiple 841 sources are supported (i.e., multiple P2MP topologies are grouped 842 together into a single VPMS instance), such tools MUST be able to 843 perform distinguishing each P2MP topology. 845 7.7.1.2. Fault Notification 847 A solution MUST provide fault notification and trouble tracking 848 mechanisms. (e.g. SNMP-trap and syslog that notify fault to remote 849 NMS.) 851 In VPMS one point of failure at upstream often affects a number of 852 downstream PEs and ACs that might raise a notification message. 853 Hence notification messages MAY be summarized or compressed for 854 operators' ease of management. 856 In case of receiver-side failure (receiver PE or its AC), this fault 857 status SHOULD be able to be monitored at sender PE. This will help 858 an operator to monitor each receiver PEs/AC in a centralized manner; 859 that is, a sender PE can collect receiver-side information. How this 860 status is transferred depends on a solution. 862 In contrast, in case of sender-side failure (sender PE or its AC), 863 this fault status SHOULD also be able to be monitored at receiver 864 PEs. This will help an operator to troubleshoot at receiver PEs 865 (i.e., distinguish local AC's failure from remote upstream AC's 866 failure easily). 868 In any case of failure at SP's network, fault information MAY be 869 notified to the customer. Specifically, such fault MAY trigger 870 generating customer OAM message toward CEs (e.g., AIS) and/or 871 shutting down receiver ACs. 873 7.7.1.3. Fault Isolation 875 A solution MUST provide diagnostic/troubleshooting tools for P2MP 876 transport in a VPMS instance. 878 7.7.2. Testing 880 A solution MUST provide a mechanism for testing each P2MP 881 connectivity and verifying the associated information in a VPMS 882 instance. The connectivity is between sender and all receiver ACs. 884 Operators will run testing before and after service activation. 885 Testing mechanism SHOULD support end-to-end testing of the data path 886 used by customer's data. End-to-end testing will have CE-to-CE path 887 test and PE-to-PE path test. A solution MUST support PE-to-PE path 888 test and MAY support CE-to-CE path test. In either case the data 889 path provided for each VPMS is unidirectional, hence if loopback 890 testing is supported, additional consideration about reverse-path 891 might also be needed (see section 6.1.3). 893 7.7.3. Performance Management 895 A solution MUST offer mechanisms to monitor traffic performance 896 parameters and statistics in each P2MP traffic. 898 A solution MUST provide access to: 900 - Traffic statistics (total traffic forwarded, incoming, outgoing, 901 dropped, etc., by period of time) 903 A solution SHOULD provide access to: 905 - Performance information related to traffic usage, e.g., one-way 906 delay, one-way jitter, one-way loss, delay variations (the 907 difference of various one-way delay from a particular sender PE to 908 multiple receiver PEs) etc. 910 All or part of this information SHOULD be made available through 911 standardized SNMP MIB Modules (Management Information Base). 913 It is expected that such information can be used for SLA monitoring 914 between sender and receiver, to give the SP a clear picture of 915 current service providing to the customer. 917 7.8. Security 919 TBD (for further study for next revision) 921 8. Security Considerations 923 Security consideration will be covered by section 6.5. and section 924 7.8. (This is for further study for next revision.) 926 9. IANA Considerations 928 This document has no actions for IANA. 930 10. Acknowledgments 932 Many thanks to Ichiro Fukuda, Kazuhiro Fujihara, Ukyo Yamaguchi and 933 Kensuke Shindome for their valuable review and feedback. 935 11. References 937 11.1. Normative References 939 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 940 Requirement Levels", BCP 14, RFC 2119, March 1997. 942 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 943 Private Network (VPN) Terminology", RFC 4026, March 2005. 945 11.2. Informative References 947 [I-D.ietf-l2vpn-vpls-mcast] 948 Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter, 949 "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-04 (work 950 in progress), June 2008. 952 [I-D.ietf-pwe3-p2mp-pw-requirements] 953 JOUNAY, F., Niger, P., Kamite, Y., DeLord, S., and L. 954 Martini, "Requirements for Point-to-Multipoint 955 Pseudowire", draft-ietf-pwe3-p2mp-pw-requirements-00 (work 956 in progress), September 2008. 958 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 959 Private Networks (L2VPNs)", RFC 4664, September 2006. 961 [RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for 962 Layer 2 Provider-Provisioned Virtual Private Networks", 963 RFC 4665, September 2006. 965 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 966 (VPLS) Using BGP for Auto-Discovery and Signaling", 967 RFC 4761, January 2007. 969 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 970 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 971 RFC 4762, January 2007. 973 Authors' Addresses 975 Yuji Kamite 976 NTT Communications Corporation 977 Granpark Tower 978 3-4-1 Shibaura, Minato-ku 979 Tokyo 108-8118 980 Japan 982 Email: y.kamite@ntt.com 984 Frederic Jounay 985 France Telecom 986 2, avenue Pierre-Marzin 987 22307 Lannion Cedex 988 France 990 Email: frederic.jounay@orange-ftgroup.com 992 Ben Niven-Jenkins 993 BT 994 208 Callisto House, Adastral Park 995 Ipswich, IP5 3RE 996 UK 998 Email: benjamin.niven-jenkins@bt.com 1000 Deborah Brungard 1001 AT&T 1002 Rm. D1-3C22, 200 S. Laurel Ave. 1003 Middletown, NJ, 07748 1004 USA 1006 Email: dbrungard@att.com 1008 Lizhong Jin 1009 Nokia Siemens Networks 1010 Building 89, 1122 North QinZhou Road, 1011 Shanghai, 200211 1012 P.R.China 1014 Email: lizhong.jin@nsn.com