idnits 2.17.1 draft-ietf-l2vpn-vpls-bgp-04.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 884. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 861. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 868. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 874. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 12 instances of lines with control characters in the document. 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 (February 19, 2005) is 7003 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 781, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2385 (ref. '2') (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2858 (ref. '3') (Obsoleted by RFC 4760) == 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-08 == Outdated reference: A later version (-09) exists of draft-ietf-l2vpn-vpls-ldp-05 == Outdated reference: A later version (-09) exists of draft-ietf-l3vpn-bgpvpn-auto-04 == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-14 == Outdated reference: A later version (-10) exists of draft-kompella-l2vpn-l2vpn-00 Summary: 9 errors (**), 0 flaws (~~), 9 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: August 23, 2005 Juniper Networks 5 February 19, 2005 7 Virtual Private LAN Service 8 draft-ietf-l2vpn-vpls-bgp-04 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 23, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 Virtual Private LAN Service (VPLS), also known as Transparent LAN 44 Service, and Virtual Private Switched Network service, is a useful 45 Service Provider offering. The service offers a Layer 2 Virtual 46 Private Network (VPN); however, in the case of VPLS, the customers in 47 the VPN are connected by a multipoint network, in contrast to the 48 usual Layer 2 VPNs, which are point-to-point in nature. 50 This document describes the functions required to offer VPLS, a 51 mechanism for signaling a VPLS, and rules for forwarding VPLS frames 52 across a packet switched network. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1 Scope of this Document . . . . . . . . . . . . . . . . . . 3 58 1.2 Conventions used in this document . . . . . . . . . . . . 4 59 1.3 Changes from last version . . . . . . . . . . . . . . . . 4 60 2. Functional Model . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.3 Interactions . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.1 Autodiscovery . . . . . . . . . . . . . . . . . . . . . . 8 66 3.1.1 Functions . . . . . . . . . . . . . . . . . . . . . . 8 67 3.1.2 Protocol Specification . . . . . . . . . . . . . . . . 9 68 3.2 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9 69 3.2.1 Setup and Teardown . . . . . . . . . . . . . . . . . . 9 70 3.2.2 Signaling PE Capabilities . . . . . . . . . . . . . . 11 71 3.3 Multi-AS VPLS . . . . . . . . . . . . . . . . . . . . . . 12 72 3.3.1 a) VPLS-to-VPLS connections at the AS border 73 routers. . . . . . . . . . . . . . . . . . . . . . . . 13 74 3.3.2 b) EBGP redistribution of VPLS information between 75 ASBRs. . . . . . . . . . . . . . . . . . . . . . . . . 13 76 3.3.3 c) Multi-hop EBGP redistribution of VPLS 77 information between ASes. . . . . . . . . . . . . . . 14 78 3.4 Multi-homing and Path Selection . . . . . . . . . . . . . 15 79 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 4.1 Encapsulation . . . . . . . . . . . . . . . . . . . . . . 17 81 4.2 Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 17 82 4.2.1 MAC address learning . . . . . . . . . . . . . . . . . 17 83 4.2.2 Flooding . . . . . . . . . . . . . . . . . . . . . . . 17 84 4.2.3 "Split Horizon" Forwarding . . . . . . . . . . . . . . 18 85 5. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 19 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 8.1 Normative References . . . . . . . . . . . . . . . . . . . 22 90 8.2 Informative References . . . . . . . . . . . . . . . . . . 22 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 92 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 94 Intellectual Property and Copyright Statements . . . . . . . . 26 96 1. Introduction 98 Virtual Private LAN Service (VPLS), also known as Transparent LAN 99 Service, and Virtual Private Switched Network service, is a useful 100 service offering. A Virtual Private LAN appears in (almost) all 101 respects as a LAN to customers of a Service Provider. However, in a 102 VPLS, the customers are not all connected to a single LAN; the 103 customers may be spread across a metro or wide area. In essence, a 104 VPLS glues several individual LANs across a packet-switched network 105 to appear and function as a single LAN ([6]). 107 This document describes the functions needed to offer VPLS, and goes 108 on to describe a mechanism for signaling a VPLS, as well as a 109 mechanism for transport of VPLS frames over tunnels across a packet 110 switched network. The signaling mechanism uses BGP as the control 111 plane protocol. This document also briefly discusses deployment 112 options, in particular, the notion of decoupling functions across 113 devices. 115 Alternative approaches include: [11], which allows one to build a 116 Layer 2 VPN with Ethernet as the interconnect; and [10]), which 117 allows one to set up an Ethernet connection across a packet-switched 118 network. Both of these, however, offer point-to-point Ethernet 119 services. What distinguishes VPLS from the above two is that a VPLS 120 offers a multipoint service. A mechanism for setting up pseudowires 121 for VPLS using the Label Distribution Protocol (LDP) is defined in 122 [7]. 124 1.1 Scope of this Document 126 This document has four major parts: defining a VPLS functional model; 127 defining a control plane for setting up VPLS; defining the data plane 128 for VPLS (encapsulation and forwarding of data); and defining various 129 deployment options. 131 The functional model underlying VPLS is laid out in Section 2. This 132 describes the service being offered, the network components that 133 interact to provide the service, and at a high level their 134 interactions. 136 The control plane described in this document uses Multiprotocol BGP 137 [3] to establish VPLS service, i.e., for the autodiscovery of VPLS 138 members and for the setup and teardown of the pseudowires that 139 constitute a given VPLS instance. Section 3 focuses on this, and 140 also describes how a VPLS that spans Autonomous System boundaries is 141 set up, as well as how multi-homing is handled. Using BGP as the 142 control plane for VPNs is not new (see [11], [9] and [8]): what is 143 described here is based on the mechanisms proposed in [9]. 145 The forwarding plane and the actions that a participating PE must 146 take is described in Section 4. 148 In Section 5, the notion of 'decoupled' operation is defined, and the 149 interaction of decoupled and non-decoupled PEs is described. 150 Decoupling allows for more flexible deployment of VPLS. 152 1.2 Conventions used in this document 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119 ([1]). 158 1.3 Changes from last version 160 [NOTE to RFC Editor: this section is to be removed before 161 publication.] 163 Incorporated IDR review comments from Eric Ji, Chaitanya Kodeboyina, 164 and Mike Loomis. Most changes are clarifications and rewording for 165 better readability. The substantive changes are to remove several 166 flags from the control field. 168 2. Functional Model 170 This will be described with reference to the following figure. 172 ----- 173 / A1 \ 174 ---- ____CE1 | 175 / \ -------- -------- / | | 176 | A2 CE2- / \ / PE1 \ / 177 \ / \ / \___/ | \ ----- 178 ---- ---PE2 | \ 179 | | \ ----- 180 | Service Provider Network | \ / \ 181 | | CE5 A5 | 182 | ___ | / \ / 183 |----| \ / \ PE4_/ ----- 184 |u-PE|--PE3 / \ / 185 |----| -------- ------- 186 ---- / | ---- 187 / \/ \ / \ CE = Customer Edge Device 188 | A3 CE3 --CE4 A4 | PE = Provider Edge Router 189 \ / \ / u-PE = Layer 2 Aggregation 190 ---- ---- A = Customer site n 192 Figure 1: Example of a VPLS 194 2.1 Terminology 196 Terminology similar to that in [9] is used, with the addition of 197 "u-PE", a Layer 2 PE device used for Layer 2 aggregation. The notion 198 of u-PE is described further in Section 5. PE and u-PE devices are 199 "VPLS-aware", which means that they know that a VPLS service is being 200 offered. We will call these VPLS edge devices, which could be either 201 a PE or an u-PE, a VE. 203 In contrast, the CE device (which may be owned and operated by either 204 the SP or the customer) is VPLS-unaware; as far as the CE is 205 concerned, it is connected to the other CEs in the VPLS via a Layer 2 206 switched network. This means that there should be no changes to a CE 207 device, either to the hardware or the software, in order to offer 208 VPLS. 210 A CE device may be connected to a PE or a u-PE via Layer 2 switches 211 that are VPLS-unaware. From a VPLS point of view, such Layer 2 212 switches are invisible, and hence will not be discussed further. 213 Furthermore, a u-PE may be connected to a PE via Layer 2 and Layer 3 214 devices; this will be discussed further in a later section. 216 The term "demultiplexor" refers to an identifier in a data packet 217 that identifies both the VPLS to which the packet belongs as well as 218 the ingress PE. In this document, the demultiplexor is an MPLS 219 label. 221 The term "VPLS" will refer to the service as well as a particular 222 instantiation of the service (i.e., an emulated LAN); it should be 223 clear from the context which usage is intended. 225 2.2 Assumptions 227 The Service Provider Network is a packet switched network. The PEs 228 are assumed to be (logically) full-meshed with tunnels over which 229 packets that belong to a service (such as VPLS) are encapsulated and 230 forwarded. These tunnels can be IP tunnels, such as GRE, or MPLS 231 tunnels, established by RSVP-TE or LDP. These tunnels are 232 established independently of the services offered over them; the 233 signaling and establishment of these tunnels are not discussed in 234 this document. 236 "Flooding" and MAC address "learning" (see Section 4) are an integral 237 part of VPLS. However, these activities are private to an SP device, 238 i.e., in the VPLS described below, no SP device requests another SP 239 device to flood packets or learn MAC addresses on its behalf. 241 All the PEs participating in a VPLS are assumed to be fully meshed, 242 i.e., every (ingress) PE can send a VPLS packet to the egress PE(s) 243 directly, without the need for an intermediate PE (see 244 Section 4.2.3.) 246 2.3 Interactions 248 VPLS is a "LAN Service" in that CE devices that belong to VPLS V can 249 interact through the SP network as if they were connected by a LAN. 250 VPLS is "private" in that CE devices that belong to different VPLSs 251 cannot interact. VPLS is "virtual" in that multiple VPLSs can be 252 offered over a common packet switched network. 254 PE devices interact to "discover" all the other PEs participating in 255 the same VPLS, and to exchange demultiplexors. These interactions 256 are control-driven, not data-driven. 258 u-PEs interact with PEs to establish connections with remote PEs or 259 u-PEs in the same VPLS. This interaction is control-driven. 261 PE devices can participate simultaneously in both VPLS and IP VPNs 262 ([9]). These are independent services, and the information exchanged 263 for each type of service is kept separate as the Network Layer 264 Reachability Information (NLRI) used for this exchange have different 265 Address Family Identifiers (AFI) and Subsequent Address Family 266 Identifiers (SAFI). Consequently, an implementation MUST maintain a 267 separate routing storage for each service. However, multiple 268 services can use the same underlying tunnels; the VPLS or VPN label 269 is used to demultiplex the packets belonging to different services. 271 3. Control Plane 273 There are two primary functions of the VPLS control plane: 274 autodiscovery, and setup and teardown of the pseudowires that 275 constitute the VPLS, often called signaling. The first two 276 subsections describe these functions. The third subsection describes 277 the setting up of pseudowires that span Autonomous Systems. The last 278 subsection details how multi-homing is handled. 280 3.1 Autodiscovery 282 Discovery refers to the process of finding all the PEs that 283 participate in a given VPLS. A PE can either be configured with the 284 identities of all the other PEs in a given VPLS, or the PE can use 285 some protocol to discover the other PEs. The latter is called 286 autodiscovery. 288 The former approach is fairly configuration-intensive, especially 289 since it is required that the PEs participating in a given VPLS are 290 fully meshed (i.e., that every PE in a given VPLS establish 291 pseudowires to every other PE in that VPLS). Furthermore, when the 292 topology of a VPLS changes (i.e., a PE is added to, or removed from 293 the VPLS), the VPLS configuration on all PEs in that VPLS must be 294 changed. 296 In the autodiscovery approach, each PE "discovers" which other PEs 297 are part of a given VPLS by means of some protocol, in this case BGP. 298 This allows each PE's configuration to consist only of the identity 299 of the VPLS instance established on this PE, not the identity of 300 every other PE in that VPLS instance -- that is auto-discovered. 301 Moreover, when the topology of a VPLS changes, only the affected PE's 302 configuration changes; other PEs automatically find out about the 303 change and adapt. 305 3.1.1 Functions 307 A PE that participates in a given VPLS V must be able to tell all 308 other PEs in VPLS V that it is also a member of V. A PE must also 309 have a means of declaring that it no longer participates in a VPLS. 310 To do both of these, the PE must have a means of identifying a VPLS 311 and a means by which to communicate to all other PEs. 313 U-PE devices also need to know what constitutes a given VPLS; 314 however, they don't need the same level of detail. The PE (or PEs) 315 to which a u-PE is connected gives the u-PE an abstraction of the 316 VPLS; this is described in section 5. 318 3.1.2 Protocol Specification 320 The specific mechanism for autodiscovery described here is based on 321 [11] and [9]; it uses BGP extended communities [4] to identify 322 members of a VPLS. A more generic autodiscovery mechanism is 323 described in [8]. The specific extended community used is the Route 324 Target, whose format is described in [4]. The semantics of the use 325 of Route Targets is described in [9]; their use in VPLS is identical. 327 As it has been assumed that VPLSs are fully meshed, a single Route 328 Target RT suffices for a given VPLS V, and in effect that RT is the 329 identifier for VPLS V. 331 A PE announces (typically via I-BGP) that it belongs to VPLS V by 332 annotating its NLRIs for V (see next subsection) with Route Target 333 RT, and acts on this by accepting NLRIs from other PEs that have 334 Route Target RT. A PE announces that it no longer participates in V 335 by withdrawing all NLRIs that it had advertised with Route Target RT. 337 3.2 Signaling 339 Once discovery is done, each pair of PEs in a VPLS must be able to 340 establish (and tear down) pseudowires to each other, i.e., exchange 341 (and withdraw) demultiplexors. This process is known as signaling. 342 Signaling is also used to transmit certain characteristics of the PE 343 regarding a given VPLS. 345 Recall that a demultiplexor is used to distinguish among several 346 different streams of traffic carried over a tunnel, each stream 347 possibly representing a different service. In the case of VPLS, the 348 demultiplexor not only says to which specific VPLS a packet belongs, 349 but also identifies the ingress PE. The former information is used 350 for forwarding the packet; the latter information is used for 351 learning MAC addresses. The demultiplexor described here is an MPLS 352 label, even though the PE-to-PE tunnels may not be MPLS tunnels. 354 3.2.1 Setup and Teardown 356 The VPLS BGP NLRI described below, with a new AFI and SAFI (see [3]) 357 is used to exchange demultiplexors. 359 A PE advertises a VPLS NLRI for each VPLS that it participates in. 360 If the PE is doing learning and flooding, i.e., it is the VE, it 361 announces a single set of VPLS NLRIs for each VPLS that it is in. If 362 the PE is connected to several u-PEs, it announces one set of VPLS 363 NLRIs for each u-PE. A hybrid scheme is also possible, where the PE 364 learns MAC addresses on some interfaces (over which it is directly 365 connected to CEs) and delegates learning on other interfaces (over 366 which it is connected to u-PEs). In this case, the PE would announce 367 one set of VPLS NLRIs for each u-PE that has customer ports in a 368 given VPLS, and one set for itself, if it has customer ports in that 369 VPLS. 371 Each set of NLRIs defines the demultiplexors for a range of other PEs 372 in the VPLS. Ideally, a single NLRI suffices to cover all PEs in a 373 VPLS; however, there are cases (such as a newly added PE) where the 374 pre-existing NLRI does not have enough labels. In such cases, 375 advertising an additional NLRI for the same VPLS serves to add labels 376 for the new PEs without disrupting service to the pre-existing PEs. 377 If service disruption is acceptable (or when the PE restarts its BGP 378 process), a PE MAY consider coalescing all NLRIs for a VPLS into a 379 single NLRI. 381 If a PE X is part of VPLS V, and X receives a VPLS NLRI for V from PE 382 Y that includes a demultiplexor that X can use, X sets up its ends of 383 a pseudowire between X and Y. X may also have to advertise a new 384 NLRI for V that includes a demultiplexor that Y can use, if its 385 pre-existing NLRI for V did not include a demultiplexor for Y. 387 If Y's configuration is changed to remove it from VPLS V, then Y MUST 388 withdraw all its NLRIs for V. If all Y's links to CEs in V go down, 389 then Y SHOULD either withdraw all its NLRIs for V, or let other PEs 390 in the VPLS V know in some way that Y is no longer connected to its 391 CEs. 393 If Y withdraws an NLRI for V that X was using, then X MUST tear down 394 its ends of the pseudowire between X and Y. 396 The format of the VPLS NLRI is given below. The AFI is to be 397 assigned by IANA, and the SAFI is the VPLS SAFI (65). 399 +------------------------------------+ 400 | Length (2 octets) | 401 +------------------------------------+ 402 | Route Distinguisher (8 octets) | 403 +------------------------------------+ 404 | VE ID (2 octets) | 405 +------------------------------------+ 406 | VE Block Offset (2 octets) | 407 +------------------------------------+ 408 | VE Block Size (2 octets) | 409 +------------------------------------+ 410 | Label Base (3 octets) | 411 +------------------------------------+ 413 Figure 2: BGP NLRI for VPLS Information 415 3.2.2 Signaling PE Capabilities 417 The Encaps Type and Control Flags are encoded in an extended 418 attribute. 420 The Encaps Type for VPLS is 19. 422 +------------------------------------+ 423 | Extended community type (2 octets) | 424 +------------------------------------+ 425 | Encaps Type (1 octet) | 426 +------------------------------------+ 427 | Control Flags (1 octet) | 428 +------------------------------------+ 429 | Layer-2 MTU (2 octet) | 430 +------------------------------------+ 431 | Reserved (2 octets) | 432 +------------------------------------+ 434 Figure 3: Layer2 Info Extended Community 436 0 1 2 3 4 5 6 7 437 +-+-+-+-+-+-+-+-+ 438 | MBZ |C|S| (MBZ = MUST Be Zero) 439 +-+-+-+-+-+-+-+-+ 441 Figure 4: Control Flags Bit Vector 443 With reference to Figure 4, the following bits are defined; the MBZ 444 bits MUST be set to zero. 446 Name Meaning 447 C If set to 1 (0), Control word is (not) required when 448 encapsulating Layer 2 frames [10]. 449 S If set to 1 (0), Sequenced delivery of frames is (not) 450 required. 452 3.3 Multi-AS VPLS 454 As in [11] and [9], the above autodiscovery and signaling functions 455 are typically announced via I-BGP. This assumes that all the sites 456 in a VPLS are connected to PEs in a single Autonomous System (AS). 458 However, sites in a VPLS may connect to PEs in different ASes. This 459 leads to two issues: 1) there would not be an I-BGP connection 460 between those PEs, so some means of signaling across ASes may be 461 needed; and 2) there may not be PE-to-PE tunnels between the ASes. 463 A similar problem is solved in [9], Section 10. Three methods are 464 suggested to address issue (1); all these methods have analogs in 465 multi-AS VPLS. 467 Here is a diagram for reference: 469 __________ ____________ ____________ __________ 470 / \ / \ / \ / \ 471 \___/ AS 1 \ / AS 2 \___/ 472 \ / 473 +-----+ +-------+ | +-------+ +-----+ 474 | PE1 | ---...--- | ASBR1 | ======= | ASBR2 | ---...--- | PE2 | 475 +-----+ +-------+ | +-------+ +-----+ 476 ___ / \ ___ 477 / \ / \ / \ 478 \__________/ \____________/ \____________/ \__________/ 480 Figure 6: Inter-AS VPLS 482 3.3.1 a) VPLS-to-VPLS connections at the AS border routers. 484 In this method, an AS Border Router (ASBR1) acts as a PE for all 485 VPLSs that span AS1 and an AS to which ASBR1 is connected, such as 486 AS2 here. The ASBR on the neighboring AS (ASBR2) is viewed by ASBR1 487 as a CE for the VPLSs that span AS1 and AS2; similarly, ASBR2 acts as 488 a PE for this VPLS from AS2's point of view, and views ASBR1 as a CE. 490 This method does not require MPLS on the ASBR1-ASBR2 link, but does 491 require that this link carry Ethernet traffic, and that there be a 492 separate VLAN sub-interface for each VPLS traversing this link. It 493 further requires that ASBR1 does the PE operations (discovery, 494 signaling, MAC address learning, flooding, encapsulation, etc.) for 495 all VPLSs that traverse ASBR1. This imposes a significant burden on 496 ASBR1, both on the control plane and the data plane, which limits the 497 number of multi-AS VPLSs. 499 Note that in general, there will be multiple connections between a 500 pair of ASes, for redundancy. In this case, the Spanning Tree 501 Protocol (STP), or some other means of loop detection and prevention, 502 must be run on each VPLS that spans these ASes, so that a loop-free 503 topology can be constructed in each VPLS. This imposes a further 504 burden on the ASBRs and PEs participating in those VPLSs, as these 505 devices would need to run a loop detection algorithm for each such 506 VPLS. How this may be achieved is outside the scope of this 507 document. 509 3.3.2 b) EBGP redistribution of VPLS information between ASBRs. 511 This method requires I-BGP peerings between the PEs in AS1 and ASBR1 512 in AS1 (perhaps via route reflectors), an E-BGP peering between ASBR1 513 and ASBR2 in AS2, and I-BGP peerings between ASBR2 and the PEs in 514 AS2. In the above example, PE1 sends a VPLS NLRI to ASBR1 with a 515 label block and itself as the BGP nexthop; ASBR1 sends the NLRI to 516 ASBR2 with new labels and itself as the BGP nexthop; and ASBR2 sends 517 the NLRI to PE2 with new labels and itself as the nexthop. 519 The VPLS NLRI that ASBR1 sends to ASBR2 (and the NLRI that ASBR2 520 sends to PE2) is identical to the VPLS NLRI that PE1 sends to ASBR1, 521 except for the label block. To be precise, the Length, the Route 522 Distinguisher, the VE ID, the VE Block Offset, and the VE Block Size 523 MUST be the same; the Label Base may be different. Furthermore, 524 ASBR1 must also update its forwarding path as follows: if the Label 525 Base sent by PE1 is L1, the Label-block Size is N, the Label Base 526 sent by ASBR1 is L2, and the tunnel label from ASBR1 to PE1 is T, 527 then ASBR1 must install the following in the forwarding path: 528 swap L2 with L1 and push T, 529 swap L2+1 with L1+1 and push T, ... 530 swap L2+N-1 with L1+N-1 and push T. 532 ASBR2 must act similarly, except that it may not need a tunnel label 533 if it is directly connected with ASBR1. 535 When PE2 wants to send a VPLS packet to PE1, PE2 uses its VE ID to 536 get the right VPLS label from ASBR2's label block for PE1, and uses a 537 tunnel label to reach ASBR2. ASBR2 swaps the VPLS label with the 538 label from ASBR1; ASBR1 then swaps the VPLS label with the label from 539 PE1, and pushes a tunnel label to reach PE1. 541 In this method, one needs MPLS on the ASBR1-ASBR2 interface, but 542 there is no requirement that the link layer be Ethernet. 543 Furthermore, the ASBRs take part in distributing VPLS information. 544 However, the data plane requirements of the ASBRs is much simpler 545 than in method (a), being limited to label operations. Finally, the 546 construction of loop-free VPLS topologies is done by routing 547 decisions, viz. BGP path and nexthop selection, so there is no need 548 to run the Spanning Tree Protocol on a per-VPLS basis. Thus, this 549 method is considerably more scalable than method (a). 551 3.3.3 c) Multi-hop EBGP redistribution of VPLS information between 552 ASes. 554 In this method, there is a multi-hop E-BGP peering between the PEs 555 (or preferably, a Route Reflector) in AS1 and the PEs (or Route 556 Reflector) in AS2. PE1 sends a VPLS NLRI with labels and nexthop 557 self to PE2; if this is via route reflectors, the BGP nexthop is not 558 changed. This requires that there be a tunnel LSP from PE1 to PE2. 559 This tunnel LSP can be created exactly as in [9], section 10 (c), for 560 example using E-BGP to exchange labeled IPv4 routes for the PE 561 loopbacks. 563 When PE1 wants to send a VPLS packet to PE2, it pushes the VPLS label 564 corresponding to its own VE ID onto the packet. It then pushes the 565 tunnel label(s) to reach PE2. 567 This method requires no VPLS information (in either the control or 568 the data plane) on the ASBRs. The ASBRs only need to set up PE-to-PE 569 tunnel LSPs in the control plane, and do label operations in the data 570 plane. Again, as in the case of method (b), the construction of 571 loop-free VPLS topologies is done by routing decisions, i.e., BGP 572 path and nexthop selection, so there is no need to run the Spanning 573 Tree Protocol on a per-VPLS basis. This option is likely to be the 574 most scalable of the three methods presented here. 576 In order to ease the allocation of VE IDs for a VPLS that spans 577 multiple ASes, one can allocate ranges for each AS. For example, AS1 578 uses VE IDs in the range 1 to 100, AS2 from 101 to 200, etc. If 579 there are 10 sites attached to AS1 and 20 to AS2, the allocated VE 580 IDs could be 1-10 and 101 to 120. This minimizes the number of VPLS 581 NLRIs that are exchanged while ensuring that VE IDs are kept unique. 583 In the above example, if AS1 needed more than 100 sites, then another 584 range can be allocated to AS1. The only caveat is that there is no 585 overlap between VE ID ranges among ASes. The exception to this rule 586 is multi-homing, which is dealt with below. 588 3.4 Multi-homing and Path Selection 590 It is often desired to multi-home a VPLS site, i.e., to connect it to 591 multiple PEs, perhaps even in different ASes. In such a case, the 592 PEs connected to the same site can either be configured with the same 593 VE ID or with different VE IDs. In the latter case, it is mandatory 594 to run STP on the CE device, and possibly on the PEs, to construct a 595 loop-free VPLS topology. How this can be accomplished is outside the 596 scope of this document; however, the rest of this section will 597 describe in some detail the former case. 599 In the case where the PEs connected to the same site are assigned the 600 same VE ID, a loop-free topology is constructed by routing 601 mechanisms, in particular, by BGP path selection. When a BGP speaker 602 receives two equivalent NLRIs (see below for the definition), it 603 applies standard path selection criteria such as Local Preference and 604 AS Path Length to determine which NLRI to choose; it MUST pick only 605 one. If the chosen NLRI is subsequently withdrawn, the BGP speaker 606 applies path selection to the remaining equivalent VPLS NLRIs to pick 607 another; if none remain, the forwarding information associated with 608 that NLRI is removed. 610 Two VPLS NLRIs are considered equivalent from a path selection point 611 of view if the Route Distinguisher, the VE ID and the VE Block Offset 612 are the same. If two PEs are assigned the same VE ID in a given 613 VPLS, they MUST use the same Route Distinguisher, and they SHOULD 614 announce the same VE Block Size for a given VE Offset. 616 4. Data Plane 618 This section discusses two aspects of the data plane for PEs and 619 u-PEs implementing VPLS: encapsulation and forwarding. 621 4.1 Encapsulation 623 Ethernet frames received from CE devices are encapsulated for 624 transmission over the packet switched network connecting the PEs. 625 The encapsulation is as in [10], with one change: a PE that sets the 626 P bit in the Control Flags strips the outermost VLAN from an Ethernet 627 frame received from a CE before encapsulating it, and pushes a VLAN 628 onto a decapsulated frame before sending it to a CE. 630 4.2 Forwarding 632 VPLS packets are classified as belonging to a given service instance 633 and associated forwarding table based on the interface over which the 634 packet is received. Packets are forwarded in the context of the 635 service instance based on the destination MAC address. The former 636 mapping is determined by configuration. The latter is the focus of 637 this section. 639 4.2.1 MAC address learning 641 As was mentioned earlier, the key distinguishing feature of VPLS is 642 that it is a multipoint service. This means that the entire Service 643 Provider network should appear as a single logical learning bridge 644 for each VPLS that the SP network supports. The logical ports for 645 the SP "bridge" are the customer ports on all of the VE on a given 646 service. Just as a learning bridge learns MAC addresses on its 647 ports, the SP bridge must learn MAC addresses at its VEs. 649 Learning consists of associating source MAC addresses of packets with 650 the (logical) ports on which they arrive; this association is the 651 Forwarding Information Base (FIB). The FIB is used for forwarding 652 packets. For example, suppose the bridge receives a packet with 653 source MAC address S on (logical) port P. If subsequently, the 654 bridge receives a packet with destination MAC address S, it knows 655 that it should send the packet out on port P. 657 4.2.2 Flooding 659 When a bridge receives a packet to a destination that is not in its 660 FIB, it floods the packet on all the other ports. Similarly, a VE 661 will flood packets to an unknown destination to all other VEs in the 662 VPLS. 664 In Figure 1 above, if CE2 sent an Ethernet frame to PE2, and the 665 destination MAC address on the frame was not in PE2's FIB (for that 666 VPLS), then PE2 would be responsible for flooding that frame to every 667 other PE in the same VPLS. On receiving that frame, PE1 would be 668 responsible for further flooding the frame to CE1 and CE5 (unless PE1 669 knew which CE "owned" that MAC address). 671 On the other hand, if PE3 received the frame, it could delegate 672 further flooding of the frame to its u-PE. If PE3 was connected to 2 673 u-PEs, it would announce that it has two u-PEs. PE3 could either 674 announce that it is incapable of flooding, in which case it would 675 receive two frames, one for each u-PE, or it could announce that it 676 is capable of flooding, in which case it would receive one copy of 677 the frame, which it would then send to both u-PEs. 679 4.2.3 "Split Horizon" Forwarding 681 When a PE capable of flooding receives a broadcast Ethernet frame, or 682 one with an unknown destination MAC address, it must flood the frame. 683 If the frame arrived from an attached CE, the PE must send a copy of 684 the frame to every other attached CE, as well as to all PEs 685 participating in the VPLS. If the frame arrived from another PE, 686 however, the PE must only send a copy of the packet to attached CEs. 687 The PE MUST NOT send the frame to other PEs. This notion has been 688 termed "split horizon" forwarding, and is a consequence of the PEs 689 being logically full-meshed -- if a broadcast frame is received from 690 PEx, then PEx would have sent a copy to all other PEs. 692 Split horizon forwarding rules also apply to multicast frames (i.e., 693 those with a multicast destination MAC address). In this case, when 694 a PE receives a multicast frame from another PE, the frame is 695 replicated and sent to the relevant subset of attached CEs; however, 696 it MUST NOT be sent to other PEs. 698 5. Deployment Options 700 In deploying a network that supports VPLS, the SP must decide what 701 functions the VPLS-aware device closest to the customer (the VE) 702 supports. The default case described in this document is that the VE 703 is a PE. However, there are a number of reasons that the VE might be 704 a device that does all the Layer 2 functions (such as MAC address 705 learning and flooding), and a limited set of Layer 3 functions (such 706 as communicating to its PE), but, for example, doesn't do 707 full-fledged discovery and PE-to-PE signaling. Such a device is 708 called a "u-PE". 710 As both of these cases have benefits, one would like to be able to 711 "mix and match" these scenarios. The signaling mechanism presented 712 here allows this. For example, in a given provider network, one PE 713 may be directly connected to CE devices; another may be connected to 714 u-PEs that are connected to CEs; and a third may be connected 715 directly to a customer over some interfaces and to u-PEs over others. 716 All these PEs perform discovery and signaling in the same manner. 717 How they do learning and forwarding depends on whether or not there 718 is a u-PE; however, this is a local matter, and is not signaled. 719 However, the details of the operation of a u-PE and its interactions 720 with PEs and other u-PEs is beyond the scope of this document. 722 6. Security Considerations 724 The focus in Virtual Private LAN Service is the privacy of data, 725 i.e., that data in a VPLS is only distributed to other nodes in that 726 VPLS and not to any external agent or other VPLS. Note that VPLS 727 does not offer security or authentication: VPLS packets are sent in 728 the clear in the packet-switched network, and a man-in-the-middle can 729 eavesdrop, and may be able to inject packets into the data stream. 730 If security is desired, the PE-to-PE tunnels can be IPsec tunnels. 731 For more security, the end systems in the VPLS sites can use 732 appropriate means of encryption to secure their data even before it 733 enters the Service Provider network. 735 There are two aspects to achieving data privacy in a VPLS: securing 736 the control plane, and protecting the forwarding path. Compromise of 737 the control plane could result in a PE sending data belonging to some 738 VPLS to another VPLS, or blackholing VPLS data, or even sending it to 739 an eavesdropper, none of which are acceptable from a data privacy 740 point of view. Since all control plane exchanges are via BGP, 741 techniques such as in [2] help authenticate BGP messages, making it 742 harder to spoof updates (which can be used to divert VPLS traffic to 743 the wrong VPLS), or withdraws (denial of service attacks). In the 744 multi-AS options (b) and (c), this also means protecting the inter-AS 745 BGP sessions, between the ASBRs, the PEs or the Route Reflectors. 746 Note that [2] will not help in keeping VPLS labels private -- knowing 747 the labels, one can eavesdrop on VPLS traffic. However, this 748 requires access to the data path within a Service Provider network. 750 Protecting the data plane requires ensuring that PE-to-PE tunnels are 751 well-behaved (this is outside the scope of this document), and that 752 VPLS labels are accepted only from valid interfaces. For a PE, valid 753 interfaces comprise links from P routers. For an ASBR, a valid 754 interface is a link from an ASBR in an AS that is part of a given 755 VPLS. It is especially important in the case of multi-AS VPLSs that 756 one accept VPLS packets only from valid interfaces. 758 7. IANA Considerations 760 IANA is asked to allocate an AFI for Layer 2 information (suggested 761 value: 25). 763 8. References 765 8.1 Normative References 767 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 768 Levels", BCP 14, RFC 2119, March 1997. 770 [2] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 771 Signature Option", RFC 2385, August 1998. 773 [3] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, "Multiprotocol 774 Extensions for BGP-4", RFC 2858, June 2000. 776 [4] Sangli, S., Tappan, D. and Y. Rekhter, "BGP Extended Communities 777 Attribute", 778 Internet-Draft draft-ietf-idr-bgp-ext-communities-08, February 779 2005. 781 [5] Martini, L., Rosen, E., El-Aawar, N. and G. Heron, 782 "Encapsulation Methods for Transport of Ethernet Frames Over 783 IP/MPLS Networks", 784 Internet-Draft draft-ietf-pwe3-ethernet-encap-08, September 785 2004. 787 8.2 Informative References 789 [6] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 790 Private Networks (L2VPNs)", 791 Internet-Draft draft-ietf-l2vpn-l2-framework-05, June 2004. 793 [7] Lasserre, M. and V. Kompella, "Virtual Private LAN Services 794 over MPLS", Internet-Draft draft-ietf-l2vpn-vpls-ldp-05, 795 September 2004. 797 [8] Ould-Brahim, H., Rosen, E. and Y. Rekhter, "Using BGP as an 798 Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs", 799 Internet-Draft draft-ietf-l3vpn-bgpvpn-auto-04, May 2004. 801 [9] Rosen, E., "BGP/MPLS IP VPNs", 802 Internet-Draft draft-ietf-l3vpn-rfc2547bis-03, October 2004. 804 [10] Martini, L., "Pseudowire Setup and Maintenance using LDP", 805 Internet-Draft draft-ietf-pwe3-control-protocol-14, November 806 2004. 808 [11] Kompella, K., "Layer 2 VPNs Over Tunnels", 809 Internet-Draft draft-kompella-l2vpn-l2vpn-00, January 2004. 811 Authors' Addresses 813 Kireeti Kompella (editor) 814 Juniper Networks 815 1194 N. Mathilda Ave. 816 Sunnyvale, CA 94089 817 US 819 Email: kireeti@juniper.net 821 Yakov Rekhter (editor) 822 Juniper Networks 823 1194 N. Mathilda Ave. 824 Sunnyvale, CA 94089 825 US 827 Email: kireeti@juniper.net 829 Appendix A. Contributors 831 The following contributed to this document: 833 Javier Achirica, Telefonica 834 Loa Andersson, Acreo 835 Chaitanya Kodeboyina, Juniper 836 Giles Heron, Alcatel 837 Sunil Khandekar, Alcatel 838 Vach Kompella, Alcatel 839 Marc Lasserre, Riverstone 840 Pierre Lin 841 Pascal Menezes 842 Ashwin Moranganti, Appian 843 Hamid Ould-Brahim, Nortel 844 Seo Yeong-il, Korea Tel 846 Appendix B. Acknowledgements 848 Thanks to Joe Regan and Alfred Nothaft for their contributions. Many 849 thanks too to Eric Ji, Chaitanya Kodeboyina, and Mike Loomis for 850 their detailed reviews. 852 Intellectual Property Statement 854 The IETF takes no position regarding the validity or scope of any 855 Intellectual Property Rights or other rights that might be claimed to 856 pertain to the implementation or use of the technology described in 857 this document or the extent to which any license under such rights 858 might or might not be available; nor does it represent that it has 859 made any independent effort to identify any such rights. Information 860 on the procedures with respect to rights in RFC documents can be 861 found in BCP 78 and BCP 79. 863 Copies of IPR disclosures made to the IETF Secretariat and any 864 assurances of licenses to be made available, or the result of an 865 attempt made to obtain a general license or permission for the use of 866 such proprietary rights by implementers or users of this 867 specification can be obtained from the IETF on-line IPR repository at 868 http://www.ietf.org/ipr. 870 The IETF invites any interested party to bring to its attention any 871 copyrights, patents or patent applications, or other proprietary 872 rights that may cover technology that may be required to implement 873 this standard. Please address the information to the IETF at 874 ietf-ipr@ietf.org. 876 Disclaimer of Validity 878 This document and the information contained herein are provided on an 879 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 880 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 881 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 882 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 883 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 884 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 886 Copyright Statement 888 Copyright (C) The Internet Society (2005). This document is subject 889 to the rights, licenses and restrictions contained in BCP 78, and 890 except as set forth therein, the authors retain all their rights. 892 Acknowledgment 894 Funding for the RFC Editor function is currently provided by the 895 Internet Society.