idnits 2.17.1 draft-ietf-l2vpn-l2-framework-00.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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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: ---------------------------------------------------------------------------- == Line 1696 has weird spacing: '...Typical secur...' == Line 1697 has weird spacing: '...include the f...' -- 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 (February 2003) is 7740 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- FW' is mentioned on line 463, but not defined == Missing Reference: 'ROSEN- L2-SIGNALING' is mentioned on line 936, but not defined == Missing Reference: 'KOMPELLA- DTLS' is mentioned on line 1492, but not defined == Unused Reference: 'RFC2026' is defined on line 1748, but no explicit reference was found in the text == Unused Reference: 'PWE3-FW' is defined on line 1851, but no explicit reference was found in the text == Unused Reference: 'SHAH-SIG' is defined on line 1871, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-01) exists of draft-andersson-ppvpn-metrics-00 -- Possible downref: Normative reference to a draft: ref. 'ANDERSSON-METRICS' == Outdated reference: A later version (-04) exists of draft-andersson-ppvpn-terminology-00 -- Possible downref: Normative reference to a draft: ref. 'ANDERSSON-TERM' -- No information found for draft-ietf-ppvpn-bgpvpn-auto - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BGP-AUTO' -- Possible downref: Normative reference to a draft: ref. 'DIRLDP' -- Possible downref: Normative reference to a draft: ref. 'DNS-LDP-VPLS' == Outdated reference: A later version (-03) exists of draft-kompella-ppvpn-dtls-01 -- Possible downref: Normative reference to a draft: ref. 'KOMPELLA-DTLS' == Outdated reference: A later version (-03) exists of draft-kompella-ppvpn-l2vpn-01 -- Possible downref: Normative reference to a draft: ref. 'KOMPELLA-L2VPN' == Outdated reference: A later version (-02) exists of draft-kompella-ppvpn-vpls-00 -- Possible downref: Normative reference to a draft: ref. 'KOMPELLA-VPLS' == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-02 == Outdated reference: A later version (-07) exists of draft-ietf-l2tpext-pwe3-fr-00 -- Possible downref: Normative reference to a draft: ref. 'L2VPN-ARCH' == Outdated reference: A later version (-02) exists of draft-augustyn-ppvpn-l2vpn-requirements-00 -- Possible downref: Normative reference to a draft: ref. 'L2VPN-REQ' -- No information found for draft-ietf-ppvpn-framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'L3VPN-FW' -- No information found for draft-ietf-ppvpn-requirements - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'L3VPN-REQ' == Outdated reference: A later version (-04) exists of draft-lasserre-vkompella-ppvpn-vpls-01 -- Possible downref: Normative reference to a draft: ref. 'LASSERRE-VKOMPELLA-VPLS' == Outdated reference: A later version (-19) exists of draft-martini-l2circuit-trans-mpls-08 ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-trans-mpls (ref. 'MARTINI-SIGNALING') -- Possible downref: Normative reference to a draft: ref. 'MOHAN-LPE' -- Possible downref: Normative reference to a draft: ref. 'MPLS-GRE' -- Possible downref: Normative reference to a draft: ref. 'MPLS-IP' == Outdated reference: A later version (-01) exists of draft-ietf-pwe3-framework-00 -- Possible downref: Normative reference to a draft: ref. 'PWE3-FW' == Outdated reference: A later version (-03) exists of draft-rosen-ppvpn-l2-signaling-01 -- Possible downref: Normative reference to a draft: ref. 'ROSEN-L2-SIGNALING' -- Possible downref: Normative reference to a draft: ref. 'SAJASSI-VPLS' -- No information found for draft-shah-l2vpn-arp-resolve - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SHAH-INTER' -- Possible downref: Normative reference to a draft: ref. 'SHAH-SIG' Summary: 6 errors (**), 0 flaws (~~), 22 warnings (==), 27 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: August 2003 Eric Rosen 5 Cisco Systems, Inc. 7 Editors 9 February 2003 11 L2VPN Framework 13 draft-ietf-l2vpn-l2-framework-00.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 . 8 55 2.3.1 Entities in the Distributed PE Reference Models .... 8 56 2.4 VPWS-PE and VPLS-PE ................................ 8 57 3 Functional Components of L2 VPN .................... 9 58 3.1 Types of L2VPN ..................................... 9 59 3.1.1 Virtual Private Wire Service (VPWS) ................ 9 60 3.1.2 Virtual Private LAN Service (VPLS) ................. 10 61 3.1.3 IP-only LAN-like Service (IPLS) .................... 10 62 3.2 Generic L2VPN Transport Functional Components ...... 11 63 3.2.1 Attachment Circuits ................................ 11 64 3.2.2 Pseudowires ........................................ 11 65 3.2.3 Forwarders ......................................... 13 66 3.2.4 Tunnels ............................................ 14 67 3.2.5 Encapsulation ...................................... 15 68 3.2.6 Pseudowire Signaling ............................... 15 69 3.2.6.1 Point-to-Point Signaling ........................... 17 70 3.2.6.2 Point-to-Multipoint Signaling ...................... 17 71 3.2.6.3 Inter-AS Considerations ............................ 19 72 3.2.7 Service Quality .................................... 19 73 3.2.7.1 Quality of Service (QoS) ........................... 19 74 3.2.7.2 Resiliency ......................................... 20 75 3.2.8 Management ......................................... 21 76 3.3 VPWS ............................................... 21 77 3.3.1 Provisioning and Auto-Discovery .................... 22 78 3.3.1.1 Attachment Circuit Provisioning .................... 22 79 3.3.1.2 PW Provisioning for Arbitrary Overlay Topologies ... 23 80 3.3.1.3 Colored Pools PW Provisioning Model ................ 24 81 3.3.2 Requirements on Auto-Discovery Procedures .......... 26 82 3.3.3 Heterogeneous Pseudowires .......................... 27 83 3.4 VPLS Emulated LANs ................................. 28 84 3.4.1 VPLS Overlay Topologies and Forwarding ............. 30 85 3.4.2 Provisioning and Auto-Discovery .................... 32 86 3.4.3 Distributed PE ..................................... 33 87 3.4.4 Scaling issues in VPLS deployment .................. 35 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 References ......................................... 39 94 6 Authors and Acknowledgments ........................ 42 95 7 Authors' Contact Information ....................... 43 97 1. Introduction 99 1.1. Conventions used in this document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC-2119 [RFC2119]. 105 1.2. Objectives and Scope of the Document 107 This document provides a framework for Layer 2 Provider Provisioned 108 Virtual Private Networks (PPVPNs). This framework is intended to aid 109 in standardizing protocols and mechanisms to support interoperable 110 Layer2 PPVPNs. 112 The PPVPN WG group works with both Layer 3 PPVPNs and Layer 2 PPVPNs. 113 A framework for L3 VPNs is found in [L3VPN-FW]. This document 114 provides the same type of framework for Layer 2 PPVPNs as the Layer 3 115 framework does for Layer 3 PPVPNs. 117 The term "provider provisioned VPNs" refers to Virtual Private 118 Networks (VPNs) for which the Service Provider (SP) participates in 119 management and provisioning of the VPN. 121 There are multiple ways in which a provider can participate in a VPN, 122 and there are therefore multiple different types of PPVPNs. The 123 framework document discusses Layer2 VPNs (as defined in section 1.3). 124 It also describes technical issues related to VPNs in which the 125 provider participates in provisioning for provider edge and customer 126 edge devices. 128 First, this document discusses reference models for Layer 2 PPVPNs. 129 Then the functional components of Layer2 PPVPN operations are 130 discussed. 132 Specifically, this includes discussion of the technical issues, which 133 are important in the design of standards and mechanisms for support 134 of Layer 2 PPVPNs. Furthermore, technical aspects of Layer2 PPVPNs 135 interworking is clarified. Finally, security issues as they apply to 136 Layer2 PPVPNs are addressed. 138 Requirements for Layer 3 VPNs are found in [L3VPN-REQ] and for Layer 139 2 VPNs, for VPLS and VPWS, in [L2VPN-REQ]. 141 This document has "inherited" a substantial content from "An 142 Architecture for L2VPNs" [L2VPN-ARCH]. 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 In [ANDERSSON-METRICS] parameters and metrics that could be used to 156 compare different Layer 2 VPN solutions and how they could be 157 evaluated when a L2 VPN has to meet different set of requirements is 158 discussed. The parameters to be considered in evaluating L2 VPN 159 implementations in different environments are e.g. scaling, cost, 160 inter-domain reachability, provisioning, flexibility, integration and 161 migration from existing infrastructure and services, value-added 162 services, cost, etc. 164 Currently we see two kinds of services that a service provider could 165 offer to a customer by means of Layer 2 VPNs. Virtual Private Wire 166 Service(VPWS)and a Virtual Private LAN Service (VPLS). The 167 possibility of an IP-only LAN-like Service (IPLS) is opened up, but 168 is very much for future study. 170 A VPWS is a VPN service that supplies a L2 point-to-point service. 171 Being a point-to-point service where there are very few scaling 172 issues with the service as such. Scaling issues might arise from the 173 number of end- points that can be supported on a particular PE. 175 A VPLS is an L2 service that in all respects emulates LAN across a 176 Wide Area Network (WAN). Thus it also has all the scaling 177 characteristics of a LAN. Other scaling issues might arise from the 178 number of end-points that can be supported on a particular PE. 180 1.4. Terminology 182 This document list some terms and concepts that are specific to the 183 L2 VPN framework, terms and concepts generally applicable to the 184 PPVPN area will be found in [ANDERSSON-TERM]. 186 2. Models 188 2.1. Reference Model for VPWS 190 The VPWS reference model is shown in Figure 1. 192 Attachment PSN Attachment 193 Circuits tunnel Circuits 194 + 195 +-----+ pseudo +-----+ 196 | | wire | | 197 | CE1 |--+ +--| CE2 | 198 | | | +-----+ +-----+ +-----+ | | | 199 +-----+ +----|---- | | P | | ----+----+ +-----+ 200 |VPWS\|---|-----|-----|/VPWS| 201 | PE1 |===|=====|=====| PE2 | 202 | /|---|-----|-----|\ | 203 +-----+ +----|---- | | | | ----|----+ +-----+ 204 | | | +-----+ +-----+ +-----+ | | | 205 | CE3 |--+ +--| CE4 | 206 | | | | 207 +-----+ +-----+ 209 Figure 1 211 2.1.1. Entities in the VPWS reference model 213 The P, PE (VPWS-PE) and CE devices and the PSN tunnel as defined in 214 [ANDERSSON-TERM]. Attachment circuit and pseudo wire as discussed in 215 section 3. The PE does a simple mapping between the PW and attachment 216 circuit based on local information, i.e. the PW de-multiplexor and 217 incoming/outgoing logical/physical port. 219 2.2. Reference Model for VPLS 221 The following diagram shows a VPLS reference model where PE devices 222 that are VPLS-capable provide a logical interconnect such that CE 223 devices belonging to a specific VPLS appear to be on a single bridged 224 Ethernet. A VPLS can contain a single VLAN or multiple, tagged VLANs. 226 The VPLS reference model is shown in Figures 2 and 3. 228 +-----+ +-----+ 229 + CE1 +--+ +---| CE2 | 230 +-----+ | ................... | +-----+ 231 VPLS A | +----+ +----+ | VPLS A 232 | |VPLS| |VPLS| | 233 +--| PE |--Routed---| PE |-+ 234 +----+ Backbone +----+ 235 / . | . \ _ /\_ 236 +-----+ / . | . \ / \ / \ +-----+ 237 + CE +--+ . | . +--\ Access \----| CE | 238 +-----+ . +----+ . | Network | +-----+ 239 VPLS B .....|VPLS|........ \ / VPLS B 240 | PE | ^ ------- 241 +----+ | 242 | | 243 | | 244 +-----+ | 245 | CE3 | +-- Emulated LAN 246 +-----+ 247 VPLS A 249 Figure 2 250 |-----Routed Backbone------| 251 | (P Routers) |PSN Tunnels, 252 Emulated LAN | |Pseudowires 253 ......................................................................... 254 . | | . 255 . |----------------------|----| |---------|-----------------| . 256 . | --------------------|--- | | -------|---------------- | . 257 . | VPLS Forwarder | | VPLS Forwarder | . 258 . | ----------|------------- | | ----------|------------- | . 259 ..|...................................................................|.. 260 | | Emulated LAN | | | Emulated LAN | 261 | | Interface | VPLS-PEs | | Interface | 262 | | | <----> | | | 263 | ----------|------------ | | ----------|------------ | 264 | | Bridge | | | | Bridge | | 265 | -|--------|---------|-- | | ---|-------|---------|- | 266 |---|--------|---------|----| |-----|-------|---------|---| 267 | | | | | | 268 | | Access | | | Access | 269 | | Networks| | | Networks| 270 | | | | | | 271 | | | | | | 272 CE devices CE devices 273 Figure 3 275 From Figure 3, we see that in VPLS, a CE device attaches, possibly 276 through an access network, to a "bridge" module of a VPLS-PE. Within 277 the VPLS-PE, the bridge module attaches, through an "Emulated LAN 278 Interface" to an Emulated LAN. For each VPLS, there is an Emulated 279 LAN instance. Figure 3 shows some internal structure to the Emulated 280 LAN: it consists "VPLS Forwarder" modules (one per VPLS-PE per VPLS 281 instance) connected by Pseudowires, where the Pseudowires may be 282 traveling through PSN tunnels over a routed backbone. 284 The functionality which the bridge module must support depends on the 285 service which is being offered by the SP to its customers, as well as 286 on various details of the SP's network. At minimum, the bridge 287 module must be able to learn MAC addresses, and to "age them out", in 288 the standard manner. However, if the PE devices have backdoor 289 connections with each other via a layer 2 network, they may need to 290 be full IEEE bridges, running spanning tree with each other. 291 Specification of the precise functionality which the bridge modules 292 must have in particular circumstances is, however, out of scope of 293 the current document. 295 2.2.1. Entities in the VPLS reference model 297 The PE (VPLS-PE) and CE devices are defined in [ANDERSSON-TERM]. 299 2.3. Reference Model for Distributed VPLS-PE or VPWS-PE 301 VPLS-PE/VPWS-PE 302 Functionality . . . . . . . 303 . . . . . . . . . . . . . 304 . . . . 305 +----+ . +----+ +----+ . . Service . 306 | CE |--.--|U-PE|----|N-PE|-.---. Provider . 307 +----+ . +----+ +----+ . . Backbone . 308 . . . . . . . . . . . . . 310 2.3.1. Entities in the Distributed PE Reference Models 312 A VPLS-PE or a VPWS-PE functionality may be distributed to more than 313 one device. The device closer to the customer/user is called User 314 facing PE (U-PE) and the device closer to the core network is called 315 Network facing PE (N-PE). 317 For further discussion see section 3.4.3. 319 The terms "U-PE" and "N-PE" are defined in [ANDERSSON-TERM]. 321 2.4. VPWS-PE and VPLS-PE 323 The VPWS-PE and VPLS-PE are functionally very similar, the they both 324 use forwarders to map attachment circuits to pseudo-wires. The only 325 differences is that while the forwarder in a VPWS-PE does a one-to- 326 one mapping between the attachment circuit and pseudo-wire, the 327 forwarder in a VPLS-PE is a Virtual Switching Instance (VSI) that 328 maps multiple attachment circuits to multiple pseudo-wires (for 329 further discussion see section 3.) 331 3. Functional Components of L2 VPN 333 This section specifies a functional model for L2VPN, which allows one 334 to break an L2VPN architecture down into its functional components. 335 This allows us to exhibit the roles played by the various protocols 336 and mechanisms, and thus to make it easier to understand the 337 differences and similarities between various proposed L2VPN 338 architectures. 340 Section 3.1 contains an overview of some different types of L2VPN. 341 In section 3.2, functional components that are common to the 342 different types are discussed. Then there is a section for each of 343 the L2VPN service types being considered. The latter sections discuss 344 functional components, which may be specific to particular L2VPN 345 types, as well as discussing type-specific features of the generic 346 components. 348 3.1. Types of L2VPN 350 The types of L2VPN are distinguished by the characteristics of the 351 service that they offer to the customers of the Service Provider 352 (SP). 354 3.1.1. Virtual Private Wire Service (VPWS) 356 In a VPWS, each CE device is presented with a set of point-to-point 357 virtual circuits. 359 The other end of each virtual circuit is another CE device. Frames 360 transmitted by a CE on such a virtual circuit are received by the CE 361 device at the other end-point of the virtual circuit. Forwarding from 362 one CE device to another is not affected by the content of the frame, 363 but is fully determined by the virtual circuit on which the frame is 364 transmitted. The PE thus acts as a virtual circuit switch. 366 This type of L2VPN has long been available over ATM and Frame Relay 367 backbones. Providing this type of L2VPN over MPLS and/or IP backbones 368 is the current topic. 370 Requirements for this type of L2VPN are specified in [L2VPN-REQ]. 372 3.1.2. Virtual Private LAN Service (VPLS) 374 In a VPLS, each CE device has one or more LAN interfaces that lead to 375 a "virtual backbone". 377 Two CEs are connected to the same virtual backbone if and only if 378 they are members of the same VPLS instance (i.e., same VPN). When a 379 CE transmits a frame, the PE that receives it examines the MAC 380 Destination Address field in order to determine how to forward the 381 frame. Thus the PE functions as a bridge. As is indicated in Figure 382 3, if a set of PEs support a common VPLS instance, then there is an 383 Emulated LAN, corresponding to that VPLS instance, to which each of 384 those PE bridges attaches (via an emulated interface). From the 385 perspective of a CE device, the virtual backbone is the set of PE 386 bridges and the Emulated LAN on which they reside. Thus to a CE 387 device, the LAN which attaches it to the PE is extended transparently 388 over the routed MPLS and/or IP backbone. 390 The PE bridge function treats the Emulated LAN as it would any other 391 LAN to which it has an interface. Forwarding decisions are made in 392 the manner which is normal for bridges, based on MAC Source Address 393 learning. 395 VPLS is like VPWS in that forwarding is done without any 396 consideration of the Layer3 header. VPLS is unlike VPWS in that: 398 - VPLS allows the PE to use addressing information in a frame's L2 399 header to determine how to forward the frame; 401 - VPLS allows a single CE/PE connection to be used for transmitting 402 frames to multiple remote CEs; in this particular respect, VPLS 403 resembles L3VPN more than VPWS. 405 Requirements for this type of L2VPN are specified in [L2VPN-REQ]. 407 3.1.3. IP-only LAN-like Service (IPLS) 409 An IPLS is very like a VPLS, except that: 411 - it is assumed that the CE devices are hosts or routers, not 412 switches 414 - it is assumed that the service will only carry IP packets, and 415 supporting packets such as ICMP and ARP; Layer2 packets which do 416 not contain IP are not supported. 418 While this service is a functional subset of the VPLS service, it is 419 considered separately because it may be possible to provide it using 420 different mechanisms, which may allow it to run on certain hardware 421 platforms that cannot support the full VPLS functionality. 423 3.2. Generic L2VPN Transport Functional Components 425 All L2VPN types must transport "frames" across the core network 426 connecting the PE's. In all L2VPN types, a PE (PE1) receives a frame 427 from a CE (CE1), then transports the frame to a PE (PE2), which then 428 transports the frame to a CE (CE2). In this section, we discuss the 429 functional components, which are necessary to transport L2 frames in 430 any type of L2VPN service. 432 3.2.1. Attachment Circuits 434 In any type of L2VPN, a CE device attaches to a PE device via some 435 sort of circuit or virtual circuit. We will call this an "Attachment 436 Circuit" (AC). We use this term very generally; an Attachment Circuit 437 may be a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, 438 a PPP connection on a physical interface, a PPP session from an L2TP 439 tunnel, an MPLS LSP, etc. The CE device may be a router, a switch, a 440 host, or just about anything, which the customer needs hooked up to 441 the VPN. An AC carries a frame between CE and PE, or vice versa. 443 Procedures for setting up and maintaining the ACs are out of scope of 444 this architecture. 446 These procedures are generally specified as part of the specification 447 of the particular Attachment Circuit technology. 449 Any given frame will traverse an AC from a CE to a PE and then on 450 another AC from a PE to a CE. 452 We refer to the former AC as the frame's "ingress AC" and to the 453 latter AC as the frame's "egress AC". Note that this notion of 454 "ingress AC" and "egress AC" is relative to a specific frame, and 455 denotes nothing more than the frame's direction of travel while on 456 that AC. 458 3.2.2. Pseudowires 460 A "Pseudowire" (PW) is a relation between two PE devices. Whereas an 461 AC is used to carry a frame from CE to PE, a PW is used to carry a 462 frame between two PEs. We use the term "pseudowire" in the sense of 463 [PWE3- FW]. 465 Setting up and maintaining the PWs is the job of the PEs. State 466 information for a particular PW is maintained at the two PEs which 467 are its endpoints, but not at other PEs, and not in the backbone 468 routers (P routers). 470 Pseudowires may be point-to-point, multipoint-to-point, or point-to- 471 multipoint. In this framework, point-to-point PWs are always 472 considered to be bidirectional; multipoint-to-point and point-to- 473 multipoint PWs are always considered to be unidirectional. 474 Multipoint-to-point PWs can be used only when the PE receiving a 475 frame from the PW does not need to know where the frame came from. 476 Point-to-multipoint PWs may be useful when frames need to be 477 multicast. 479 Procedures for setting up and maintaining point-to-multipoint PWs are 480 not considered in this version of this framework. 482 Any given frame travels first on its ingress AC, then on a PW, then 483 on its egress AC. 485 Multicast frames may be replicated by a PE, so of course the 486 information carried in multicast frames may travel on more than one 487 PW and more than one egress AC. 489 Thus with respect to a given frame, a PW may be said to associate a 490 number of ACs. If these ACs are of the same technology (e.g., both 491 ATM, both Ethernet, both Frame Relay) the PW is said to provide 492 "homogeneous transport"; otherwise it is said to provide 493 "heterogeneous transport". Heterogeneous transport requires that some 494 sort of interworking function be applied. There are at least three 495 different approaches to interworking: 497 1. One of the CEs may perform the interworking locally. For 498 example, if CE1 attaches to PE1 via ATM, but CE2 attaches to 499 PE2 via Ethernet, then CE1 may decide to send/receive Ethernet 500 frames over ATM, using the RFC2684 "LLC Encapsulation for 501 Bridged Protocols". In such a case, PE1 would need to know 502 that it is to terminate the ATM VC locally, and only 503 send/receive Ethernet frames over the PW. 505 2. One of the PEs may perform the interworking. For example, if 506 CE1 attaches to PE1 via ATM, but CE2 attaches to PE2 via Frame 507 Relay, PE1 may provide the "ATM/FR Service Interworking" 508 function. This would be transparent to the CEs, and the PW 509 would carry only Frame Relay frames. 511 3. IPLS could be used. In this case the "frames" carried by the 512 PW are IP datagrams, and the two PEs need to cooperate in order 513 to spoof various L2-specific procedures used by IP (see section 514 3.5). 516 3.2.3. Forwarders 518 In all types of L2VPN, a PE, say PE1, receives a frame over an AC, 519 and forwards it over a PW to another PE, say PE2. PE2 then forwards 520 the frame out on another AC. 522 The case in which PE1 and PE2 are the same device is an important 523 case to handle correctly, in order to provide the L2VPN service 524 properly. However, as this case does not require any protocol, we do 525 not further address it in this document. 527 When PE1 receives a frame on a particular AC, it must determine the 528 PW on which the frame must be forwarded. In general, this is done by 529 considering: 531 - the incoming AC, 533 - possibly the contents of the frame's Layer2 header, and 535 - possibly some forwarding information which may be statically or 536 dynamically maintained. 538 If dynamic or static forwarding information is considered, the 539 information is specific to a particular L2VPN instance (i.e., to a 540 particular VPN). 542 Similarly, when PE2 receives a frame on a particular PW, it must 543 determine the AC on which the frame must be forwarded. This is done 544 by considering: 546 - the incoming PW, 548 - possibly the contents of the frame's Layer2 header, and 550 - possibly some forwarding information which may be statically or 551 dynamically maintained. 553 If dynamic or static forwarding information is considered, the 554 information is specific to a particular L2VPN instance (i.e. to a 555 particular VPN). 557 The procedures used to make the forwarding decision are known as a 558 "forwarder". We may think of a PW as being "bound", at each of its 559 endpoints, to a forwarder. The forwarder in turn "binds" the PWs to 560 ACs. Different types of L2VPN have different types of forwarders. 562 For instance, a forwarder may bind a single AC to a single PW, 563 ignoring all frame contents and using no other forwarding 564 information. Or a forwarder may bind an AC to a set of PWs and ACs, 565 moving individual frames from AC to PW, from a PW to an AC or from AC 566 to AC by comparing information from the frame's Layer2 header to 567 information in a forwarding database. This is discussed in more 568 detail below, as we consider the different L2VPN types. 570 3.2.4. Tunnels 572 A PW is carried in a "tunnel" from PE1 to PE2. We assume that an 573 arbitrary number of PWs may be carried in a single tunnel; the only 574 requirement is that the PWs all terminate at PE2. 576 We do not even require that all the PWs in the tunnel originate at 577 PE1; the tunnels may be multipoint-to-point tunnels. Nor do we 578 require that all PWs between the same pair of PEs travel in the same 579 tunnel. All we require is that when a frame traveling through such a 580 tunnel arrives at PE2, PE2 will be able to associate it with a 581 particular PW. 583 (While one can imagine tunneling techniques that only allow one PW 584 per tunnel, they have evident scalability problems, and we do not 585 consider them further.) 587 There are a variety of different tunneling technologies which may be 588 used for the PE-PE tunnels. All that is really required is that the 589 tunneling technologies allow the proper demultiplexing of the 590 contained PWs. The tunnels might be MPLS LSPs, L2TP tunnels, IPsec 591 tunnels, MPLS- in-IP tunnels, etc. Generally the tunneling 592 technology will require the use of an encapsulation that contains a 593 demultiplexor field, where the demultiplexor field is used to 594 identify a particular PW. Procedures for setting up and maintaining 595 the tunnels are not within the scope of this framework. (But see 596 section 3.2.6, "Pseudowire Signaling".) 598 If there are multiple tunnels from PE1 to PE2, it may be desirable to 599 assign a particular PE1-PE2 PW to a particular tunnel based on some 600 particular characteristics of the PW and/or the tunnel. For example, 601 perhaps different tunnels are associated with different QoS 602 characteristics, and different PWs require different QoS. Procedures 603 for specifying how to assign PWs to tunnels are out of scope of the 604 current framework. 606 Though point-to-point PWs are bidirectional, the tunnels in which 607 they travel need not be either bidirectional or point-to-point. For 608 example, a point-to-point PW may travel within a unidirectional 609 multipoint-to- point MPLS LSP. 611 3.2.5. Encapsulation 613 As L2VPN packets are carried in pseudowires, standard pseudowire 614 encapsulation formats and techniques (as specified by the IETF's PWE3 615 WG) should be used wherever applicable. 617 Generally the PW encapsulations will themselves be encapsulated 618 within a tunnel encapsulation, as determined by the specification of 619 the tunneling protocol. 621 It may be necessary to define additional PW encapsulations to cover 622 areas that are of importance for L2VPN, but may not be within the 623 scope of PWE3. Heterogeneous transport may be an instance of this. 625 3.2.6. Pseudowire Signaling 627 Procedures for setting up and maintaining the PWs themselves are 628 within the scope of this framework. This includes procedures for 629 distributing demultiplexor field values, even though the 630 demultiplexor field, strictly speaking, belongs to the tunneling 631 protocol rather than to the PW. 633 The signaling for a point-to-point pseudowire must perform the 634 following functions: 636 - Distribution of the demultiplexor. 638 Since many PWs may be carried in a single tunnel, the tunneling 639 protocol must assign a demultiplexor value to each PW. These 640 demultiplexors must be unique with respect to a given tunnel (or 641 with some tunneling technologies, unique at the egress PE). 642 Generally, the PE which is the egress of the tunnel will select 643 the demultiplexor values, and will distribute them to the PE(s) 644 which is (are) the ingress(es) of the tunnel. This is the 645 essential part of the PW setup procedure. 647 Note that, as is usually the case in tunneling architectures, the 648 demultiplexor field belongs to the tunneling protocol, not to the 649 protocol being tunneled. For this reason, the PW setup protocols 650 may be extensions of the control protocols for setting up the 651 tunnels. 653 - Selection of the Forwarder at the Remote PE. 655 The signaling protocol must contain enough information to enable 656 the remote PE to select the proper forwarder to which the PW is 657 to be bound. We can call this information the "Remote Forwarder 658 Selector". The information that is required will depend on the 659 type of L2VPN being provided and on the provisioning model (see 660 sections 3.3.1 and 3.4.2) being used. The Remote Forwarder 661 Selector may uniquely identify a particular Forwarder, or it may 662 identify an attribute of Forwarders. In the latter case, it would 663 select whichever Forwarder has been provisioned with that 664 attribute. 666 - Support pseudowire emulations. 668 To the extent that a particular PW must emulate the signaling of 669 a particular Layer2 technology, the PW signaling must provide the 670 necessary functions. 672 - Distribution of State Changes. 674 Changes in the state of an AC may need to be reflected in changes 675 to the state of the PW to which the AC is bound, and vice versa. 676 The specification as to which changes need to be reflected in 677 what way would generally be within the province of the PWE3 WG. 679 - Establish pseudowire characteristics. 681 To the extent that one or more characteristics of a PW must be 682 known to and/or agreed upon by both endpoints, the signaling must 683 allow for the necessary interaction. 685 As specified above, signaling for point-to-point PWs must pass enough 686 information to allow a remote PE to properly bind a PW to a 687 Forwarder, and to associate a particular demultiplexor value with 688 that PW. Once the two PEs have done the proper PW/Forwarder bindings, 689 and have agreed on the demultiplexor values, the PW may be considered 690 to have been set up. If it is necessary to negotiate further 691 characteristics or parameters of a particular PW, or to passing 692 status information for a particular PW, the PW may be identified by 693 the demultiplexor value. 695 Signaling procedures for point-to-point pseudowires are most commonly 696 point-to-point procedures that are executed by the two PW endpoints. 697 There are however proposals to use point-to-multipoint signaling for 698 setting up point-to-point pseudowires, so this is included in the 699 framework. When PWs are themselves point-to-multipoint, it is also 700 possible to use either point-to-point signaling or point-to- 701 multipoint signaling to set them up. This is discussed in the 702 remainder of this section. 704 3.2.6.1. Point-to-Point Signaling 706 There are several ways to do the necessary point-to-point signaling. 707 Among them are: 709 - LDP 711 LDP extensions can be defined for pseudowire signaling. See for 712 example [MARTINI-SIGNALING], [ROSEN-L2-SIGNALING]. This form of 713 signaling can be used for pseudowires which are to be carried in 714 MPLS "tunnels", or in MPLS-in-something-else tunnels (e.g., 715 [MPLS-IP], [MPLS-GRE]). 717 - L2TP 719 L2TP [L2TP-BASE] can be used for pseudowire signaling, resulting 720 in pseudowires that are carried as "sessions" within L2TP 721 tunnels. Pseudowire-specific extensions to L2TP may also be 722 needed, e.g., see [L2TP-FR]. 724 Other methods may be possible as well. 726 It is possible to have one control connection between a pair of PEs, 727 which is used to control many PWs. 729 The use of point-to-point signaling for setting up point-to-point PWs 730 is straightforward. Multipoint-to-point PWs can also be set up by 731 point- to-point signaling, as the remote PEs do not necessarily need 732 to know whether the PWs are multipoint-to-point or point-to-point. 733 In some signaling procedures, the same demultiplexor value may be 734 assigned to all the remote PEs. 736 3.2.6.2. Point-to-Multipoint Signaling 738 Consider the following situation: 740 - It is necessary to set up a set of PWs, all of which have the 741 same characteristics. 743 - It is not necessary to use the PW signaling protocol to pass PW 744 state changes. 746 - For each PW in the set, the same value of the Remote Forwarder 747 Selector can be used. 749 Call these the "Environmental Conditions". 751 Suppose also that there is some mechanism by which, given a range of 752 demultiplexor values, each of a set of PEs can make a unique and 753 deterministic selection of a single value from within that range. 754 Call this the "Demultiplexor Condition". Alternatively, suppose that 755 one is trying to set up a multipoint-to-point PW rather than a 756 point-to-point PW. Call this the "Multipoint Condition". 758 If: 760 - The Environmental Conditions hold, and 762 - Either 764 * the Demultiplexor Condition holds, or 766 * the Multipoint Condition holds, 768 then for a given set of PWs which terminate at egress PE1, the 769 information which PE1 needs to send to the ingress PE(s) of each 770 pseudowire in the set is exactly the same. All the ingress PE(s) 771 receive the same Forwarder Selector value. They all receive the same 772 set of PW parameters (if any). And either they all receive the same 773 demultiplexor value (if the PW is multipoint-to-point) or they all 774 receive a range of demultiplexor values from which each can choose a 775 unique demultiplexor value for itself. 777 Rather than connecting to each ingress PE and replicating the same 778 information, it may make sense either to multicast the information, 779 or to send the information once to a "reflector", which will then 780 take responsibility for distributing the information to the other 781 PEs. 783 We refer to this sort of technique as "point-to-multipoint" 784 signaling. It would, for example, be possible to use BGP to do the 785 signaling, with the PEs being BGP peers not of each other, but of one 786 or more BGP route reflectors. 788 Such a scheme, based Multi-protocol Extensions to BGP, is proposed in 789 [KOMPELLA-L2VPN]. 791 3.2.6.3. Inter-AS Considerations 793 Pseudowires may need to run from a PE in one Service Provider's 794 network to a PE in another Service Provider's network. This means 795 that the signaling to set up the PEs must be able to cross network 796 boundaries. All known proposals for signaling are able to do this. It 797 is especially advisable to use some form of authentication between 798 the two PW endpoints in this case. 800 3.2.7. Service Quality 802 Service Quality refers to the ability for the network to deliver a 803 Service level Specification (SLS) for service attributes such as 804 protection, security and Quality of Service (QoS). The service 805 quality provided depends on the subscriber's requirements, and can be 806 characterized by a number of performance metrics. 808 The necessary Service Quality must be provided on the ACs as well as 809 on the PWs. Mechanisms for providing Service Quality on the PWs may 810 be PW- specific or tunnel-specific; in the latter case, the 811 assignment of a PW to a tunnel may depend on the Service Quality. 813 3.2.7.1. Quality of Service (QoS) 815 QoS describes the queuing behavior applied to a particular "flow", in 816 order to achieve particular goals of precedence, throughput, delay, 817 jitter, etc. 819 Based on the customer Service Level Agreement (SLA), traffic from 820 customer can be prioritized, policed and shaped for QoS requirements. 821 The queuing and forwarding policies can preserve the packet order and 822 QoS parameters of customer traffic. The class of services can be 823 mapped from information in the customer frames, or it can be 824 independent of the frame content. 826 QoS functions can be listed as follows: 828 - Customer Traffic Prioritization: L2VPN services could be best 829 effort or QoS guaranteed. Traffic from one customer might need to 830 be prioritized over others when sharing same network resources. 831 This requires capabilities within the L2VPN solution to classify 832 and mark priority to QoS guaranteed customer traffic. 834 - Proper queuing behavior would be needed at the egress AC, and 835 possibly within the backbone network as well. If queuing behavior 836 must be controlled within the backbone network, the control might 837 be based on CoS information in the MPLS or IP header, or it might 838 be achieved by nesting particular tunnels within particular 839 traffic engineering tunnels. 841 - Policing: This ensures that a user of L2VPN services uses network 842 resources within the limits of the agreed SLA. Any excess L2VPN 843 traffic can be rejected or handled differently based on provider 844 policy. 846 - Policing would generally be applied at the ingress AC. 848 - Shaping: Under some cases the random nature of L2VPN traffic 849 might lead to sub-optimal utilization of network resources. 850 Through queuing and forwarding mechanisms the traffic can be 851 shaped without altering the packet order. 853 - Shaping would generally be applied at the ingress AC. 855 3.2.7.2. Resiliency 857 Resiliency describes the ability of the L2VPN infrastructure to 858 protect a flow from network outage, so that service remains available 859 in the presence of failures. 861 L2VPN, like any other service, is subject to failures such as link, 862 trunk and node failures, both in the SP's core network infrastructure 863 and on the ACs. 865 It is desirable that the failure be detected "immediately" and 866 protection mechanisms allow fast restoration times to make L2VPN 867 service almost transparent to these failures to the extent possible, 868 based on the level of resiliency. Restoration should take place 869 before the CEs can react to the failure. Essential aspects of 870 providing resiliency are: 872 - Link/Node failure detection: Mechanisms within the L2VPN service 873 should allow for link or node failures that impact the Service, 874 and should be detected immediately. 876 - Resiliency policy: The way in which a detected failure is handled 877 will depend upon the restoration policy of the SLA associated 878 with the L2VPN service specification. It may need to be handled 879 immediately, or it may need to be handled only if no other 880 critical failure needs protection resources, or it may be 881 completely ignored if it is within the bounds of the "acceptable 882 downtime" allowed by the L2VPN service. 884 - Restoration Mechanisms: The L2VPN solutions could allow for 885 physical level protection, logical level protection or both. For 886 example, by connecting customers over redundant and physically 887 separate ACs to different provider customer-facing devices, one 888 AC can be maintained as active while the other could be marked as 889 a backup; upon the failure detection across the primary AC, the 890 backup could become active. 892 To a great extent, resiliency is a matter of having appropriate 893 failure and recovery mechanisms in the network core, including 894 "ordinary" adaptive routing as well as "fast reroute" [???] 895 capabilities. The ability to support redundant ACs between CEs and 896 PEs also plays a role. 898 3.2.8. Management 900 An L2VPN solution can provide mechanisms to manage and monitor 901 different L2VPN components. From a Service Level Agreement (SLA) 902 perspective, L2VPN solutions could allow monitoring of L2VPN service 903 characteristics and offer mechanisms used by Service Providers to 904 report such monitored statistical data. Trouble-shooting and 905 verification of operational and maintenance activities of L2VPN 906 services are essential requirements for Service Providers. 908 3.3. VPWS 910 A VPWS is an L2VPN service in which each forwarder binds exactly one 911 AC to exactly one PW. Frames received on the AC are transmitted on 912 the PW; frames received on the PW are transmitted on the AC. The 913 content of a frame's Layer2 header plays no role in the forwarding 914 decision, except insofar as the Layer2 header contents are used to 915 associate the frame with a particular AC (as, e.g., the DLCI field of 916 a Frame Relay frame identifies the AC). 918 A particular combination of forms a "virtual circuit" 919 between two CE devices. 921 A particular VPN (VPWS instance) may be thought of as a collection of 922 such virtual circuits, or as an "overlay" of PWs on the MPLS or IP 923 backbone. This creates an overlay topology that is in effect the 924 "virtual backbone" of a particular VPN. 926 Whether two virtual circuits are said to belong to the same VPN or 927 not is an administrative matter, based on the agreements between the 928 SPs and their customers. This may impact the provisioning model 929 (discussed below). It may also affect how particular PWs are 930 assigned to tunnels, the way QoS is assigned to particular ACs and 931 PWs, etc. 933 Note that VPWS makes use of point-to-point PWs exclusively. 935 VPWS solutions are found e.g. in [DIRLDP], [KOMPELLA-L2VPN] and 936 [ROSEN- L2-SIGNALING]. 938 3.3.1. Provisioning and Auto-Discovery 940 Provisioning a VPWS is a matter of: 942 1. Provisioning the ACs 944 2. Providing the PEs with the necessary information to enable them 945 to set up PWs between ACs to result in the desired overlay 946 topology. 948 3. Configuring the PWs with any necessary characteristics 950 3.3.1.1. Attachment Circuit Provisioning 952 In many cases, the ACs must be individually provisioned on the PE 953 and/or CE. This will certainly be the case if the CE/PE attachment 954 technology is a switched network, such as ATM or FR, and the VCs are 955 PVCs rather than SVCs. It is also the case whenever the individual 956 Attachment Circuits need to be given specific parameters (e.g., QoS 957 parameters, guaranteed bandwidth parameters) that differ from circuit 958 to circuit. 960 There are also cases in which ACs might not have to be individually 961 provisioned. E.g., if an AC is just an MPLS LSP running between a CE 962 and a PE, it could be set up as the RESULT of a PW being set up, 963 rather than having to be provisioned BEFORE the PW can be set up. The 964 same may apply whenever the AC is a Switched Virtual Circuit of any 965 sort, though in this case, various policy controls might need to be 966 provisioned, e.g., limiting the number of ACs that can be set up 967 between a given CE and a given PE. 969 Issues such as whether the Attachment Circuits need to be 970 individually provisioned or not, whether they are Switched VCs or 971 Permanent VCs, and what sorts of policy controls may be applied, are 972 implementation and deployment issues, and are considered to be out of 973 scope of this framework. 975 3.3.1.2. PW Provisioning for Arbitrary Overlay Topologies 977 In order to support arbitrary overlay topologies, it is necessary to 978 allow the provisioning of individual PWs. In this model, when a PW 979 is provisioned on a PE device, it is locally bound to a specific AC. 980 It is also provisioned with information that identifies a specific AC 981 at a remote PE. 983 There are basically two variations of this provisioning model: 985 - Two-sided provisioning 987 With two-sided provisioning, each PE that is at the end of a PW 988 is provisioned with the following information: 990 * Identifier of the Local AC to which the PW is to be bound 992 * PW type and parameters 994 * IP address of the remote PE (i.e., the PE which is to be at 995 the remote end of the PW) 997 * Identifier which is meaningful to the remote PE, and which 998 can be passed in the PW signaling protocol to enable the 999 remote PE to bind the PW to the proper AC. This can be an 1000 identifier of the pseudowire (as in [MARTINI-SIGNALING]), or 1001 an identifier of the remote AC (as in [ROSEN-L2-SIGNALING]). 1002 If a PW identifier is used, it must be unique at each of the 1003 two PEs. If an AC identifier is used, it need only be unique 1004 at the remote PE. 1006 This identifier is then used as the Remote Forwarder Selector 1007 when signaling is done (see 3.2.6.1). 1009 - Single-sided Provisioning 1011 With single sided provisioning, a PE at one end of a PW is 1012 provisioned with the following information: 1014 * Identifier of the Local AC to which the PW is to be bound 1015 * PW type and parameters 1017 * Globally unique identifier of remote AC 1019 This identifier is then used as the Forwarder Selector when 1020 signaling is done (see section 3.2.6.1). 1022 In this provisioning model, the IP address of the remote PE is 1023 not provisioned. Rather, the assumption is that an auto- 1024 discovery scheme will be used to map the globally unique 1025 identifier to the IP address of the remote PE, along with an 1026 identifier (perhaps unique only at the latter PE) for an AC at 1027 that PE. The PW signaling protocol can then make a connection to 1028 the remote PE, passing the AC identifier, so that the remote PE 1029 binds the PW to the proper AC. (See, for example, [ROSEN-L2- 1030 SIGNALING].) 1032 This scheme requires provisioning of the PW at only one PE, but 1033 does not eliminate the need (if there is a need) to provision the 1034 ACs at both PEs. 1036 These provisioning models fit well with the use of point-to-point 1037 signaling. When each PW is individually provisioned, as the 1038 conditions necessary for the use of point-to-multipoint signaling do 1039 not hold. 1041 3.3.1.3. Colored Pools PW Provisioning Model 1043 Suppose that at each PE, sets of ACs are gathered together into 1044 "pools", and that each such pool is assigned a "color". (For 1045 example, a pool might contain all and only the ACs from this PE to a 1046 particular CE.) Now suppose we impose the following rule: whenever 1047 PE1 and PE2 have a pool of the same color, there will be a PW between 1048 PE1 and PE2 which is bound at PE1 to an arbitrarily chosen AC from 1049 that pool, and at PE2 to an arbitrarily chosen AC from that pool. 1050 (We do not rule out the case where a single PE has multiple pools of 1051 a given color.) 1053 For example, each pool in a particular PE might represent a 1054 particular CE device, with the ACs in the pool being the ACs 1055 connecting that CE to that PE. The color might be a VPN-id. 1056 Application of this provisioning model would then lead to a full CE- 1057 to-CE mesh within the VPN, where every CE in the VPN has a virtual 1058 circuit to every other CE within the VPN. 1060 More specifically, to provision VPWS according to this model, one 1061 provisions a set of pools, and configures each pool with the 1062 following information: 1064 - The set of ACs that belong to the pool (with no AC belonging to 1065 more than one pool) 1067 - The color 1069 - A pool identifier that is unique at least relative to the color. 1071 An auto-discovery procedure is then used to map each color into a 1072 list of ordered pairs . The 1073 occurrence of a pair on this list means that the PE at IP 1074 address X has a pool with pool id Y which is of the specified 1075 color. 1077 This information can be used to support several different 1078 signaling techniques. One possible technique proceeds as 1079 follows: 1081 - A PE finds that it has a pool of color C. 1083 - Using auto-discovery, it obtains the set of ordered pairs 1084 for color C. 1086 - For each such pair , it: 1088 * removes an AC from the pool 1090 * binds the AC to a particular PW 1092 * signals PE X via point-to-point signaling that the PW is to 1093 be bound to an AC from pool Y. 1094 This sort of technique is discussed in [ROSEN-L2-SIGNALING]. 1096 Another possible signaling technique is the following: 1098 - A PE finds that it has a pool of color C, containing n ACs. 1100 - It binds each AC to a PW, creating a set of PWs. This set of PWs 1101 is then organized into a sequence. (For instance, each PW may be 1102 associated with a demultiplexor field value, and the PWs may then 1103 be sequenced according to the numerical value of their respective 1104 demultiplexors.) 1106 - Using auto-discovery, it obtains the list of PE routers that have 1107 one or more pools of color C. 1109 - It signals each such PE router, specifying the sequence Q of PWs. 1111 - If PE X receives such a signal, and PE X has a pool Y of the 1112 specified color, it: 1114 * removes an AC from the pool 1116 * binds the AC to the PW which is the "Yth" PW in the sequence 1117 Q. 1119 This presumes, of course, that the pool identifiers are or can be 1120 uniquely mapped into small ordinal numbers; assigning the pool 1121 identifiers in this way becomes a requirement of the provisioning 1122 system. 1124 Note that since this technique signals the same information to all 1125 the remote PEs, it can be supported via point-to-multipoint 1126 signaling. This sort of scheme is discussed in [KOMPELLA-L2VPN]. 1128 This provisioning model can be applied as long as the following 1129 conditions hold: 1131 - There is no need to provision different characteristics for the 1132 different PWs, and 1134 - It makes no difference which pairs of ACs are bound together by 1135 PWs, as long as both ACs in the pair come from like-colored 1136 pools, and 1138 - It is possible to construct the desired overlay topology simply 1139 by assigning colors to the pools. (This is certainly simple if a 1140 full mesh is desired, or if a hub and spoke configuration is 1141 desired; creating arbitrary topologies is less simple, and 1142 perhaps not always possible.) 1144 3.3.2. Requirements on Auto-Discovery Procedures 1146 Some of the requirements for auto-discovery procedures can be deduced 1147 from the above. 1149 To support the single-sided provisioning model, auto-discovery must 1150 be able to map a globally unique identifier (of a PW or of an 1151 Attachment Circuit) to an IP address of a PE. 1153 To support the colored pools provisioning model, auto-discovery must 1154 enable a PE to determine the set of other PEs that contain pools of 1155 the same color. 1157 Examples of suitable auto-discovery procedures can be found in 1158 Examples of suitable auto-discovery procedures can be found in 1159 [KOMPELLA-L2VPN], [BGP-AUTO] and [ROSEN-L2-SIGNALING], and [DNS-LDP- 1160 VPLS]. 1162 These requirements enable the auto-discovery scheme to provide the 1163 information, which the PEs need to set up the PWs. 1165 There are additional requirements on the auto-discovery procedures 1166 that cannot simply be deduced from the provisioning model: 1168 - Particular signaling schemes may require additional information 1169 before they can proceed, and hence may impose additional 1170 requirements on the auto-discovery procedures. 1172 - A given Service Provider may support several different types of 1173 signaling procedures, and thus the PEs may need to learn, via 1174 auto- discovery, which signaling procedures to use. 1176 - Changes in the configuration of a PE should be reflected by the 1177 auto-discovery procedures, within a timely manner, and without 1178 the need to explicitly reconfigure any other PE. 1180 - The auto-configuration procedures must work across service 1181 provider boundaries. This rules out, e.g., the use of schemes 1182 that piggyback the auto-discovery information on the backbone's 1183 IGP. 1185 3.3.3. Heterogeneous Pseudowires 1187 Under certain circumstances, it may be desirable to have a PW that 1188 binds two ACs that use different technologies (e.g., one is ATM, one 1189 is Ethernet). There are a number of different ways, depending on the 1190 AC types, in which this can be done. For example: 1192 - If one AC is ATM and one is FR, then standard ATM/FR Network 1193 Interworking can be used. In this case, the PW might be signaled 1194 for ATM, with the Interworking function occurring between the PW 1195 and the FR AC. 1197 - A common encapsulation can be used on both ACs, e.g., if one AC 1198 is Ethernet and one is FR, an "Ethernet over FR" encapsulation 1199 can be used on the latter. In this case, the PW could be 1200 signaled for Ethernet, with the processing of the Ethernet over 1201 FR encapsulation being local to the PE with the FR AC. 1203 - If it is known that the two ACs attach to IP routers or hosts, 1204 and carry only IP traffic, then one could use a PW which carries 1205 the IP packets, and the respective Layer2 encapsulations would be 1206 local matters for the two PEs. However, if one of the ACs is a 1207 LAN and one is a point-to-point link, care would have to be taken 1208 to ensure that such procedures as ARP and Inverse ARP are 1209 properly handled; this might require some signaling, and some 1210 proxy functions. Further, if the CEs use a routing algorithm that 1211 has different procedures for LAN interfaces than for point-to- 1212 point interfaces, additional mechanisms may be required to ensure 1213 proper interworking. These issues are discussed in [SHAH-INTER]. 1215 3.4. VPLS Emulated LANs 1217 A VPLS is an L2VPN service in which: 1219 - the ACs attach CE devices to PE bridge modules, 1221 - each PE bridge module is attached via an "emulated LAN interface" 1222 to an "emulated LAN" 1224 This is shown in Figure 3. 1226 In this section, we examine the functional decomposition of the VPLS 1227 Emulated LAN. An Emulated LAN's ACs are the "emulated LAN 1228 interfaces" attaching PE bridge modules to the "VPLS Forwarder" 1229 modules (see Figure 3). The payload on the ACs consists of ethernet 1230 frames, with or without VLAN headers. 1232 A given VPLS Forwarder in a given PE will have multiple ACs only if 1233 there are multiple bridge modules in that PE which attach to that 1234 Forwarder. This scenario is included in the Framework, though 1235 discussion of its utility is out of scope. 1237 The set of VPLS Forwarders within a single VPLS are connected via 1238 PWs. Two VPLS Forwarders will have a PW between them only if those 1239 two Forwarders are part of the same VPLS. (There may be a further 1240 restriction that two VPLS Forwarders have a PW between them only if 1241 those two Forwarders belong to the same VLAN in the same VPN.) A 1242 particular set of interconnected VPLS Forwarders is what constitutes 1243 a VPLS Emulated LAN. 1245 On a real LAN, any frame transmitted by one entity is received by all 1246 the others. A VPLS Emulated LAN, however, behaves somewhat 1247 differently. When a VPLS Forwarder receives a unicast frame over one 1248 of its Emulated LAN interfaces, the Forwarder does not necessarily 1249 send the frame to all the other Forwarders on that Emulated LAN. A 1250 unicast frame need be sent to only one other Forwarder in order to be 1251 properly delivered to its destination MAC address. If the 1252 transmitting Forwarder knows which other Forwarder needs to receive a 1253 particular unicast frame, it will send the frame to just that one 1254 Forwarder. This forwarding optimization is an important part of any 1255 attempt to provide a VPLS service over a wide-area or metropolitan 1256 area network. 1258 In effect then each Forwarder behaves as a "Virtual Switch Instance" 1259 (VSI), maintaining a forwarding table in which maps MAC addresses to 1260 PWs. The VSI is populated in much the same was as a standard bridge 1261 populates its forwarding table. The VPLS Forwarders do MAC SA 1262 learning on frames received on PWs from other Forwarders, and must 1263 also do the related set of procedures, such as the aging out of 1264 address entries. Frames with unknown DAs or multicast DAs must be 1265 "broadcast" by one Forwarder to all the others (on the same emulated 1266 LAN). There are however a few important differences between the VPLS 1267 Forwarder VSI and the standard bridge forwarding function: 1269 - A VPLS Forwarder never learns the MAC SAs of frames which it 1270 receives on its ACs, it only learns the MAC SAs of frames which 1271 are received on PWs from other VPLS Forwarders; 1273 - The VPLS Forwarders of a particular emulated LAN do not 1274 participate in a spanning tree protocol with each other. A 1275 "split horizon" technique is used to prevent forwarding loops. 1277 These points are discussed further in the next section. 1279 Note that the PE bridge modules which are on a given Emulated LAN may 1280 or may not run spanning tree protocol with each other over the 1281 Emulated LAN; whether they do so or not is outside the scope of the 1282 VPLS specifications. The PE bridge modules will do MAC address 1283 learning on the ACs. The PE bridge modules also do MAC address 1284 learning on the Emulated LAN interfaces, but do not do MAC address 1285 learning on the PWs, as the PWs are "hidden" behind the Emulated LAN 1286 interface. Conceptually, the PE bridge module's forwarding table and 1287 the VPLS Forwarder's VSI are distinct entities. (Of course, 1288 particular implementations might combine these into a single table, 1289 but that is beyond the scope of this document.) 1291 A further issue does arise in the case where the PE bridges do run 1292 bridge control protocols with each other over the Emulated LAN. 1294 Bridge control protocols are generally designed to run in over a real 1295 LAN, and may presume, for their proper functioning, certain 1296 characteristics of the LAN, such as low latency and sequential 1297 delivery. If the Emulated LAN does not provide these 1298 characteristics, the control protocols may not perform as expected 1299 unless special mechanisms are provided for carrying the control 1300 frames. 1302 It should be noted that changes in the spanning tree (if any) of a 1303 customer network, or in the spanning tree (if any) of the PE bridges, 1304 may cause certain MAC addresses to change their location from one PE 1305 to another. These changes may not be visible to the VPLS Forwarders, 1306 which means that those MAC addresses might become unreachable until 1307 they are aged out of the first PE's VSI. If this is not acceptable, 1308 some mechanism for communicating such changes to the VPLS Forwarders 1309 must be provided. 1311 VPLS solutions are found e.g. in [DNS-LDP-VPLS], [LASSERRE-VKOMPELLA- 1312 VPLS] and [KOMPELLA-VPLS]. 1314 3.4.1. VPLS Overlay Topologies and Forwarding 1316 Within a single VPLS, the VPLS Forwarders are interconnected by PWs. 1317 The set of PWs thus forms an "overlay topology". 1319 The VPLS Forwarder VSIs are populated by means of MAC address 1320 learning. That is, the VSI keeps track of which MAC SAs have been 1321 received over which PWs. The presumption of course is that if a 1322 particular MAC address appears as the SA of a frame received over a 1323 particular PW, then frames which carry that MAC address in the DA 1324 field should be sent to the VSI which is at the remote end of the PW. 1325 In order for this presumption to be true, there must be a unique VSI 1326 at the remote end of the PW, which means that VSIs cannot be 1327 interconnected by means of multipoint-to-point PWs. The PWs are 1328 necessarily either point-to-point or, possibly, point-to-multipoint. 1330 MAC learning over a point-to-point PW is done via the standard 1331 techniques as specified by IEEE, where the PW is treated by the VPLS 1332 Forwarder as a "bridge port". Of course, if a MAC address is learned 1333 from a point-to-multipoint PW, the VSI must indicate that packets to 1334 that address are to be sent over a point-to-point PW which leads to 1335 the root of that point-to-multipoint PW. 1337 The VSI forwarding decisions must be coordinated so that loop-free 1338 forwarding over the overlay topology is ensured. 1340 There are several possible types of overlay topologies: 1342 - Full mesh 1344 In a full mesh, every VSI in a given VPLS has exactly one point- 1345 to-point PW to every other VSI in that same VPLS. 1347 In this topology, loop free forwarding of frames is ensured by 1348 the following rule: if a VSI receives a frame, over a PW, from 1349 another VSI, it MUST NOT forward that frame over ANY other PW to 1350 any other VSI. This ensures that once a frame traverses the 1351 Emulated LAN, it must be sent off the Emulated LAN. 1353 If a VSI receives, on one of its Emulated LAN interfaces, a 1354 unicast frame with a known DA, the frame is sent on exactly one 1355 point-to-point PW. 1357 If a VSI receives, on one of its Emulated LAN interfaces, a 1358 multicast frame or a unicast frame with unknown DA, it send a 1359 copy of the frame to each other VSI in the same Emulated LAN. 1360 This can be done by replicating the frame and sending a copy over 1361 each point-to-point PW. Alternatively, the full mesh of point- 1362 to-point PWs may be augmented with point-to-multipoint PWs, where 1363 each VSI in a VPLS is the transmitter on a single point-to- 1364 multipoint PW, and the receivers on that PW are all the other 1365 VSIs in that VPLS. 1367 - Tree Structured 1369 In a tree structured topology, every VSI in a particular VPLS is 1370 provisioned to be at a particular level in the tree. A given VSI 1371 has at most one pseudowire leading to a higher level. The root of 1372 the tree is considered to be the highest level. 1374 In this topology, loop free forwarding of frames is ensured by 1375 the following rule: if a frame is received over a pseudowire from 1376 a higher level, it may not be sent over a pseudowire that leads 1377 to a higher level. 1379 - Tree with Meshed Highest Level 1381 In this variant of the tree-structured topology, there may be 1382 more than one VSI at the highest level, but the set of VSIs which 1383 are at the highest level must be fully meshed. To ensure loop 1384 free forwarding, we need to impose the rule that a frame can be 1385 sent on a pseudowire to the same or higher level only if it 1386 arrived over a pseudowire from a lower level, and frames arriving 1387 over PWs from the same level cannot be sent on PWs to the same 1388 level. 1390 Other overlay topologies are also possible, e.g., an arbitrary 1391 partial mesh of PWs among the VSIs of a VPLS. Loop-freedom could 1392 then be assured by, for example, running spanning tree on the 1393 overlay. These topologies are not further considered in this 1394 framework. 1396 Note that loop freedom in the overlay topology does not necessarily 1397 ensure loop freedom in the overall customer LAN that contains the 1398 VPLS. It does not even ensure loop freedom among the PE bridge 1399 modules. It ensures only that when a frame is sent on the Emulated 1400 LAN, the frame will not loop endlessly before (or instead of) leaving 1401 the Emulated LAN. 1403 Improper configuration of the customer LAN or PE bridge modules may 1404 cause frames to loop, and frames that fall into such loops may 1405 transit the overlay topology multiple times. Procedures that enable 1406 the PE to detect and/or prevent such loops may be advisable. 1408 3.4.2. Provisioning and Auto-Discovery 1410 Each VPLS must be assigned a globally unique identifier. This can be 1411 thought of as a VPN-id. 1413 The ACs attaching the CEs to the PEs must be provisioned on both the 1414 PEs and the CEs. A VSI for that VPLS must be provisioned on the PE, 1415 and the local ACs of that VPLS must be associated with that VSI. The 1416 VSI must be provisioned with the identifier of the VPLS to which it 1417 belongs. 1419 An auto-discovery scheme may be used by a PE to map a VPLS identifier 1420 into the set of remote PEs that have VSIs in that VPLS. Once this 1421 set is determined, the PE can use pseudowire signaling to set up a PW 1422 to each of those VSIs. The VPLS identifier would serve as the 1423 signaling protocol's Forwarder Selector. This would result in a full 1424 mesh of PWs among the VSIs in a particular VPLS. 1426 If a single VPLS contains multiple VLANs, then it may be desirable to 1427 limit connectivity so that two VSIs are connected only if they have a 1428 VLAN in common. 1430 In this case, each VSI would need to be provisioned with one or more 1431 VLAN ids, and the auto-discovery scheme would need to map a VPLS 1432 identifier into pairs of . 1434 If a fully meshed topology of VSIs is not desired, then each VSI 1435 needs to be provisioned with additional information specifying its 1436 placement in the topology. This information would also need to be 1437 provided by the auto-discovery scheme. 1439 Examples of suitable auto-discovery procedures can be found in 1440 [KOMPELLA-L2VPN], [BGP-AUTO] and [ROSEN-L2-SIGNALING], and [DNS-LDP- 1441 VPLS]. 1443 Alternatively, the single-sided provisioning method discussed in 1444 section 3.3.1.2 could be used. As this is more complicated, it would 1445 only be used if it were necessary to associate individual PWs with 1446 individual characteristics. For example, if different guaranteed 1447 bandwidths were needed between different pairs of sites within a 1448 VPLS, the PWs would have to be individually provisioned. 1450 3.4.3. Distributed PE 1452 Often when a VPLS type of service is provided, the CE devices attach 1453 to a provider-managed CPE device. This provider-managed CPE device 1454 may attach to CEs of multiple customers, especially if, e.g., there 1455 are multiple customers occupying the same building. However, this 1456 device is really part of the SP's network, hence may be considered to 1457 be a PE device. 1459 In some scenarios when a VPLS type of service is provided, the CE 1460 devices attach to a provider-managed intermediary device. This 1461 provider- managed device may attach to CEs of multiple customers. 1462 This may arise in a situation there multiple customers occupying the 1463 same building. This device is really part of the SP's network, and 1464 may for that reason be considered to be a PE device, however in the 1465 simplest case it is only performing aggregation and none of the 1466 function associated with a VPLS. 1468 Relative to the VPLS there are three different possibilities to 1469 allocate functions to a device in such a position in the provider 1470 network: 1472 - it can perform aggregation and pure Layer2 service only, in which 1473 case it does not really play the role of a PE device in a VPLS 1474 service. In this case the intermediary system must connect to 1475 devices that perform VPLS PE functionality; the intermediary 1476 device itself is not part of the VPLS architecture and has hence 1477 not been named in this architecture. 1479 - it can perform all the PE functions relevant for a VPLS, in such 1480 a case the device is called VPLS-PE, see [ANDERSSON-TERM]. This 1481 type of device will be connected to the core (P) routers. 1483 The PE functionality for a VPLS may be distributed between two 1484 devices, one "low-end" closer to the customer that performs e.g. the 1485 MAC-address learning and forwarding decisions, and one "high-end" 1486 that performs the control functions, e.g. establishing tunnels, PWs 1487 and VCs. We call the low-end device User-Facing PE (U-PE) and the 1488 high-end device Network- Facing PE (N-PE). 1490 It is conceivable that the U-PE may be placed very close to the 1491 customer, e.g. in a building with more than one customer. In 1492 [KOMPELLA- DTLS], these are referred to as Multi-Tenant Units, but 1493 the resulting acronym is already used for something else. In 1494 [SAJASSI-VPLS] this type of device is called PE-CLE. [MOHAN-LPE] 1495 introduces another yet another naming scheme, the U-PE is called PE- 1496 Edge and the N-PE is called PE- Core. 1498 The N-PE, in [KOMPELLA-DTLS] called L2PE and in [SAJASSI-VPLS] called 1499 PE-POP, will presumably be placed on the SP's premises. 1501 The distributed case is potentially of interest for a number of 1502 possible reasons: 1504 - The N-PE may be a device that cannot easily implement the VSI 1505 functionality described above. E.g., perhaps the N-PE is a router 1506 which cannot perform the high speed MAC learning that is needed 1507 in order to implement a VSI forwarder. At the same time, the U-PE 1508 may need to be a low-cost device that also cannot implement the 1509 full set of VPLS functions. 1511 This leads one to investigate further if there are sensible ways 1512 to split the VPLS PE functionality between the U-PE and the N-PE. 1514 - Generally, in the L2VPN architecture, the PEs are expected to 1515 participate as peers in the backbone routing protocol. Since the 1516 number of U-PEs is potentially very large relative to the number 1517 of N-PEs, this may be undesirable, as a matter of scaling the 1518 backbone routing protocol. 1520 - The U-PE may be a relatively inexpensive device that is unable to 1521 participate in the full range of signaling and/or auto-discovery 1522 procedures that are needed in order to provide the VPLS service. 1524 The VPLS functionality can be distributed between U-PE and N-PE in a 1525 number of different ways, and a number of different proposals have 1526 been made ([KOMPELLA-DTLS], [MOHAN-LPE], [SAJASSI-VPLS]). They all 1527 presume that the U-PE will maintain a VSI forwarder, connected by PWs 1528 to the remote VSIs; the N-PE thus does not need to perform the VSI 1529 forwarding function. The proposals tend to differ with respect to the 1530 following questions: 1532 - Should the U-PEs perform full PW signaling to set up the PWs to 1533 remote VSIs? Or should the N-PEs do this signaling? 1535 Since the U-PEs need to be able to send packets on PWs to remote 1536 VSIs and receive packets on PWs from remote VSIs, if the PW 1537 signaling is done by the N-PE, there would have to be some form 1538 of "lightweight" (presumably) signaling between N-PE and U-PE 1539 that allows the PWs to be extended from N-PE to U-PE. 1541 - Should the U-PEs do their own auto-discovery, or should this be 1542 done by the N-PEs? In the latter case, the U-PEs may need to have 1543 some means of telling the N-PEs which VPLS's they are interested 1544 in, and the N-PEs must have some means of passing the results of 1545 the auto-discovery process to the U-PE. 1547 Whether it makes sense to split auto-discovery in this manner may 1548 depend on the particular auto-discovery protocol used. One would 1549 not expect the U-PE to participate in BGP auto-discovery, e.g., 1550 but perhaps they would be expected to participate in DNS auto- 1551 discovery. 1553 - If a U-PE does not participate in routing, but is redundantly 1554 connected to two different N-PEs, can the U-PE still make an 1555 intelligent choice of the best N-PE to use as the "next hop" for 1556 traffic destined to a particular remote VSI? If not, can this 1557 choice be made as the result of some other sort of interaction 1558 between N-PE and U-PE? Or does this choice need to be established 1559 by provisioning? 1561 - If a U-PE does not participate in routing, but does participate 1562 in full PW signaling, and if MPLS is being used, how can the the 1563 N-PE send the the U-PEs the labels that the U-PE needs to send 1564 traffic to its signaling peers. (If the U-PE did participate in 1565 routing, this would happen automatically.) 1567 - When a frame must be multicast, should the replication be done by 1568 the N-PE or the U-PE? 1570 These questions are not all independent; the way one answers some 1571 of them may influence the way one answers others. 1573 3.4.4. Scaling issues in VPLS deployment 1575 In general, the PSN supports a VPLS solution with a tunnel from each 1576 VPLS-PE every other VPLS-PE participating in the same VPLS instance. 1577 Strictly, VPLS-PE's with more than one VPLS instance in common only 1578 need one tunnel, but for resource allocation reasons it might be 1579 necessary to establish several tunnels. For each VPLS service on a 1580 given VPLS-PE it needs to establish one pseudowire to every other 1581 VPLS-PE participating in that VPLS service. In total n*(n-1) 1582 pseudowires must be setup between the VPLS-PE routers. In large scale 1583 deployment this obviously creates scaling problems. An solution 1584 addressing the scaling problems was addressed in an Internet Draft by 1585 S Khandekar et.al. called "Hierarchical Virtual Private LAN Service", 1586 this work has latter been included in [LASSERRE-VKOMPELLA-VPLS]. 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 [SHAH-INTER] for a discussion of 1600 this.) This allows the PE to be implemented on devices that are not 1601 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 [SHAH-INTER]. 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 1697 include 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 1721 not 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. References 1748 [RFC2026] 1749 Bradner, S. "The Internet Standards Process -- Revision 3", RFC 1750 2026, October 1996. 1752 [RFC2119] 1753 Bradner, S. "Key words for use in RFCs to Indicate Requirement 1754 Levels", RFC 2119, March 1997. 1756 [RFC3036] 1757 Andersson, L et.al. "LDP Speficification", RFC 3036, Jan 2001 1759 [ANDERSSON-METRICS] 1760 Andersson, L. "Parameters and related metrics to compare PPVPN 1761 Layer 2 solutions", draft-andersson-ppvpn-metrics-00.txt, Work 1762 in Progrss, Internet Draft, Feb 2002. 1764 [ANDERSSON-TERM] 1765 Andersson, L. and Madsen T. "VPN Terminology", draft-andersson- 1766 ppvpn-terminology-00.txt", Work in Progress, Internet Draft, 1767 Feb 2002. 1769 [BGP-AUTO] 1770 Ould-Brahim, H. et.al. "Using BGP as an Auto-Discovery 1771 Mechanism for Network-based VPNs", Ould-Brahim et al, draft- 1772 ietf-ppvpn-bgpvpn-auto-01.txt, Work in Progress, Internet 1773 Draft, Nov 2001 1775 [DIRLDP] 1776 Heinanen, J, "Directory/LDP Based Unidirectional Virtual 1777 Circuit VPNs" draft-heinanen-dirldp-uni-vc-vpns-01.txt, Work in 1778 Progress, Internet Draft, Nov 2001 1780 [DNS-LDP-VPLS] 1781 Heinanen, J, "DNS/LDP Based VPLS", draft-heinanen-dns-ldp-vpls- 1782 00.txt, Work in Progress, Internet Draft, Jan 2002 1784 [KOMPELLA-DTLS] 1785 Kompella, K et.al. "Decoupled Virtual private LAN Services", 1786 draft-kompella-ppvpn-dtls-01.txt, December 2001 1788 [KOMPELLA-L2VPN] 1789 Kompella, K. et.al. "Layer 2 VPNs Over Tunnels", draft- 1790 kompella-ppvpn-l2vpn-01.txt, Nov 2001 1792 [KOMPELLA-VPLS] 1793 Kompella, K. "Virtual Private LAN Service", draft-kompella- 1794 ppvpn-vpls-00.txt, Work in Progress, Internet Draft, Nov 2001 1796 [L2TP-BASE] 1797 Lau, J. "Layer Two Tunneling Protocol (Version 3) L2TPv3" 1798 draft-ietf-l2tpext-l2tp-base-02.txt", Work in Progress, 1799 Internet Draft, March 2002. 1801 [L2TP-FR] 1802 Townsley, W. M. et.al. ""Frame Relay Pseudowire Extensions for 1803 L2TP", draft-ietf-l2tpext-pwe3-fr-00.txt, Work in Progress, 1804 Internet Draft, Feb 2002. 1806 [L2VPN-ARCH] 1807 Rosen, E. et.al. "An Architecture for L2VPNs", draft-ietf- 1808 ppvpn-l2vpn-00.txt, Work in Progress, Internet Draft Jul 2001. 1810 [L2VPN-REQ] 1811 Augustyn, W. et.al "Requirements for Layer 2 Virtual Private 1812 Network Services (L2VPN)", draft-augustyn-ppvpn-l2vpn- 1813 requirements-00.txt, Work in Progress, Internet Draft, June 1814 2002. 1816 [L3VPN-FW] 1817 Callon, R. et.al. "A Framework for Layer 3 Provider Provisioned 1818 Virtual Private Networks", draft-ietf-ppvpn-framework-05.txt, 1819 Work in Progress, Internet Draft, April 2002 1821 [L3VPN-REQ] 1822 Carugi, M. et.al. "Service requirements for Layer 3 Provider 1823 Provisioned Virtual Private Networks" draft-ietf-ppvpn- 1824 requirements-04.txt, Work in Progress, Internet Draft, Feb 1825 2002. 1827 [LASSERRE-VKOMPELLA-VPLS] 1828 Lasserre, M. et.al. "Virtual Private LAN Services over MPLS", 1829 draft-lasserre-vkompella-ppvpn-vpls-01.txt, Work in progress, 1830 Internet Draft, Mar 2002. 1832 [MARTINI-SIGNALING] 1833 Martini, L. et.al. "Transport of Layer 2 Frames Over MPLS", 1834 draft-martini-l2circuit-trans-mpls-08.txt, Work in Progress, 1836 [MOHAN-LPE] 1837 Mohan, D. et.al. "VPLS/LPE L2VPNs: Virtual Private LAN Services 1838 using Logical PE Architecture ", draft-ouldbrahim-l2vpn-lpe- 1839 02.txt, Work in Progress, Internet Draft, Mar 2002 1841 [MPLS-GRE] 1842 Rekhter, Y. "MPLS Label Stack Encapsulation in GRE", Rekhter et 1843 al, draft-rekhter-mpls-over-gre-03.txt, Work in Progress, 1844 Internet Draft Sep, 2001. 1846 [MPLS-IP] 1847 Worster, T. et.al. "MPLS Label Stack Encapsulation in IP", 1848 Worster et al, draft-worster-mpls-in-ip-05.txt, Work in 1849 Progress, Internet Draft, Jul 2001. 1851 [PWE3-FW] 1852 Pate, P. editor, "Framework for Pseudo Wire Emulation Edge-to- 1853 Edge", Pate, P. editor, draft-ietf-pwe3-framework-00.txt, Work 1854 in Progress, Internet draft, Feb 2002 1856 [ROSEN-L2-SIGNALING] 1857 Rosen, E. "Single-Sided Signaling for L2VPNs", draft-rosen- 1858 ppvpn-l2-signaling-01.txt, Work in Progress, Internet Draft, 1859 Feb 2002 1861 [SAJASSI-VPLS] 1862 Sajassi, A. "VPLS Architectures", draft-sajassi-vpls- 1863 architectures-00.txt , Work in Progress, Internet Draft, Feb 1864 2002. 1866 [SHAH-INTER] 1867 Shah, H. et.al. "IP address resolution for IP interworking of 1868 Layer 2 VPN", draft-shah-l2vpn-arp-resolve-00.txt, Work in 1869 Progress, Internet Draft, Jan 2002 1871 [SHAH-SIG] 1872 Shah, H. et.al. "Signaling between PE and L2PE/MTU for 1873 Decoupled VPLS and Hierarchical VPLS", draft-shah-ppvpn-vpls- 1874 pe-mtu-signaling-00.txt, Work in Progress, Internet Draft, Feb 1875 2002. 1877 6. Authors and Acknowledgments 1879 This document is the outcome of discussions within a PPVPN Layer 2 1880 VPN design team, all of whose members could be considered to be co- 1881 authors. Specifically, the co-authors are Loa Andersson, Waldemar 1882 Augustyn, Marty Borden, Hamid Ould-Brahim, Juha Heinanen, Kireeti 1883 Kompella, Vach Kompella, Marc Lasserre, Pascal Menezes, Vasile 1884 Radoaca, Eric Rosen, and Tissa Senevirathne. 1886 The authors would like to thank Marco Carugi for cooperation in 1887 setting up context, working directions and taking time for 1888 discussions in this space, Tove Madsen for valuable input and 1889 reviews, and Norm Finn, Matt Squires, and Ali Sajassi for valuable 1890 discussion of the VPLS issues. 1892 7. Authors' Contact Information 1894 Loa Andersson 1895 Email: loa@pi.se 1897 Eric C. Rosen 1898 Cisco Systems, Inc. 1899 250 Apollo Drive 1900 Chelmsford, MA, 01824 1901 Email: erosen@cisco.com 1903 Waldemar Augustyn 1904 Email: waldemar@nxp.com 1906 Marty Borden 1907 mborden@acm.org 1909 Juha Heinanen 1910 Song Networks, Inc. 1911 Hallituskatu 16 1912 33200 Tampere, Finland 1913 Email: jh@song.fi 1915 Kireeti Kompella 1916 Juniper Networks, Inc. 1917 1194 N. Mathilda Ave 1918 Sunnyvale, CA 94089 1919 Email: kireeti@juniper.net 1921 Vach Kompella 1922 TiMetra Networks 1923 274 Ferguson Dr. 1924 Mountain View, CA 94043 1925 Email: vkompella@timetra.com 1926 Marc Lasserre 1927 Riverstone Networks 1928 5200 Great America Pkwy 1929 Santa Clara, CA 95054 1930 Email: marc@riverstonenet.com 1932 Pascal Menezies 1933 Email: pascalm1@yahoo.com 1935 Hamid Ould-Brahim 1936 Nortel Networks 1937 P O Box 3511 Station C 1938 Ottawa, ON K1Y 4H7, Canada 1939 Email: hbrahim@nortelnetworks.com 1941 Vasile Radoaca 1942 Nortel Networks 1943 600 Technology Park 1944 Billerica, MA 01821 1945 Email: vasile@nortelnetworks.com 1947 Tissa Senevirathne 1948 1567 Belleville Way 1949 Sunnyvale CA 94087 1950 Email: tsenevir@hotmail.com