idnits 2.17.1 draft-ietf-l2vpn-vpms-frmwk-requirements-02.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? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Oct 26, 2009) is 5294 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-05 == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-p2mp-pw-requirements-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Kamite 3 Internet-Draft NTT Communications 4 Intended status: Informational F. Jounay 5 Expires: April 29, 2010 France Telecom 6 B. Niven-Jenkins 7 BT 8 D. Brungard 9 AT&T 10 L. Jin 11 Nokia Siemens Networks 12 Oct 26, 2009 14 Framework and Requirements for Virtual Private Multicast Service (VPMS) 15 draft-ietf-l2vpn-vpms-frmwk-requirements-02.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 April 29, 2010. 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 in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 This document provides a framework and service level requirements for 54 Virtual Private Multicast Service (VPMS). VPMS is defined as a Layer 55 2 VPN service that provides point-to-multipoint connectivity for a 56 variety of Layer 2 link layers across an IP or MPLS-enabled PSN. 57 This document outlines architectural service models of VPMS and 58 states generic and high level requirements. This is intended to aid 59 in developing protocols and mechanisms to support VPMS. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Scope of This Document . . . . . . . . . . . . . . . . . . 4 66 2. Conventions used in this document . . . . . . . . . . . . . . 5 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. Ethernet Use Case . . . . . . . . . . . . . . . . . . . . 6 71 4.1.1. Ethernet-based multicast stream . . . . . . . . . . . 6 72 4.1.2. Ethernet-based time/frequency synchronization . . . . 7 73 4.2. ATM-based Use Case . . . . . . . . . . . . . . . . . . . . 7 74 4.2.1. ATM-based multicast stream . . . . . . . . . . . . . . 7 75 4.3. TDM-based Use Case . . . . . . . . . . . . . . . . . . . . 8 76 4.3.1. TDM-based multicast stream . . . . . . . . . . . . . . 8 77 5. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 8 78 6. Customer Requirements . . . . . . . . . . . . . . . . . . . . 10 79 6.1. Service Topology . . . . . . . . . . . . . . . . . . . . . 10 80 6.1.1. Point-to-Multipoint Traffic Support . . . . . . . . . 10 81 6.1.2. Reverse Traffic Support . . . . . . . . . . . . . . . 10 82 6.2. Transparency . . . . . . . . . . . . . . . . . . . . . . . 12 83 6.3. Quality of Service (QoS) . . . . . . . . . . . . . . . . . 13 84 6.4. High Availability . . . . . . . . . . . . . . . . . . . . 13 85 6.4.1. Dual-homed Access Support . . . . . . . . . . . . . . 13 86 6.4.2. Single/Dual Traffic Support in Dual-homed Access . . . 16 87 6.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 6.6. Reordering Prevention . . . . . . . . . . . . . . . . . . 17 89 6.7. Failure reporting . . . . . . . . . . . . . . . . . . . . 17 90 7. Service Provider Network Requirements . . . . . . . . . . . . 17 91 7.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 17 92 7.2. Pseudo Wire Signaling and PSN Tunneling . . . . . . . . . 17 93 7.3. Auto-discovery . . . . . . . . . . . . . . . . . . . . . . 18 94 7.4. Activation and Deactivation . . . . . . . . . . . . . . . 19 95 7.5. Inter-AS Support . . . . . . . . . . . . . . . . . . . . . 21 96 7.6. Co-existence with Existing L2VPNs . . . . . . . . . . . . 21 97 7.7. Operation, Administration and Maintenance . . . . . . . . 22 98 7.7.1. Fault Management . . . . . . . . . . . . . . . . . . . 22 99 7.7.2. Testing . . . . . . . . . . . . . . . . . . . . . . . 22 100 7.7.3. Performance Management . . . . . . . . . . . . . . . . 23 101 7.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 104 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 105 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 106 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 107 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 110 1. Introduction 112 1.1. Problem Statement 114 [RFC4664] describes different types of Provider Provisioned Layer 2 115 VPNs (L2 PPVPNs, or L2VPNs). Some of them are widely deployed today, 116 such as Virtual Private Wire Service (VPWS) and Virtual Private LAN 117 Service (VPLS). A VPWS is a VPN service that supplies a Layer 2 (L2) 118 point-to-point service. A VPLS is an L2 service that emulates 119 Ethernet LAN service across a Wide Area Network (WAN). 121 For some use cases described hereafter, there are P2MP (point-to- 122 multipoint) type services for Layer 2 traffic. However, there is no 123 straightforward way to realize them based on the existing L2VPN 124 specifications. 126 In a VPWS, a SP can set up point-to-point connectivity per a pair of 127 CEs but it is not possible to replicate traffic for point-to- 128 multipoint services in the SP's network side. A SP could build 129 multiple Pseudowires (PWs) independently and have the CEs replicate 130 traffic over them, but this is not only inconvenient for the 131 customer, it's a waste of bandwidth resources. 133 In a VPLS, SPs can natively offer multipoint connectivity across 134 their backbone. Although it is seemingly applicable for point-to- 135 multipoint service as well, there remains extra complexity for SPs to 136 filter unnecessary traffic between irrelevant sites (i.e., from a 137 receiver PE to another receiver PE) because VPLS provides multipoint- 138 to-multipoint connectivity between CEs. Moreover, VPLS's MAC-based 139 learning/forwarding operation is unnecessary for some scenarios 140 particularly if customers only need simple unidirectional point-to- 141 multipoint service, or if they require non- Ethernet Layer 2 142 connectivity. 144 Consequently, there is a real need for a solution that natively 145 provides point-to-multipoint service in L2VPN. 147 1.2. Scope of This Document 149 VPMS is defined as a Layer 2 service that provides point-to- 150 multipoint connectivity for a variety of Layer2 link layers across an 151 IP or MPLS-enabled PSN. VPMS is categorized as a class of provider- 152 provisioned Layer 2 Virtual Private Networks (L2VPN). 154 This document introduces a new service framework, reference model and 155 functional requirements for VPMS by extending the existing framework 156 [RFC4664] and requirements [RFC4665] for L2VPNs. 158 The technical specifications are outside the scope of this document. 159 There is no intent to specify solution-specific details. 161 This document provides requirements from both the Service Provider's 162 and the Customer's point of view. 164 2. Conventions used in this document 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [RFC2119] . 170 3. Terminology 172 The content of this document makes use of the terminology defined in 173 [RFC4026]. For readability purposes, we list some of the terms here 174 in addition to some specific terms used in this document. 176 3.1. Acronyms 178 P2P: Point-to-Point 180 P2MP: Point-to-Multipoint 182 PW: Pseudowire 184 VPMS: Virtual Private Multicast Service 186 PE/CE: Provider/Customer Edge 188 P: Provider Router 190 AC: Attachment Circuit 192 PSN: Packet Switched Network 194 SP: Service Provider 196 VPMS instance: A service entity manageable in a VPMS that provides 197 isolated service reachability domain to each CE. It corresponds 198 to a so-called "VPN" as a specific set of sites that allows 199 communication. 201 P2MP connection: A logical entity between PE/ACs in a given VPMS 202 instance that transfers unidirectional traffic transparently from 203 one local ingress AC to one or more remote egress ACs. 205 4. Use Cases 207 4.1. Ethernet Use Case 209 4.1.1. Ethernet-based multicast stream 211 For multicast traffic delivery, there is a requirement to deliver a 212 unidirectional P2MP service in addition to the existing P2P service. 213 The demand is growing to provide private (P2MP native Ethernet) 214 services, for various applications such as IP- based delivery of TV 215 broadcasting, content delivery networks, etc. Moreover, many digital 216 audio/video devices (e.g., MPEG-TS, HD-SDI) that supports Ethernet 217 interfaces are becoming available, which will make Ethernet P2MP 218 service more common. Also there are some applications that naturally 219 suited to static transport of VPMS. For example, MPEG-TS/IP/ 220 Ethernet in DVB-H is typically static broadcast without any signaling 221 in the upstream direction. VPMS could be a possible solution to 222 provide these kinds of networking connectivity over PSNs. 224 Currently VPLS [RFC4761][RFC4762] is able to give P2MP-type 225 replication for Ethernet traffic. Native VPLS already supports this 226 capability via a full mesh of PWs, and an extension to optimize 227 replication is also proposed [I-D.ietf-l2vpn-vpls-mcast] as an 228 additional feature. However, VPLS by nature requires MAC-based 229 learning and forwarding, which might not be needed in some cases by 230 particular users. Generally, video distribution applications use 231 unidirectional P2MP traffic, but may not always require any added 232 complexity of MAC address management. In addition, VPLS is a service 233 that essentially provides any-to-any connectivity between all CEs in 234 a L2VPN as it emulates a LAN service. However, if only P2MP 235 connectivity is required, the traffic between leaves is not allowed. 236 It might require extra efforts to guarantee this behavior in VPLS. 237 And in some P2MP scenarios there no traffic from leafs to root. In 238 these cases, VPMS is a service that provides much simpler operation. 240 Note that VPMS provides single coverage of receiver membership; that 241 is, there is no distinct differentiation for multiple multicast 242 groups. All traffic from a particular Attachment Circuit (AC) will 243 be forwarded toward the same remote receivers, even if the 244 destination MAC address is changed. Basically in VPMS, destination 245 MAC addresses are not used for forwarding, which is significantly 246 different from VPLS. If MAC-based forwarding is preferred (i.e., 247 multicast/unicast differentiation of MAC address), VPLS should be 248 chosen rather than VPMS. 250 4.1.2. Ethernet-based time/frequency synchronization 252 Nowadays there exist several solutions to provide synchronization for 253 time and/or frequency reference by the packet-based technology of 254 Ethernet. For example, PTPv2 (Precision Time Protocol version 2) is 255 a time-transfer protocol defined in the IEEEE1588-2008 standard. It 256 provides precise synchronization of packet-based networks (e.g., 257 Ethernet). It adopts two-way time transfer approach for 258 synchronization. Time transfer protocol may be operated in multicast 259 or unicast mode in both directions, and it is mapped over the 260 Ethernet/IP/UDP protocol stack. 262 Moreover, PTPv2 telecom profile is now discussed in ITU-T that 263 defines a set of capabilities and extensions required to support 264 telecommunication applications. It aims at providing frequency 265 distribution with higher level of accuracy. It allows unicast mode 266 or the mix of unicast/multicast modes for the transmission of the PTP 267 messages. 269 In this aspect, VPMS might be considered as a potential packet-based 270 infrastructure to deliver multicast messages in PTPv2 with efficient 271 forwarding. Note, however, in PTPv2 telecom profile, multicast 272 transport may not always be supported in all the parts of a telecom 273 network because multicast might sometimes generate additional PDV 274 (packet delay variation) compared to unicast. Therefore, VPMS use 275 case and the corresponding solution for this purpose will need more 276 study in the future (e.g., PDV issue to be checked). 278 4.2. ATM-based Use Case 280 4.2.1. ATM-based multicast stream 282 A use case of ATM-based service in VPMS could be to offer the 283 capability for service providers to support IP multicast wholesale 284 services over ATM in case the wholesale customer relies on ATM 285 infrastructure. The P2MP support alleviates the constraint in terms 286 of replication for ATM to support IP multicast services. 288 Another use case of VPMS for ATM is for audio/video stream 289 applications. Today many digital TV broadcasting networks adopt ATM- 290 based distribution systems with point-to-multipoint PVPs/PVCs. The 291 transport network supports replicating ATM cells in transit nodes to 292 efficiently deliver programs to multiple terminals. For migrating 293 such ATM-based networks onto IP/MPLS-based networks, VPMS is 294 considered to be a candidate solution. 296 4.3. TDM-based Use Case 298 4.3.1. TDM-based multicast stream 300 Today the existing VPWS already supports TDM emulation services 301 (SAToP, CESoPSN or TDMoIP). It is a Layer 1 service, not Layer 2 302 service; however, a common architecture is being used since they are 303 all packet-based emulations over a SP's network. VPMS is also 304 considered to be a solution for such TDM applications that require 305 point-to-multipoint topology. 307 One use case is TDM-based multicast stream delivery, like video 308 delivery. That is, data duplication is simply provided by Layer 1, 309 without using upper layer's multicast protocols. 311 5. Reference Model 313 The VPMS reference model is shown in Figure 1. 315 +-----+ AC1 AC2 +-----+ 316 | CE1 |>---+ ------------------------ +--->| CE2 | 317 +-----+ | | VPMS A's P2MP | | +-----+ 318 VPMS A | +------+ Connection +------+ | VPMS A 319 Sender +->|......>...+.......... >......|>-+ Receiver 320 | VPMS | . | VPMS | 321 | PE1 | . | PE2 | 322 +-<|......<.. . ....+.....<......|<-+ 323 | +------+ . . +------+ | 324 +-----+ | | . . | | +-----+ 325 | CE4 |<---+ |Routed . . VPMS B's P2MP +---<| CE3 | 326 +-----+ AC4 |Backbone. . Connection AC3 +-----+ 327 VPMS B | . . | VPMS B 328 Receiver | +-v-----v-+ | Sender 329 ------| . . |------- 330 | . VPMS. | 331 | . PE3 . | 332 +---------+ 333 v v VPMS A: 334 | | Root AC : AC1 335 AC5| |AC6 Leaf AC : AC2, AC5 336 v v VPMS B: 337 +-----+ +-----+ Root AC : AC3 338 | CE5 | | CE6 | Leaf AC : AC4, AC6 339 +-----+ +-----+ 340 VPMS A VPMS B 341 Receiver Receiver 343 Figure 1: Reference Model for VPMS 345 A VPMS instance is defined as a service entity manageable in the VPMS 346 architecture. A single VPMS instance provides an isolated service 347 reachability domain to each CE, so it corresponds to a so-called 348 "VPN" as it allows communication among a specific set of sites. A 349 single VPMS instance provides a unique point-to-multipoint L2VPN 350 service. In Figure 1, there are two VPMS instances shown, VPMS A and 351 VPMS B. In principle, there is no traffic exchange allowed between 352 these different instances, so they are treated as different VPNs. 354 In a VPMS, a single CE-PE link connection is used for transmitting 355 frames for delivery to multiple remote CEs, with point-to-multipoint 356 duplication. The SP's network (PE as well as P) has a role to 357 replicate frames so that the sender's CE does not need to send 358 multiple frames to individual receivers. 360 Like VPWS, an Attachment Circuit (AC) is provided to accommodate CEs 361 in a VPMS. In a VPMS, an AC attached to a VPMS MUST be configured as 362 "root" (sender) or "leaf" (receiver) not both. Any AC is associated 363 with the role of either sending side (Tx) or receiving side (Rx) from 364 the view of the CE. These will be named the root (sender) AC and 365 leaf (receiver) AC respectively. Unless reverse traffic is 366 optionally supported, a root AC does not transmit traffic back to a 367 CE at upstream side, likewise a leaf AC does not receive traffic from 368 a CE at downstream side. In Figure 1, AC1 and AC3 are configured as 369 root ACs while AC2, AC4, AC5 and AC6 are configured as leaf ACs. In 370 VPMS A, CE1 could send traffic via AC1, and CE2 and CE5 could receive 371 the traffic. 373 A CE which is locally connected to a root AC is called a root 374 (sender) CE. Also a CE which is locally connected to a leaf AC is 375 called a leaf (receiver) CE. However, such CEs's roles will not be 376 managed directly in VPMS because the configured AC's role (root or 377 leaf) will automatically determine them. 379 Similarly, a PE which locally accommodates a root AC is called a root 380 (sender) PE. A PE which locally accommodates a leaf AC is called a 381 leaf (receiver) PE. 383 Basically there is a one-to-one mapping between an attachment circuit 384 and a VPMS instance. For example, all traffic from CE1 to PE1 385 (through AC1) is mapped to VPMS A (to CE2 and CE5). 387 In a VPMS, P2MP tree-shaped reachability is given from a single root 388 AC to several leaf ACs. This will be named a "P2MP connection" in 389 this VPMS framework. P2MP connection is a logical entity between PE/ 390 ACs in a given VPMS instance that transfers unidirectional traffic 391 transparently from one local ingress AC to one or more remote egress 392 ACs. 394 Similar to other L2VPN mechanisms, the VPMS architecture is based on 395 PWs which may be using through IP or MPLS-enabled PSN tunnels over a 396 routed backbone. That is, every P2MP connection can be instantiated 397 by PW technology that supports P2MP traffic optimization (i.e., P2MP 398 PW. See section 7.2.). P2MP traffic optimization will provide the 399 benefit of traffic replication for high bandwidth efficiency. That 400 is, the sender CE has only to transmit one stream towards the PE and 401 it does not have to replicate traffic. 403 Regarding end-to-end traffic topology between the ACs, a single VPMS 404 instance (i.e., one VPN) may correspond to a single P2MP connection. 405 In Figure 1, VPMS A (one instance) has one P2MP connection (from AC1 406 to AC2 and AC5). However, there is also a case that a single VPMS 407 consists of two or more P2MP connections grouped, which is typically 408 used for redundancy. The details are given in section 6.4. 410 VPMS can support various Layer 2 protocol services such as Ethernet, 411 ATM, etc. 413 6. Customer Requirements 415 6.1. Service Topology 417 6.1.1. Point-to-Multipoint Traffic Support 419 A solution MUST support unidirectional point-to-multipoint traffic 420 from a sender CE to multiple receiver CEs. A root CE can send 421 traffic to one or more leaf CEs. Leaf CEs include not only the CEs 422 which are located at remote sites, but also the local CEs which are 423 connected to the same root PE. If there is only one receiver in the 424 instance, it is considered equivalent to unidirectional point-to- 425 point traffic. 427 6.1.2. Reverse Traffic Support 429 There are cases where a reverse traffic flow is needed. A root CE 430 may need to receive traffic from leaf CEs. There are some usage 431 scenarios for this, such as stream monitoring through a loopback 432 mechanism, control channels which need feedback communication etc. A 433 possible way to accomplish this is to provide different VPMS 434 instances for reverse traffic, i.e. a root CE is a receiver of 435 another VPMS instance. However, provisioning different VPNs for a 436 particular customer would make its management task more complex. It 437 is desired to have an alternative solution for supporting reverse 438 traffic flow. This section provides additional requirements for this 439 optional capability. 441 A VPMS solution MAY support reverse traffic from a leaf AC to a root 442 AC. Each reverse path is basically given in a P2P (unicast) manner. 443 In other words, each leaf of the P2MP tree can individually send back 444 traffic to the root. For this purpose a VPMS instance MAY have more 445 than one reverse P2P connections as network entity; However, such 446 network entities MUST have a common indetifier that enables 447 themselves to be managed together in the same VPN. Thus any PWs used 448 for such connections are expected to be assigned a common VPMS 449 instance ID (i.e., VPN ID). 451 Note, a VPMS does not assume any-to-any multipoint reachability. 452 Therefore, in principle, every leaf AC does not exchange traffic 453 directly with other leaf ACs even if reverse traffic is supported. 455 Figure 3 illustrates this kind of scenario, where CE1 is configured 456 as a sender in VPMS A. AC1 is a root AC, and AC2/AC3/AC4 are leaf 457 ACs. P2MP connection is given for forward traffic. Unidirectional 458 P2P connection is also provided for reverse traffic from AC4 to AC1. 459 Other reverse P2P connections can be provided similarly. (from AC2 to 460 AC1 / from AC3 to AC1). 462 In this case, PEs need to deal with two types of traffic, locally- 463 attached CE's sending (Tx) and receiving (Rx) flows. In Figure 3, 464 they are both passing through the same physical PE-CE link (AC1 and 465 AC4 respectively). But it is an implementation matter if Tx and Rx 466 traffic are conveyed on the same physical link or separate links. It 467 is also possible that a root PE multiplexes two ore more reverse 468 traffic from different leaves and transmits it to an upstream CE over 469 the same local physical link. 471 Note, in most implementations of VPWS today, every AC is always 472 considered bidirectional. In contrast, in VPMS, every AC can be 473 chosen unidirectional (if it is a totally unidirectional service), or 474 bidirectional (if reverse traffic is supported). 476 +-----+ <-- Rx (bidirectional) 477 | CE1 |--------------+ 478 +-----+ --> Tx | 479 VPMS A Sender | 480 AC1 | 481 +----------+ VPMS 482 | . . | PE1 483 | . .... | 484 -------| . . |-------- 485 | P2MP +-v------^-+ | 486 Connection . . | 487 (forward) + . | 488 | . . | 489 +------+ . . . . +------+ 490 +-<|......<.. . .. . ......>..... |>-+ 491 | | VPMS | . . | VPMS | | 492 AC2| | PE2 | . . | PE3 | |AC3 493 | +------+ . . +------+ | 494 +-----+ | | . . P2P | | +-----+ 495 | CE2 |<--+ | Routed . . Connection +-->| CE3 | 496 +-----+ <-- | Backbone. . (reverse)| --> +-----+ 497 VPMS A Rx | +-v------^-+ | Rx VPMS A 498 Receiver -------| . . |-------- Receiver 499 | . .... | 500 | . . | VPMS 501 +----------+ PE4 502 AC4| 503 | 504 | <-- Tx +-----+ 505 +--------------------| CE4 | 506 (bidirectional) --> Rx +-----+ 507 VPMS A 508 Receiver 510 Figure 3: Reverse traffic support 512 6.2. Transparency 514 A solution is intended to provide Layer-2 traffic transparency. 515 Transparency SHOULD be supported per VPMS instance basis. In other 516 words, Layer-2 traffic can be transparently transported from a local 517 CE to remote CEs in a given instance. Note, however, if service 518 delimiting fields (VLAN Id in Ethernet, VPI/VCI in ATM, DLCI in FR 519 etc.) are assigned by the SP, the Layer-2 traffic is not necessarily 520 transparent. It will depend on the SP's choice if they assign it to 521 each AC. Hence, it could be that some of the leaf CEs are receiving 522 traffic that has different delimiting fields than the traffic for the 523 other leaf CEs. Hence, it could be that some of receiver CEs are 524 getting traffic with different delimiting fields than the other 525 receiver CEs. 527 The VPMS solution SHOULD NOT require any special packet processing by 528 the end users (CEs). 530 6.3. Quality of Service (QoS) 532 A customer may require that the VPMS service provide guaranteed QoS. 533 In particular, for real time applications which are considered common 534 in point-to-multipoint delivery, delay and loss sensitive traffic 535 MUST be supported. The solution SHOULD provide native QoS techniques 536 for service class differentiation, such as IEEE 802.1p CoS for 537 Ethernet. 539 For bandwidth committed services (e.g., ATM CBR), a solution SHOULD 540 guarantee end-to-end bandwidth. It MAY provide flow admission 541 control mechanisms to achieve that. 543 6.4. High Availability 545 A solution MUST provide protection and restoration mechanism for end- 546 to-end services to ensure high availability. 548 There are multiple parts of the connection that can support 549 protection and restoration: (1) CE to PE, (2) between PEs (3) inside 550 core (PSN backbone). It is expected that (3) is fulfilled by 551 existing PSN protection mechanisms (e.g., RSVP-TE FRR). Following 552 subsections covers the requirements for redundancy support for (1) 553 and (2). 555 6.4.1. Dual-homed Access Support 557 A solution MUST allow dual-homed redundant access from a CE to 558 multiple PEs. This if beneficial to support reliable data delivery 559 for customers. Figure 3 provides an example of this access topology. 561 +-----+ 562 | CE1 |--------------+ 563 +-----+ \ 564 VPMS A | | 565 Sender | v AC1 566 (dual-homed)| +----+ 567 | -----|VPMS|-------- 568 | | | PE1| | 569 \ | +----+ | 570 \ AC2 +----+ +----+ AC4 571 +------>|VPMS| |VPMS|------------+ 572 | PE2| Routed | PE3| \ 573 +----+ Backbone +----+\ | 574 AC3 / | | \ AC5 v 575 +-----+ / | | \ +-----+ 576 | CE2 |<-+ | | \ | CE3 | 577 +-----+ | +----+ | \ +-----+ 578 VPMS A ----|VPMS|--------- \ VPMS A 579 Receiver | PE4| | Receiver 580 +----+ | 581 | AC6 v 582 \ +-----+ 583 +--------------->| CE4 | 584 +-----+ 585 VPMS A 586 Receiver 587 (dual-homed) 589 Figure 3: Dual-homing support 591 A solution SHOULD provide a protection mechanism between the 592 redundant PEs to which a CE is dual-homed. This is because when an 593 ingress root PE node fails whole traffic delivery will fail unless a 594 backup root PE is provided, even in case of dual-homed access. 595 Similarly, if an egress leaf PE node fails, traffic toward that CE is 596 never received unless a backup leaf PE is provided. 598 In some cases, the data source is required to be highly reliable 599 since it is often deployed as a centralized server that provides 600 traffic to many receivers. Therefore, there is an additional 601 requirement specifically about redundancy of root-side: each VPMS 602 instance SHOULD be able to have multiple P2MP connections whose roots 603 are located at separate root ACs. Those root ACs can be located at 604 physically separate root PEs, whereas those trees will share common 605 leaf ACs. This means that each P2MP connection has a single root AC, 606 but several P2MP connections can be managed together inside a common 607 VPN. 609 For example, in Figure 4, traffic from root AC1 and AC2 both reach 610 receivers CE3 and CE4 while AC1, AC2, AC3 and AC4 all are associated 611 with a single VPMS instance. This topology is reliable since there 612 are redundant root PE/ACs. At the egress side, PE3 and PE4 select 613 traffic from either root, PE1 or PE2. In this figure, each leaf PE 614 has one leaf AC only (AC3 attached to PE3, and AC4 attached to PE4). 615 Therefore, PEs will need to support PW protection and restoration 616 mechanism so that two redundant P2MP connections are given among 617 common ACs. 619 +-----+ AC2 620 | CE1 |>--------------------------------------------+ 621 +-----+ | 622 AC1v VPMS A | 623 | Sender ----------------------------- | 624 | | VPMS A's P2MP | | 625 | +------+ Connection-2 +------+ | 626 +------->|......>.. .............+..<......|<-+ 627 Tx | VPMS | . . . | VPMS | Tx 628 | PE 1 | . . . | PE 2 | 629 | | . . . | | 630 +------+ . . . +------+ 631 | . . . | 632 VPMS A's P2MP +.. . ...... . | 633 Connection-1 . . . . | 634 | . . . . | 635 | +-v----v-+ +-v----v-+ | 636 ---| . . |---| . . |--- 637 VPMS| . . | | . . |VPMS 638 PE 3| . | | . |PE 4 639 +--------+ +--------+ 640 v v 641 AC3| |AC4 642 v v 643 +-----+ +-----+ 644 | CE3 | | CE4 | 645 +-----+ +-----+ 646 VPMS A VPMS A 647 Receiver Receiver 649 Figure 4: Multiple P2MP connections in Dual-homed Sender 651 Note, if the solution supports dual-homed sender scenario to provide 652 multiple root ACs like, it is expected that such a mechanism can also 653 be used in multi-source scenrio. For example, suppose in TV 654 provisioning scenario, a leaf (receiver) CE has the fixed one 655 interface to the leaf PE, and the CE needs to receive many TV channel 656 traffic from two video servers (the two servers provide different TV 657 channels). The two video servers are in different location. In this 658 case, there need two root ACs and the same number of P2MP 659 connections, which is similar to dual-homed sender case. If the root 660 CE shown in Figure 4 is given physically separated, such a topology 661 is equivalent to this multi-source scenario. 663 6.4.2. Single/Dual Traffic Support in Dual-homed Access 665 When dual-homed access to root PEs is provided, a solution MAY allow 666 a sender CE to transmit just a single copy of the traffic to either 667 one of the two root (ingress) PEs or to transmit a copy of the 668 traffic to both the PEs simultaneously. The latter scenario consumes 669 more resource of CE-PE link than the single traffic scenario, but it 670 is usually applicable when a source device has only a simple 671 forwarding capability without any switchover functionality. In the 672 dual traffic case, the backup root (ingress) PE SHOULD be able to 673 filter the incoming unnecessary traffic while the other root PE is 674 active if it is needed by SP. In either case, single traffic or dual 675 traffic, the switchover mechanism between root (ingress) PEs will be 676 necessary to handle traffic appropriately in case of failure. 678 In the case of dual-homed access to leaf PEs, a solution MAY allow a 679 receiver CE to receive a single copy of the traffic from either one 680 of the two leaf (egress) PEs, or receive a copy of the traffic from 681 both PEs simultaneously. The dual traffic approach is applicable if 682 CE has fast switchover capability as a receiver by selecting either 683 one of incoming traffic, but note that additional traffic resources 684 are always consumed at PE-CE link of backup side. Specifically in 685 the single traffic case, it might be needed to support switchover 686 mechanism between egress PEs in case of failure. 688 6.5. Security 690 The basic security requirements from the view of customers are raised 691 in section 6.5 of [RFC4665]. It also applies to VPMS. 693 In addition, a VPMS solution MAY have the mechanisms to activate the 694 appropriate filtering capabilities (for example, MAC/VLAN filtering 695 etc.), and it MAY be added with the control mechanism between 696 particular sender/receiver sites inside a VPMS instance. For 697 example, in Figure 1, filtering can be added such that traffic from 698 CE1 to CE4/CE5 is allowed but traffic from CE1 to CE6 is filtered. 700 6.6. Reordering Prevention 702 A solution SHOULD prevent Layer-2 frame reordering when delivering 703 customer traffic under normal conditions. 705 6.7. Failure reporting 707 A solution MAY provide information to the customer about failures. 708 For example, if there is a loss of connectivity toward some of the 709 receiver CEs, it is reported to the sender CE. 711 7. Service Provider Network Requirements 713 7.1. Scalability 715 A VPMS solution MUST be designed to scale well with an increase in 716 the number of any of the following metrics: 718 - the number of PEs (per VPMS instance and total in a SP network) 719 - the number of VPMS instances (per PE and total) 720 - the number of root ACs / sender CEs (per PE, VPMS instance and 721 total) 722 - the number of leaf ACs / receiver CEs (per PE, VPMS instance and 723 total) 725 A VPMS solution SHALL document its scalability characteristics in 726 quantitative terms. A solution SHOULD quantify the amount of state 727 that a PE and a P device has to support. 729 The scalability characteristics SHOULD include: 731 - the processing resources required by the control plane in managing 732 PWs (neighborhood or session maintenance messages, keepalives, 733 timers, etc.) 734 - the processing resources required by the control plane in managing 735 PSN tunnels 736 - the memory resources needed for the control plane 737 - other particular elements inherent to each solution that impact 738 scalability 740 7.2. Pseudo Wire Signaling and PSN Tunneling 742 A VPMS solution SHOULD provide an efficient replication that can 743 contribute to optimizing the bandwidth usage required in a SP's 744 network. For supporting efficient replication, it is expected to 745 take advantage of PW and PSN mechanisms that are capable of P2MP 746 traffic. 748 Regarding PW mechanism, [I-D.ietf-pwe3-p2mp-pw-requirements] 749 introduces P2MP PW concept and its requirements, showing two basic 750 approaches of providing replication. One is SS (Single Segment)-PW 751 model that provides replication by PSN tunnel such as P2MP LSP (i.e., 752 by outer label layer), and the other is MS (Multi Segment)-PW model 753 that provides replication by multiple interconnected PWs (i.e., by 754 inner label layer). In either case, end-to-end P2MP topology (i.e., 755 P2MP connection) in VPMS is common from the view of ACs. 756 Requirements as a provider service specified in this document will be 757 commonly applied regardless of P2MP PW's signaling model. 759 It is out of scope of this document how to extend and use PW 760 mechanisms to realize P2MP connections. For example, it is under the 761 scope of the solution work how to support forward/reverse traffic 762 e.g., by a single PW signaling, coupling multiple PWs, or other ways. 764 This document does not raise any specific requirements for particular 765 PSN tunneling schemes (point-to-point, point-to-multipoint and 766 multipoint-to-multipoint) that are applied to VPMS. The actual type 767 of PSN tunnel used in VPMS will be dependent on individual deployment 768 scenarios (e.g., which PSN protocol is available in the core and how 769 much of the network resources that operators will want to optimize). 771 7.3. Auto-discovery 773 A solution SHOULD support auto-discovery methods that dynamically 774 allow VPMS related information to be discovered by the PEs to 775 minimize the amount of configuration the SP must perform. 777 All of the requirements on discovery described in Section 7.3 of 778 [RFC4665] SHOULD be satisfied in VPMS as well. 780 Auto-discovery will help operators' initial configuration of adding a 781 new VPN (i.e., VPMS instance), adding/deleting new sender/receiver, 782 and so on. 784 The candidate information treated in auto-discovery will be as 785 follows: 787 - Information to indentify the location of each PE, e.g., PE router 788 ID / IP address 789 - Information to identify the VPMS instance, that is, to identify a 790 VPN 791 - Information to identify the type of ACs (root AC or leaf AC) 792 - Information to identify the P2MP connection that binds ACs 793 - Information to show if reverse traffic support is optionally 794 desired 795 - SP-related information (AS number, etc. for an inter-provider 796 case) 798 Following is an example scenario about adding a new leaf PE: suppose 799 there are three PEs in an existing VPMS, PE1, PE2, PE3. PE1 is a 800 root PE and has a AC1. PE2 and PE3 are leaves and have AC2 and AC3. 801 every PE has the association among the information described above. 802 Now a new PE4 having an AC4 is provisioned in the existing VPMS 803 instance and this AC is configured as leaf. This information will be 804 automatically discovered by the other existing remote PEs (i.e., 805 ingress and egress PEs in the same VPMS instance). Once the ingress 806 PE1 discovers this new PE/AC, it can automatically add AC4 as the new 807 leaf of P2MP connection topology according to P2MP PW signaling 808 mechanism. The ingress PE1 will graft a new leaf (PE4) to the 809 already existing P2MP connection which is now created from AC1 to 810 AC2/AC3/AC4. This operation does not require any new configuration 811 at the existing PEs. 813 Another example is about adding new root PE: suppose there are one 814 root PE (PE1/AC1) and three leaf PEs (PE2/AC2, PE3/AC3 and PE4/AC4). 815 There is an existing P2MP connection from AC1 to AC2/AC3/AC4. Now 816 the operator adds a new root PE/AC (PE5/AC5) for some reasons (e.g., 817 multiple source sites, dual-homed access, root PE redundancy etc.). 818 Then, auto-discovery mechanism advertises this information to all 819 other members PE1/PE2/PE3/PE4, and a new P2MP connection from AC5 to 820 AC2/AC3/AC4 is created by PW signaling. 822 Note that VPMS instance is created when one root PE and at least one 823 leaf PE are added. In principle VPMS requires such minimum 824 provisioning. Hence in dual-homing case of sender, only backup root 825 PE can be dynamically added/deleted to/from VPMS without destroying 826 the VPN. 828 7.4. Activation and Deactivation 830 A solution SHOULD provide a way to activate/deactivate the 831 administrative status of each AC. After initial provisioning, a SP 832 might change connectivity configuration between particular CEs inside 833 a single VPMS instance for operational reasons. This feature will be 834 beneficial to help such a scenario. 836 For example, in Figure 5, AC1, AC3, AC4 and AC5 are initially 837 provisioned for VPMS A. AC2 is not provisioned for any VPMSes. In 838 VPMS A, CE1 is a sender and CE3, CE4 and CE5 are receivers. Traffic 839 will usually flow from CE1 to all receivers, CE3, CE4 and CE5. 841 However, for maintenance operation, application's request (e.g., 842 stream program has changed) or some other reasons, AC4 needs to be 843 set as administratively deactivated. Then it becomes necessary to 844 turn off traffic from PE4 to CE4. This operation must be 845 appropriately distinguished from failure cases. 847 When deactivating a particular site, backbone PSN/PW resources (e.g., 848 admission control of PSN tunnel) MAY be released for that particular 849 direction in order to provide that bandwidth to other services. In 850 Figure 5, AC3 is now administratively activated and receiving 851 traffic. However, if AC3 comes to be administratively deactivated, 852 and if RSVP-TE (including P2P and/or P2MP) is used for backbone PSN, 853 then TE reserved resources from PE1 to PE3 may be released. 855 In addition, a solution SHOULD allow single-sided activation 856 operation at a root (ingress) PE. In some scenarios, operators 857 prefer centralized operation. This is often considered natural for 858 one-way digital audio/video distribution applications: SPs often want 859 to complete their service delivery by a single operation at one 860 source PE, not by multiple operations at many leaf (egress) PEs. 861 Figure 5 illustrates this scenario, where a SP only has to do single- 862 sided operation at PE1 (source) to administratively activate/ 863 deactivate various connections from AC1 to AC3, AC4 and/or AC5. It 864 is not needed to perform operations on PE3 and PE4 directly. 866 +-----+ AC1 867 + CE1 +----------------+ 868 +-----+ | 869 VPMS A Sender | 870 (sending now) v 871 +----+ 872 -----|VPMS|-------- 873 | | PE1| | 874 | +----+ | 875 +----+ +----+ 876 |VPMS| |VPMS| 877 | PE2| Routed | PE3| 878 AC2 +----+ Backbone +----+ AC3 879 (not provisioned) / | | \ 880 +-----+ / | | \ +-----+ 881 + CE2 +<-+ | | +->| CE3 | 882 +-----+ | +----+ | +-----+ 883 (not receiving) ----|VPMS|--------- VPMS A Receiver 884 | PE4| (receiving now) 885 +----+ 886 AC5 / \ AC4 887 +-----+ / \ +-----+ 888 + CE5 +<----------+ +---------------->| CE4 | 889 +-----+ +-----+ 890 VPMS A Receiver VPMS A Receiver 891 (receiving now) (not receiving) 893 AC1: Administratively activated 894 AC2: No VPMS provisioned 895 AC3: Administratively activated 896 AC4: Administratively deactivated 897 AC5: Administratively activated 899 Figure 5: Site activation and deactivation 901 7.5. Inter-AS Support 903 A solution SHOULD support inter-AS scenarios, where there is more 904 than one provider providing a common VPMS instance and VPN. More 905 specifically, it is necessary to consider the case where some of the 906 PEs that compose one VPMS belong to several different ASes. 908 7.6. Co-existence with Existing L2VPNs 910 A solution MUST co-exist with the existing L2VPNs (e.g., VPWS, VPLS) 911 across the same SP's network. A solution MUST NOT impede the 912 operation of auto-discovery and signaling mechanism that are already 913 supported by the PEs for those existing L2VPNs. 915 7.7. Operation, Administration and Maintenance 917 7.7.1. Fault Management 919 7.7.1.1. Fault Detection 921 A solution MUST provide tools that detect reachability failure and 922 traffic looping of data transport in a VPMS instance. If multiple 923 root ACs are supported (i.e., multiple P2MP connections are grouped 924 together into a single VPMS instance), such tools MUST be able to 925 perform distinguishing each P2MP connection. 927 7.7.1.2. Fault Notification 929 A solution MUST provide fault notification and trouble tracking 930 mechanisms. (e.g. SNMP-trap and syslog that notify fault to remote 931 NMS.) 933 In VPMS one point of failure at upstream often affects a number of 934 downstream PEs and ACs that might raise a notification message. 935 Hence notification messages MAY be summarized or compressed for 936 operators' ease of management. 938 In case of receiver-side failure (leaf PE or its AC), this fault 939 status SHOULD be able to be monitored at root PE. This will help an 940 operator to monitor each leaf PE/AC in a centralized manner; that is, 941 a root PE can collect leaf-side information. How this status is 942 transferred depends on a solution. 944 In contrast, in case of sender-side failure (root PE or its AC), this 945 fault status SHOULD also be able to be monitored at leaf PEs. This 946 will help an operator to troubleshoot at leaf PEs (i.e., distinguish 947 local AC's failure from remote root AC's failure easily). 949 In any case of failure at SP's network, fault information MAY be 950 notified to the customer. Specifically, such fault MAY trigger 951 generating customer OAM message toward CEs (e.g., AIS) and/or 952 shutting down leaf ACs. 954 7.7.1.3. Fault Isolation 956 A solution MUST provide diagnostic/troubleshooting tools for data 957 transport in a VPMS instance. 959 7.7.2. Testing 961 A solution MUST provide a mechanism for testing each data 962 connectivity and verifying the associated information in a VPMS 963 instance. The connectivity is between a root and all leaf ACs (i.e., 964 each P2MP connection can be tested). 966 Operators will run testing before and after service activation. 967 Testing mechanism SHOULD support end-to-end testing of the data path 968 used by customer's data. End-to-end testing will have CE-to-CE path 969 test and PE-to-PE path test. A solution MUST support PE-to-PE path 970 test and MAY support CE-to-CE path test. In either case the minimum 971 data path unit for each VPMS is unidirectional, hence if loopback 972 testing is supported, additional consideration about reverse-path 973 might also be needed (see section 6.1.2). 975 If there are multiple P2MP connections for redundancy (active/backup 976 tree) in a common VPMS (like in Figure 4), testing mechanism MUST be 977 able to check the connectivity over not only working P2MP connection 978 but also protecting connection(s). This testing MUST be able to be 979 performed from a root PE. It MAY also be able to be performed from a 980 sender CE. 982 7.7.3. Performance Management 984 A solution MUST offer mechanisms to monitor traffic performance 985 parameters and statistics of data traffic in VPMS. 987 A solution MUST provide access to: 989 - Traffic statistics (total traffic forwarded, incoming, outgoing, 990 dropped, etc., by period of time) 992 A solution SHOULD provide access to: 994 - Performance information related to traffic usage, e.g., one-way 995 delay, one-way jitter, one-way loss, delay variations (the 996 difference of various one-way delay from a particular root PE to 997 multiple leaf PEs) etc. 999 All or part of this information SHOULD be made available through 1000 standardized SNMP MIB Modules (Management Information Base). 1002 It is expected that such information can be used for SLA monitoring 1003 between sender and receiver, to give the SP a clear picture of 1004 current service providing to the customer. 1006 7.8. Security 1008 Section 7.6. of [RFC4665] describes common Layer-2 VPN security 1009 requirements from service provider aspect, which also applies to 1010 VPMS. (For example, an SP network MUST be protected against 1011 malformed or maliciously constructed customer traffic, etc.) 1013 This subsection adds VPMS-specific consideration and requirements. 1015 In VPMS, all traffic is transported with multicast duplication in 1016 terms of end-to-end perspective, regardless of customer's individual 1017 protocol. A PE never processes CE's multicast control protocol 1018 (e.g., PIM, IGMP, MLD as Layer-3). Hence, in PE and P, basically the 1019 security threat from malicious customer's C-plane protocol is small. 1021 In VPMS, there is security threat from malicious customers' D-plane 1022 traffic. A PE might receive a high volume of data from a CE. If 1023 there is no safeguard on PE, it will cause excessive replication in 1024 the SP network. Therefore, a VPMS solution SHOULD support traffic 1025 policing to limit the unwanted data traffic. Such a policing 1026 mechanism MUST be configurable per VPN basis, not the total of 1027 various VPNs to isolate malicious customer's traffic from others. 1029 8. Security Considerations 1031 The security requirements common to customers and service providers 1032 are raised in Section 5.5. of [RFC4665], which are fundamental for 1033 all Layer-2 VPN services. VPMS is a variant of Layer-2 VPN, and that 1034 statement also applies to VPMS. 1036 Moreover, in this document, security requirements from the view of 1037 customers are shown in Section 6.5. Security requirements from the 1038 view of providers are shown in Section 7.8. They explain security 1039 considerations that are specific to VPMS. 1041 9. IANA Considerations 1043 This document has no actions for IANA. 1045 10. Acknowledgments 1047 Many thanks to Ichiro Fukuda, Kazuhiro Fujihara, Ukyo Yamaguchi and 1048 Kensuke Shindome for their ideas and feedback in documentation. 1050 The authors gratefully acknowledge the valuable review and comments 1051 provided by Greg Mirsky and Yuji Tochio. 1053 11. References 1054 11.1. Normative References 1056 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1057 Requirement Levels", BCP 14, RFC 2119, March 1997. 1059 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 1060 Private Network (VPN) Terminology", RFC 4026, March 2005. 1062 11.2. Informative References 1064 [I-D.ietf-l2vpn-vpls-mcast] 1065 Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter, 1066 "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-05 (work 1067 in progress), July 2009. 1069 [I-D.ietf-pwe3-p2mp-pw-requirements] 1070 JOUNAY, F., Niger, P., Kamite, Y., DeLord, S., and L. 1071 Martini, "Requirements for Point-to-Multipoint 1072 Pseudowire", draft-ietf-pwe3-p2mp-pw-requirements-00 (work 1073 in progress), September 2008. 1075 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 1076 Private Networks (L2VPNs)", RFC 4664, September 2006. 1078 [RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for 1079 Layer 2 Provider-Provisioned Virtual Private Networks", 1080 RFC 4665, September 2006. 1082 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 1083 (VPLS) Using BGP for Auto-Discovery and Signaling", 1084 RFC 4761, January 2007. 1086 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 1087 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 1088 RFC 4762, January 2007. 1090 Authors' Addresses 1092 Yuji Kamite 1093 NTT Communications Corporation 1094 Granpark Tower 1095 3-4-1 Shibaura, Minato-ku 1096 Tokyo 108-8118 1097 Japan 1099 Email: y.kamite@ntt.com 1100 Frederic Jounay 1101 France Telecom 1102 2, avenue Pierre-Marzin 1103 22307 Lannion Cedex 1104 France 1106 Email: frederic.jounay@orange-ftgroup.com 1108 Ben Niven-Jenkins 1109 BT 1110 208 Callisto House, Adastral Park 1111 Ipswich, IP5 3RE 1112 UK 1114 Email: benjamin.niven-jenkins@bt.com 1116 Deborah Brungard 1117 AT&T 1118 Rm. D1-3C22, 200 S. Laurel Ave. 1119 Middletown, NJ, 07748 1120 USA 1122 Email: dbrungard@att.com 1124 Lizhong Jin 1125 Nokia Siemens Networks 1126 Building 89, 1122 North QinZhou Road, 1127 Shanghai, 200211 1128 P.R.China 1130 Email: lizhong.jin@nsn.com