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