idnits 2.17.1 draft-kompella-l2vpn-l2vpn-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 693 has weird spacing: '...nt with top l...' -- 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 (January 2004) is 7400 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: 'KEYWORDS' is mentioned on line 49, but not defined -- Looks like a reference, but probably isn't: '0' on line 688 -- Looks like a reference, but probably isn't: '4' on line 724 == Missing Reference: 'INETVPN' is mentioned on line 878, but not defined -- Looks like a reference, but probably isn't: '8' on line 1034 == Unused Reference: 'BGP-RFSH' is defined on line 1131, but no explicit reference was found in the text == Unused Reference: 'IPVPN-MCAST' is defined on line 1145, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. 'BGP') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2842 (ref. 'BGP-CAP') (Obsoleted by RFC 3392) ** Obsolete normative reference: RFC 2858 (ref. 'BGP-MP') (Obsoleted by RFC 4760) -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-ORF' -- Possible downref: Non-RFC (?) normative reference: ref. 'EXT-COMM' -- Possible downref: Non-RFC (?) normative reference: ref. 'L2-ENCAP' -- Obsolete informational reference (is this intentional?): RFC 2547 (ref. 'IPVPN') (Obsoleted by RFC 4364) Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Kompella (Editor) 2 Internet Draft Juniper Networks 3 Expiration Date: July 2004 January 2004 4 draft-kompella-l2vpn-l2vpn-00.txt 6 Layer 2 VPNs Over Tunnels 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (2004). All Rights Reserved. 33 Abstract 35 Virtual Private Networks (VPNs) based on Frame Relay or ATM circuits 36 have been around a long time. While these VPNs work well, the costs 37 of maintaining separate networks for Internet traffic and VPNs and 38 the administrative burden of provisioning these VPNs have led Service 39 Providers to look for alternative solutions. In this document, we 40 present a VPN solution where from the customer's point of view, the 41 VPN is based on Layer 2 circuits, but the Service Provider maintains 42 and manages a single network for IP, IP VPNs, and Layer 2 VPNs. 44 Conventions used in this document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 50 1. Introduction 52 The first corporate networks were based on dedicated leased lines 53 interconnecting the various offices of the corporation. Such 54 networks offered connectivity and little else: they didn't scale 55 well, they were expensive for the service providers (and hence for 56 their customers), and provisioning them was a slow and arduous task. 58 The first Virtual Private Networks (VPNs) were based on Layer 2 59 circuits: X.25, Frame Relay and ATM (see [VPN]). Layer 2 VPNs were 60 easier to provision, and virtual circuits allowed the service 61 provider to share a common infrastructure for all the VPNs. These 62 features were passed on to the customers in terms of cost savings. 63 However, while Layer 2 VPNs were a significant step forward from 64 dedicated lines, they still had their drawbacks. First, they tied 65 the service provider VPN infrastructure to a single medium (e.g., 66 ATM). This became even more of a burden if the Internet 67 infrastructure was to share the same physical links. Second, the 68 Internet infrastructure and the VPN infrastructure, even if they 69 shared the same physical network, needed separate administration and 70 maintenance. Third, while provisioning was much easier than for 71 dedicated lines, it was still complex. This was especially evident 72 in the effort to add a site to an existing VPN. 74 This document offers a solution that preserves the advantages of a 75 Layer 2 VPN while allowing the Service Provider to maintain and 76 manage a single network for IP, IP VPNs ([IPVPN]) and Layer 2 VPNs, 77 and reducing the provisioning problem significantly. In particular, 78 adding a site to an existing VPN in most cases requires configuring 79 just the Provider Edge router connected to the new site. 81 To ease the restriction that all sites within a single VPN connect 82 via the same layer 2 technology, this document proposes a limited 83 form of layer 2 interworking, restricted to IP only as the layer 3 84 protocol. 86 The solution we propose scales well because the amount of forwarding 87 state maintained in the core routers of the Service Provider Network 88 is independent of the number of layer 2 VPNs provisioned over the SP 89 network. This is achieved by using tunnels to carry the data, with a 90 "demultiplexing field" that identifies individual VCs. These tunnels 91 could be MPLS, GRE, or any other tunnel technology that offers a 92 demultiplexing field; the signaling of these tunnels is outside the 93 scope of this document. The specific approach taken here is to use a 94 32-bit demultiplexing field formatted as an MPLS label; other sizes 95 and formats are clearly possible, and will be defined as needed. 97 This approach combines auto-discovery of VPN sites with the 98 signalling of the demultiplexing fields for L2VPN PVCs. This is 99 possible because the mechanism used for auto-discovery (BGP) is also 100 capable of distributing Layer 2 information as well as the 101 demultiplexing field. 103 The rest of this section discusses the relative merits of Layer 2 and 104 Layer 3 VPNs. Section 4 describes the operation of a Layer 2 VPN. 105 Section 5 describes IP-only layer 2 interworking. Section 6 106 describes how the L2 packets are transported across the SP network. 107 Section 7 discusses BGP as a mechanism for auto-discovery and 108 signalling of Layer 2 VPNs. 110 1.1. Terminology 112 We assume that the reader is familiar with Multi-Protocol Label 113 Switching (MPLS [MPLS]) and the Border Gateway Protocol version 4 114 (BGP [BGP]). 116 The terminology we use follows. A "customer" is a customer of a 117 Service Provider seeking to interconnect the various "sites" 118 (independently connected networks) through the Service Provider's 119 network, while maintaining privacy of communication and address 120 space. The device in a customer site that connects to a Service 121 Provider router is termed the CE (customer edge device); this device 122 may be a router or a switch. The Service Provider router to which a 123 CE connects is termed a PE. A router in the Service Provider's 124 network which doesn't connect directly to any CE is termed P. These 125 definitions follow those given in [IPVPN]. 127 We also introduce three new terms: 129 VPN Label - the demultiplexing field which identifies an L2VPN PVC to 130 the edge of the SP network, i.e., the PE. 132 Tunnel - a PE-to-PE tunnel that is used to carry multiple types of 133 data. P routers in the SP core forward this data based on the tunnel 134 header and not on the data within, thus limiting the Layer 2 state to 135 the PE routers who host the Layer 2 circuit. 137 CE ID - a number that uniquely identifies a CE within an L2 VPN. 138 More accurately, the CE ID identifies a physical connection from the 139 CE device to the PE. Say a CE connected to a PE over a DS-3 for 140 Frame Relay access to a VPN; this DS-3 would need a CE ID. The CE 141 would also have N DLCIs over this DS-3 to speak to N other sites in 142 the VPN. 144 A CE may be connected to multiple PEs (or multiply connected to a 145 PE), in which case it would have a CE ID for each connection. If 146 these connections are in the same VPN, the CE IDs would have to be 147 different. A CE may also be part of many L2 VPNs; it would need one 148 (or more) CE ID(s) for each L2 VPN of which it is a member. 150 For the case of inter-Provider L2 VPNs, there needs to be some 151 coordination of allocation of CE IDs. One solution is to allocate 152 ranges for each SP. Other solutions may be forthcoming. 154 1.2. Advantages of Layer 2 VPNs 156 We define a Layer 2 VPN as one where a Service Provider provides a 157 layer 2 network to the customer. As far as the customer is 158 concerned, they have (say) Frame Relay circuits connecting the 159 various sites; each CE is configured with a DLCI with which to talk 160 to other CEs. Within the Service Provider's network, though, the 161 layer 2 packets are transported within tunnels, which could be MPLS 162 Label-Switched Paths (LSPs) or GRE tunnels, as examples. 164 The Service Provider does not participate in the customer's layer 3 165 network, in particular, in the routing, resulting in several 166 advantages to the SP as a whole and to PE routers in particular. 168 1.2.1. Separation of Administrative Responsibilities 170 In a Layer 2 VPN, the Service Provider is responsible for Layer 2 171 connectivity; the customer is responsible for Layer 3 connectivity, 172 which includes routing. If the customer says that host x in site A 173 cannot reach host y in site B, the Service Provider need only 174 demonstrate that site A is connected to site B. The details of how 175 routes for host y reach host x are the customer's responsibility. 177 Another very important factor is that once a PE provides Layer 2 178 connectivity to its connected CE, its job is done. A misbehaving CE 179 can at worst flap its interface. On the other hand, a misbehaving CE 180 in a Layer 3 VPN can flap its routes, leading to instability of the 181 PE router or even the entire SP network. This means that the Service 182 Provider must aggressively damp route flaps from a CE; this is common 183 enough with external BGP peers, but in the case of VPNs, the scale of 184 the problem is much larger; also, the CE-PE routing protocol may not 185 be BGP, and thus not have BGP's flap damping control. 187 1.2.2. Migrating from Traditional Layer 2 VPNs 189 Since "traditional" Layer 2 VPNs (i.e., real Frame Relay circuits 190 connecting sites) are indistinguishable from tunnel-based VPNs from 191 the customer's point-of-view, migrating from one to the other raises 192 few issues. With Layer 3 VPNs, special care has to be taken that 193 routes within the traditional VPN are not preferred over the Layer 3 194 VPN routes (the so-called "backdoor routing" problem, whose solution 195 requires protocol changes that are somewhat ad hoc). 197 1.2.3. Privacy of Routing 199 In a Layer 2 VPN, the privacy of customer routing is a natural 200 fallout of the fact that the Service Provider does not participate in 201 routing. The SP routers need not do anything special to keep 202 customer routes separate from other customers or from the Internet; 203 there is no need for per-VPN routing tables, and the additional 204 complexity this imposes on PE routers. 206 1.2.4. Layer 3 Independence 208 Since the Service Provider simply provides Layer 2 connectivity, the 209 customer can run any Layer 3 protocols they choose. If the SP were 210 participating in customer routing, it would be vital that the 211 customer and SP both use the same layer 3 protocol(s) and routing 212 protocols. 214 Note that IP-only layer 2 interworking doesn't have this benefit as 215 it restricts the layer 3 to IP only. 217 1.2.5. PE Scaling 219 In the Layer 2 VPN scheme described below, each PE transmits a single 220 small chunk of information about every CE that the PE is connected to 221 to every other PE. That means that each PE need only maintain a 222 single chunk of information from each CE in each VPN, and keep a 223 single "route" to every site in every VPN. This means that both the 224 Forwarding Information Base and the Routing Information Base scale 225 well with the number of sites and number of VPNs. Furthermore, the 226 scaling properties are independent of the customer: the only germane 227 quantity is the total number of VPN sites. 229 This is to be contrasted with Layer 3 VPNs, where each CE in a VPN 230 may have an arbitrary number of routes that need to be carried by the 231 SP. This leads to two issues. First, both the information stored at 232 each PE and the number of routes installed by the PE for a CE in a 233 VPN can be (in principle) unbounded, which means in practice that a 234 PE must restrict itself to installing routes associated with the VPNs 235 that it is currently a member of. Second, a CE can send a large 236 number of routes to its PE, which means that the PE must protect 237 itself against such a condition. Thus, the SP must enforce limits on 238 the number of routes accepted from a CE; this in turn requires the PE 239 router to offer such control. 241 The scaling issues of Layer 3 VPNs come into sharp focus at a BGP 242 route reflector (RR). An RR cannot keep all the advertised routes in 243 every VPN since the number of routes will be too large. The 244 following solutions/extensions are needed to address this issue: 246 1) RRs could be partitioned so that each RR services a subset of 247 VPNs so that no single RR has to carry all the routes. 248 2) An RR could use a preconfigured list of Route-Targets for its 249 inbound route filtering. The RR may also need to install 250 Outbound Route Filters [BGP-ORF] which contain the above list 251 of Route-Targets on each of its peers so that they do not send 252 unnecessary VPN routes. This method also requires significant 253 extensions along with the fact that multiple RRs are needed to 254 service different sets of VPNs. 256 1.2.6. Ease of Configuration 258 Configuring traditional Layer 2 VPNs was a burden primarily because 259 of the O(n*n) nature of the task. If there are n CEs in a Frame 260 Relay VPN, say full-mesh connected, n*(n-1)/2 DLCI PVCs must be 261 provisioned across the SP network. At each CE, (n-1) DLCIs must be 262 configured to reach each of the other CEs. Furthermore, when a new 263 CE is added, n new DLCI PVCs must be provisioned; also, each existing 264 CE must be updated with a new DLCI to reach the new CE. 266 In our proposal, PVCs are tunnelled across the SP network. The 267 tunnels used are provisioned independent of the L2VPNs, using 268 signalling protocols (in case of MPLS, LDP or RSVP-TE can be used), 269 or set up by configuration; and the number of tunnels is independent 270 of the number of L2VPNs. This reduces a large part of the 271 provisioning burden. 273 Furthermore, we assume that DLCIs at the CE edge are relatively 274 cheap; and VPN labels in the SP network are cheap. This allows the 275 SP to "over-provision" VPNs: for example, allocate 50 CEs to a VPN 276 when only 20 are needed. With this over-provisioning, adding a new 277 CE to a VPN requires configuring just the new CE and its associated 278 PE; existing CEs and their PEs need not be re-configured. Note that 279 if DLCIs at the CE edge are expensive, e.g. if these DLCIs are 280 provisioned across a switched network, one could provision them as 281 and when needed, at the expense of extra configuration. This need not 282 still result in extra state in the SP network, i.e. an intelligent 283 implementation can allow overprovisioning of the pool of VPN labels. 285 1.3. Advantages of Layer 3 VPNs 287 Layer 3 VPNs ([IPVPN] in particular) offer a good solution when the 288 customer traffic is wholly IP, customer routing is reasonably simple, 289 and the customer sites connect to the SP with a variety of Layer 2 290 technologies. 292 1.3.1. Layer 2 Independence 294 One major restriction in a Layer 2 VPN is that the Layer 2 medium 295 with which the various sites of a single VPN connect to the SP must 296 be uniform. On the other hand, the various sites of a Layer 3 VPN 297 can connect to the SP with any supported media; for example, some 298 sites may connect with Frame Relay circuits, and others with 299 Ethernet. 301 This restriction of layer 2 VPN is alleviated by the IP-only layer 2 302 interworking proposed in this document. This comes at the cost of 303 losing the layer 3 independence. 305 A corollary to this is that the number of sites that can be in a 306 Layer 2 VPN is determined by the number of Layer 2 circuits that the 307 Layer 2 technology provides. For example, if the Layer 2 technology 308 is Frame Relay with 2-octet DLCIs, a CE can connect to at most about 309 a thousand other CEs in a VPN. 311 1.3.2. SP Routing as Added Value 313 Another problem with Layer 2 VPNs is that the CE router in a VPN must 314 be able to deal with having N routing peers, where N is the number of 315 sites in the VPN. This can be alleviated by manipulating the 316 topology of the VPN. For example, a hub-and-spoke VPN architecture 317 means that only one CE router (the hub) needs to deal with N 318 neighbors. However, in a Layer 3 VPN, a CE router need only deal 319 with one neighbor, the PE router. Thus, the SP can offer Layer 3 320 VPNs as a value-added service to its customers. 322 Moreover, with layer 2 VPNs it is up to a customer to build and 323 operate the whole network. With Layer 3 VPNs, a customer is just 324 responsible for building and operating routing within each site, 325 which is likely to be much simpler than building and operating 326 routing for the whole VPN. That, in turn, makes Layer 3 VPNs more 327 suitable for customers who don't have sufficient routing expertise, 328 again allowing the SP to provide added value. 330 As mentioned later, multicast routing and forwarding is another 331 value-added service that an SP can offer. 333 1.3.3. Class-of-Service 335 Class-of-Service issues have been addressed for Layer 3 VPNs. Since 336 the PE router has visibility into the network layer (IP), the PE 337 router can take on the tasks of CoS classification and routing. This 338 restriction on layer 2 VPNs is again eased in the case of IP-only 339 layer 2 interworking, as the PE router has visibility into the 340 network layer (IP). 342 1.4. Multicast Routing 344 There are two aspects to multicast routing that we will consider. On 345 the protocol front, supporting IP multicast in a Layer 3 VPN requires 346 PE routers to participate in the multicast routing instance of the 347 customer, and thus keep some related state information. 349 In the Layer 2 VPN case, the CE routers run native multicast routing 350 directly. The SP network just provides pipes to connect the CE 351 routers; PEs are unaware whether the CEs run multicast or not, and 352 thus do not have to participate in multicast protocols or keep 353 multicast state information. 355 On the forwarding front, in a Layer 3 VPN, CE routers do not 356 replicate multicast packets; thus, the CE-PE link carries only one 357 copy of a multicast packet. Whether replication occurs at the 358 ingress PE, or somewhere within the SP network depends on the 359 sophistication of the Layer 3 VPN multicast solution. The simple 360 solution where a PE replicates packets for each of its CEs may place 361 considerable burden on the PE. More complex solutions may require 362 VPN multicast state in the SP network, but may significantly reduce 363 the traffic in the SP network by delaying packet replication until 364 needed. 366 In a Layer 2 VPN, packet replication occurs at the CE. This has the 367 advantage of distributing the burden of replication among the CEs 368 rather than focusing it on the PE to which they are attached, and 369 thus will scale better. However, the CE-PE link will need to carry 370 the multiple copies of multicast packets. 372 Thus, just as in the case of unicast routing, the SP has the choice 373 to offer a value-added service (multicast routing and forwarding) at 374 some cost (multicast state and packet replication) using a Layer 3 375 VPN, or to keep it simple and use a Layer 2 VPN. 377 2. Contributors 379 The following contributed to this document. 381 Manoj Leelanivas, Juniper Networks 382 Quaizar Vohra, Juniper Networks 383 Javier Achirica, Telefonica 384 Ronald Bonica, MCI 385 Dave Cooper, Global Crossing 386 Chris Liljenstolpe, C&W 387 Eduard Metz, KPN Dutch Telecom 388 Hamid Ould-Brahim, Nortel 389 Chandramouli Sargor, CoSine 390 Himanshu Shah, Ciena 391 Vijay Srinivasan, CoSine 392 Zhaohui Zhang, Juniper Networks 394 3. Operation of a Layer 2 VPN 396 The following simple example of a customer with 4 sites connected to 397 3 PE routers in a Service Provider network will hopefully illustrate 398 the various aspects of the operation of a Layer 2 VPN. For 399 simplicity, we assume that a full-mesh topology is desired. 401 In what follows, Frame Relay serves as the Layer 2 medium, and each 402 CE has multiple DLCIs to its PE, each to connect to another CE in the 403 VPN. If the Layer 2 medium were ATM, then each CE would have 404 multiple VPI/VCIs to connect to other CEs. For PPP and Cisco HDLC, 405 each CE would have multiple physical interfaces to connect to other 406 CEs. In the case of IP-only layer 2 interworking, each CE could have 407 a mix of one or more of the above layer 2 mediums to connect to other 408 CEs. 410 3.1. Network Topology 412 Consider a Service Provider network with edge routers PE0, PE1, and 413 PE2. Assume that PE0 and PE1 are IGP neighbors, and PE2 is more than 414 one hop away from PE0. 416 Suppose that a customer C has 4 sites S0, S1, S2 and S3 that C wants 417 to connect via the Service Provider's network using Frame Relay. 418 Site S0 has CE0 and CE1 both connected to PE0. Site S1 has CE2 419 connected to PE0. Site S2 has CE3 connected to PE1 and CE4 connected 420 to PE2. Site S3 has CE5 connected to PE2. (See the Figure 1 below.) 421 Suppose further that C wants to "over-provision" each current site, 422 in expectation that the number of sites will grow to at least 10 in 423 the near future. However, CE4 is only provisioned with 9 DLCIs. 425 (Note that the signalling mechanism discussed in section 7 will allow 426 a site to grow in terms of connectivity to other sites at a later 427 point of time at the cost of additional signalling, i.e., over- 428 provisioning is not a must but a recommendation). 430 Suppose finally that CE0 and CE2 have DLCIs 100 through 109 free; CE1 431 and CE3 have DLCIs 200 through 209 free; CE4 has DLCIs 107, 209, 265, 432 301, 414, 555, 654, 777 and 888 free; and CE5 has DLCIs 417-426. 434 3.2. Configuration 436 The following sub-sections detail the configuration that is needed to 437 provision the above VPN. For the purpose of exposition, we assume 438 that the customer will connect to the SP with Frame Relay circuits, 439 and that the customer's IGP of choice is OSPF. 441 While we focus primarily on the configuration that an SP has to do, 442 we touch upon the configuration requirements of CEs as well. The 443 main point of contact in CE-PE configuration is that both must agree 444 on the DLCIs that will be used on the interface connecting them. 446 If the PE-CE connection is Frame Relay, it is recommended to run LMI 447 between the PE and CE with the PE as DCE and the CE as DTE. For the 448 case of ATM VCs, OAM cells may be used; for PPP and Cisco HDLC, 449 keepalives may be used. The PPP and cisco hdlc keepalives could be 450 between local and remote CE if both CEs connect via the same layer 2 451 medium. 453 In case of IP-only layer 2 interworking, if CE1, attached to PE0, 454 connects to CE3, attached to PE1, via an L2VPN circuit, the layer 2 455 medium between CE1 and PE0 is independent of the layer 2 medium 456 between CE3 and PE1. Each side will run its own layer 2 specific 457 link management protocol, e.g., LMI, LCP, etc. PE0 will inform PE1 458 about the status of its local circuit to CE1 via the circuit status 459 vector TLV defined in section 7. Similarly PE1 will inform PE0 about 460 the status of its local circuit to CE3. 462 3.2.1. CE Configuration 464 Each CE that belongs to a VPN is given a "CE ID". CE IDs must be 465 unique in the context of a VPN. We assume that the CE ID for CE-k is 466 k. 468 Each CE is configured to communicate with its corresponding PE with 469 the set of DLCIs given above; for example, CE0 is configured with 470 DLCIs 100 through 109. OSPF is configured to run over each DLCI. In 471 general, a CE is configured with a list of circuits, all with the 473 Figure 1: Example Network Topology 475 S0 S3 476 .............. .............. 477 . . . . 478 . +-----+ . . . 479 . | CE0 |-----------+ . +-----+ . 480 . +-----+ . | . | CE5 | . 481 . . | . +--+--+ . 482 . +-----+ . | . | . 483 . | CE1 |-------+ | .......|...... 484 . +-----+ . | | / 485 . . | | / 486 .............. | | / 487 | | SP Network / 488 .....|...|.............................../..... 489 . | | / . 490 . +-+---+-+ +-------+ / . 491 . | PE0 |-------| P |-- | . 492 . +-+---+-+ +-------+ \ | . 493 . / \ \ +---+---+ . 494 . | -----+ --| PE2 | . 495 . | | +---+---+ . 496 . | +---+---+ / . 497 . | | PE1 | / . 498 . | +---+---+ / . 499 . | \ / . 500 ...|.............|.............../............. 501 | | / 502 | | / 503 | | / 504 S1 | | S2 / 505 .............. | ........|........../...... 506 . . | . | | . 507 . +-----+ . | . +--+--+ +--+--+ . 508 . | CE2 |-----+ . | CE3 | | CE4 | . 509 . +-----+ . . +-----+ +-----+ . 510 . . . . 511 .............. .......................... 513 same layer 2 encapsulation type, e.g., DLCIs, VCIs, physical PPP 514 interface etc. (IP-only layer 2 interworking allows a mix of layer 2 515 encapsulation types). The size of this list/set determines the 516 number of remote CEs a given CE can communicate with. Denote the 517 size of this list/set as the CE's range. 519 Each CE also "knows" which DLCI connects it to each other CE. A 520 simple algorithm is to use the CE ID of the other CE as an index into 521 the DLCI list this CE has (with zero-based indexing, i.e., 0 is the 522 first index). For example, CE0 is connected to CE3 through its 523 fourth DLCI, 103; CE4 is connected to CE2 by the third DLCI in its 524 list, namely 265. This is the methodology used in the examples 525 below; the actual methodology used to pick the DLCI to be used is a 526 local matter; the key factor is that CE-k may communicate with CE-m 527 using a different DLCI from the DLCI that CE-m uses to communicate to 528 CE-k, i.e., the SP network effectively acts as a giant Frame Relay 529 switch. This is very important, as it decouples the DLCIs used at 530 each CE site, making for much simpler provisioning. 532 3.2.2. PE Configuration 534 Each PE is configured with the VPNs in which it participates. Each 535 VPN is configured with a Route Target community [IPVPN] which 536 uniquely identifies the VPN within the SP network. For each VPN, the 537 PE has a list of CEs, which are members of that VPN. For each CE, 538 the PE knows the CE ID, its range and which DLCIs to expect from the 539 CE. 541 3.2.3. Adding a New Site 543 The first step in adding a new site to a VPN is to pick a new CE ID. 544 If all current members of the VPN are over-provisioned, i.e., their 545 range includes the new CE ID, adding the new site is a purely local 546 task. Otherwise, the sites whose range doesn't include the new CE ID 547 and wish to communicate directly with the new CE must have their 548 ranges increased by allocating additional local circuits to 549 incorporate the new CE ID. 551 The next step is ensuring that the new site has the required 552 connectivity (see below). This may require tweaking the connectivity 553 mechanism; however, in several common cases, the only configuration 554 needed is local to the PE to which the CE is attached. 556 The rest of the configuration is a local matter between the new CE 557 and the PE to which it is attached. 559 It bears repeating that the key to making additions easy is over- 560 provisioning and the algorithm for mapping a CE-id to a DLCI which is 561 used for connecting to the corresponding CE. However, what is being 562 over-provisioned is the number of DLCIs/VCIs that connect the CE to 563 the PE. This is a local matter, and generally is not an issue. 565 3.3. PE Information Exchange 567 When a PE is configured with all the needed information for a CE, it 568 first of all chooses a contiguous set of n labels, where n is the 569 CE's initial range. Denote a contiguous set of labels by a label- 570 block. Call the smallest label in this label-block the label-base 571 and the number of labels in the label-block as label-range. 573 To allow a CE to grow its connectivity at a later point of time 574 additional DLCIs might be added between the CE and its PE. To 575 advertise the additional capacity of a CE without disrupting existing 576 connectivity to the site, a new label-block is picked with k labels, 577 where k is the the number of additional circuits. This process might 578 be repeated several times as and when a CE's range needs growing. 580 The PE then advertises for this CE all its label-blocks. Each label- 581 block is propagated in a separate BGP NLRI (see figure 3). This is 582 the basic Layer 2 VPN advertisement. This same advertisement is sent 583 to all other PEs. Note that PEs that may not be part of the VPN can 584 receive and keep this information, in case at some future point, a CE 585 connected to the PE joins the VPN. 587 So as to be able to distinguish between the multiple label-blocks of 588 a given CE, notion of a block offset is introduced. The block offset 589 identifies the position of a given label-block in the set of label 590 blocks of a given CE. A remote site with CE ID m will connect to 591 this CE using a label selected from one of the label blocks such that 592 the following condition holds true for that label-block : 594 block offset <= m < block offset + label-range 596 If the PE-CE physical link goes down, or the CE configuration is 597 removed, all its advertised label-blocks are withdrawn. 599 Note that an implementation can easily allow allocation of a label- 600 block which is larger than the actual number of DLCIs provisioned. 601 This allows DLCIs to be provisioned as and when needed without 602 increasing the state in the network, at the cost of extra signalling 603 and configuration. 605 3.3.1. PE Advertisement Processing 607 When a PE receives a Layer 2 VPN advertisement, it checks if the 608 received Route Target community matches any VPN that it is a member 609 of. If not, the PE may store the advertisement for future use, or 610 may discard it. Since we use BGP as the auto-discovery and 611 signalling protocol, a PE can use the BGP Route Refresh capability to 612 learn all the discarded advertisements pertaining to a VPN at a later 613 time, when the VPN is configured on the PE. 615 Otherwise, suppose the advertisement is from PE A for VPN X, CE m, 616 and a label-block Lm. Add this label-block to the existing label- 617 blocks for CE m in VPN X. For the purpose of further discussion we 618 denote a label-block from CE m as Lm. Denote Lm's block offset as 619 LOm, label-base as LBm, and label-range as LRm. 621 For each CE that the receiving PE B is connected to that is a member 622 of VPN X, PE B does the following. 624 0) Look up the configuration information associated with the CE. 625 If the encapsulation type for VPN X in the advertisement does 626 not match the configured encapsulation type for VPN X, stop. 627 (Note that for IP-only layer 2 interworking a separate 628 encapsulation type is defined). 629 1) Say the configured CE ID is k, and the DLCI list is Dk[]. 630 A label-block of k is denoted by Lk. Denote Lk's block offset 631 as LOk, label-base as LBk, and label-range as LRk. 632 2) Check if k = m. If so, issue an error: "CE ID k has been 633 allocated to two CEs in VPN X (check CE at PE A)". Stop. 634 3) Search among all the label-blocks from m for one which 635 satisfies LOm <= k < LOm + LRm. If none found, issue a 636 warning : "Cannot communicate with CE m (PE A) of VPN X: 637 outside range" and stop. Otherwise let Lm be the label-block 638 found. 639 4) Search among all the label-blocks of k for one which 640 satisfies LOk <= m < LOk + LRk. If none found, issue a 641 warning : "Cannot communicate with CE m (PE A) of VPN X: 642 outside range" and stop. Otherwise let Lk be the label-block 643 found. 644 5) Look in the appropriate table to see which label-stack will 645 get to PE A. This is the "tunnel" label-stack, Z. 646 6) The DLCI that CE-k will use to talk to CE-m is Dk[m]. Then 647 "VPN" label for sending packets to CE-m is (LBm + k - LOm) if 648 The "VPN" label on which to expect packets from CE-m is 649 (LBk + m - LOk). 650 7) Install a "route" such that packets from CE-k with DLCI Dk[m] 651 will be sent with tunnel label-stack Z, VPN label 652 (LBm + k - LOm). Also, install a route such that packets 653 received with label (LBk + m - LOk) will be mapped to DLCI 654 Dk[m] and be sent to CE k. 655 8) Activate DLCI Dk[m] to the CE. This can be done using LMI. 657 If an advertisement is withdrawn, the appropriate DLCIs must be de- 658 activated, and the corresponding routes must be removed from the 659 forwarding table. 661 3.3.2. Example of PE Advertisement Processing 663 Consider the example network of Figure 1. Let S0, S1, S2 and S3 664 belong to the same VPN, say VPN1. Suppose PE2 receives an 665 advertisement from PE0 for VPN1, CE ID 0 and a label block L0 with 666 block offset LO0 = 0, label-range LR0 = 10 and label base LB0 = 1000. 667 Since PE2 is connected to CE4 which is also in VPN1, PE2 does the 668 following: 670 0) Look up the configuration information associated with CE4. 671 The advertised encapsulation type matches the configured 672 encapsulation type (both are Frame Relay), so proceed. 673 1) CE4 is configured with DLCI list D4[] is [ 107, 209, 265, 674 301, 414, 555, 654, 777, 888]. A label-block L4 is allocated 675 to CE4 with block offset LO4 = 0, label-range LR4 = 9 and 676 a label-base LB4 = 4000 677 2) CE0 and CE4 have ids 0 and 4 respectively, so step 2 of 4.3.1 678 is skipped. 679 3) Since CE4's id falls in the label-block L0 from CE0, i.e. 680 LO0 <= 4 < LO0 + LR0, L0 is the label-block selected in step 3 681 of 4.3.1 682 4) Since CE0's id falls in the label-block L4 of CE4, i.e. 683 LO4 <= 0 < LO4 + LR4, L4 is the label-block selected in step 4 684 of 4.3.1 685 5) Look in the appropriate table on PE2 to see which tunnel 686 label-stack will get to PE0. Let the label-stack be a single 687 label, 10001. 688 6) The DLCI that CE4 will use to talk to CE0 is D4[0], i.e., 107. 689 The VPN label for sending packets to CE0 is (LB0 + 4 - LO0), 690 i.e 1004. The VPN label on which to expect packets from CE0 691 is (LB4 + 0 - LO4), i.e., 4000. 692 7) Install a "route" such that packets from CE4 with DLCI 107 693 will be sent with top label 10001, VPN label 1004. Also, 694 install a route such that packets received with label 4000 will 695 be mapped to DLCI 107 and be sent to CE4. 696 8) Activate DLCI 107 to CE4. 698 Since CE5 is also attached to PE2, PE2 needs to do processing similar 699 to the above for CE5. 701 Similarly, when PE0 receives an advertisement from PE2 for VPN1, CE4, 702 with and a label block L4 with block offset LO4 = 0, label-range LR4 703 = 9 and label base LB4 = 4000. PE0 processes the advertisement for 704 CE0 (and CE1, which is also in VPN1). 706 0) Look up the configuration information associated with CE0. 707 The advertised encapsulation type matches the configured 708 encapsulation type (both are Frame Relay), so proceed. 710 1) CE0 is configured with a DLCI list D0[] is [100 - 109], 711 Label-block L0 is allocated to CE0 with block offset LO0 = 0, 712 label-range LR0 = 10 and a label-base LB0 = 1000 (which 713 was advertised to PE2) 714 2) CE0 and CE4 have ids 0 and 4 respectively, so step 2 of 4.3.1 715 is skipped. 716 3) Since CE0's id falls in the label-block L4 of CE4, i.e. 717 LO4 <= 0 < LO4 + LR4, L4 is the label-block selected in step 4 718 of 4.3.1 719 4) Since CE4's id falls in the label-block L0 from CE0, i.e. 720 LO0 <= 4 < LO0 + LR0, L0 is the label-block selected in step 3 721 of 4.3.1 722 5) Let the tunnel label-stack to reach PE2 be a single label, 723 9999. 724 6) The DLCI which CE0 will use to talk to CE4 is D0[4], i.e., 104. 725 The VPN label for sending packets to CE4 is (LB4 + 0 - LO4), 726 i.e., 4000. The VPN label on which to expect packets from CE4 727 is (LB0 + 4 - LO4), i.e., 1004. 728 7) Install a "route" such that packets from CE0 with DLCI 104 729 will be sent with top label 9999, VPN label 4000. Also, 730 install a route that packets received with label 1004 will be 731 mapped to DLCI 104 and be sent to CE0. 732 8) Activate DLCI 104 to CE0. 734 Note that the VPN label of 4000, computed by PE0, for sending packets 735 from CE0 to CE4 is the same as what PE2 computed as the incoming 736 label for receiving packets originated at CE0 and destined to CE4. 737 Similarly, the VPN label of 1004, computed by PE0, for receiving 738 packets from CE4 to CE0 is same as what PE2 computed as the outgoing 739 label for sending packets originated at CE4 and destined to CE0. 741 3.3.3. Generalizing the VPN Topology 743 In the above, we assumed for simplicity that the VPN was a full mesh. 744 To allow for more general VPN topologies, a mechanism based on 745 filtering on BGP extended communities can be used (see section 7). 747 4. Layer 2 Interworking 749 As defined so far in this document, all CE-PE connections for a given 750 Layer 2 VPN must use the same layer 2 encapsulation, e.g., they must 751 all be Frame Relay. This is often a burdensome restriction. One 752 answer is to use an existing Layer 2 interworking mechanism, for 753 example, Frame Relay-ATM interworking. 755 In this document, we take a different approach: we postulate that the 756 network layer is IP, and base Layer 2 interworking on that. Thus, 757 one can choose between pure Layer 2 VPNs, with a stringent Layer 2 758 restriction but with Layer 3 independence, or a Layer 2 interworking 759 VPNs, where there is no restriction on Layer 2, but Layer 3 must be 760 IP. Of course, a PE may choose to implement Frame Relay-ATM 761 interworking. For example, an ATM Layer 2 VPN could have some CEs 762 connect via Frame Relay links, if their PE could translate Frame 763 Relay to ATM transparent to the rest of the VPN. This would be 764 private to the CE-PE connection, and such a course is outside the 765 scope of this document. 767 For Layer 2 interworking as defined here, when an IP packet arrives 768 at a PE, its Layer 2 address is noted, then all Layer 2 overhead is 769 stripped, leaving just the IP packet. Then, a VPN label is added, 770 and the packet is encapsulated in the PE-PE tunnel (as required by 771 the tunnel technology). Finally, the packet is forwarded. Note that 772 the forwarding decision is made on the basis of the Layer 2 773 information, not the IP header. At the egress, the VPN label 774 determines to which CE the packet must be sent, and over which 775 virtual circuit; from this, the egress PE can also determine the 776 Layer 2 encapsulation to place on the packet once the VPN label is 777 stripped. 779 An added benefit of restricting interworking to IP only as the layer 780 3 technology is that the provider's network can provide IP Diffserv 781 or any other IP based QOS mechanism to the L2VPN customer. The 782 ingress PE can set up IP/TCP/UDP based classifiers to do DiffServ 783 marking, and other functions like policing and shaping on the L2 784 circuits of the VPN customer. Note the division of labor: the CE 785 determines the destination CE, and encodes that in the Layer 2 786 address. The ingress PE thus determines the egress PE and VPN label 787 based on the Layer 2 address supplied by the CE, but the ingress PE 788 can choose the tunnel to reach the egress PE (in the case that there 789 are different tunnels for each CoS/DiffServ code point), or the CoS 790 bits to place in the tunnel (in the case where a single tunnel 791 carries multiple CoS/DiffServ code points) based on its own 792 classification of the packet. 794 5. Packet Transport 796 When a packet arrives at a PE from a CE in a Layer 2 VPN, the layer 2 797 address of the packet identifies to which other CE the packet is 798 destined. The procedure outlined above installs a route that maps 799 the layer 2 address to a tunnel (which identifies the PE to which the 800 destination CE is attached) and a VPN label (which identifies the 801 destination CE). If the egress PE is the same as the ingress PE, no 802 tunnel or VPN label is needed. 804 The packet may then be modified (depending on the layer 2 805 encapsulation). In case of IP-only layer 2 interworking, the layer 2 806 header is completely stripped off till the IP header. Then, a VPN 807 label and tunnel encapsulation are added as specified by the route 808 described above, and the packet is sent to the egress PE. 810 If the egress PE is the same as the ingress, the packet "arrives" 811 with no labels. Otherwise, the packet arrives with the VPN label, 812 which is used to determine which CE is the destination CE. The 813 packet is restored to a fully-formed layer 2 packet, and then sent to 814 the CE. 816 5.1. Layer 2 MTU 818 This document requires that the Layer 2 MTU configured on all the 819 access circuits connecting CEs to PEs in an L2VPN be the same. This 820 can be ensured by passing the configured layer 2 MTU in the 821 Layer2-info extended community when advertising L2VPN label-blocks. 822 On receiving L2VPN label-block from remote PEs in a VPN, the MTU 823 value carried in the layer2-info extendend community should be 824 compared against the configured value for the VPN. If they don't 825 match, then the label-block should be ignored. 827 The MTU on the Layer 2 access links MUST be chosen such that the size 828 of the L2 frames plus the L2VPN header does not exceed the MTU of the 829 SP network. Layer 2 frames that exceed the MTU after encapsulation 830 MUST be dropped. For the case of IP-only layer 2 interworking the IP 831 MTU on the layer 2 access link must be chosen such that the size of 832 the IP packet and the L2VPN header does not exceed the MTU of the SP 833 network. 835 5.2. Layer 2 Frame Format 837 The modification to the Layer 2 frame depends on the Layer 2 type. 838 This document requires that the encapsulation methods used in 839 transporting of layer 2 frames over tunnels be the same as described 840 in [L2-ENCAP], except in the case of IP-only Layer 2 Interworking 841 which is described in section 6.2. 843 5.3. IP-only Layer 2 Interworking 845 Figure 2: Format of IP-only layer 2 interworking packet 847 +----------------------------+ 848 | Tunnel | VPN | IP | VPN label is the 849 | Encap | Label | Packet | demultiplexing field 850 +----------------------------+ 852 At the ingress PE, an L2 frame's L2 header is completely stripped off 853 and is carried over as an IP packet within the SP network (Figure 2). 854 The forwarding decision is still based on the L2 address of the 855 incoming L2 frame. At the egress PE, the IP packet is encapsulated 856 back in an L2 frame and transported over to the destination CE. The 857 forwarding decision at the egress PE is based on the VPN label as 858 before. The L2 technology between egress PE and CE is independent of 859 the L2 technology between ingress PE and CE. 861 6. Auto-discovery and Signalling of Layer 2 VPNs 863 BGP version 4 ([BGP]) is used as the auto-discovery and signalling 864 protocol for Layer 2 VPNs described in this document. 866 In BGP, the Multiprotocol Extensions [BGP-MP] are used to carry 867 L2-VPN signalling information. [BGP-MP] defines the format of two 868 BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used 869 to announce and withdraw the announcement of reachability 870 information. We introduce a new address family identifier (AFI) for 871 L2-VPN [to be assigned by IANA], a new subsequent address family 872 identifier (SAFI) [to be assigned by IANA], and also a new NLRI 873 format for carrying the individual L2-VPN label-block information. 874 One or more NLRIs will be carried in the above-mentioned BGP 875 attributes. L2VPN NLRIs MUST be accompanied by one or more extended 876 communities. This document proposes the reuse of ROUTE TARGET 877 extended community defined in [EXT-COMM]. Its usage is exactly the 878 same as in the case of [INETVPN]. 880 PEs receiving VPN information may filter advertisements based on the 881 extended communities, thus controlling CE-to-CE connectivity. 883 The format of the Layer 2 VPN NLRI is as shown in Figure 3 below. 884 One or more such NLRIs can be carried in a single MP_REACH_NLRI or 885 MP_REACH_NLRI attribute. An L2VPN NLRI is uniquely identified by the 886 RD, CE ID and the Label-block Offset. So an L2VPN NLRI carried in 887 MP_UNREACH_NLRI attribute must contain only these 3 fields other than 888 the length field. 890 Figure 3: BGP NLRI for L2 VPN Information 892 +------------------------------------+ 893 | Length (2 octets) | 894 +------------------------------------+ 895 | Route Distinguisher (8 octets) | 896 +------------------------------------+ 897 | CE ID (2 octets) | 898 +------------------------------------+ 899 | Label-block Offset (2 octets) | 900 +------------------------------------+ 901 | Label Base (3 octets) | 902 +------------------------------------+ 903 | Variable TLVs (0 to N octets) | 904 | ... | 905 +------------------------------------+ 907 6.1. L2VPN NLRI Format 909 6.1.1. Length 911 The Length field indicates the length in octets of the L2-VPN address 912 information. 914 6.1.2. Route Distinguisher 916 Has the same meaning as in [IPVPN]. 918 6.1.3. CE ID 920 A 16 bit number which uniquely identifies a CE in a VPN. 922 6.1.4. Label-Block Offset 924 A 16 bit number which identifies the position of a label-block within 925 a set of label-blocks of a given CE. This enables a remote CE to 926 select a label block when picking the VPN label for sending traffic 927 destined to the CE this label-block corresponds to, such that : 929 label-block offset <= remote CE id. 931 6.1.5. Label base 933 The label-base which is to be used for determining the VPN label for 934 forwarding packets to the CE identified by CE ID 936 6.1.6. Sub-TLVs 938 New sub-TLVs can be introduced as needed. 940 L2VPN TLVs can be added to extend the information carried in the L2 941 VPN NLRI. In L2VPN TLVs, type is 1 octet, length is 2 octets and 942 represents the size of the value field in bits. 944 6.1.7. Circuit Status Vector 946 A new sub-TLV is introduced to carry the status of an L2VPN PVC 947 between a pair of PEs. This sub-TLV is a mandatory part of 948 MP_REACH_NLRI. 950 Note that an L2VPN PVC is bidirectional, composed of two simplex 951 connection going in opposite directions. A simplex connection 952 consists of the 3 segments: 1) the local access circuit between the 953 source CE and the ingress PE, 2) the tunnel LSP between the ingress 954 and egress PEs, and 3) the access circuit between the egress PE and 955 the destination CE. 957 To monitor the status of a PVC, a PE needs to monitor the status of 958 both simplex connections. Since it knows that status of its access 959 circuit, and the status of the tunnel towards the remote PE, it can 960 inform the remote PE of these two. Similarly, the remote PE can 961 inform the status of its access circuit to its local CE and the 962 status of the tunnel to the first PE. Combining the local and the 963 remote information, a PE can determine the status of a PVC. 965 The basic unit of advertisement in L2VPN for a given CE is a label- 966 block. Each label within a label-block corresponds to a PVC on the 967 CE. So its natural to advertise the local status information for all 968 PVCs corresponding to a label-block along with the label-block's 969 NLRI. This is done by introducing the circuit status vector TLV. 970 The value field of this TLV is a bit-vector, each bit of which 971 indicates the status of the PVC associated with the corresponding 972 label in the label-block. Bit value 0 indicates that the local 973 circuit and the tunnel LSP to the remote PE is up, while a value of 1 974 indicates that either or both of them are down. 976 PE A, while selecting a label from a label-block (advertised by PE B, 977 for remote CE m, and VPN X) for one of its local CE n (in VPN X) can 978 also determine the status of the corresponding PVC (between CE n and 979 CE m) by looking at the appropriate bit in the circuit status vector. 981 Type field for the circuit status vector TLV is TBD. 983 The length field of the TLV specifies the length of the value field 984 in bits. The value field is padded to the nearest octet boundary. 986 Note that the length field corresponds to the number of labels in the 987 label-block, i.e., the label-block range. Label-block range enables 988 a CE to select a label block (among several label-blocks advertised 989 by a CE) when picking the VPN label for sending traffic destined to 990 the CE this label-block corresponds to, such that : 992 received label-block offset <= local CE id < received label-block range. 994 6.2. Layer2-Info Extended Community 996 This document introduces a new extended community, Layer2-Info, to 997 allow carrying layer 2 specific information in a VPN. This extended 998 community MUST be carried as part of path attribute in all BGP update 999 messages carrying L2VPN NLRIs. The encoding of this community is 1000 shown in figure 4. 1002 Figure 4: layer2-info extended community 1004 +------------------------------------+ 1005 | Extended community type (2 octets) | 1006 +------------------------------------+ 1007 | Encaps Type (1 octet) | 1008 +------------------------------------+ 1009 | Cntrl Flags (1 octet) | 1010 +------------------------------------+ 1011 | Layer-2 MTU (2 octet) | 1012 +------------------------------------+ 1013 | Reserved (2 octets) | 1014 +------------------------------------+ 1016 6.2.1. Extended Community Type 1018 TBD. 1020 6.2.2. Encapsulation Type 1022 Identifies the layer 2 encapsulation, e.g., ATM, Frame Relay etc. 1023 The following encapsulation types are defined: 1025 Value Encapsulation 1026 0 Reserved 1027 1 Frame Relay 1028 2 ATM AAL5 VCC transport 1029 3 ATM transparent cell transport 1030 4 Ethernet VLAN 1031 5 Ethernet 1032 6 Cisco-HDLC 1033 7 PPP 1034 8 CEM [8] 1035 9 ATM VCC cell transport 1036 10 ATM VPC cell transport 1037 11 MPLS 1038 12 VPLS 1039 64 IP-interworking 1041 6.2.3. Control Flags 1043 This is a bit vector, defined as in Figure 5. 1045 Figure 5: Control Flags Bit Vector 1047 0 1 2 3 4 5 6 7 1048 +-+-+-+-+-+-+-+-+ 1049 | MBZ |Q|F|C|S| (MBZ = MUST Be Zero) 1050 +-+-+-+-+-+-+-+-+ 1052 The following bits are defined; the MBZ bits MUST be set to zero. 1054 Name Meaning 1055 C If set to 1(0), Control word is (not) required when 1056 encapsulating Layer 2 frames [L2-ENCAP]. 1057 S If set to 1(0), Sequenced delivery of frames is (not) 1058 required. 1060 The Q and F flags are reserved for other use. 1062 6.2.4. Layer-2 MTU 1064 Specifies the layer-2 specific MTU of all the circuits in all the 1065 label-blocks advertised with this extended community. This allows 1066 for checking of the layer 2 MTU being same for all the circuits 1067 across all the sites in a VPN. 1069 6.3. BGP L2 VPN capability 1071 The BGP Multiprotocol capability extension [BGP-CAP] is used to 1072 indicate that the BGP speaker wants to negotiate L2 VPN capability 1073 with its peers. The capability code is 1, the capability length is 1074 4, and the AFI and SAFI values will be set to the L2 VPN AFI and L2 1075 VPN SAFI (discussed in seccion 7) respectively. 1077 6.4. Advantages of Using BGP 1079 PE routers in an SP network typically run BGP v4. This means that 1080 SPs are familiar with using BGP, and have already configured BGP on 1081 their PEs, so configuring and using BGP to signal Layer 2 VPNs is not 1082 much of an additional burden to the SP operators. 1084 Another advantage of using BGP is that with BGP it is easier to build 1085 inter-provider VPNs. Mechanisms for this are similar as that 1086 described in [IPVPN]. Option a) and b) described there could be 1087 adapted with slight modification for the l2vpn case but have adverse 1088 scaling issue in the l2vpn context. So we recommend using option C) 1089 which in l2vpn context would require an ASBR to maintain labeled IPv4 1090 /32 routes to PEs within its AS and use EBGP to distribute these 1091 routes to other ASes. This results in creation of an LSP from a PE in 1092 one AS to another PE in another AS. Now these PEs can run multihop 1093 EBGP to exchange L2VPN information. The L2VPN traffic will be 1094 tunnelled thru the inter-AS LSP established between PEs as described 1095 above. 1097 7. Acknowledgments 1099 The authors would like to thank Chaitanya Kodeboyina Dennis Ferguson, 1100 Der-Hwa Gan, Dave Katz, Nischal Sheth, John Stewart, and Paul Traina 1101 for the enlightening discussions that helped shape the ideas 1102 presented here, and Ross Callon for his valuable comments. 1104 The idea of using extended communities for more general connectivity 1105 of a Layer 2 VPN was a contribution by Yakov Rekhter, who also gave 1106 many useful comments on the text; many thanks to him. 1108 8. Security Considerations 1110 The security aspects of this solution will be discussed at a later 1111 time. 1113 9. IANA Considerations 1115 (To be filled in in a later revision.) 1117 10. Normative References 1119 [BGP] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", 1120 RFC 1771, March 1995. 1122 [BGP-CAP] Chandra, R., and Scudder, J., "Capabilities Advertisement 1123 with BGP-4", RFC 2842, May 2000. 1125 [BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and Katz, D., 1126 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000 1128 [BGP-ORF] Chen, E., and Rekhter, Y., "Cooperative Route Filtering 1129 Capability for BGP-4", March 2000 (work in progress). 1131 [BGP-RFSH] Chen, E., "Route Refresh Capability for BGP-4", RFC2918, 1132 September 2000. 1134 [EXT-COMM] Ramachandra, S., Tappan, D.,Rekhtar, Y., "BGP Extended 1135 Communities Attribute" (work in progress). 1137 [L2-ENCAP] Martini, et. al., "Encapsulation Methods for Transport of 1138 Layer 2 Frames Over MPLS", November 2001 (work in progress). 1140 11. Informative References 1142 [IPVPN] Rosen, E., and Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March 1143 1999. 1145 [IPVPN-MCAST] Rosen, et. al., "Multicast in MPLS/BGP VPNs", November 1146 2000 (work in progress). 1148 [MPLS] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1149 Label Switching Architecture", RFC 3031, January 2001. 1151 [VPN] Kosiur, Dave, "Building and Managing Virtual Private Networks", 1152 Wiley Computer Publishing, 1998. 1154 Editor's Address 1156 Kireeti Kompella 1157 Juniper Networks 1158 1194 N. Mathilda Ave 1159 Sunnyvale, CA 94089 1160 kireeti@juniper.net 1162 IPR Notice 1164 The IETF takes no position regarding the validity or scope of any 1165 intellectual property or other rights that might be claimed to 1166 pertain to the implementation or use of the technology described in 1167 this document or the extent to which any license under such rights 1168 might or might not be available; neither does it represent that it 1169 has made any effort to identify any such rights. Information on the 1170 IETF's procedures with respect to rights in standards-track and 1171 standards-related documentation can be found in BCP-11. Copies of 1172 claims of rights made available for publication and any assurances of 1173 licenses to be made available, or the result of an attempt made to 1174 obtain a general license or permission for the use of such 1175 proprietary rights by implementors or users of this specification can 1176 be obtained from the IETF Secretariat. 1178 The IETF invites any interested party to bring to its attention any 1179 copyrights, patents or patent applications, or other proprietary 1180 rights which may cover technology that may be required to practice 1181 this standard. Please address the information to the IETF Executive 1182 Director. 1184 Full Copyright Statement 1186 Copyright (C) The Internet Society (2004). All Rights Reserved. 1188 This document and translations of it may be copied and furnished to 1189 others, and derivative works that comment on or otherwise explain it 1190 or assist in its implementation may be prepared, copied, published 1191 and distributed, in whole or in part, without restriction of any 1192 kind, provided that the above copyright notice and this paragraph are 1193 included on all such copies and derivative works. However, this 1194 document itself may not be modified in any way, such as by removing 1195 the copyright notice or references to the Internet Society or other 1196 Internet organizations, except as needed for the purpose of 1197 developing Internet standards in which case the procedures for 1198 copyrights defined in the Internet Standards process must be 1199 followed, or as required to translate it into languages other than 1200 English. 1202 The limited permissions granted above are perpetual and will not be 1203 revoked by the Internet Society or its successors or assignees. 1205 This document and the information contained herein is provided on an 1206 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1207 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1208 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1209 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1210 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.