idnits 2.17.1 draft-ietf-ppvpn-l2vpn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 186 has weird spacing: '...n order to pr...' == Line 318 has weird spacing: '...nneling techn...' == Line 319 has weird spacing: '...tion is used,...' -- 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 (July 2001) is 8320 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) == Outdated reference: A later version (-03) exists of draft-ouldbrahim-bgpvpn-auto-01 -- Possible downref: Normative reference to a draft: ref. 'AUTO' == Outdated reference: A later version (-12) exists of draft-martini-l2circuit-encap-mpls-01 ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-encap-mpls (ref. 'L2ENCAPS') == Outdated reference: A later version (-19) exists of draft-martini-l2circuit-trans-mpls-05 ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-trans-mpls (ref. 'L2SIG') -- Possible downref: Normative reference to a draft: ref. 'MPLSL2VPN' == Outdated reference: A later version (-04) exists of draft-rosen-rfc2547bis-03 -- Possible downref: Normative reference to a draft: ref. 'RFC2547bis' Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Eric C. Rosen 3 Internet Draft Clarence Filsfils 4 Expiration Date: January 2002 Cisco Systems, Inc. 6 Giles Heron Andrew G. Malis 7 Gone2 Ltd. Vivace Networks, Inc. 9 Luca Martini Steve Vogelsang 10 Level 3 Communications, LLC. Laurel Networks, Inc. 12 July 2001 14 An Architecture for L2VPNs 16 draft-ietf-ppvpn-l2vpn-00.txt 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 Service Providers may offer a "Layer 2 VPN Service" over an IP 42 backbone by provisioning point-to-point "virtual circuits" that run 43 through IP tunnels. This document discusses the signaling, 44 encapsulation, and configuration issues that arise. Its purpose is 45 to provide an architecture which allows different kinds of point-to- 46 point virtual circuits to be provided through different kinds of IP 47 tunnels. 49 Table of Contents 51 1 Boilerplate for Sub-IP Area Drafts ..................... 2 52 2 Introduction ........................................... 3 53 3 Outline of Architecture ................................ 4 54 4 Encapsulating .......................................... 6 55 5 Signaling .............................................. 6 56 6 Tunneling .............................................. 6 57 7 Configuration Models ................................... 7 58 7.1 Brute Force ............................................ 7 59 7.2 Eliminating Tunnel Configuration ....................... 8 60 7.3 Single Endpoint Configuration of Emulated VCs .......... 8 61 7.4 Single Endpoint Configuration of Attachment VCs ........ 9 62 7.5 Zero-Configuration Attachment VCs ...................... 9 63 7.6 Auto-discovery of remote CEs ........................... 10 64 8 References ............................................. 11 65 9 Authors' Information ................................... 11 67 1. Boilerplate for Sub-IP Area Drafts 69 This draft is targeted at the PPVPN WG, as it addresses the following 70 work item from the PPVPN WG charter: 72 "The working group is expected to consider at least three 73 specific approaches including ... port-based VPNs (i.e., 74 where the SP provides a Layer 2 interface, such as Frame 75 Relay or ATM, to the VPN customer, while using IP-based 76 mechanisms in the provider infrastructure" 78 The set of related documents may be found in the "References" 79 section. 81 2. Introduction 83 Enterprises have long built their own wide-area networks by 84 purchasing wide-area point-to-point data link layer connectivity from 85 service providers, and then building their own layer 3 infrastructure 86 on top of that. Originally the data links from the service provider 87 were leased lines, and the layer 3 overlays were termed "private 88 networks". Later, virtual circuits of various sorts (X.25, Frame 89 Relay, ATM) began to replace leased lines, and the layer 3 overlays 90 were termed "virtual private networks". (Though what makes a leased 91 line less virtual than an ATM VC is difficult to understand.) 93 We will refer to these VPNs as "Layer 2 VPNs" because the service 94 provider providers only a layer 2 interface to its customer, and the 95 customer is responsible for creating and managing the layer 3 96 overlay. 98 Today, layer 2 VPNs are usually offered over a Frame Relay or ATM 99 infrastructure. 101 There are still many enterprises that wish to manage their own layer 102 3 overlays, and many service providers who wish to provide layer 2 103 interfaces to such customers. However, many of these service 104 providers would like to replace their Frame Relay or ATM 105 infrastructures with an IP infrastructure. So it is desirable to 106 have standard ways of using an IP infrastructure to provide a layer 2 107 interface to customers. In particular, it is desirable to have 108 standard ways of using an IP infrastructure to provide virtual 109 circuits between pairs of customer sites. 111 The term "Layer 2 VPN" may be somewhat misleading, in that the SP 112 does not actually provide a VPN to the customer. The SP provides 113 layer 2 connectivity, and the customer builds his own VPN, using the 114 provided layer 2 connectivity as one of the building blocks. The 115 problem is really how to provide the layer 2 connectivity over an IP 116 backbone, rather than how to provide a network service over an IP 117 backbone. 119 Typically a customer will expect a certain amount of bandwidth from 120 each data link. The customer may build his network using data links 121 obtained from a variety of providers. 123 In an L2VPN service, the SP need not know about the customer's 124 topology, about the customer's policies, or about the customer's 125 routing. The SP need not even know whether all the point-to-point 126 links he is providing are used by the customer as part of the same 127 network, or whether a customer network has point-to-point links from 128 other providers as well. In essence the customer builds his own 129 network, using data link resources obtained from the SP. 130 Nevertheless, we will continue to use the term "Layer 2 VPN" (L2VPN), 131 as it is apparently well entrenched in the vernacular, despite its 132 technical inaccuracy. 134 We adopt the "Provider Edge" (PE) and "Customer Edge" (CE) 135 terminology from RFC2547 [RFC2547bis]. 137 Not all L2VPNs are built on top of point-to-point data link 138 connections. It is possible for an SP to provide an "emulated LAN" 139 service instead. In this case, the PE device is a LAN switch which 140 can serve multiple customers, and which can do SA learning and 141 Spanning Tree on a per-customer basis. Some sort of multicast 142 technique must be used for transmitting customer LAN multicasts and 143 unknown DA frames among the PEs which attach to a common customer. 144 The primary focus of this draft will however be on the provision of 145 point-to-point data link services. If the CE devices attaching to an 146 L2VPN's PE devices are LAN switches, the L2VPN may be thought of as a 147 "Transparent LAN Service", even if the SP provides only point-to- 148 point data link connections. 150 The provision of Emulated LAN services over IP backbone networks can 151 be added at a later date if there is sufficient interest. 153 3. Outline of Architecture 155 The general architecture for providing L2VPN services is the 156 following. A CE devices attaches to a PE device via some sort of 157 virtual circuit. We will call this the "Attachment VC". To provide 158 a layer 2 connection between CE1 and CE2, where CE1 attaches to PE1 159 and CE2 attaches to PE2, an "Emulated VC" must be carried across the 160 IP backbone from PE1 to PE2. At each of PE1 and PE2, the Emulated VC 161 is associated with an Attachment VC. In effect, the ordered triple 162 163 functions as a VC between CE1 and CE2. 165 The Emulated VC is carried in a "Tunnel" from PE1 to PE2. When there 166 are multiple Emulated VCs running from PE1 to PE2, a single Tunnel 167 should be able to carry a large number of Emulated VCs. There should 168 be no requirement that two Emulated VCs in a common tunnel have the 169 same CE endpoints. When PE2 removes a packet from a Tunnel, it 170 associates the packet with an Emulated VC. The association of the 171 Emulated VC with an Attachment VC determines the CE to which the 172 packet is sent. 174 There should be no requirement that all VCs going from PE1 to PE2 175 travel in the same tunnel. 177 If the two Attachment VCs associated with an Emulated VC are of the 178 same type (e.g., both Frame Relay, both ATM), the Emulated VC may 179 need to carry some type-specific information with each packet. If 180 the two Attachment VCs are not of the same type, one or the other end 181 of the Emulated VC must perform some sort of inter-working function. 183 It is desired to allow a variety of different tunneling technologies 184 to be used for the PE-PE Tunnels. 186 In order to provide this sort of L2VPN architecture in a standard 187 way, the following need to be standardized: 189 - Tunneling Protocols. The architecture allows any number of 190 different tunneling protocols to be used, but each should be 191 standardized. 193 * Signaling. The standard for a tunneling protocol will 194 generally include a signaling protocol, so that tunnels can 195 be set up dynamically, and tunnel control information can be 196 passed from one tunnel endpoint to another. 198 * Encapsulation The standard for a tunneling protocol always 199 includes a way to encapsulate data packets in the tunnel. 201 * Multiplexing. Most tunneling protocols allow for multiple 202 streams to be encapsulated inside a single tunnel. They do 203 this by supporting a multiplexing field. To support L2VPNs, 204 each Emulated VC in the tunnel should correspond to a 205 distinct value of the tunnel multiplexing field. It is 206 important to note that this multiplexing field belongs to the 207 tunneling protocol, not to the data packet that is 208 encapsulated in the tunnel. 210 - Signaling Protocols for the Emulated VCs. A protocol is needed 211 to setup and maintain the Emulated VCs that are carried within 212 the tunnels. This protocol does not set up the tunnels, but only 213 the Emulated VCs within the tunnels. 215 Note though that to set up an Emulated VC, one must set up the 216 multiplexing field value which the tunnel protocol will use when 217 carrying packets of that Emulated VC. This strongly suggests 218 that the signaling protocol for setting up an Emulated VC be 219 specific to the particular tunneling technology that is being 220 used. 222 - Encapsulations for the user data frames. For each kind of layer 223 2 frame that may be received on an Attachment VC, an 224 encapsulation must be specified that allows the frame and its 225 related per-frame control information to be carried within the 226 Emulated VC. 228 While not strictly required for standardization, it is also important 229 to discuss the configuration model for setting up the L2VPN service. 230 If it turns out that the configuration model can be considerably 231 simplified through the use of an auto-discovery mechanism, the auto- 232 discovery mechanism will need to be standardized. 234 4. Encapsulating 236 An encapsulation for User Data Frames is proposed in [L2ENCAPS]. 237 Actually, that draft proposes both a tunnel-independent encapsulation 238 for user data frames, as well as the method for encapsulating the 239 frames within an MPLS tunnel. We propose to adopt the tunnel- 240 independent encapsulation specified therein. 242 5. Signaling 244 As we stated in the introduction, the signaling used to setup and 245 maintain the Emulated VCs should depend on the particular tunneling 246 technology. If MPLS is to be used as the tunneling technology, the 247 procedures specified in [L2SIG]. That draft proposes to use 248 extensions to the standard MPLS signaling (LDP) to set up the 249 multiplexing field (itself an MPLS label) for the Emulated VC, as 250 well as to setup and pass other control information needed to 251 maintain the Emulated VC. 253 If the tunneling technology is L2TP or IPsec, then the signaling 254 protocols which are native to those tunnel technologies should be 255 similarly extended. 257 6. Tunneling 259 In the case where MPLS is the tunneling technology, [L2SIG] specifies 260 the way in which frames on one or more Emulated VCs are to be carried 261 in an MPLS LSP. 263 Similar drafts are needed for L2TP and IPsec tunnels. 265 7. Configuration Models 267 It can be somewhat unwieldy to configure a large number of point-to- 268 point VCs. Therefore a number of L2VPN proposals focus on methods of 269 simplifying the configuration, either by adding additional signaling 270 mechanisms, or by adding auto-configuration and auto-discovery 271 mechanisms, or both. The current proposal is to separate the 272 signaling from any auto-configuration or auto-discovery mechanisms. 273 Then we can discuss separately the procedures for signaling, given a 274 particular configuration, and the procedures for creating the that 275 configuration in the first place. 277 This approach differs from the approach of RFC2547 for layer 3 VPNs; 278 there the auto-discovery of VPN sites is combined with the signaling 279 of MPLS labels for VPN routes. What we propose here is more like the 280 way auto-discovery is separated from virtual circuit setup in the 281 Virtual Router (VR) model of layer 3 VPNs. (See, e.g., [AUTO].) In 282 both the L2VPN case and the VR case, it is necessary to set up data 283 link connections which go from one PE to another. In the RFC2547 284 case, there are no cross-network data link connections set up. 285 Setting up a point-to-point data link connection requires signaling 286 of the sort specified in [L2SIG], and cannot be properly automated as 287 a side effect of the auto-discovery procedures. 289 7.1. Brute Force 291 In order to provide L2PVN service connecting CE1 and CE2, one 292 configuration model is the following: 294 - CE1 must be configured with an Attachment VC to PE1. Call this 295 A1. 296 - PE1 must be configured with that same Attachment VC (to CE1). 297 - CE2 must be configured with an Attachment VC to PE2. Call this 298 A2. 299 - PE2 must be configured with that same attachment VC (to CE2). 300 - PE1 must be configured with an identified Emulated VC to PE2. 301 - PE2 must be configured with an identified Emulated VC to PE1; the 302 identifier should be the same at both PEs, and the triple must be unique. Call this E. 304 - PE1 must be configured to associate A1 with E. 305 - PE2 must be configured to associate A2 with E. 306 - PE1 must be configured with a tunnel, T1, to PE2, and a tunnel, 307 T2, from PE2. PE2 must be configured with a tunnel, T1, from 308 PE1, and a tunnel, T2, to PE1. 310 - PE1 must be configured to associate E with T1 and T2. 311 - PE2 must be configured to associate E with T1 and T2. 313 Note also that A1, E, and A2 may have specific properties that need 314 to be configured, e.g., QoS, bandwidth, etc. 316 7.2. Eliminating Tunnel Configuration 318 If MPLS is the tunneling technology, and LDP downstream 319 unsolicited label distribution is used, it is NOT necessary to 320 configure T1 and T2, or to explicitly associate E with them. The 321 necessary tunnel exists automatically as long as there is a route 322 from one PE to the other. 324 7.3. Single Endpoint Configuration of Emulated VCs 326 We assumed above that the Emulated VC signaling required that a 327 particular Emulated VC be configured at both PE endpoints. This 328 isn't necessarily the case. If the Emulated VC signaling protocol 329 allows an Emulated VC to be set up based on the configuration of just 330 a single endpoint, there is no need to configure the other endpoint, 331 and those steps can be removed. 333 This enables the configuration model to be simplified to: 335 - CE1 must be configured with an Attachment VC to PE1. Call this 336 A1. 337 - PE1 must be configured with that same Attachment VC (to CE1). 338 - CE2 must be configured with an Attachment VC to PE2. Call this 339 A2. 340 - PE2 must be configured with that same attachment VC (to CE2). 341 - PE1 must be configured with an identified Emulated VC to PE2. 342 - PE1 must be configured to associate A1 and A2 with E. 344 In this case, PE1 must tell PE2 to associate A2 with E. If E has 345 specified properties, PE1 needs to be configured with these, and must 346 tell PE2 about them. 348 It is not completely obvious whether single endpoint configuration of 349 Emulated VCs is really worthwhile. The provisioning system that 350 configures the Emulated VCs will generally have to consult the 351 configuration of both endpoint PEs to determine the availability of 352 Attachment VCs, to set up QoS for Attachment VCs, etc. In any event, 353 the signaling procedures of draft- martini-l2circuit-trans-mpls are 354 easily extended to handle the case of signaling Emulated VCs that are 355 configured at only one endpoint. 357 7.4. Single Endpoint Configuration of Attachment VCs 359 The need to configure the Attachment VCs on BOTH the CE and the PE 360 could be eliminated by an appropriate LMI. Then an Attachment VC 361 could be configured just on the PE, and the PE would use the LMI to 362 inform the CE. The feasibility of this depends on the particular 363 technology used for the Attachment VC, and whether such LMI 364 procedures exist for that technology. If they do, they exist whether 365 or not an L2VPN service of the sort envisioned here is being offered, 366 so we need not consider this any further. 368 We have assumed that the L2VPN service will be a PVC rather than an 369 SVC service. A model for supporting an SVC service is discussed in 370 draft-ouldbrahim-bgpgmpls-ovpn. With the SVC model, the need to 371 configure the Attachment VC (or the Emulated VC) on the PE could be 372 eliminated. We do not further consider this here. 374 7.5. Zero-Configuration Attachment VCs 376 In the "Zero-Configuration of Attachment VCs" model, only the 377 Emulated VC is configured (at one or both endpoints). The signaling 378 of the Emulated VC doesn't specify a particular Attachment VC to 379 associate it with, nor is a particular Attachment VC configured to be 380 associated with the Emulated VC. Rather, the Emulated VC is simply 381 associated with an interface at each end. When the Emulated VC is 382 set up, each endpoint PE creates an Attachment VC on the specified 383 interface, and some sort of LMI or signaling procedure is used to 384 inform the CE of this. 386 Whether this is feasible depends on the particular technology used 387 for the Attachment VCs. To the extent that an Attachment VC uses a 388 scarce resource, this is not really feasible. For example, if the CE 389 and the PE are connected via an ATM or Frame Relay switch, one could 390 not automatically create an Attachment VC when the Emulated VC is 391 setup. An Attachment VC in these technologies requires a switch 392 cross-connect entry, and these scarce resources might not be 393 available in the absence of an explicit provisioning process. As 394 another example, if the Attachment VCs must have specific QoS 395 properties, it might be necessary to do explicit provisioning to 396 ensure that the necessary QoS characteristics can be met. 398 On the other hand, if an Attachment VC is nothing more than the value 399 of some multiplexing field, with no particular QoS characteristics, 400 and no use of switches between PE and CE, then it might be feasible 401 to create the Attachment VCs automatically as a side-effect of 402 setting up an Emulated VC. The procedures for doing this would 403 depend on the technology used for the Attachment VCs. 405 7.6. Auto-discovery of remote CEs 407 If an L2VPN is to have a hub and spoke topology, some further 408 simplification of the configuration could be made, as one could 409 provide some sort of auto-discovery of the hub CE. Then when a new 410 spoke CE is attached to a PE, the PE would automatically determine 411 which other PE attaches the corresponding hub CE. 413 Then when one adds a new spoke CE to the L2VPN, one wouldn't have to 414 explicitly configure the attached PE with the information about how 415 to reach the hub. However, a hub and spoke topology is already 416 simple to configure, and this additional simplification is probably 417 not worth the additional mechanism. 419 If an L2VPN is to have a fully meshed topology, simplification of the 420 configuration could be made. If a PE is attached to a CE of a 421 particular VPN, it could auto-discover all the other PEs that are 422 attached to CEs of the same VPN, and could discover for each such PE 423 the set of CEs in that VPN to which it is attached. This could be 424 done using the auto-discovery techniques first described in RFC2547 425 and later extended and generalized in [AUTO]. Once a PE discovers 426 the complete set of CEs in a given VPN, it can signal an Emulated VC 427 from itself to each other PE that has a CE attached to the same VPN; 428 the Emulated VC thus need not be explicitly configured. (This does 429 presuppose that the Emulated VCs are of uniform characteristics. If 430 each has some specific QoS property, for example, then this degree of 431 auto-discovery would be impossible, and more explicit provisioning 432 would be required.) 434 If the Attachment VC technology used by that VPN allows for Zero- 435 Configuration Attachment VCs, a full mesh of point-to-point (CE-CEs) 436 virtual circuits could be set up, with very little configuration. A 437 PE would just need to be configured to know which VPN each of its CEs 438 belongs to. 440 Whether this sort of auto-discovery is worthwhile is somewhat 441 dubious, though, since it only really pays off if the L2VPN consists 442 of a full mesh of point-to-point connections, and this is a very 443 unusual topology. (Whereas a full mesh of L3 connectivity is the 444 common case, a full mesh of L2 connections is rather uncommon.) As 445 discussed in draft-ouldbrahim-bgvpn- auto, additional configuration 446 information ("colors") could be added to facilitate different 447 topologies, but once one departs from either the hub and spoke or the 448 full mesh topology, figuring out how to make the right topology 449 auto-configure itself quickly becomes more difficult than explicitly 450 provisioning it. 452 An auto-discovery scheme of this sort, though combined with a 453 particular signaling and encapsulation scheme, is detailed in 454 [MPLSL2VPN]. 456 8. References 458 [AUTO] "Using BGP as an Auto-Discovery Mechanism for Network-based 459 VPNs", Ould-Brahim, et. al., draft-ouldbrahim-bgpvpn-auto-01.txt, 460 3/01. 462 [L2ENCAPS] "Encapsulation Methods for Transport of Layer 2 Frames 463 Over MPLS", Martini, et. al., draft-martini-l2circuit-encap-mpls- 464 01.txt, 2/01. 466 [L2SIG] "Transport of Layer 2 Frames Over MPLS", Martini, et. al., 467 draft-martini-l2circuit-trans-mpls-05.txt, 2/01. 469 [MPLSL2VPN] "MPLS-based Layer 2 VPNs", Kompella, et. al., draft- 470 kompella-mpls-l2vpn-02.txt, 11/00. 472 [RFC2547bis] "BGP/MPLS VPNs", Rosen et. al. draft-rosen-rfc2547bis- 473 03.txt, 3/01. 475 9. Authors' Information 477 Eric C. Rosen 478 Cisco Systems, Inc. 479 250 Apollo Drive 480 Chelmsford, MA, 01824 482 E-mail: erosen@cisco.com 484 Clarence Filsfils 485 Cisco Systems, Inc. 486 Avenue Marcel Thiry, 77 487 B-1200 Brussels Belgium 489 E-mail: cfilsfil@cisco.com 490 Giles Heron 491 Gone2 Ltd. 492 c/o MDP 493 One Curzon Street 494 London 495 W1J 5HD 496 United Kingdom 497 e-mail: giles@goneto.net 499 Andrew G. Malis 500 Vivace Networks, Inc. 501 2730 Orchard Parkway 502 San Jose, CA 95134 503 Phone: +1 408 383 7223 504 Email: Andy.Malis@vivacenetworks.com 506 Luca Martini 507 Level 3 Communications, LLC. 508 1025 Eldorado Blvd. 509 Broomfield, CO, 80021 510 e-mail: luca@level3.net 512 Steve Vogelsang 513 Laurel Networks, Inc. 514 2607 Nicholson Rd. 515 Sewickley, PA 15143 516 e-mail: sjv@laurelnetworks.com