idnits 2.17.1 draft-ietf-l2vpn-vpls-bgp-05.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 999. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 976. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 983. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 989. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 2 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 -- 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 (April 8, 2005) is 6957 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: '5' is defined on line 897, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2385 (ref. '2') (Obsoleted by RFC 5925) == Outdated reference: A later version (-10) exists of draft-ietf-idr-rfc2858bis-06 == Outdated reference: A later version (-09) exists of draft-ietf-idr-bgp-ext-communities-08 == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-ethernet-encap-09 == Outdated reference: A later version (-09) exists of draft-ietf-l2vpn-vpls-ldp-06 == Outdated reference: A later version (-09) exists of draft-ietf-l3vpn-bgpvpn-auto-05 == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-16 == Outdated reference: A later version (-10) exists of draft-kompella-l2vpn-l2vpn-00 Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella, Ed. 3 Internet-Draft Y. Rekhter, Ed. 4 Expires: October 10, 2005 Juniper Networks 5 April 8, 2005 7 Virtual Private LAN Service 8 draft-ietf-l2vpn-vpls-bgp-05 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 10, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 Virtual Private LAN Service (VPLS), also known as Transparent LAN 42 Service, and Virtual Private Switched Network service, is a useful 43 Service Provider offering. The service offers a Layer 2 Virtual 44 Private Network (VPN); however, in the case of VPLS, the customers in 45 the VPN are connected by a multipoint network, in contrast to the 46 usual Layer 2 VPNs, which are point-to-point in nature. 48 This document describes the functions required to offer VPLS, a 49 mechanism for signaling a VPLS, and rules for forwarding VPLS frames 50 across a packet switched network. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1 Scope of this Document . . . . . . . . . . . . . . . . . . 3 56 1.2 Conventions used in this document . . . . . . . . . . . . 4 57 1.3 Changes from version 04 to 05 . . . . . . . . . . . . . . 4 58 1.4 Changes from version 03 to 04 . . . . . . . . . . . . . . 5 59 2. Functional Model . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.3 Interactions . . . . . . . . . . . . . . . . . . . . . . . 7 63 3. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.1 Autodiscovery . . . . . . . . . . . . . . . . . . . . . . 9 65 3.1.1 Functions . . . . . . . . . . . . . . . . . . . . . . 9 66 3.1.2 Protocol Specification . . . . . . . . . . . . . . . . 10 67 3.2 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 10 68 3.2.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . 10 69 3.2.2 PW Setup and Teardown . . . . . . . . . . . . . . . . 11 70 3.2.3 Signaling PE Capabilities . . . . . . . . . . . . . . 12 71 3.3 BGP VPLS Operation . . . . . . . . . . . . . . . . . . . . 13 72 3.4 Multi-AS VPLS . . . . . . . . . . . . . . . . . . . . . . 14 73 3.4.1 a) VPLS-to-VPLS connections at the AS border 74 routers. . . . . . . . . . . . . . . . . . . . . . . . 15 75 3.4.2 b) EBGP redistribution of VPLS information between 76 ASBRs. . . . . . . . . . . . . . . . . . . . . . . . . 15 77 3.4.3 c) Multi-hop EBGP redistribution of VPLS 78 information between ASes. . . . . . . . . . . . . . . 16 79 3.4.4 Allocation of VE IDs Across Multiple ASes . . . . . . 17 80 3.5 Multi-homing and Path Selection . . . . . . . . . . . . . 17 81 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 4.1 Encapsulation . . . . . . . . . . . . . . . . . . . . . . 19 83 4.2 Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 19 84 4.2.1 MAC address learning . . . . . . . . . . . . . . . . . 19 85 4.2.2 Flooding . . . . . . . . . . . . . . . . . . . . . . . 19 86 4.2.3 "Split Horizon" Forwarding . . . . . . . . . . . . . . 20 87 5. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 21 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 91 8.1 Normative References . . . . . . . . . . . . . . . . . . . 24 92 8.2 Informative References . . . . . . . . . . . . . . . . . . 24 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 94 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 95 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 96 Intellectual Property and Copyright Statements . . . . . . . . 28 98 1. Introduction 100 Virtual Private LAN Service (VPLS), also known as Transparent LAN 101 Service, and Virtual Private Switched Network service, is a useful 102 service offering. A Virtual Private LAN appears in (almost) all 103 respects as a LAN to customers of a Service Provider. However, in a 104 VPLS, the customers are not all connected to a single LAN; the 105 customers may be spread across a metro or wide area. In essence, a 106 VPLS glues several individual LANs across a packet-switched network 107 to appear and function as a single LAN ([6]). 109 This document describes the functions needed to offer VPLS, and goes 110 on to describe a mechanism for signaling a VPLS, as well as a 111 mechanism for transport of VPLS frames over tunnels across a packet 112 switched network. The signaling mechanism uses BGP as the control 113 plane protocol. This document also briefly discusses deployment 114 options, in particular, the notion of decoupling functions across 115 devices. 117 Alternative approaches include: [11], which allows one to build a 118 Layer 2 VPN with Ethernet as the interconnect; and [10]), which 119 allows one to set up an Ethernet connection across a packet-switched 120 network. Both of these, however, offer point-to-point Ethernet 121 services. What distinguishes VPLS from the above two is that a VPLS 122 offers a multipoint service. A mechanism for setting up pseudowires 123 for VPLS using the Label Distribution Protocol (LDP) is defined in 124 [7]. 126 1.1 Scope of this Document 128 This document has four major parts: defining a VPLS functional model; 129 defining a control plane for setting up VPLS; defining the data plane 130 for VPLS (encapsulation and forwarding of data); and defining various 131 deployment options. 133 The functional model underlying VPLS is laid out in Section 2. This 134 describes the service being offered, the network components that 135 interact to provide the service, and at a high level their 136 interactions. 138 The control plane described in this document uses Multiprotocol BGP 139 [3] to establish VPLS service, i.e., for the autodiscovery of VPLS 140 members and for the setup and teardown of the pseudowires that 141 constitute a given VPLS instance. Section 3 focuses on this, and 142 also describes how a VPLS that spans Autonomous System boundaries is 143 set up, as well as how multi-homing is handled. Using BGP as the 144 control plane for VPNs is not new (see [11], [9] and [8]): what is 145 described here is based on the mechanisms proposed in [9]. 147 The forwarding plane and the actions that a participating PE must 148 take is described in Section 4. 150 In Section 5, the notion of 'decoupled' operation is defined, and the 151 interaction of decoupled and non-decoupled PEs is described. 152 Decoupling allows for more flexible deployment of VPLS. 154 1.2 Conventions used in this document 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 ([1]). 160 1.3 Changes from version 04 to 05 162 [NOTE to RFC Editor: this section is to be removed before 163 publication.] 165 Updated IANA section to reflect agreement with authors of [8] that 166 the two docs should use the same AFI for L2VPN information. 168 Addressed comments received from Alex Zinin. No technical changes, 169 but a more complete description to cover the issues that Alex raised: 171 1. encoding of BGP NEXT_HOP for the new AFI/SAFI is not described 173 2. VE ID, Block offset, Block size, Label base are not described 174 anywhere 176 3. no information on how the receiving PE choose the PW label 178 4. section 3.2.2 talks about PE capabilities all of a sudden and 179 introduces a L2 Info Community, whose fields and use are not 180 described 182 Changes to address these: 184 1. Broke up section 3.2.1 into "Concepts" and "PW Setup". 186 2. Expanded section on "Signaling PE Capabilities". 188 3. Added a new section 3.3 "BGP VPLS Operation". 190 4. Minor tweaking, e.g. to fix section number references. 192 1.4 Changes from version 03 to 04 194 [NOTE to RFC Editor: this section is to be removed before 195 publication.] 197 Incorporated IDR review comments from Eric Ji, Chaitanya Kodeboyina, 198 and Mike Loomis. Most changes are clarifications and rewording for 199 better readability. The substantive changes are to remove several 200 flags from the control field. 202 2. Functional Model 204 This will be described with reference to the following figure. 206 ----- 207 / A1 \ 208 ---- ____CE1 | 209 / \ -------- -------- / | | 210 | A2 CE2- / \ / PE1 \ / 211 \ / \ / \___/ | \ ----- 212 ---- ---PE2 | \ 213 | | \ ----- 214 | Service Provider Network | \ / \ 215 | | CE5 A5 | 216 | ___ | / \ / 217 |----| \ / \ PE4_/ ----- 218 |u-PE|--PE3 / \ / 219 |----| -------- ------- 220 ---- / | ---- 221 / \/ \ / \ CE = Customer Edge Device 222 | A3 CE3 --CE4 A4 | PE = Provider Edge Router 223 \ / \ / u-PE = Layer 2 Aggregation 224 ---- ---- A = Customer site n 226 Figure 1: Example of a VPLS 228 2.1 Terminology 230 Terminology similar to that in [9] is used, with the addition of 231 "u-PE", a Layer 2 PE device used for Layer 2 aggregation. The notion 232 of u-PE is described further in Section 5. PE and u-PE devices are 233 "VPLS-aware", which means that they know that a VPLS service is being 234 offered. We will call these VPLS edge devices, which could be either 235 a PE or an u-PE, a VE. 237 In contrast, the CE device (which may be owned and operated by either 238 the SP or the customer) is VPLS-unaware; as far as the CE is 239 concerned, it is connected to the other CEs in the VPLS via a Layer 2 240 switched network. This means that there should be no changes to a CE 241 device, either to the hardware or the software, in order to offer 242 VPLS. 244 A CE device may be connected to a PE or a u-PE via Layer 2 switches 245 that are VPLS-unaware. From a VPLS point of view, such Layer 2 246 switches are invisible, and hence will not be discussed further. 247 Furthermore, a u-PE may be connected to a PE via Layer 2 and Layer 3 248 devices; this will be discussed further in a later section. 250 The term "demultiplexor" refers to an identifier in a data packet 251 that identifies both the VPLS to which the packet belongs as well as 252 the ingress PE. In this document, the demultiplexor is an MPLS 253 label. 255 The term "VPLS" will refer to the service as well as a particular 256 instantiation of the service (i.e., an emulated LAN); it should be 257 clear from the context which usage is intended. 259 2.2 Assumptions 261 The Service Provider Network is a packet switched network. The PEs 262 are assumed to be (logically) full-meshed with tunnels over which 263 packets that belong to a service (such as VPLS) are encapsulated and 264 forwarded. These tunnels can be IP tunnels, such as GRE, or MPLS 265 tunnels, established by RSVP-TE or LDP. These tunnels are 266 established independently of the services offered over them; the 267 signaling and establishment of these tunnels are not discussed in 268 this document. 270 "Flooding" and MAC address "learning" (see Section 4) are an integral 271 part of VPLS. However, these activities are private to an SP device, 272 i.e., in the VPLS described below, no SP device requests another SP 273 device to flood packets or learn MAC addresses on its behalf. 275 All the PEs participating in a VPLS are assumed to be fully meshed, 276 i.e., every (ingress) PE can send a VPLS packet to the egress PE(s) 277 directly, without the need for an intermediate PE (see 278 Section 4.2.3.) 280 2.3 Interactions 282 VPLS is a "LAN Service" in that CE devices that belong to VPLS V can 283 interact through the SP network as if they were connected by a LAN. 284 VPLS is "private" in that CE devices that belong to different VPLSs 285 cannot interact. VPLS is "virtual" in that multiple VPLSs can be 286 offered over a common packet switched network. 288 PE devices interact to "discover" all the other PEs participating in 289 the same VPLS, and to exchange demultiplexors. These interactions 290 are control-driven, not data-driven. 292 u-PEs interact with PEs to establish connections with remote PEs or 293 u-PEs in the same VPLS. This interaction is control-driven. 295 PE devices can participate simultaneously in both VPLS and IP VPNs 296 ([9]). These are independent services, and the information exchanged 297 for each type of service is kept separate as the Network Layer 298 Reachability Information (NLRI) used for this exchange have different 299 Address Family Identifiers (AFI) and Subsequent Address Family 300 Identifiers (SAFI). Consequently, an implementation MUST maintain a 301 separate routing storage for each service. However, multiple 302 services can use the same underlying tunnels; the VPLS or VPN label 303 is used to demultiplex the packets belonging to different services. 305 3. Control Plane 307 There are two primary functions of the VPLS control plane: 308 autodiscovery, and setup and teardown of the pseudowires that 309 constitute the VPLS, often called signaling. Section 3.1 and 310 Section 3.2 describe these functions. Both of these functions are 311 accomplished with a single BGP Update advertisement; Section 3.3 312 describes how this is done by detailing BGP protocol operation for 313 VPLS. Section 3.4 describes the setting up of pseudowires that span 314 Autonomous Systems. Section 3.5 describes how multi-homing is 315 handled. 317 3.1 Autodiscovery 319 Discovery refers to the process of finding all the PEs that 320 participate in a given VPLS. A PE can either be configured with the 321 identities of all the other PEs in a given VPLS, or the PE can use 322 some protocol to discover the other PEs. The latter is called 323 autodiscovery. 325 The former approach is fairly configuration-intensive, especially 326 since it is required that the PEs participating in a given VPLS are 327 fully meshed (i.e., that every PE in a given VPLS establish 328 pseudowires to every other PE in that VPLS). Furthermore, when the 329 topology of a VPLS changes (i.e., a PE is added to, or removed from 330 the VPLS), the VPLS configuration on all PEs in that VPLS must be 331 changed. 333 In the autodiscovery approach, each PE "discovers" which other PEs 334 are part of a given VPLS by means of some protocol, in this case BGP. 335 This allows each PE's configuration to consist only of the identity 336 of the VPLS instance established on this PE, not the identity of 337 every other PE in that VPLS instance -- that is auto-discovered. 338 Moreover, when the topology of a VPLS changes, only the affected PE's 339 configuration changes; other PEs automatically find out about the 340 change and adapt. 342 3.1.1 Functions 344 A PE that participates in a given VPLS V must be able to tell all 345 other PEs in VPLS V that it is also a member of V. A PE must also 346 have a means of declaring that it no longer participates in a VPLS. 347 To do both of these, the PE must have a means of identifying a VPLS 348 and a means by which to communicate to all other PEs. 350 U-PE devices also need to know what constitutes a given VPLS; 351 however, they don't need the same level of detail. The PE (or PEs) 352 to which a u-PE is connected gives the u-PE an abstraction of the 353 VPLS; this is described in section 5. 355 3.1.2 Protocol Specification 357 The specific mechanism for autodiscovery described here is based on 358 [11] and [9]; it uses BGP extended communities [4] to identify 359 members of a VPLS. A more generic autodiscovery mechanism is 360 described in [8]. The specific extended community used is the Route 361 Target, whose format is described in [4]. The semantics of the use 362 of Route Targets is described in [9]; their use in VPLS is identical. 364 As it has been assumed that VPLSs are fully meshed, a single Route 365 Target RT suffices for a given VPLS V, and in effect that RT is the 366 identifier for VPLS V. 368 A PE announces (typically via I-BGP) that it belongs to VPLS V by 369 annotating its NLRIs for V (see next subsection) with Route Target 370 RT, and acts on this by accepting NLRIs from other PEs that have 371 Route Target RT. A PE announces that it no longer participates in V 372 by withdrawing all NLRIs that it had advertised with Route Target RT. 374 3.2 Signaling 376 Once discovery is done, each pair of PEs in a VPLS must be able to 377 establish (and tear down) pseudowires to each other, i.e., exchange 378 (and withdraw) demultiplexors. This process is known as signaling. 379 Signaling is also used to transmit certain characteristics of the 380 pseudowires that a PE sets up for a given VPLS. 382 Recall that a demultiplexor is used to distinguish among several 383 different streams of traffic carried over a tunnel, each stream 384 possibly representing a different service. In the case of VPLS, the 385 demultiplexor not only says to which specific VPLS a packet belongs, 386 but also identifies the ingress PE. The former information is used 387 for forwarding the packet; the latter information is used for 388 learning MAC addresses. The demultiplexor described here is an MPLS 389 label. However, note that the PE-to-PE tunnels need not be MPLS 390 tunnels. 392 3.2.1 Concepts 394 The VPLS BGP NLRI described below, with a new AFI and SAFI (see [3]) 395 is used to exchange VPLS membership and demultiplexors. 397 A VPLS BGP NLRI has the following information elements: a VE ID, a VE 398 Block Offset, a VE Block Size and a label base. The exact format is 399 given below. 401 A PE participating in a VPLS must have at least one VE ID. If the PE 402 is the VE, it typically has one VE ID. If the PE is connected to 403 several u-PEs, it has a distinct VE ID for each u-PE. It may 404 additionally have a VE ID for itself, if it itself acts as a VE for 405 that VPLS. In what follows, we will call the PE announcing the VPLS 406 NLRI PE-a, and we will assume that PE-a owns VE ID V (either 407 belonging to PE-a itself, or to a u-PE connected to PE-a). 409 VE IDs are typically assigned by the network administrator. Their 410 scope is local to a VPLS. A given VE ID should belong to only one 411 PE, unless a CE is multi-homed (see Section 3.5). 413 A label block is a set of demultiplexor labels used to reach a given 414 VE ID. A VPLS BGP NLRI with VE ID V, VE Block Offset VBO, VE Block 415 Size VBS and label base LB implicitly announces 417 label block for V: labels from LB to (LB + VBS - 1), and 419 remote VE set for V: from VBO to (VBO + VBS - 1). 421 There is a one-to-one correspondance between the remote VE set and 422 the label block: VE ID (VBO + n) corresponds to label (LB + n). 424 3.2.2 PW Setup and Teardown 426 Suppose PE-a is part of VPLS foo, and makes an announcement with VE 427 ID V, VE Block Offset VBO, VE Block Size VBS and label base LB. If 428 PE-b is also part of VPLS foo, and has VE ID W, PE-b does the 429 following: 431 1. is W part of PE-a's 'remote VE set': if VBO <= W < VBO + VBS, 432 then W is part of PE-a's remote VE set. If not, PE-b ignores 433 this message, and skips the rest of this procedure. 435 2. set up a PW to PE-a: the demultiplexor label to send traffic from 436 PE-b to PE-a is computed as (LB + W - VBO). 438 3. is V part of any 'remote VE set' that PE-b announced: PE-b checks 439 if V belongs to some remote VE set that PE-b announced, say with 440 VE Block Offset VBO', VE Block Size VBS' and label base LB'. If 441 not, PE-b MUST make a new announcement as described in 442 Section 3.3. 444 4. set up a PW from PE-a: the demultiplexor label over which PE-b 445 should expect traffic from PE-a is computed as: (LB' + V - VBO'). 447 If Y withdraws an NLRI for V that X was using, then X MUST tear down 448 its ends of the pseudowire between X and Y. 450 The format of the VPLS NLRI is given below. The AFI is the L2VPN AFI 451 (to be assigned by IANA), and the SAFI is the VPLS SAFI (65). 453 +------------------------------------+ 454 | Length (2 octets) | 455 +------------------------------------+ 456 | Route Distinguisher (8 octets) | 457 +------------------------------------+ 458 | VE ID (2 octets) | 459 +------------------------------------+ 460 | VE Block Offset (2 octets) | 461 +------------------------------------+ 462 | VE Block Size (2 octets) | 463 +------------------------------------+ 464 | Label Base (3 octets) | 465 +------------------------------------+ 467 Figure 2: BGP NLRI for VPLS Information 469 3.2.3 Signaling PE Capabilities 471 The following extended attribute, the "Layer2 Info Extended 472 Community", is used to signal control information about the 473 pseudowires to be setup for a given VPLS. This information includes 474 the Encaps Type (type of encapsulation on the pseudowires), Control 475 Flags (control information regarding the pseudowires) and the Maximum 476 Transmission Unit (MTU) to be used on the pseudowires. 478 The Encaps Type for VPLS is 19. 480 +------------------------------------+ 481 | Extended community type (2 octets) | 482 +------------------------------------+ 483 | Encaps Type (1 octet) | 484 +------------------------------------+ 485 | Control Flags (1 octet) | 486 +------------------------------------+ 487 | Layer-2 MTU (2 octet) | 488 +------------------------------------+ 489 | Reserved (2 octets) | 490 +------------------------------------+ 492 Figure 3: Layer2 Info Extended Community 494 0 1 2 3 4 5 6 7 495 +-+-+-+-+-+-+-+-+ 496 | MBZ |C|S| (MBZ = MUST Be Zero) 497 +-+-+-+-+-+-+-+-+ 499 Figure 4: Control Flags Bit Vector 501 With reference to Figure 4, the following bits in the Control Flags 502 are defined; the remaining bits, designated MBZ, MUST be set to zero 503 when sending and MUST be ignored when receiving this community. 505 Name Meaning 506 C If set to 1 (0), Control word MUST (NOT) be present when 507 sending VPLS packets to this PE [10]. 508 S If set to 1 (0), Sequenced delivery of frames is (not) 509 required when sending VPLS packets to this PE. 511 3.3 BGP VPLS Operation 513 To create a new VPLS, say VPLS foo, a network administrator must pick 514 a RT for VPLS foo, say RT-foo. This will be used by all PEs that 515 serve VPLS foo. To configure a given PE, say PE-a, to be part of 516 VPLS foo, the network administrator only has to choose a VE ID V for 517 PE-a. (If PE-a is connected to u-PEs, PE-a may be configured with 518 more than one VE ID; in that case, the following is done for each VE 519 ID). The PE may also be configured with a Route Distinguisher (RD); 520 if not, it generates a unique RD for VPLS foo. Say the RD is 521 RD-foo-a. PE-a then generates an initial label block and a remote VE 522 set for V, defined by VE Block Offset VBO, VE Block Size VBS and 523 label base LB. These may be empty. 525 PE-a then creates a VPLS BGP NLRI with RD RD-foo-a, VE ID V, VE Block 526 Offset VBO, VE Block Size VBS and label base LB. To this, it 527 attaches a Layer2 Info Extended Community and a RT, RT-foo. It sets 528 the BGP Next Hop for this NLRI as itself, and announces this NLRI to 529 its peers. The Network Layer protocol associated with the Network 530 Address of the Next Hop for the combination is IP; this association is required by [3], Section 5. If the 532 value of the Length of the Next Hop field is 4, then the Next Hop 533 contains an IPv4 address. If this value is 16, then the Next Hop 534 contains an IPv6 address. 536 If PE-a hears from another PE, say PE-b, a VPLS BGP announcement with 537 RT-foo and VE ID W, then PE-a knows that PE-b is a member of the same 538 VPLS (auto-discovery). PE-a then has to set up its part of a VPLS 539 pseudowire between PE-a and PE-b, using the mechanisms in 540 Section 3.2. Similarly, PE-b will have discovered that PE-a is in 541 the same VPLS, and PE-b must set up its part of the VPLS pseudowire. 542 Thus, signaling and pseudowire setup is also achieved with the same 543 Update message. 545 If W is not in any remote VE set that PE-a announced for VE ID V in 546 VPLS foo, PE-b will not be able to set up its part of the pseudowire 547 to PE-a. To address this, PE-a can choose to withdraw the old 548 announcement(s) it made for VPLS foo, and announce a new Update with 549 a larger remote VE set and corresponding label block that covers all 550 VE IDs that are in VPLS foo. This however, may cause some service 551 disruption. An alternative for PE-a is to create a new remote VE set 552 and corresponding label block, and announce them in a new Update, 553 without withdrawing previous announcements. 555 If PE-a's configuration is changed to remove VE ID V from VPLS foo, 556 then PE-a MUST withdraw all its announcements for VPLS foo that 557 contain VE ID V. If all of PE-a's links to its CEs in VPLS foo go 558 down, then PE-a SHOULD either withdraw all its NLRIs for VPLS foo, or 559 let other PEs in the VPLS foo know in some way that PE-a is no longer 560 connected to its CEs. 562 3.4 Multi-AS VPLS 564 As in [11] and [9], the above autodiscovery and signaling functions 565 are typically announced via I-BGP. This assumes that all the sites 566 in a VPLS are connected to PEs in a single Autonomous System (AS). 568 However, sites in a VPLS may connect to PEs in different ASes. This 569 leads to two issues: 1) there would not be an I-BGP connection 570 between those PEs, so some means of signaling across ASes may be 571 needed; and 2) there may not be PE-to-PE tunnels between the ASes. 573 A similar problem is solved in [9], Section 10. Three methods are 574 suggested to address issue (1); all these methods have analogs in 575 multi-AS VPLS. 577 Here is a diagram for reference: 579 __________ ____________ ____________ __________ 580 / \ / \ / \ / \ 581 \___/ AS 1 \ / AS 2 \___/ 582 \ / 583 +-----+ +-------+ | +-------+ +-----+ 584 | PE1 | ---...--- | ASBR1 | ======= | ASBR2 | ---...--- | PE2 | 585 +-----+ +-------+ | +-------+ +-----+ 586 ___ / \ ___ 587 / \ / \ / \ 588 \__________/ \____________/ \____________/ \__________/ 590 Figure 6: Inter-AS VPLS 592 3.4.1 a) VPLS-to-VPLS connections at the AS border routers. 594 In this method, an AS Border Router (ASBR1) acts as a PE for all 595 VPLSs that span AS1 and an AS to which ASBR1 is connected, such as 596 AS2 here. The ASBR on the neighboring AS (ASBR2) is viewed by ASBR1 597 as a CE for the VPLSs that span AS1 and AS2; similarly, ASBR2 acts as 598 a PE for this VPLS from AS2's point of view, and views ASBR1 as a CE. 600 This method does not require MPLS on the ASBR1-ASBR2 link, but does 601 require that this link carry Ethernet traffic, and that there be a 602 separate VLAN sub-interface for each VPLS traversing this link. It 603 further requires that ASBR1 does the PE operations (discovery, 604 signaling, MAC address learning, flooding, encapsulation, etc.) for 605 all VPLSs that traverse ASBR1. This imposes a significant burden on 606 ASBR1, both on the control plane and the data plane, which limits the 607 number of multi-AS VPLSs. 609 Note that in general, there will be multiple connections between a 610 pair of ASes, for redundancy. In this case, the Spanning Tree 611 Protocol (STP), or some other means of loop detection and prevention, 612 must be run on each VPLS that spans these ASes, so that a loop-free 613 topology can be constructed in each VPLS. This imposes a further 614 burden on the ASBRs and PEs participating in those VPLSs, as these 615 devices would need to run a loop detection algorithm for each such 616 VPLS. How this may be achieved is outside the scope of this 617 document. 619 3.4.2 b) EBGP redistribution of VPLS information between ASBRs. 621 This method requires I-BGP peerings between the PEs in AS1 and ASBR1 622 in AS1 (perhaps via route reflectors), an E-BGP peering between ASBR1 623 and ASBR2 in AS2, and I-BGP peerings between ASBR2 and the PEs in 624 AS2. In the above example, PE1 sends a VPLS NLRI to ASBR1 with a 625 label block and itself as the BGP nexthop; ASBR1 sends the NLRI to 626 ASBR2 with new labels and itself as the BGP nexthop; and ASBR2 sends 627 the NLRI to PE2 with new labels and itself as the nexthop. 629 The VPLS NLRI that ASBR1 sends to ASBR2 (and the NLRI that ASBR2 630 sends to PE2) is identical to the VPLS NLRI that PE1 sends to ASBR1, 631 except for the label block. To be precise, the Length, the Route 632 Distinguisher, the VE ID, the VE Block Offset, and the VE Block Size 633 MUST be the same; the Label Base may be different. Furthermore, 634 ASBR1 must also update its forwarding path as follows: if the Label 635 Base sent by PE1 is L1, the Label-block Size is N, the Label Base 636 sent by ASBR1 is L2, and the tunnel label from ASBR1 to PE1 is T, 637 then ASBR1 must install the following in the forwarding path: 639 swap L2 with L1 and push T, 641 swap L2+1 with L1+1 and push T, ... 643 swap L2+N-1 with L1+N-1 and push T. 645 ASBR2 must act similarly, except that it may not need a tunnel label 646 if it is directly connected with ASBR1. 648 When PE2 wants to send a VPLS packet to PE1, PE2 uses its VE ID to 649 get the right VPLS label from ASBR2's label block for PE1, and uses a 650 tunnel label to reach ASBR2. ASBR2 swaps the VPLS label with the 651 label from ASBR1; ASBR1 then swaps the VPLS label with the label from 652 PE1, and pushes a tunnel label to reach PE1. 654 In this method, one needs MPLS on the ASBR1-ASBR2 interface, but 655 there is no requirement that the link layer be Ethernet. 656 Furthermore, the ASBRs take part in distributing VPLS information. 657 However, the data plane requirements of the ASBRs is much simpler 658 than in method (a), being limited to label operations. Finally, the 659 construction of loop-free VPLS topologies is done by routing 660 decisions, viz. BGP path and nexthop selection, so there is no need 661 to run the Spanning Tree Protocol on a per-VPLS basis. Thus, this 662 method is considerably more scalable than method (a). 664 3.4.3 c) Multi-hop EBGP redistribution of VPLS information between 665 ASes. 667 In this method, there is a multi-hop E-BGP peering between the PEs 668 (or preferably, a Route Reflector) in AS1 and the PEs (or Route 669 Reflector) in AS2. PE1 sends a VPLS NLRI with labels and nexthop 670 self to PE2; if this is via route reflectors, the BGP nexthop is not 671 changed. This requires that there be a tunnel LSP from PE1 to PE2. 673 This tunnel LSP can be created exactly as in [9], section 10 (c), for 674 example using E-BGP to exchange labeled IPv4 routes for the PE 675 loopbacks. 677 When PE1 wants to send a VPLS packet to PE2, it pushes the VPLS label 678 corresponding to its own VE ID onto the packet. It then pushes the 679 tunnel label(s) to reach PE2. 681 This method requires no VPLS information (in either the control or 682 the data plane) on the ASBRs. The ASBRs only need to set up PE-to-PE 683 tunnel LSPs in the control plane, and do label operations in the data 684 plane. Again, as in the case of method (b), the construction of 685 loop-free VPLS topologies is done by routing decisions, i.e., BGP 686 path and nexthop selection, so there is no need to run the Spanning 687 Tree Protocol on a per-VPLS basis. This option is likely to be the 688 most scalable of the three methods presented here. 690 3.4.4 Allocation of VE IDs Across Multiple ASes 692 In order to ease the allocation of VE IDs for a VPLS that spans 693 multiple ASes, one can allocate ranges for each AS. For example, AS1 694 uses VE IDs in the range 1 to 100, AS2 from 101 to 200, etc. If 695 there are 10 sites attached to AS1 and 20 to AS2, the allocated VE 696 IDs could be 1-10 and 101 to 120. This minimizes the number of VPLS 697 NLRIs that are exchanged while ensuring that VE IDs are kept unique. 699 In the above example, if AS1 needed more than 100 sites, then another 700 range can be allocated to AS1. The only caveat is that there be no 701 overlap between VE ID ranges among ASes. The exception to this rule 702 is multi-homing, which is dealt with below. 704 3.5 Multi-homing and Path Selection 706 It is often desired to multi-home a VPLS site, i.e., to connect it to 707 multiple PEs, perhaps even in different ASes. In such a case, the 708 PEs connected to the same site can either be configured with the same 709 VE ID or with different VE IDs. In the latter case, it is mandatory 710 to run STP on the CE device, and possibly on the PEs, to construct a 711 loop-free VPLS topology. How this can be accomplished is outside the 712 scope of this document; however, the rest of this section will 713 describe in some detail the former case. 715 In the case where the PEs connected to the same site are assigned the 716 same VE ID, a loop-free topology is constructed by routing 717 mechanisms, in particular, by BGP path selection. When a BGP speaker 718 receives two equivalent NLRIs (see below for the definition), it 719 applies standard path selection criteria such as Local Preference and 720 AS Path Length to determine which NLRI to choose; it MUST pick only 721 one. If the chosen NLRI is subsequently withdrawn, the BGP speaker 722 applies path selection to the remaining equivalent VPLS NLRIs to pick 723 another; if none remain, the forwarding information associated with 724 that NLRI is removed. 726 Two VPLS NLRIs are considered equivalent from a path selection point 727 of view if the Route Distinguisher, the VE ID and the VE Block Offset 728 are the same. If two PEs are assigned the same VE ID in a given 729 VPLS, they MUST use the same Route Distinguisher, and they SHOULD 730 announce the same VE Block Size for a given VE Offset. 732 4. Data Plane 734 This section discusses two aspects of the data plane for PEs and 735 u-PEs implementing VPLS: encapsulation and forwarding. 737 4.1 Encapsulation 739 Ethernet frames received from CE devices are encapsulated for 740 transmission over the packet switched network connecting the PEs. 741 The encapsulation is as in [10], with one change: a PE that sets the 742 P bit in the Control Flags strips the outermost VLAN from an Ethernet 743 frame received from a CE before encapsulating it, and pushes a VLAN 744 onto a decapsulated frame before sending it to a CE. 746 4.2 Forwarding 748 VPLS packets are classified as belonging to a given service instance 749 and associated forwarding table based on the interface over which the 750 packet is received. Packets are forwarded in the context of the 751 service instance based on the destination MAC address. The former 752 mapping is determined by configuration. The latter is the focus of 753 this section. 755 4.2.1 MAC address learning 757 As was mentioned earlier, the key distinguishing feature of VPLS is 758 that it is a multipoint service. This means that the entire Service 759 Provider network should appear as a single logical learning bridge 760 for each VPLS that the SP network supports. The logical ports for 761 the SP "bridge" are the customer ports on all of the VE on a given 762 service. Just as a learning bridge learns MAC addresses on its 763 ports, the SP bridge must learn MAC addresses at its VEs. 765 Learning consists of associating source MAC addresses of packets with 766 the (logical) ports on which they arrive; this association is the 767 Forwarding Information Base (FIB). The FIB is used for forwarding 768 packets. For example, suppose the bridge receives a packet with 769 source MAC address S on (logical) port P. If subsequently, the bridge 770 receives a packet with destination MAC address S, it knows that it 771 should send the packet out on port P. 773 4.2.2 Flooding 775 When a bridge receives a packet to a destination that is not in its 776 FIB, it floods the packet on all the other ports. Similarly, a VE 777 will flood packets to an unknown destination to all other VEs in the 778 VPLS. 780 In Figure 1 above, if CE2 sent an Ethernet frame to PE2, and the 781 destination MAC address on the frame was not in PE2's FIB (for that 782 VPLS), then PE2 would be responsible for flooding that frame to every 783 other PE in the same VPLS. On receiving that frame, PE1 would be 784 responsible for further flooding the frame to CE1 and CE5 (unless PE1 785 knew which CE "owned" that MAC address). 787 On the other hand, if PE3 received the frame, it could delegate 788 further flooding of the frame to its u-PE. If PE3 was connected to 2 789 u-PEs, it would announce that it has two u-PEs. PE3 could either 790 announce that it is incapable of flooding, in which case it would 791 receive two frames, one for each u-PE, or it could announce that it 792 is capable of flooding, in which case it would receive one copy of 793 the frame, which it would then send to both u-PEs. 795 4.2.3 "Split Horizon" Forwarding 797 When a PE capable of flooding receives a broadcast Ethernet frame, or 798 one with an unknown destination MAC address, it must flood the frame. 799 If the frame arrived from an attached CE, the PE must send a copy of 800 the frame to every other attached CE, as well as to all PEs 801 participating in the VPLS. If the frame arrived from another PE, 802 however, the PE must only send a copy of the packet to attached CEs. 803 The PE MUST NOT send the frame to other PEs. This notion has been 804 termed "split horizon" forwarding, and is a consequence of the PEs 805 being logically full-meshed -- if a broadcast frame is received from 806 PEx, then PEx would have sent a copy to all other PEs. 808 Split horizon forwarding rules also apply to multicast frames (i.e., 809 those with a multicast destination MAC address). In this case, when 810 a PE receives a multicast frame from another PE, the frame is 811 replicated and sent to the relevant subset of attached CEs; however, 812 it MUST NOT be sent to other PEs. 814 5. Deployment Options 816 In deploying a network that supports VPLS, the SP must decide what 817 functions the VPLS-aware device closest to the customer (the VE) 818 supports. The default case described in this document is that the VE 819 is a PE. However, there are a number of reasons that the VE might be 820 a device that does all the Layer 2 functions (such as MAC address 821 learning and flooding), and a limited set of Layer 3 functions (such 822 as communicating to its PE), but, for example, doesn't do full- 823 fledged discovery and PE-to-PE signaling. Such a device is called a 824 "u-PE". 826 As both of these cases have benefits, one would like to be able to 827 "mix and match" these scenarios. The signaling mechanism presented 828 here allows this. For example, in a given provider network, one PE 829 may be directly connected to CE devices; another may be connected to 830 u-PEs that are connected to CEs; and a third may be connected 831 directly to a customer over some interfaces and to u-PEs over others. 832 All these PEs perform discovery and signaling in the same manner. 833 How they do learning and forwarding depends on whether or not there 834 is a u-PE; however, this is a local matter, and is not signaled. 835 However, the details of the operation of a u-PE and its interactions 836 with PEs and other u-PEs is beyond the scope of this document. 838 6. Security Considerations 840 The focus in Virtual Private LAN Service is the privacy of data, 841 i.e., that data in a VPLS is only distributed to other nodes in that 842 VPLS and not to any external agent or other VPLS. Note that VPLS 843 does not offer security or authentication: VPLS packets are sent in 844 the clear in the packet-switched network, and a man-in-the-middle can 845 eavesdrop, and may be able to inject packets into the data stream. 846 If security is desired, the PE-to-PE tunnels can be IPsec tunnels. 847 For more security, the end systems in the VPLS sites can use 848 appropriate means of encryption to secure their data even before it 849 enters the Service Provider network. 851 There are two aspects to achieving data privacy in a VPLS: securing 852 the control plane, and protecting the forwarding path. Compromise of 853 the control plane could result in a PE sending data belonging to some 854 VPLS to another VPLS, or blackholing VPLS data, or even sending it to 855 an eavesdropper, none of which are acceptable from a data privacy 856 point of view. Since all control plane exchanges are via BGP, 857 techniques such as in [2] help authenticate BGP messages, making it 858 harder to spoof updates (which can be used to divert VPLS traffic to 859 the wrong VPLS), or withdraws (denial of service attacks). In the 860 multi-AS options (b) and (c), this also means protecting the inter-AS 861 BGP sessions, between the ASBRs, the PEs or the Route Reflectors. 862 Note that [2] will not help in keeping VPLS labels private -- knowing 863 the labels, one can eavesdrop on VPLS traffic. However, this 864 requires access to the data path within a Service Provider network. 866 Protecting the data plane requires ensuring that PE-to-PE tunnels are 867 well-behaved (this is outside the scope of this document), and that 868 VPLS labels are accepted only from valid interfaces. For a PE, valid 869 interfaces comprise links from P routers. For an ASBR, a valid 870 interface is a link from an ASBR in an AS that is part of a given 871 VPLS. It is especially important in the case of multi-AS VPLSs that 872 one accept VPLS packets only from valid interfaces. 874 7. IANA Considerations 876 IANA is asked to allocate an AFI for L2VPN information (suggested 877 value: 25). This should be the same as the AFI requested by [8]. 879 8. References 881 8.1 Normative References 883 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 884 Levels", BCP 14, RFC 2119, March 1997. 886 [2] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 887 Signature Option", RFC 2385, August 1998. 889 [3] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol 890 Extensions for BGP-4", draft-ietf-idr-rfc2858bis-06 (work in 891 progress), May 2004. 893 [4] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 894 Communities Attribute", draft-ietf-idr-bgp-ext-communities-08 895 (work in progress), February 2005. 897 [5] Martini, L., "Encapsulation Methods for Transport of Ethernet 898 Frames Over MPLS Networks", draft-ietf-pwe3-ethernet-encap-09 899 (work in progress), February 2005. 901 8.2 Informative References 903 [6] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 904 Private Networks (L2VPNs)", draft-ietf-l2vpn-l2-framework-05 905 (work in progress), June 2004. 907 [7] Lasserre, M. and V. Kompella, "Virtual Private LAN Services 908 over MPLS", draft-ietf-l2vpn-vpls-ldp-06 (work in progress), 909 February 2005. 911 [8] Ould-Brahim, H., Rosen, E., and Y. Rekhter, "Using BGP as an 912 Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs", 913 draft-ietf-l3vpn-bgpvpn-auto-05 (work in progress), 914 February 2005. 916 [9] Rosen, E., "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-03 917 (work in progress), October 2004. 919 [10] Martini, L., "Pseudowire Setup and Maintenance using LDP", 920 draft-ietf-pwe3-control-protocol-16 (work in progress), 921 March 2005. 923 [11] Kompella, K., "Layer 2 VPNs Over Tunnels", 924 draft-kompella-l2vpn-l2vpn-00 (work in progress), January 2004. 926 Authors' Addresses 928 Kireeti Kompella (editor) 929 Juniper Networks 930 1194 N. Mathilda Ave. 931 Sunnyvale, CA 94089 932 US 934 Email: kireeti@juniper.net 936 Yakov Rekhter (editor) 937 Juniper Networks 938 1194 N. Mathilda Ave. 939 Sunnyvale, CA 94089 940 US 942 Email: kireeti@juniper.net 944 Appendix A. Contributors 946 The following contributed to this document: 948 Javier Achirica, Telefonica 949 Loa Andersson, Acreo 950 Chaitanya Kodeboyina, Juniper 951 Giles Heron, Alcatel 952 Sunil Khandekar, Alcatel 953 Vach Kompella, Alcatel 954 Marc Lasserre, Riverstone 955 Pierre Lin 956 Pascal Menezes 957 Ashwin Moranganti, Appian 958 Hamid Ould-Brahim, Nortel 959 Seo Yeong-il, Korea Tel 961 Appendix B. Acknowledgements 963 Thanks to Joe Regan and Alfred Nothaft for their contributions. Many 964 thanks too to Eric Ji, Chaitanya Kodeboyina, and Mike Loomis for 965 their detailed reviews. 967 Intellectual Property Statement 969 The IETF takes no position regarding the validity or scope of any 970 Intellectual Property Rights or other rights that might be claimed to 971 pertain to the implementation or use of the technology described in 972 this document or the extent to which any license under such rights 973 might or might not be available; nor does it represent that it has 974 made any independent effort to identify any such rights. Information 975 on the procedures with respect to rights in RFC documents can be 976 found in BCP 78 and BCP 79. 978 Copies of IPR disclosures made to the IETF Secretariat and any 979 assurances of licenses to be made available, or the result of an 980 attempt made to obtain a general license or permission for the use of 981 such proprietary rights by implementers or users of this 982 specification can be obtained from the IETF on-line IPR repository at 983 http://www.ietf.org/ipr. 985 The IETF invites any interested party to bring to its attention any 986 copyrights, patents or patent applications, or other proprietary 987 rights that may cover technology that may be required to implement 988 this standard. Please address the information to the IETF at 989 ietf-ipr@ietf.org. 991 Disclaimer of Validity 993 This document and the information contained herein are provided on an 994 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 995 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 996 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 997 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 998 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 999 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1001 Copyright Statement 1003 Copyright (C) The Internet Society (2005). This document is subject 1004 to the rights, licenses and restrictions contained in BCP 78, and 1005 except as set forth therein, the authors retain all their rights. 1007 Acknowledgment 1009 Funding for the RFC Editor function is currently provided by the 1010 Internet Society.