idnits 2.17.1 draft-ietf-l2vpn-l2-framework-01.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 7529 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 492, but not defined == Unused Reference: 'PWE3-ARCH' is defined on line 1867, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) == 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 (-04) exists of draft-andersson-ppvpn-terminology-03 == 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 == 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 (~~), 15 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-01.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions 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 (PPVPNs). This framework is intended to aid 39 in standardizing protocols and mechanisms to support interoperable 40 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 ........................................ 5 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 ........................... 6 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 (PPVPNs). This framework is intended to aid 112 in standardizing protocols and mechanisms to support interoperable 113 Layer2 PPVPNs. 115 The PPVPN WG group works with both Layer 3 PPVPNs and Layer 2 PPVPNs. 116 A framework for L3 VPNs is found in [L3VPN-FW]. This document 117 provides the same type of framework for Layer 2 PPVPNs as the Layer 3 118 framework does for Layer 3 PPVPNs. 120 The term "provider provisioned VPNs" refers to Virtual Private 121 Networks (VPNs) for which the Service Provider (SP) participates in 122 management and provisioning of the VPN. 124 There are multiple ways in which a provider can participate in a VPN, 125 and there are therefore multiple different types of PPVPNs. The 126 framework document discusses Layer2 VPNs (as defined in section 1.3). 127 It also describes technical issues related to VPNs in which the 128 provider participates in provisioning for provider edge and customer 129 edge devices. 131 First, this document discusses reference models for Layer 2 PPVPNs. 132 Then the functional components of Layer2 PPVPN operations are 133 discussed. 135 Specifically, this includes discussion of the technical issues, which 136 are important in the design of standards and mechanisms for support 137 of Layer 2 PPVPNs. Furthermore, technical aspects of Layer2 PPVPNs 138 interworking is clarified. Finally, security issues as they apply to 139 Layer2 PPVPNs are addressed. 141 Requirements for Layer 3 VPNs are found in [L3VPN-REQ] and for Layer 142 2 VPNs, for VPLS and VPWS, in [L2VPN-REQ]. 144 This document does not make choices, and does not select any 145 particular approach to support VPNs. 147 1.3. Layer 2 Virtual Private Networks 149 As Layer 2 provider provisioned VPN solutions has attracted more and 150 more interest, several solutions has been proposed to the PPVPN WG. 151 This document addresses the generic components relevant for every 152 Layer 2 VPN but will not make any recommendations on the relative 153 merits of how the different components are implemented. 155 We see two kinds of services that a service provider could offer to a 156 customer by means of Layer 2 VPNs. Virtual Private Wire Service 157 (VPWS)and a Virtual Private LAN Service (VPLS). The possibility of an 158 IP-only LAN-like Service (IPLS, [IPLS]) is opened up as well. 160 A VPWS is a VPN service that supplies a L2 point-to-point service. 161 Being a point-to-point service where there are very few scaling 162 issues with the service as such. Scaling issues might arise from the 163 number of end- points that can be supported on a particular PE. 165 A VPLS is an L2 service that in all respects emulates LAN across a 166 Wide Area Network (WAN). Thus it also has all the scaling 167 characteristics of a LAN. Other scaling issues might arise from the 168 number of end-points that can be supported on a particular PE. 170 1.4. Terminology 172 This document list some terms and concepts that are specific to the 173 L2 VPN framework, terms and concepts generally applicable to the 174 PPVPN area will be found in [L2VPN-TERM]. 176 2. Models 178 2.1. Reference Model for VPWS 180 The VPWS reference model is shown in Figure 1. 182 Attachment PSN Attachment 183 Circuits tunnel Circuits 184 + 185 +-----+ pseudo +-----+ 186 | | wire | | 187 | CE1 |--+ +--| CE2 | 188 | | | +-----+ +-----+ +-----+ | | | 189 +-----+ +----|---- | | P | | ----+----+ +-----+ 190 |VPWS\|---|-----|-----|/VPWS| 191 | PE1 |===|=====|=====| PE2 | 192 | /|---|-----|-----|\ | 193 +-----+ +----|---- | | | | ----|----+ +-----+ 194 | | | +-----+ +-----+ +-----+ | | | 195 | CE3 |--+ +--| CE4 | 196 | | | | 197 +-----+ +-----+ 199 Figure 1 201 2.1.1. Entities in the VPWS reference model 203 The P, PE (VPWS-PE) and CE devices and the PSN tunnel as defined in 204 [L2VPN-TERM]. Attachment circuit and pseudo wire as discussed in 205 section 3. The PE does a simple mapping between the PW and attachment 206 circuit based on local information, i.e. the PW de-multiplexor and 207 incoming/outgoing logical/physical port. 209 2.2. Reference Model for VPLS 211 The following diagram shows a VPLS reference model where PE devices 212 that are VPLS-capable provide a logical interconnect such that CE 213 devices belonging to a specific VPLS appear to be on a single bridged 214 Ethernet. A VPLS can contain a single VLAN or multiple, tagged VLANs. 216 The VPLS reference model is shown in Figures 2 and 3. 218 +-----+ +-----+ 219 + CE1 +--+ +---| CE2 | 220 +-----+ | ................... | +-----+ 221 VPLS A | +----+ +----+ | VPLS A 222 | |VPLS| |VPLS| | 223 +--| PE |--Routed---| PE |-+ 224 +----+ Backbone +----+ 225 / . | . \ _ /\_ 226 +-----+ / . | . \ / \ / \ +-----+ 227 + CE +--+ . | . +--\ Access \----| CE | 228 +-----+ . +----+ . | Network | +-----+ 229 VPLS B .....|VPLS|........ \ / VPLS B 230 | PE | ^ ------- 231 +----+ | 232 | | 233 | | 234 +-----+ | 235 | CE3 | +-- Emulated LAN 236 +-----+ 237 VPLS A 239 Figure 2 240 |-----Routed Backbone------| 241 | (P Routers) |PSN Tunnels, 242 Emulated LAN | |Pseudowires 243 ......................................................................... 244 . | | . 245 . |----------------------|----| |---------|-----------------| . 246 . | --------------------|--- | | -------|---------------- | . 247 . | VPLS Forwarder | | VPLS Forwarder | . 248 . | ----------|------------- | | ----------|------------- | . 249 ..|...................................................................|.. 250 | | Emulated LAN | | | Emulated LAN | 251 | | Interface | VPLS-PEs | | Interface | 252 | | | <----> | | | 253 | ----------|------------ | | ----------|------------ | 254 | | Bridge | | | | Bridge | | 255 | -|--------|---------|-- | | ---|-------|---------|- | 256 |---|--------|---------|----| |-----|-------|---------|---| 257 | | | | | | 258 | | Access | | | Access | 259 | | Networks| | | Networks| 260 | | | | | | 261 | | | | | | 262 CE devices CE devices 263 Figure 3 265 From Figure 3, we see that in VPLS, a CE device attaches, possibly 266 through an access network, to a "bridge" module of a VPLS-PE. Within 267 the VPLS-PE, the bridge module attaches, through an "Emulated LAN 268 Interface" to an Emulated LAN. For each VPLS, there is an Emulated 269 LAN instance. Figure 3 shows some internal structure to the Emulated 270 LAN: it consists "VPLS Forwarder" modules (one per VPLS-PE per VPLS 271 instance) connected by Pseudowires, where the Pseudowires may be 272 traveling through PSN tunnels over a routed backbone. 274 The functionality which the bridge module must support depends on the 275 service which is being offered by the SP to its customers, as well as 276 on various details of the SP's network. At minimum, the bridge 277 module must be able to learn MAC addresses, and to "age them out", in 278 the standard manner. However, if the PE devices have backdoor 279 connections with each other via a layer 2 network, they may need to 280 be full IEEE bridges, running spanning tree with each other. 281 Specification of the precise functionality which the bridge modules 282 must have in particular circumstances is, however, out of scope of 283 the current document. 285 This framework specifies that each "bridge module" has a single 286 "Emulated LAN interface". It does not specify the number of bridge 287 modules that a VPLS-PE may contain, nor does it specify the number of 288 VPLS instances which may attach to a bridge module over a single 289 "Emulated LAN interface". 291 Thus the framework is compatible with at least the following three 292 models: 294 - Model 1 296 A VPLS-PE contains a single bridge module, and supports a single 297 VPLS instance. The VPLS instance is an Emulated LAN; if that 298 Emulated LAN contains VLANs, 802.1Q tagging must be used to 299 indicate which packets are in which VLANs. 301 - Model 2 303 A VPLS-PE contains a single bridge module, but supports multiple 304 VPLS instances. Each VPLS instance is thought of as a VLAN (in 305 effect, an "Emulated VLAN"), and the set of VPLS instances are 306 treated as a set of VLANs on a common LAN. 308 - Model 3 310 A VPLS-PE contains an arbitrary number of bridge modules, each of 311 which attaches to a single VPLS instance. 313 There may be other models as well, some of which are combinations of 314 the 3 models above. Different models may have different 315 characteristics, and different scopes of applicability. 317 Each VPLS solution should specify the model or models that it is 318 supporting. Each solution should also specify the necessary bridge 319 functionality that its bridge modules must support. 321 This framework does not specify the way in which bridge control 322 protocols are used on the Emulated LANs. 324 2.2.1. Entities in the VPLS reference model 326 The PE (VPLS-PE) and CE devices are defined in [L2VPN-TERM]. 328 2.3. Reference Model for Distributed VPLS-PE or VPWS-PE 330 VPLS-PE/VPWS-PE 331 Functionality . . . . . . . 332 . . . . . . . . . . . . . 333 . . . . 334 +----+ . +----+ +----+ . . Service . 335 | CE |--.--|U-PE|----|N-PE|-.---. Provider . 336 +----+ . +----+ +----+ . . Backbone . 337 . . . . . . . . . . . . . 339 2.3.1. Entities in the Distributed PE Reference Models 341 A VPLS-PE or a VPWS-PE functionality may be distributed to more than 342 one device. The device closer to the customer/user is called User 343 facing PE (U-PE) and the device closer to the core network is called 344 Network facing PE (N-PE). 346 For further discussion see section 3.4.3. 348 The terms "U-PE" and "N-PE" are defined in [L2VPN-TERM]. 350 2.4. VPWS-PE and VPLS-PE 352 The VPWS-PE and VPLS-PE are functionally very similar, the they both 353 use forwarders to map attachment circuits to pseudo-wires. The only 354 differences is that while the forwarder in a VPWS-PE does a one-to- 355 one mapping between the attachment circuit and pseudo-wire, the 356 forwarder in a VPLS-PE is a Virtual Switching Instance (VSI) that 357 maps multiple attachment circuits to multiple pseudo-wires (for 358 further discussion see section 3.) 360 3. Functional Components of L2 VPN 362 This section specifies a functional model for L2VPN, which allows one 363 to break an L2VPN architecture down into its functional components. 364 This allows us to exhibit the roles played by the various protocols 365 and mechanisms, and thus to make it easier to understand the 366 differences and similarities between various proposed L2VPN 367 architectures. 369 Section 3.1 contains an overview of some different types of L2VPN. 370 In section 3.2, functional components that are common to the 371 different types are discussed. Then there is a section for each of 372 the L2VPN service types being considered. The latter sections discuss 373 functional components, which may be specific to particular L2VPN 374 types, as well as discussing type-specific features of the generic 375 components. 377 3.1. Types of L2VPN 379 The types of L2VPN are distinguished by the characteristics of the 380 service that they offer to the customers of the Service Provider 381 (SP). 383 3.1.1. Virtual Private Wire Service (VPWS) 385 In a VPWS, each CE device is presented with a set of point-to-point 386 virtual circuits. 388 The other end of each virtual circuit is another CE device. Frames 389 transmitted by a CE on such a virtual circuit are received by the CE 390 device at the other end-point of the virtual circuit. Forwarding from 391 one CE device to another is not affected by the content of the frame, 392 but is fully determined by the virtual circuit on which the frame is 393 transmitted. The PE thus acts as a virtual circuit switch. 395 This type of L2VPN has long been available over ATM and Frame Relay 396 backbones. Providing this type of L2VPN over MPLS and/or IP backbones 397 is the current topic. 399 Requirements for this type of L2VPN are specified in [L2VPN-REQ]. 401 3.1.2. Virtual Private LAN Service (VPLS) 403 In a VPLS, each CE device has one or more LAN interfaces that lead to 404 a "virtual backbone". 406 Two CEs are connected to the same virtual backbone if and only if 407 they are members of the same VPLS instance (i.e., same VPN). When a 408 CE transmits a frame, the PE that receives it examines the MAC 409 Destination Address field in order to determine how to forward the 410 frame. Thus the PE functions as a bridge. As is indicated in Figure 411 3, if a set of PEs support a common VPLS instance, then there is an 412 Emulated LAN, corresponding to that VPLS instance, to which each of 413 those PE bridges attaches (via an emulated interface). From the 414 perspective of a CE device, the virtual backbone is the set of PE 415 bridges and the Emulated LAN on which they reside. Thus to a CE 416 device, the LAN which attaches it to the PE is extended transparently 417 over the routed MPLS and/or IP backbone. 419 The PE bridge function treats the Emulated LAN as it would any other 420 LAN to which it has an interface. Forwarding decisions are made in 421 the manner which is normal for bridges, based on MAC Source Address 422 learning. 424 VPLS is like VPWS in that forwarding is done without any 425 consideration of the Layer3 header. VPLS is unlike VPWS in that: 427 - VPLS allows the PE to use addressing information in a frame's L2 428 header to determine how to forward the frame; 430 - VPLS allows a single CE/PE connection to be used for transmitting 431 frames to multiple remote CEs; in this particular respect, VPLS 432 resembles L3VPN more than VPWS. 434 Requirements for this type of L2VPN are specified in [L2VPN-REQ]. 436 3.1.3. IP-only LAN-like Service (IPLS) 438 An IPLS is very like a VPLS, except that: 440 - it is assumed that the CE devices are hosts or routers, not 441 switches 443 - it is assumed that the service will only carry IP packets, and 444 supporting packets such as ICMP and ARP; Layer2 packets which do 445 not contain IP are not supported. 447 While this service is a functional subset of the VPLS service, it is 448 considered separately because it may be possible to provide it using 449 different mechanisms, which may allow it to run on certain hardware 450 platforms that cannot support the full VPLS functionality. 452 3.2. Generic L2VPN Transport Functional Components 454 All L2VPN types must transport "frames" across the core network 455 connecting the PE's. In all L2VPN types, a PE (PE1) receives a frame 456 from a CE (CE1), then transports the frame to a PE (PE2), which then 457 transports the frame to a CE (CE2). In this section, we discuss the 458 functional components, which are necessary to transport L2 frames in 459 any type of L2VPN service. 461 3.2.1. Attachment Circuits 463 In any type of L2VPN, a CE device attaches to a PE device via some 464 sort of circuit or virtual circuit. We will call this an "Attachment 465 Circuit" (AC). We use this term very generally; an Attachment Circuit 466 may be a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, 467 a PPP connection on a physical interface, a PPP session from an L2TP 468 tunnel, an MPLS LSP, etc. The CE device may be a router, a switch, a 469 host, or just about anything, which the customer needs hooked up to 470 the VPN. An AC carries a frame between CE and PE, or vice versa. 472 Procedures for setting up and maintaining the ACs are out of scope of 473 this architecture. 475 These procedures are generally specified as part of the specification 476 of the particular Attachment Circuit technology. 478 Any given frame will traverse an AC from a CE to a PE and then on 479 another AC from a PE to a CE. 481 We refer to the former AC as the frame's "ingress AC" and to the 482 latter AC as the frame's "egress AC". Note that this notion of 483 "ingress AC" and "egress AC" is relative to a specific frame, and 484 denotes nothing more than the frame's direction of travel while on 485 that AC. 487 3.2.2. Pseudowires 489 A "Pseudowire" (PW) is a relation between two PE devices. Whereas an 490 AC is used to carry a frame from CE to PE, a PW is used to carry a 491 frame between two PEs. We use the term "pseudowire" in the sense of 492 [PWE3- ARCH]. 494 Setting up and maintaining the PWs is the job of the PEs. State 495 information for a particular PW is maintained at the two PEs which 496 are its endpoints, but not at other PEs, and not in the backbone 497 routers (P routers). 499 Pseudowires may be point-to-point, multipoint-to-point, or point-to- 500 multipoint. In this framework, point-to-point PWs are always 501 considered to be bidirectional; multipoint-to-point and point-to- 502 multipoint PWs are always considered to be unidirectional. 503 Multipoint-to-point PWs can be used only when the PE receiving a 504 frame from the PW does not need to know where the frame came from. 505 Point-to-multipoint PWs may be useful when frames need to be 506 multicast. 508 Procedures for setting up and maintaining point-to-multipoint PWs are 509 not considered in this version of this framework. 511 Any given frame travels first on its ingress AC, then on a PW, then 512 on its egress AC. 514 Multicast frames may be replicated by a PE, so of course the 515 information carried in multicast frames may travel on more than one 516 PW and more than one egress AC. 518 Thus with respect to a given frame, a PW may be said to associate a 519 number of ACs. If these ACs are of the same technology (e.g., both 520 ATM, both Ethernet, both Frame Relay) the PW is said to provide 521 "homogeneous transport"; otherwise it is said to provide 522 "heterogeneous transport". Heterogeneous transport requires that some 523 sort of interworking function be applied. There are at least three 524 different approaches to interworking: 526 1. One of the CEs may perform the interworking locally. For 527 example, if CE1 attaches to PE1 via ATM, but CE2 attaches to 528 PE2 via Ethernet, then CE1 may decide to send/receive Ethernet 529 frames over ATM, using the RFC2684 "LLC Encapsulation for 530 Bridged Protocols". In such a case, PE1 would need to know 531 that it is to terminate the ATM VC locally, and only 532 send/receive Ethernet frames over the PW. 534 2. One of the PEs may perform the interworking. For example, if 535 CE1 attaches to PE1 via ATM, but CE2 attaches to PE2 via Frame 536 Relay, PE1 may provide the "ATM/FR Service Interworking" 537 function. This would be transparent to the CEs, and the PW 538 would carry only Frame Relay frames. 540 3. IPLS could be used. In this case the "frames" carried by the 541 PW are IP datagrams, and the two PEs need to cooperate in order 542 to spoof various L2-specific procedures used by IP (see section 543 3.5). 545 3.2.3. Forwarders 547 In all types of L2VPN, a PE, say PE1, receives a frame over an AC, 548 and forwards it over a PW to another PE, say PE2. PE2 then forwards 549 the frame out on another AC. 551 The case in which PE1 and PE2 are the same device is an important 552 case to handle correctly, in order to provide the L2VPN service 553 properly. However, as this case does not require any protocol, we do 554 not further address it in this document. 556 When PE1 receives a frame on a particular AC, it must determine the 557 PW on which the frame must be forwarded. In general, this is done by 558 considering: 560 - the incoming AC, 562 - possibly the contents of the frame's Layer2 header, and 564 - possibly some forwarding information which may be statically or 565 dynamically maintained. 567 If dynamic or static forwarding information is considered, the 568 information is specific to a particular L2VPN instance (i.e., to a 569 particular VPN). 571 Similarly, when PE2 receives a frame on a particular PW, it must 572 determine the AC on which the frame must be forwarded. This is done 573 by considering: 575 - the incoming PW, 577 - possibly the contents of the frame's Layer2 header, and 579 - possibly some forwarding information which may be statically or 580 dynamically maintained. 582 If dynamic or static forwarding information is considered, the 583 information is specific to a particular L2VPN instance (i.e. to a 584 particular VPN). 586 The procedures used to make the forwarding decision are known as a 587 "forwarder". We may think of a PW as being "bound", at each of its 588 endpoints, to a forwarder. The forwarder in turn "binds" the PWs to 589 ACs. Different types of L2VPN have different types of forwarders. 591 For instance, a forwarder may bind a single AC to a single PW, 592 ignoring all frame contents and using no other forwarding 593 information. Or a forwarder may bind an AC to a set of PWs and ACs, 594 moving individual frames from AC to PW, from a PW to an AC or from AC 595 to AC by comparing information from the frame's Layer2 header to 596 information in a forwarding database. This is discussed in more 597 detail below, as we consider the different L2VPN types. 599 3.2.4. Tunnels 601 A PW is carried in a "tunnel" from PE1 to PE2. We assume that an 602 arbitrary number of PWs may be carried in a single tunnel; the only 603 requirement is that the PWs all terminate at PE2. 605 We do not even require that all the PWs in the tunnel originate at 606 PE1; the tunnels may be multipoint-to-point tunnels. Nor do we 607 require that all PWs between the same pair of PEs travel in the same 608 tunnel. All we require is that when a frame traveling through such a 609 tunnel arrives at PE2, PE2 will be able to associate it with a 610 particular PW. 612 (While one can imagine tunneling techniques that only allow one PW 613 per tunnel, they have evident scalability problems, and we do not 614 consider them further.) 616 There are a variety of different tunneling technologies which may be 617 used for the PE-PE tunnels. All that is really required is that the 618 tunneling technologies allow the proper demultiplexing of the 619 contained PWs. The tunnels might be MPLS LSPs, L2TP tunnels, IPsec 620 tunnels, MPLS- in-IP tunnels, etc. Generally the tunneling 621 technology will require the use of an encapsulation that contains a 622 demultiplexor field, where the demultiplexor field is used to 623 identify a particular PW. Procedures for setting up and maintaining 624 the tunnels are not within the scope of this framework. (But see 625 section 3.2.6, "Pseudowire Signaling".) 627 If there are multiple tunnels from PE1 to PE2, it may be desirable to 628 assign a particular PE1-PE2 PW to a particular tunnel based on some 629 particular characteristics of the PW and/or the tunnel. For example, 630 perhaps different tunnels are associated with different QoS 631 characteristics, and different PWs require different QoS. Procedures 632 for specifying how to assign PWs to tunnels are out of scope of the 633 current framework. 635 Though point-to-point PWs are bidirectional, the tunnels in which 636 they travel need not be either bidirectional or point-to-point. For 637 example, a point-to-point PW may travel within a unidirectional 638 multipoint-to- point MPLS LSP. 640 3.2.5. Encapsulation 642 As L2VPN packets are carried in pseudowires, standard pseudowire 643 encapsulation formats and techniques (as specified by the IETF's PWE3 644 WG) should be used wherever applicable. 646 Generally the PW encapsulations will themselves be encapsulated 647 within a tunnel encapsulation, as determined by the specification of 648 the tunneling protocol. 650 It may be necessary to define additional PW encapsulations to cover 651 areas that are of importance for L2VPN, but may not be within the 652 scope of PWE3. Heterogeneous transport may be an instance of this. 654 3.2.6. Pseudowire Signaling 656 Procedures for setting up and maintaining the PWs themselves are 657 within the scope of this framework. This includes procedures for 658 distributing demultiplexor field values, even though the 659 demultiplexor field, strictly speaking, belongs to the tunneling 660 protocol rather than to the PW. 662 The signaling for a point-to-point pseudowire must perform the 663 following functions: 665 - Distribution of the demultiplexor. 667 Since many PWs may be carried in a single tunnel, the tunneling 668 protocol must assign a demultiplexor value to each PW. These 669 demultiplexors must be unique with respect to a given tunnel (or 670 with some tunneling technologies, unique at the egress PE). 671 Generally, the PE which is the egress of the tunnel will select 672 the demultiplexor values, and will distribute them to the PE(s) 673 which is (are) the ingress(es) of the tunnel. This is the 674 essential part of the PW setup procedure. 676 Note that, as is usually the case in tunneling architectures, the 677 demultiplexor field belongs to the tunneling protocol, not to the 678 protocol being tunneled. For this reason, the PW setup protocols 679 may be extensions of the control protocols for setting up the 680 tunnels. 682 - Selection of the Forwarder at the Remote PE. 684 The signaling protocol must contain enough information to enable 685 the remote PE to select the proper forwarder to which the PW is 686 to be bound. We can call this information the "Remote Forwarder 687 Selector". The information that is required will depend on the 688 type of L2VPN being provided and on the provisioning model (see 689 sections 3.3.1 and 3.4.2) being used. The Remote Forwarder 690 Selector may uniquely identify a particular Forwarder, or it may 691 identify an attribute of Forwarders. In the latter case, it would 692 select whichever Forwarder has been provisioned with that 693 attribute. 695 - Support pseudowire emulations. 697 To the extent that a particular PW must emulate the signaling of 698 a particular Layer2 technology, the PW signaling must provide the 699 necessary functions. 701 - Distribution of State Changes. 703 Changes in the state of an AC may need to be reflected in changes 704 to the state of the PW to which the AC is bound, and vice versa. 705 The specification as to which changes need to be reflected in 706 what way would generally be within the province of the PWE3 WG. 708 - Establish pseudowire characteristics. 710 To the extent that one or more characteristics of a PW must be 711 known to and/or agreed upon by both endpoints, the signaling must 712 allow for the necessary interaction. 714 As specified above, signaling for point-to-point PWs must pass enough 715 information to allow a remote PE to properly bind a PW to a 716 Forwarder, and to associate a particular demultiplexor value with 717 that PW. Once the two PEs have done the proper PW/Forwarder bindings, 718 and have agreed on the demultiplexor values, the PW may be considered 719 to have been set up. If it is necessary to negotiate further 720 characteristics or parameters of a particular PW, or to passing 721 status information for a particular PW, the PW may be identified by 722 the demultiplexor value. 724 Signaling procedures for point-to-point pseudowires are most commonly 725 point-to-point procedures that are executed by the two PW endpoints. 726 There are however proposals to use point-to-multipoint signaling for 727 setting up point-to-point pseudowires, so this is included in the 728 framework. When PWs are themselves point-to-multipoint, it is also 729 possible to use either point-to-point signaling or point-to- 730 multipoint signaling to set them up. This is discussed in the 731 remainder of this section. 733 3.2.6.1. Point-to-Point Signaling 735 There are several ways to do the necessary point-to-point signaling. 736 Among them are: 738 - LDP 740 LDP extensions can be defined for pseudowire signaling. See for 741 example [PWE3-LDP], [L2VPN-SIGNALING]. This form of signaling 742 can be used for pseudowires which are to be carried in MPLS 743 "tunnels", or in MPLS-in-something-else tunnels (e.g., [MPLS-IP- 744 GRE]). 746 - L2TP 748 L2TP [L2TP-BASE] can be used for pseudowire signaling, resulting 749 in pseudowires that are carried as "sessions" within L2TP 750 tunnels. Pseudowire-specific extensions to L2TP may also be 751 needed. 753 Other methods may be possible as well. 755 It is possible to have one control connection between a pair of PEs, 756 which is used to control many PWs. 758 The use of point-to-point signaling for setting up point-to-point PWs 759 is straightforward. Multipoint-to-point PWs can also be set up by 760 point- to-point signaling, as the remote PEs do not necessarily need 761 to know whether the PWs are multipoint-to-point or point-to-point. 762 In some signaling procedures, the same demultiplexor value may be 763 assigned to all the remote PEs. 765 3.2.6.2. Point-to-Multipoint Signaling 767 Consider the following situation: 769 - It is necessary to set up a set of PWs, all of which have the 770 same characteristics. 772 - It is not necessary to use the PW signaling protocol to pass PW 773 state changes. 775 - For each PW in the set, the same value of the Remote Forwarder 776 Selector can be used. 778 Call these the "Environmental Conditions". 780 Suppose also that there is some mechanism by which, given a range of 781 demultiplexor values, each of a set of PEs can make a unique and 782 deterministic selection of a single value from within that range. 783 Call this the "Demultiplexor Condition". Alternatively, suppose that 784 one is trying to set up a multipoint-to-point PW rather than a 785 point-to-point PW. Call this the "Multipoint Condition". 787 If: 789 - The Environmental Conditions hold, and 791 - Either 793 * the Demultiplexor Condition holds, or 795 * the Multipoint Condition holds, 797 then for a given set of PWs which terminate at egress PE1, the 798 information which PE1 needs to send to the ingress PE(s) of each 799 pseudowire in the set is exactly the same. All the ingress PE(s) 800 receive the same Forwarder Selector value. They all receive the same 801 set of PW parameters (if any). And either they all receive the same 802 demultiplexor value (if the PW is multipoint-to-point) or they all 803 receive a range of demultiplexor values from which each can choose a 804 unique demultiplexor value for itself. 806 Rather than connecting to each ingress PE and replicating the same 807 information, it may make sense either to multicast the information, 808 or to send the information once to a "reflector", which will then 809 take responsibility for distributing the information to the other 810 PEs. 812 We refer to this sort of technique as "point-to-multipoint" 813 signaling. It would, for example, be possible to use BGP to do the 814 signaling, with the PEs being BGP peers not of each other, but of one 815 or more BGP route reflectors. 817 Such a scheme, based Multi-protocol Extensions to BGP, is proposed in 818 [L2VPN-BGP]. 820 3.2.6.3. Inter-AS Considerations 822 Pseudowires may need to run from a PE in one Service Provider's 823 network to a PE in another Service Provider's network. This means 824 that the signaling to set up the PEs must be able to cross network 825 boundaries. All known proposals for signaling are able to do this. It 826 is especially advisable to use some form of authentication between 827 the two PW endpoints in this case. 829 3.2.7. Service Quality 831 Service Quality refers to the ability for the network to deliver a 832 Service level Specification (SLS) for service attributes such as 833 protection, security and Quality of Service (QoS). The service 834 quality provided depends on the subscriber's requirements, and can be 835 characterized by a number of performance metrics. 837 The necessary Service Quality must be provided on the ACs as well as 838 on the PWs. Mechanisms for providing Service Quality on the PWs may 839 be PW- specific or tunnel-specific; in the latter case, the 840 assignment of a PW to a tunnel may depend on the Service Quality. 842 3.2.7.1. Quality of Service (QoS) 844 QoS describes the queuing behavior applied to a particular "flow", in 845 order to achieve particular goals of precedence, throughput, delay, 846 jitter, etc. 848 Based on the customer Service Level Agreement (SLA), traffic from 849 customer can be prioritized, policed and shaped for QoS requirements. 850 The queuing and forwarding policies can preserve the packet order and 851 QoS parameters of customer traffic. The class of services can be 852 mapped from information in the customer frames, or it can be 853 independent of the frame content. 855 QoS functions can be listed as follows: 857 - Customer Traffic Prioritization: L2VPN services could be best 858 effort or QoS guaranteed. Traffic from one customer might need to 859 be prioritized over others when sharing same network resources. 860 This requires capabilities within the L2VPN solution to classify 861 and mark priority to QoS guaranteed customer traffic. 863 - Proper queuing behavior would be needed at the egress AC, and 864 possibly within the backbone network as well. If queuing behavior 865 must be controlled within the backbone network, the control might 866 be based on CoS information in the MPLS or IP header, or it might 867 be achieved by nesting particular tunnels within particular 868 traffic engineering tunnels. 870 - Policing: This ensures that a user of L2VPN services uses network 871 resources within the limits of the agreed SLA. Any excess L2VPN 872 traffic can be rejected or handled differently based on provider 873 policy. 875 - Policing would generally be applied at the ingress AC. 877 - Shaping: Under some cases the random nature of L2VPN traffic 878 might lead to sub-optimal utilization of network resources. 879 Through queuing and forwarding mechanisms the traffic can be 880 shaped without altering the packet order. 882 - Shaping would generally be applied at the ingress AC. 884 3.2.7.2. Resiliency 886 Resiliency describes the ability of the L2VPN infrastructure to 887 protect a flow from network outage, so that service remains available 888 in the presence of failures. 890 L2VPN, like any other service, is subject to failures such as link, 891 trunk and node failures, both in the SP's core network infrastructure 892 and on the ACs. 894 It is desirable that the failure be detected "immediately" and 895 protection mechanisms allow fast restoration times to make L2VPN 896 service almost transparent to these failures to the extent possible, 897 based on the level of resiliency. Restoration should take place 898 before the CEs can react to the failure. Essential aspects of 899 providing resiliency are: 901 - Link/Node failure detection: Mechanisms within the L2VPN service 902 should allow for link or node failures that impact the Service, 903 and should be detected immediately. 905 - Resiliency policy: The way in which a detected failure is handled 906 will depend upon the restoration policy of the SLA associated 907 with the L2VPN service specification. It may need to be handled 908 immediately, or it may need to be handled only if no other 909 critical failure needs protection resources, or it may be 910 completely ignored if it is within the bounds of the "acceptable 911 downtime" allowed by the L2VPN service. 913 - Restoration Mechanisms: The L2VPN solutions could allow for 914 physical level protection, logical level protection or both. For 915 example, by connecting customers over redundant and physically 916 separate ACs to different provider customer-facing devices, one 917 AC can be maintained as active while the other could be marked as 918 a backup; upon the failure detection across the primary AC, the 919 backup could become active. 921 To a great extent, resiliency is a matter of having appropriate 922 failure and recovery mechanisms in the network core, including 923 "ordinary" adaptive routing as well as "fast reroute" capabilities. 924 The ability to support redundant ACs between CEs and PEs also plays a 925 role. 927 3.2.8. Management 929 An L2VPN solution can provide mechanisms to manage and monitor 930 different L2VPN components. From a Service Level Agreement (SLA) 931 perspective, L2VPN solutions could allow monitoring of L2VPN service 932 characteristics and offer mechanisms used by Service Providers to 933 report such monitored statistical data. Trouble-shooting and 934 verification of operational and maintenance activities of L2VPN 935 services are essential requirements for Service Providers. 937 3.3. VPWS 939 A VPWS is an L2VPN service in which each forwarder binds exactly one 940 AC to exactly one PW. Frames received on the AC are transmitted on 941 the PW; frames received on the PW are transmitted on the AC. The 942 content of a frame's Layer2 header plays no role in the forwarding 943 decision, except insofar as the Layer2 header contents are used to 944 associate the frame with a particular AC (as, e.g., the DLCI field of 945 a Frame Relay frame identifies the AC). 947 A particular combination of forms a "virtual circuit" 948 between two CE devices. 950 A particular VPN (VPWS instance) may be thought of as a collection of 951 such virtual circuits, or as an "overlay" of PWs on the MPLS or IP 952 backbone. This creates an overlay topology that is in effect the 953 "virtual backbone" of a particular VPN. 955 Whether two virtual circuits are said to belong to the same VPN or 956 not is an administrative matter, based on the agreements between the 957 SPs and their customers. This may impact the provisioning model 958 (discussed below). It may also affect how particular PWs are 959 assigned to tunnels, the way QoS is assigned to particular ACs and 960 PWs, etc. 962 Note that VPWS makes use of point-to-point PWs exclusively. 964 VPWS solutions are found e.g. in [L2VPN-BGP] and [L2VPN-SIGNALING]. 966 3.3.1. Provisioning and Auto-Discovery 968 Provisioning a VPWS is a matter of: 970 1. Provisioning the ACs 972 2. Providing the PEs with the necessary information to enable them 973 to set up PWs between ACs to result in the desired overlay 974 topology. 976 3. Configuring the PWs with any necessary characteristics 978 3.3.1.1. Attachment Circuit Provisioning 980 In many cases, the ACs must be individually provisioned on the PE 981 and/or CE. This will certainly be the case if the CE/PE attachment 982 technology is a switched network, such as ATM or FR, and the VCs are 983 PVCs rather than SVCs. It is also the case whenever the individual 984 Attachment Circuits need to be given specific parameters (e.g., QoS 985 parameters, guaranteed bandwidth parameters) that differ from circuit 986 to circuit. 988 There are also cases in which ACs might not have to be individually 989 provisioned. E.g., if an AC is just an MPLS LSP running between a CE 990 and a PE, it could be set up as the RESULT of a PW being set up, 991 rather than having to be provisioned BEFORE the PW can be set up. The 992 same may apply whenever the AC is a Switched Virtual Circuit of any 993 sort, though in this case, various policy controls might need to be 994 provisioned, e.g., limiting the number of ACs that can be set up 995 between a given CE and a given PE. 997 Issues such as whether the Attachment Circuits need to be 998 individually provisioned or not, whether they are Switched VCs or 999 Permanent VCs, and what sorts of policy controls may be applied, are 1000 implementation and deployment issues, and are considered to be out of 1001 scope of this framework. 1003 3.3.1.2. PW Provisioning for Arbitrary Overlay Topologies 1005 In order to support arbitrary overlay topologies, it is necessary to 1006 allow the provisioning of individual PWs. In this model, when a PW 1007 is provisioned on a PE device, it is locally bound to a specific AC. 1008 It is also provisioned with information that identifies a specific AC 1009 at a remote PE. 1011 There are basically two variations of this provisioning model: 1013 - Two-sided provisioning 1015 With two-sided provisioning, each PE that is at the end of a PW 1016 is provisioned with the following information: 1018 * Identifier of the Local AC to which the PW is to be bound 1020 * PW type and parameters 1022 * IP address of the remote PE (i.e., the PE which is to be at 1023 the remote end of the PW) 1025 * Identifier which is meaningful to the remote PE, and which 1026 can be passed in the PW signaling protocol to enable the 1027 remote PE to bind the PW to the proper AC. This can be an 1028 identifier of the pseudowire (as in [PWE3-LDP]), or an 1029 identifier of the remote AC (as in [L2VPN-SIGNALING]). If a 1030 PW identifier is used, it must be unique at each of the two 1031 PEs. If an AC identifier is used, it need only be unique at 1032 the remote PE. 1034 This identifier is then used as the Remote Forwarder Selector 1035 when signaling is done (see 3.2.6.1). 1037 - Single-sided Provisioning 1039 With single sided provisioning, a PE at one end of a PW is 1040 provisioned with the following information: 1042 * Identifier of the Local AC to which the PW is to be bound 1044 * PW type and parameters 1046 * Globally unique identifier of remote AC 1048 This identifier is then used as the Forwarder Selector when 1049 signaling is done (see section 3.2.6.1). 1051 In this provisioning model, the IP address of the remote PE is 1052 not provisioned. Rather, the assumption is that an auto- 1053 discovery scheme will be used to map the globally unique 1054 identifier to the IP address of the remote PE, along with an 1055 identifier (perhaps unique only at the latter PE) for an AC at 1056 that PE. The PW signaling protocol can then make a connection to 1057 the remote PE, passing the AC identifier, so that the remote PE 1058 binds the PW to the proper AC. (See, for example, [L2VPN- 1059 SIGNALING].) 1061 This scheme requires provisioning of the PW at only one PE, but 1062 does not eliminate the need (if there is a need) to provision the 1063 ACs at both PEs. 1065 These provisioning models fit well with the use of point-to-point 1066 signaling. When each PW is individually provisioned, as the 1067 conditions necessary for the use of point-to-multipoint signaling do 1068 not hold. 1070 3.3.1.3. Colored Pools PW Provisioning Model 1072 Suppose that at each PE, sets of ACs are gathered together into 1073 "pools", and that each such pool is assigned a "color". (For 1074 example, a pool might contain all and only the ACs from this PE to a 1075 particular CE.) Now suppose we impose the following rule: whenever 1076 PE1 and PE2 have a pool of the same color, there will be a PW between 1077 PE1 and PE2 which is bound at PE1 to an arbitrarily chosen AC from 1078 that pool, and at PE2 to an arbitrarily chosen AC from that pool. 1079 (We do not rule out the case where a single PE has multiple pools of 1080 a given color.) 1082 For example, each pool in a particular PE might represent a 1083 particular CE device, with the ACs in the pool being the ACs 1084 connecting that CE to that PE. The color might be a VPN-id. 1085 Application of this provisioning model would then lead to a full CE- 1086 to-CE mesh within the VPN, where every CE in the VPN has a virtual 1087 circuit to every other CE within the VPN. 1089 More specifically, to provision VPWS according to this model, one 1090 provisions a set of pools, and configures each pool with the 1091 following information: 1093 - The set of ACs that belong to the pool (with no AC belonging to 1094 more than one pool) 1096 - The color 1098 - A pool identifier that is unique at least relative to the color. 1100 An auto-discovery procedure is then used to map each color into a 1101 list of ordered pairs . The 1102 occurrence of a pair on this list means that the PE at IP 1103 address X has a pool with pool id Y which is of the specified 1104 color. 1106 This information can be used to support several different 1107 signaling techniques. One possible technique proceeds as 1108 follows: 1110 - A PE finds that it has a pool of color C. 1112 - Using auto-discovery, it obtains the set of ordered pairs 1113 for color C. 1115 - For each such pair , it: 1117 * removes an AC from the pool 1119 * binds the AC to a particular PW 1121 * signals PE X via point-to-point signaling that the PW is to 1122 be bound to an AC from pool Y. 1123 This sort of technique is discussed in [L2VPN-SIGNALING]. 1125 Another possible signaling technique is the following: 1127 - A PE finds that it has a pool of color C, containing n ACs. 1129 - It binds each AC to a PW, creating a set of PWs. This set of PWs 1130 is then organized into a sequence. (For instance, each PW may be 1131 associated with a demultiplexor field value, and the PWs may then 1132 be sequenced according to the numerical value of their respective 1133 demultiplexors.) 1135 - Using auto-discovery, it obtains the list of PE routers that have 1136 one or more pools of color C. 1138 - It signals each such PE router, specifying the sequence Q of PWs. 1140 - If PE X receives such a signal, and PE X has a pool Y of the 1141 specified color, it: 1143 * removes an AC from the pool 1145 * binds the AC to the PW which is the "Yth" PW in the sequence 1146 Q. 1148 This presumes, of course, that the pool identifiers are or can be 1149 uniquely mapped into small ordinal numbers; assigning the pool 1150 identifiers in this way becomes a requirement of the provisioning 1151 system. 1153 Note that since this technique signals the same information to all 1154 the remote PEs, it can be supported via point-to-multipoint 1155 signaling. This sort of scheme is discussed in [L2VPN-BGP]. 1157 This provisioning model can be applied as long as the following 1158 conditions hold: 1160 - There is no need to provision different characteristics for the 1161 different PWs, and 1163 - It makes no difference which pairs of ACs are bound together by 1164 PWs, as long as both ACs in the pair come from like-colored 1165 pools, and 1167 - It is possible to construct the desired overlay topology simply 1168 by assigning colors to the pools. (This is certainly simple if a 1169 full mesh is desired, or if a hub and spoke configuration is 1170 desired; creating arbitrary topologies is less simple, and 1171 perhaps not always possible.) 1173 3.3.2. Requirements on Auto-Discovery Procedures 1175 Some of the requirements for auto-discovery procedures can be deduced 1176 from the above. 1178 To support the single-sided provisioning model, auto-discovery must 1179 be able to map a globally unique identifier (of a PW or of an 1180 Attachment Circuit) to an IP address of a PE. 1182 To support the colored pools provisioning model, auto-discovery must 1183 enable a PE to determine the set of other PEs that contain pools of 1184 the same color. 1186 Examples of suitable auto-discovery procedures can be found in 1187 Examples of suitable auto-discovery procedures can be found in 1188 [L2VPN-BGP], [BGP-AUTO] and [L2VPN-SIGNALING], and [VPLS-L2TP-RAD]. 1190 These requirements enable the auto-discovery scheme to provide the 1191 information, which the PEs need to set up the PWs. 1193 There are additional requirements on the auto-discovery procedures 1194 that cannot simply be deduced from the provisioning model: 1196 - Particular signaling schemes may require additional information 1197 before they can proceed, and hence may impose additional 1198 requirements on the auto-discovery procedures. 1200 - A given Service Provider may support several different types of 1201 signaling procedures, and thus the PEs may need to learn, via 1202 auto- discovery, which signaling procedures to use. 1204 - Changes in the configuration of a PE should be reflected by the 1205 auto-discovery procedures, within a timely manner, and without 1206 the need to explicitly reconfigure any other PE. 1208 - The auto-configuration procedures must work across service 1209 provider boundaries. This rules out, e.g., the use of schemes 1210 that piggyback the auto-discovery information on the backbone's 1211 IGP. 1213 3.3.3. Heterogeneous Pseudowires 1215 Under certain circumstances, it may be desirable to have a PW that 1216 binds two ACs that use different technologies (e.g., one is ATM, one 1217 is Ethernet). There are a number of different ways, depending on the 1218 AC types, in which this can be done. For example: 1220 - If one AC is ATM and one is FR, then standard ATM/FR Network 1221 Interworking can be used. In this case, the PW might be signaled 1222 for ATM, with the Interworking function occurring between the PW 1223 and the FR AC. 1225 - A common encapsulation can be used on both ACs, e.g., if one AC 1226 is Ethernet and one is FR, an "Ethernet over FR" encapsulation 1227 can be used on the latter. In this case, the PW could be 1228 signaled for Ethernet, with the processing of the Ethernet over 1229 FR encapsulation being local to the PE with the FR AC. 1231 - If it is known that the two ACs attach to IP routers or hosts, 1232 and carry only IP traffic, then one could use a PW which carries 1233 the IP packets, and the respective Layer2 encapsulations would be 1234 local matters for the two PEs. However, if one of the ACs is a 1235 LAN and one is a point-to-point link, care would have to be taken 1236 to ensure that such procedures as ARP and Inverse ARP are 1237 properly handled; this might require some signaling, and some 1238 proxy functions. Further, if the CEs use a routing algorithm that 1239 has different procedures for LAN interfaces than for point-to- 1240 point interfaces, additional mechanisms may be required to ensure 1241 proper interworking. These issues are discussed in [ARP- 1242 MEDIATION]. 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 SA 1291 learning on frames received on PWs from other Forwarders, and must 1292 also do the related set of procedures, such as the aging out of 1293 address entries. Frames with unknown DAs or multicast DAs must be 1294 "broadcast" by one Forwarder to all the others (on the same emulated 1295 LAN). There are however a few important differences between the VPLS 1296 Forwarder VSI and the standard bridge forwarding function: 1298 - A VPLS Forwarder never learns the MAC SAs of frames which it 1299 receives on its ACs, it only learns the MAC SAs of frames which 1300 are received on PWs from other VPLS Forwarders; 1302 - The VPLS Forwarders of a particular emulated LAN do not 1303 participate in a spanning tree protocol with each other. A 1304 "split horizon" technique is used to prevent forwarding loops. 1306 These points are discussed further in the next section. 1308 Note that the PE bridge modules which are on a given Emulated LAN may 1309 or may not run spanning tree protocol with each other over the 1310 Emulated LAN; whether they do so or not is outside the scope of the 1311 VPLS specifications. The PE bridge modules will do MAC address 1312 learning on the ACs. The PE bridge modules also do MAC address 1313 learning on the Emulated LAN interfaces, but do not do MAC address 1314 learning on the PWs, as the PWs are "hidden" behind the Emulated LAN 1315 interface. Conceptually, the PE bridge module's forwarding table and 1316 the VPLS Forwarder's VSI are distinct entities. (Of course, 1317 particular implementations might combine these into a single table, 1318 but that is beyond the scope of this document.) 1320 A further issue does arise in the case where the PE bridges do run 1321 bridge control protocols with each other over the Emulated LAN. 1322 Bridge control protocols are generally designed to run in over a real 1323 LAN, and may presume, for their proper functioning, certain 1324 characteristics of the LAN, such as low latency and sequential 1325 delivery. If the Emulated LAN does not provide these 1326 characteristics, the control protocols may not perform as expected 1327 unless special mechanisms are provided for carrying the control 1328 frames. 1330 It should be noted that changes in the spanning tree (if any) of a 1331 customer network, or in the spanning tree (if any) of the PE bridges, 1332 may cause certain MAC addresses to change their location from one PE 1333 to another. These changes may not be visible to the VPLS Forwarders, 1334 which means that those MAC addresses might become unreachable until 1335 they are aged out of the first PE's VSI. If this is not acceptable, 1336 some mechanism for communicating such changes to the VPLS Forwarders 1337 must be provided. 1339 VPLS solutions are found e.g. in [VPLS-L2TP-RAD], [VPLS-LDP], and 1341 [VPLS-BGP]. 1343 3.4.1. VPLS Overlay Topologies and Forwarding 1345 Within a single VPLS, the VPLS Forwarders are interconnected by PWs. 1346 The set of PWs thus forms an "overlay topology". 1348 The VPLS Forwarder VSIs are populated by means of MAC address 1349 learning. That is, the VSI keeps track of which MAC SAs have been 1350 received over which PWs. The presumption of course is that if a 1351 particular MAC address appears as the SA of a frame received over a 1352 particular PW, then frames which carry that MAC address in the DA 1353 field should be sent to the VSI which is at the remote end of the PW. 1354 In order for this presumption to be true, there must be a unique VSI 1355 at the remote end of the PW, which means that VSIs cannot be 1356 interconnected by means of multipoint-to-point PWs. The PWs are 1357 necessarily either point-to-point or, possibly, point-to-multipoint. 1359 MAC learning over a point-to-point PW is done via the standard 1360 techniques as specified by IEEE, where the PW is treated by the VPLS 1361 Forwarder as a "bridge port". Of course, if a MAC address is learned 1362 from a point-to-multipoint PW, the VSI must indicate that packets to 1363 that address are to be sent over a point-to-point PW which leads to 1364 the root of that point-to-multipoint PW. 1366 The VSI forwarding decisions must be coordinated so that loop-free 1367 forwarding over the overlay topology is ensured. 1369 There are several possible types of overlay topologies: 1371 - Full mesh 1373 In a full mesh, every VSI in a given VPLS has exactly one point- 1374 to-point PW to every other VSI in that same VPLS. 1376 In this topology, loop free forwarding of frames is ensured by 1377 the following rule: if a VSI receives a frame, over a PW, from 1378 another VSI, it MUST NOT forward that frame over ANY other PW to 1379 any other VSI. This ensures that once a frame traverses the 1380 Emulated LAN, it must be sent off the Emulated LAN. 1382 If a VSI receives, on one of its Emulated LAN interfaces, a 1383 unicast frame with a known DA, the frame is sent on exactly one 1384 point-to-point PW. 1386 If a VSI receives, on one of its Emulated LAN interfaces, a 1387 multicast frame or a unicast frame with unknown DA, it send a 1388 copy of the frame to each other VSI in the same Emulated LAN. 1389 This can be done by replicating the frame and sending a copy over 1390 each point-to-point PW. Alternatively, the full mesh of point- 1391 to-point PWs may be augmented with point-to-multipoint PWs, where 1392 each VSI in a VPLS is the transmitter on a single point-to- 1393 multipoint PW, and the receivers on that PW are all the other 1394 VSIs in that VPLS. 1396 - Tree Structured 1398 In a tree structured topology, every VSI in a particular VPLS is 1399 provisioned to be at a particular level in the tree. A given VSI 1400 has at most one pseudowire leading to a higher level. The root of 1401 the tree is considered to be the highest level. 1403 In this topology, loop free forwarding of frames is ensured by 1404 the following rule: if a frame is received over a pseudowire from 1405 a higher level, it may not be sent over a pseudowire that leads 1406 to a higher level. 1408 - Tree with Meshed Highest Level 1410 In this variant of the tree-structured topology, there may be 1411 more than one VSI at the highest level, but the set of VSIs which 1412 are at the highest level must be fully meshed. To ensure loop 1413 free forwarding, we need to impose the rule that a frame can be 1414 sent on a pseudowire to the same or higher level only if it 1415 arrived over a pseudowire from a lower level, and frames arriving 1416 over PWs from the same level cannot be sent on PWs to the same 1417 level. 1419 Other overlay topologies are also possible, e.g., an arbitrary 1420 partial mesh of PWs among the VSIs of a VPLS. Loop-freedom could 1421 then be assured by, for example, running spanning tree on the 1422 overlay. These topologies are not further considered in this 1423 framework. 1425 Note that loop freedom in the overlay topology does not necessarily 1426 ensure loop freedom in the overall customer LAN that contains the 1427 VPLS. It does not even ensure loop freedom among the PE bridge 1428 modules. It ensures only that when a frame is sent on the Emulated 1429 LAN, the frame will not loop endlessly before (or instead of) leaving 1430 the Emulated LAN. 1432 Improper configuration of the customer LAN or PE bridge modules may 1433 cause frames to loop, and frames that fall into such loops may 1434 transit the overlay topology multiple times. Procedures that enable 1435 the PE to detect and/or prevent such loops may be advisable. 1437 3.4.2. Provisioning and Auto-Discovery 1439 Each VPLS must be assigned a globally unique identifier. This can be 1440 thought of as a VPN-id. 1442 The ACs attaching the CEs to the PEs must be provisioned on both the 1443 PEs and the CEs. A VSI for that VPLS must be provisioned on the PE, 1444 and the local ACs of that VPLS must be associated with that VSI. The 1445 VSI must be provisioned with the identifier of the VPLS to which it 1446 belongs. 1448 An auto-discovery scheme may be used by a PE to map a VPLS identifier 1449 into the set of remote PEs that have VSIs in that VPLS. Once this 1450 set is determined, the PE can use pseudowire signaling to set up a PW 1451 to each of those VSIs. The VPLS identifier would serve as the 1452 signaling protocol's Forwarder Selector. This would result in a full 1453 mesh of PWs among the VSIs in a particular VPLS. 1455 If a single VPLS contains multiple VLANs, then it may be desirable to 1456 limit connectivity so that two VSIs are connected only if they have a 1457 VLAN in common. 1459 In this case, each VSI would need to be provisioned with one or more 1460 VLAN ids, and the auto-discovery scheme would need to map a VPLS 1461 identifier into pairs of . 1463 If a fully meshed topology of VSIs is not desired, then each VSI 1464 needs to be provisioned with additional information specifying its 1465 placement in the topology. This information would also need to be 1466 provided by the auto-discovery scheme. 1468 Examples of suitable auto-discovery procedures can be found in 1469 [L2VPN-BGP], [BGP-AUTO] and [L2VPN-SIGNALING], and [VPLS-L2TP-RAD]. 1471 Alternatively, the single-sided provisioning method discussed in 1472 section 3.3.1.2 could be used. As this is more complicated, it would 1473 only be used if it were necessary to associate individual PWs with 1474 individual characteristics. For example, if different guaranteed 1475 bandwidths were needed between different pairs of sites within a 1476 VPLS, the PWs would have to be individually provisioned. 1478 3.4.3. Distributed PE 1480 Often when a VPLS type of service is provided, the CE devices attach 1481 to a provider-managed CPE device. This provider-managed CPE device 1482 may attach to CEs of multiple customers, especially if, e.g., there 1483 are multiple customers occupying the same building. However, this 1484 device is really part of the SP's network, hence may be considered to 1485 be a PE device. 1487 In some scenarios when a VPLS type of service is provided, the CE 1488 devices attach to a provider-managed intermediary device. This 1489 provider- managed device may attach to CEs of multiple customers. 1490 This may arise in a situation there multiple customers occupying the 1491 same building. This device is really part of the SP's network, and 1492 may for that reason be considered to be a PE device, however in the 1493 simplest case it is only performing aggregation and none of the 1494 function associated with a VPLS. 1496 Relative to the VPLS there are three different possibilities to 1497 allocate functions to a device in such a position in the provider 1498 network: 1500 - it can perform aggregation and pure Layer2 service only, in which 1501 case it does not really play the role of a PE device in a VPLS 1502 service. In this case the intermediary system must connect to 1503 devices that perform VPLS PE functionality; the intermediary 1504 device itself is not part of the VPLS architecture and has hence 1505 not been named in this architecture. 1507 - it can perform all the PE functions relevant for a VPLS, in such 1508 a case the device is called VPLS-PE, see [L2VPN-TERM]. This type 1509 of device will be connected to the core (P) routers. 1511 The PE functionality for a VPLS may be distributed between two 1512 devices, one "low-end" closer to the customer that performs e.g. the 1513 MAC-address learning and forwarding decisions, and one "high-end" 1514 that performs the control functions, e.g. establishing tunnels, PWs 1515 and VCs. We call the low-end device User-Facing PE (U-PE) and the 1516 high-end device Network- Facing PE (N-PE). 1518 It is conceivable that the U-PE may be placed very close to the 1519 customer, e.g. in a building with more than one customer. The N-PE 1520 will presumably be placed on the SP's premises. PE-POP, will 1521 presumably be placed on the SP's premises. 1523 The distributed case is potentially of interest for a number of 1524 possible reasons: 1526 - The N-PE may be a device that cannot easily implement the VSI 1527 functionality described above. E.g., perhaps the N-PE is a router 1528 which cannot perform the high speed MAC learning that is needed 1529 in order to implement a VSI forwarder. At the same time, the U-PE 1530 may need to be a low-cost device that also cannot implement the 1531 full set of VPLS functions. 1533 This leads one to investigate further if there are sensible ways 1534 to split the VPLS PE functionality between the U-PE and the N-PE. 1536 - Generally, in the L2VPN architecture, the PEs are expected to 1537 participate as peers in the backbone routing protocol. Since the 1538 number of U-PEs is potentially very large relative to the number 1539 of N-PEs, this may be undesirable, as a matter of scaling the 1540 backbone routing protocol. 1542 - The U-PE may be a relatively inexpensive device that is unable to 1543 participate in the full range of signaling and/or auto-discovery 1544 procedures that are needed in order to provide the VPLS service. 1546 The VPLS functionality can be distributed between U-PE and N-PE in a 1547 number of different ways, and a number of different proposals have 1548 been made. They all presume that the U-PE will maintain a VSI 1549 forwarder, connected by PWs to the remote VSIs; the N-PE thus does 1550 not need to perform the VSI forwarding function. The proposals tend 1551 to differ with respect to the following questions: 1553 - Should the U-PEs perform full PW signaling to set up the PWs to 1554 remote VSIs? Or should the N-PEs do this signaling? 1556 Since the U-PEs need to be able to send packets on PWs to remote 1557 VSIs and receive packets on PWs from remote VSIs, if the PW 1558 signaling is done by the N-PE, there would have to be some form 1559 of "lightweight" (presumably) signaling between N-PE and U-PE 1560 that allows the PWs to be extended from N-PE to U-PE. 1562 - Should the U-PEs do their own auto-discovery, or should this be 1563 done by the N-PEs? In the latter case, the U-PEs may need to have 1564 some means of telling the N-PEs which VPLS's they are interested 1565 in, and the N-PEs must have some means of passing the results of 1566 the auto-discovery process to the U-PE. 1568 Whether it makes sense to split auto-discovery in this manner may 1569 depend on the particular auto-discovery protocol used. One would 1570 not expect the U-PEs to participate in a BGP-based auto-discovery 1571 scheme, e.g., but perhaps they would be expected to participate 1572 in a RADIUS-based auto-discovery scheme. 1574 - If a U-PE does not participate in routing, but is redundantly 1575 connected to two different N-PEs, can the U-PE still make an 1576 intelligent choice of the best N-PE to use as the "next hop" for 1577 traffic destined to a particular remote VSI? If not, can this 1578 choice be made as the result of some other sort of interaction 1579 between N-PE and U-PE? Or does this choice need to be established 1580 by provisioning? 1582 - If a U-PE does not participate in routing, but does participate 1583 in full PW signaling, and if MPLS is being used, how can the the 1584 N-PE send the the U-PEs the labels that the U-PE needs to send 1585 traffic to its signaling peers. (If the U-PE did participate in 1586 routing, this would happen automatically.) 1588 - When a frame must be multicast, should the replication be done by 1589 the N-PE or the U-PE? 1591 These questions are not all independent; the way one answers some 1592 of them may influence the way one answers others. 1594 3.4.4. Scaling issues in VPLS deployment 1596 In general, the PSN supports a VPLS solution with a tunnel from each 1597 VPLS-PE every other VPLS-PE participating in the same VPLS instance. 1598 Strictly, VPLS-PE's with more than one VPLS instance in common only 1599 need one tunnel, but for resource allocation reasons it might be 1600 necessary to establish several tunnels. For each VPLS service on a 1601 given VPLS-PE it needs to establish one pseudowire to every other 1602 VPLS-PE participating in that VPLS service. In total n*(n-1) 1603 pseudowires must be setup between the VPLS-PE routers. In large scale 1604 deployment this obviously creates scaling problems. One way to 1605 address the scaling problems is to use hierarchy; this is discussed 1606 in [VPLS-LDP]. 1608 3.5. IP-only LAN-like Service (IPLS) 1610 If, instead of providing a general VPLS service, one wishes to 1611 provide a VPLS that is used only to connect IP routers or hosts 1612 (i.e., the CE devices are all assumed to be IP routers or hosts), 1613 then it is possible to make certain simplifications. 1615 In this environment, all Ethernet frames sent from a particular CE to 1616 a particular PE on a particular Attachment Circuit will have the same 1617 MAC Source Address. Thus rather than using address learning in the 1618 data plane to learn the MAC addresses, the PE can use the control 1619 plane to learn the MAC address. (See [ARP-MEDIATION] for a discussion 1620 of this.) This allows the PE to be implemented on devices that are 1621 not capable of doing MAC address learning in the data plane. 1623 To eliminate the need for MAC address learning on the PWs as well as 1624 on the ACs, the pseudowire signaling protocol would have to carry the 1625 MAC address from one pseudowire endpoint to the other. Each PE would 1626 perform proxy ARP to its directly attached CEs. 1628 Eliminating the need to do MAC address learning on the PWs eliminates 1629 the need for the PWs to be point-to-point. Multipoint-to-point PWs 1630 could be used instead. 1632 Unlike a VPLS, all the ACs in an IPLS would not necessarily have to 1633 carry Ethernet frames; only the IP packets would need to be passed 1634 across the network, not their Layer2 wrappers. However, this might 1635 require "translation" between "ARP" and "Inverse ARP". The set of 1636 routing protocols which could be carried across the IPLS might also 1637 be restricted. A fuller discussion of the advantages, disadvantages, 1638 and restrictions may be found in [ARP-MEDIATION]. 1640 4. Security Considerations 1642 The security considerations section of the L2VPN requirements 1643 document [L2VPN-REQ] addresses a number of areas that are potentially 1644 insecure aspects of the L2VPN. These relate to both control plane 1645 and data plane security issues that may arise in the following areas: 1647 - issues fully contained in the provider network 1649 - issues fully contained in the customer network 1651 - issues in the customer-provider interface network 1653 These three areas are addressed below. 1655 4.1. Provider Network Security Issues 1657 This section discusses security issues that only impact the SP's 1658 equipment. 1660 There are security issues having to do with the control connections 1661 that are used on a PE-PE basis for setting up and maintaining the 1662 pseudowires. 1664 A PE should not engage with another PE in a control connection unless 1665 it has some confidence that the peer is really a PE to which it 1666 should be setting up PWs. Otherwise L2PVN traffic may go to the 1667 wrong place. If control packets are maliciously and undetectably 1668 altered while in flight, denial of service, or alteration of the 1669 expected quality of service, may result. 1671 If peers discover each other dynamically (via some auto-discovery 1672 procedure), this presupposes that the auto-discovery procedures are 1673 themselves adequately trusted. 1675 PEs should not accept control connections from arbitrary entities; a 1676 PE should either be configured with its peers, or learn them from a 1677 trusted auto-configuration procedure. If the peer is required to be 1678 within the same SP's network, then access control filters at the 1679 borders of that network can be used to prevent spoofing of the peer's 1680 source address. If the peer is from another SP's network, then 1681 setting up such filters may be difficult or even impossible, 1682 depending on the way in which the two SPs are connected. Even if the 1683 access filters can be set up, the level of assurance which they 1684 provide will be lower. 1686 Thus for inter-SP control connections, it is advisable to use some 1687 sort of cryptographic authentication procedure. Control protocols 1688 which used TCP may use the TCP MD5 option to provide a measure of 1689 PE-PE authentication; this requires at least one shared secret 1690 between SPs. The use of IPsec between PEs is also possible, and 1691 provides a greater degree of assurance, though at a greater cost. 1693 When LDP [RFC3036] is used as the control protocol, the LDP security 1694 considerations discussed in [RFC3036] are applicable. Note that LDP 1695 uses both UDP as well as TCP. It may be advisable to have some 1696 protection against spoofed UDP messages which appear to be from a 1697 valid peer; this requires further study. 1699 Future versions of this document will discuss the security 1700 considerations that apply to other signaling protocols. 1702 To limit the effect of Denial of Service attacks on a PE, some means 1703 of limiting the rate of processing of control plane traffic may be 1704 desirable. 1706 Unlike authentication and integrity, privacy of the signaling 1707 messages is not usually considered very important. If it is needed, 1708 the signaling messages can be sent through an IPsec connection. 1710 4.2. Provider-Customer Network Security Issues 1712 There are a number of security issues related to the access network 1713 between the provider and the customer. This is also traditionally a 1714 network that is hard to protect physically. 1716 Typical security issues on the provider-customer interface include 1717 the following: 1719 - Preventing unauthorized members joining an L2VPN 1721 - Ensuring correct customer interface configured 1723 - Ensuring correct service delimiting fields (VLAN, DLCI, etc.) 1725 - Preventing unauthorized access to PE 1727 As the access network for an L2VPN service is necessarily a layer 2 1728 network, it is preferable to use authentication mechanisms that do 1729 not presuppose any IP capabilities on the CE device. 1731 There are existing layer 2 protocols and best current practices to 1732 guard against these security issues. For example, IEEE 802.1x 1733 defines authentication at the link level for access through an 1734 ethernet bridge; the Frame Relay Forum defines LMI extensions for 1735 authentication (FRF.17). 1737 4.3. Customer Network Security Issues 1739 Even if all CE devices are properly authorized to attach to their PE 1740 devices, misconfiguration of the PE may interconnect CEs that are not 1741 supposed to be in the same L2VPN. 1743 In a VPWS, the CEs may run IPsec to authenticate each other. Other 1744 layer 3 or layer 4 protocols may have their own authentication 1745 methods. 1747 In a VPLS, CE-to-CE IPsec is even more problematic, as IPsec does not 1748 well support the multipoint configuration which is provided by the 1749 VPLS service. 1751 There may be alternative methods for achieving a degree of CE-to-CE 1752 authentication, if the L2VPN signaling protocol can carry opaque 1753 objects between the CEs, either inband (over the L2VPN), or out-of- 1754 band, through the participation of the signaling protocol. This is 1755 for further study. 1757 The L2VPN procedures do not provide authentication, integrity, or 1758 privacy for the customer's traffic; if this is needed, it becomes the 1759 responsibility of the customer. 1761 If there is CE-to-CE control traffic (e.g., BPDUs), on whose 1762 integrity the customer's own layer 2 network depends, it may be 1763 advisable to send the control traffic using some more secure 1764 mechanism than is used for the data traffic. 1766 5. Intellectual Property Notice 1768 The IETF takes no position regarding the validity or scope of any 1769 intellectual property or other rights that might be claimed to 1770 pertain to the implementation or use of the technology described in 1771 this document or the extent to which any license under such rights 1772 might or might not be available; neither does it represent that it 1773 has made any effort to identify any such rights. Information on the 1774 IETF's procedures with respect to rights in standards-track and 1775 standards-related documentation can be found in BCP-11. Copies of 1776 claims of rights made available for publication and any assurances of 1777 licenses to be made available, or the result of an attempt made to 1778 obtain a general license or permission for the use of such 1779 proprietary rights by implementors or users of this specification can 1780 be obtained from the IETF Secretariat. 1782 The IETF invites any interested party to bring to its attention any 1783 copyrights, patents or patent applications, or other proprietary 1784 rights which may cover technology that may be required to practice 1785 this standard. Please address the information to the IETF Executive 1786 Director. 1788 6. Copyright Notice 1790 "Copyright (C) The Internet Society (date). All Rights Reserved. 1792 This document and translations of it may be copied and furnished to 1793 others, and derivative works that comment on or otherwise explain it 1794 or assist in its implementation may be prepared, copied, published 1795 and distributed, in whole or in part, without restriction of any 1796 kind, provided that the above copyright notice and this paragraph are 1797 included on all such copies and derivative works. However, this 1798 document itself may not be modified in any way, such as by removing 1799 the copyright notice or references to the Internet Society or other 1800 Internet organizations, except as needed for the purpose of 1801 developing Internet standards in which case the procedures for 1802 copyrights defined in the Internet Standards process must be 1803 followed, or as required to translate it into languages other than 1804 English. 1806 The limited permissions granted above are perpetual and will not be 1807 revoked by the Internet Society or its successors or assigns. 1809 This document and the information contained herein is provided on an 1810 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1811 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1812 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1813 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1814 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1816 7. Normative References 1818 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 1819 Requirement Levels", RFC 2119, March 1997. 1821 8. Informative References 1823 [RFC3036] Andersson, L et.al. "LDP Specification", RFC 3036, Jan 1824 2001. 1826 [ARP-MEDIATION] Shah, J. et. al., "ARP Mediation for IP interworking 1827 of Layer 2 VPN", draft-shah-ppvpn-arp-mediation-02.txt, Work in 1828 Progress, June 2003. 1830 [BGP-AUTO] Ould-Brahim, H. et.al. "Using BGP as an Auto-Discovery 1831 Mechanism for Network-based VPNs",draft-ietf-l3vpn-bgpvpn-auto- 1832 00.txt, Work in Progress, July 2003. 1834 [IPLS] Shah H., et.al. "IP-Only LAN Service (IPLS)", draft-shah- 1835 ppvpn-ipls-02.txt, June 2003. 1837 [L2TP-BASE] Lau, J. "Layer Two Tunneling Protocol (Version 3) 1838 L2TPv3", draft-ietf-l2tpext-l2tp-base-10.txt", Work in Progress, 1839 April 2003. 1841 [L2VPN-BGP] Kompella, K. et.al. "Layer 2 VPNs Over Tunnels", draft- 1842 kompella-ppvpn-l2vpn-03.txt, April 2003. 1844 [L2VPN-REQ] Augustyn, W. et.al "Service Requirements for Layer 2 1845 Provider Provisioned Virtual Private Networks", draft-ietf-l2vpn- 1846 requirements-00.txt, Work in Progress, May 2003. 1848 [L2VPN-TERM] Andersson, L. and Madsen T. "VPN Terminology", draft- 1849 andersson-ppvpn-terminology-03.txt", Work in Progress, April 2003. 1851 [L2VPN-SIGNALING] Rosen, E. "Provisioning Models and Endpoint 1852 Identifiers in L2VPN Signaling", draft-ietf-l2vpn-signaling-00.txt, 1853 Work in Progress, September 2003. 1855 [L3VPN-FW] Callon, R. et.al. "A Framework for Layer 3 Provider 1856 Provisioned Virtual Private Networks", draft-ietf-l3vpn-framework- 1857 00.txt, Work in Progress, Internet Draft, July 2003. 1859 [L3VPN-REQ] Carugi, M. et.al. "Service requirements for Layer 3 1860 Provider Provisioned Virtual Private Networks" draft-ietf-l3vpn- 1861 requirements-00.txt, Work in Progress, July 2003. 1863 [MPLS-IP-GRE] Worster, T., et. al., "Encapsulating MPLS in IP or 1864 GRE", draft-ietf-mpls-in-ip-or-gre-02.txt, Work in Progress, August 1865 2003. 1867 [PWE3-ARCH] Bryant, S., "PWE3 Architecture", draft-ietf-pwe3-arch- 1868 05.txt, Work in Progress, August 2003. 1870 [PWE3-LDP] Martini, L. et.al. "Pseudowire Setup and Maintenance using 1871 LDP", draft-ietf-pwe3-control-protocol-03.txt, Work in Progress, July 1872 2003. 1874 [VPLS-BGP] Kompella, K. "Virtual Private LAN Service", draft-ietf- 1875 l2vpn-vpls-bgp-00.txt, Work in Progress, May 2003. 1877 [VPLS-L2TP-RAD] Heinanen, J, "Radius/L2TP Based VPLS", draft- 1878 heinanen-radius-l2tp-vpls-0-.txt, Work in Progress, February 2003. 1880 [VPLS-LDP] Lasserre, M. et.al. "Virtual Private LAN Services over 1881 MPLS", draft-ietf-l2vpn-vpls-ldp-00.txt, Work in progress, June 2003. 1883 9. Authors and Acknowledgments 1885 This document is the outcome of discussions within a PPVPN Layer 2 1886 VPN design team, all of whose members could be considered to be co- 1887 authors. Specifically, the co-authors are Loa Andersson, Waldemar 1888 Augustyn, Marty Borden, Hamid Ould-Brahim, Juha Heinanen, Kireeti 1889 Kompella, Vach Kompella, Marc Lasserre, Pascal Menezes, Vasile 1890 Radoaca, Eric Rosen, and Tissa Senevirathne. 1892 The authors would like to thank Marco Carugi for cooperation in 1893 setting up context, working directions and taking time for 1894 discussions in this space, Tove Madsen for valuable input and 1895 reviews, and Norm Finn, Matt Squires, and Ali Sajassi for valuable 1896 discussion of the VPLS issues. 1898 10. Authors' Contact Information 1900 Loa Andersson 1901 Email: loa@pi.se 1903 Eric C. Rosen 1904 Cisco Systems, Inc. 1905 1414 Massachusetts Avenue 1906 Boxborough, MA 01719 1907 Email: erosen@cisco.com 1909 Waldemar Augustyn 1910 Email: waldemar@nxp.com 1912 Marty Borden 1913 mborden@acm.org 1915 Juha Heinanen 1916 Song Networks, Inc. 1917 Hallituskatu 16 1918 33200 Tampere, Finland 1919 Email: jh@song.fi 1921 Kireeti Kompella 1922 Juniper Networks, Inc. 1923 1194 N. Mathilda Ave 1924 Sunnyvale, CA 94089 1925 Email: kireeti@juniper.net 1927 Vach Kompella 1928 TiMetra Networks 1929 274 Ferguson Dr. 1930 Mountain View, CA 94043 1931 Email: vkompella@timetra.com 1932 Marc Lasserre 1933 Riverstone Networks 1934 5200 Great America Pkwy 1935 Santa Clara, CA 95054 1936 Email: marc@riverstonenet.com 1938 Pascal Menezies 1939 Email: pascalm1@yahoo.com 1941 Hamid Ould-Brahim 1942 Nortel Networks 1943 P O Box 3511 Station C 1944 Ottawa, ON K1Y 4H7, Canada 1945 Email: hbrahim@nortelnetworks.com 1947 Vasile Radoaca 1948 Nortel Networks 1949 600 Technology Park 1950 Billerica, MA 01821 1951 Email: vasile@nortelnetworks.com 1953 Tissa Senevirathne 1954 1567 Belleville Way 1955 Sunnyvale CA 94087 1956 Email: tsenevir@hotmail.com