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