idnits 2.17.1 draft-ietf-l2vpn-l2-framework-02.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 (September 2003) is 7522 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 472, but not defined == Unused Reference: 'L3VPN-FW' is defined on line 1829, but no explicit reference was found in the text == Unused Reference: 'L3VPN-REQ' is defined on line 1833, but no explicit reference was found in the text == Unused Reference: 'PWE3-ARCH' is defined on line 1845, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-l3vpn-bgpvpn-auto-00 == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-10 == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-requirements-00 == Outdated reference: A later version (-08) exists of draft-ietf-l2vpn-signaling-00 == Outdated reference: A later version (-02) exists of draft-ietf-l3vpn-requirements-00 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-in-ip-or-gre-02 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-arch-05 == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-03 -- Obsolete informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-08) exists of draft-ietf-l2vpn-vpls-bgp-00 -- No information found for draft-heinanen-radius-l2tp-vpls-0- - is the name correct? == Outdated reference: A later version (-09) exists of draft-ietf-l2vpn-vpls-ldp-00 Summary: 3 errors (**), 0 flaws (~~), 16 warnings (==), 4 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: March 2004 Eric C. Rosen 5 Cisco Systems, Inc. 7 Editors 9 September 2003 11 L2VPN Framework 13 draft-ietf-l2vpn-l2-framework-02.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 (Layer 2 PPVPNs, or L2VPNs). This framework 39 is intended to aid in standardizing protocols and mechanisms to 40 support interoperable Layer 2 PPVPNs. 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 ............................................. 4 50 2.1 Reference Model for VPWS ........................... 4 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 ............... 8 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 .................... 9 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) ................. 10 61 3.1.3 IP-only LAN-like Service (IPLS) .................... 11 62 3.2 Generic L2VPN Transport Functional Components ...... 11 63 3.2.1 Attachment Circuits ................................ 12 64 3.2.2 Pseudowires ........................................ 12 65 3.2.3 Forwarders ......................................... 13 66 3.2.4 Tunnels ............................................ 15 67 3.2.5 Encapsulation ...................................... 15 68 3.2.6 Pseudowire Signaling ............................... 16 69 3.2.6.1 Point-to-Point Signaling ........................... 17 70 3.2.6.2 Point-to-Multipoint Signaling ...................... 18 71 3.2.6.3 Inter-AS Considerations ............................ 19 72 3.2.7 Service Quality .................................... 20 73 3.2.7.1 Quality of Service (QoS) ........................... 20 74 3.2.7.2 Resiliency ......................................... 21 75 3.2.8 Management ......................................... 22 76 3.3 VPWS ............................................... 22 77 3.3.1 Provisioning and Auto-Discovery .................... 23 78 3.3.1.1 Attachment Circuit Provisioning .................... 23 79 3.3.1.2 PW Provisioning for Arbitrary Overlay Topologies ... 23 80 3.3.1.3 Colored Pools PW Provisioning Model ................ 25 81 3.3.2 Requirements on Auto-Discovery Procedures .......... 27 82 3.3.3 Heterogeneous Pseudowires .......................... 28 83 3.4 VPLS Emulated LANs ................................. 29 84 3.4.1 VPLS Overlay Topologies and Forwarding ............. 31 85 3.4.2 Provisioning and Auto-Discovery .................... 33 86 3.4.3 Distributed PE ..................................... 33 87 3.4.4 Scaling issues in VPLS deployment .................. 36 88 3.5 IP-only LAN-like Service (IPLS) .................... 36 89 4 Security Considerations ............................ 37 90 4.1 Provider Network Security Issues ................... 37 91 4.2 Provider-Customer Network Security Issues .......... 38 92 4.3 Customer Network Security Issues ................... 39 93 5 Intellectual Property Notice ....................... 40 94 6 Copyright Notice ................................... 40 95 7 Normative References ............................... 41 96 8 Informative References ............................. 41 97 9 Authors and Acknowledgments ........................ 42 98 10 Authors' Contact Information ....................... 43 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 (Layer 2 PPVPNs). This framework is 112 intended to aid in standardizing protocols and mechanisms to support 113 interoperable Layer 2 PPVPNs. 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 Layer 2 PPVPNs can be found in [L2VPN-REQ]. 121 This document provides reference models for Layer 2 PPVPNs, and 122 discusses the functional components of Layer 2 PPVPNs. Specifically, 123 this includes discussion of the technical issues which are important 124 in the design of standards and mechanisms for Layer 2 PPVPNs, 125 including those standards and mechanisms needed for interworking and 126 security. 128 This document discusses a number of different technical approaches to 129 Layer 2 PPVPNs. It tries to show how the different approaches are 130 related, and to clarify the issues that may lead one to select one 131 approach rather than another. However, this document does not 132 attempt to select any particular approach. 134 1.3. Layer 2 Virtual Private Networks 136 There are two fundamentally different kinds of Layer 2 VPN service 137 that a service provider could offer to a customer: Virtual Private 138 Wire Service (VPWS) and Virtual Private LAN Service (VPLS). There is 139 also the possibility of an IP-only LAN-like Service (IPLS, [IPLS]). 141 A VPWS is a VPN service that supplies a L2 point-to-point service. 142 Being a point-to-point service, there are very few scaling issues 143 with the service as such. Scaling issues might arise from the number 144 of end-points that can be supported on a particular PE. 146 A VPLS is an L2 service that in all emulates LAN service across a 147 Wide Area Network (WAN). Thus it also has all the scaling 148 characteristics of a LAN. Other scaling issues might arise from the 149 number of end-points that can be supported on a particular PE. 151 1.4. Terminology 153 The list of the technical terms used when discussing L2 PPVPNs may be 154 found in the companion document [PPVPN-TERM]. 156 2. Models 158 2.1. Reference Model for VPWS 160 The VPWS reference model is shown in Figure 1. 162 Attachment PSN Attachment 163 Circuits tunnel Circuits 164 + 165 +-----+ pseudo +-----+ 166 | | wire | | 167 | CE1 |--+ +--| CE2 | 168 | | | +-----+ +-----+ +-----+ | | | 169 +-----+ +----|---- | | P | | ----+----+ +-----+ 170 |VPWS\|---|-----|-----|/VPWS| 171 | PE1 |===|=====|=====| PE2 | 172 | /|---|-----|-----|\ | 173 +-----+ +----|---- | | | | ----|----+ +-----+ 174 | | | +-----+ +-----+ +-----+ | | | 175 | CE3 |--+ +--| CE4 | 176 | | | | 177 +-----+ +-----+ 179 Figure 1 181 2.1.1. Entities in the VPWS reference model 183 The P, PE (VPWS-PE) and CE devices and the PSN tunnel as defined in 184 [PPVPN-TERM]. Attachment circuit and pseudo wire as discussed in 185 section 3. The PE does a simple mapping between the PW and attachment 186 circuit based on local information, i.e. the PW de-multiplexor and 187 incoming/outgoing logical/physical port. 189 2.2. Reference Model for VPLS 191 The following diagram shows a VPLS reference model where PE devices 192 that are VPLS-capable provide a logical interconnect such that CE 193 devices belonging to a specific VPLS appear to be on a single bridged 194 Ethernet. A VPLS can contain a single VLAN or multiple, tagged VLANs. 196 The VPLS reference model is shown in Figures 2 and 3. 198 +-----+ +-----+ 199 + CE1 +--+ +---| CE2 | 200 +-----+ | ................... | +-----+ 201 VPLS A | +----+ +----+ | VPLS A 202 | |VPLS| |VPLS| | 203 +--| PE |--Routed---| PE |-+ 204 +----+ Backbone +----+ 205 / . | . \ _ /\_ 206 +-----+ / . | . \ / \ / \ +-----+ 207 + CE +--+ . | . +--\ Access \----| CE | 208 +-----+ . +----+ . | Network | +-----+ 209 VPLS B .....|VPLS|........ \ / VPLS B 210 | PE | ^ ------- 211 +----+ | 212 | | 213 | | 214 +-----+ | 215 | CE3 | +-- Emulated LAN 216 +-----+ 217 VPLS A 219 Figure 2 220 |-----Routed Backbone------| 221 | (P Routers) |PSN Tunnels, 222 Emulated LAN | |Pseudowires 223 ......................................................................... 224 . | | . 225 . |----------------------|----| |---------|-----------------| . 226 . | --------------------|--- | | -------|---------------- | . 227 . | VPLS Forwarder | | VPLS Forwarder | . 228 . | ----------|------------- | | ----------|------------- | . 229 ..|...................................................................|.. 230 | | Emulated LAN | | | Emulated LAN | 231 | | Interface | VPLS-PEs | | Interface | 232 | | | <----> | | | 233 | ----------|------------ | | ----------|------------ | 234 | | Bridge | | | | Bridge | | 235 | -|--------|---------|-- | | ---|-------|---------|- | 236 |---|--------|---------|----| |-----|-------|---------|---| 237 | | | | | | 238 | | Access | | | Access | 239 | | Networks| | | Networks| 240 | | | | | | 241 | | | | | | 242 CE devices CE devices 243 Figure 3 245 From Figure 3, we see that in VPLS, a CE device attaches, possibly 246 through an access network, to a "bridge" module of a VPLS-PE. Within 247 the VPLS-PE, the bridge module attaches, through an "Emulated LAN 248 Interface" to an Emulated LAN. For each VPLS, there is an Emulated 249 LAN instance. Figure 3 shows some internal structure to the Emulated 250 LAN: it consists "VPLS Forwarder" modules (one per VPLS-PE per VPLS 251 instance) connected by Pseudowires, where the Pseudowires may be 252 traveling through PSN tunnels over a routed backbone. 254 The functionality which the bridge module must support depends on the 255 service which is being offered by the SP to its customers, as well as 256 on various details of the SP's network. At minimum, the bridge 257 module must be able to learn MAC addresses, and to "age them out", in 258 the standard manner. However, if the PE devices have backdoor 259 connections with each other via a layer 2 network, they may need to 260 be full IEEE bridges, running spanning tree with each other. 261 Specification of the precise functionality which the bridge modules 262 must have in particular circumstances is, however, out of scope of 263 the current document. 265 This framework specifies that each "bridge module" has a single 266 "Emulated LAN interface". It does not specify the number of bridge 267 modules that a VPLS-PE may contain, nor does it specify the number of 268 VPLS instances which may attach to a bridge module over a single 269 "Emulated LAN interface". 271 Thus the framework is compatible with at least the following three 272 models: 274 - Model 1 276 A VPLS-PE contains a single bridge module, and supports a single 277 VPLS instance. The VPLS instance is an Emulated LAN; if that 278 Emulated LAN contains VLANs, 802.1Q tagging must be used to 279 indicate which packets are in which VLANs. 281 - Model 2 283 A VPLS-PE contains a single bridge module, but supports multiple 284 VPLS instances. Each VPLS instance is thought of as a VLAN (in 285 effect, an "Emulated VLAN"), and the set of VPLS instances are 286 treated as a set of VLANs on a common LAN. 288 - Model 3 290 A VPLS-PE contains an arbitrary number of bridge modules, each of 291 which attaches to a single VPLS instance. 293 There may be other models as well, some of which are combinations of 294 the 3 models above. Different models may have different 295 characteristics, and different scopes of applicability. 297 Each VPLS solution should specify the model or models that it is 298 supporting. Each solution should also specify the necessary bridge 299 functionality that its bridge modules must support. 301 This framework does not specify the way in which bridge control 302 protocols are used on the Emulated LANs. 304 2.2.1. Entities in the VPLS reference model 306 The PE (VPLS-PE) and CE devices are defined in [PPVPN-TERM]. 308 2.3. Reference Model for Distributed VPLS-PE or VPWS-PE 310 VPLS-PE/VPWS-PE 311 Functionality . . . . . . . 312 . . . . . . . . . . . . . 313 . . . . 314 +----+ . +----+ +----+ . . Service . 315 | CE |--.--|U-PE|----|N-PE|-.---. Provider . 316 +----+ . +----+ +----+ . . Backbone . 317 . . . . . . . . . . . . . 319 2.3.1. Entities in the Distributed PE Reference Models 321 A VPLS-PE or a VPWS-PE functionality may be distributed to more than 322 one device. The device closer to the customer/user is called User 323 facing PE (U-PE) and the device closer to the core network is called 324 Network facing PE (N-PE). 326 For further discussion see section 3.4.3. 328 The terms "U-PE" and "N-PE" are defined in [PPVPN-TERM]. 330 2.4. VPWS-PE and VPLS-PE 332 The VPWS-PE and VPLS-PE are functionally very similar, the they both 333 use forwarders to map attachment circuits to pseudo-wires. The only 334 differences is that while the forwarder in a VPWS-PE does a one-to- 335 one mapping between the attachment circuit and pseudo-wire, the 336 forwarder in a VPLS-PE is a Virtual Switching Instance (VSI) that 337 maps multiple attachment circuits to multiple pseudo-wires (for 338 further discussion see section 3.) 340 3. Functional Components of L2 VPN 342 This section specifies a functional model for L2VPN, which allows one 343 to break an L2VPN architecture down into its functional components. 344 This allows us to exhibit the roles played by the various protocols 345 and mechanisms, and thus to make it easier to understand the 346 differences and similarities between various proposed L2VPN 347 architectures. 349 Section 3.1 contains an overview of some different types of L2VPN. 350 In section 3.2, functional components that are common to the 351 different types are discussed. Then there is a section for each of 352 the L2VPN service types being considered. The latter sections discuss 353 functional components, which may be specific to particular L2VPN 354 types, as well as discussing type-specific features of the generic 355 components. 357 3.1. Types of L2VPN 359 The types of L2VPN are distinguished by the characteristics of the 360 service that they offer to the customers of the Service Provider 361 (SP). 363 3.1.1. Virtual Private Wire Service (VPWS) 365 In a VPWS, each CE device is presented with a set of point-to-point 366 virtual circuits. 368 The other end of each virtual circuit is another CE device. Frames 369 transmitted by a CE on such a virtual circuit are received by the CE 370 device at the other end-point of the virtual circuit. Forwarding from 371 one CE device to another is not affected by the content of the frame, 372 but is fully determined by the virtual circuit on which the frame is 373 transmitted. The PE thus acts as a virtual circuit switch. 375 This type of L2VPN has long been available over ATM and Frame Relay 376 backbones. Providing this type of L2VPN over MPLS and/or IP backbones 377 is the current topic. 379 Requirements for this type of L2VPN are specified in [L2VPN-REQ]. 381 3.1.2. Virtual Private LAN Service (VPLS) 383 In a VPLS, each CE device has one or more LAN interfaces that lead to 384 a "virtual backbone". 386 Two CEs are connected to the same virtual backbone if and only if 387 they are members of the same VPLS instance (i.e., same VPN). When a 388 CE transmits a frame, the PE that receives it examines the MAC 389 Destination Address field in order to determine how to forward the 390 frame. Thus the PE functions as a bridge. As is indicated in Figure 391 3, if a set of PEs support a common VPLS instance, then there is an 392 Emulated LAN, corresponding to that VPLS instance, to which each of 393 those PE bridges attaches (via an emulated interface). From the 394 perspective of a CE device, the virtual backbone is the set of PE 395 bridges and the Emulated LAN on which they reside. Thus to a CE 396 device, the LAN which attaches it to the PE is extended transparently 397 over the routed MPLS and/or IP backbone. 399 The PE bridge function treats the Emulated LAN as it would any other 400 LAN to which it has an interface. Forwarding decisions are made in 401 the manner which is normal for bridges, based on MAC Source Address 402 learning. 404 VPLS is like VPWS in that forwarding is done without any 405 consideration of the Layer3 header. VPLS is unlike VPWS in that: 407 - VPLS allows the PE to use addressing information in a frame's L2 408 header to determine how to forward the frame; 410 - VPLS allows a single CE/PE connection to be used for transmitting 411 frames to multiple remote CEs; in this particular respect, VPLS 412 resembles L3VPN more than VPWS. 414 Requirements for this type of L2VPN are specified in [L2VPN-REQ]. 416 3.1.3. IP-only LAN-like Service (IPLS) 418 An IPLS is very like a VPLS, except that: 420 - it is assumed that the CE devices are hosts or routers, not 421 switches 423 - it is assumed that the service will only carry IP packets, and 424 supporting packets such as ICMP and ARP; Layer2 packets which do 425 not contain IP are not supported. 427 While this service is a functional subset of the VPLS service, it is 428 considered separately because it may be possible to provide it using 429 different mechanisms, which may allow it to run on certain hardware 430 platforms that cannot support the full VPLS functionality. 432 3.2. Generic L2VPN Transport Functional Components 434 All L2VPN types must transport "frames" across the core network 435 connecting the PE's. In all L2VPN types, a PE (PE1) receives a frame 436 from a CE (CE1), then transports the frame to a PE (PE2), which then 437 transports the frame to a CE (CE2). In this section, we discuss the 438 functional components, which are necessary to transport L2 frames in 439 any type of L2VPN service. 441 3.2.1. Attachment Circuits 443 In any type of L2VPN, a CE device attaches to a PE device via some 444 sort of circuit or virtual circuit. We will call this an "Attachment 445 Circuit" (AC). We use this term very generally; an Attachment Circuit 446 may be a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, 447 a PPP connection on a physical interface, a PPP session from an L2TP 448 tunnel, an MPLS LSP, etc. The CE device may be a router, a switch, a 449 host, or just about anything, which the customer needs hooked up to 450 the VPN. An AC carries a frame between CE and PE, or vice versa. 452 Procedures for setting up and maintaining the ACs are out of scope of 453 this architecture. 455 These procedures are generally specified as part of the specification 456 of the particular Attachment Circuit technology. 458 Any given frame will traverse an AC from a CE to a PE and then on 459 another AC from a PE to a CE. 461 We refer to the former AC as the frame's "ingress AC" and to the 462 latter AC as the frame's "egress AC". Note that this notion of 463 "ingress AC" and "egress AC" is relative to a specific frame, and 464 denotes nothing more than the frame's direction of travel while on 465 that AC. 467 3.2.2. Pseudowires 469 A "Pseudowire" (PW) is a relation between two PE devices. Whereas an 470 AC is used to carry a frame from CE to PE, a PW is used to carry a 471 frame between two PEs. We use the term "pseudowire" in the sense of 472 [PWE3- ARCH]. 474 Setting up and maintaining the PWs is the job of the PEs. State 475 information for a particular PW is maintained at the two PEs which 476 are its endpoints, but not at other PEs, and not in the backbone 477 routers (P routers). 479 Pseudowires may be point-to-point, multipoint-to-point, or point-to- 480 multipoint. In this framework, point-to-point PWs are always 481 considered to be bidirectional; multipoint-to-point and point-to- 482 multipoint PWs are always considered to be unidirectional. 483 Multipoint-to-point PWs can be used only when the PE receiving a 484 frame from the PW does not need to know where the frame came from. 485 Point-to-multipoint PWs may be useful when frames need to be 486 multicast. 488 Procedures for setting up and maintaining point-to-multipoint PWs are 489 not considered in this version of this framework. 491 Any given frame travels first on its ingress AC, then on a PW, then 492 on its egress AC. 494 Multicast frames may be replicated by a PE, so of course the 495 information carried in multicast frames may travel on more than one 496 PW and more than one egress AC. 498 Thus with respect to a given frame, a PW may be said to associate a 499 number of ACs. If these ACs are of the same technology (e.g., both 500 ATM, both Ethernet, both Frame Relay) the PW is said to provide 501 "homogeneous transport"; otherwise it is said to provide 502 "heterogeneous transport". Heterogeneous transport requires that some 503 sort of interworking function be applied. There are at least three 504 different approaches to interworking: 506 1. One of the CEs may perform the interworking locally. For 507 example, if CE1 attaches to PE1 via ATM, but CE2 attaches to 508 PE2 via Ethernet, then CE1 may decide to send/receive Ethernet 509 frames over ATM, using the RFC2684 "LLC Encapsulation for 510 Bridged Protocols". In such a case, PE1 would need to know 511 that it is to terminate the ATM VC locally, and only 512 send/receive Ethernet frames over the PW. 514 2. One of the PEs may perform the interworking. For example, if 515 CE1 attaches to PE1 via ATM, but CE2 attaches to PE2 via Frame 516 Relay, PE1 may provide the "ATM/FR Service Interworking" 517 function. This would be transparent to the CEs, and the PW 518 would carry only Frame Relay frames. 520 3. IPLS could be used. In this case the "frames" carried by the 521 PW are IP datagrams, and the two PEs need to cooperate in order 522 to spoof various L2-specific procedures used by IP (see section 523 3.5). 525 3.2.3. Forwarders 527 In all types of L2VPN, a PE, say PE1, receives a frame over an AC, 528 and forwards it over a PW to another PE, say PE2. PE2 then forwards 529 the frame out on another AC. 531 The case in which PE1 and PE2 are the same device is an important 532 case to handle correctly, in order to provide the L2VPN service 533 properly. However, as this case does not require any protocol, we do 534 not further address it in this document. 536 When PE1 receives a frame on a particular AC, it must determine the 537 PW on which the frame must be forwarded. In general, this is done by 538 considering: 540 - the incoming AC, 542 - possibly the contents of the frame's Layer2 header, and 544 - possibly some forwarding information which may be statically or 545 dynamically maintained. 547 If dynamic or static forwarding information is considered, the 548 information is specific to a particular L2VPN instance (i.e., to a 549 particular VPN). 551 Similarly, when PE2 receives a frame on a particular PW, it must 552 determine the AC on which the frame must be forwarded. This is done 553 by considering: 555 - the incoming PW, 557 - possibly the contents of the frame's Layer2 header, and 559 - possibly some forwarding information which may be statically or 560 dynamically maintained. 562 If dynamic or static forwarding information is considered, the 563 information is specific to a particular L2VPN instance (i.e. to a 564 particular VPN). 566 The procedures used to make the forwarding decision are known as a 567 "forwarder". We may think of a PW as being "bound", at each of its 568 endpoints, to a forwarder. The forwarder in turn "binds" the PWs to 569 ACs. Different types of L2VPN have different types of forwarders. 571 For instance, a forwarder may bind a single AC to a single PW, 572 ignoring all frame contents and using no other forwarding 573 information. Or a forwarder may bind an AC to a set of PWs and ACs, 574 moving individual frames from AC to PW, from a PW to an AC or from AC 575 to AC by comparing information from the frame's Layer2 header to 576 information in a forwarding database. This is discussed in more 577 detail below, as we consider the different L2VPN types. 579 3.2.4. Tunnels 581 A PW is carried in a "tunnel" from PE1 to PE2. We assume that an 582 arbitrary number of PWs may be carried in a single tunnel; the only 583 requirement is that the PWs all terminate at PE2. 585 We do not even require that all the PWs in the tunnel originate at 586 PE1; the tunnels may be multipoint-to-point tunnels. Nor do we 587 require that all PWs between the same pair of PEs travel in the same 588 tunnel. All we require is that when a frame traveling through such a 589 tunnel arrives at PE2, PE2 will be able to associate it with a 590 particular PW. 592 (While one can imagine tunneling techniques that only allow one PW 593 per tunnel, they have evident scalability problems, and we do not 594 consider them further.) 596 There are a variety of different tunneling technologies which may be 597 used for the PE-PE tunnels. All that is really required is that the 598 tunneling technologies allow the proper demultiplexing of the 599 contained PWs. The tunnels might be MPLS LSPs, L2TP tunnels, IPsec 600 tunnels, MPLS- in-IP tunnels, etc. Generally the tunneling 601 technology will require the use of an encapsulation that contains a 602 demultiplexor field, where the demultiplexor field is used to 603 identify a particular PW. Procedures for setting up and maintaining 604 the tunnels are not within the scope of this framework. (But see 605 section 3.2.6, "Pseudowire Signaling".) 607 If there are multiple tunnels from PE1 to PE2, it may be desirable to 608 assign a particular PE1-PE2 PW to a particular tunnel based on some 609 particular characteristics of the PW and/or the tunnel. For example, 610 perhaps different tunnels are associated with different QoS 611 characteristics, and different PWs require different QoS. Procedures 612 for specifying how to assign PWs to tunnels are out of scope of the 613 current framework. 615 Though point-to-point PWs are bidirectional, the tunnels in which 616 they travel need not be either bidirectional or point-to-point. For 617 example, a point-to-point PW may travel within a unidirectional 618 multipoint-to- point MPLS LSP. 620 3.2.5. Encapsulation 622 As L2VPN packets are carried in pseudowires, standard pseudowire 623 encapsulation formats and techniques (as specified by the IETF's PWE3 624 WG) should be used wherever applicable. 626 Generally the PW encapsulations will themselves be encapsulated 627 within a tunnel encapsulation, as determined by the specification of 628 the tunneling protocol. 630 It may be necessary to define additional PW encapsulations to cover 631 areas that are of importance for L2VPN, but may not be within the 632 scope of PWE3. Heterogeneous transport may be an instance of this. 634 3.2.6. Pseudowire Signaling 636 Procedures for setting up and maintaining the PWs themselves are 637 within the scope of this framework. This includes procedures for 638 distributing demultiplexor field values, even though the 639 demultiplexor field, strictly speaking, belongs to the tunneling 640 protocol rather than to the PW. 642 The signaling for a point-to-point pseudowire must perform the 643 following functions: 645 - Distribution of the demultiplexor. 647 Since many PWs may be carried in a single tunnel, the tunneling 648 protocol must assign a demultiplexor value to each PW. These 649 demultiplexors must be unique with respect to a given tunnel (or 650 with some tunneling technologies, unique at the egress PE). 651 Generally, the PE which is the egress of the tunnel will select 652 the demultiplexor values, and will distribute them to the PE(s) 653 which is (are) the ingress(es) of the tunnel. This is the 654 essential part of the PW setup procedure. 656 Note that, as is usually the case in tunneling architectures, the 657 demultiplexor field belongs to the tunneling protocol, not to the 658 protocol being tunneled. For this reason, the PW setup protocols 659 may be extensions of the control protocols for setting up the 660 tunnels. 662 - Selection of the Forwarder at the Remote PE. 664 The signaling protocol must contain enough information to enable 665 the remote PE to select the proper forwarder to which the PW is 666 to be bound. We can call this information the "Remote Forwarder 667 Selector". The information that is required will depend on the 668 type of L2VPN being provided and on the provisioning model (see 669 sections 3.3.1 and 3.4.2) being used. The Remote Forwarder 670 Selector may uniquely identify a particular Forwarder, or it may 671 identify an attribute of Forwarders. In the latter case, it would 672 select whichever Forwarder has been provisioned with that 673 attribute. 675 - Support pseudowire emulations. 677 To the extent that a particular PW must emulate the signaling of 678 a particular Layer2 technology, the PW signaling must provide the 679 necessary functions. 681 - Distribution of State Changes. 683 Changes in the state of an AC may need to be reflected in changes 684 to the state of the PW to which the AC is bound, and vice versa. 685 The specification as to which changes need to be reflected in 686 what way would generally be within the province of the PWE3 WG. 688 - Establish pseudowire characteristics. 690 To the extent that one or more characteristics of a PW must be 691 known to and/or agreed upon by both endpoints, the signaling must 692 allow for the necessary interaction. 694 As specified above, signaling for point-to-point PWs must pass enough 695 information to allow a remote PE to properly bind a PW to a 696 Forwarder, and to associate a particular demultiplexor value with 697 that PW. Once the two PEs have done the proper PW/Forwarder bindings, 698 and have agreed on the demultiplexor values, the PW may be considered 699 to have been set up. If it is necessary to negotiate further 700 characteristics or parameters of a particular PW, or to passing 701 status information for a particular PW, the PW may be identified by 702 the demultiplexor value. 704 Signaling procedures for point-to-point pseudowires are most commonly 705 point-to-point procedures that are executed by the two PW endpoints. 706 There are however proposals to use point-to-multipoint signaling for 707 setting up point-to-point pseudowires, so this is included in the 708 framework. When PWs are themselves point-to-multipoint, it is also 709 possible to use either point-to-point signaling or point-to- 710 multipoint signaling to set them up. This is discussed in the 711 remainder of this section. 713 3.2.6.1. Point-to-Point Signaling 715 There are several ways to do the necessary point-to-point signaling. 716 Among them are: 718 - LDP 720 LDP extensions can be defined for pseudowire signaling. See for 721 example [PWE3-LDP], [L2VPN-SIGNALING]. This form of signaling 722 can be used for pseudowires which are to be carried in MPLS 723 "tunnels", or in MPLS-in-something-else tunnels (e.g., [MPLS-IP- 724 GRE]). 726 - L2TP 728 L2TP [L2TP-BASE] can be used for pseudowire signaling, resulting 729 in pseudowires that are carried as "sessions" within L2TP 730 tunnels. Pseudowire-specific extensions to L2TP may also be 731 needed. 733 Other methods may be possible as well. 735 It is possible to have one control connection between a pair of PEs, 736 which is used to control many PWs. 738 The use of point-to-point signaling for setting up point-to-point PWs 739 is straightforward. Multipoint-to-point PWs can also be set up by 740 point- to-point signaling, as the remote PEs do not necessarily need 741 to know whether the PWs are multipoint-to-point or point-to-point. 742 In some signaling procedures, the same demultiplexor value may be 743 assigned to all the remote PEs. 745 3.2.6.2. Point-to-Multipoint Signaling 747 Consider the following situation: 749 - It is necessary to set up a set of PWs, all of which have the 750 same characteristics. 752 - It is not necessary to use the PW signaling protocol to pass PW 753 state changes. 755 - For each PW in the set, the same value of the Remote Forwarder 756 Selector can be used. 758 Call these the "Environmental Conditions". 760 Suppose also that there is some mechanism by which, given a range of 761 demultiplexor values, each of a set of PEs can make a unique and 762 deterministic selection of a single value from within that range. 763 Call this the "Demultiplexor Condition". Alternatively, suppose that 764 one is trying to set up a multipoint-to-point PW rather than a 765 point-to-point PW. Call this the "Multipoint Condition". 767 If: 769 - The Environmental Conditions hold, and 771 - Either 773 * the Demultiplexor Condition holds, or 775 * the Multipoint Condition holds, 777 then for a given set of PWs which terminate at egress PE1, the 778 information which PE1 needs to send to the ingress PE(s) of each 779 pseudowire in the set is exactly the same. All the ingress PE(s) 780 receive the same Forwarder Selector value. They all receive the same 781 set of PW parameters (if any). And either they all receive the same 782 demultiplexor value (if the PW is multipoint-to-point) or they all 783 receive a range of demultiplexor values from which each can choose a 784 unique demultiplexor value for itself. 786 Rather than connecting to each ingress PE and replicating the same 787 information, it may make sense either to multicast the information, 788 or to send the information once to a "reflector", which will then 789 take responsibility for distributing the information to the other 790 PEs. 792 We refer to this sort of technique as "point-to-multipoint" 793 signaling. It would, for example, be possible to use BGP to do the 794 signaling, with the PEs being BGP peers not of each other, but of one 795 or more BGP route reflectors. 797 Such a scheme, based Multi-protocol Extensions to BGP, is proposed in 798 [L2VPN-BGP]. 800 3.2.6.3. Inter-AS Considerations 802 Pseudowires may need to run from a PE in one Service Provider's 803 network to a PE in another Service Provider's network. This means 804 that the signaling to set up the PEs must be able to cross network 805 boundaries. All known proposals for signaling are able to do this. It 806 is especially advisable to use some form of authentication between 807 the two PW endpoints in this case. 809 3.2.7. Service Quality 811 Service Quality refers to the ability for the network to deliver a 812 Service level Specification (SLS) for service attributes such as 813 protection, security and Quality of Service (QoS). The service 814 quality provided depends on the subscriber's requirements, and can be 815 characterized by a number of performance metrics. 817 The necessary Service Quality must be provided on the ACs as well as 818 on the PWs. Mechanisms for providing Service Quality on the PWs may 819 be PW- specific or tunnel-specific; in the latter case, the 820 assignment of a PW to a tunnel may depend on the Service Quality. 822 3.2.7.1. Quality of Service (QoS) 824 QoS describes the queuing behavior applied to a particular "flow", in 825 order to achieve particular goals of precedence, throughput, delay, 826 jitter, etc. 828 Based on the customer Service Level Agreement (SLA), traffic from 829 customer can be prioritized, policed and shaped for QoS requirements. 830 The queuing and forwarding policies can preserve the packet order and 831 QoS parameters of customer traffic. The class of services can be 832 mapped from information in the customer frames, or it can be 833 independent of the frame content. 835 QoS functions can be listed as follows: 837 - Customer Traffic Prioritization: L2VPN services could be best 838 effort or QoS guaranteed. Traffic from one customer might need to 839 be prioritized over others when sharing same network resources. 840 This requires capabilities within the L2VPN solution to classify 841 and mark priority to QoS guaranteed customer traffic. 843 - Proper queuing behavior would be needed at the egress AC, and 844 possibly within the backbone network as well. If queuing behavior 845 must be controlled within the backbone network, the control might 846 be based on CoS information in the MPLS or IP header, or it might 847 be achieved by nesting particular tunnels within particular 848 traffic engineering tunnels. 850 - Policing: This ensures that a user of L2VPN services uses network 851 resources within the limits of the agreed SLA. Any excess L2VPN 852 traffic can be rejected or handled differently based on provider 853 policy. 855 - Policing would generally be applied at the ingress AC. 857 - Shaping: Under some cases the random nature of L2VPN traffic 858 might lead to sub-optimal utilization of network resources. 859 Through queuing and forwarding mechanisms the traffic can be 860 shaped without altering the packet order. 862 - Shaping would generally be applied at the ingress AC. 864 3.2.7.2. Resiliency 866 Resiliency describes the ability of the L2VPN infrastructure to 867 protect a flow from network outage, so that service remains available 868 in the presence of failures. 870 L2VPN, like any other service, is subject to failures such as link, 871 trunk and node failures, both in the SP's core network infrastructure 872 and on the ACs. 874 It is desirable that the failure be detected "immediately" and 875 protection mechanisms allow fast restoration times to make L2VPN 876 service almost transparent to these failures to the extent possible, 877 based on the level of resiliency. Restoration should take place 878 before the CEs can react to the failure. Essential aspects of 879 providing resiliency are: 881 - Link/Node failure detection: Mechanisms within the L2VPN service 882 should allow for link or node failures that impact the Service, 883 and should be detected immediately. 885 - Resiliency policy: The way in which a detected failure is handled 886 will depend upon the restoration policy of the SLA associated 887 with the L2VPN service specification. It may need to be handled 888 immediately, or it may need to be handled only if no other 889 critical failure needs protection resources, or it may be 890 completely ignored if it is within the bounds of the "acceptable 891 downtime" allowed by the L2VPN service. 893 - Restoration Mechanisms: The L2VPN solutions could allow for 894 physical level protection, logical level protection or both. For 895 example, by connecting customers over redundant and physically 896 separate ACs to different provider customer-facing devices, one 897 AC can be maintained as active while the other could be marked as 898 a backup; upon the failure detection across the primary AC, the 899 backup could become active. 901 To a great extent, resiliency is a matter of having appropriate 902 failure and recovery mechanisms in the network core, including 903 "ordinary" adaptive routing as well as "fast reroute" capabilities. 904 The ability to support redundant ACs between CEs and PEs also plays a 905 role. 907 3.2.8. Management 909 An L2VPN solution can provide mechanisms to manage and monitor 910 different L2VPN components. From a Service Level Agreement (SLA) 911 perspective, L2VPN solutions could allow monitoring of L2VPN service 912 characteristics and offer mechanisms used by Service Providers to 913 report such monitored statistical data. Trouble-shooting and 914 verification of operational and maintenance activities of L2VPN 915 services are essential requirements for Service Providers. 917 3.3. VPWS 919 A VPWS is an L2VPN service in which each forwarder binds exactly one 920 AC to exactly one PW. Frames received on the AC are transmitted on 921 the PW; frames received on the PW are transmitted on the AC. The 922 content of a frame's Layer2 header plays no role in the forwarding 923 decision, except insofar as the Layer2 header contents are used to 924 associate the frame with a particular AC (as, e.g., the DLCI field of 925 a Frame Relay frame identifies the AC). 927 A particular combination of forms a "virtual circuit" 928 between two CE devices. 930 A particular VPN (VPWS instance) may be thought of as a collection of 931 such virtual circuits, or as an "overlay" of PWs on the MPLS or IP 932 backbone. This creates an overlay topology that is in effect the 933 "virtual backbone" of a particular VPN. 935 Whether two virtual circuits are said to belong to the same VPN or 936 not is an administrative matter, based on the agreements between the 937 SPs and their customers. This may impact the provisioning model 938 (discussed below). It may also affect how particular PWs are 939 assigned to tunnels, the way QoS is assigned to particular ACs and 940 PWs, etc. 942 Note that VPWS makes use of point-to-point PWs exclusively. 944 VPWS solutions are found e.g. in [L2VPN-BGP] and [L2VPN-SIGNALING]. 946 3.3.1. Provisioning and Auto-Discovery 948 Provisioning a VPWS is a matter of: 950 1. Provisioning the ACs 952 2. Providing the PEs with the necessary information to enable them 953 to set up PWs between ACs to result in the desired overlay 954 topology. 956 3. Configuring the PWs with any necessary characteristics 958 3.3.1.1. Attachment Circuit Provisioning 960 In many cases, the ACs must be individually provisioned on the PE 961 and/or CE. This will certainly be the case if the CE/PE attachment 962 technology is a switched network, such as ATM or FR, and the VCs are 963 PVCs rather than SVCs. It is also the case whenever the individual 964 Attachment Circuits need to be given specific parameters (e.g., QoS 965 parameters, guaranteed bandwidth parameters) that differ from circuit 966 to circuit. 968 There are also cases in which ACs might not have to be individually 969 provisioned. E.g., if an AC is just an MPLS LSP running between a CE 970 and a PE, it could be set up as the RESULT of a PW being set up, 971 rather than having to be provisioned BEFORE the PW can be set up. The 972 same may apply whenever the AC is a Switched Virtual Circuit of any 973 sort, though in this case, various policy controls might need to be 974 provisioned, e.g., limiting the number of ACs that can be set up 975 between a given CE and a given PE. 977 Issues such as whether the Attachment Circuits need to be 978 individually provisioned or not, whether they are Switched VCs or 979 Permanent VCs, and what sorts of policy controls may be applied, are 980 implementation and deployment issues, and are considered to be out of 981 scope of this framework. 983 3.3.1.2. PW Provisioning for Arbitrary Overlay Topologies 985 In order to support arbitrary overlay topologies, it is necessary to 986 allow the provisioning of individual PWs. In this model, when a PW 987 is provisioned on a PE device, it is locally bound to a specific AC. 988 It is also provisioned with information that identifies a specific AC 989 at a remote PE. 991 There are basically two variations of this provisioning model: 993 - Two-sided provisioning 995 With two-sided provisioning, each PE that is at the end of a PW 996 is provisioned with the following information: 998 * Identifier of the Local AC to which the PW is to be bound 1000 * PW type and parameters 1002 * IP address of the remote PE (i.e., the PE which is to be at 1003 the remote end of the PW) 1005 * Identifier which is meaningful to the remote PE, and which 1006 can be passed in the PW signaling protocol to enable the 1007 remote PE to bind the PW to the proper AC. This can be an 1008 identifier of the pseudowire (as in [PWE3-LDP]), or an 1009 identifier of the remote AC (as in [L2VPN-SIGNALING]). If a 1010 PW identifier is used, it must be unique at each of the two 1011 PEs. If an AC identifier is used, it need only be unique at 1012 the remote PE. 1014 This identifier is then used as the Remote Forwarder Selector 1015 when signaling is done (see 3.2.6.1). 1017 - Single-sided Provisioning 1019 With single sided provisioning, a PE at one end of a PW is 1020 provisioned with the following information: 1022 * Identifier of the Local AC to which the PW is to be bound 1024 * PW type and parameters 1026 * Globally unique identifier of remote AC 1028 This identifier is then used as the Forwarder Selector when 1029 signaling is done (see section 3.2.6.1). 1031 In this provisioning model, the IP address of the remote PE is 1032 not provisioned. Rather, the assumption is that an auto- 1033 discovery scheme will be used to map the globally unique 1034 identifier to the IP address of the remote PE, along with an 1035 identifier (perhaps unique only at the latter PE) for an AC at 1036 that PE. The PW signaling protocol can then make a connection to 1037 the remote PE, passing the AC identifier, so that the remote PE 1038 binds the PW to the proper AC. (See, for example, [L2VPN- 1039 SIGNALING].) 1041 This scheme requires provisioning of the PW at only one PE, but 1042 does not eliminate the need (if there is a need) to provision the 1043 ACs at both PEs. 1045 These provisioning models fit well with the use of point-to-point 1046 signaling. When each PW is individually provisioned, as the 1047 conditions necessary for the use of point-to-multipoint signaling do 1048 not hold. 1050 3.3.1.3. Colored Pools PW Provisioning Model 1052 Suppose that at each PE, sets of ACs are gathered together into 1053 "pools", and that each such pool is assigned a "color". (For 1054 example, a pool might contain all and only the ACs from this PE to a 1055 particular CE.) Now suppose we impose the following rule: whenever 1056 PE1 and PE2 have a pool of the same color, there will be a PW between 1057 PE1 and PE2 which is bound at PE1 to an arbitrarily chosen AC from 1058 that pool, and at PE2 to an arbitrarily chosen AC from that pool. 1059 (We do not rule out the case where a single PE has multiple pools of 1060 a given color.) 1062 For example, each pool in a particular PE might represent a 1063 particular CE device, with the ACs in the pool being the ACs 1064 connecting that CE to that PE. The color might be a VPN-id. 1065 Application of this provisioning model would then lead to a full CE- 1066 to-CE mesh within the VPN, where every CE in the VPN has a virtual 1067 circuit to every other CE within the VPN. 1069 More specifically, to provision VPWS according to this model, one 1070 provisions a set of pools, and configures each pool with the 1071 following information: 1073 - The set of ACs that belong to the pool (with no AC belonging to 1074 more than one pool) 1076 - The color 1078 - A pool identifier that is unique at least relative to the color. 1080 An auto-discovery procedure is then used to map each color into a 1081 list of ordered pairs . The 1082 occurrence of a pair on this list means that the PE at IP 1083 address X has a pool with pool id Y which is of the specified 1084 color. 1086 This information can be used to support several different 1087 signaling techniques. One possible technique proceeds as 1088 follows: 1090 - A PE finds that it has a pool of color C. 1092 - Using auto-discovery, it obtains the set of ordered pairs 1093 for color C. 1095 - For each such pair , it: 1097 * removes an AC from the pool 1099 * binds the AC to a particular PW 1101 * signals PE X via point-to-point signaling that the PW is to 1102 be bound to an AC from pool Y. 1103 This sort of technique is discussed in [L2VPN-SIGNALING]. 1105 Another possible signaling technique is the following: 1107 - A PE finds that it has a pool of color C, containing n ACs. 1109 - It binds each AC to a PW, creating a set of PWs. This set of PWs 1110 is then organized into a sequence. (For instance, each PW may be 1111 associated with a demultiplexor field value, and the PWs may then 1112 be sequenced according to the numerical value of their respective 1113 demultiplexors.) 1115 - Using auto-discovery, it obtains the list of PE routers that have 1116 one or more pools of color C. 1118 - It signals each such PE router, specifying the sequence Q of PWs. 1120 - If PE X receives such a signal, and PE X has a pool Y of the 1121 specified color, it: 1123 * removes an AC from the pool 1125 * binds the AC to the PW which is the "Yth" PW in the sequence 1126 Q. 1128 This presumes, of course, that the pool identifiers are or can be 1129 uniquely mapped into small ordinal numbers; assigning the pool 1130 identifiers in this way becomes a requirement of the provisioning 1131 system. 1133 Note that since this technique signals the same information to all 1134 the remote PEs, it can be supported via point-to-multipoint 1135 signaling. This sort of scheme is discussed in [L2VPN-BGP]. 1137 This provisioning model can be applied as long as the following 1138 conditions hold: 1140 - There is no need to provision different characteristics for the 1141 different PWs, and 1143 - It makes no difference which pairs of ACs are bound together by 1144 PWs, as long as both ACs in the pair come from like-colored 1145 pools, and 1147 - It is possible to construct the desired overlay topology simply 1148 by assigning colors to the pools. (This is certainly simple if a 1149 full mesh is desired, or if a hub and spoke configuration is 1150 desired; creating arbitrary topologies is less simple, and 1151 perhaps not always possible.) 1153 3.3.2. Requirements on Auto-Discovery Procedures 1155 Some of the requirements for auto-discovery procedures can be deduced 1156 from the above. 1158 To support the single-sided provisioning model, auto-discovery must 1159 be able to map a globally unique identifier (of a PW or of an 1160 Attachment Circuit) to an IP address of a PE. 1162 To support the colored pools provisioning model, auto-discovery must 1163 enable a PE to determine the set of other PEs that contain pools of 1164 the same color. 1166 Examples of suitable auto-discovery procedures can be found in 1167 Examples of suitable auto-discovery procedures can be found in 1168 [L2VPN-BGP], [BGP-AUTO] and [L2VPN-SIGNALING], and [VPLS-L2TP-RAD]. 1170 These requirements enable the auto-discovery scheme to provide the 1171 information, which the PEs need to set up the PWs. 1173 There are additional requirements on the auto-discovery procedures 1174 that cannot simply be deduced from the provisioning model: 1176 - Particular signaling schemes may require additional information 1177 before they can proceed, and hence may impose additional 1178 requirements on the auto-discovery procedures. 1180 - A given Service Provider may support several different types of 1181 signaling procedures, and thus the PEs may need to learn, via 1182 auto- discovery, which signaling procedures to use. 1184 - Changes in the configuration of a PE should be reflected by the 1185 auto-discovery procedures, within a timely manner, and without 1186 the need to explicitly reconfigure any other PE. 1188 - The auto-configuration procedures must work across service 1189 provider boundaries. This rules out, e.g., the use of schemes 1190 that piggyback the auto-discovery information on the backbone's 1191 IGP. 1193 3.3.3. Heterogeneous Pseudowires 1195 Under certain circumstances, it may be desirable to have a PW that 1196 binds two ACs that use different technologies (e.g., one is ATM, one 1197 is Ethernet). There are a number of different ways, depending on the 1198 AC types, in which this can be done. For example: 1200 - If one AC is ATM and one is FR, then standard ATM/FR Network 1201 Interworking can be used. In this case, the PW might be signaled 1202 for ATM, with the Interworking function occurring between the PW 1203 and the FR AC. 1205 - A common encapsulation can be used on both ACs, e.g., if one AC 1206 is Ethernet and one is FR, an "Ethernet over FR" encapsulation 1207 can be used on the latter. In this case, the PW could be 1208 signaled for Ethernet, with the processing of the Ethernet over 1209 FR encapsulation being local to the PE with the FR AC. 1211 - If it is known that the two ACs attach to IP routers or hosts, 1212 and carry only IP traffic, then one could use a PW which carries 1213 the IP packets, and the respective Layer2 encapsulations would be 1214 local matters for the two PEs. However, if one of the ACs is a 1215 LAN and one is a point-to-point link, care would have to be taken 1216 to ensure that such procedures as ARP and Inverse ARP are 1217 properly handled; this might require some signaling, and some 1218 proxy functions. Further, if the CEs use a routing algorithm that 1219 has different procedures for LAN interfaces than for point-to- 1220 point interfaces, additional mechanisms may be required to ensure 1221 proper interworking. These issues are discussed in [ARP- 1222 MEDIATION]. 1224 3.4. VPLS Emulated LANs 1226 A VPLS is an L2VPN service in which: 1228 - the ACs attach CE devices to PE bridge modules, 1230 - each PE bridge module is attached via an "emulated LAN interface" 1231 to an "emulated LAN" 1233 This is shown in Figure 3. 1235 In this section, we examine the functional decomposition of the VPLS 1236 Emulated LAN. An Emulated LAN's ACs are the "emulated LAN 1237 interfaces" attaching PE bridge modules to the "VPLS Forwarder" 1238 modules (see Figure 3). The payload on the ACs consists of ethernet 1239 frames, with or without VLAN headers. 1241 A given VPLS Forwarder in a given PE will have multiple ACs only if 1242 there are multiple bridge modules in that PE which attach to that 1243 Forwarder. This scenario is included in the Framework, though 1244 discussion of its utility is out of scope. 1246 The set of VPLS Forwarders within a single VPLS are connected via 1247 PWs. Two VPLS Forwarders will have a PW between them only if those 1248 two Forwarders are part of the same VPLS. (There may be a further 1249 restriction that two VPLS Forwarders have a PW between them only if 1250 those two Forwarders belong to the same VLAN in the same VPN.) A 1251 particular set of interconnected VPLS Forwarders is what constitutes 1252 a VPLS Emulated LAN. 1254 On a real LAN, any frame transmitted by one entity is received by all 1255 the others. A VPLS Emulated LAN, however, behaves somewhat 1256 differently. When a VPLS Forwarder receives a unicast frame over one 1257 of its Emulated LAN interfaces, the Forwarder does not necessarily 1258 send the frame to all the other Forwarders on that Emulated LAN. A 1259 unicast frame need be sent to only one other Forwarder in order to be 1260 properly delivered to its destination MAC address. If the 1261 transmitting Forwarder knows which other Forwarder needs to receive a 1262 particular unicast frame, it will send the frame to just that one 1263 Forwarder. This forwarding optimization is an important part of any 1264 attempt to provide a VPLS service over a wide-area or metropolitan 1265 area network. 1267 In effect then each Forwarder behaves as a "Virtual Switch Instance" 1268 (VSI), maintaining a forwarding table in which maps MAC addresses to 1269 PWs. The VSI is populated in much the same was as a standard bridge 1270 populates its forwarding table. The VPLS Forwarders do MAC SA 1271 learning on frames received on PWs from other Forwarders, and must 1272 also do the related set of procedures, such as the aging out of 1273 address entries. Frames with unknown DAs or multicast DAs must be 1274 "broadcast" by one Forwarder to all the others (on the same emulated 1275 LAN). There are however a few important differences between the VPLS 1276 Forwarder VSI and the standard bridge forwarding function: 1278 - A VPLS Forwarder never learns the MAC SAs of frames which it 1279 receives on its ACs, it only learns the MAC SAs of frames which 1280 are received on PWs from other VPLS Forwarders; 1282 - The VPLS Forwarders of a particular emulated LAN do not 1283 participate in a spanning tree protocol with each other. A 1284 "split horizon" technique is used to prevent forwarding loops. 1286 These points are discussed further in the next section. 1288 Note that the PE bridge modules which are on a given Emulated LAN may 1289 or may not run spanning tree protocol with each other over the 1290 Emulated LAN; whether they do so or not is outside the scope of the 1291 VPLS specifications. The PE bridge modules will do MAC address 1292 learning on the ACs. The PE bridge modules also do MAC address 1293 learning on the Emulated LAN interfaces, but do not do MAC address 1294 learning on the PWs, as the PWs are "hidden" behind the Emulated LAN 1295 interface. Conceptually, the PE bridge module's forwarding table and 1296 the VPLS Forwarder's VSI are distinct entities. (Of course, 1297 particular implementations might combine these into a single table, 1298 but that is beyond the scope of this document.) 1300 A further issue does arise in the case where the PE bridges do run 1301 bridge control protocols with each other over the Emulated LAN. 1302 Bridge control protocols are generally designed to run in over a real 1303 LAN, and may presume, for their proper functioning, certain 1304 characteristics of the LAN, such as low latency and sequential 1305 delivery. If the Emulated LAN does not provide these 1306 characteristics, the control protocols may not perform as expected 1307 unless special mechanisms are provided for carrying the control 1308 frames. 1310 It should be noted that changes in the spanning tree (if any) of a 1311 customer network, or in the spanning tree (if any) of the PE bridges, 1312 may cause certain MAC addresses to change their location from one PE 1313 to another. These changes may not be visible to the VPLS Forwarders, 1314 which means that those MAC addresses might become unreachable until 1315 they are aged out of the first PE's VSI. If this is not acceptable, 1316 some mechanism for communicating such changes to the VPLS Forwarders 1317 must be provided. 1319 VPLS solutions are found e.g. in [VPLS-L2TP-RAD], [VPLS-LDP], and 1321 [VPLS-BGP]. 1323 3.4.1. VPLS Overlay Topologies and Forwarding 1325 Within a single VPLS, the VPLS Forwarders are interconnected by PWs. 1326 The set of PWs thus forms an "overlay topology". 1328 The VPLS Forwarder VSIs are populated by means of MAC address 1329 learning. That is, the VSI keeps track of which MAC SAs have been 1330 received over which PWs. The presumption of course is that if a 1331 particular MAC address appears as the SA of a frame received over a 1332 particular PW, then frames which carry that MAC address in the DA 1333 field should be sent to the VSI which is at the remote end of the PW. 1334 In order for this presumption to be true, there must be a unique VSI 1335 at the remote end of the PW, which means that VSIs cannot be 1336 interconnected by means of multipoint-to-point PWs. The PWs are 1337 necessarily either point-to-point or, possibly, point-to-multipoint. 1339 MAC learning over a point-to-point PW is done via the standard 1340 techniques as specified by IEEE, where the PW is treated by the VPLS 1341 Forwarder as a "bridge port". Of course, if a MAC address is learned 1342 from a point-to-multipoint PW, the VSI must indicate that packets to 1343 that address are to be sent over a point-to-point PW which leads to 1344 the root of that point-to-multipoint PW. 1346 The VSI forwarding decisions must be coordinated so that loop-free 1347 forwarding over the overlay topology is ensured. 1349 There are several possible types of overlay topologies: 1351 - Full mesh 1353 In a full mesh, every VSI in a given VPLS has exactly one point- 1354 to-point PW to every other VSI in that same VPLS. 1356 In this topology, loop free forwarding of frames is ensured by 1357 the following rule: if a VSI receives a frame, over a PW, from 1358 another VSI, it MUST NOT forward that frame over ANY other PW to 1359 any other VSI. This ensures that once a frame traverses the 1360 Emulated LAN, it must be sent off the Emulated LAN. 1362 If a VSI receives, on one of its Emulated LAN interfaces, a 1363 unicast frame with a known DA, the frame is sent on exactly one 1364 point-to-point PW. 1366 If a VSI receives, on one of its Emulated LAN interfaces, a 1367 multicast frame or a unicast frame with unknown DA, it send a 1368 copy of the frame to each other VSI in the same Emulated LAN. 1369 This can be done by replicating the frame and sending a copy over 1370 each point-to-point PW. Alternatively, the full mesh of point- 1371 to-point PWs may be augmented with point-to-multipoint PWs, where 1372 each VSI in a VPLS is the transmitter on a single point-to- 1373 multipoint PW, and the receivers on that PW are all the other 1374 VSIs in that VPLS. 1376 - Tree Structured 1378 In a tree structured topology, every VSI in a particular VPLS is 1379 provisioned to be at a particular level in the tree. A given VSI 1380 has at most one pseudowire leading to a higher level. The root of 1381 the tree is considered to be the highest level. 1383 In this topology, loop free forwarding of frames is ensured by 1384 the following rule: if a frame is received over a pseudowire from 1385 a higher level, it may not be sent over a pseudowire that leads 1386 to a higher level. 1388 - Tree with Meshed Highest Level 1390 In this variant of the tree-structured topology, there may be 1391 more than one VSI at the highest level, but the set of VSIs which 1392 are at the highest level must be fully meshed. To ensure loop 1393 free forwarding, we need to impose the rule that a frame can be 1394 sent on a pseudowire to the same or higher level only if it 1395 arrived over a pseudowire from a lower level, and frames arriving 1396 over PWs from the same level cannot be sent on PWs to the same 1397 level. 1399 Other overlay topologies are also possible, e.g., an arbitrary 1400 partial mesh of PWs among the VSIs of a VPLS. Loop-freedom could 1401 then be assured by, for example, running spanning tree on the 1402 overlay. These topologies are not further considered in this 1403 framework. 1405 Note that loop freedom in the overlay topology does not necessarily 1406 ensure loop freedom in the overall customer LAN that contains the 1407 VPLS. It does not even ensure loop freedom among the PE bridge 1408 modules. It ensures only that when a frame is sent on the Emulated 1409 LAN, the frame will not loop endlessly before (or instead of) leaving 1410 the Emulated LAN. 1412 Improper configuration of the customer LAN or PE bridge modules may 1413 cause frames to loop, and frames that fall into such loops may 1414 transit the overlay topology multiple times. Procedures that enable 1415 the PE to detect and/or prevent such loops may be advisable. 1417 3.4.2. Provisioning and Auto-Discovery 1419 Each VPLS must be assigned a globally unique identifier. This can be 1420 thought of as a VPN-id. 1422 The ACs attaching the CEs to the PEs must be provisioned on both the 1423 PEs and the CEs. A VSI for that VPLS must be provisioned on the PE, 1424 and the local ACs of that VPLS must be associated with that VSI. The 1425 VSI must be provisioned with the identifier of the VPLS to which it 1426 belongs. 1428 An auto-discovery scheme may be used by a PE to map a VPLS identifier 1429 into the set of remote PEs that have VSIs in that VPLS. Once this 1430 set is determined, the PE can use pseudowire signaling to set up a PW 1431 to each of those VSIs. The VPLS identifier would serve as the 1432 signaling protocol's Forwarder Selector. This would result in a full 1433 mesh of PWs among the VSIs in a particular VPLS. 1435 If a single VPLS contains multiple VLANs, then it may be desirable to 1436 limit connectivity so that two VSIs are connected only if they have a 1437 VLAN in common. 1439 In this case, each VSI would need to be provisioned with one or more 1440 VLAN ids, and the auto-discovery scheme would need to map a VPLS 1441 identifier into pairs of . 1443 If a fully meshed topology of VSIs is not desired, then each VSI 1444 needs to be provisioned with additional information specifying its 1445 placement in the topology. This information would also need to be 1446 provided by the auto-discovery scheme. 1448 Examples of suitable auto-discovery procedures can be found in 1449 [L2VPN-BGP], [BGP-AUTO] and [L2VPN-SIGNALING], and [VPLS-L2TP-RAD]. 1451 Alternatively, the single-sided provisioning method discussed in 1452 section 3.3.1.2 could be used. As this is more complicated, it would 1453 only be used if it were necessary to associate individual PWs with 1454 individual characteristics. For example, if different guaranteed 1455 bandwidths were needed between different pairs of sites within a 1456 VPLS, the PWs would have to be individually provisioned. 1458 3.4.3. Distributed PE 1460 Often when a VPLS type of service is provided, the CE devices attach 1461 to a provider-managed CPE device. This provider-managed CPE device 1462 may attach to CEs of multiple customers, especially if, e.g., there 1463 are multiple customers occupying the same building. However, this 1464 device is really part of the SP's network, hence may be considered to 1465 be a PE device. 1467 In some scenarios when a VPLS type of service is provided, the CE 1468 devices attach to a provider-managed intermediary device. This 1469 provider- managed device may attach to CEs of multiple customers. 1470 This may arise in a situation there multiple customers occupying the 1471 same building. This device is really part of the SP's network, and 1472 may for that reason be considered to be a PE device, however in the 1473 simplest case it is only performing aggregation and none of the 1474 function associated with a VPLS. 1476 Relative to the VPLS there are three different possibilities to 1477 allocate functions to a device in such a position in the provider 1478 network: 1480 - it can perform aggregation and pure Layer2 service only, in which 1481 case it does not really play the role of a PE device in a VPLS 1482 service. In this case the intermediary system must connect to 1483 devices that perform VPLS PE functionality; the intermediary 1484 device itself is not part of the VPLS architecture and has hence 1485 not been named in this architecture. 1487 - it can perform all the PE functions relevant for a VPLS, in such 1488 a case the device is called VPLS-PE, see [PPVPN-TERM]. This type 1489 of device will be connected to the core (P) routers. 1491 The PE functionality for a VPLS may be distributed between two 1492 devices, one "low-end" closer to the customer that performs e.g. the 1493 MAC-address learning and forwarding decisions, and one "high-end" 1494 that performs the control functions, e.g. establishing tunnels, PWs 1495 and VCs. We call the low-end device User-Facing PE (U-PE) and the 1496 high-end device Network- Facing PE (N-PE). 1498 It is conceivable that the U-PE may be placed very close to the 1499 customer, e.g. in a building with more than one customer. The N-PE 1500 will presumably be placed on the SP's premises. PE-POP, will 1501 presumably be placed on the SP's premises. 1503 The distributed case is potentially of interest for a number of 1504 possible reasons: 1506 - The N-PE may be a device that cannot easily implement the VSI 1507 functionality described above. E.g., perhaps the N-PE is a router 1508 which cannot perform the high speed MAC learning that is needed 1509 in order to implement a VSI forwarder. At the same time, the U-PE 1510 may need to be a low-cost device that also cannot implement the 1511 full set of VPLS functions. 1513 This leads one to investigate further if there are sensible ways 1514 to split the VPLS PE functionality between the U-PE and the N-PE. 1516 - Generally, in the L2VPN architecture, the PEs are expected to 1517 participate as peers in the backbone routing protocol. Since the 1518 number of U-PEs is potentially very large relative to the number 1519 of N-PEs, this may be undesirable, as a matter of scaling the 1520 backbone routing protocol. 1522 - The U-PE may be a relatively inexpensive device that is unable to 1523 participate in the full range of signaling and/or auto-discovery 1524 procedures that are needed in order to provide the VPLS service. 1526 The VPLS functionality can be distributed between U-PE and N-PE in a 1527 number of different ways, and a number of different proposals have 1528 been made. They all presume that the U-PE will maintain a VSI 1529 forwarder, connected by PWs to the remote VSIs; the N-PE thus does 1530 not need to perform the VSI forwarding function. The proposals tend 1531 to differ with respect to the following questions: 1533 - Should the U-PEs perform full PW signaling to set up the PWs to 1534 remote VSIs? Or should the N-PEs do this signaling? 1536 Since the U-PEs need to be able to send packets on PWs to remote 1537 VSIs and receive packets on PWs from remote VSIs, if the PW 1538 signaling is done by the N-PE, there would have to be some form 1539 of "lightweight" (presumably) signaling between N-PE and U-PE 1540 that allows the PWs to be extended from N-PE to U-PE. 1542 - Should the U-PEs do their own auto-discovery, or should this be 1543 done by the N-PEs? In the latter case, the U-PEs may need to have 1544 some means of telling the N-PEs which VPLS's they are interested 1545 in, and the N-PEs must have some means of passing the results of 1546 the auto-discovery process to the U-PE. 1548 Whether it makes sense to split auto-discovery in this manner may 1549 depend on the particular auto-discovery protocol used. One would 1550 not expect the U-PEs to participate in a BGP-based auto-discovery 1551 scheme, e.g., but perhaps they would be expected to participate 1552 in a RADIUS-based auto-discovery scheme. 1554 - If a U-PE does not participate in routing, but is redundantly 1555 connected to two different N-PEs, can the U-PE still make an 1556 intelligent choice of the best N-PE to use as the "next hop" for 1557 traffic destined to a particular remote VSI? If not, can this 1558 choice be made as the result of some other sort of interaction 1559 between N-PE and U-PE? Or does this choice need to be established 1560 by provisioning? 1562 - If a U-PE does not participate in routing, but does participate 1563 in full PW signaling, and if MPLS is being used, how can the the 1564 N-PE send the the U-PEs the labels that the U-PE needs to send 1565 traffic to its signaling peers. (If the U-PE did participate in 1566 routing, this would happen automatically.) 1568 - When a frame must be multicast, should the replication be done by 1569 the N-PE or the U-PE? 1571 These questions are not all independent; the way one answers some 1572 of them may influence the way one answers others. 1574 3.4.4. Scaling issues in VPLS deployment 1576 In general, the PSN supports a VPLS solution with a tunnel from each 1577 VPLS-PE every other VPLS-PE participating in the same VPLS instance. 1578 Strictly, VPLS-PE's with more than one VPLS instance in common only 1579 need one tunnel, but for resource allocation reasons it might be 1580 necessary to establish several tunnels. For each VPLS service on a 1581 given VPLS-PE it needs to establish one pseudowire to every other 1582 VPLS-PE participating in that VPLS service. In total n*(n-1) 1583 pseudowires must be setup between the VPLS-PE routers. In large scale 1584 deployment this obviously creates scaling problems. One way to 1585 address the scaling problems is to use hierarchy; this is discussed 1586 in [VPLS-LDP]. 1588 3.5. IP-only LAN-like Service (IPLS) 1590 If, instead of providing a general VPLS service, one wishes to 1591 provide a VPLS that is used only to connect IP routers or hosts 1592 (i.e., the CE devices are all assumed to be IP routers or hosts), 1593 then it is possible to make certain simplifications. 1595 In this environment, all Ethernet frames sent from a particular CE to 1596 a particular PE on a particular Attachment Circuit will have the same 1597 MAC Source Address. Thus rather than using address learning in the 1598 data plane to learn the MAC addresses, the PE can use the control 1599 plane to learn the MAC address. (See [ARP-MEDIATION] for a discussion 1600 of this.) This allows the PE to be implemented on devices that are 1601 not capable of doing MAC address learning in the data plane. 1603 To eliminate the need for MAC address learning on the PWs as well as 1604 on the ACs, the pseudowire signaling protocol would have to carry the 1605 MAC address from one pseudowire endpoint to the other. Each PE would 1606 perform proxy ARP to its directly attached CEs. 1608 Eliminating the need to do MAC address learning on the PWs eliminates 1609 the need for the PWs to be point-to-point. Multipoint-to-point PWs 1610 could be used instead. 1612 Unlike a VPLS, all the ACs in an IPLS would not necessarily have to 1613 carry Ethernet frames; only the IP packets would need to be passed 1614 across the network, not their Layer2 wrappers. However, this might 1615 require "translation" between "ARP" and "Inverse ARP". The set of 1616 routing protocols which could be carried across the IPLS might also 1617 be restricted. A fuller discussion of the advantages, disadvantages, 1618 and restrictions may be found in [ARP-MEDIATION]. 1620 4. Security Considerations 1622 The security considerations section of the L2VPN requirements 1623 document [L2VPN-REQ] addresses a number of areas that are potentially 1624 insecure aspects of the L2VPN. These relate to both control plane 1625 and data plane security issues that may arise in the following areas: 1627 - issues fully contained in the provider network 1629 - issues fully contained in the customer network 1631 - issues in the customer-provider interface network 1633 These three areas are addressed below. 1635 4.1. Provider Network Security Issues 1637 This section discusses security issues that only impact the SP's 1638 equipment. 1640 There are security issues having to do with the control connections 1641 that are used on a PE-PE basis for setting up and maintaining the 1642 pseudowires. 1644 A PE should not engage with another PE in a control connection unless 1645 it has some confidence that the peer is really a PE to which it 1646 should be setting up PWs. Otherwise L2PVN traffic may go to the 1647 wrong place. If control packets are maliciously and undetectably 1648 altered while in flight, denial of service, or alteration of the 1649 expected quality of service, may result. 1651 If peers discover each other dynamically (via some auto-discovery 1652 procedure), this presupposes that the auto-discovery procedures are 1653 themselves adequately trusted. 1655 PEs should not accept control connections from arbitrary entities; a 1656 PE should either be configured with its peers, or learn them from a 1657 trusted auto-configuration procedure. If the peer is required to be 1658 within the same SP's network, then access control filters at the 1659 borders of that network can be used to prevent spoofing of the peer's 1660 source address. If the peer is from another SP's network, then 1661 setting up such filters may be difficult or even impossible, 1662 depending on the way in which the two SPs are connected. Even if the 1663 access filters can be set up, the level of assurance which they 1664 provide will be lower. 1666 Thus for inter-SP control connections, it is advisable to use some 1667 sort of cryptographic authentication procedure. Control protocols 1668 which used TCP may use the TCP MD5 option to provide a measure of 1669 PE-PE authentication; this requires at least one shared secret 1670 between SPs. The use of IPsec between PEs is also possible, and 1671 provides a greater degree of assurance, though at a greater cost. 1673 When LDP [RFC3036] is used as the control protocol, the LDP security 1674 considerations discussed in [RFC3036] are applicable. Note that LDP 1675 uses both UDP as well as TCP. It may be advisable to have some 1676 protection against spoofed UDP messages which appear to be from a 1677 valid peer; this requires further study. 1679 Future versions of this document will discuss the security 1680 considerations that apply to other signaling protocols. 1682 To limit the effect of Denial of Service attacks on a PE, some means 1683 of limiting the rate of processing of control plane traffic may be 1684 desirable. 1686 Unlike authentication and integrity, privacy of the signaling 1687 messages is not usually considered very important. If it is needed, 1688 the signaling messages can be sent through an IPsec connection. 1690 4.2. Provider-Customer Network Security Issues 1692 There are a number of security issues related to the access network 1693 between the provider and the customer. This is also traditionally a 1694 network that is hard to protect physically. 1696 Typical security issues on the provider-customer interface include 1697 the following: 1699 - Preventing unauthorized members joining an L2VPN 1701 - Ensuring correct customer interface configured 1703 - Ensuring correct service delimiting fields (VLAN, DLCI, etc.) 1705 - Preventing unauthorized access to PE 1707 As the access network for an L2VPN service is necessarily a layer 2 1708 network, it is preferable to use authentication mechanisms that do 1709 not presuppose any IP capabilities on the CE device. 1711 There are existing layer 2 protocols and best current practices to 1712 guard against these security issues. For example, IEEE 802.1x 1713 defines authentication at the link level for access through an 1714 ethernet bridge; the Frame Relay Forum defines LMI extensions for 1715 authentication (FRF.17). 1717 4.3. Customer Network Security Issues 1719 Even if all CE devices are properly authorized to attach to their PE 1720 devices, misconfiguration of the PE may interconnect CEs that are not 1721 supposed to be in the same L2VPN. 1723 In a VPWS, the CEs may run IPsec to authenticate each other. Other 1724 layer 3 or layer 4 protocols may have their own authentication 1725 methods. 1727 In a VPLS, CE-to-CE IPsec is even more problematic, as IPsec does not 1728 well support the multipoint configuration which is provided by the 1729 VPLS service. 1731 There may be alternative methods for achieving a degree of CE-to-CE 1732 authentication, if the L2VPN signaling protocol can carry opaque 1733 objects between the CEs, either inband (over the L2VPN), or out-of- 1734 band, through the participation of the signaling protocol. This is 1735 for further study. 1737 The L2VPN procedures do not provide authentication, integrity, or 1738 privacy for the customer's traffic; if this is needed, it becomes the 1739 responsibility of the customer. 1741 If there is CE-to-CE control traffic (e.g., BPDUs), on whose 1742 integrity the customer's own layer 2 network depends, it may be 1743 advisable to send the control traffic using some more secure 1744 mechanism than is used for the data traffic. 1746 5. Intellectual Property Notice 1748 The IETF takes no position regarding the validity or scope of any 1749 intellectual property or other rights that might be claimed to 1750 pertain to the implementation or use of the technology described in 1751 this document or the extent to which any license under such rights 1752 might or might not be available; neither does it represent that it 1753 has made any effort to identify any such rights. Information on the 1754 IETF's procedures with respect to rights in standards-track and 1755 standards-related documentation can be found in BCP-11. Copies of 1756 claims of rights made available for publication and any assurances of 1757 licenses to be made available, or the result of an attempt made to 1758 obtain a general license or permission for the use of such 1759 proprietary rights by implementors or users of this specification can 1760 be obtained from the IETF Secretariat. 1762 The IETF invites any interested party to bring to its attention any 1763 copyrights, patents or patent applications, or other proprietary 1764 rights which may cover technology that may be required to practice 1765 this standard. Please address the information to the IETF Executive 1766 Director. 1768 6. Copyright Notice 1770 "Copyright (C) The Internet Society (date). All Rights Reserved. 1772 This document and translations of it may be copied and furnished to 1773 others, and derivative works that comment on or otherwise explain it 1774 or assist in its implementation may be prepared, copied, published 1775 and distributed, in whole or in part, without restriction of any 1776 kind, provided that the above copyright notice and this paragraph are 1777 included on all such copies and derivative works. However, this 1778 document itself may not be modified in any way, such as by removing 1779 the copyright notice or references to the Internet Society or other 1780 Internet organizations, except as needed for the purpose of 1781 developing Internet standards in which case the procedures for 1782 copyrights defined in the Internet Standards process must be 1783 followed, or as required to translate it into languages other than 1784 English. 1786 The limited permissions granted above are perpetual and will not be 1787 revoked by the Internet Society or its successors or assigns. 1789 This document and the information contained herein is provided on an 1790 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1791 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1792 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1793 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1794 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1796 7. Normative References 1798 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 1799 Requirement Levels", RFC 2119, March 1997. 1801 8. Informative References 1803 [ARP-MEDIATION] Shah, J. et. al., "ARP Mediation for IP interworking 1804 of Layer 2 VPN", draft-shah-ppvpn-arp-mediation-02.txt, Work in 1805 Progress, June 2003. 1807 [BGP-AUTO] Ould-Brahim, H. et.al. "Using BGP as an Auto-Discovery 1808 Mechanism for Network-based VPNs",draft-ietf-l3vpn-bgpvpn-auto- 1809 00.txt, Work in Progress, July 2003. 1811 [IPLS] Shah H., et.al. "IP-Only LAN Service (IPLS)", draft-shah- 1812 ppvpn-ipls-02.txt, June 2003. 1814 [L2TP-BASE] Lau, J. "Layer Two Tunneling Protocol (Version 3) 1815 L2TPv3", draft-ietf-l2tpext-l2tp-base-10.txt", Work in Progress, 1816 April 2003. 1818 [L2VPN-BGP] Kompella, K. et.al. "Layer 2 VPNs Over Tunnels", draft- 1819 kompella-ppvpn-l2vpn-03.txt, April 2003. 1821 [L2VPN-REQ] Augustyn, W. et.al "Service Requirements for Layer 2 1822 Provider Provisioned Virtual Private Networks", draft-ietf-l2vpn- 1823 requirements-00.txt, Work in Progress, May 2003. 1825 [L2VPN-SIGNALING] Rosen, E. "Provisioning Models and Endpoint 1826 Identifiers in L2VPN Signaling", draft-ietf-l2vpn-signaling-00.txt, 1827 Work in Progress, September 2003. 1829 [L3VPN-FW] Callon, R. et.al. "A Framework for Layer 3 Provider 1830 Provisioned Virtual Private Networks", draft-ietf-l3vpn-framework- 1831 00.txt, Work in Progress, Internet Draft, July 2003. 1833 [L3VPN-REQ] Carugi, M. et.al. "Service requirements for Layer 3 1834 Provider Provisioned Virtual Private Networks" draft-ietf-l3vpn- 1835 requirements-00.txt, Work in Progress, July 2003. 1837 [MPLS-IP-GRE] Worster, T., et. al., "Encapsulating MPLS in IP or 1838 GRE", draft-ietf-mpls-in-ip-or-gre-02.txt, Work in Progress, August 1839 2003. 1841 [PPVPN-TERM] Andersson, L. and Madsen T. "VPN Terminology", draft- 1842 andersson-ppvpn-terminology-04.txt", Work in Progress, September 1843 2003. 1845 [PWE3-ARCH] Bryant, S., "PWE3 Architecture", draft-ietf-pwe3-arch- 1846 05.txt, Work in Progress, August 2003. 1848 [PWE3-LDP] Martini, L. et.al. "Pseudowire Setup and Maintenance using 1849 LDP", draft-ietf-pwe3-control-protocol-03.txt, Work in Progress, July 1850 2003. 1852 [RFC3036] Andersson, L et.al. "LDP Specification", RFC 3036, Jan 1853 2001. 1855 [VPLS-BGP] Kompella, K. "Virtual Private LAN Service", draft-ietf- 1856 l2vpn-vpls-bgp-00.txt, Work in Progress, May 2003. 1858 [VPLS-L2TP-RAD] Heinanen, J, "Radius/L2TP Based VPLS", draft- 1859 heinanen-radius-l2tp-vpls-0-.txt, Work in Progress, February 2003. 1861 [VPLS-LDP] Lasserre, M. et.al. "Virtual Private LAN Services over 1862 MPLS", draft-ietf-l2vpn-vpls-ldp-00.txt, Work in progress, June 2003. 1864 9. Authors and Acknowledgments 1866 This document is the outcome of discussions within a PPVPN Layer 2 1867 VPN design team, all of whose members could be considered to be co- 1868 authors. Specifically, the co-authors are Loa Andersson, Waldemar 1869 Augustyn, Marty Borden, Hamid Ould-Brahim, Juha Heinanen, Kireeti 1870 Kompella, Vach Kompella, Marc Lasserre, Pascal Menezes, Vasile 1871 Radoaca, Eric Rosen, and Tissa Senevirathne. 1873 The authors would like to thank Marco Carugi for cooperation in 1874 setting up context, working directions and taking time for 1875 discussions in this space, Tove Madsen for valuable input and 1876 reviews, and Norm Finn, Matt Squires, and Ali Sajassi for valuable 1877 discussion of the VPLS issues. 1879 10. Authors' Contact Information 1881 Loa Andersson 1882 Email: loa@pi.se 1884 Eric C. Rosen 1885 Cisco Systems, Inc. 1886 1414 Massachusetts Avenue 1887 Boxborough, MA 01719 1888 Email: erosen@cisco.com 1890 Waldemar Augustyn 1891 Email: waldemar@nxp.com 1893 Marty Borden 1894 mborden@acm.org 1896 Juha Heinanen 1897 Song Networks, Inc. 1898 Hallituskatu 16 1899 33200 Tampere, Finland 1900 Email: jh@song.fi 1902 Kireeti Kompella 1903 Juniper Networks, Inc. 1904 1194 N. Mathilda Ave 1905 Sunnyvale, CA 94089 1906 Email: kireeti@juniper.net 1908 Vach Kompella 1909 TiMetra Networks 1910 274 Ferguson Dr. 1911 Mountain View, CA 94043 1912 Email: vkompella@timetra.com 1913 Marc Lasserre 1914 Riverstone Networks 1915 5200 Great America Pkwy 1916 Santa Clara, CA 95054 1917 Email: marc@riverstonenet.com 1919 Pascal Menezies 1920 Email: pascalm1@yahoo.com 1922 Hamid Ould-Brahim 1923 Nortel Networks 1924 P O Box 3511 Station C 1925 Ottawa, ON K1Y 4H7, Canada 1926 Email: hbrahim@nortelnetworks.com 1928 Vasile Radoaca 1929 Nortel Networks 1930 600 Technology Park 1931 Billerica, MA 01821 1932 Email: vasile@nortelnetworks.com 1934 Tissa Senevirathne 1935 1567 Belleville Way 1936 Sunnyvale CA 94087 1937 Email: tsenevir@hotmail.com