idnits 2.17.1 draft-ietf-l2vpn-l2-framework-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 14 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2003) is 7498 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PWE3- ARCH' is mentioned on line 470, but not defined == Unused Reference: 'PWE3-ARCH' is defined on line 1775, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-requirements-00 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-arch-06 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Loa Andersson 2 Internet Draft 3 Expiration Date: April 2004 Eric C. Rosen 4 Cisco Systems, Inc. 6 Editors 8 October 2003 10 L2VPN Framework 12 draft-ietf-l2vpn-l2-framework-03.txt 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document provides a framework for Layer 2 Provider Provisioned 37 Virtual Private Networks (L2VPNs). This framework is intended to aid 38 in standardizing protocols and mechanisms to support interoperable 39 L2VPNs. 41 Table of Contents 43 1 Introduction ....................................... 3 44 1.1 Conventions used in this document .................. 3 45 1.2 Objectives and Scope of the Document ............... 3 46 1.3 Layer 2 Virtual Private Networks ................... 4 47 1.4 Terminology ........................................ 4 48 2 Models ............................................. 4 49 2.1 Reference Model for VPWS ........................... 4 50 2.1.1 Entities in the VPWS reference model ............... 5 51 2.2 Reference Model for VPLS ........................... 5 52 2.2.1 Entities in the VPLS reference model ............... 8 53 2.3 Reference Model for Distributed VPLS-PE or VPWS-PE . 9 54 2.3.1 Entities in the Distributed PE Reference Models .... 9 55 2.4 VPWS-PE and VPLS-PE ................................ 9 56 3 Functional Components of L2 VPN .................... 9 57 3.1 Types of L2VPN ..................................... 10 58 3.1.1 Virtual Private Wire Service (VPWS) ................ 10 59 3.1.2 Virtual Private LAN Service (VPLS) ................. 10 60 3.1.3 IP-only LAN-like Service (IPLS) .................... 11 61 3.2 Generic L2VPN Transport Functional Components ...... 11 62 3.2.1 Attachment Circuits ................................ 12 63 3.2.2 Pseudowires ........................................ 12 64 3.2.3 Forwarders ......................................... 13 65 3.2.4 Tunnels ............................................ 15 66 3.2.5 Encapsulation ...................................... 15 67 3.2.6 Pseudowire Signaling ............................... 16 68 3.2.6.1 Point-to-Point Signaling ........................... 17 69 3.2.6.2 Point-to-Multipoint Signaling ...................... 18 70 3.2.6.3 Inter-AS Considerations ............................ 19 71 3.2.7 Service Quality .................................... 19 72 3.2.7.1 Quality of Service (QoS) ........................... 20 73 3.2.7.2 Resiliency ......................................... 21 74 3.2.8 Management ......................................... 22 75 3.3 VPWS ............................................... 22 76 3.3.1 Provisioning and Auto-Discovery .................... 22 77 3.3.1.1 Attachment Circuit Provisioning .................... 23 78 3.3.1.2 PW Provisioning for Arbitrary Overlay Topologies ... 23 79 3.3.1.3 Colored Pools PW Provisioning Model ................ 25 80 3.3.2 Requirements on Auto-Discovery Procedures .......... 27 81 3.3.3 Heterogeneous Pseudowires .......................... 28 82 3.4 VPLS Emulated LANs ................................. 28 83 3.4.1 VPLS Overlay Topologies and Forwarding ............. 30 84 3.4.2 Provisioning and Auto-Discovery .................... 32 85 3.4.3 Distributed PE ..................................... 33 86 3.4.4 Scaling issues in VPLS deployment .................. 36 87 3.5 IP-only LAN-like Service (IPLS) .................... 36 88 4 Security Considerations ............................ 37 89 4.1 Provider Network Security Issues ................... 37 90 4.2 Provider-Customer Network Security Issues .......... 38 91 4.3 Customer Network Security Issues ................... 39 92 5 Intellectual Property Notice ....................... 39 93 6 Copyright Notice ................................... 40 94 7 Normative References ............................... 40 95 8 Informative References ............................. 41 96 9 Authors and Acknowledgments ........................ 41 97 10 Authors' Contact Information ....................... 41 99 1. Introduction 101 1.1. Conventions used in this document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC-2119 [RFC2119]. 107 1.2. Objectives and Scope of the Document 109 This document provides a framework for Layer 2 Provider Provisioned 110 Virtual Private Networks (L2VPNs). This framework is intended to aid 111 in standardizing protocols and mechanisms to support interoperable 112 L2VPNs. 114 The term "provider provisioned VPNs" refers to Virtual Private 115 Networks (VPNs) for which the Service Provider (SP) participates in 116 management and provisioning of the VPN. 118 Requirements for L2VPNs can be found in [L2VPN-REQ]. 120 This document provides reference models for L2VPNs, and discusses the 121 functional components of L2VPNs. Specifically, this includes 122 discussion of the technical issues which are important in the design 123 of standards and mechanisms for L2VPNs, including those standards and 124 mechanisms needed for interworking and security. 126 This document discusses a number of different technical approaches to 127 L2VPNs. It tries to show how the different approaches are related, 128 and to clarify the issues that may lead one to select one approach 129 rather than another. However, this document does not attempt to 130 select any particular approach. 132 1.3. Layer 2 Virtual Private Networks 134 There are two fundamentally different kinds of Layer 2 VPN service 135 that a service provider could offer to a customer: Virtual Private 136 Wire Service (VPWS) and Virtual Private LAN Service (VPLS). There is 137 also the possibility of an IP-only LAN-like Service (IPLS). 139 A VPWS is a VPN service that supplies a L2 point-to-point service. 140 Being a point-to-point service, there are very few scaling issues 141 with the service as such. Scaling issues might arise from the number 142 of end-points that can be supported on a particular PE. 144 A VPLS is an L2 service that in all emulates LAN service across a 145 Wide Area Network (WAN). Thus it also has all the scaling 146 characteristics of a LAN. Other scaling issues might arise from the 147 number of end-points that can be supported on a particular PE. 149 1.4. Terminology 151 The list of the technical terms used when discussing L2VPNs may be 152 found in the companion document [VPN-TERM]. 154 2. Models 156 2.1. Reference Model for VPWS 158 The VPWS reference model is shown in Figure 1. 160 Attachment PSN Attachment 161 Circuits tunnel Circuits 162 + 163 +-----+ pseudo +-----+ 164 | | wire | | 165 | CE1 |--+ +--| CE2 | 166 | | | +-----+ +-----+ +-----+ | | | 167 +-----+ +----|---- | | P | | ----+----+ +-----+ 168 |VPWS\|---|-----|-----|/VPWS| 169 | PE1 |===|=====|=====| PE2 | 170 | /|---|-----|-----|\ | 171 +-----+ +----|---- | | | | ----|----+ +-----+ 172 | | | +-----+ +-----+ +-----+ | | | 173 | CE3 |--+ +--| CE4 | 174 | | | | 175 +-----+ +-----+ 177 Figure 1 179 2.1.1. Entities in the VPWS reference model 181 The P, PE (VPWS-PE) and CE devices and the PSN tunnel as defined in 182 [VPN-TERM]. Attachment circuit and pseudo wire as discussed in 183 section 3. The PE does a simple mapping between the PW and attachment 184 circuit based on local information, i.e. the PW de-multiplexor and 185 incoming/outgoing logical/physical port. 187 2.2. Reference Model for VPLS 189 The following diagram shows a VPLS reference model where PE devices 190 that are VPLS-capable provide a logical interconnect such that CE 191 devices belonging to a specific VPLS appear to be on a single bridged 192 Ethernet. A VPLS can contain a single VLAN or multiple, tagged VLANs. 194 The VPLS reference model is shown in Figures 2 and 3. 196 +-----+ +-----+ 197 + CE1 +--+ +---| CE2 | 198 +-----+ | ................... | +-----+ 199 VPLS A | +----+ +----+ | VPLS A 200 | |VPLS| |VPLS| | 201 +--| PE |--Routed---| PE |-+ 202 +----+ Backbone +----+ 203 / . | . \ _ /\_ 204 +-----+ / . | . \ / \ / \ +-----+ 205 + CE +--+ . | . +--\ Access \----| CE | 206 +-----+ . +----+ . | Network | +-----+ 207 VPLS B .....|VPLS|........ \ / VPLS B 208 | PE | ^ ------- 209 +----+ | 210 | | 211 | | 212 +-----+ | 213 | CE3 | +-- Emulated LAN 214 +-----+ 215 VPLS A 217 Figure 2 218 |-----Routed Backbone------| 219 | (P Routers) |PSN Tunnels, 220 Emulated LAN | |Pseudowires 221 ......................................................................... 222 . | | . 223 . |----------------------|----| |---------|-----------------| . 224 . | --------------------|--- | | -------|---------------- | . 225 . | VPLS Forwarder | | VPLS Forwarder | . 226 . | ----------|------------- | | ----------|------------- | . 227 ..|...................................................................|.. 228 | | Emulated LAN | | | Emulated LAN | 229 | | Interface | VPLS-PEs | | Interface | 230 | | | <----> | | | 231 | ----------|------------ | | ----------|------------ | 232 | | Bridge | | | | Bridge | | 233 | -|--------|---------|-- | | ---|-------|---------|- | 234 |---|--------|---------|----| |-----|-------|---------|---| 235 | | | | | | 236 | | Access | | | Access | 237 | | Networks| | | Networks| 238 | | | | | | 239 | | | | | | 240 CE devices CE devices 241 Figure 3 243 From Figure 3, we see that in VPLS, a CE device attaches, possibly 244 through an access network, to a "bridge" module of a VPLS-PE. Within 245 the VPLS-PE, the bridge module attaches, through an "Emulated LAN 246 Interface" to an Emulated LAN. For each VPLS, there is an Emulated 247 LAN instance. Figure 3 shows some internal structure to the Emulated 248 LAN: it consists "VPLS Forwarder" modules (one per VPLS-PE per VPLS 249 instance) connected by Pseudowires, where the Pseudowires may be 250 traveling through PSN tunnels over a routed backbone. 252 The functionality which the bridge module must support depends on the 253 service which is being offered by the SP to its customers, as well as 254 on various details of the SP's network. At minimum, the bridge 255 module must be able to learn MAC addresses, and to "age them out", in 256 the standard manner. However, if the PE devices have backdoor 257 connections with each other via a layer 2 network, they may need to 258 be full IEEE bridges, running spanning tree with each other. 259 Specification of the precise functionality which the bridge modules 260 must have in particular circumstances is, however, out of scope of 261 the current document. 263 This framework specifies that each "bridge module" has a single 264 "Emulated LAN interface". It does not specify the number of bridge 265 modules that a VPLS-PE may contain, nor does it specify the number of 266 VPLS instances which may attach to a bridge module over a single 267 "Emulated LAN interface". 269 Thus the framework is compatible with at least the following three 270 models: 272 - Model 1 274 A VPLS-PE contains a single bridge module, and supports a single 275 VPLS instance. The VPLS instance is an Emulated LAN; if that 276 Emulated LAN contains VLANs, 802.1Q tagging must be used to 277 indicate which packets are in which VLANs. 279 - Model 2 281 A VPLS-PE contains a single bridge module, but supports multiple 282 VPLS instances. Each VPLS instance is thought of as a VLAN (in 283 effect, an "Emulated VLAN"), and the set of VPLS instances are 284 treated as a set of VLANs on a common LAN. 286 - Model 3 288 A VPLS-PE contains an arbitrary number of bridge modules, each of 289 which attaches to a single VPLS instance. 291 There may be other models as well, some of which are combinations of 292 the 3 models above. Different models may have different 293 characteristics, and different scopes of applicability. 295 Each VPLS solution should specify the model or models that it is 296 supporting. Each solution should also specify the necessary bridge 297 functionality that its bridge modules must support. 299 This framework does not specify the way in which bridge control 300 protocols are used on the Emulated LANs. 302 2.2.1. Entities in the VPLS reference model 304 The PE (VPLS-PE) and CE devices are defined in [VPN-TERM]. 306 2.3. Reference Model for Distributed VPLS-PE or VPWS-PE 308 VPLS-PE/VPWS-PE 309 Functionality . . . . . . . 310 . . . . . . . . . . . . . 311 . . . . 312 +----+ . +----+ +----+ . . Service . 313 | CE |--.--|U-PE|----|N-PE|-.---. Provider . 314 +----+ . +----+ +----+ . . Backbone . 315 . . . . . . . . . . . . . 317 2.3.1. Entities in the Distributed PE Reference Models 319 A VPLS-PE or a VPWS-PE functionality may be distributed to more than 320 one device. The device closer to the customer/user is called User 321 facing PE (U-PE) and the device closer to the core network is called 322 Network facing PE (N-PE). 324 For further discussion see section 3.4.3. 326 The terms "U-PE" and "N-PE" are defined in [VPN-TERM]. 328 2.4. VPWS-PE and VPLS-PE 330 The VPWS-PE and VPLS-PE are functionally very similar, the they both 331 use forwarders to map attachment circuits to pseudo-wires. The only 332 differences is that while the forwarder in a VPWS-PE does a one-to- 333 one mapping between the attachment circuit and pseudo-wire, the 334 forwarder in a VPLS-PE is a Virtual Switching Instance (VSI) that 335 maps multiple attachment circuits to multiple pseudo-wires (for 336 further discussion see section 3.) 338 3. Functional Components of L2 VPN 340 This section specifies a functional model for L2VPN, which allows one 341 to break an L2VPN architecture down into its functional components. 342 This allows us to exhibit the roles played by the various protocols 343 and mechanisms, and thus to make it easier to understand the 344 differences and similarities between various proposed L2VPN 345 architectures. 347 Section 3.1 contains an overview of some different types of L2VPN. 348 In section 3.2, functional components that are common to the 349 different types are discussed. Then there is a section for each of 350 the L2VPN service types being considered. The latter sections discuss 351 functional components, which may be specific to particular L2VPN 352 types, as well as discussing type-specific features of the generic 353 components. 355 3.1. Types of L2VPN 357 The types of L2VPN are distinguished by the characteristics of the 358 service that they offer to the customers of the Service Provider 359 (SP). 361 3.1.1. Virtual Private Wire Service (VPWS) 363 In a VPWS, each CE device is presented with a set of point-to-point 364 virtual circuits. 366 The other end of each virtual circuit is another CE device. Frames 367 transmitted by a CE on such a virtual circuit are received by the CE 368 device at the other end-point of the virtual circuit. Forwarding from 369 one CE device to another is not affected by the content of the frame, 370 but is fully determined by the virtual circuit on which the frame is 371 transmitted. The PE thus acts as a virtual circuit switch. 373 This type of L2VPN has long been available over ATM and Frame Relay 374 backbones. Providing this type of L2VPN over MPLS and/or IP backbones 375 is the current topic. 377 Requirements for this type of L2VPN are specified in [L2VPN-REQ]. 379 3.1.2. Virtual Private LAN Service (VPLS) 381 In a VPLS, each CE device has one or more LAN interfaces that lead to 382 a "virtual backbone". 384 Two CEs are connected to the same virtual backbone if and only if 385 they are members of the same VPLS instance (i.e., same VPN). When a 386 CE transmits a frame, the PE that receives it examines the MAC 387 Destination Address field in order to determine how to forward the 388 frame. Thus the PE functions as a bridge. As is indicated in Figure 389 3, if a set of PEs support a common VPLS instance, then there is an 390 Emulated LAN, corresponding to that VPLS instance, to which each of 391 those PE bridges attaches (via an emulated interface). From the 392 perspective of a CE device, the virtual backbone is the set of PE 393 bridges and the Emulated LAN on which they reside. Thus to a CE 394 device, the LAN which attaches it to the PE is extended transparently 395 over the routed MPLS and/or IP backbone. 397 The PE bridge function treats the Emulated LAN as it would any other 398 LAN to which it has an interface. Forwarding decisions are made in 399 the manner which is normal for bridges, based on MAC Source Address 400 learning. 402 VPLS is like VPWS in that forwarding is done without any 403 consideration of the Layer3 header. VPLS is unlike VPWS in that: 405 - VPLS allows the PE to use addressing information in a frame's L2 406 header to determine how to forward the frame; 408 - VPLS allows a single CE/PE connection to be used for transmitting 409 frames to multiple remote CEs; in this particular respect, VPLS 410 resembles L3VPN more than VPWS. 412 Requirements for this type of L2VPN are specified in [L2VPN-REQ]. 414 3.1.3. IP-only LAN-like Service (IPLS) 416 An IPLS is very like a VPLS, except that: 418 - it is assumed that the CE devices are hosts or routers, not 419 switches 421 - it is assumed that the service will only carry IP packets, and 422 supporting packets such as ICMP and ARP; Layer2 packets which do 423 not contain IP are not supported. 425 While this service is a functional subset of the VPLS service, it is 426 considered separately because it may be possible to provide it using 427 different mechanisms, which may allow it to run on certain hardware 428 platforms that cannot support the full VPLS functionality. 430 3.2. Generic L2VPN Transport Functional Components 432 All L2VPN types must transport "frames" across the core network 433 connecting the PE's. In all L2VPN types, a PE (PE1) receives a frame 434 from a CE (CE1), then transports the frame to a PE (PE2), which then 435 transports the frame to a CE (CE2). In this section, we discuss the 436 functional components, which are necessary to transport L2 frames in 437 any type of L2VPN service. 439 3.2.1. Attachment Circuits 441 In any type of L2VPN, a CE device attaches to a PE device via some 442 sort of circuit or virtual circuit. We will call this an "Attachment 443 Circuit" (AC). We use this term very generally; an Attachment Circuit 444 may be a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, 445 a PPP connection on a physical interface, a PPP session from an L2TP 446 tunnel, an MPLS LSP, etc. The CE device may be a router, a switch, a 447 host, or just about anything, which the customer needs hooked up to 448 the VPN. An AC carries a frame between CE and PE, or vice versa. 450 Procedures for setting up and maintaining the ACs are out of scope of 451 this architecture. 453 These procedures are generally specified as part of the specification 454 of the particular Attachment Circuit technology. 456 Any given frame will traverse an AC from a CE to a PE and then on 457 another AC from a PE to a CE. 459 We refer to the former AC as the frame's "ingress AC" and to the 460 latter AC as the frame's "egress AC". Note that this notion of 461 "ingress AC" and "egress AC" is relative to a specific frame, and 462 denotes nothing more than the frame's direction of travel while on 463 that AC. 465 3.2.2. Pseudowires 467 A "Pseudowire" (PW) is a relation between two PE devices. Whereas an 468 AC is used to carry a frame from CE to PE, a PW is used to carry a 469 frame between two PEs. We use the term "pseudowire" in the sense of 470 [PWE3- ARCH]. 472 Setting up and maintaining the PWs is the job of the PEs. State 473 information for a particular PW is maintained at the two PEs which 474 are its endpoints, but not at other PEs, and not in the backbone 475 routers (P routers). 477 Pseudowires may be point-to-point, multipoint-to-point, or point-to- 478 multipoint. In this framework, point-to-point PWs are always 479 considered to be bidirectional; multipoint-to-point and point-to- 480 multipoint PWs are always considered to be unidirectional. 481 Multipoint-to-point PWs can be used only when the PE receiving a 482 frame from the PW does not need to know where the frame came from. 483 Point-to-multipoint PWs may be useful when frames need to be 484 multicast. 486 Procedures for setting up and maintaining point-to-multipoint PWs are 487 not considered in this version of this framework. 489 Any given frame travels first on its ingress AC, then on a PW, then 490 on its egress AC. 492 Multicast frames may be replicated by a PE, so of course the 493 information carried in multicast frames may travel on more than one 494 PW and more than one egress AC. 496 Thus with respect to a given frame, a PW may be said to associate a 497 number of ACs. If these ACs are of the same technology (e.g., both 498 ATM, both Ethernet, both Frame Relay) the PW is said to provide 499 "homogeneous transport"; otherwise it is said to provide 500 "heterogeneous transport". Heterogeneous transport requires that some 501 sort of interworking function be applied. There are at least three 502 different approaches to interworking: 504 1. One of the CEs may perform the interworking locally. For 505 example, if CE1 attaches to PE1 via ATM, but CE2 attaches to 506 PE2 via Ethernet, then CE1 may decide to send/receive Ethernet 507 frames over ATM, using the RFC2684 "LLC Encapsulation for 508 Bridged Protocols". In such a case, PE1 would need to know 509 that it is to terminate the ATM VC locally, and only 510 send/receive Ethernet frames over the PW. 512 2. One of the PEs may perform the interworking. For example, if 513 CE1 attaches to PE1 via ATM, but CE2 attaches to PE2 via Frame 514 Relay, PE1 may provide the "ATM/FR Service Interworking" 515 function. This would be transparent to the CEs, and the PW 516 would carry only Frame Relay frames. 518 3. IPLS could be used. In this case the "frames" carried by the 519 PW are IP datagrams, and the two PEs need to cooperate in order 520 to spoof various L2-specific procedures used by IP (see section 521 3.5). 523 3.2.3. Forwarders 525 In all types of L2VPN, a PE, say PE1, receives a frame over an AC, 526 and forwards it over a PW to another PE, say PE2. PE2 then forwards 527 the frame out on another AC. 529 The case in which PE1 and PE2 are the same device is an important 530 case to handle correctly, in order to provide the L2VPN service 531 properly. However, as this case does not require any protocol, we do 532 not further address it in this document. 534 When PE1 receives a frame on a particular AC, it must determine the 535 PW on which the frame must be forwarded. In general, this is done by 536 considering: 538 - the incoming AC, 540 - possibly the contents of the frame's Layer2 header, and 542 - possibly some forwarding information which may be statically or 543 dynamically maintained. 545 If dynamic or static forwarding information is considered, the 546 information is specific to a particular L2VPN instance (i.e., to a 547 particular VPN). 549 Similarly, when PE2 receives a frame on a particular PW, it must 550 determine the AC on which the frame must be forwarded. This is done 551 by considering: 553 - the incoming PW, 555 - possibly the contents of the frame's Layer2 header, and 557 - possibly some forwarding information which may be statically or 558 dynamically maintained. 560 If dynamic or static forwarding information is considered, the 561 information is specific to a particular L2VPN instance (i.e. to a 562 particular VPN). 564 The procedures used to make the forwarding decision are known as a 565 "forwarder". We may think of a PW as being "bound", at each of its 566 endpoints, to a forwarder. The forwarder in turn "binds" the PWs to 567 ACs. Different types of L2VPN have different types of forwarders. 569 For instance, a forwarder may bind a single AC to a single PW, 570 ignoring all frame contents and using no other forwarding 571 information. Or a forwarder may bind an AC to a set of PWs and ACs, 572 moving individual frames from AC to PW, from a PW to an AC or from AC 573 to AC by comparing information from the frame's Layer2 header to 574 information in a forwarding database. This is discussed in more 575 detail below, as we consider the different L2VPN types. 577 3.2.4. Tunnels 579 A PW is carried in a "tunnel" from PE1 to PE2. We assume that an 580 arbitrary number of PWs may be carried in a single tunnel; the only 581 requirement is that the PWs all terminate at PE2. 583 We do not even require that all the PWs in the tunnel originate at 584 PE1; the tunnels may be multipoint-to-point tunnels. Nor do we 585 require that all PWs between the same pair of PEs travel in the same 586 tunnel. All we require is that when a frame traveling through such a 587 tunnel arrives at PE2, PE2 will be able to associate it with a 588 particular PW. 590 (While one can imagine tunneling techniques that only allow one PW 591 per tunnel, they have evident scalability problems, and we do not 592 consider them further.) 594 There are a variety of different tunneling technologies which may be 595 used for the PE-PE tunnels. All that is really required is that the 596 tunneling technologies allow the proper demultiplexing of the 597 contained PWs. The tunnels might be MPLS LSPs, L2TP tunnels, IPsec 598 tunnels, MPLS- in-IP tunnels, etc. Generally the tunneling 599 technology will require the use of an encapsulation that contains a 600 demultiplexor field, where the demultiplexor field is used to 601 identify a particular PW. Procedures for setting up and maintaining 602 the tunnels are not within the scope of this framework. (But see 603 section 3.2.6, "Pseudowire Signaling".) 605 If there are multiple tunnels from PE1 to PE2, it may be desirable to 606 assign a particular PE1-PE2 PW to a particular tunnel based on some 607 particular characteristics of the PW and/or the tunnel. For example, 608 perhaps different tunnels are associated with different QoS 609 characteristics, and different PWs require different QoS. Procedures 610 for specifying how to assign PWs to tunnels are out of scope of the 611 current framework. 613 Though point-to-point PWs are bidirectional, the tunnels in which 614 they travel need not be either bidirectional or point-to-point. For 615 example, a point-to-point PW may travel within a unidirectional 616 multipoint-to- point MPLS LSP. 618 3.2.5. Encapsulation 620 As L2VPN packets are carried in pseudowires, standard pseudowire 621 encapsulation formats and techniques (as specified by the IETF's PWE3 622 WG) should be used wherever applicable. 624 Generally the PW encapsulations will themselves be encapsulated 625 within a tunnel encapsulation, as determined by the specification of 626 the tunneling protocol. 628 It may be necessary to define additional PW encapsulations to cover 629 areas that are of importance for L2VPN, but may not be within the 630 scope of PWE3. Heterogeneous transport may be an instance of this. 632 3.2.6. Pseudowire Signaling 634 Procedures for setting up and maintaining the PWs themselves are 635 within the scope of this framework. This includes procedures for 636 distributing demultiplexor field values, even though the 637 demultiplexor field, strictly speaking, belongs to the tunneling 638 protocol rather than to the PW. 640 The signaling for a point-to-point pseudowire must perform the 641 following functions: 643 - Distribution of the demultiplexor. 645 Since many PWs may be carried in a single tunnel, the tunneling 646 protocol must assign a demultiplexor value to each PW. These 647 demultiplexors must be unique with respect to a given tunnel (or 648 with some tunneling technologies, unique at the egress PE). 649 Generally, the PE which is the egress of the tunnel will select 650 the demultiplexor values, and will distribute them to the PE(s) 651 which is (are) the ingress(es) of the tunnel. This is the 652 essential part of the PW setup procedure. 654 Note that, as is usually the case in tunneling architectures, the 655 demultiplexor field belongs to the tunneling protocol, not to the 656 protocol being tunneled. For this reason, the PW setup protocols 657 may be extensions of the control protocols for setting up the 658 tunnels. 660 - Selection of the Forwarder at the Remote PE. 662 The signaling protocol must contain enough information to enable 663 the remote PE to select the proper forwarder to which the PW is 664 to be bound. We can call this information the "Remote Forwarder 665 Selector". The information that is required will depend on the 666 type of L2VPN being provided and on the provisioning model (see 667 sections 3.3.1 and 3.4.2) being used. The Remote Forwarder 668 Selector may uniquely identify a particular Forwarder, or it may 669 identify an attribute of Forwarders. In the latter case, it would 670 select whichever Forwarder has been provisioned with that 671 attribute. 673 - Support pseudowire emulations. 675 To the extent that a particular PW must emulate the signaling of 676 a particular Layer2 technology, the PW signaling must provide the 677 necessary functions. 679 - Distribution of State Changes. 681 Changes in the state of an AC may need to be reflected in changes 682 to the state of the PW to which the AC is bound, and vice versa. 683 The specification as to which changes need to be reflected in 684 what way would generally be within the province of the PWE3 WG. 686 - Establish pseudowire characteristics. 688 To the extent that one or more characteristics of a PW must be 689 known to and/or agreed upon by both endpoints, the signaling must 690 allow for the necessary interaction. 692 As specified above, signaling for point-to-point PWs must pass enough 693 information to allow a remote PE to properly bind a PW to a 694 Forwarder, and to associate a particular demultiplexor value with 695 that PW. Once the two PEs have done the proper PW/Forwarder bindings, 696 and have agreed on the demultiplexor values, the PW may be considered 697 to have been set up. If it is necessary to negotiate further 698 characteristics or parameters of a particular PW, or to passing 699 status information for a particular PW, the PW may be identified by 700 the demultiplexor value. 702 Signaling procedures for point-to-point pseudowires are most commonly 703 point-to-point procedures that are executed by the two PW endpoints. 704 There are however proposals to use point-to-multipoint signaling for 705 setting up point-to-point pseudowires, so this is included in the 706 framework. When PWs are themselves point-to-multipoint, it is also 707 possible to use either point-to-point signaling or point-to- 708 multipoint signaling to set them up. This is discussed in the 709 remainder of this section. 711 3.2.6.1. Point-to-Point Signaling 713 There are several ways to do the necessary point-to-point signaling. 714 Among them are: 716 - LDP 718 LDP extensions can be defined for pseudowire signaling. This form 719 of signaling can be used for pseudowires which are to be carried 720 in MPLS "tunnels", or in MPLS-in-something-else tunnels. 722 - L2TP 724 L2TP can be used for pseudowire signaling, resulting in 725 pseudowires that are carried as "sessions" within L2TP tunnels. 726 Pseudowire-specific extensions to L2TP may also be needed. 728 Other methods may be possible as well. 730 It is possible to have one control connection between a pair of PEs, 731 which is used to control many PWs. 733 The use of point-to-point signaling for setting up point-to-point PWs 734 is straightforward. Multipoint-to-point PWs can also be set up by 735 point- to-point signaling, as the remote PEs do not necessarily need 736 to know whether the PWs are multipoint-to-point or point-to-point. 737 In some signaling procedures, the same demultiplexor value may be 738 assigned to all the remote PEs. 740 3.2.6.2. Point-to-Multipoint Signaling 742 Consider the following situation: 744 - It is necessary to set up a set of PWs, all of which have the 745 same characteristics. 747 - It is not necessary to use the PW signaling protocol to pass PW 748 state changes. 750 - For each PW in the set, the same value of the Remote Forwarder 751 Selector can be used. 753 Call these the "Environmental Conditions". 755 Suppose also that there is some mechanism by which, given a range of 756 demultiplexor values, each of a set of PEs can make a unique and 757 deterministic selection of a single value from within that range. 758 Call this the "Demultiplexor Condition". Alternatively, suppose that 759 one is trying to set up a multipoint-to-point PW rather than a 760 point-to-point PW. Call this the "Multipoint Condition". 762 If: 764 - The Environmental Conditions hold, and 766 - Either 768 * the Demultiplexor Condition holds, or 770 * the Multipoint Condition holds, 772 then for a given set of PWs which terminate at egress PE1, the 773 information which PE1 needs to send to the ingress PE(s) of each 774 pseudowire in the set is exactly the same. All the ingress PE(s) 775 receive the same Forwarder Selector value. They all receive the same 776 set of PW parameters (if any). And either they all receive the same 777 demultiplexor value (if the PW is multipoint-to-point) or they all 778 receive a range of demultiplexor values from which each can choose a 779 unique demultiplexor value for itself. 781 Rather than connecting to each ingress PE and replicating the same 782 information, it may make sense either to multicast the information, 783 or to send the information once to a "reflector", which will then 784 take responsibility for distributing the information to the other 785 PEs. 787 We refer to this sort of technique as "point-to-multipoint" 788 signaling. It would, for example, be possible to use BGP to do the 789 signaling, with the PEs being BGP peers not of each other, but of one 790 or more BGP route reflectors. 792 3.2.6.3. Inter-AS Considerations 794 Pseudowires may need to run from a PE in one Service Provider's 795 network to a PE in another Service Provider's network. This means 796 that the signaling to set up the PEs must be able to cross network 797 boundaries. All known proposals for signaling are able to do this. It 798 is especially advisable to use some form of authentication between 799 the two PW endpoints in this case. 801 3.2.7. Service Quality 803 Service Quality refers to the ability for the network to deliver a 804 Service level Specification (SLS) for service attributes such as 805 protection, security and Quality of Service (QoS). The service 806 quality provided depends on the subscriber's requirements, and can be 807 characterized by a number of performance metrics. 809 The necessary Service Quality must be provided on the ACs as well as 810 on the PWs. Mechanisms for providing Service Quality on the PWs may 811 be PW- specific or tunnel-specific; in the latter case, the 812 assignment of a PW to a tunnel may depend on the Service Quality. 814 3.2.7.1. Quality of Service (QoS) 816 QoS describes the queuing behavior applied to a particular "flow", in 817 order to achieve particular goals of precedence, throughput, delay, 818 jitter, etc. 820 Based on the customer Service Level Agreement (SLA), traffic from 821 customer can be prioritized, policed and shaped for QoS requirements. 822 The queuing and forwarding policies can preserve the packet order and 823 QoS parameters of customer traffic. The class of services can be 824 mapped from information in the customer frames, or it can be 825 independent of the frame content. 827 QoS functions can be listed as follows: 829 - Customer Traffic Prioritization: L2VPN services could be best 830 effort or QoS guaranteed. Traffic from one customer might need to 831 be prioritized over others when sharing same network resources. 832 This requires capabilities within the L2VPN solution to classify 833 and mark priority to QoS guaranteed customer traffic. 835 - Proper queuing behavior would be needed at the egress AC, and 836 possibly within the backbone network as well. If queuing behavior 837 must be controlled within the backbone network, the control might 838 be based on CoS information in the MPLS or IP header, or it might 839 be achieved by nesting particular tunnels within particular 840 traffic engineering tunnels. 842 - Policing: This ensures that a user of L2VPN services uses network 843 resources within the limits of the agreed SLA. Any excess L2VPN 844 traffic can be rejected or handled differently based on provider 845 policy. 847 - Policing would generally be applied at the ingress AC. 849 - Shaping: Under some cases the random nature of L2VPN traffic 850 might lead to sub-optimal utilization of network resources. 851 Through queuing and forwarding mechanisms the traffic can be 852 shaped without altering the packet order. 854 - Shaping would generally be applied at the ingress AC. 856 3.2.7.2. Resiliency 858 Resiliency describes the ability of the L2VPN infrastructure to 859 protect a flow from network outage, so that service remains available 860 in the presence of failures. 862 L2VPN, like any other service, is subject to failures such as link, 863 trunk and node failures, both in the SP's core network infrastructure 864 and on the ACs. 866 It is desirable that the failure be detected "immediately" and 867 protection mechanisms allow fast restoration times to make L2VPN 868 service almost transparent to these failures to the extent possible, 869 based on the level of resiliency. Restoration should take place 870 before the CEs can react to the failure. Essential aspects of 871 providing resiliency are: 873 - Link/Node failure detection: Mechanisms within the L2VPN service 874 should allow for link or node failures that impact the Service, 875 and should be detected immediately. 877 - Resiliency policy: The way in which a detected failure is handled 878 will depend upon the restoration policy of the SLA associated 879 with the L2VPN service specification. It may need to be handled 880 immediately, or it may need to be handled only if no other 881 critical failure needs protection resources, or it may be 882 completely ignored if it is within the bounds of the "acceptable 883 downtime" allowed by the L2VPN service. 885 - Restoration Mechanisms: The L2VPN solutions could allow for 886 physical level protection, logical level protection or both. For 887 example, by connecting customers over redundant and physically 888 separate ACs to different provider customer-facing devices, one 889 AC can be maintained as active while the other could be marked as 890 a backup; upon the failure detection across the primary AC, the 891 backup could become active. 893 To a great extent, resiliency is a matter of having appropriate 894 failure and recovery mechanisms in the network core, including 895 "ordinary" adaptive routing as well as "fast reroute" capabilities. 896 The ability to support redundant ACs between CEs and PEs also plays a 897 role. 899 3.2.8. Management 901 An L2VPN solution can provide mechanisms to manage and monitor 902 different L2VPN components. From a Service Level Agreement (SLA) 903 perspective, L2VPN solutions could allow monitoring of L2VPN service 904 characteristics and offer mechanisms used by Service Providers to 905 report such monitored statistical data. Trouble-shooting and 906 verification of operational and maintenance activities of L2VPN 907 services are essential requirements for Service Providers. 909 3.3. VPWS 911 A VPWS is an L2VPN service in which each forwarder binds exactly one 912 AC to exactly one PW. Frames received on the AC are transmitted on 913 the PW; frames received on the PW are transmitted on the AC. The 914 content of a frame's Layer2 header plays no role in the forwarding 915 decision, except insofar as the Layer2 header contents are used to 916 associate the frame with a particular AC (as, e.g., the DLCI field of 917 a Frame Relay frame identifies the AC). 919 A particular combination of forms a "virtual circuit" 920 between two CE devices. 922 A particular VPN (VPWS instance) may be thought of as a collection of 923 such virtual circuits, or as an "overlay" of PWs on the MPLS or IP 924 backbone. This creates an overlay topology that is in effect the 925 "virtual backbone" of a particular VPN. 927 Whether two virtual circuits are said to belong to the same VPN or 928 not is an administrative matter, based on the agreements between the 929 SPs and their customers. This may impact the provisioning model 930 (discussed below). It may also affect how particular PWs are 931 assigned to tunnels, the way QoS is assigned to particular ACs and 932 PWs, etc. 934 Note that VPWS makes use of point-to-point PWs exclusively. 936 3.3.1. Provisioning and Auto-Discovery 938 Provisioning a VPWS is a matter of: 940 1. Provisioning the ACs 941 2. Providing the PEs with the necessary information to enable them 942 to set up PWs between ACs to result in the desired overlay 943 topology. 945 3. Configuring the PWs with any necessary characteristics 947 3.3.1.1. Attachment Circuit Provisioning 949 In many cases, the ACs must be individually provisioned on the PE 950 and/or CE. This will certainly be the case if the CE/PE attachment 951 technology is a switched network, such as ATM or FR, and the VCs are 952 PVCs rather than SVCs. It is also the case whenever the individual 953 Attachment Circuits need to be given specific parameters (e.g., QoS 954 parameters, guaranteed bandwidth parameters) that differ from circuit 955 to circuit. 957 There are also cases in which ACs might not have to be individually 958 provisioned. E.g., if an AC is just an MPLS LSP running between a CE 959 and a PE, it could be set up as the RESULT of a PW being set up, 960 rather than having to be provisioned BEFORE the PW can be set up. The 961 same may apply whenever the AC is a Switched Virtual Circuit of any 962 sort, though in this case, various policy controls might need to be 963 provisioned, e.g., limiting the number of ACs that can be set up 964 between a given CE and a given PE. 966 Issues such as whether the Attachment Circuits need to be 967 individually provisioned or not, whether they are Switched VCs or 968 Permanent VCs, and what sorts of policy controls may be applied, are 969 implementation and deployment issues, and are considered to be out of 970 scope of this framework. 972 3.3.1.2. PW Provisioning for Arbitrary Overlay Topologies 974 In order to support arbitrary overlay topologies, it is necessary to 975 allow the provisioning of individual PWs. In this model, when a PW 976 is provisioned on a PE device, it is locally bound to a specific AC. 977 It is also provisioned with information that identifies a specific AC 978 at a remote PE. 980 There are basically two variations of this provisioning model: 982 - Two-sided provisioning 984 With two-sided provisioning, each PE that is at the end of a PW 985 is provisioned with the following information: 987 * Identifier of the Local AC to which the PW is to be bound 989 * PW type and parameters 991 * IP address of the remote PE (i.e., the PE which is to be at 992 the remote end of the PW) 994 * Identifier which is meaningful to the remote PE, and which 995 can be passed in the PW signaling protocol to enable the 996 remote PE to bind the PW to the proper AC. This can be an 997 identifier of the PW or an identifier of the remote AC. If a 998 PW identifier is used, it must be unique at each of the two 999 PEs. If an AC identifier is used, it need only be unique at 1000 the remote PE. 1002 This identifier is then used as the Remote Forwarder Selector 1003 when signaling is done (see 3.2.6.1). 1005 - Single-sided Provisioning 1007 With single sided provisioning, a PE at one end of a PW is 1008 provisioned with the following information: 1010 * Identifier of the Local AC to which the PW is to be bound 1012 * PW type and parameters 1014 * Globally unique identifier of remote AC 1016 This identifier is then used as the Forwarder Selector when 1017 signaling is done (see section 3.2.6.1). 1019 In this provisioning model, the IP address of the remote PE is 1020 not provisioned. Rather, the assumption is that an auto- 1021 discovery scheme will be used to map the globally unique 1022 identifier to the IP address of the remote PE, along with an 1023 identifier (perhaps unique only at the latter PE) for an AC at 1024 that PE. The PW signaling protocol can then make a connection to 1025 the remote PE, passing the AC identifier, so that the remote PE 1026 binds the PW to the proper AC. 1028 This scheme requires provisioning of the PW at only one PE, but 1029 does not eliminate the need (if there is a need) to provision the 1030 ACs at both PEs. 1032 These provisioning models fit well with the use of point-to-point 1033 signaling. When each PW is individually provisioned, as the 1034 conditions necessary for the use of point-to-multipoint signaling do 1035 not hold. 1037 3.3.1.3. Colored Pools PW Provisioning Model 1039 Suppose that at each PE, sets of ACs are gathered together into 1040 "pools", and that each such pool is assigned a "color". (For 1041 example, a pool might contain all and only the ACs from this PE to a 1042 particular CE.) Now suppose we impose the following rule: whenever 1043 PE1 and PE2 have a pool of the same color, there will be a PW between 1044 PE1 and PE2 which is bound at PE1 to an arbitrarily chosen AC from 1045 that pool, and at PE2 to an arbitrarily chosen AC from that pool. 1046 (We do not rule out the case where a single PE has multiple pools of 1047 a given color.) 1049 For example, each pool in a particular PE might represent a 1050 particular CE device, with the ACs in the pool being the ACs 1051 connecting that CE to that PE. The color might be a VPN-id. 1052 Application of this provisioning model would then lead to a full CE- 1053 to-CE mesh within the VPN, where every CE in the VPN has a virtual 1054 circuit to every other CE within the VPN. 1056 More specifically, to provision VPWS according to this model, one 1057 provisions a set of pools, and configures each pool with the 1058 following information: 1060 - The set of ACs that belong to the pool (with no AC belonging to 1061 more than one pool) 1063 - The color 1065 - A pool identifier that is unique at least relative to the color. 1067 An auto-discovery procedure is then used to map each color into a 1068 list of ordered pairs . The 1069 occurrence of a pair on this list means that the PE at IP 1070 address X has a pool with pool id Y which is of the specified 1071 color. 1073 This information can be used to support several different 1074 signaling techniques. One possible technique proceeds as 1075 follows: 1077 - A PE finds that it has a pool of color C. 1079 - Using auto-discovery, it obtains the set of ordered pairs 1080 for color C. 1082 - For each such pair , it: 1084 * removes an AC from the pool 1086 * binds the AC to a particular PW 1088 * signals PE X via point-to-point signaling that the PW is to 1089 be bound to an AC from pool Y. 1091 Another possible signaling technique is the following: 1093 - A PE finds that it has a pool of color C, containing n ACs. 1095 - It binds each AC to a PW, creating a set of PWs. This set of PWs 1096 is then organized into a sequence. (For instance, each PW may be 1097 associated with a demultiplexor field value, and the PWs may then 1098 be sequenced according to the numerical value of their respective 1099 demultiplexors.) 1101 - Using auto-discovery, it obtains the list of PE routers that have 1102 one or more pools of color C. 1104 - It signals each such PE router, specifying the sequence Q of PWs. 1106 - If PE X receives such a signal, and PE X has a pool Y of the 1107 specified color, it: 1109 * removes an AC from the pool 1111 * binds the AC to the PW which is the "Yth" PW in the sequence 1112 Q. 1114 This presumes, of course, that the pool identifiers are or can be 1115 uniquely mapped into small ordinal numbers; assigning the pool 1116 identifiers in this way becomes a requirement of the provisioning 1117 system. 1119 Note that since this technique signals the same information to all 1120 the remote PEs, it can be supported via point-to-multipoint 1121 signaling. 1123 This provisioning model can be applied as long as the following 1124 conditions hold: 1126 - There is no need to provision different characteristics for the 1127 different PWs, and 1129 - It makes no difference which pairs of ACs are bound together by 1130 PWs, as long as both ACs in the pair come from like-colored 1131 pools, and 1133 - It is possible to construct the desired overlay topology simply 1134 by assigning colors to the pools. (This is certainly simple if a 1135 full mesh is desired, or if a hub and spoke configuration is 1136 desired; creating arbitrary topologies is less simple, and 1137 perhaps not always possible.) 1139 3.3.2. Requirements on Auto-Discovery Procedures 1141 Some of the requirements for auto-discovery procedures can be deduced 1142 from the above. 1144 To support the single-sided provisioning model, auto-discovery must 1145 be able to map a globally unique identifier (of a PW or of an 1146 Attachment Circuit) to an IP address of a PE. 1148 To support the colored pools provisioning model, auto-discovery must 1149 enable a PE to determine the set of other PEs that contain pools of 1150 the same color. 1152 These requirements enable the auto-discovery scheme to provide the 1153 information, which the PEs need to set up the PWs. 1155 There are additional requirements on the auto-discovery procedures 1156 that cannot simply be deduced from the provisioning model: 1158 - Particular signaling schemes may require additional information 1159 before they can proceed, and hence may impose additional 1160 requirements on the auto-discovery procedures. 1162 - A given Service Provider may support several different types of 1163 signaling procedures, and thus the PEs may need to learn, via 1164 auto- discovery, which signaling procedures to use. 1166 - Changes in the configuration of a PE should be reflected by the 1167 auto-discovery procedures, within a timely manner, and without 1168 the need to explicitly reconfigure any other PE. 1170 - The auto-configuration procedures must work across service 1171 provider boundaries. This rules out, e.g., the use of schemes 1172 that piggyback the auto-discovery information on the backbone's 1173 IGP. 1175 3.3.3. Heterogeneous Pseudowires 1177 Under certain circumstances, it may be desirable to have a PW that 1178 binds two ACs that use different technologies (e.g., one is ATM, one 1179 is Ethernet). There are a number of different ways, depending on the 1180 AC types, in which this can be done. For example: 1182 - If one AC is ATM and one is FR, then standard ATM/FR Network 1183 Interworking can be used. In this case, the PW might be signaled 1184 for ATM, with the Interworking function occurring between the PW 1185 and the FR AC. 1187 - A common encapsulation can be used on both ACs, e.g., if one AC 1188 is Ethernet and one is FR, an "Ethernet over FR" encapsulation 1189 can be used on the latter. In this case, the PW could be 1190 signaled for Ethernet, with the processing of the Ethernet over 1191 FR encapsulation being local to the PE with the FR AC. 1193 - If it is known that the two ACs attach to IP routers or hosts, 1194 and carry only IP traffic, then one could use a PW which carries 1195 the IP packets, and the respective Layer2 encapsulations would be 1196 local matters for the two PEs. However, if one of the ACs is a 1197 LAN and one is a point-to-point link, care would have to be taken 1198 to ensure that such procedures as ARP and Inverse ARP are 1199 properly handled; this might require some signaling, and some 1200 proxy functions. Further, if the CEs use a routing algorithm that 1201 has different procedures for LAN interfaces than for point-to- 1202 point interfaces, additional mechanisms may be required to ensure 1203 proper interworking. 1205 3.4. VPLS Emulated LANs 1207 A VPLS is an L2VPN service in which: 1209 - the ACs attach CE devices to PE bridge modules, 1211 - each PE bridge module is attached via an "emulated LAN interface" 1212 to an "emulated LAN" 1214 This is shown in Figure 3. 1216 In this section, we examine the functional decomposition of the VPLS 1217 Emulated LAN. An Emulated LAN's ACs are the "emulated LAN 1218 interfaces" attaching PE bridge modules to the "VPLS Forwarder" 1219 modules (see Figure 3). The payload on the ACs consists of ethernet 1220 frames, with or without VLAN headers. 1222 A given VPLS Forwarder in a given PE will have multiple ACs only if 1223 there are multiple bridge modules in that PE which attach to that 1224 Forwarder. This scenario is included in the Framework, though 1225 discussion of its utility is out of scope. 1227 The set of VPLS Forwarders within a single VPLS are connected via 1228 PWs. Two VPLS Forwarders will have a PW between them only if those 1229 two Forwarders are part of the same VPLS. (There may be a further 1230 restriction that two VPLS Forwarders have a PW between them only if 1231 those two Forwarders belong to the same VLAN in the same VPN.) A 1232 particular set of interconnected VPLS Forwarders is what constitutes 1233 a VPLS Emulated LAN. 1235 On a real LAN, any frame transmitted by one entity is received by all 1236 the others. A VPLS Emulated LAN, however, behaves somewhat 1237 differently. When a VPLS Forwarder receives a unicast frame over one 1238 of its Emulated LAN interfaces, the Forwarder does not necessarily 1239 send the frame to all the other Forwarders on that Emulated LAN. A 1240 unicast frame need be sent to only one other Forwarder in order to be 1241 properly delivered to its destination MAC address. If the 1242 transmitting Forwarder knows which other Forwarder needs to receive a 1243 particular unicast frame, it will send the frame to just that one 1244 Forwarder. This forwarding optimization is an important part of any 1245 attempt to provide a VPLS service over a wide-area or metropolitan 1246 area network. 1248 In effect then each Forwarder behaves as a "Virtual Switch Instance" 1249 (VSI), maintaining a forwarding table in which maps MAC addresses to 1250 PWs. The VSI is populated in much the same was as a standard bridge 1251 populates its forwarding table. The VPLS Forwarders do MAC SA 1252 learning on frames received on PWs from other Forwarders, and must 1253 also do the related set of procedures, such as the aging out of 1254 address entries. Frames with unknown DAs or multicast DAs must be 1255 "broadcast" by one Forwarder to all the others (on the same emulated 1256 LAN). There are however a few important differences between the VPLS 1257 Forwarder VSI and the standard bridge forwarding function: 1259 - A VPLS Forwarder never learns the MAC SAs of frames which it 1260 receives on its ACs, it only learns the MAC SAs of frames which 1261 are received on PWs from other VPLS Forwarders; 1263 - The VPLS Forwarders of a particular emulated LAN do not 1264 participate in a spanning tree protocol with each other. A 1265 "split horizon" technique is used to prevent forwarding loops. 1267 These points are discussed further in the next section. 1269 Note that the PE bridge modules which are on a given Emulated LAN may 1270 or may not run spanning tree protocol with each other over the 1271 Emulated LAN; whether they do so or not is outside the scope of the 1272 VPLS specifications. The PE bridge modules will do MAC address 1273 learning on the ACs. The PE bridge modules also do MAC address 1274 learning on the Emulated LAN interfaces, but do not do MAC address 1275 learning on the PWs, as the PWs are "hidden" behind the Emulated LAN 1276 interface. Conceptually, the PE bridge module's forwarding table and 1277 the VPLS Forwarder's VSI are distinct entities. (Of course, 1278 particular implementations might combine these into a single table, 1279 but that is beyond the scope of this document.) 1281 A further issue does arise in the case where the PE bridges do run 1282 bridge control protocols with each other over the Emulated LAN. 1283 Bridge control protocols are generally designed to run in over a real 1284 LAN, and may presume, for their proper functioning, certain 1285 characteristics of the LAN, such as low latency and sequential 1286 delivery. If the Emulated LAN does not provide these 1287 characteristics, the control protocols may not perform as expected 1288 unless special mechanisms are provided for carrying the control 1289 frames. 1291 It should be noted that changes in the spanning tree (if any) of a 1292 customer network, or in the spanning tree (if any) of the PE bridges, 1293 may cause certain MAC addresses to change their location from one PE 1294 to another. These changes may not be visible to the VPLS Forwarders, 1295 which means that those MAC addresses might become unreachable until 1296 they are aged out of the first PE's VSI. If this is not acceptable, 1297 some mechanism for communicating such changes to the VPLS Forwarders 1298 must be provided. 1300 3.4.1. VPLS Overlay Topologies and Forwarding 1302 Within a single VPLS, the VPLS Forwarders are interconnected by PWs. 1303 The set of PWs thus forms an "overlay topology". 1305 The VPLS Forwarder VSIs are populated by means of MAC address 1306 learning. That is, the VSI keeps track of which MAC SAs have been 1307 received over which PWs. The presumption of course is that if a 1308 particular MAC address appears as the SA of a frame received over a 1309 particular PW, then frames which carry that MAC address in the DA 1310 field should be sent to the VSI which is at the remote end of the PW. 1311 In order for this presumption to be true, there must be a unique VSI 1312 at the remote end of the PW, which means that VSIs cannot be 1313 interconnected by means of multipoint-to-point PWs. The PWs are 1314 necessarily either point-to-point or, possibly, point-to-multipoint. 1316 MAC learning over a point-to-point PW is done via the standard 1317 techniques as specified by IEEE, where the PW is treated by the VPLS 1318 Forwarder as a "bridge port". Of course, if a MAC address is learned 1319 from a point-to-multipoint PW, the VSI must indicate that packets to 1320 that address are to be sent over a point-to-point PW which leads to 1321 the root of that point-to-multipoint PW. 1323 The VSI forwarding decisions must be coordinated so that loop-free 1324 forwarding over the overlay topology is ensured. 1326 There are several possible types of overlay topologies: 1328 - Full mesh 1330 In a full mesh, every VSI in a given VPLS has exactly one point- 1331 to-point PW to every other VSI in that same VPLS. 1333 In this topology, loop free forwarding of frames is ensured by 1334 the following rule: if a VSI receives a frame, over a PW, from 1335 another VSI, it MUST NOT forward that frame over ANY other PW to 1336 any other VSI. This ensures that once a frame traverses the 1337 Emulated LAN, it must be sent off the Emulated LAN. 1339 If a VSI receives, on one of its Emulated LAN interfaces, a 1340 unicast frame with a known DA, the frame is sent on exactly one 1341 point-to-point PW. 1343 If a VSI receives, on one of its Emulated LAN interfaces, a 1344 multicast frame or a unicast frame with unknown DA, it send a 1345 copy of the frame to each other VSI in the same Emulated LAN. 1346 This can be done by replicating the frame and sending a copy over 1347 each point-to-point PW. Alternatively, the full mesh of point- 1348 to-point PWs may be augmented with point-to-multipoint PWs, where 1349 each VSI in a VPLS is the transmitter on a single point-to- 1350 multipoint PW, and the receivers on that PW are all the other 1351 VSIs in that VPLS. 1353 - Tree Structured 1355 In a tree structured topology, every VSI in a particular VPLS is 1356 provisioned to be at a particular level in the tree. A given VSI 1357 has at most one pseudowire leading to a higher level. The root of 1358 the tree is considered to be the highest level. 1360 In this topology, loop free forwarding of frames is ensured by 1361 the following rule: if a frame is received over a pseudowire from 1362 a higher level, it may not be sent over a pseudowire that leads 1363 to a higher level. 1365 - Tree with Meshed Highest Level 1367 In this variant of the tree-structured topology, there may be 1368 more than one VSI at the highest level, but the set of VSIs which 1369 are at the highest level must be fully meshed. To ensure loop 1370 free forwarding, we need to impose the rule that a frame can be 1371 sent on a pseudowire to the same or higher level only if it 1372 arrived over a pseudowire from a lower level, and frames arriving 1373 over PWs from the same level cannot be sent on PWs to the same 1374 level. 1376 Other overlay topologies are also possible, e.g., an arbitrary 1377 partial mesh of PWs among the VSIs of a VPLS. Loop-freedom could 1378 then be assured by, for example, running spanning tree on the 1379 overlay. These topologies are not further considered in this 1380 framework. 1382 Note that loop freedom in the overlay topology does not necessarily 1383 ensure loop freedom in the overall customer LAN that contains the 1384 VPLS. It does not even ensure loop freedom among the PE bridge 1385 modules. It ensures only that when a frame is sent on the Emulated 1386 LAN, the frame will not loop endlessly before (or instead of) leaving 1387 the Emulated LAN. 1389 Improper configuration of the customer LAN or PE bridge modules may 1390 cause frames to loop, and frames that fall into such loops may 1391 transit the overlay topology multiple times. Procedures that enable 1392 the PE to detect and/or prevent such loops may be advisable. 1394 3.4.2. Provisioning and Auto-Discovery 1396 Each VPLS must be assigned a globally unique identifier. This can be 1397 thought of as a VPN-id. 1399 The ACs attaching the CEs to the PEs must be provisioned on both the 1400 PEs and the CEs. A VSI for that VPLS must be provisioned on the PE, 1401 and the local ACs of that VPLS must be associated with that VSI. The 1402 VSI must be provisioned with the identifier of the VPLS to which it 1403 belongs. 1405 An auto-discovery scheme may be used by a PE to map a VPLS identifier 1406 into the set of remote PEs that have VSIs in that VPLS. Once this 1407 set is determined, the PE can use pseudowire signaling to set up a PW 1408 to each of those VSIs. The VPLS identifier would serve as the 1409 signaling protocol's Forwarder Selector. This would result in a full 1410 mesh of PWs among the VSIs in a particular VPLS. 1412 If a single VPLS contains multiple VLANs, then it may be desirable to 1413 limit connectivity so that two VSIs are connected only if they have a 1414 VLAN in common. 1416 In this case, each VSI would need to be provisioned with one or more 1417 VLAN ids, and the auto-discovery scheme would need to map a VPLS 1418 identifier into pairs of . 1420 If a fully meshed topology of VSIs is not desired, then each VSI 1421 needs to be provisioned with additional information specifying its 1422 placement in the topology. This information would also need to be 1423 provided by the auto-discovery scheme. 1425 Alternatively, the single-sided provisioning method discussed in 1426 section 3.3.1.2 could be used. As this is more complicated, it would 1427 only be used if it were necessary to associate individual PWs with 1428 individual characteristics. For example, if different guaranteed 1429 bandwidths were needed between different pairs of sites within a 1430 VPLS, the PWs would have to be individually provisioned. 1432 3.4.3. Distributed PE 1434 Often when a VPLS type of service is provided, the CE devices attach 1435 to a provider-managed CPE device. This provider-managed CPE device 1436 may attach to CEs of multiple customers, especially if, e.g., there 1437 are multiple customers occupying the same building. However, this 1438 device is really part of the SP's network, hence may be considered to 1439 be a PE device. 1441 In some scenarios when a VPLS type of service is provided, the CE 1442 devices attach to a provider-managed intermediary device. This 1443 provider- managed device may attach to CEs of multiple customers. 1444 This may arise in a situation there multiple customers occupying the 1445 same building. This device is really part of the SP's network, and 1446 may for that reason be considered to be a PE device, however in the 1447 simplest case it is only performing aggregation and none of the 1448 function associated with a VPLS. 1450 Relative to the VPLS there are three different possibilities to 1451 allocate functions to a device in such a position in the provider 1452 network: 1454 - it can perform aggregation and pure Layer2 service only, in which 1455 case it does not really play the role of a PE device in a VPLS 1456 service. In this case the intermediary system must connect to 1457 devices that perform VPLS PE functionality; the intermediary 1458 device itself is not part of the VPLS architecture and has hence 1459 not been named in this architecture. 1461 - it can perform all the PE functions relevant for a VPLS, in such 1462 a case the device is called VPLS-PE, see [VPN-TERM]. This type of 1463 device will be connected to the core (P) routers. 1465 The PE functionality for a VPLS may be distributed between two 1466 devices, one "low-end" closer to the customer that performs e.g. the 1467 MAC-address learning and forwarding decisions, and one "high-end" 1468 that performs the control functions, e.g. establishing tunnels, PWs 1469 and VCs. We call the low-end device User-Facing PE (U-PE) and the 1470 high-end device Network- Facing PE (N-PE). 1472 It is conceivable that the U-PE may be placed very close to the 1473 customer, e.g. in a building with more than one customer. The N-PE 1474 will presumably be placed on the SP's premises. 1476 The distributed case is potentially of interest for a number of 1477 possible reasons: 1479 - The N-PE may be a device that cannot easily implement the VSI 1480 functionality described above. E.g., perhaps the N-PE is a router 1481 which cannot perform the high speed MAC learning that is needed 1482 in order to implement a VSI forwarder. At the same time, the U-PE 1483 may need to be a low-cost device that also cannot implement the 1484 full set of VPLS functions. 1486 This leads one to investigate further if there are sensible ways 1487 to split the VPLS PE functionality between the U-PE and the N-PE. 1489 - Generally, in the L2VPN architecture, the PEs are expected to 1490 participate as peers in the backbone routing protocol. Since the 1491 number of U-PEs is potentially very large relative to the number 1492 of N-PEs, this may be undesirable, as a matter of scaling the 1493 backbone routing protocol. 1495 - The U-PE may be a relatively inexpensive device that is unable to 1496 participate in the full range of signaling and/or auto-discovery 1497 procedures that are needed in order to provide the VPLS service. 1499 The VPLS functionality can be distributed between U-PE and N-PE in a 1500 number of different ways, and a number of different proposals have 1501 been made. They all presume that the U-PE will maintain a VSI 1502 forwarder, connected by PWs to the remote VSIs; the N-PE thus does 1503 not need to perform the VSI forwarding function. The proposals tend 1504 to differ with respect to the following questions: 1506 - Should the U-PEs perform full PW signaling to set up the PWs to 1507 remote VSIs? Or should the N-PEs do this signaling? 1509 Since the U-PEs need to be able to send packets on PWs to remote 1510 VSIs and receive packets on PWs from remote VSIs, if the PW 1511 signaling is done by the N-PE, there would have to be some form 1512 of "lightweight" (presumably) signaling between N-PE and U-PE 1513 that allows the PWs to be extended from N-PE to U-PE. 1515 - Should the U-PEs do their own auto-discovery, or should this be 1516 done by the N-PEs? In the latter case, the U-PEs may need to have 1517 some means of telling the N-PEs which VPLS's they are interested 1518 in, and the N-PEs must have some means of passing the results of 1519 the auto-discovery process to the U-PE. 1521 Whether it makes sense to split auto-discovery in this manner may 1522 depend on the particular auto-discovery protocol used. One would 1523 not expect the U-PEs to participate in a BGP-based auto-discovery 1524 scheme, e.g., but perhaps they would be expected to participate 1525 in a RADIUS-based auto-discovery scheme. 1527 - If a U-PE does not participate in routing, but is redundantly 1528 connected to two different N-PEs, can the U-PE still make an 1529 intelligent choice of the best N-PE to use as the "next hop" for 1530 traffic destined to a particular remote VSI? If not, can this 1531 choice be made as the result of some other sort of interaction 1532 between N-PE and U-PE? Or does this choice need to be established 1533 by provisioning? 1535 - If a U-PE does not participate in routing, but does participate 1536 in full PW signaling, and if MPLS is being used, how can the the 1537 N-PE send the the U-PEs the labels that the U-PE needs to send 1538 traffic to its signaling peers. (If the U-PE did participate in 1539 routing, this would happen automatically.) 1541 - When a frame must be multicast, should the replication be done by 1542 the N-PE or the U-PE? 1544 These questions are not all independent; the way one answers some 1545 of them may influence the way one answers others. 1547 3.4.4. Scaling issues in VPLS deployment 1549 In general, the PSN supports a VPLS solution with a tunnel from each 1550 VPLS-PE every other VPLS-PE participating in the same VPLS instance. 1551 Strictly, VPLS-PE's with more than one VPLS instance in common only 1552 need one tunnel, but for resource allocation reasons it might be 1553 necessary to establish several tunnels. For each VPLS service on a 1554 given VPLS-PE it needs to establish one pseudowire to every other 1555 VPLS-PE participating in that VPLS service. In total n*(n-1) 1556 pseudowires must be setup between the VPLS-PE routers. In large scale 1557 deployment this obviously creates scaling problems. One way to 1558 address the scaling problems is to use hierarchy. 1560 3.5. IP-only LAN-like Service (IPLS) 1562 If, instead of providing a general VPLS service, one wishes to 1563 provide a VPLS that is used only to connect IP routers or hosts 1564 (i.e., the CE devices are all assumed to be IP routers or hosts), 1565 then it is possible to make certain simplifications. 1567 In this environment, all Ethernet frames sent from a particular CE to 1568 a particular PE on a particular Attachment Circuit will have the same 1569 MAC Source Address. Thus rather than using address learning in the 1570 data plane to learn the MAC addresses, the PE can use the control 1571 plane to learn the MAC address. This allows the PE to be implemented 1572 on devices that are not capable of doing MAC address learning in the 1573 data plane. 1575 To eliminate the need for MAC address learning on the PWs as well as 1576 on the ACs, the pseudowire signaling protocol would have to carry the 1577 MAC address from one pseudowire endpoint to the other. Each PE would 1578 perform proxy ARP to its directly attached CEs. 1580 Eliminating the need to do MAC address learning on the PWs eliminates 1581 the need for the PWs to be point-to-point. Multipoint-to-point PWs 1582 could be used instead. 1584 Unlike a VPLS, all the ACs in an IPLS would not necessarily have to 1585 carry Ethernet frames; only the IP packets would need to be passed 1586 across the network, not their Layer2 wrappers. However, this might 1587 require "translation" between "ARP" and "Inverse ARP". The set of 1588 routing protocols which could be carried across the IPLS might also 1589 be restricted. 1591 4. Security Considerations 1593 The security considerations section of the L2VPN requirements 1594 document [L2VPN-REQ] addresses a number of areas that are potentially 1595 insecure aspects of the L2VPN. These relate to both control plane 1596 and data plane security issues that may arise in the following areas: 1598 - issues fully contained in the provider network 1600 - issues fully contained in the customer network 1602 - issues in the customer-provider interface network 1604 These three areas are addressed below. 1606 4.1. Provider Network Security Issues 1608 This section discusses security issues that only impact the SP's 1609 equipment. 1611 There are security issues having to do with the control connections 1612 that are used on a PE-PE basis for setting up and maintaining the 1613 pseudowires. 1615 A PE should not engage with another PE in a control connection unless 1616 it has some confidence that the peer is really a PE to which it 1617 should be setting up PWs. Otherwise L2PVN traffic may go to the 1618 wrong place. If control packets are maliciously and undetectably 1619 altered while in flight, denial of service, or alteration of the 1620 expected quality of service, may result. 1622 If peers discover each other dynamically (via some auto-discovery 1623 procedure), this presupposes that the auto-discovery procedures are 1624 themselves adequately trusted. 1626 PEs should not accept control connections from arbitrary entities; a 1627 PE should either be configured with its peers, or learn them from a 1628 trusted auto-configuration procedure. If the peer is required to be 1629 within the same SP's network, then access control filters at the 1630 borders of that network can be used to prevent spoofing of the peer's 1631 source address. If the peer is from another SP's network, then 1632 setting up such filters may be difficult or even impossible, 1633 depending on the way in which the two SPs are connected. Even if the 1634 access filters can be set up, the level of assurance which they 1635 provide will be lower. 1637 Thus for inter-SP control connections, it is advisable to use some 1638 sort of cryptographic authentication procedure. Control protocols 1639 which used TCP may use the TCP MD5 option to provide a measure of 1640 PE-PE authentication; this requires at least one shared secret 1641 between SPs. The use of IPsec between PEs is also possible, and 1642 provides a greater degree of assurance, though at a greater cost. 1644 Any other security considerations which apply to the control protocol 1645 in general will also apply when the control protocol is used for 1646 setting up PWs. If the control protocol uses UDP messages, it may be 1647 advisable to have some protection against spoofed UDP messages which 1648 appear to be from a valid peer; this requires further study. 1650 To limit the effect of Denial of Service attacks on a PE, some means 1651 of limiting the rate of processing of control plane traffic may be 1652 desirable. 1654 Unlike authentication and integrity, privacy of the signaling 1655 messages is not usually considered very important. If it is needed, 1656 the signaling messages can be sent through an IPsec connection. 1658 4.2. Provider-Customer Network Security Issues 1660 There are a number of security issues related to the access network 1661 between the provider and the customer. This is also traditionally a 1662 network that is hard to protect physically. 1664 Typical security issues on the provider-customer interface include 1665 the following: 1667 - Preventing unauthorized members joining an L2VPN 1669 - Ensuring correct customer interface configured 1671 - Ensuring correct service delimiting fields (VLAN, DLCI, etc.) 1673 - Preventing unauthorized access to PE 1675 As the access network for an L2VPN service is necessarily a layer 2 1676 network, it is preferable to use authentication mechanisms that do 1677 not presuppose any IP capabilities on the CE device. 1679 There are existing layer 2 protocols and best current practices to 1680 guard against these security issues. For example, IEEE 802.1x 1681 defines authentication at the link level for access through an 1682 ethernet bridge; the Frame Relay Forum defines LMI extensions for 1683 authentication (FRF.17). 1685 4.3. Customer Network Security Issues 1687 Even if all CE devices are properly authorized to attach to their PE 1688 devices, misconfiguration of the PE may interconnect CEs that are not 1689 supposed to be in the same L2VPN. 1691 In a VPWS, the CEs may run IPsec to authenticate each other. Other 1692 layer 3 or layer 4 protocols may have their own authentication 1693 methods. 1695 In a VPLS, CE-to-CE IPsec is even more problematic, as IPsec does not 1696 well support the multipoint configuration which is provided by the 1697 VPLS service. 1699 There may be alternative methods for achieving a degree of CE-to-CE 1700 authentication, if the L2VPN signaling protocol can carry opaque 1701 objects between the CEs, either inband (over the L2VPN), or out-of- 1702 band, through the participation of the signaling protocol. This is 1703 for further study. 1705 The L2VPN procedures do not provide authentication, integrity, or 1706 privacy for the customer's traffic; if this is needed, it becomes the 1707 responsibility of the customer. 1709 If there is CE-to-CE control traffic (e.g., BPDUs), on whose 1710 integrity the customer's own layer 2 network depends, it may be 1711 advisable to send the control traffic using some more secure 1712 mechanism than is used for the data traffic. 1714 5. Intellectual Property Notice 1716 The IETF takes no position regarding the validity or scope of any 1717 intellectual property or other rights that might be claimed to 1718 pertain to the implementation or use of the technology described in 1719 this document or the extent to which any license under such rights 1720 might or might not be available; neither does it represent that it 1721 has made any effort to identify any such rights. Information on the 1722 IETF's procedures with respect to rights in standards-track and 1723 standards-related documentation can be found in BCP-11. Copies of 1724 claims of rights made available for publication and any assurances of 1725 licenses to be made available, or the result of an attempt made to 1726 obtain a general license or permission for the use of such 1727 proprietary rights by implementors or users of this specification can 1728 be obtained from the IETF Secretariat. 1730 The IETF invites any interested party to bring to its attention any 1731 copyrights, patents or patent applications, or other proprietary 1732 rights which may cover technology that may be required to practice 1733 this standard. Please address the information to the IETF Executive 1734 Director. 1736 6. Copyright Notice 1738 "Copyright (C) The Internet Society (date). All Rights Reserved. 1740 This document and translations of it may be copied and furnished to 1741 others, and derivative works that comment on or otherwise explain it 1742 or assist in its implementation may be prepared, copied, published 1743 and distributed, in whole or in part, without restriction of any 1744 kind, provided that the above copyright notice and this paragraph are 1745 included on all such copies and derivative works. However, this 1746 document itself may not be modified in any way, such as by removing 1747 the copyright notice or references to the Internet Society or other 1748 Internet organizations, except as needed for the purpose of 1749 developing Internet standards in which case the procedures for 1750 copyrights defined in the Internet Standards process must be 1751 followed, or as required to translate it into languages other than 1752 English. 1754 The limited permissions granted above are perpetual and will not be 1755 revoked by the Internet Society or its successors or assigns. 1757 This document and the information contained herein is provided on an 1758 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1759 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1760 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1761 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1762 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1764 7. Normative References 1766 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 1767 Requirement Levels", RFC 2119, March 1997. 1769 8. Informative References 1771 [L2VPN-REQ] Augustyn, W. et.al "Service Requirements for Layer 2 1772 Provider Provisioned Virtual Private Networks", draft-ietf-l2vpn- 1773 requirements-00.txt, Work in Progress, May 2003. 1775 [PWE3-ARCH] Bryant, S., "PWE3 Architecture", draft-ietf-pwe3-arch- 1776 06.txt, Work in Progress, October 2003. 1778 [VPN-TERM] Andersson, L. and Madsen T. "VPN Terminology", draft- 1779 andersson-ppvpn-terminology-04.txt", Work in Progress, September 1780 2003. 1782 9. Authors and Acknowledgments 1784 This document is the outcome of discussions within a Layer 2 VPN 1785 design team, all of whose members could be considered to be co- 1786 authors. Specifically, the co-authors are Loa Andersson, Waldemar 1787 Augustyn, Marty Borden, Hamid Ould-Brahim, Juha Heinanen, Kireeti 1788 Kompella, Vach Kompella, Marc Lasserre, Pascal Menezes, Vasile 1789 Radoaca, Eric Rosen, and Tissa Senevirathne. 1791 The authors would like to thank Marco Carugi for cooperation in 1792 setting up context, working directions and taking time for 1793 discussions in this space, Tove Madsen for valuable input and 1794 reviews, and Norm Finn, Matt Squires, and Ali Sajassi for valuable 1795 discussion of the VPLS issues. 1797 10. Authors' Contact Information 1799 Loa Andersson 1800 Email: loa@pi.se 1802 Eric C. Rosen 1803 Cisco Systems, Inc. 1804 1414 Massachusetts Avenue 1805 Boxborough, MA 01719 1806 Email: erosen@cisco.com 1808 Waldemar Augustyn 1809 Email: waldemar@nxp.com 1810 Marty Borden 1811 mborden@acm.org 1813 Juha Heinanen 1814 Song Networks, Inc. 1815 Hallituskatu 16 1816 33200 Tampere, Finland 1817 Email: jh@song.fi 1819 Kireeti Kompella 1820 Juniper Networks, Inc. 1821 1194 N. Mathilda Ave 1822 Sunnyvale, CA 94089 1823 Email: kireeti@juniper.net 1825 Vach Kompella 1826 TiMetra Networks 1827 274 Ferguson Dr. 1828 Mountain View, CA 94043 1829 Email: vkompella@timetra.com 1831 Marc Lasserre 1832 Riverstone Networks 1833 5200 Great America Pkwy 1834 Santa Clara, CA 95054 1835 Email: marc@riverstonenet.com 1837 Pascal Menezies 1838 Email: pascalm1@yahoo.com 1840 Hamid Ould-Brahim 1841 Nortel Networks 1842 P O Box 3511 Station C 1843 Ottawa, ON K1Y 4H7, Canada 1844 Email: hbrahim@nortelnetworks.com 1845 Vasile Radoaca 1846 Nortel Networks 1847 600 Technology Park 1848 Billerica, MA 01821 1849 Email: vasile@nortelnetworks.com 1851 Tissa Senevirathne 1852 1567 Belleville Way 1853 Sunnyvale CA 94087 1854 Email: tsenevir@hotmail.com