idnits 2.17.1 draft-ietf-l2vpn-l2-framework-04.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 copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 159 has weird spacing: '...ols may not h...' == Line 1631 has weird spacing: '...k) one of th...' -- 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 (March 2004) is 7346 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) == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-requirements-00 ** Downref: Normative reference to an Informational draft: draft-ietf-l2vpn-requirements (ref. 'L2VPN-REQ') == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-arch-06 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-arch (ref. 'PWE3-ARCH') -- Possible downref: Normative reference to a draft: ref. 'VPN-TERM' -- Obsolete informational reference (is this intentional?): RFC 1771 (ref. 'BGP') (Obsoleted by RFC 4271) -- Obsolete informational reference (is this intentional?): RFC 2796 (ref. 'BGPRR') (Obsoleted by RFC 4456) -- Obsolete informational reference (is this intentional?): RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Loa Andersson 3 Internet Draft 4 Expiration Date: September 2004 Eric C. Rosen 5 Cisco Systems, Inc. 7 Editors 9 March 2004 11 Framework for Layer 2 Virtual Private Networks (L2VPNs) 13 draft-ietf-l2vpn-l2-framework-04.txt 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document provides a framework for Layer 2 Provider Provisioned 38 Virtual Private Networks (L2VPNs). This framework is intended to aid 39 in standardizing protocols and mechanisms to support interoperable 40 L2VPNs. 42 Table of Contents 44 1 Introduction ....................................... 3 45 1.1 Conventions used in this document .................. 3 46 1.2 Objectives and Scope of the Document ............... 3 47 1.3 Layer 2 Virtual Private Networks ................... 4 48 1.4 Terminology ........................................ 4 49 2 Models ............................................. 5 50 2.1 Reference Model for VPWS ........................... 5 51 2.1.1 Entities in the VPWS reference model ............... 5 52 2.2 Reference Model for VPLS ........................... 5 53 2.2.1 Entities in the VPLS reference model ............... 9 54 2.3 Reference Model for Distributed VPLS-PE or VPWS-PE . 9 55 2.3.1 Entities in the Distributed PE Reference Models .... 9 56 2.4 VPWS-PE and VPLS-PE ................................ 9 57 3 Functional Components of L2 VPN .................... 10 58 3.1 Types of L2VPN ..................................... 10 59 3.1.1 Virtual Private Wire Service (VPWS) ................ 10 60 3.1.2 Virtual Private LAN Service (VPLS) ................. 11 61 3.1.3 IP-only LAN-like Service (IPLS) .................... 11 62 3.2 Generic L2VPN Transport Functional Components ...... 12 63 3.2.1 Attachment Circuits ................................ 12 64 3.2.2 Pseudowires ........................................ 13 65 3.2.3 Forwarders ......................................... 14 66 3.2.4 Tunnels ............................................ 15 67 3.2.5 Encapsulation ...................................... 16 68 3.2.6 Pseudowire Signaling ............................... 17 69 3.2.6.1 Point-to-Point Signaling ........................... 18 70 3.2.6.2 Point-to-Multipoint Signaling ...................... 19 71 3.2.6.3 Inter-AS Considerations ............................ 20 72 3.2.7 Service Quality .................................... 21 73 3.2.7.1 Quality of Service (QoS) ........................... 21 74 3.2.7.2 Resiliency ......................................... 22 75 3.2.8 Management ......................................... 23 76 3.3 VPWS ............................................... 23 77 3.3.1 Provisioning and Auto-Discovery .................... 24 78 3.3.1.1 Attachment Circuit Provisioning .................... 24 79 3.3.1.2 PW Provisioning for Arbitrary Overlay Topologies ... 24 80 3.3.1.3 Colored Pools PW Provisioning Model ................ 26 81 3.3.2 Requirements on Auto-Discovery Procedures .......... 28 82 3.3.3 Heterogeneous Pseudowires .......................... 29 83 3.4 VPLS Emulated LANs ................................. 30 84 3.4.1 VPLS Overlay Topologies and Forwarding ............. 32 85 3.4.2 Provisioning and Auto-Discovery .................... 34 86 3.4.3 Distributed PE ..................................... 34 87 3.4.4 Scaling issues in VPLS deployment .................. 37 88 3.5 IP-only LAN-like Service (IPLS) .................... 37 89 4 Security Considerations ............................ 38 90 4.1 Provider Network Security Issues ................... 39 91 4.2 Provider-Customer Network Security Issues .......... 40 92 4.3 Customer Network Security Issues ................... 40 93 5 Authors and Acknowledgments ........................ 41 94 6 Authors' Contact Information ....................... 42 95 7 Normative References ............................... 43 96 8 Informative References ............................. 44 97 9 Intellectual Property Notice ....................... 44 98 10 Copyright Notice ................................... 45 100 1. Introduction 102 1.1. Conventions used in this document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC-2119 [RFC2119]. 108 1.2. Objectives and Scope of the Document 110 This document provides a framework for Layer 2 Provider Provisioned 111 Virtual Private Networks (L2VPNs). This framework is intended to aid 112 in standardizing protocols and mechanisms to support interoperable 113 L2VPNs. 115 The term "provider provisioned VPNs" refers to Virtual Private 116 Networks (VPNs) for which the Service Provider (SP) participates in 117 management and provisioning of the VPN. 119 Requirements for L2VPNs can be found in [L2VPN-REQ]. 121 This document provides reference models for L2VPNs, and discusses the 122 functional components of L2VPNs. Specifically, this includes 123 discussion of the technical issues which are important in the design 124 of standards and mechanisms for L2VPNs, including those standards and 125 mechanisms needed for interworking and security. 127 This document discusses a number of different technical approaches to 128 L2VPNs. It tries to show how the different approaches are related, 129 and to clarify the issues that may lead one to select one approach 130 rather than another. However, this document does not attempt to 131 select any particular approach. 133 1.3. Layer 2 Virtual Private Networks 135 There are two fundamentally different kinds of Layer 2 VPN service 136 that a service provider could offer to a customer: Virtual Private 137 Wire Service (VPWS) and Virtual Private LAN Service (VPLS). There is 138 also the possibility of an IP-only LAN-like Service (IPLS). 140 A VPWS is a VPN service that supplies a L2 point-to-point service. 141 Being a point-to-point service, there are very few scaling issues 142 with the service as such. Scaling issues might arise from the number 143 of end-points that can be supported on a particular PE. 145 A VPLS is an L2 service that emulates LAN service across a Wide Area 146 Network (WAN). With regard to the amount of state information that 147 must be kept at the edges in order to support the forwarding 148 function, it has the scaling characteristics of a LAN. Other scaling 149 issues might arise from the number of end-points that can be 150 supported on a particular PE. (See section 3.4.4.) 152 Note that VPLS uses a service which does not have native multicast 153 capability to emulate a service which does have native multicast 154 capability. As a result, there will be scalability issues with 155 regard to the handling of multicast traffic in VPLS. 157 A VPLS service may also impose longer delays, and provide less 158 reliable transport, than a native LAN service. The standard LAN 159 control protocols may not have been designed for such an 160 environment, and may experience scaling problems when run in that 161 environment. 163 1.4. Terminology 165 The list of the technical terms used when discussing L2VPNs may be 166 found in the companion document [VPN-TERM]. 168 2. Models 170 2.1. Reference Model for VPWS 172 The VPWS reference model is shown in Figure 1. 174 Attachment PSN Attachment 175 Circuits tunnel Circuits 176 + 177 +-----+ pseudo +-----+ 178 | | wire | | 179 | CE1 |--+ +--| CE2 | 180 | | | +-----+ +-----+ +-----+ | | | 181 +-----+ +----|---- | | P | | ----+----+ +-----+ 182 |VPWS\|---|-----|-----|/VPWS| 183 | PE1 |===|=====|=====| PE2 | 184 | /|---|-----|-----|\ | 185 +-----+ +----|---- | | | | ----|----+ +-----+ 186 | | | +-----+ +-----+ +-----+ | | | 187 | CE3 |--+ +--| CE4 | 188 | | | | 189 +-----+ +-----+ 191 Figure 1 193 2.1.1. Entities in the VPWS reference model 195 The P, PE (VPWS-PE) and CE devices and the PSN tunnel are defined in 196 [VPN-TERM]. Attachment circuit and pseudowire are discussed in 197 section 3. The PE does a simple mapping between the PW and attachment 198 circuit based on local information, i.e. the PW demultiplexor and 199 incoming/outgoing logical/physical port. 201 2.2. Reference Model for VPLS 203 The following diagram shows a VPLS reference model where PE devices 204 that are VPLS-capable provide a logical interconnect such that CE 205 devices belonging to a specific VPLS appear to be on a single bridged 206 Ethernet. A VPLS can contain a single VLAN or multiple, tagged VLANs. 208 The VPLS reference model is shown in Figures 2 and 3. 210 +-----+ +-----+ 211 + CE1 +--+ +---| CE2 | 212 +-----+ | ................... | +-----+ 213 VPLS A | +----+ +----+ | VPLS A 214 | |VPLS| |VPLS| | 215 +--| PE |--Routed---| PE |-+ 216 +----+ Backbone +----+ 217 / . | . \ _ /\_ 218 +-----+ / . | . \ / \ / \ +-----+ 219 + CE +--+ . | . +--\ Access \----| CE | 220 +-----+ . +----+ . | Network | +-----+ 221 VPLS B .....|VPLS|........ \ / VPLS B 222 | PE | ^ ------- 223 +----+ | 224 | | 225 | | 226 +-----+ | 227 | CE3 | +-- Emulated LAN 228 +-----+ 229 VPLS A 231 Figure 2 232 |-----Routed Backbone------| 233 | (P Routers) |PSN Tunnels, 234 Emulated LAN | |Pseudowires 235 ......................................................................... 236 . | | . 237 . |----------------------|----| |---------|-----------------| . 238 . | --------------------|--- | | -------|---------------- | . 239 . | VPLS Forwarder | | VPLS Forwarder | . 240 . | ----------|------------- | | ----------|------------- | . 241 ..|...................................................................|.. 242 | | Emulated LAN | | | Emulated LAN | 243 | | Interface | VPLS-PEs | | Interface | 244 | | | <----> | | | 245 | ----------|------------ | | ----------|------------ | 246 | | Bridge | | | | Bridge | | 247 | -|--------|---------|-- | | ---|-------|---------|- | 248 |---|--------|---------|----| |-----|-------|---------|---| 249 | | | | | | 250 | | Access | | | Access | 251 | | Networks| | | Networks| 252 | | | | | | 253 | | | | | | 254 CE devices CE devices 255 Figure 3 257 From Figure 3, we see that in VPLS, a CE device attaches, possibly 258 through an access network, to a "bridge" module of a VPLS-PE. Within 259 the VPLS-PE, the bridge module attaches, through an "Emulated LAN 260 Interface" to an Emulated LAN. For each VPLS, there is an Emulated 261 LAN instance. Figure 3 shows some internal structure to the Emulated 262 LAN: it consists of "VPLS Forwarder" modules connected by 263 pseudowires, where the pseudowires may be traveling through PSN 264 tunnels over a routed backbone. 266 A "VPLS instance" consists of a set of VPLS Forwarders (no more than 267 one per PE) connected by pseudowires. 269 The functionality which the bridge module must support depends on the 270 service which is being offered by the SP to its customers, as well as 271 on various details of the SP's network. At a minimum, the bridge 272 module must be able to learn MAC addresses, and to "age them out", in 273 the standard manner. However, if the PE devices have backdoor 274 connections with each other via a layer 2 network, they may need to 275 be full IEEE bridges ([IEEE8021D]), running spanning tree with each 276 other. Specification of the precise functionality which the bridge 277 modules must have in particular circumstances is, however, out of 278 scope of the current document. 280 This framework specifies that each "bridge module" has a single 281 "Emulated LAN interface". It does not specify the number of bridge 282 modules that a VPLS-PE may contain, nor does it specify the number of 283 VPLS instances which may attach to a bridge module over a single 284 "Emulated LAN interface". 286 Thus the framework is compatible with at least the following three 287 models: 289 - Model 1 291 A VPLS-PE contains a single bridge module, and supports a single 292 VPLS instance. The VPLS instance is an Emulated LAN; if that 293 Emulated LAN contains VLANs, 802.1Q [IEEE8021Q] tagging must be 294 used to indicate which packets are in which VLANs. 296 - Model 2 298 A VPLS-PE contains a single bridge module, but supports multiple 299 VPLS instances. Each VPLS instance is thought of as a VLAN (in 300 effect, an "Emulated VLAN"), and the set of VPLS instances are 301 treated as a set of VLANs on a common LAN. Since each VLAN uses 302 a separate set of PWs, there is no need for 802.1Q tagging. 304 - Model 3 306 A VPLS-PE contains an arbitrary number of bridge modules, each of 307 which attaches to a single VPLS instance. 309 There may be other models as well, some of which are combinations of 310 the 3 models above. Different models may have different 311 characteristics, and different scopes of applicability. 313 Each VPLS solution should specify the model or models that it is 314 supporting. Each solution should also specify the necessary bridge 315 functionality that its bridge modules must support. 317 This framework does not specify the way in which bridge control 318 protocols are used on the Emulated LANs. 320 2.2.1. Entities in the VPLS reference model 322 The PE (VPLS-PE) and CE devices are defined in [VPN-TERM]. 324 2.3. Reference Model for Distributed VPLS-PE or VPWS-PE 326 VPLS-PE/VPWS-PE 327 Functionality . . . . . . . 328 . . . . . . . . . . . . . 329 . . . . 330 +----+ . +----+ +----+ . . Service . 331 | CE |--.--|U-PE|----|N-PE|-.---. Provider . 332 +----+ . +----+ +----+ . . Backbone . 333 . . . . . . . . . . . . . 335 2.3.1. Entities in the Distributed PE Reference Models 337 A VPLS-PE or a VPWS-PE functionality may be distributed to more than 338 one device. The device closer to the customer/user is called User 339 facing PE (U-PE) and the device closer to the core network is called 340 Network facing PE (N-PE). 342 For further discussion see section 3.4.3. 344 The terms "U-PE" and "N-PE" are defined in [VPN-TERM]. 346 2.4. VPWS-PE and VPLS-PE 348 The VPWS-PE and VPLS-PE are functionally very similar, in that they 349 both use forwarders to map attachment circuits to pseudowires. The 350 only differences is that while the forwarder in a VPWS-PE does a 351 one-to-one mapping between the attachment circuit and pseudowire, the 352 forwarder in a VPLS-PE is a Virtual Switching Instance (VSI) that 353 maps multiple attachment circuits to multiple pseudowires (for 354 further discussion see section 3.) 356 3. Functional Components of L2 VPN 358 This section specifies a functional model for L2VPN, which allows one 359 to break an L2VPN architecture down into its functional components. 360 This allows us to exhibit the roles played by the various protocols 361 and mechanisms, and thus to make it easier to understand the 362 differences and similarities between various proposed L2VPN 363 architectures. 365 Section 3.1 contains an overview of some different types of L2VPNs. 366 In section 3.2, functional components that are common to the 367 different types are discussed. Then there is a section for each of 368 the L2VPN service types being considered. The latter sections discuss 369 functional components, which may be specific to particular L2VPN 370 types, as well as discussing type-specific features of the generic 371 components. 373 3.1. Types of L2VPN 375 The types of L2VPN are distinguished by the characteristics of the 376 service that they offer to the customers of the Service Provider 377 (SP). 379 3.1.1. Virtual Private Wire Service (VPWS) 381 In a VPWS, each CE device is presented with a set of point-to-point 382 virtual circuits. 384 The other end of each virtual circuit is another CE device. Frames 385 transmitted by a CE on such a virtual circuit are received by the CE 386 device at the other end-point of the virtual circuit. Forwarding from 387 one CE device to another is not affected by the content of the frame, 388 but is fully determined by the virtual circuit on which the frame is 389 transmitted. The PE thus acts as a virtual circuit switch. 391 This type of L2VPN has long been available over ATM and Frame Relay 392 backbones. Providing this type of L2VPN over MPLS and/or IP backbones 393 is the current topic. 395 Requirements for this type of L2VPN are specified in [L2VPN-REQ]. 397 3.1.2. Virtual Private LAN Service (VPLS) 399 In a VPLS, each CE device has one or more LAN interfaces that lead to 400 a "virtual backbone". 402 Two CEs are connected to the same virtual backbone if and only if 403 they are members of the same VPLS instance (i.e., same VPN). When a 404 CE transmits a frame, the PE that receives it examines the MAC 405 Destination Address field in order to determine how to forward the 406 frame. Thus the PE functions as a bridge. As is indicated in Figure 407 3, if a set of PEs support a common VPLS instance, then there is an 408 Emulated LAN, corresponding to that VPLS instance, to which each of 409 those PE bridges attaches (via an emulated interface). From the 410 perspective of a CE device, the virtual backbone is the set of PE 411 bridges and the Emulated LAN on which they reside. Thus to a CE 412 device, the LAN which attaches it to the PE is extended transparently 413 over the routed MPLS and/or IP backbone. 415 The PE bridge function treats the Emulated LAN as it would any other 416 LAN to which it has an interface. Forwarding decisions are made in 417 the manner which is normal for bridges, based on MAC Source Address 418 learning. 420 VPLS is like VPWS in that forwarding is done without any 421 consideration of the Layer3 header. VPLS is unlike VPWS in that: 423 - VPLS allows the PE to use addressing information in a frame's L2 424 header to determine how to forward the frame; 426 - VPLS allows a single CE/PE connection to be used for transmitting 427 frames to multiple remote CEs; in this particular respect, VPLS 428 resembles L3VPN more than VPWS. 430 Requirements for this type of L2VPN are specified in [L2VPN-REQ]. 432 3.1.3. IP-only LAN-like Service (IPLS) 434 An IPLS is very like a VPLS, except that: 436 - it is assumed that the CE devices are hosts or routers, not 437 switches 439 - it is assumed that the service will only carry IP packets, and 440 supporting packets such as ICMP and ARP (in the case of IPv4) or 441 Neighbor Discovery (in the case of IPv6); layer 2 packets which 442 do not contain IP are not supported. 444 While this service is a functional subset of the VPLS service, it is 445 considered separately because it may be possible to provide it using 446 different mechanisms, which may allow it to run on certain hardware 447 platforms that cannot support the full VPLS functionality. 449 3.2. Generic L2VPN Transport Functional Components 451 All L2VPN types must transport "frames" across the core network 452 connecting the PE's. In all L2VPN types, a PE (PE1) receives a frame 453 from a CE (CE1), then transports the frame to a PE (PE2), which then 454 transports the frame to a CE (CE2). In this section, we discuss the 455 functional components, which are necessary to transport L2 frames in 456 any type of L2VPN service. 458 3.2.1. Attachment Circuits 460 In any type of L2VPN, a CE device attaches to a PE device via some 461 sort of circuit or virtual circuit. We will call this an "Attachment 462 Circuit" (AC). We use this term very generally; an Attachment Circuit 463 may be a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, 464 a PPP connection on a physical interface, a PPP session from an L2TP 465 tunnel, an MPLS LSP, etc. The CE device may be a router, a switch, a 466 host, or just about anything, which the customer needs hooked up to 467 the VPN. An AC carries a frame between CE and PE, or vice versa. 469 Procedures for setting up and maintaining the ACs are out of scope of 470 this architecture. 472 These procedures are generally specified as part of the specification 473 of the particular Attachment Circuit technology. 475 Any given frame will traverse an AC from a CE to a PE and then on 476 another AC from a PE to a CE. 478 We refer to the former AC as the frame's "ingress AC" and to the 479 latter AC as the frame's "egress AC". Note that this notion of 480 "ingress AC" and "egress AC" is relative to a specific frame, and 481 denotes nothing more than the frame's direction of travel while on 482 that AC. 484 3.2.2. Pseudowires 486 A "Pseudowire" (PW) is a relation between two PE devices. Whereas an 487 AC is used to carry a frame from CE to PE, a PW is used to carry a 488 frame between two PEs. We use the term "pseudowire" in the sense of 489 [PWE3-ARCH]. 491 Setting up and maintaining the PWs is the job of the PEs. State 492 information for a particular PW is maintained at the two PEs which 493 are its endpoints, but not at other PEs, and not in the backbone 494 routers (P routers). 496 Pseudowires may be point-to-point, multipoint-to-point, or point-to- 497 multipoint. In this framework, point-to-point PWs are always 498 considered to be bidirectional; multipoint-to-point and point-to- 499 multipoint PWs are always considered to be unidirectional. 500 Multipoint-to-point PWs can be used only when the PE receiving a 501 frame does not need to infer, from the PW on which the frame was 502 received, the identity of the frame's ingress AC. Point-to- 503 multipoint PWs may be useful when frames need to be multicast. 505 Procedures for setting up and maintaining point-to-multipoint PWs are 506 not considered in this version of this framework. 508 Any given frame travels first on its ingress AC, then on a PW, then 509 on its egress AC. 511 Multicast frames may be replicated by a PE, so of course the 512 information carried in multicast frames may travel on more than one 513 PW and more than one egress AC. 515 Thus with respect to a given frame, a PW may be said to associate a 516 number of ACs. If these ACs are of the same technology (e.g., both 517 ATM, both Ethernet, both Frame Relay) the PW is said to provide 518 "homogeneous transport"; otherwise it is said to provide 519 "heterogeneous transport". Heterogeneous transport requires that some 520 sort of interworking function be applied. There are at least three 521 different approaches to interworking: 523 1. One of the CEs may perform the interworking locally. For 524 example, if CE1 attaches to PE1 via ATM, but CE2 attaches to 525 PE2 via Ethernet, then CE1 may decide to send/receive Ethernet 526 frames over ATM, using the RFC2684 "LLC Encapsulation for 527 Bridged Protocols". In such a case, PE1 would need to know 528 that it is to terminate the ATM VC locally, and only 529 send/receive Ethernet frames over the PW. 531 2. One of the PEs may perform the interworking. For example, if 532 CE1 attaches to PE1 via ATM, but CE2 attaches to PE2 via Frame 533 Relay, PE1 may provide the "ATM/FR Service Interworking" 534 function. This would be transparent to the CEs, and the PW 535 would carry only Frame Relay frames. 537 3. IPLS could be used. In this case the "frames" carried by the 538 PW are IP datagrams, and the two PEs need to cooperate in order 539 to spoof various L2-specific procedures used by IP (see section 540 3.5). 542 If heterogeneous PWs are used, the setup protocol must ensure that 543 each endpoint knows the MTU of the remote AC. If the two ACs do not 544 have the same MTU, one of the following three procedures must be 545 carried out: 547 - The PW is not allowed to come up. 549 - The endpoint at the AC with the larger MTU must reduce the AC's 550 MTU so that it is the same as the MTU of remote AC. 552 - The two endpoints must agree to use a specified 553 fragmentation/reassembly procedure. 555 3.2.3. Forwarders 557 In all types of L2VPN, a PE, say PE1, receives a frame over an AC, 558 and forwards it over a PW to another PE, say PE2. PE2 then forwards 559 the frame out on another AC. 561 The case in which PE1 and PE2 are the same device is an important 562 case to handle correctly, in order to provide the L2VPN service 563 properly. However, as this case does not require any protocol, we do 564 not further address it in this document. 566 When PE1 receives a frame on a particular AC, it must determine the 567 PW on which the frame must be forwarded. In general, this is done by 568 considering: 570 - the incoming AC, 572 - possibly the contents of the frame's Layer2 header, and 573 - possibly some forwarding information which may be statically or 574 dynamically maintained. 576 If dynamic or static forwarding information is considered, the 577 information is specific to a particular L2VPN instance (i.e., to a 578 particular VPN). 580 Similarly, when PE2 receives a frame on a particular PW, it must 581 determine the AC on which the frame must be forwarded. This is done 582 by considering: 584 - the incoming PW, 586 - possibly the contents of the frame's Layer2 header, and 588 - possibly some forwarding information which may be statically or 589 dynamically maintained. 591 If dynamic or static forwarding information is considered, the 592 information is specific to a particular L2VPN instance (i.e. to a 593 particular VPN). 595 The procedures used to make the forwarding decision are known as a 596 "forwarder". We may think of a PW as being "bound", at each of its 597 endpoints, to a forwarder. The forwarder in turn "binds" the PWs to 598 ACs. Different types of L2VPN have different types of forwarders. 600 For instance, a forwarder may bind a single AC to a single PW, 601 ignoring all frame contents and using no other forwarding 602 information. Or a forwarder may bind an AC to a set of PWs and ACs, 603 moving individual frames from AC to PW, from a PW to an AC or from AC 604 to AC by comparing information from the frame's Layer2 header to 605 information in a forwarding database. This is discussed in more 606 detail below, as we consider the different L2VPN types. 608 3.2.4. Tunnels 610 A PW is carried in a "tunnel" from PE1 to PE2. We assume that an 611 arbitrary number of PWs may be carried in a single tunnel; the only 612 requirement is that the PWs all terminate at PE2. 614 We do not even require that all the PWs in the tunnel originate at 615 PE1; the tunnels may be multipoint-to-point tunnels. Nor do we 616 require that all PWs between the same pair of PEs travel in the same 617 tunnel. All we require is that when a frame traveling through such a 618 tunnel arrives at PE2, PE2 will be able to associate it with a 619 particular PW. 621 (While one can imagine tunneling techniques that only allow one PW 622 per tunnel, they have evident scalability problems, and we do not 623 consider them further.) 625 There are a variety of different tunneling technologies which may be 626 used for the PE-PE tunnels. All that is really required is that the 627 tunneling technologies allow the proper demultiplexing of the 628 contained PWs. The tunnels might be MPLS LSPs, L2TP tunnels, IPsec 629 tunnels, MPLS-in-IP tunnels, etc. Generally the tunneling technology 630 will require the use of an encapsulation that contains a 631 demultiplexor field, where the demultiplexor field is used to 632 identify a particular PW. Procedures for setting up and maintaining 633 the tunnels are not within the scope of this framework. (But see 634 section 3.2.6, "Pseudowire Signaling".) 636 If there are multiple tunnels from PE1 to PE2, it may be desirable to 637 assign a particular PE1-PE2 PW to a particular tunnel based on some 638 particular characteristics of the PW and/or the tunnel. For example, 639 perhaps different tunnels are associated with different QoS 640 characteristics, and different PWs require different QoS. Procedures 641 for specifying how to assign PWs to tunnels are out of scope of the 642 current framework. 644 Though point-to-point PWs are bidirectional, the tunnels in which 645 they travel need not be either bidirectional or point-to-point. For 646 example, a point-to-point PW may travel within a unidirectional 647 multipoint-to-point MPLS LSP. 649 3.2.5. Encapsulation 651 As L2VPN packets are carried in pseudowires, standard pseudowire 652 encapsulation formats and techniques (as specified by the IETF's PWE3 653 WG) should be used wherever applicable. 655 Generally the PW encapsulations will themselves be encapsulated 656 within a tunnel encapsulation, as determined by the specification of 657 the tunneling protocol. 659 It may be necessary to define additional PW encapsulations to cover 660 areas that are of importance for L2VPN, but may not be within the 661 scope of PWE3. Heterogeneous transport may be an instance of this. 663 3.2.6. Pseudowire Signaling 665 Procedures for setting up and maintaining the PWs themselves are 666 within the scope of this framework. This includes procedures for 667 distributing demultiplexor field values, even though the 668 demultiplexor field, strictly speaking, belongs to the tunneling 669 protocol rather than to the PW. 671 The signaling for a point-to-point pseudowire must perform the 672 following functions: 674 - Distribution of the demultiplexor. 676 Since many PWs may be carried in a single tunnel, the tunneling 677 protocol must assign a demultiplexor value to each PW. These 678 demultiplexors must be unique with respect to a given tunnel (or 679 with some tunneling technologies, unique at the egress PE). 680 Generally, the PE which is the egress of the tunnel will select 681 the demultiplexor values, and will distribute them to the PE(s) 682 which is (are) the ingress(es) of the tunnel. This is the 683 essential part of the PW setup procedure. 685 Note that, as is usually the case in tunneling architectures, the 686 demultiplexor field belongs to the tunneling protocol, not to the 687 protocol being tunneled. For this reason, the PW setup protocols 688 may be extensions of the control protocols for setting up the 689 tunnels. 691 - Selection of the Forwarder at the Remote PE. 693 The signaling protocol must contain enough information to enable 694 the remote PE to select the proper forwarder to which the PW is 695 to be bound. We can call this information the "Remote Forwarder 696 Selector". The information that is required will depend on the 697 type of L2VPN being provided and on the provisioning model (see 698 sections 3.3.1 and 3.4.2) being used. The Remote Forwarder 699 Selector may uniquely identify a particular Forwarder, or it may 700 identify an attribute of Forwarders. In the latter case, it would 701 select whichever Forwarder has been provisioned with that 702 attribute. 704 - Support pseudowire emulations. 706 To the extent that a particular PW must emulate the signaling of 707 a particular Layer2 technology, the PW signaling must provide the 708 necessary functions. 710 - Distribution of State Changes. 712 Changes in the state of an AC may need to be reflected in changes 713 to the state of the PW to which the AC is bound, and vice versa. 714 The specification as to which changes need to be reflected in 715 what way would generally be within the province of the PWE3 WG. 717 - Establish pseudowire characteristics. 719 To the extent that one or more characteristics of a PW must be 720 known to and/or agreed upon by both endpoints, the signaling must 721 allow for the necessary interaction. 723 As specified above, signaling for point-to-point PWs must pass enough 724 information to allow a remote PE to properly bind a PW to a 725 Forwarder, and to associate a particular demultiplexor value with 726 that PW. Once the two PEs have done the proper PW/Forwarder bindings, 727 and have agreed on the demultiplexor values, the PW may be considered 728 to have been set up. If it is necessary to negotiate further 729 characteristics or parameters of a particular PW, or to passing 730 status information for a particular PW, the PW may be identified by 731 the demultiplexor value. 733 Signaling procedures for point-to-point pseudowires are most commonly 734 point-to-point procedures that are executed by the two PW endpoints. 735 There are however proposals to use point-to-multipoint signaling for 736 setting up point-to-point pseudowires, so this is included in the 737 framework. When PWs are themselves point-to-multipoint, it is also 738 possible to use either point-to-point signaling or point-to- 739 multipoint signaling to set them up. This is discussed in the 740 remainder of this section. 742 3.2.6.1. Point-to-Point Signaling 744 There are several ways to do the necessary point-to-point signaling. 745 Among them are: 747 - LDP 749 LDP [LDP] extensions can be defined for pseudowire signaling. 750 This form of signaling can be used for pseudowires which are to 751 be carried in MPLS "tunnels", or in MPLS-in-something-else 752 tunnels. 754 - L2TP 756 L2TP [L2TP] can be used for pseudowire signaling, resulting in 757 pseudowires that are carried as "sessions" within L2TP tunnels. 758 Pseudowire-specific extensions to L2TP may also be needed. 760 Other methods may be possible as well. 762 It is possible to have one control connection between a pair of PEs, 763 which is used to control many PWs. 765 The use of point-to-point signaling for setting up point-to-point PWs 766 is straightforward. Multipoint-to-point PWs can also be set up by 767 point-to-point signaling, as the remote PEs do not necessarily need 768 to know whether the PWs are multipoint-to-point or point-to-point. 769 In some signaling procedures, the same demultiplexor value may be 770 assigned to all the remote PEs. 772 3.2.6.2. Point-to-Multipoint Signaling 774 Consider the following situation: 776 - It is necessary to set up a set of PWs, all of which have the 777 same characteristics. 779 - It is not necessary to use the PW signaling protocol to pass PW 780 state changes. 782 - For each PW in the set, the same value of the Remote Forwarder 783 Selector can be used. 785 Call these the "Environmental Conditions". 787 Suppose also that there is some mechanism by which, given a range of 788 demultiplexor values, each of a set of PEs can make a unique and 789 deterministic selection of a single value from within that range. 790 Call this the "Demultiplexor Condition". Alternatively, suppose that 791 one is trying to set up a multipoint-to-point PW rather than a 792 point-to-point PW. Call this the "Multipoint Condition". 794 If: 796 - The Environmental Conditions hold, and 797 - Either 799 * the Demultiplexor Condition holds, or 801 * the Multipoint Condition holds, 803 then for a given set of PWs which terminate at egress PE1, the 804 information which PE1 needs to send to the ingress PE(s) of each 805 pseudowire in the set is exactly the same. All the ingress PE(s) 806 receive the same Forwarder Selector value. They all receive the same 807 set of PW parameters (if any). And either they all receive the same 808 demultiplexor value (if the PW is multipoint-to-point) or they all 809 receive a range of demultiplexor values from which each can choose a 810 unique demultiplexor value for itself. 812 Rather than connecting to each ingress PE and replicating the same 813 information, it may make sense either to multicast the information, 814 or to send the information once to a "reflector", which will then 815 take responsibility for distributing the information to the other 816 PEs. 818 We refer to this sort of technique as "point-to-multipoint" 819 signaling. It would, for example, be possible to use BGP [BGP] to do 820 the signaling, with the PEs being BGP peers not of each other, but of 821 one or more BGP route reflectors [BGPRR]. 823 3.2.6.3. Inter-AS Considerations 825 Pseudowires may need to run from a PE in one Service Provider's 826 network to a PE in another Service Provider's network. This has the 827 following implications: 829 - The signaling protocol that sets up the PWs must be able to cross 830 network boundaries. Of course, all IP-based protocols have this 831 capability. 833 - The two PEs at the PW endpoints must be addressable and routable 834 from each other. 836 - The signaling protocol needs to allow each PW endpoint to 837 authenticate the other. 839 3.2.7. Service Quality 841 Service Quality refers to the ability for the network to deliver a 842 Service level Specification (SLS) for service attributes such as 843 protection, security and Quality of Service (QoS). The service 844 quality provided depends on the subscriber's requirements, and can be 845 characterized by a number of performance metrics. 847 The necessary Service Quality must be provided on the ACs as well as 848 on the PWs. Mechanisms for providing Service Quality on the PWs may 849 be PW-specific or tunnel-specific; in the latter case, the assignment 850 of a PW to a tunnel may depend on the Service Quality. 852 3.2.7.1. Quality of Service (QoS) 854 QoS describes the queuing behavior applied to a particular "flow", in 855 order to achieve particular goals of precedence, throughput, delay, 856 jitter, etc. 858 Based on the customer Service Level Agreement (SLA), traffic from a 859 customer can be prioritized, policed and shaped for QoS requirements. 860 The queuing and forwarding policies can preserve the packet order and 861 QoS parameters of customer traffic. The class of services can be 862 mapped from information in the customer frames, or it can be 863 independent of the frame content. 865 QoS functions can be listed as follows: 867 - Customer Traffic Prioritization: L2VPN services could be best 868 effort or QoS guaranteed. Traffic from one customer might need to 869 be prioritized over others when sharing same network resources. 870 This requires capabilities within the L2VPN solution to classify 871 and mark priority to QoS guaranteed customer traffic. 873 - Proper queuing behavior would be needed at the egress AC, and 874 possibly within the backbone network as well. If queuing behavior 875 must be controlled within the backbone network, the control might 876 be based on CoS information in the MPLS or IP header, or it might 877 be achieved by nesting particular tunnels within particular 878 traffic engineering tunnels. 880 - Policing: This ensures that a user of L2VPN services uses network 881 resources within the limits of the agreed SLA. Any excess L2VPN 882 traffic can be rejected or handled differently based on provider 883 policy. 885 - Policing would generally be applied at the ingress AC. 887 - Shaping: Under some cases the random nature of L2VPN traffic 888 might lead to sub-optimal utilization of network resources. 889 Through queuing and forwarding mechanisms the traffic can be 890 shaped without altering the packet order. 892 - Shaping would generally be applied at the ingress AC. 894 3.2.7.2. Resiliency 896 Resiliency describes the ability of the L2VPN infrastructure to 897 protect a flow from network outage, so that service remains available 898 in the presence of failures. 900 L2VPN, like any other service, is subject to failures such as link, 901 trunk and node failures, both in the SP's core network infrastructure 902 and on the ACs. 904 It is desirable that the failure be detected "immediately" and 905 protection mechanisms allow fast restoration times to make L2VPN 906 service almost transparent to these failures to the extent possible, 907 based on the level of resiliency. Restoration should take place 908 before the CEs can react to the failure. Essential aspects of 909 providing resiliency are: 911 - Link/Node failure detection: Mechanisms within the L2VPN service 912 should allow for link or node failures that impact the Service, 913 and should be detected immediately. 915 - Resiliency policy: The way in which a detected failure is handled 916 will depend upon the restoration policy of the SLA associated 917 with the L2VPN service specification. It may need to be handled 918 immediately, or it may need to be handled only if no other 919 critical failure needs protection resources, or it may be 920 completely ignored if it is within the bounds of the "acceptable 921 downtime" allowed by the L2VPN service. 923 - Restoration Mechanisms: The L2VPN solutions could allow for 924 physical level protection, logical level protection or both. For 925 example, by connecting customers over redundant and physically 926 separate ACs to different provider customer-facing devices, one 927 AC can be maintained as active while the other could be marked as 928 a backup; upon the failure detection across the primary AC, the 929 backup could become active. 931 To a great extent, resiliency is a matter of having appropriate 932 failure and recovery mechanisms in the network core, including 933 "ordinary" adaptive routing as well as "fast reroute" capabilities. 934 The ability to support redundant ACs between CEs and PEs also plays a 935 role. 937 3.2.8. Management 939 An L2VPN solution can provide mechanisms to manage and monitor 940 different L2VPN components. From a Service Level Agreement (SLA) 941 perspective, L2VPN solutions could allow monitoring of L2VPN service 942 characteristics and offer mechanisms used by Service Providers to 943 report such monitored statistical data. Trouble-shooting and 944 verification of operational and maintenance activities of L2VPN 945 services are essential requirements for Service Providers. 947 3.3. VPWS 949 A VPWS is an L2VPN service in which each forwarder binds exactly one 950 AC to exactly one PW. Frames received on the AC are transmitted on 951 the PW; frames received on the PW are transmitted on the AC. The 952 content of a frame's Layer2 header plays no role in the forwarding 953 decision, except insofar as the Layer2 header contents are used to 954 associate the frame with a particular AC (as, e.g., the DLCI field of 955 a Frame Relay frame identifies the AC). 957 A particular combination of forms a "virtual circuit" 958 between two CE devices. 960 A particular VPN (VPWS instance) may be thought of as a collection of 961 such virtual circuits, or as an "overlay" of PWs on the MPLS or IP 962 backbone. This creates an overlay topology that is in effect the 963 "virtual backbone" of a particular VPN. 965 Whether two virtual circuits are said to belong to the same VPN or 966 not is an administrative matter, based on the agreements between the 967 SPs and their customers. This may impact the provisioning model 968 (discussed below). It may also affect how particular PWs are 969 assigned to tunnels, the way QoS is assigned to particular ACs and 970 PWs, etc. 972 Note that VPWS makes use of point-to-point PWs exclusively. 974 3.3.1. Provisioning and Auto-Discovery 976 Provisioning a VPWS is a matter of: 978 1. Provisioning the ACs 980 2. Providing the PEs with the necessary information to enable them 981 to set up PWs between ACs to result in the desired overlay 982 topology. 984 3. Configuring the PWs with any necessary characteristics 986 3.3.1.1. Attachment Circuit Provisioning 988 In many cases, the ACs must be individually provisioned on the PE 989 and/or CE. This will certainly be the case if the CE/PE attachment 990 technology is a switched network, such as ATM or FR, and the VCs are 991 PVCs rather than SVCs. It is also the case whenever the individual 992 Attachment Circuits need to be given specific parameters (e.g., QoS 993 parameters, guaranteed bandwidth parameters) that differ from circuit 994 to circuit. 996 There are also cases in which ACs might not have to be individually 997 provisioned. E.g., if an AC is just an MPLS LSP running between a CE 998 and a PE, it could be set up as the RESULT of a PW being set up, 999 rather than having to be provisioned BEFORE the PW can be set up. The 1000 same may apply whenever the AC is a Switched Virtual Circuit of any 1001 sort, though in this case, various policy controls might need to be 1002 provisioned, e.g., limiting the number of ACs that can be set up 1003 between a given CE and a given PE. 1005 Issues such as whether the Attachment Circuits need to be 1006 individually provisioned or not, whether they are Switched VCs or 1007 Permanent VCs, and what sorts of policy controls may be applied, are 1008 implementation and deployment issues, and are considered to be out of 1009 scope of this framework. 1011 3.3.1.2. PW Provisioning for Arbitrary Overlay Topologies 1013 In order to support arbitrary overlay topologies, it is necessary to 1014 allow the provisioning of individual PWs. In this model, when a PW 1015 is provisioned on a PE device, it is locally bound to a specific AC. 1016 It is also provisioned with information that identifies a specific AC 1017 at a remote PE. 1019 There are basically two variations of this provisioning model: 1021 - Two-sided provisioning 1023 With two-sided provisioning, each PE that is at the end of a PW 1024 is provisioned with the following information: 1026 * Identifier of the Local AC to which the PW is to be bound 1028 * PW type and parameters 1030 * IP address of the remote PE (i.e., the PE which is to be at 1031 the remote end of the PW) 1033 * Identifier which is meaningful to the remote PE, and which 1034 can be passed in the PW signaling protocol to enable the 1035 remote PE to bind the PW to the proper AC. This can be an 1036 identifier of the PW or an identifier of the remote AC. If a 1037 PW identifier is used, it must be unique at each of the two 1038 PEs. If an AC identifier is used, it need only be unique at 1039 the remote PE. 1041 This identifier is then used as the Remote Forwarder Selector 1042 when signaling is done (see 3.2.6.1). 1044 - Single-sided Provisioning 1046 With single sided provisioning, a PE at one end of a PW is 1047 provisioned with the following information: 1049 * Identifier of the Local AC to which the PW is to be bound 1051 * PW type and parameters 1053 * Globally unique identifier of remote AC 1055 This identifier is then used as the Forwarder Selector when 1056 signaling is done (see section 3.2.6.1). 1058 In this provisioning model, the IP address of the remote PE is 1059 not provisioned. Rather, the assumption is that an auto- 1060 discovery scheme will be used to map the globally unique 1061 identifier to the IP address of the remote PE, along with an 1062 identifier (perhaps unique only at the latter PE) for an AC at 1063 that PE. The PW signaling protocol can then make a connection to 1064 the remote PE, passing the AC identifier, so that the remote PE 1065 binds the PW to the proper AC. 1067 This scheme requires provisioning of the PW at only one PE, but 1068 does not eliminate the need (if there is a need) to provision the 1069 ACs at both PEs. 1071 These provisioning models fit well with the use of point-to-point 1072 signaling. When each PW is individually provisioned, as the 1073 conditions necessary for the use of point-to-multipoint signaling do 1074 not hold. 1076 3.3.1.3. Colored Pools PW Provisioning Model 1078 Suppose that at each PE, sets of ACs are gathered together into 1079 "pools", and that each such pool is assigned a "color". (For 1080 example, a pool might contain all and only the ACs from this PE to a 1081 particular CE.) Now suppose we impose the following rule: whenever 1082 PE1 and PE2 have a pool of the same color, there will be a PW between 1083 PE1 and PE2 which is bound at PE1 to an arbitrarily chosen AC from 1084 that pool, and at PE2 to an arbitrarily chosen AC from that pool. 1085 (We do not rule out the case where a single PE has multiple pools of 1086 a given color.) 1088 For example, each pool in a particular PE might represent a 1089 particular CE device, with the ACs in the pool being the ACs 1090 connecting that CE to that PE. The color might be a VPN-id. 1091 Application of this provisioning model would then lead to a full CE- 1092 to-CE mesh within the VPN, where every CE in the VPN has a virtual 1093 circuit to every other CE within the VPN. 1095 More specifically, to provision VPWS according to this model, one 1096 provisions a set of pools, and configures each pool with the 1097 following information: 1099 - The set of ACs that belong to the pool (with no AC belonging to 1100 more than one pool) 1102 - The color 1104 - A pool identifier that is unique at least relative to the color. 1106 An auto-discovery procedure is then used to map each color into a 1107 list of ordered pairs . The 1108 occurrence of a pair on this list means that the PE at IP 1109 address X has a pool with pool id Y which is of the specified 1110 color. 1112 This information can be used to support several different 1113 signaling techniques. One possible technique proceeds as 1114 follows: 1116 - A PE finds that it has a pool of color C. 1118 - Using auto-discovery, it obtains the set of ordered pairs 1119 for color C. 1121 - For each such pair , it: 1123 * removes an AC from the pool 1125 * binds the AC to a particular PW 1127 * signals PE X via point-to-point signaling that the PW is to 1128 be bound to an AC from pool Y. 1130 Another possible signaling technique is the following: 1132 - A PE finds that it has a pool of color C, containing n ACs. 1134 - It binds each AC to a PW, creating a set of PWs. This set of PWs 1135 is then organized into a sequence. (For instance, each PW may be 1136 associated with a demultiplexor field value, and the PWs may then 1137 be sequenced according to the numerical value of their respective 1138 demultiplexors.) 1140 - Using auto-discovery, it obtains the list of PE routers that have 1141 one or more pools of color C. 1143 - It signals each such PE router, specifying the sequence Q of PWs. 1145 - If PE X receives such a signal, and PE X has a pool Y of the 1146 specified color, it: 1148 * removes an AC from the pool 1150 * binds the AC to the PW which is the "Yth" PW in the sequence 1151 Q. 1153 This presumes, of course, that the pool identifiers are or can be 1154 uniquely mapped into small ordinal numbers; assigning the pool 1155 identifiers in this way becomes a requirement of the provisioning 1156 system. 1158 Note that since this technique signals the same information to all 1159 the remote PEs, it can be supported via point-to-multipoint 1160 signaling. 1162 This provisioning model can be applied as long as the following 1163 conditions hold: 1165 - There is no need to provision different characteristics for the 1166 different PWs, and 1168 - It makes no difference which pairs of ACs are bound together by 1169 PWs, as long as both ACs in the pair come from like-colored 1170 pools, and 1172 - It is possible to construct the desired overlay topology simply 1173 by assigning colors to the pools. (This is certainly simple if a 1174 full mesh is desired, or if a hub and spoke configuration is 1175 desired; creating arbitrary topologies is less simple, and 1176 perhaps not always possible.) 1178 3.3.2. Requirements on Auto-Discovery Procedures 1180 Some of the requirements for auto-discovery procedures can be deduced 1181 from the above. 1183 To support the single-sided provisioning model, auto-discovery must 1184 be able to map a globally unique identifier (of a PW or of an 1185 Attachment Circuit) to an IP address of a PE. 1187 To support the colored pools provisioning model, auto-discovery must 1188 enable a PE to determine the set of other PEs that contain pools of 1189 the same color. 1191 These requirements enable the auto-discovery scheme to provide the 1192 information, which the PEs need to set up the PWs. 1194 There are additional requirements on the auto-discovery procedures 1195 that cannot simply be deduced from the provisioning model: 1197 - Particular signaling schemes may require additional information 1198 before they can proceed, and hence may impose additional 1199 requirements on the auto-discovery procedures. 1201 - A given Service Provider may support several different types of 1202 signaling procedures, and thus the PEs may need to learn, via 1203 auto- discovery, which signaling procedures to use. 1205 - Changes in the configuration of a PE should be reflected by the 1206 auto-discovery procedures, within a timely manner, and without 1207 the need to explicitly reconfigure any other PE. 1209 - The auto-configuration procedures must work across service 1210 provider boundaries. This rules out, e.g., the use of schemes 1211 that piggyback the auto-discovery information on the backbone's 1212 IGP. 1214 3.3.3. Heterogeneous Pseudowires 1216 Under certain circumstances, it may be desirable to have a PW that 1217 binds two ACs that use different technologies (e.g., one is ATM, one 1218 is Ethernet). There are a number of different ways, depending on the 1219 AC types, in which this can be done. For example: 1221 - If one AC is ATM and one is FR, then standard ATM/FR Network 1222 Interworking can be used. In this case, the PW might be signaled 1223 for ATM, with the Interworking function occurring between the PW 1224 and the FR AC. 1226 - A common encapsulation can be used on both ACs, e.g., if one AC 1227 is Ethernet and one is FR, an "Ethernet over FR" encapsulation 1228 can be used on the latter. In this case, the PW could be 1229 signaled for Ethernet, with the processing of the Ethernet over 1230 FR encapsulation being local to the PE with the FR AC. 1232 - If it is known that the two ACs attach to IP routers or hosts, 1233 and carry only IP traffic, then one could use a PW which carries 1234 the IP packets, and the respective Layer2 encapsulations would be 1235 local matters for the two PEs. However, if one of the ACs is a 1236 LAN and one is a point-to-point link, care would have to be taken 1237 to ensure that such procedures as ARP and Inverse ARP are 1238 properly handled; this might require some signaling, and some 1239 proxy functions. Further, if the CEs use a routing algorithm that 1240 has different procedures for LAN interfaces than for point-to- 1241 point interfaces, additional mechanisms may be required to ensure 1242 proper interworking. 1244 3.4. VPLS Emulated LANs 1246 A VPLS is an L2VPN service in which: 1248 - the ACs attach CE devices to PE bridge modules, 1250 - each PE bridge module is attached via an "emulated LAN interface" 1251 to an "emulated LAN" 1253 This is shown in Figure 3. 1255 In this section, we examine the functional decomposition of the VPLS 1256 Emulated LAN. An Emulated LAN's ACs are the "emulated LAN 1257 interfaces" attaching PE bridge modules to the "VPLS Forwarder" 1258 modules (see Figure 3). The payload on the ACs consists of ethernet 1259 frames, with or without VLAN headers. 1261 A given VPLS Forwarder in a given PE will have multiple ACs only if 1262 there are multiple bridge modules in that PE which attach to that 1263 Forwarder. This scenario is included in the Framework, though 1264 discussion of its utility is out of scope. 1266 The set of VPLS Forwarders within a single VPLS are connected via 1267 PWs. Two VPLS Forwarders will have a PW between them only if those 1268 two Forwarders are part of the same VPLS. (There may be a further 1269 restriction that two VPLS Forwarders have a PW between them only if 1270 those two Forwarders belong to the same VLAN in the same VPN.) A 1271 particular set of interconnected VPLS Forwarders is what constitutes 1272 a VPLS Emulated LAN. 1274 On a real LAN, any frame transmitted by one entity is received by all 1275 the others. A VPLS Emulated LAN, however, behaves somewhat 1276 differently. When a VPLS Forwarder receives a unicast frame over one 1277 of its Emulated LAN interfaces, the Forwarder does not necessarily 1278 send the frame to all the other Forwarders on that Emulated LAN. A 1279 unicast frame need be sent to only one other Forwarder in order to be 1280 properly delivered to its destination MAC address. If the 1281 transmitting Forwarder knows which other Forwarder needs to receive a 1282 particular unicast frame, it will send the frame to just that one 1283 Forwarder. This forwarding optimization is an important part of any 1284 attempt to provide a VPLS service over a wide-area or metropolitan 1285 area network. 1287 In effect then each Forwarder behaves as a "Virtual Switch Instance" 1288 (VSI), maintaining a forwarding table in which maps MAC addresses to 1289 PWs. The VSI is populated in much the same was as a standard bridge 1290 populates its forwarding table. The VPLS Forwarders do MAC Source 1291 Address (SA) learning on frames received on PWs from other 1292 Forwarders, and must also do the related set of procedures, such as 1293 the aging out of address entries. Frames with unknown DAs or 1294 multicast DAs must be "broadcast" by one Forwarder to all the others 1295 (on the same emulated LAN). There are however a few important 1296 differences between the VPLS Forwarder VSI and the standard bridge 1297 forwarding function: 1299 - A VPLS Forwarder never learns the MAC SAs of frames which it 1300 receives on its ACs, it only learns the MAC SAs of frames which 1301 are received on PWs from other VPLS Forwarders; 1303 - The VPLS Forwarders of a particular emulated LAN do not 1304 participate in a spanning tree protocol with each other. A 1305 "split horizon" technique is used to prevent forwarding loops. 1307 These points are discussed further in the next section. 1309 Note that the PE bridge modules which are on a given Emulated LAN may 1310 or may not run spanning tree protocol with each other over the 1311 Emulated LAN; whether they do so or not is outside the scope of the 1312 VPLS specifications. The PE bridge modules will do MAC address 1313 learning on the ACs. The PE bridge modules also do MAC address 1314 learning on the Emulated LAN interfaces, but do not do MAC address 1315 learning on the PWs, as the PWs are "hidden" behind the Emulated LAN 1316 interface. Conceptually, the PE bridge module's forwarding table and 1317 the VPLS Forwarder's VSI are distinct entities. (Of course, 1318 particular implementations might combine these into a single table, 1319 but that is beyond the scope of this document.) 1321 A further issue does arise in the case where the PE bridges do run 1322 bridge control protocols with each other over the Emulated LAN. 1323 Bridge control protocols are generally designed to run in over a real 1324 LAN, and may presume, for their proper functioning, certain 1325 characteristics of the LAN, such as low latency and sequential 1326 delivery. If the Emulated LAN does not provide these 1327 characteristics, the control protocols may not perform as expected 1328 unless special mechanisms are provided for carrying the control 1329 frames. 1331 It should be noted that changes in the spanning tree (if any) of a 1332 customer network, or in the spanning tree (if any) of the PE bridges, 1333 may cause certain MAC addresses to change their location from one PE 1334 to another. These changes may not be visible to the VPLS Forwarders, 1335 which means that those MAC addresses might become unreachable until 1336 they are aged out of the first PE's VSI. If this is not acceptable, 1337 some mechanism for communicating such changes to the VPLS Forwarders 1338 must be provided. 1340 3.4.1. VPLS Overlay Topologies and Forwarding 1342 Within a single VPLS, the VPLS Forwarders are interconnected by PWs. 1343 The set of PWs thus forms an "overlay topology". 1345 The VPLS Forwarder VSIs are populated by means of MAC address 1346 learning. That is, the VSI keeps track of which MAC SAs have been 1347 received over which PWs. The presumption of course is that if a 1348 particular MAC address appears as the SA of a frame received over a 1349 particular PW, then frames which carry that MAC address in the DA 1350 field should be sent to the VSI which is at the remote end of the PW. 1351 In order for this presumption to be true, there must be a unique VSI 1352 at the remote end of the PW, which means that VSIs cannot be 1353 interconnected by means of multipoint-to-point PWs. The PWs are 1354 necessarily either point-to-point or, possibly, point-to-multipoint. 1356 MAC learning over a point-to-point PW is done via the standard 1357 techniques as specified by IEEE, where the PW is treated by the VPLS 1358 Forwarder as a "bridge port". Of course, if a MAC address is learned 1359 from a point-to-multipoint PW, the VSI must indicate that packets to 1360 that address are to be sent over a point-to-point PW which leads to 1361 the root of that point-to-multipoint PW. 1363 The VSI forwarding decisions must be coordinated so that loop-free 1364 forwarding over the overlay topology is ensured. 1366 There are several possible types of overlay topologies: 1368 - Full mesh 1370 In a full mesh, every VSI in a given VPLS has exactly one point- 1371 to-point PW to every other VSI in that same VPLS. 1373 In this topology, loop free forwarding of frames is ensured by 1374 the following rule: if a VSI receives a frame, over a PW, from 1375 another VSI, it MUST NOT forward that frame over ANY other PW to 1376 any other VSI. This ensures that once a frame traverses the 1377 Emulated LAN, it must be sent off the Emulated LAN. 1379 If a VSI receives, on one of its Emulated LAN interfaces, a 1380 unicast frame with a known DA, the frame is sent on exactly one 1381 point-to-point PW. 1383 If a VSI receives, on one of its Emulated LAN interfaces, a 1384 multicast frame or a unicast frame with unknown DA, it send a 1385 copy of the frame to each other VSI in the same Emulated LAN. 1386 This can be done by replicating the frame and sending a copy over 1387 each point-to-point PW. Alternatively, the full mesh of point- 1388 to-point PWs may be augmented with point-to-multipoint PWs, where 1389 each VSI in a VPLS is the transmitter on a single point-to- 1390 multipoint PW, and the receivers on that PW are all the other 1391 VSIs in that VPLS. 1393 - Tree Structured 1395 In a tree structured topology, every VSI in a particular VPLS is 1396 provisioned to be at a particular level in the tree. A given VSI 1397 has at most one pseudowire leading to a higher level. The root of 1398 the tree is considered to be the highest level. 1400 In this topology, loop free forwarding of frames is ensured by 1401 the following rule: if a frame is received over a pseudowire from 1402 a higher level, it may not be sent over a pseudowire that leads 1403 to a higher level. 1405 - Tree with Meshed Highest Level 1407 In this variant of the tree-structured topology, there may be 1408 more than one VSI at the highest level, but the set of VSIs which 1409 are at the highest level must be fully meshed. To ensure loop 1410 free forwarding, we need to impose the rule that a frame can be 1411 sent on a pseudowire to the same or higher level only if it 1412 arrived over a pseudowire from a lower level, and frames arriving 1413 over PWs from the same level cannot be sent on PWs to the same 1414 level. 1416 Other overlay topologies are also possible, e.g., an arbitrary 1417 partial mesh of PWs among the VSIs of a VPLS. Loop-freedom could 1418 then be assured by, for example, running spanning tree on the 1419 overlay. These topologies are not further considered in this 1420 framework. 1422 Note that loop freedom in the overlay topology does not necessarily 1423 ensure loop freedom in the overall customer LAN that contains the 1424 VPLS. It does not even ensure loop freedom among the PE bridge 1425 modules. It ensures only that when a frame is sent on the Emulated 1426 LAN, the frame will not loop endlessly before (or instead of) leaving 1427 the Emulated LAN. 1429 Improper configuration of the customer LAN or PE bridge modules may 1430 cause frames to loop, and frames that fall into such loops may 1431 transit the overlay topology multiple times. Procedures that enable 1432 the PE to detect and/or prevent such loops may be advisable. 1434 3.4.2. Provisioning and Auto-Discovery 1436 Each VPLS must be assigned a globally unique identifier. This can be 1437 thought of as a VPN-id. 1439 The ACs attaching the CEs to the PEs must be provisioned on both the 1440 PEs and the CEs. A VSI for that VPLS must be provisioned on the PE, 1441 and the local ACs of that VPLS must be associated with that VSI. The 1442 VSI must be provisioned with the identifier of the VPLS to which it 1443 belongs. 1445 An auto-discovery scheme may be used by a PE to map a VPLS identifier 1446 into the set of remote PEs that have VSIs in that VPLS. Once this 1447 set is determined, the PE can use pseudowire signaling to set up a PW 1448 to each of those VSIs. The VPLS identifier would serve as the 1449 signaling protocol's Forwarder Selector. This would result in a full 1450 mesh of PWs among the VSIs in a particular VPLS. 1452 If a single VPLS contains multiple VLANs, then it may be desirable to 1453 limit connectivity so that two VSIs are connected only if they have a 1454 VLAN in common. 1456 In this case, each VSI would need to be provisioned with one or more 1457 VLAN ids, and the auto-discovery scheme would need to map a VPLS 1458 identifier into pairs of . 1460 If a fully meshed topology of VSIs is not desired, then each VSI 1461 needs to be provisioned with additional information specifying its 1462 placement in the topology. This information would also need to be 1463 provided by the auto-discovery scheme. 1465 Alternatively, the single-sided provisioning method discussed in 1466 section 3.3.1.2 could be used. As this is more complicated, it would 1467 only be used if it were necessary to associate individual PWs with 1468 individual characteristics. For example, if different guaranteed 1469 bandwidths were needed between different pairs of sites within a 1470 VPLS, the PWs would have to be individually provisioned. 1472 3.4.3. Distributed PE 1474 Often when a VPLS type of service is provided, the CE devices attach 1475 to a provider-managed CPE device. This provider-managed CPE device 1476 may attach to CEs of multiple customers, especially if, e.g., there 1477 are multiple customers occupying the same building. However, this 1478 device is really part of the SP's network, hence may be considered to 1479 be a PE device. 1481 In some scenarios when a VPLS type of service is provided, the CE 1482 devices attach to a provider-managed intermediary device. This 1483 provider-managed device may attach to CEs of multiple customers. This 1484 may arise in a situation there multiple customers occupying the same 1485 building. This device is really part of the SP's network, and may 1486 for that reason be considered to be a PE device, however in the 1487 simplest case it is only performing aggregation and none of the 1488 function associated with a VPLS. 1490 Relative to the VPLS there are three different possibilities to 1491 allocate functions to a device in such a position in the provider 1492 network: 1494 - it can perform aggregation and pure Layer2 service only, in which 1495 case it does not really play the role of a PE device in a VPLS 1496 service. In this case the intermediary system must connect to 1497 devices that perform VPLS PE functionality; the intermediary 1498 device itself is not part of the VPLS architecture and has hence 1499 not been named in this architecture. 1501 - it can perform all the PE functions relevant for a VPLS, in such 1502 a case the device is called VPLS-PE, see [VPN-TERM]. This type of 1503 device will be connected to the core (P) routers. 1505 The PE functionality for a VPLS may be distributed between two 1506 devices, one "low-end" closer to the customer that performs e.g. the 1507 MAC-address learning and forwarding decisions, and one "high-end" 1508 that performs the control functions, e.g. establishing tunnels, PWs 1509 and VCs. We call the low-end device User-Facing PE (U-PE) and the 1510 high-end device Network-Facing PE (N-PE). 1512 It is conceivable that the U-PE may be placed very close to the 1513 customer, e.g. in a building with more than one customer. The N-PE 1514 will presumably be placed on the SP's premises. 1516 The distributed case is potentially of interest for a number of 1517 possible reasons: 1519 - The N-PE may be a device that cannot easily implement the VSI 1520 functionality described above. E.g., perhaps the N-PE is a router 1521 which cannot perform the high speed MAC learning that is needed 1522 in order to implement a VSI forwarder. At the same time, the U-PE 1523 may need to be a low-cost device that also cannot implement the 1524 full set of VPLS functions. 1526 This leads one to investigate further if there are sensible ways 1527 to split the VPLS PE functionality between the U-PE and the N-PE. 1529 - Generally, in the L2VPN architecture, the PEs are expected to 1530 participate as peers in the backbone routing protocol. Since the 1531 number of U-PEs is potentially very large relative to the number 1532 of N-PEs, this may be undesirable, as a matter of scaling the 1533 backbone routing protocol. 1535 - The U-PE may be a relatively inexpensive device that is unable to 1536 participate in the full range of signaling and/or auto-discovery 1537 procedures that are needed in order to provide the VPLS service. 1539 The VPLS functionality can be distributed between U-PE and N-PE in a 1540 number of different ways, and a number of different proposals have 1541 been made. They all presume that the U-PE will maintain a VSI 1542 forwarder, connected by PWs to the remote VSIs; the N-PE thus does 1543 not need to perform the VSI forwarding function. The proposals tend 1544 to differ with respect to the following questions: 1546 - Should the U-PEs perform full PW signaling to set up the PWs to 1547 remote VSIs? Or should the N-PEs do this signaling? 1549 Since the U-PEs need to be able to send packets on PWs to remote 1550 VSIs and receive packets on PWs from remote VSIs, if the PW 1551 signaling is done by the N-PE, there would have to be some form 1552 of "lightweight" (presumably) signaling between N-PE and U-PE 1553 that allows the PWs to be extended from N-PE to U-PE. 1555 - Should the U-PEs do their own auto-discovery, or should this be 1556 done by the N-PEs? In the latter case, the U-PEs may need to have 1557 some means of telling the N-PEs which VPLS's they are interested 1558 in, and the N-PEs must have some means of passing the results of 1559 the auto-discovery process to the U-PE. 1561 Whether it makes sense to split auto-discovery in this manner may 1562 depend on the particular auto-discovery protocol used. One would 1563 not expect the U-PEs to participate in a BGP-based auto-discovery 1564 scheme, e.g., but perhaps they would be expected to participate 1565 in a RADIUS-based auto-discovery scheme. 1567 - If a U-PE does not participate in routing, but is redundantly 1568 connected to two different N-PEs, can the U-PE still make an 1569 intelligent choice of the best N-PE to use as the "next hop" for 1570 traffic destined to a particular remote VSI? If not, can this 1571 choice be made as the result of some other sort of interaction 1572 between N-PE and U-PE? Or does this choice need to be established 1573 by provisioning? 1575 - If a U-PE does not participate in routing, but does participate 1576 in full PW signaling, and if MPLS is being used, how can an N-PE 1577 send a U-PE the labels that the U-PE needs in order to be able to 1578 send traffic to its signaling peers. (If the U-PE did participate 1579 in routing, this would happen automatically.) 1581 - When a frame must be multicast, should the replication be done by 1582 the N-PE or the U-PE? 1584 These questions are not all independent; the way one answers some 1585 of them may influence the way one answers others. 1587 3.4.4. Scaling issues in VPLS deployment 1589 In general, the PSN supports a VPLS solution with a tunnel from each 1590 VPLS-PE every other VPLS-PE participating in the same VPLS instance. 1591 Strictly, VPLS-PE's with more than one VPLS instance in common only 1592 need one tunnel, but for resource allocation reasons it might be 1593 necessary to establish several tunnels. For each VPLS service on a 1594 given VPLS-PE it needs to establish one pseudowire to every other 1595 VPLS-PE participating in that VPLS service. In total n*(n-1) 1596 pseudowires must be setup between the VPLS-PE routers. In large scale 1597 deployment this obviously creates scaling problems. One way to 1598 address the scaling problems is to use hierarchy. 1600 3.5. IP-only LAN-like Service (IPLS) 1602 If, instead of providing a general VPLS service, one wishes to 1603 provide a VPLS that is used only to connect IP routers or hosts 1604 (i.e., the CE devices are all assumed to be IP routers or hosts), 1605 then it is possible to make certain simplifications. 1607 In this environment, all Ethernet frames sent from a particular CE to 1608 a particular PE on a particular Attachment Circuit will have the same 1609 MAC Source Address. Thus rather than using address learning in the 1610 data plane to learn the MAC addresses, the PE can use the control 1611 plane to learn the MAC address. This allows the PE to be implemented 1612 on devices that are not capable of doing MAC address learning in the 1613 data plane. 1615 To eliminate the need for MAC address learning on the PWs as well as 1616 on the ACs, the pseudowire signaling protocol would have to carry the 1617 MAC address from one pseudowire endpoint to the other. In the case of 1618 IPv4, Each PE would perform proxy ARP to its directly attached CEs. 1619 In the case of IPv6, each PE would send proxy Neighbor and/or Router 1620 Advertisements. 1622 Eliminating the need to do MAC address learning on the PWs eliminates 1623 the need for the PWs to be point-to-point. Multipoint-to-point PWs 1624 could be used instead. 1626 Unlike a VPLS, all the ACs in an IPLS would not necessarily have to 1627 carry Ethernet frames; only the IP packets would need to be passed 1628 across the network, not their Layer 2 wrappers. However, if there are 1629 protocols which are specific to the layer 2, but which provide, e.g., 1630 address resolution services for layer 3, it may then be necessary to 1631 "translate" (or otherwise interwork) one of these layer 2 protocols 1632 to the other. For example, if an IPLS instance has an ethernet AC 1633 and a Frame Relay AC, with IPv4 running on both, interworking between 1634 ARP and Inverse ARP might be required. 1636 The set of routing protocols which could be carried across the IPLS 1637 might also be restricted. 1639 An IPLS instance must have a particular IPLS-wide MTU; if there are 1640 different kinds of AC in an IPLS instance, and those different kinds 1641 of AC support different MTUs, all ACS must enforce the IPLS-wide MTU; 1642 an AC that cannot do this must not be allowed to join the IPLS 1643 instance. 1645 4. Security Considerations 1647 The security considerations section of the L2VPN requirements 1648 document [L2VPN-REQ] addresses a number of areas that are potentially 1649 insecure aspects of the L2VPN. These relate to both control plane 1650 and data plane security issues that may arise in the following areas: 1652 - issues fully contained in the provider network 1654 - issues fully contained in the customer network 1656 - issues in the customer-provider interface network 1658 These three areas are addressed below. 1660 4.1. Provider Network Security Issues 1662 This section discusses security issues that only impact the SP's 1663 equipment. 1665 There are security issues having to do with the control connections 1666 that are used on a PE-PE basis for setting up and maintaining the 1667 pseudowires. 1669 A PE should not engage with another PE in a control connection unless 1670 it has some confidence that the peer is really a PE to which it 1671 should be setting up PWs. Otherwise L2PVN traffic may go to the 1672 wrong place. If control packets are maliciously and undetectably 1673 altered while in flight, denial of service, or alteration of the 1674 expected quality of service, may result. 1676 If peers discover each other dynamically (via some auto-discovery 1677 procedure), this presupposes that the auto-discovery procedures are 1678 themselves adequately trusted. 1680 PEs should not accept control connections from arbitrary entities; a 1681 PE should either be configured with its peers, or learn them from a 1682 trusted auto-configuration procedure. If the peer is required to be 1683 within the same SP's network, then access control filters at the 1684 borders of that network can be used to prevent spoofing of the peer's 1685 source address. If the peer is from another SP's network, then 1686 setting up such filters may be difficult or even impossible, 1687 depending on the way in which the two SPs are connected. Even if the 1688 access filters can be set up, the level of assurance which they 1689 provide will be lower. 1691 Thus for inter-SP control connections, it is advisable to use some 1692 sort of cryptographic authentication procedure. Control protocols 1693 which used TCP may use the TCP MD5 option to provide a measure of 1694 PE-PE authentication; this requires at least one shared secret 1695 between SPs. The use of IPsec between PEs is also possible, and 1696 provides a greater degree of assurance, though at a greater cost. 1698 Any other security considerations which apply to the control protocol 1699 in general will also apply when the control protocol is used for 1700 setting up PWs. If the control protocol uses UDP messages, it may be 1701 advisable to have some protection against spoofed UDP messages which 1702 appear to be from a valid peer; this requires further study. 1704 To limit the effect of Denial of Service attacks on a PE, some means 1705 of limiting the rate of processing of control plane traffic may be 1706 desirable. 1708 Unlike authentication and integrity, privacy of the signaling 1709 messages is not usually considered very important. If it is needed, 1710 the signaling messages can be sent through an IPsec connection. 1712 If the PE cannot efficiently handle high volumes of multicast traffic 1713 for sustained periods, then it may be possible to launch a denial of 1714 service attack on a VPLS service by sending a PE excessive amounts of 1715 layer 2 multicast traffic. 1717 4.2. Provider-Customer Network Security Issues 1719 There are a number of security issues related to the access network 1720 between the provider and the customer. This is also traditionally a 1721 network that is hard to protect physically. 1723 Typical security issues on the provider-customer interface include 1724 the following: 1726 - Ensuring correct customer interface configured 1728 - Preventing unauthorized access to PE 1730 - Preventing unauthorized access to a specific PE port 1732 - Ensuring correct service delimiting fields (VLAN, DLCI, etc.) 1734 As the access network for an L2VPN service is necessarily a layer 2 1735 network, it is preferable to use authentication mechanisms that do 1736 not presuppose any IP capabilities on the CE device. 1738 There are existing layer 2 protocols and best current practices to 1739 guard against these security issues. For example, IEEE 802.1x 1740 defines authentication at the link level for access through an 1741 ethernet bridge; the Frame Relay Forum defines LMI extensions for 1742 authentication (FRF.17). 1744 4.3. Customer Network Security Issues 1746 Even if all CE devices are properly authorized to attach to their PE 1747 devices, misconfiguration of the PE may interconnect CEs that are not 1748 supposed to be in the same L2VPN. 1750 In a VPWS, the CEs may run IPsec to authenticate each other. Other 1751 layer 3 or layer 4 protocols may have their own authentication 1752 methods. 1754 In a VPLS, CE-to-CE IPsec is even more problematic, as IPsec does not 1755 well support the multipoint configuration which is provided by the 1756 VPLS service. 1758 There may be alternative methods for achieving a degree of CE-to-CE 1759 authentication, if the L2VPN signaling protocol can carry opaque 1760 objects between the CEs, either inband (over the L2VPN), or out-of- 1761 band, through the participation of the signaling protocol. This is 1762 for further study. 1764 The L2VPN procedures do not provide authentication, integrity, or 1765 privacy for the customer's traffic; if this is needed, it becomes the 1766 responsibility of the customer. For customers who really need these 1767 features, or who do not trust their service providers to provide the 1768 level of security that they need, the L2VPN framework discussed in 1769 this document may not be satisfactory. Such customers may consider 1770 alternative L2VPN schemes which are based not upon an overlay of PWs, 1771 but upon an overlay of IPsec tunnels whose endpoints are at the 1772 customer sites; however, such alternatives are not discussed in this 1773 document. 1775 If there is CE-to-CE control traffic (e.g., BPDUs), on whose 1776 integrity the customer's own layer 2 network depends, it may be 1777 advisable to send the control traffic using some more secure 1778 mechanism than is used for the data traffic. 1780 5. Authors and Acknowledgments 1782 This document is the outcome of discussions within a Layer 2 VPN 1783 design team, all of whose members could be considered to be co- 1784 authors. Specifically, the co-authors are Loa Andersson, Waldemar 1785 Augustyn, Marty Borden, Hamid Ould-Brahim, Juha Heinanen, Kireeti 1786 Kompella, Vach Kompella, Marc Lasserre, Pascal Menezes, Vasile 1787 Radoaca, Eric Rosen, and Tissa Senevirathne. 1789 The authors would like to thank Marco Carugi for cooperation in 1790 setting up context, working directions and taking time for 1791 discussions in this space, Tove Madsen and Pekka Savola for valuable 1792 input and reviews, and Norm Finn, Matt Squires, and Ali Sajassi for 1793 valuable discussion of the VPLS issues. 1795 6. Authors' Contact Information 1797 Loa Andersson 1798 Email: loa@pi.se 1800 Eric C. Rosen 1801 Cisco Systems, Inc. 1802 1414 Massachusetts Avenue 1803 Boxborough, MA 01719 1804 Email: erosen@cisco.com 1806 Waldemar Augustyn 1807 Email: waldemar@nxp.com 1809 Marty Borden 1810 mborden@acm.org 1812 Juha Heinanen 1813 Song Networks, Inc. 1814 Hallituskatu 16 1815 33200 Tampere, Finland 1816 Email: jh@song.fi 1818 Kireeti Kompella 1819 Juniper Networks, Inc. 1820 1194 N. Mathilda Ave 1821 Sunnyvale, CA 94089 1822 Email: kireeti@juniper.net 1824 Vach Kompella 1825 TiMetra Networks 1826 274 Ferguson Dr. 1827 Mountain View, CA 94043 1828 Email: vkompella@timetra.com 1829 Marc Lasserre 1830 Riverstone Networks 1831 5200 Great America Pkwy 1832 Santa Clara, CA 95054 1833 Email: marc@riverstonenet.com 1835 Pascal Menezies 1836 Email: pascalm1@yahoo.com 1838 Hamid Ould-Brahim 1839 Nortel Networks 1840 P O Box 3511 Station C 1841 Ottawa, ON K1Y 4H7, Canada 1842 Email: hbrahim@nortelnetworks.com 1844 Vasile Radoaca 1845 Nortel Networks 1846 600 Technology Park 1847 Billerica, MA 01821 1848 Email: vasile@nortelnetworks.com 1850 Tissa Senevirathne 1851 1567 Belleville Way 1852 Sunnyvale CA 94087 1853 Email: tsenevir@hotmail.com 1855 7. Normative References 1857 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 1858 Requirement Levels", RFC 2119, March 1997. 1860 [L2VPN-REQ] Augustyn, W. et.al "Service Requirements for Layer 2 1861 Provider Provisioned Virtual Private Networks", draft-ietf-l2vpn- 1862 requirements-00.txt, Work in Progress, May 2003. 1864 [PWE3-ARCH] Bryant, S., "PWE3 Architecture", draft-ietf-pwe3-arch- 1865 06.txt, Work in Progress, October 2003. 1867 [VPN-TERM] Andersson, L. and Madsen T. "VPN Terminology", draft- 1868 andersson-ppvpn-terminology-04.txt", Work in Progress, September 1869 2003. 1871 8. Informative References 1873 [BGP] "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, P. Gross, 1874 RFC 1771, March 1995 1876 [BGPRR] "BGP Route Reflection - An Alternative to Full Mesh IBGP", T. 1877 Bates, R. Chandra, E. Chen. RFC 2796, April 2000 1879 [IEEE8021D] IEEE 802.1D-2003, "IEEE Standard for Local and 1880 Metropolitan Area Networks: Media Access Control (MAC) Bridges" 1882 [IEEE8021Q] IEEE 802.1Q-1998, "IEEE Standards for Local and 1883 Metropolitan Area Networks: Virtual Bridged Local Area Networks" 1885 [L2TP] "Layer Two Tunneling Protocool", M. Townsley, A. Valencia, A. 1886 Rubens, G. Pall, G. Zorn, B. Palter, RFC 2661, August 1999 1888 [LDP] "LDP Specification" L. Andersson, P. Doolan, N. Feldman, A. 1889 Fredette, B. Thomas. RFC 3036, January 2001 1891 9. Intellectual Property Notice 1893 The IETF takes no position regarding the validity or scope of any 1894 intellectual property or other rights that might be claimed to 1895 pertain to the implementation or use of the technology described in 1896 this document or the extent to which any license under such rights 1897 might or might not be available; neither does it represent that it 1898 has made any effort to identify any such rights. Information on the 1899 IETF's procedures with respect to rights in standards-track and 1900 standards-related documentation can be found in BCP-11. Copies of 1901 claims of rights made available for publication and any assurances of 1902 licenses to be made available, or the result of an attempt made to 1903 obtain a general license or permission for the use of such 1904 proprietary rights by implementors or users of this specification can 1905 be obtained from the IETF Secretariat. 1907 The IETF invites any interested party to bring to its attention any 1908 copyrights, patents or patent applications, or other proprietary 1909 rights which may cover technology that may be required to practice 1910 this standard. Please address the information to the IETF Executive 1911 Director. 1913 10. Copyright Notice 1915 "Copyright (C) The Internet Society (2004). All Rights Reserved. 1917 This document and translations of it may be copied and furnished to 1918 others, and derivative works that comment on or otherwise explain it 1919 or assist in its implementation may be prepared, copied, published 1920 and distributed, in whole or in part, without restriction of any 1921 kind, provided that the above copyright notice and this paragraph are 1922 included on all such copies and derivative works. However, this 1923 document itself may not be modified in any way, such as by removing 1924 the copyright notice or references to the Internet Society or other 1925 Internet organizations, except as needed for the purpose of 1926 developing Internet standards in which case the procedures for 1927 copyrights defined in the Internet Standards process must be 1928 followed, or as required to translate it into languages other than 1929 English. 1931 The limited permissions granted above are perpetual and will not be 1932 revoked by the Internet Society or its successors or assigns. 1934 This document and the information contained herein is provided on an 1935 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1936 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1937 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1938 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1939 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."