idnits 2.17.1 draft-kompella-l2vpn-l2vpn-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 930. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 941. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 948. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 954. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 4, 2007) is 6256 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) == Unused Reference: '3' is defined on line 855, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 858, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 897, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4447 (ref. '11') (Obsoleted by RFC 8077) == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-03 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track March 4, 2007 5 Expires: September 5, 2007 7 Layer 2 Virtual Private Networks Using BGP for Auto-discovery and 8 Signaling 9 draft-kompella-l2vpn-l2vpn-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 5, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM 43 circuits have been around a long time; more recently, Ethernet VPNs, 44 including Virtual Private LAN Service, have become popular. 45 Traditional L2VPNs often required a separate Service Provider 46 infrastructure for each type, and yet another for the Internet and IP 47 VPNs. In addition, L2VPN provisioning was cumbersome. This document 48 presents a new approach to the problem of offering L2VPN services 49 where the L2VPN customer's experience is virtually identical to that 50 offered by traditional Layer 2 VPNs, but such that a Service Provider 51 can maintain a single network for L2VPNs, IP VPNs and the Internet, 52 as well as a common provisioning methodology for all services. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.2. Advantages of Layer 2 VPNs . . . . . . . . . . . . . . . . 6 59 1.2.1. Separation of Administrative Responsibilities . . . . 6 60 1.2.2. Migrating from Traditional Layer 2 VPNs . . . . . . . 7 61 1.2.3. Privacy of Routing . . . . . . . . . . . . . . . . . . 7 62 1.2.4. Layer 3 Independence . . . . . . . . . . . . . . . . . 7 63 1.2.5. PE Scaling . . . . . . . . . . . . . . . . . . . . . . 7 64 1.2.6. Ease of Configuration . . . . . . . . . . . . . . . . 8 65 1.3. Advantages of Layer 3 VPNs . . . . . . . . . . . . . . . . 9 66 1.3.1. Layer 2 Independence . . . . . . . . . . . . . . . . . 9 67 1.3.2. SP Routing as Added Value . . . . . . . . . . . . . . 9 68 1.3.3. Class-of-Service . . . . . . . . . . . . . . . . . . . 10 69 1.4. Multicast Routing . . . . . . . . . . . . . . . . . . . . 10 70 1.5. Conventions used in this document . . . . . . . . . . . . 11 71 2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 3. Operation of a Layer 2 VPN . . . . . . . . . . . . . . . . . . 13 73 3.1. Network Topology . . . . . . . . . . . . . . . . . . . . . 13 74 3.2. Configuration . . . . . . . . . . . . . . . . . . . . . . 14 75 3.2.1. CE Configuration . . . . . . . . . . . . . . . . . . . 15 76 3.2.2. PE Configuration . . . . . . . . . . . . . . . . . . . 16 77 3.2.3. Adding a New Site . . . . . . . . . . . . . . . . . . 16 78 4. PE Information Exchange . . . . . . . . . . . . . . . . . . . 17 79 4.1. Circuit Status Vector . . . . . . . . . . . . . . . . . . 17 80 4.2. Generalizing the VPN Topology . . . . . . . . . . . . . . 18 81 5. Layer 2 Interworking . . . . . . . . . . . . . . . . . . . . . 19 82 6. Packet Transport . . . . . . . . . . . . . . . . . . . . . . . 20 83 6.1. Layer 2 MTU . . . . . . . . . . . . . . . . . . . . . . . 20 84 6.2. Layer 2 Frame Format . . . . . . . . . . . . . . . . . . . 20 85 6.3. IP-only Layer 2 Interworking . . . . . . . . . . . . . . . 21 86 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 90 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 92 Intellectual Property and Copyright Statements . . . . . . . . . . 27 94 1. Introduction 96 The earliest Virtual Private Networks (VPNs) were based on Layer 2 97 circuits: X.25, Frame Relay and ATM (see [15]). More recently, VPNs 98 based on Ethernet Virtual Local Area Networks (VLANs) and Virtual 99 Private LAN Service (VPLS) ([2] and [12]) have become quite popular. 100 All of these come under the classification of Layer 2 VPNs (L2VPNs), 101 as the customer to Service Provider (SP) hand-off is at Layer 2. 103 There are at least two factors that adversely affected the cost of 104 offering L2VPNs. The first is that the easiest way to offer a L2VPN 105 of a given type of Layer 2 was over an infrastructure of the same 106 type. This approach required that the Service Provider build a 107 separate infrastructure for each Layer 2 encapsulation -- e.g., an 108 ATM infrastructure for ATM VPNs, an Ethernet infrastructure for 109 Ethernet VPNs, etc. In addition, a separate infrastructure was 110 needed for the Internet and IP VPNs ([6], and possibly yet another 111 for voice services. Going down this path meant a proliferation of 112 networks. 114 The other is that each of these networks had different provisioning 115 methodologies. Furthermore, the provisioning of a L2VPN was fairly 116 complex. It is important to distinguish between a single Layer 2 117 circuit, which connects two customer sites, and a Layer 2 VPN, which 118 is a set of circuits that connect sites belonging to the same 119 customer. The fact that two different circuits belonged to the same 120 VPN was typically known only to the provisioning system, not to the 121 switches offering the service; this complicated the setting up, and 122 subsequently, the troubleshooting, of a L2VPN. Also, each switch 123 offering the service had to be provisioned with the address of every 124 other switch in the same VPN, requiring, in the case of full-mesh VPN 125 connectivity, provisioning proportional to the square of the number 126 of sites. This made full-mesh L2VPN connectivity prohibitively 127 expensive for the SP, and thus in turn for customers. Finally, even 128 setting up a individual circuit often required the provisioning of 129 every switch along the path. 131 Of late, there has been much progress in network "convergence", 132 whereby Layer 2 traffic, Internet traffic and IP VPN traffic can be 133 carried over a single, consolidated network infrastructure based on 134 IP/MPLS tunnels; this is made possible by techniques such as those 135 described in [7], [8], [9], and [10] for Layer 2 traffic, and [6] for 136 IP VPN traffic. This development goes a long way toward addressing 137 the problem of network profileration. This document goes one step 138 further and shows how a Service Provider can offer Layer 2 VPNs using 139 protocol and provisioning methodologies similar to that used for VPLS 140 ([2]) and IP VPNs ([6]), thereby achieving a significant degree of 141 operational convergence as well. In particular, all of these 142 methodologies include the notion of a VPN identifier that serves to 143 unify components of a given VPN, and the concept of auto-discovery, 144 which simplifies the provisioning of dense VPN topologies (for 145 example, a full mesh). In addition, similar techniques are used in 146 all of the above-mentioned VPN technologies to offer inter-AS and 147 inter-provider VPNs (i.e., VPNs whose sites are connected to multiple 148 Autonomous Systems (ASs) or service providers). 150 Technically, the approach proposed here uses the concepts and 151 solution and described in [2], which describes VPLS, a particular 152 form of a Layer 2 VPN. That document in turn borrowed much from [6]. 153 This includes the use of BGP for auto-discovery and "demultiplexor" 154 (see below) exchange, and the concepts of Route Distinguishers to 155 make VPN advertisements unique, and Route Targets to control VPN 156 topology. In addition, all three documents share the idea that 157 routers not directly connected to VPN customers should carry no VPN 158 state, restricting the provisioning of individual connections to just 159 the edge devices. This is achieved by using tunnels to carry the 160 data, with a demultiplexor that identifies individual VPN circuits. 161 These tunnels could be based on MPLS, GRE, or any other tunnel 162 technology that offers a demultiplexing field; the signaling of these 163 tunnels is outside the scope of this document. The specific approach 164 taken here is to use an MPLS label as the demultiplexor. 166 Layer 2 VPNs typically require that all sites in the VPN connect to 167 the SP with the same Layer 2 encapsulation. To ease this 168 restriction, this document proposes a limited form of Layer 2 169 interworking, by restricting the Layer 3 protocol to IP only (see 170 Section 5). 172 It may be instructive to compare the approach in [11] with the one 173 described here, keeping in mind that the solution described therein 174 does not include auto-discovery. 176 The rest of this section discusses the relative merits of Layer 2 and 177 Layer 3 VPNs. Section 3 describes the operation of a Layer 2 VPN. 178 Section 5 describes IP-only Layer 2 interworking. Section 6 179 describes how the L2 packets are transported across the SP network. 181 1.1. Terminology 183 The terminology used is from [2] and [6], and is briefly repeated 184 here. A "customer" is a customer of a Service Provider seeking to 185 interconnect their various "sites" (each an independent network) at 186 Layer 2 through the Service Provider's network, while maintaining 187 privacy of communication and address space. The device in a customer 188 site that connects to a Service Provider router is termed the CE 189 (customer edge) device; this device may be a router or a switch. The 190 Service Provider router to which a CE connects is termed a PE. A 191 router in the Service Provider's network which doesn't connect 192 directly to any CE is termed P. Every pair of PEs is connected by a 193 "tunnel"; within a tunnel, VPN data is distinguished by a 194 "demultiplexor", which in this document is an MPLS label. 196 Each CE within a VPN is assigned a CE ID, a number that uniquely 197 identifies a CE within an L2 VPN. More accurately, the CE ID 198 identifies a physical connection from the CE device to the PE, since 199 a CE may be connected to multiple PEs (or multiply connected to a 200 PE); in such a case, the CE would have a CE ID for each connection. 201 A CE may also be part of many L2 VPNs; it would need one (or more) CE 202 ID(s) for each L2 VPN of which it is a member. The number space for 203 CE IDs is scoped to a given VPN. 205 In the case of inter-Provider L2 VPNs, there needs to be some 206 coordination of allocation of CE IDs. One solution is to allocate 207 ranges for each SP. Other solutions may be forthcoming. 209 Within each physical connection from a CE to a PE, there may be 210 multiple virtual circuits. These will be referred to as Attachment 211 Circuits (ACs), following [11]. Similarly, the entity that connects 212 two attachment circuits across the Service Provider network is called 213 a pseudo-wire (PW). 215 1.2. Advantages of Layer 2 VPNs 217 A Layer 2 VPN is one where a Service Provider provides Layer 2 218 connectivity to the customer. The Service Provider does not 219 participate in the customer's Layer 3 network, in particular, in the 220 routing, resulting in several advantages to the SP as a whole and to 221 PE routers in particular. 223 1.2.1. Separation of Administrative Responsibilities 225 In a Layer 2 VPN, the Service Provider is responsible for Layer 2 226 connectivity; the customer is responsible for Layer 3 connectivity, 227 which includes routing. If the customer says that host x in site A 228 cannot reach host y in site B, the Service Provider need only 229 demonstrate that site A is connected to site B. The details of how 230 routes for host y reach host x are the customer's responsibility. 232 Another important factor is that once a PE provides Layer 2 233 connectivity to its connected CE, its job is done. A misbehaving CE 234 can at worst flap its interface, but route flaps in the customer 235 network have little effect on the SP network. On the other hand, a 236 misbehaving CE in a Layer 3 VPN can flap its routes, leading to 237 instability of the PE router or even the entire SP network. Thus, 238 when offering a Layer 3 VPN, a SP should proactively protect itself 239 from Layer 3 instability in the CE network. 241 1.2.2. Migrating from Traditional Layer 2 VPNs 243 Since "traditional" Layer 2 VPNs (i.e., real Frame Relay circuits 244 connecting sites) are indistinguishable from tunnel-based VPNs from 245 the customer's point-of-view, migrating from one to the other raises 246 few issues. Layer 3 VPNs, on the other hand, require a considerable 247 re-design of the customer's Layer 3 routing architecture. 248 Furthermore, with Layer 3 VPNs, special care has to be taken that 249 routes within the traditional VPN are not preferred over the Layer 3 250 VPN routes (the so-called "backdoor routing" problem, whose solution 251 requires protocol changes that are somewhat ad hoc). 253 1.2.3. Privacy of Routing 255 In a Layer 2 VPN, the privacy of customer routing is a natural 256 fallout of the fact that the Service Provider does not participate in 257 routing. The SP routers need not do anything special to keep 258 customer routes separate from other customers or from the Internet; 259 there is no need for per-VPN routing tables, and the additional 260 complexity this imposes on PE routers. 262 1.2.4. Layer 3 Independence 264 Since the Service Provider simply provides Layer 2 connectivity, the 265 customer can run any Layer 3 protocols they choose. If the SP were 266 participating in customer routing, it would be vital that the 267 customer and SP both use the same Layer 3 protocol(s) and routing 268 protocols. 270 Note that IP-only Layer 2 interworking doesn't have this benefit as 271 it restricts the Layer 3 to IP only. 273 1.2.5. PE Scaling 275 In the Layer 2 VPN scheme described below, each PE transmits a single 276 small chunk of information about every CE that the PE is connected to 277 to every other PE. That means that each PE need only maintain a 278 single chunk of information from each CE in each VPN, and keep a 279 single "route" to every site in every VPN. This means that both the 280 Forwarding Information Base and the Routing Information Base scale 281 well with the number of sites and number of VPNs. Furthermore, the 282 scaling properties are independent of the customer: the only germane 283 quantity is the total number of VPN sites. 285 This is to be contrasted with Layer 3 VPNs, where each CE in a VPN 286 may have an arbitrary number of routes that need to be carried by the 287 SP. This leads to two issues. First, both the information stored at 288 each PE and the number of routes installed by the PE for a CE in a 289 VPN can be (in principle) unbounded, which means in practice that a 290 PE must restrict itself to installing routes associated with the VPNs 291 that it is currently a member of. Second, a CE can send a large 292 number of routes to its PE, which means that the PE must protect 293 itself against such a condition. Thus, the SP must enforce limits on 294 the number of routes accepted from a CE; this in turn requires the PE 295 router to offer such control. 297 The scaling issues of Layer 3 VPNs come into sharp focus at a BGP 298 route reflector (RR). An RR cannot keep all the advertised routes in 299 every VPN since the number of routes will be too large. The 300 following solutions/extensions are needed to address this issue: 302 1. RRs could be partitioned so that each RR services a subset of 303 VPNs so that no single RR has to carry all the routes. 305 2. An RR could use a preconfigured list of Route-Targets for its 306 inbound route filtering. The RR may choose to perform Route 307 Target Filtering, described in [13]. 309 1.2.6. Ease of Configuration 311 Configuring traditional Layer 2 VPNs with dense topologies was a 312 burden primarily because of the O(n*n) nature of the task. If there 313 are n CEs in a Frame Relay VPN, say full-mesh connected, n*(n-1)/2 314 DLCI PVCs must be provisioned across the SP network. At each CE, 315 (n-1) DLCIs must be configured to reach each of the other CEs. 316 Furthermore, when a new CE is added, n new DLCI PVCs must be 317 provisioned; also, each existing CE must be updated with a new DLCI 318 to reach the new CE. Finally, each PVC requires state in every 319 transit switch. 321 In our proposal, PVCs are tunnelled across the SP network. The 322 tunnels used are provisioned independently of the L2VPNs, using 323 signalling protocols (in case of MPLS, LDP or RSVP-TE can be used), 324 or set up by configuration; and the number of tunnels is independent 325 of the number of L2VPNs. This reduces a large part of the 326 provisioning burden. 328 Furthermore, we assume that DLCIs at the CE edge are relatively 329 cheap; and VPN labels in the SP network are cheap. This allows the 330 SP to "over-provision" VPNs: for example, allocate 50 CEs to a VPN 331 when only 20 are needed. With this over-provisioning, adding a new 332 CE to a VPN requires configuring just the new CE and its associated 333 PE; existing CEs and their PEs need not be re-configured. Note that 334 if DLCIs at the CE edge are expensive, e.g. if these DLCIs are 335 provisioned across a switched network, one could provision them as 336 and when needed, at the expense of extra configuration. This need 337 not still result in extra state in the SP network, i.e. an 338 intelligent implementation can allow overprovisioning of the pool of 339 VPN labels. 341 1.3. Advantages of Layer 3 VPNs 343 Layer 3 VPNs ([6] in particular) offer a good solution when the 344 customer traffic is wholly IP, customer routing is reasonably simple, 345 and the customer sites connect to the SP with a variety of Layer 2 346 technologies. 348 1.3.1. Layer 2 Independence 350 One major restriction in a Layer 2 VPN is that the Layer 2 medium 351 with which the various sites of a single VPN connect to the SP must 352 be uniform. On the other hand, the various sites of a Layer 3 VPN 353 can connect to the SP with any supported media; for example, some 354 sites may connect with Frame Relay circuits, and others with 355 Ethernet. 357 This restriction of Layer 2 VPN is alleviated by the IP-only Layer 2 358 interworking proposed in this document. This comes at the cost of 359 losing the Layer 3 independence. 361 A corollary to this is that the number of sites that can be in a 362 Layer 2 VPN is determined by the number of Layer 2 circuits that the 363 Layer 2 technology provides. For example, if the Layer 2 technology 364 is Frame Relay with 2-octet DLCIs, a CE can connect to at most about 365 a thousand other CEs in a VPN. 367 1.3.2. SP Routing as Added Value 369 Another problem with Layer 2 VPNs is that the CE router in a VPN must 370 be able to deal with having N routing peers, where N is the number of 371 sites in the VPN. This can be alleviated by manipulating the 372 topology of the VPN. For example, a hub-and-spoke VPN architecture 373 means that only one CE router (the hub) needs to deal with N 374 neighbors. However, in a Layer 3 VPN, a CE router need only deal 375 with one neighbor, the PE router. Thus, the SP can offer Layer 3 376 VPNs as a value-added service to its customers. 378 Moreover, with Layer 2 VPNs it is up to a customer to build and 379 operate the whole network. With Layer 3 VPNs, a customer is just 380 responsible for building and operating routing within each site, 381 which is likely to be much simpler than building and operating 382 routing for the whole VPN. That, in turn, makes Layer 3 VPNs more 383 suitable for customers who don't have sufficient routing expertise, 384 again allowing the SP to provide added value. 386 As mentioned later, multicast routing and forwarding is another 387 value-added service that an SP can offer. 389 1.3.3. Class-of-Service 391 Class-of-Service issues have been addressed for Layer 3 VPNs. Since 392 the PE router has visibility into the network Layer (IP), the PE 393 router can take on the tasks of CoS classification and routing. This 394 restriction on Layer 2 VPNs is again eased in the case of IP-only 395 Layer 2 interworking, as the PE router has visibility into the 396 network Layer (IP). 398 1.4. Multicast Routing 400 There are two aspects to multicast routing that we will consider. On 401 the protocol front, supporting IP multicast in a Layer 3 VPN requires 402 PE routers to participate in the multicast routing instance of the 403 customer, and thus keep some related state information. 405 In the Layer 2 VPN case, the CE routers run native multicast routing 406 directly. The SP network just provides pipes to connect the CE 407 routers; PEs are unaware whether the CEs run multicast or not, and 408 thus do not have to participate in multicast protocols or keep 409 multicast state information. 411 On the forwarding front, in a Layer 3 VPN, CE routers do not 412 replicate multicast packets; thus, the CE-PE link carries only one 413 copy of a multicast packet. Whether replication occurs at the 414 ingress PE, or somewhere within the SP network depends on the 415 sophistication of the Layer 3 VPN multicast solution. The simple 416 solution where a PE replicates packets for each of its CEs may place 417 considerable burden on the PE. More complex solutions may require 418 VPN multicast state in the SP network, but may significantly reduce 419 the traffic in the SP network by delaying packet replication until 420 needed. 422 In a Layer 2 VPN, packet replication occurs at the CE. This has the 423 advantage of distributing the burden of replication among the CEs 424 rather than focusing it on the PE to which they are attached, and 425 thus will scale better. However, the CE-PE link will need to carry 426 the multiple copies of multicast packets. In the case of Virtual 427 Private LAN Service (a specific type of L2 VPN; see [2]), however, 428 the CE-PE link need transport only one copy of a multicast packet. 430 Thus, just as in the case of unicast routing, the SP has the choice 431 to offer a value-added service (multicast routing and forwarding) at 432 some cost (multicast state and packet replication) using a Layer 3 433 VPN, or to keep it simple and use a Layer 2 VPN. 435 1.5. Conventions used in this document 437 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 438 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 439 document are to be interpreted as described in [1]. 441 2. Contributors 443 The following contributed to this document. 445 Manoj Leelanivas, Juniper Networks 446 Quaizar Vohra, Nuova Networks 447 Javier Achirica, Telefonica 448 Ronald Bonica, Juniper Networks 449 Dave Cooper, Global Crossing 450 Chris Liljenstolpe, Alcatel 451 Eduard Metz, KPN Dutch Telecom 452 Hamid Ould-Brahim, Nortel 453 Chandramouli Sargor, CoSine 454 Himanshu Shah, Ciena 455 Vijay Srinivasan, CoSine 456 Zhaohui Zhang, Juniper Networks 458 3. Operation of a Layer 2 VPN 460 The following simple example of a customer with 4 sites connected to 461 3 PE routers in a Service Provider network will hopefully illustrate 462 the various aspects of the operation of a Layer 2 VPN. For 463 simplicity, we assume that a full-mesh topology is desired. 465 In what follows, Frame Relay serves as the Layer 2 medium, and each 466 CE has multiple DLCIs to its PE, each to connect to another CE in the 467 VPN. If the Layer 2 medium were ATM, then each CE would have 468 multiple VPI/VCIs to connect to other CEs. For PPP and Cisco HDLC, 469 each CE would have multiple physical interfaces to connect to other 470 CEs. In the case of IP-only Layer 2 interworking, each CE could have 471 a mix of one or more of the above Layer 2 mediums to connect to other 472 CEs. 474 3.1. Network Topology 476 Consider a Service Provider network with edge routers PE0, PE1, and 477 PE2. Assume that PE0 and PE1 are IGP neighbors, and PE2 is more than 478 one hop away from PE0. 480 Suppose that a customer C has 4 sites S0, S1, S2 and S3 that C wants 481 to connect via the Service Provider's network using Frame Relay. 482 Site S0 has CE0 and CE1 both connected to PE0. Site S1 has CE2 483 connected to PE0. Site S2 has CE3 connected to PE1 and CE4 connected 484 to PE2. Site S3 has CE5 connected to PE2. (See the Figure 1 below.) 485 Suppose further that C wants to "over-provision" each current site, 486 in expectation that the number of sites will grow to at least 10 in 487 the near future. However, CE4 is only provisioned with 9 DLCIs. 488 (Note that the signalling mechanism discussed in Section 4 will allow 489 a site to grow in terms of connectivity to other sites at a later 490 point of time at the cost of additional signalling, i.e., over- 491 provisioning is not a must but a recommendation). 493 Suppose finally that CE0 and CE2 have DLCIs 100 through 109 494 provisioned; CE1 and CE3 have DLCIs 200 through 209 provisioned; CE4 495 has DLCIs 107, 209, 265, 301, 414, 555, 654, 777 and 888 provisioned; 496 and CE5 has DLCIs 417-426. 498 S0 S3 499 .............. .............. 500 . . . . 501 . +-----+ . . . 502 . | CE0 |-----------+ . +-----+ . 503 . +-----+ . | . | CE5 | . 504 . . | . +--+--+ . 505 . +-----+ . | . | . 506 . | CE1 |-------+ | .......|...... 507 . +-----+ . | | / 508 . . | | / 509 .............. | | / 510 | | SP Network / 511 .....|...|.............................../..... 512 . | | / . 513 . +-+---+-+ +-------+ / . 514 . | PE0 |-------| P |-- | . 515 . +-+---+-+ +-------+ \\ | . 516 . / \\ \\ +---+---+ . 517 . | -----+ --| PE2 | . 518 . | | +---+---+ . 519 . | +---+---+ / . 520 . | | PE1 | / . 521 . | +---+---+ / . 522 . | \\ / . 523 ...|.............|.............../............. 524 | | / 525 | | / 526 | | / 527 S1 | | S2 / 528 .............. | ........|........../...... 529 . . | . | | . 530 . +-----+ . | . +--+--+ +--+--+ . 531 . | CE2 |-----+ . | CE3 | | CE4 | . 532 . +-----+ . . +-----+ +-----+ . 533 . . . . 534 .............. .......................... 536 Figure 1: Example Network Topology 538 3.2. Configuration 540 The following sub-sections detail the configuration that is needed to 541 provision the above VPN. For the purpose of exposition, we assume 542 that the customer will connect to the SP with Frame Relay circuits. 544 While we focus primarily on the configuration that an SP has to do, 545 we touch upon the configuration requirements of CEs as well. The 546 main point of contact in CE-PE configuration is that both must agree 547 on the DLCIs that will be used on the interface connecting them. 549 If the PE-CE connection is Frame Relay, it is recommended to run LMI 550 between the PE and CE. For the case of ATM VCs, OAM cells may be 551 used; for PPP and Cisco HDLC, keepalives may be used directly between 552 CEs; however, in this case, PEs would not have visibility as to the 553 liveness of customers circuits. 555 In case of IP-only Layer 2 interworking, if CE1, attached to PE0, 556 connects to CE3, attached to PE1, via a L2VPN circuit, the Layer 2 557 medium between CE1 and PE0 is independent of the Layer 2 medium 558 between CE3 and PE1. Each side will run its own Layer 2 specific 559 link management protocol, e.g., LMI, LCP, etc. PE0 will inform PE1 560 about the status of its local circuit to CE1 via the circuit status 561 vector TLV defined in Section 4. Similarly PE1 will inform PE0 about 562 the status of its local circuit to CE3. 564 3.2.1. CE Configuration 566 Each CE that belongs to a VPN is given a "CE ID". CE IDs must be 567 unique in the context of a VPN. For the example, we assume that the 568 CE ID for CE-k is k. 570 Each CE is configured to communicate with its corresponding PE with 571 the set of DLCIs given above; for example, CE0 is configured with 572 DLCIs 100 through 109. In general, a CE is configured with a list of 573 circuits, all with the same Layer 2 encapsulation type, e.g., DLCIs, 574 VCIs, physical PPP interface etc. (IP-only Layer 2 interworking 575 allows a mix of Layer 2 encapsulation types). The size of this list/ 576 set determines the number of remote CEs a given CE can communicate 577 with. Denote the size of this list/set as the CE's range. A CE's 578 range must be at least the number of remote CEs that the CE will 579 connect to in a given VPN; if the range exceeds this, then the CE is 580 over-provisioned, in anticipation of growth of the VPN. 582 Each CE also "knows" which DLCI connects it to each other CE. The 583 methodology followed in this example is to use the CE ID of the other 584 CE as an index into the DLCI list this CE has (with zero-based 585 indexing, i.e., 0 is the first index). For example, CE0 is connected 586 to CE3 through its fourth DLCI, 103; CE4 is connected to CE2 by the 587 third DLCI in its list, namely 265. This is just the methodology 588 used in the example below; the actual methodology used to pick the 589 DLCI to be used is a local matter; the key factor is that CE-k may 590 communicate with CE-m using a different DLCI from the DLCI that CE-m 591 uses to communicate to CE-k, i.e., the SP network effectively acts as 592 a giant Frame Relay switch. This is very important, as it decouples 593 the DLCIs used at each CE site, making for much simpler provisioning. 595 3.2.2. PE Configuration 597 Each PE is configured with the VPNs in which it participates. Each 598 VPN is associated with one or more Route Target communities [5] which 599 serve to define the topology of the VPN. For each VPN, the PE must 600 determine a Route Distinguisher (RD) to use; this may either be 601 configured or chosen by the PE. RDs do not have to be unique across 602 the VPN. For each CE attached to the PE in a given VPN, the PE must 603 know the set of virtual circuits (DLCI, VCI/VPI or VLAN) connecting 604 it to the CE, and a CE ID identifying the CE within the VPN. CE IDs 605 must be unique in the context of a given VPN. 607 3.2.3. Adding a New Site 609 The first step in adding a new site to a VPN is to pick a new CE ID. 610 If all current members of the VPN are over-provisioned, i.e., their 611 range includes the new CE ID, adding the new site is a purely local 612 task. Otherwise, the sites whose range doesn't include the new CE ID 613 and wish to communicate directly with the new CE must have their 614 ranges increased by allocating additional local circuits to 615 incorporate the new CE ID. 617 The next step is ensuring that the new site has the required 618 connectivity. This usually requires adding a new virtual circuit 619 between the PE and CE; in most cases, this configuration is limited 620 to the PE in question. 622 The rest of the configuration is a local matter between the new CE 623 and the PE to which it is attached. 625 It bears repeating that the key to making additions easy is over- 626 provisioning and the algorithm for mapping a CE-id to a DLCI which is 627 used for connecting to the corresponding CE. However, what is being 628 over-provisioned is the number of DLCIs/VCIs that connect the CE to 629 the PE. This is a local matter between the PE and CE, and does not 630 affect other PEs or CEs. 632 4. PE Information Exchange 634 When a PE is configured with all the required information for a CE, 635 it advertises to other PEs the fact that it is participating in a VPN 636 via BGP messages, as per [2], section 3. BGP was chosen as the means 637 for exchanging L2 VPN information for two reasons: it offers 638 mechanisms for both auto-discovery and signaling, and allows for 639 operational convergence, as explained in Section 1. A bonus for 640 using BGP is a robust inter-AS solution for L2VPNs. 642 There are two modifications to the formating of messages. The first 643 is that the set of encapsulation types carried in the L2-info 644 extended community has been expanded to include the following set. 645 The encapsulation type identifies the Layer 2 encapsulation, e.g., 646 ATM, Frame Relay etc. 648 Value Encapsulation 649 0 Reserved 650 1 Frame Relay 651 2 ATM AAL5 VCC transport 652 3 ATM transparent cell transport 653 4 Ethernet VLAN 654 5 Ethernet 655 6 Cisco-HDLC 656 7 PPP 657 8 CEM 658 9 ATM VCC cell transport 659 10 ATM VPC cell transport 660 11 MPLS 661 12 VPLS 662 64 IP-interworking 664 The second is the introduction of notion of sub-TLVs (Type-Length- 665 Value triplets). L2VPN TLVs can be added to extend the information 666 carried in the L2 VPN NLRI. In L2VPN TLVs, type is 1 octet, length 667 is 2 octets and represents the size of the value field in bits. 669 4.1. Circuit Status Vector 671 This sub-TLV carries the status of a L2VPN PVC between a pair of PEs. 672 Note that a L2VPN PVC is bidirectional, composed of two simplex 673 connection going in opposite directions. A simplex connection 674 consists of the 3 segments: 1) the local access circuit between the 675 source CE and the ingress PE, 2) the tunnel LSP between the ingress 676 and egress PEs, and 3) the access circuit between the egress PE and 677 the destination CE. 679 To monitor the status of a PVC, a PE needs to monitor the status of 680 both simplex connections. Since it knows that status of its access 681 circuit, and the status of the tunnel towards the remote PE, it can 682 inform the remote PE of these two. Similarly, the remote PE can 683 inform the status of its access circuit to its local CE and the 684 status of the tunnel to the first PE. Combining the local and the 685 remote information, a PE can determine the status of a PVC. 687 The basic unit of advertisement in L2VPN for a given CE is a label- 688 block. Each label within a label-block corresponds to a PVC on the 689 CE. The local status information for all PVCs corresponding to a 690 label-block is advertised along with the NLRI for the label-block 691 using the status vector TLV. The Type field of this TLV is 1. The 692 Length field of the TLV specifies the length of the value field in 693 bits. The Value field of this TLV is a bit-vector, each bit of which 694 indicates the status of the PVC associated with the corresponding 695 label in the label-block. Bit value 0 corresponds to the PVC 696 associated with the first label in the label block, and indicates 697 that the local circuit and the tunnel LSP to the remote PE is up, 698 while a value of 1 indicates that either or both of them are down. 699 The Value field is padded to the nearest octet boundary. 701 If PE A receives an L2VPN NLRI, while selecting a label from a label- 702 block (advertised by PE B, for remote CE m, and VPN X) for one of its 703 local CE n (in VPN X) can also determine the status of the 704 corresponding PVC (between CE n and CE m) by looking at the 705 appropriate bit in the circuit status vector. 707 4.2. Generalizing the VPN Topology 709 In the above, we assumed for simplicity that the VPN was a full mesh. 710 To allow for more general VPN topologies, a mechanism based on 711 filtering on BGP extended communities can be used (see Section 4). 713 5. Layer 2 Interworking 715 As defined so far in this document, all CE-PE connections for a given 716 Layer 2 VPN must use the same Layer 2 encapsulation, e.g., they must 717 all be Frame Relay. This is often a burdensome restriction. One 718 answer is to use an existing Layer 2 interworking mechanism, for 719 example, Frame Relay-ATM interworking. 721 In this document, we take a different approach: we postulate that the 722 network Layer is IP, and base Layer 2 interworking on that. Thus, 723 one can choose between pure Layer 2 VPNs, with a stringent Layer 2 724 restriction but with Layer 3 independence, or a Layer 2 interworking 725 VPNs, where there is no restriction on Layer 2, but Layer 3 must be 726 IP. Of course, a PE may choose to implement Frame Relay-ATM 727 interworking. For example, an ATM Layer 2 VPN could have some CEs 728 connect via Frame Relay links, if their PE could translate Frame 729 Relay to ATM transparent to the rest of the VPN. This would be 730 private to the CE-PE connection, and such a course is outside the 731 scope of this document. 733 For Layer 2 interworking as defined here, when an IP packet arrives 734 at a PE, its Layer 2 address is noted, then all Layer 2 overhead is 735 stripped, leaving just the IP packet. Then, a VPN label is added, 736 and the packet is encapsulated in the PE-PE tunnel (as required by 737 the tunnel technology). Finally, the packet is forwarded. Note that 738 the forwarding decision is made on the basis of the Layer 2 739 information, not the IP header. At the egress, the VPN label 740 determines to which CE the packet must be sent, and over which 741 virtual circuit; from this, the egress PE can also determine the 742 Layer 2 encapsulation to place on the packet once the VPN label is 743 stripped. 745 An added benefit of restricting interworking to IP only as the Layer 746 3 technology is that the provider's network can provide IP Diffserv 747 or any other IP based QOS mechanism to the L2VPN customer. The 748 ingress PE can set up IP/TCP/UDP based classifiers to do DiffServ 749 marking, and other functions like policing and shaping on the L2 750 circuits of the VPN customer. Note the division of labor: the CE 751 determines the destination CE, and encodes that in the Layer 2 752 address. The ingress PE thus determines the egress PE and VPN label 753 based on the Layer 2 address supplied by the CE, but the ingress PE 754 can choose the tunnel to reach the egress PE (in the case that there 755 are different tunnels for each CoS/DiffServ code point), or the CoS 756 bits to place in the tunnel (in the case where a single tunnel 757 carries multiple CoS/DiffServ code points) based on its own 758 classification of the packet. 760 6. Packet Transport 762 When a packet arrives at a PE from a CE in a Layer 2 VPN, the Layer 2 763 address of the packet identifies to which other CE the packet is 764 destined. The procedure outlined above installs a route that maps 765 the Layer 2 address to a tunnel (which identifies the PE to which the 766 destination CE is attached) and a VPN label (which identifies the 767 destination CE). If the egress PE is the same as the ingress PE, no 768 tunnel or VPN label is needed. 770 The packet may then be modified (depending on the Layer 2 771 encapsulation). In case of IP-only Layer 2 interworking, the Layer 2 772 header is completely stripped off till the IP header. Then, a VPN 773 label and tunnel encapsulation are added as specified by the route 774 described above, and the packet is sent to the egress PE. 776 If the egress PE is the same as the ingress, the packet "arrives" 777 with no labels. Otherwise, the packet arrives with the VPN label, 778 which is used to determine which CE is the destination CE. The 779 packet is restored to a fully-formed Layer 2 packet, and then sent to 780 the CE. 782 6.1. Layer 2 MTU 784 This document requires that the Layer 2 MTU configured on all the 785 access circuits connecting CEs to PEs in a L2VPN be the same. This 786 can be ensured by passing the configured Layer 2 MTU in the Layer2- 787 info extended community when advertising L2VPN label-blocks. On 788 receiving L2VPN label-block from remote PEs in a VPN, the MTU value 789 carried in the Layer2-info extendend community should be compared 790 against the configured value for the VPN. If they don't match, then 791 the label-block should be ignored. 793 The MTU on the Layer 2 access links MUST be chosen such that the size 794 of the L2 frames plus the L2VPN header does not exceed the MTU of the 795 SP network. Layer 2 frames that exceed the MTU after encapsulation 796 MUST be dropped. For the case of IP-only Layer 2 interworking the IP 797 MTU on the Layer 2 access link must be chosen such that the size of 798 the IP packet and the L2VPN header does not exceed the MTU of the SP 799 network. 801 6.2. Layer 2 Frame Format 803 The modification to the Layer 2 frame depends on the Layer 2 type. 804 This document requires that the encapsulation methods used in 805 transporting of Layer 2 frames over tunnels be the same as described 806 in [7], [8], [9], and [10], except in the case of IP-only Layer 2 807 Interworking which is described next. 809 6.3. IP-only Layer 2 Interworking 811 +----------------------------+ 812 | Tunnel | VPN | IP | VPN label is the 813 | Encap | Label | Packet | demultiplexing field 814 +----------------------------+ 816 Figure 2: Format of IP-only Layer 2 interworking packet 818 At the ingress PE, an L2 frame's L2 header is completely stripped off 819 and is carried over as an IP packet within the SP network (Figure 2). 820 The forwarding decision is still based on the L2 address of the 821 incoming L2 frame. At the egress PE, the IP packet is encapsulated 822 back in an L2 frame and transported over to the destination CE. The 823 forwarding decision at the egress PE is based on the VPN label as 824 before. The L2 technology between egress PE and CE is independent of 825 the L2 technology between ingress PE and CE. 827 7. Acknowledgments 829 The author would like to thank Chaitanya Kodeboyina, Dennis Ferguson, 830 Der-Hwa Gan, Dave Katz, Nischal Sheth, John Stewart, and Paul Traina 831 for the enlightening discussions that helped shape the ideas 832 presented here, and Ross Callon for his valuable comments. 834 The idea of using extended communities for more general connectivity 835 of a Layer 2 VPN was a contribution by Yakov Rekhter, who also gave 836 many useful comments on the text; many thanks to him. 838 8. Security Considerations 840 RFC 4761, on which this document is based, has a detailed discussion 841 of security considerations, most of which apply to this document as 842 well. No new security concerns are introduced in this document. 844 9. References 846 9.1. Normative References 848 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 849 Levels", BCP 14, RFC 2119, March 1997. 851 [2] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 852 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, 853 January 2007. 855 [3] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 856 (BGP-4)", RFC 4271, January 2006. 858 [4] Bates, T., "Multiprotocol Extensions for BGP-4", 859 draft-ietf-idr-rfc2858bis-10 (work in progress), March 2006. 861 [5] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 862 Communities Attribute", RFC 4360, February 2006. 864 [6] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks 865 (VPNs)", RFC 4364, February 2006. 867 [7] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 868 "Encapsulation Methods for Transport of Ethernet over MPLS 869 Networks", RFC 4448, April 2006. 871 [8] Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation 872 Methods for Transport of PPP/High-Level Data Link Control 873 (HDLC) over MPLS Networks", RFC 4618, September 2006. 875 [9] Martini, L., Kawa, C., and A. Malis, "Encapsulation Methods for 876 Transport of Frame Relay over Multiprotocol Label Switching 877 (MPLS) Networks", RFC 4619, September 2006. 879 [10] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., Brayley, 880 J., and G. Koleyni, "Encapsulation Methods for Transport of 881 Asynchronous Transfer Mode (ATM) over MPLS Networks", RFC 4717, 882 December 2006. 884 9.2. Informative References 886 [11] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, 887 "Pseudowire Setup and Maintenance Using the Label Distribution 888 Protocol (LDP)", RFC 4447, April 2006. 890 [12] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 891 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 892 RFC 4762, January 2007. 894 [13] Marques, P., "Constrained VPN Route Distribution", 895 draft-ietf-l3vpn-rt-constrain-02 (work in progress), June 2005. 897 [14] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", 898 draft-ietf-l3vpn-2547bis-mcast-03 (work in progress), 899 October 2006. 901 [15] Kosiur, D., "Building and Managing Virtual Private Networks", 902 1998. 904 Wiley Computer Publishing 906 Author's Address 908 Kireeti Kompella 909 Juniper Networks 910 1194 N. Mathilda Ave. 911 Sunnyvale, CA 94089 912 US 914 Email: kireeti@juniper.net 916 Full Copyright Statement 918 Copyright (C) The IETF Trust (2007). 920 This document is subject to the rights, licenses and restrictions 921 contained in BCP 78, and except as set forth therein, the authors 922 retain all their rights. 924 This document and the information contained herein are provided on an 925 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 926 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 927 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 928 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 929 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 930 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 932 Intellectual Property 934 The IETF takes no position regarding the validity or scope of any 935 Intellectual Property Rights or other rights that might be claimed to 936 pertain to the implementation or use of the technology described in 937 this document or the extent to which any license under such rights 938 might or might not be available; nor does it represent that it has 939 made any independent effort to identify any such rights. Information 940 on the procedures with respect to rights in RFC documents can be 941 found in BCP 78 and BCP 79. 943 Copies of IPR disclosures made to the IETF Secretariat and any 944 assurances of licenses to be made available, or the result of an 945 attempt made to obtain a general license or permission for the use of 946 such proprietary rights by implementers or users of this 947 specification can be obtained from the IETF on-line IPR repository at 948 http://www.ietf.org/ipr. 950 The IETF invites any interested party to bring to its attention any 951 copyrights, patents or patent applications, or other proprietary 952 rights that may cover technology that may be required to implement 953 this standard. Please address the information to the IETF at 954 ietf-ipr@ietf.org. 956 Acknowledgment 958 Funding for the RFC Editor function is provided by the IETF 959 Administrative Support Activity (IASA).