idnits 2.17.1 draft-ietf-l2vpn-signaling-06.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1362. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1352. ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (September 9, 2005) is 6803 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DTLS' is mentioned on line 807, but not defined == Missing Reference: 'LPE' is mentioned on line 807, but not defined == Missing Reference: '2547bis' is mentioned on line 1207, but not defined == Missing Reference: 'L2VPN-REQS' is mentioned on line 1203, but not defined == Unused Reference: 'BRADNER' is defined on line 1239, but no explicit reference was found in the text == Unused Reference: 'MP-BGP' is defined on line 1242, but no explicit reference was found in the text == Unused Reference: 'EXT-COMM' is defined on line 1245, but no explicit reference was found in the text == Unused Reference: 'RFC2685' is defined on line 1288, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2858 (ref. 'MP-BGP') (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) == Outdated reference: A later version (-09) exists of draft-ietf-l3vpn-bgpvpn-auto-05 == Outdated reference: A later version (-07) exists of draft-ietf-l2tpext-l2vpn-05 == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-requirements-04 == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-iana-allocation-11 == Outdated reference: A later version (-09) exists of draft-ietf-l2vpn-vpls-ldp-06 == Outdated reference: A later version (-08) exists of draft-ietf-l2vpn-vpls-bgp-05 == Outdated reference: A later version (-01) exists of draft-metz-aii-aggregate-00 Summary: 5 errors (**), 0 flaws (~~), 18 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Rosen 3 Internet-Draft W. Luo 4 Expires: March 13, 2006 B. Davie 5 Cisco Systems, Inc. 6 V. Radoaca 7 September 9, 2005 9 Provisioning, Autodiscovery, and Signaling in L2VPNs 10 draft-ietf-l2vpn-signaling-06.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 22 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 March 13, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 There are a number of different kinds of "Provider Provisioned Layer 44 2 VPNs" (L2VPNs). The different kinds of L2VPN may have different 45 "provisioning models", i.e., different models for what information 46 needs to be configured in what entities. Once configured, the 47 provisioning information is distributed by a "discovery process". 48 When the discovery process is complete, a signaling protocol is 49 automatically invoked. The signaling protocol sets up the mesh of 50 Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. Any 51 PW signaling protocol needs to have a method which allows each PW 52 endpoint to identify the other; thus a PW signaling protocol will 53 have the notion of an endpoint identifier. The semantics of the 54 endpoint identifiers which the signaling protocol uses for a 55 particular type of L2VPN are determined by the provisioning model. 56 This document specifies a number of L2VPN provisioning models, and 57 further specifies the semantic structure of the endpoint identifiers 58 required by each provisioning model. It discusses the way in which 59 the endpoint identifiers are distributed by the discovery process, 60 especially when the discovery process is based upon the Border 61 Gateway Protocol (BGP). It then specifies how the endpoint 62 identifiers are carried in the two signaling protocols that are used 63 to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2 64 Tunneling Protocol (L2TPv3). 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Signaling Protocol Framework . . . . . . . . . . . . . . . . . 7 71 2.1. Endpoint Identification . . . . . . . . . . . . . . . . . 7 72 2.2. Creating a Single Bidirectional Pseudowire . . . . . . . . 8 73 2.3. Attachment Identifiers and Forwarders . . . . . . . . . . 9 75 3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 3.1. Individual Point-to-Point Pseudowires . . . . . . . . . . 11 77 3.1.1. Provisioning Models . . . . . . . . . . . . . . . . . 11 78 3.1.1.1. Double Sided Provisioning . . . . . . . . . . . . 11 79 3.1.1.2. Single Sided Provisioning with Discovery . . . . . 11 80 3.1.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 12 81 3.2. Virtual Private LAN Service . . . . . . . . . . . . . . . 13 82 3.2.1. Provisioning . . . . . . . . . . . . . . . . . . . . . 13 83 3.2.2. Auto-Discovery . . . . . . . . . . . . . . . . . . . . 14 84 3.2.2.1. BGP-based auto-discovery . . . . . . . . . . . . . 14 85 3.2.3. Signaling . . . . . . . . . . . . . . . . . . . . . . 15 86 3.2.4. Pseudowires as VPLS Attachment Circuits . . . . . . . 16 87 3.3. Colored Pools: Full Mesh of Point-to-Point Pseudowires . . 16 88 3.3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . 16 89 3.3.2. Auto-Discovery . . . . . . . . . . . . . . . . . . . . 17 90 3.3.2.1. BGP-based auto-discovery . . . . . . . . . . . . . 17 91 3.3.3. Signaling . . . . . . . . . . . . . . . . . . . . . . 18 92 3.4. Colored Pools: Partial Mesh . . . . . . . . . . . . . . . 19 93 3.5. Distributed VPLS . . . . . . . . . . . . . . . . . . . . . 20 94 3.5.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 22 95 3.5.2. Provisioning and Discovery . . . . . . . . . . . . . . 23 96 3.5.3. Non-distributed VPLS as a sub-case . . . . . . . . . . 24 97 3.5.4. Splicing and the Data Plane . . . . . . . . . . . . . 24 99 4. Inter-AS Operation . . . . . . . . . . . . . . . . . . . . . . 25 100 4.1. Multihop EBGP redistribution of L2VPN NLRIs . . . . . . . 25 101 4.2. EBGP redistribution of L2VPN NLRIs with Pseudowire 102 Switching . . . . . . . . . . . . . . . . . . . . . . . . 26 103 4.3. Inter-Provider Application of Dist. VPLS Signaling . . . . 27 104 4.4. RT and RD Assignment Considerations . . . . . . . . . . . 28 106 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29 108 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 110 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 112 8. Normative References . . . . . . . . . . . . . . . . . . . . . 32 113 9. Informative References . . . . . . . . . . . . . . . . . . . . 33 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 116 Intellectual Property and Copyright Statements . . . . . . . . . . 35 118 1. Introduction 120 [L2VPN-FW] describes a number of different ways in which sets of 121 pseudowires may be combined together into "Provider Provisioned Layer 122 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of different 123 kinds of L2VPN. Different kinds of L2VPN may have different 124 "provisioning models", i.e., different models for what information 125 needs to be configured in what entities. Once configured, the 126 provisioning information is distributed by a "discovery process", and 127 once the information is discovered, the signaling protocol is 128 automatically invoked to set up the required pseudowires. The 129 semantics of the endpoint identifiers which the signaling protocol 130 uses for a particular type of L2VPN are determined by the 131 provisioning model. That is, different kinds of L2VPN, with 132 different provisioning models, require different kinds of endpoint 133 identifiers. This document specifies a number of PPVPN provisioning 134 models, and specifies the semantic structure of the endpoint 135 identifiers required for each provisioning model. 137 Either LDP (as specified in [LDP] and extended in [PWE3-CONTROL]) or 138 L2TP version 3 (as specified in [L2TP-BASE] and extended in [L2TP- 139 L2VPN]) can be used as signaling protocols to set up and maintain 140 pseudowires (PWs) [PWE3-ARCH]. Any protocol which sets up 141 connections must provide a way for each endpoint of the connection to 142 identify the other; each PW signaling protocol thus provides a way to 143 identify the PW endpoints. Since each signaling protocol needs to 144 support all the different kinds of L2VPN and provisioning models, the 145 signaling protocol must have a very general way of representing 146 endpoint identifiers, and it is necessary to specify rules for 147 encoding each particular kind of endpoint identifier into the 148 relevant fields of each signaling protocol. This document specifies 149 how to encode the endpoint identifiers of each provisioning model 150 into the LDP and L2TPv3 signaling protocols. 152 We make free use of terminology from [L2VPN-FW], [L2VPN-TERM], and 153 [PWE3-ARCH], in particular the terms "Attachment Circuit", 154 "pseudowire", "PE", "CE". 156 Section 2 provides an overview of the relevant aspects of [PWE3- 157 CONTROL] and [L2TP-L2VPN]. 159 Section 3 details various provisioning models and relates them to the 160 signaling process and to the discovery process. The way in which the 161 signaling mechanisms can be integrated with BGP-based auto-discovery 162 is covered in some detail. 164 Section 4 explains how the procedures for discovery and signaling can 165 be applied in a multi-AS environment and outlines several options for 166 the establishment of multi-AS L2VPNs. 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119 172 2. Signaling Protocol Framework 174 2.1. Endpoint Identification 176 Per [L2VPN-FW], a pseudowire can be thought of as a relationship 177 between a pair of "Forwarders". In simple instances of VPWS, a 178 Forwarder binds a pseudowire to a single Attachment Circuit, such 179 that frames received on the one are sent on the other, and vice 180 versa. In VPLS, a Forwarder binds a set of pseudowires to a set of 181 Attachment Circuits; when a frame is received from any member of that 182 set, a MAC address table is consulted (and various 802.1d procedures 183 executed) to determine the member or members of that set on which the 184 frame is to be transmitted. In more complex scenarios, Forwarders 185 may bind PWs to PWs, thereby "splicing" two PWs together; this is 186 needed, e.g., to support distributed VPLS and some inter-AS 187 scenarios. 189 In simple VPWS, where a Forwarder binds exactly one PW to exactly one 190 Attachment Circuit, a Forwarder can be identified by identifying its 191 Attachment Circuit. In simple VPLS, a Forwarder can be identified by 192 identifying its PE device and its VPN. 194 To set up a PW between a pair of Forwarders, the signaling protocol 195 must allow the Forwarder at one endpoint to identify the Forwarder at 196 the other. In [PWE3-CONTROL], the term "Attachment Identifier", or 197 "AI", is used to refer to a quantity whose purpose is to identify a 198 Forwarder. In [L2TP-L2VPN], the term "Forwarder Identifier" is used 199 for the same purpose. In the context of this document, "Attachment 200 Identifier" and "Forwarder Identifier" are used interchangeably. 202 [PWE3-CONTROL] specifies two FEC elements that can be used when 203 setting up pseudowires, the PWid FEC element, and the Generalized Id 204 FEC element. The PWid FEC element carries only one Forwarder 205 identifier; it can be thus be used only when both forwarders have the 206 same identifier, and when that identifier can be coded as a 32-bit 207 quantity. The Generalized Id FEC element carries two Forwarder 208 identifiers, one for each of the two Forwarders being connected. 209 Each identifier is known as an Attachment Identifier, and a signaling 210 message carries both a "Source Attachment Identifier" (SAI) and a 211 "Target Attachment Identifier" (TAI). 213 The Generalized ID FEC element also provides some additional 214 structuring of the identifiers. It is assumed that the SAI and TAI 215 will sometimes have a common part, called the "Attachment Group 216 Identifier" (AGI), such that the SAI and TAI can each be thought of 217 as the concatenation of the AGI with an "Attachment Individual 218 Identifier" (AII). So the pair of identifiers is encoded into three 219 fields: AGI, Source AII (SAII), and Target AII (TAII). The SAI is 220 the concatenation of the AGI and the SAII, while the TAI is the 221 concatenation of the AGI and the TAII. 223 Similarly, [L2TP-L2VPN] allows using one or two Forwarder Identifiers 224 to set up pseudowires. If only the target Forwarder Identifier is 225 used in L2TP signaling messages, both the source and target 226 Forwarders are assumed to have the same value. If both the source 227 and target Forwarder Identifiers are carried in L2TP signaling 228 messages, each Forwarder uses a locally significant identifier value. 230 The Forwarder Identifier in [L2TP-L2VPN] is an equivalent term as 231 Attachment Identifier in [PWE3-CONTROL]. A Forwarder Identifier also 232 consists of an Attachment Group Identifier and an Attachment 233 Individual Identifier. Unlike the Generalized ID FEC element, the 234 AGI and AII are carried in distinct L2TP Attribute-Value-Pairs 235 (AVPs). The AGI is encoded in the AGI AVP, and the SAII and TAII are 236 encoded in the Local End ID AVP and the Remote End ID AVP 237 respectively. The source Forwarder Identifier is the concatenation 238 of the AGI and SAII, while the target Forwarder Identifier is the 239 concatenation of the AGI and TAII. 241 In applications that group sets of PWs into "Layer 2 Virtual Private 242 Networks", the AGI can be thought of as a "VPN Identifier". 244 It should be noted that while different forwarders support different 245 applications, the type of application (e.g., VPLS vs. VPWS) cannot 246 necessarily be inferred from the forwarders' identifiers. A router 247 receiving a signaling message with a particular TAI will have to be 248 able to determine which of its local forwarders is identified by that 249 TAI, and to determine the application provided by that forwarder. 250 But other nodes may not be able to infer the application simply by 251 inspection of the signaling messages. 253 In this document some further structure of the AGI and AII is 254 proposed for certain L2VPN applications. We note that [PWE3-CONTROL] 255 defines a TLV structure for AGI and AII fields. Thus, an operator 256 who chooses to use the AII structure defined here could also make use 257 of different AGI or AII types if he also wanted to use a different 258 structure for these identifiers for some other application. For 259 example, the long prefix type of [AII-TYPES] could be used to enable 260 the communication of administrative information, perhaps combined 261 with information learned during autodiscovery. 263 2.2. Creating a Single Bidirectional Pseudowire 265 In any form of LDP-based signaling, each PW endpoint must initiate 266 the creation of a unidirectional LSP. A PW is a pair of such LSPs. 267 In most of the PPVPN provisioning models, the two endpoints of a 268 given PW can simultaneously initiate the signaling for it. They must 269 therefore have some way of determining when a given pair of LSPs are 270 intended to be associated together as a single PW. 272 The way in which this association is done is different for the 273 various different L2VPN services and provisioning models. The 274 details appear in later sections. 276 L2TP signaling inherently establishes a bidirectional session that 277 carries a PW between two PW endpoints. The two endpoints can also 278 simultaneously initiate the signaling for a given PW. It is possible 279 that two PWs can be established for a pair of Forwarders. 281 In order to avoid setting up duplicated pseudowires between two 282 Forwarders, each PE must be able to independently detect such a 283 pseudowire tie. The procedures of detecting a pseudowire tie is 284 described in [L2TP-L2VPN] 286 2.3. Attachment Identifiers and Forwarders 288 Every Forwarder in a PE must be associated with an Attachment 289 Identifier (AI), either through configuration or through some 290 algorithm. The Attachment Identifier must be unique in the context 291 of the PE router in which the Forwarder resides. The combination must be globally unique. 294 As specified in [PWE3-CONTROL], the Attachment Identifier may consist 295 of an Attachment Group Identifier (AGI) plus an Attachment Individual 296 Identifier (AII). In the context of this document, an AGI may be 297 thought of as a VPN-id, or a VLAN identifier, some attribute which is 298 shared by all the Attachment Circuits which are allowed to be 299 connected. 301 It is sometimes helpful to consider a set of attachment circuits at a 302 single PE to belong to a common "pool". For example a set of 303 attachment circuits that connect a single CE to a given PE may be 304 considered a pool. The use of pools is described in detail in 305 Section 3.3. 307 The details for how to construct the AGI and AII fields identifying 308 the pseudowire endpoints in particular provisioning models are 309 discussed later in this paper. 311 We can now consider an LSP for one direction of a pseudowire to be 312 identified by: 314 o , PE2, > 316 and the LSP in the opposite direction of the pseudowire will be 317 identified by: 319 o , PE1, > 321 A pseudowire is a pair of such LSPs. In the case of using L2TP 322 signaling, these refer to the two directions of an L2TP session. 324 When a signaling message is sent from PE1 to PE2, and PE1 needs to 325 refer to an Attachment Identifier which has been configured on one of 326 its own Attachment Circuits (or pools), the Attachment Identifier is 327 called a "Source Attachment Identifier". If PE1 needs to refer to an 328 Attachment Identifier which has been configured on one of PE2's 329 Attachment Circuits (or pools), the Attachment Identifier is called a 330 "Target Attachment Identifier". (So an SAI at one endpoint is a TAI 331 at the remote endpoint, and vice versa.) 333 In the signaling protocol, we define encodings for the following 334 three fields: 336 o Attachment Group Identifier (AGI) 338 o Source Attachment Individual Identifier (SAII) 340 o Target Attachment Individual Identifier (TAII) 342 If the AGI is non-null, then the SAI consists of the AGI together 343 with the SAII, and the TAI consists of the TAII together with the 344 AGI. If the AGI is null, then the SAII and TAII are the SAI and TAI 345 respectively. 347 The intention is that the PE which receives an LDP Label Mapping 348 message or an L2TP Incoming Call Request (ICRQ) message containing a 349 TAI will be able to map that TAI uniquely to one of its Attachment 350 Circuits (or pools). The way in which a PE maps a TAI to an 351 Attachment Circuit (or pool) should be a local matter (including the 352 choice of whether to use some or all of the bytes in the TAI for the 353 mapping). So as far as the signaling procedures are concerned, the 354 TAI is really just an arbitrary string of bytes, a "cookie". 356 3. Applications 358 In this section, we specify the way in which the pseudowire signaling 359 using the notion of source and target Forwarder is applied for a 360 number of different applications. For some of the applications, we 361 specify the way in which different provisioning models can be used. 362 However, this is not meant to be an exhaustive list of the 363 applications, or an exhaustive list of the provisioning models that 364 can be applied to each application. 366 3.1. Individual Point-to-Point Pseudowires 368 The signaling specified in this document can be used to set up 369 individually provisioned point-to-point pseudowires. In this 370 application, each Forwarder binds a single PW to a single Attachment 371 Circuit. Each PE must be provisioned with the necessary set of 372 Attachment Circuits, and then certain parameters must be provisioned 373 for each Attachment Circuit. 375 3.1.1. Provisioning Models 377 3.1.1.1. Double Sided Provisioning 379 In this model, the Attachment Circuit must be provisioned with a 380 local name, a remote PE address, and a remote name. During 381 signaling, the local name is sent as the SAII, the remote name as the 382 TAII, and the AGI is null. If two Attachment Circuits are to be 383 connected by a PW, the local name of each must be the remote name of 384 the other. 386 Note that if the local name and the remote name are the same, the 387 PWid FEC element can be used instead of the Generalized ID FEC 388 element in the LDP based signaling. 390 With L2TP signaling, the local name is sent in Local End ID AVP, the 391 remote name in Remote End ID AVP. The AGI AVP is optional. If 392 present, it contains a zero-length AGI value. If the local name and 393 the remote name are the same, Local End ID AVP can be omitted from 394 L2TP signaling messages. 396 3.1.1.2. Single Sided Provisioning with Discovery 398 In this model, each Attachment Circuit must be provisioned with a 399 local name. The local name consists of a VPN-id (signaled as the 400 AGI) and an Attachment Individual Identifier which is unique relative 401 to the AGI. If two Attachment circuits are to be connected by a PW, 402 only one of them needs to be provisioned with a remote name (which of 403 course is the local name of the other Attachment Circuit). Neither 404 needs to be provisioned with the address of the remote PE, but both 405 must have the same VPN-id. 407 As part of an auto-discovery procedure, each PE advertises its 408 pairs. Each PE compares its local pairs with the pairs advertised by 410 the other PEs. If PE1 has a local pair with 411 value , and PE2 has a local pair with 412 value , PE1 will thus be able to discover that it needs to 413 connect to PE2. When signaling, it will use "fred" as the TAII, and 414 will use V as the AGI. PE1's local name for the Attachment Circuit 415 is sent as the SAII. 417 The primary benefit of this provisioning model when compared to 418 Double Sided Provisioning is that it enables one to move an 419 Attachment Circuit from one PE to another without having to 420 reconfigure the remote endpoint. However, compared to the approach 421 described in Section 3.3 below, it imposes a greater burden on the 422 discovery mechanism, because each attachment circuit's name must be 423 advertised individually (i.e. there is no aggregation of AC names in 424 this simple scheme). 426 3.1.2. Signaling 428 The LDP-based signaling follows the procedures specified in [PWE3- 429 CONTROL]. That is, one PE (PE1) sends a Label Mapping Message to 430 another PE (PE2) to establish an LSP in one direction. If that 431 message is processed successfully, and there is not yet an LSP for 432 the pseudowire in the opposite (PE1->PE2) direction, then PE2 sends a 433 Label Mapping Message to PE1. 435 In addition to the procedures of [PWE3-CONTROL], when a PE receives a 436 Label Mapping Message, and the TAI identifies a particular Attachment 437 Circuit which is configured to be bound to a point-to-point PW, then 438 the following checks must be made. 440 If the Attachment Circuit is already bound to a pseudowire (including 441 the case where only one of the two LSPs currently exists), and the 442 remote endpoint is not PE1, then PE2 sends a Label Release message to 443 PE1, with a Status Code meaning "Attachment Circuit bound to 444 different PE", and the processing of the Mapping message is complete. 446 If the Attachment Circuit is already bound to a pseudowire (including 447 the case where only one of the two LSPs currently exists), but the AI 448 at PE1 is different than that specified in the AGI/SAII fields of the 449 Mapping message then PE2 sends a Label Release message to PE1, with a 450 Status Code meaning "Attachment Circuit bound to different remote 451 Attachment Circuit", and the processing of the Mapping message is 452 complete. 454 Similarly with the L2TP-based signaling, when a PE receives an ICRQ 455 message, and the TAI identifies a particular Attachment Circuit which 456 is configured to be bound to a point-to-point PW, it performs the 457 following checks. 459 If the Attachment Circuit is already bound to a pseudowire, and the 460 remote endpoint is not PE1, then PE2 sends a Call Disconnect Notify 461 (CDN) message to PE1, with a Status Code meaning "Attachment Circuit 462 bound to different PE", and the processing of the ICRQ message is 463 complete. 465 If the Attachment Circuit is already bound to a pseudowire, but the 466 pseudowire is bound to a Forwarder on PE1 with the AI different than 467 that specified in the SAI fields of the ICRQ message, then PE2 sends 468 a CDN message to PE1, with a Status Code meaning "Attachment Circuit 469 bound to different remote Attachment Circuit", and the processing of 470 the ICRQ message is complete. 472 These errors could occur as the result of misconfigurations. 474 3.2. Virtual Private LAN Service 476 In the VPLS application [L2VPN-REQ, VPLS], the Attachment Circuits 477 can be though of as LAN interfaces which attach to "virtual LAN 478 switches", or, in the terminology of [L2VPN-FW], "Virtual Switching 479 Instances" (VSIs). Each Forwarder is a VSI that attaches to a number 480 of PWs and a number of Attachment Circuits. The VPLS service [L2VPN- 481 REQ, VPLS] requires that a single pseudowire be created between each 482 pair of VSIs that are in the same VPLS. Each PE device may have a 483 multiple VSIs, where each VSI belongs to a different VPLS. 485 3.2.1. Provisioning 487 Each VPLS must have a globally unique identifier, which we call a 488 VPN-id. Every VSI must be configured with the VPN-id of the VPLS to 489 which it belongs. 491 Each VSI must also have a unique identifier, which we call a VSI-ID. 492 This can be formed automatically by concatenating its VPN-id with an 493 IP address of its PE router. (Note that the PE address here is used 494 only as a form of unique identifier; a service provider could choose 495 to use some other numbering scheme if that was desired. See 496 Section 4.4 for a discussion of the assignment of identifiers in the 497 case of multiple providers.) 499 3.2.2. Auto-Discovery 501 3.2.2.1. BGP-based auto-discovery 503 The framework for BGP-based auto-discovery for a generic L2VPN 504 service is as described in [BGP-AUTO], section 3.2. 506 The AFI/SAFI used would be: 508 o An AFI specified by IANA for L2VPN. (This is the same for all 509 L2VPN schemes.) 511 o A SAFI specified by IANA specifically for an L2VPN service whose 512 pseudowires are set up using the procedures described in the 513 current document. 515 See Section 6 for further discussion of AFI/SAFI assignment. 517 In order to use BGP-based auto-discovery as specified in [BGP-AUTO], 518 there must be at least one globally unique identifier associated with 519 a VPLS, and each such identifier must be encodable as an 8-byte Route 520 Distinguisher (RD). If the globally unique identifier for a VPLS is 521 an RFC2685 VPN-id, it can be encoded as an RD as specified in [BGP- 522 AUTO]. However, any other method of assigning one or more unique 523 identifiers to a VPLS and encoding each of them as an RD (using the 524 encoding techniques of [RFC2547bis]) will do. 526 Each VSI needs to have a unique identifier, which can be encoded as a 527 BGP NLRI. This is formed by prepending the RD (from the previous 528 paragraph) to an IP address of the PE containing the VSI. Note that 529 the role of this address is simply as a readily available unique 530 identifier for the VSIs within a VPN; it does not need to be globally 531 routable. An alternate numbering scheme (e.g. numbering the VSIs of 532 a single VPN from 1 to n) could be used if desired. 534 (Note also that it is not strictly necessary for all the VSIs in the 535 same VPLS to have the same RD, all that is really necessary is that 536 the NLRI uniquely identify a VSI.) 538 Each VSI needs to be associated with one or more Route Target (RT) 539 Extended Communities, as discussed in [BGP-AUTO]. These control the 540 distribution of the NLRI, and hence will control the formation of the 541 overlay topology of pseudowires that constitutes a particular VPLS. 543 Auto-discovery proceeds by having each PE distribute, via BGP, the 544 NLRI for each of its VSIs, with itself as the BGP next hop, and with 545 the appropriate RT for each such NLRI. Typically, each PE would be a 546 client of a small set of BGP route reflectors, which would 547 redistribute this information to the other clients. 549 If a PE has a VSI with a particular RT, it can then import all the 550 NLRI which have that same RT, and from the BGP next hop attribute of 551 these NLRI it will learn the IP addresses of the other PE routers 552 which have VSIs with the same RT. The considerations of [RFC2547bis] 553 section 4.3.3 on the use of route reflectors apply. 555 If a particular VPLS is meant to be a single fully connected LAN, all 556 its VSIs will have the same RT, in which case the RT could be (though 557 it need not be) an encoding of the VPN-id. If a particular VPLS 558 consists of multiple VLANs, each VLAN must have its own unique RT. A 559 VSI can be placed in multiple VLANS (or even in multiple VPLSes) by 560 assigning it multiple RTs. 562 Note that hierarchical VPLS can be set up by assigning multiple RTs 563 to some of the VSIs; the RT mechanism allows one to have complete 564 control over the pseudowire overlay which constitutes the VPLS 565 topology. 567 If Distributed VPLS (described in Section 3.5) is deployed, only the 568 N-PEs participate in BGP-based autodiscovery. This means that an 569 N-PE would need to advertise reachability to each of the VSIs that it 570 supports, including those located in U-PEs to which it is connected. 571 To create a unique identifier for each such VSI, an IP address of 572 each U-PE combined with the RD for the VPLS instance could be used. 574 In summary, the BGP advertisement for a particular VSI at a given PE 575 will contain: 577 o an NLRI of AFI = L2VPN, SAFI = TBD, encoded as RD:PE_addr 579 o a BGP next hop equal to the loopback address of the PE 581 o an extended community attribute containing one or more RTs. 583 Note that this advertisement is quite similar to the NLRI format 584 defined in [BGP-VPLS], the main difference being that [BGP-VPLS] also 585 includes a label block in the NLRI. Interoperability between the 586 VPLS scheme defined here and that defined in [BGP-VPLS] is beyond the 587 scope of this document. 589 3.2.3. Signaling 591 It is necessary to create Attachment Identifiers which identify the 592 VSIs. In the preceding section, a VSI-ID was encoded as RD:PE_addr 593 for the purposes of autodiscovery. For signaling purposes, the same 594 information is carried but is encoded slightly differently. 596 Specifically, we encode the RD in the AGI field, and place the 597 PE_addr (or, more generally, the VSI-ID that was advertised in BGP, 598 minus the RD) in the TAII field. The combination of AGI and TAII is 599 sufficient to fully specify the VSI to which this pseudowire is to be 600 connected, in both single AS and inter-AS environments. The SAII 601 SHOULD be null. 603 The structure of the AGI and AII fields for the Generalized ID FEC in 604 LDP is defined in [PWE3-CONTROL]. The AGI field in this case 605 consists of a Type of 1, a length field of value 8, and the 8 bytes 606 of the RD. The TAII consists of a Type of 1, a length field of value 607 4, followed by the 4-byte PE address (or other 4-byte identifier). 608 See Section 6 for discussion of the AGI and AII Type assignment. 610 The encoding of the AGI and AII in L2TP is specified in [L2TP-L2VPN]. 612 Note that it is not possible using this technique to set up more than 613 one PW per pair of VSIs. 615 3.2.4. Pseudowires as VPLS Attachment Circuits 617 It is also possible using this technique to set up a PW which 618 attaches at one endpoint to a VSI, but at the other endpoint only to 619 an Attachment Circuit. However, in this case there may be more than 620 one PW terminating on a given VSI, which must somehow be 621 distinguished, so that the SAIIs cannot be null in this case. 622 Rather, each such PW must have an SAII which is unique relative to 623 the VSI-ID. 625 3.3. Colored Pools: Full Mesh of Point-to-Point Pseudowires 627 The "Colored Pools" model of operation provides an automated way to 628 deliver Virtual Private Wire Service (VPWS). In this model, each PE 629 may contain several pools of Attachment Circuits, each pool 630 associated with a particular VPN. A PE may contain multiple pools 631 per VPN, as each pool may correspond to a particular CE device. It 632 may be desired to create one pseudowire between each pair of pools 633 that are in the same VPN; the result would be to create a full mesh 634 of CE-CE VCs for each VPN. 636 3.3.1. Provisioning 638 Each pool is configured, and associated with: 640 o a set of Attachment Circuits; 642 o a "color", which can be thought of as a VPN-id of some sort; 643 o a relative pool identifier, which is unique relative to the color. 645 [Note: depending on the technology used for Attachment Circuits, it 646 may or may not be necessary to provision these circuits as well. For 647 example, if the ACs are frame relay circuits, there may be some 648 separate provisioning system to set up such circuits. Alternatively, 649 "provisioning" an AC may be as simple as allocating an unused VLAN ID 650 on an interface, and communicating the choice to the customer. These 651 issues are independent of the procedures described in this document.] 653 The pool identifier, and color, taken together, constitute a globally 654 unique identifier for the pool. Thus if there are n pools of a given 655 color, their pool identifiers can be (though they do not need to be) 656 the numbers 1-n. 658 The semantics are that a pseudowire will be created between every 659 pair of pools that have the same color, where each such pseudowire 660 will be bound to one Attachment Circuit from each of the two pools. 662 If each pool is a set of Attachment Circuits leading to a single CE 663 device, then the layer 2 connectivity among the CEs is controlled by 664 the way the colors are assigned to the pools. To create a full mesh, 665 the "color" would just be a VPN-id. 667 Optionally, a particular Attachment Circuit may be configured with 668 the relative pool identifier of a remote pool. Then that Attachment 669 Circuit would be bound to a particular pseudowire only if that 670 pseudowire's remote endpoint is the pool with that relative pool 671 identifier. With this option, the same pairs of Attachment Circuits 672 will always be bound via pseudowires. 674 3.3.2. Auto-Discovery 676 3.3.2.1. BGP-based auto-discovery 678 The framework for BGP-based auto-discovery for a generic L2VPN 679 service is described in [BGP-AUTO], section 3.2. 681 The AFI/SAFI used would be: 683 o An AFI specified by IANA for L2VPN. (This is the same for all 684 L2VPN schemes.) 686 o A SAFI specified by IANA specifically for an L2VPN service whose 687 pseudowires are set up using the procedures described in the 688 current document. 690 See Section 6 for further discussion of AFI/SAFI assignment. 692 In order to use BGP-based auto-discovery, there must be one or more 693 unique identifiers (the "color") associated with a particular VPWS 694 instance. Each identifier must be encodable as an RD (Route 695 Distinguisher). The globally unique identifier of a pool must be 696 encodable as NLRI; the color would be encoded as the RD and the pool 697 identifier as a four-byte quantity which is appended to the RD to 698 create the NLRI. 700 Each pool must also be associated with an RT (route target), which 701 may also be an encoding of the color. If the desired topology is a 702 full mesh of pseudowires, all pools may have the same RT. See 703 Section 3.4 for a discussion of other topologies. 705 Auto-discovery procedures by having each PE distribute, via BGP, the 706 NLRI for each of its pools, with itself as the BGP next hop, and with 707 the RT that encodes the pool's color. If a given PE has a pool with 708 a particular color (RT), it must receive, via BGP, all NLRI with that 709 same color (RT). Typically, each PE would be a client of a small set 710 of BGP route reflectors, which would redistribute this information to 711 the other clients. 713 If a PE has a pool with a particular color, it can then receive all 714 the NLRI which have that same color, and from the BGP next hop 715 attribute of these NLRI will learn the IP addresses of the other PE 716 routers which have pools switches with the same color. It also 717 learns the unique identifier of each such remote pool, as this is 718 encoded in the NLRI. The remote pool's relative identifier can be 719 extracted from the NLRI and used in the signaling, as specified 720 below. 722 In summary, the BGP advertisement for a particular pool of attachment 723 circuits at a given PE will contain: 725 o an NLRI of AFI = L2VPN, SAFI = TBD, encoded as RD:pool_num; 727 o a BGP next hop equal to the loopback address of the PE; 729 o an extended community attribute containing one or more RTs. 731 3.3.3. Signaling 733 The LDP-based signaling follows the procedures specified in [PWE3- 734 CONTROL]. That is, one PE (PE1) sends a Label Mapping Message to 735 another PE (PE2) to establish an LSP in one direction. The address 736 of PE2 is the next-hop address learned via BGP as described above. 737 If the message is processed successfully, and there is not yet an LSP 738 for the pseudowire in the opposite (PE1->PE2) direction, then PE2 739 sends a Label Mapping Message to PE1. Similarly, the L2TPv3-based 740 signaling follows the procedures of [L2TP-BASE]. Additional details 741 on the use of these signaling protocols follow. 743 When a PE sends a Label Mapping message or an ICRQ message to set up 744 a PW between two pools, it encodes the color as the AGI, the local 745 pool's relative identifier as the SAII, and the remote pool's 746 relative identifier as the TAII. 748 The structure of the AGI and AII fields for the Generalized ID FEC in 749 LDP is defined in [PWE3-CONTROL]. The AGI field in this case 750 consists of a Type of 1, a length field of value 8, and the 8 bytes 751 of the RD. The TAII consists of a Type of 1, a length field of value 752 4, followed by the 4-byte remote pool number. The SAII consists of a 753 Type of 1, a length field of value 4, followed by the 4-byte local 754 pool number. See Section 6 for discussion of the AGI and AII Type 755 assignment. Note that the VPLS and VPWS procedures defined in this 756 document can make use of the same AGI Type (1) and the same AII Type 757 (1). 759 The encoding of the AGI and AII in L2TP is specified in [L2TP-L2VPN]. 761 When PE2 receives a Label Mapping message or an ICRQ message from 762 PE1, and the TAI identifies to a pool, and there is already an 763 pseudowire connecting an Attachment Circuit in that pool to an 764 Attachment Circuit at PE1, and the AI at PE1 of that pseudowire is 765 the same as the SAI of the Label Mapping or ICRQ message, then PE2 766 sends a Label Release or CDN message to PE1, with a Status Code 767 meaning "Attachment Circuit already bound to remote Attachment 768 Circuit". This prevents the creation of multiple pseudowires between 769 a given pair of pools. 771 Note that the signaling itself only identifies the remote pool to 772 which the pseudowire is to lead, not the remote Attachment Circuit 773 which is to be bound to the the pseudowire. However, the remote PE 774 may examine the SAII field to determine which Attachment Circuit 775 should be bound to the pseudowire. 777 3.4. Colored Pools: Partial Mesh 779 The procedures for creating a partial mesh of pseudowires among a set 780 of colored pools are substantially the same as those for creating a 781 full mesh, with the following exceptions: 783 o Each pool is optionally configured with a set of "import RTs" and 784 "export RTs"; 786 o During BGP-based auto-discovery, the pool color is still encoded 787 in the RD, but if the pool is configured with a set of "export 788 RTs", these are are encoded in the RTs of the BGP Update messages, 789 INSTEAD of the color; 791 o If a pool has a particular "import RT" value X, it will create a 792 PW to every other pool which has X as one of its "export RTs". 793 The signaling messages and procedures themselves are as in section 794 3.3.3. 796 As a simple example, consider the task of building a hub-and-spoke 797 topology with a single hub. One pool, the "hub" pool, is configured 798 with an export RT of RT_hub and an import RT of RT_spoke. All other 799 pools (the spokes) are configured with an export RT of RT_spoke and 800 an import RT of RT_hub. Thus the Hub pool will connect to the 801 spokes, and vice-versa, but the spoke pools will not connect to each 802 other. More complex examples are presented in section 4.2.2 of [BGP- 803 AUTO]. 805 3.5. Distributed VPLS 807 In Distributed VPLS ([L2VPN-FW], [DTLS], [LPE]), the VPLS 808 functionality of a PE router is divided among two systems: a U-PE and 809 an N-PE. The U-PE sits between the user and the N-PE. VSI 810 functionality (e.g., MAC address learning and bridging) is performed 811 on the U-PE. A number of U-PEs attach to an N-PE. For each VPLS 812 supported by a U-PE, the U-PE maintains a pseudowire to each other 813 U-PE in the same VPLS. However, the U-PEs do not maintain signaling 814 control connections with each other. Rather, each U-PE has only a 815 single signaling connection, to its N-PE. In essence, each U-PE-to- 816 U-PE pseudowire is composed of three pseudowires spliced together: 817 one from U-PE to N-PE, one from N-PE to N-PE, and one from N-PE to 818 U-PE. 820 Consider for example the following topology: 822 U-PE A-----| |----U-PE C 823 | | 824 | | 825 N-PE E--------N-PE F 826 | | 827 | | 828 U-PE B-----| |-----U-PE D 830 where the four U-PEs are in a common VPLS. We now illustrate how PWs 831 get spliced together in the above topology in order to establish the 832 necessary PWs from U-PE A to the other U-PEs. 834 There are three PWs from A to E. Call these A-E/1, A-E/2, and A-E/3. 835 In order to connect A properly to the other U-PEs, there must be two 836 PWs from E to F (call these E-F/1 and E-F/2), one PW from E to B 837 (E-B/1), one from F to C (F-C/1), and one from F to D (F-D/1). 839 The N-PEs must then splice these pseudowires together to get the 840 equivalent of what the non-distributed VPLS signaling mechanism would 841 provide: 843 o PW from A to B: A-E/1 gets spliced to E-B/1. 845 o PW from A to C: A-E/2 gets spliced to E-F/1 gets spliced to F-C/1. 847 o PW from A to D: A-E/3 gets spliced to E-F/2 gets spliced to F-D/1. 849 It doesn't matter which PWs get spliced together, as long as the 850 result is one from A to each of B, C, and D. 852 Similarly, there are additional PWs which must get spliced together 853 to properly interconnect U-PE B with U-PEs C and D, and to 854 interconnect U-PE C with U-PE D. 856 The following figure illustrates the PWs from A to C and from B to D. 857 For clarity of the figure, the other four PWs are not shown. 859 splicing points 860 | | 861 V V 862 A-C PW <-----><-----------><------> 864 U-PE A-----| |----U-PE C 865 | | 866 | | 867 N-PE E--------N-PE F 868 | | 869 | | 870 U-PE B-----| |-----U-PE D 872 B-D PW <-----><-----------><------> 873 ^ ^ 874 | | 875 splicing points 877 One can see that distributed VPLS does not reduce the number of 878 pseudowires per U-PE, but it does reduce the number of control 879 connections per U-PE. Whether this is worthwhile depends, of course, 880 on what the bottleneck is. 882 3.5.1. Signaling 884 The signaling to support Distributed VPLS can be done with the 885 mechanisms described in this paper. However, the procedures for VPLS 886 (section 3.2.3) need some additional machinery to ensure that the 887 appropriate number of PWs are established between the various N-PEs 888 and U-PEs, and among the N-PEs. 890 At a given N-PE, the directly attached U-PEs in a given VPLS can be 891 numbered from 1 to n. This number identifies the U-PE relative to a 892 particular VPN-id and a particular N-PE. (That is, to uniquely 893 identify the U-PE, the N-PE, the VPN-id, and the U-PE number must be 894 known.) 896 As a result of configuration/discovery, each U-PE must be given a 897 list of pairs. Each element in this list tells the 898 U-PE to set up j PWs to the specified IP address. When the U-PE 899 signals to the N-PE, it sets the AGI to the proper-VPN-id, and sets 900 the SAII to the PW number, and sets the TAII to null. 902 In the above example, U-PE A would be told <3, E>, telling it to set 903 up 3 PWs to E. When signaling, A would set the AGI to the proper 904 VPN-id, and would set the SAII to 1, 2, or 3, depending on which of 905 the three PWs it is signaling. 907 As a result of configuration/discovery, each N-PE must be given the 908 following information for each VPLS: 910 o A "Local" list: {}, where each element tells it to 911 set up j PWs to the locally attached U-PE at the specified 912 address. The number of elements in this list will be n, the 913 number of locally attached U-PEs in this VPLS. In the above 914 example, E would be given the local list: {<3, A>, <3, B>}, 915 telling it to set up 3 PWs to A and 3 to B. 917 o A local numbering, relative to the particular VPLS and the 918 particular N-PE, of its U-PEs. In the above example, E could be 919 told that U-PE A is 1, and U-PE B is 2. 921 o A "Remote" list: {}, telling it to set up k PWs, 922 for each U-PE, to the specified IP address. Each of these IP 923 addresses identifies a N-PE, and k specifies the number of U-PEs 924 at that N-PE which are in the VPLS. In the above example, E would 925 be given the remote list: {<2, F>}. Since N-PE E has two U-PEs, 926 this tells it to set up 4 PWs to N-PE F, 2 for each of its E's 927 U-PEs. 929 The signaling of a PW from N-PE to U-PE is based on the local list 930 and the local numbering of U-PEs. When signaling a particular PW 931 from an N-PE to a U-PE, the AGI is set to the proper VPN-id, and SAII 932 is set to null, and the TAII is set to the PW number (relative to 933 that particular VPLS and U-PE). In the above example, when E signals 934 to A, it would set the TAII to be 1, 2, or 3, respectively, for the 935 three PWs it must set up to A. It would similarly signal three PWs to 936 B. 938 The LSP signaled from U-PE to N-PE is associated with an LSP from 939 N-PE to U-PE in the usual manner. A PW between a U-PE and an N-PE is 940 known as a "U-PW". 942 The signaling of the appropriate set of PWs from N-PE to N-PE is 943 based on the remote list. The PWs between the N-PEs can all be 944 considered equivalent. As long as the correct total number of PWs 945 are established, the N-PEs can splice these PWs to appropriate U-PWs. 946 The signaling of the correct number of PWs from N-PE to N-PE is based 947 on the remote list. The remote list specifies the number of PWs to 948 set up, per local U-PE, to a particular remote N-PE. 950 When signaling a particular PW from an N-PE to an N-PE, the AGI is 951 set to the appropriate VPN-id. The TAII identifies the remote N-PE, 952 as in the non-distributed case, i.e. it contains an IP address of the 953 remote N-PE. If there are n such PWs, they are distinguished by the 954 setting of the SAII, which will be a number from 1 to n inclusive. A 955 PW between two N-PEs is known as an "N-PW". 957 Each U-PW must be "spliced" to an N-PW. This is based on the remote 958 list. If the remote list contains an element , then i U-PWs 959 from each local U-PE must be spliced to i N-PWs from the remote N-PE 960 F. It does not matter which U-PWs are spliced to which N-PWs, as long 961 as this constraint is met. 963 If an N-PE has more than one local U-PE for a given VPLS, it must 964 also ensure that a U-PW from each such U-PE is spliced to a U-PW from 965 each of the other U-PEs. 967 3.5.2. Provisioning and Discovery 969 Every N-PE must be provisioned with the set of VPLS instances it 970 supports, a VPN-id for each one, and a list of local U-PEs for each 971 such VPLS. As part of the discovery procedure, the N-PE advertises 972 the number of U-PEs for each VPLS. See Section 3.2.2 for details. 974 Auto-discovery (e.g., BGP-based) can be used to discover all the 975 other N-PEs in the VPLS, and for each, the number of U-PEs local to 976 that N-PE. From this, one can compute the total number of U-PEs in 977 the VPLS. This information is sufficient to enable one to compute 978 the local list and the remote list for each N-PE. 980 3.5.3. Non-distributed VPLS as a sub-case 982 A PE which is providing "non-distributed VPLS" (i.e., a PE which 983 performs both the U-PE and N-PE functions) can interoperate with 984 N-PE/U-PE pairs that are providing distributed VPLS. The "non- 985 distributed PE" simply advertises, in the discovery procedure, that 986 it has one local U-PE per VPLS. And of course, the non-distributed 987 PE does no splicing. 989 If every PE in a VPLS is providing non-distributed VPLS, and thus 990 every PE advertises itself as an N-PE with one local U-PE, the 991 resultant signaling is exactly the same as that specified in 992 Section 3.2.3 above, except that an SAII value of 1 is used instead 993 of null. (A PE providing non-distributed VPLS should therefore treat 994 SAII values of 1 the same as it treats SAII values of null.) 996 3.5.4. Splicing and the Data Plane 998 Splicing two PWs together is quite straightforward in the MPLS data 999 plane, as moving a packet from one PW directly to another is just a 1000 label replace operation on the PW label. When a PW consists of two 1001 or more PWs spliced together, it is assumed that the data will go to 1002 the node where the splicing is being done, i.e., that the data path 1003 will pass through the nodes that participate in PW signaling. 1005 Further details on splicing are discussed in [PW-SWITCH]. 1007 4. Inter-AS Operation 1009 The provisioning, autodiscovery and signaling mechanisms described 1010 above can all be applied in an inter-AS environment. As in [2547bis] 1011 there are a number of options for inter-AS operation. 1013 4.1. Multihop EBGP redistribution of L2VPN NLRIs 1015 This option is most like option (c) in [2547bis]. That is, we use 1016 multihop EBGP redistribution of L2VPN NLRIs between source and 1017 destination ASes, with EBGP redistribution of labeled IPv4 routes 1018 from AS to neighboring AS. 1020 An ASBR must maintain labeled IPv4 /32 routes to the PE routers 1021 within its AS. It uses EBGP to distribute these routes to other 1022 ASes, and sets itself as the BGP next hop for these routes. ASBRs in 1023 any transit ASes will also have to use EBGP to pass along the labeled 1024 /32 routes. This results in the creation of a set of label switched 1025 paths from all ingress PE routers to all egress PE routers. Now PE 1026 routers in different ASes can establish multi-hop EBGP connections to 1027 each other, and can exchange L2VPN NLRIs over those connections. 1028 Following such exchanges a pair of PEs in different ASes could 1029 establish an LDP session to signal PWs between each other. 1031 For VPLS, the BGP advertisement and PW signaling are exactly as 1032 described in Section 3.2. As a result of the multihop EBGP session 1033 that exists between source and destination AS, the PEs in one AS that 1034 have VSIs of a certain VPLS will discover the PEs in another AS that 1035 have VSIs of the same VPLS. These PEs will then be able to establish 1036 the appropriate PW signaling protocol session and establish the full 1037 mesh of VSI-VSI pseudowires to build the VPLS as described in Section 1038 3.2.3. 1040 For VPWS, the BGP advertisement and PW signaling are exactly as 1041 described in Section 3.3. As a result of the multihop EBGP session 1042 that exists between source and destination AS, the PEs in one AS that 1043 have pools of a certain color (VPN) will discover PEs in another AS 1044 that have pools of the same color. These PEs will then be able to 1045 establish the appropriate PW signaling protocol session and establish 1046 the full mesh of pseudowires as described in Section 3.2.3. A 1047 partial mesh can similarly be established using the procedures of 1048 Section 3.4. 1050 As in layer 3 VPNs, building an L2VPN that spans the networks of more 1051 than one provider requires some co-ordination in the use of RTs and 1052 RDs. This subject is discussed in more detail in Section 4.4. 1054 4.2. EBGP redistribution of L2VPN NLRIs with Pseudowire Switching 1056 A possible drawback of the approach of the previous section is that 1057 it creates PW signaling sessions among all the PEs of a given L2VPN 1058 (VPLS or VPWS). This means a potentially large number of LDP or 1059 L2TPv3 sessions will cross the AS boundary and that these session 1060 connect to many devices within an AS. In the case were the ASes 1061 belong to different providers, one might imagine that providers would 1062 like to have fewer signaling sessions crossing the AS boundary and 1063 that the entities that terminate the sessions could be restricted to 1064 a smaller set of devices. Furthermore, by forcing the LDP or L2TPv3 1065 signaling sessions to terminate on a small set of ASBRs, a provider 1066 could use standard authentication procedures on a small set of inter- 1067 provider sessions. These concerns motivate the approach described 1068 here. 1070 [PW-SWITCH] describes an approach to "switching" packets from one 1071 pseudowire to another at a particular node. This approach allows an 1072 end-to-end pseudowire to be constructed out of several pseudowire 1073 segments, without maintaining an end-to-end control connection. We 1074 can use this approach to produce an inter-AS solution that more 1075 closely resembles option (b) in [2547bis]. 1077 In this model, we use EBGP redistribution of L2VPN NLRI from AS to 1078 neighboring AS. First, the PE routers use IBGP to redistribute L2VPN 1079 NLRI either to an Autonomous System Border Router (ASBR), or to a 1080 route reflector of which an ASBR is a client. The ASBR then uses 1081 EBGP to redistribute those L2VPN NLRI to an ASBR in another AS, which 1082 in turn distributes them to the PE routers in that AS, or perhaps to 1083 another ASBR which in turn distributes them, and so on. 1085 In this case, a PE can learn the address of an ASBR through which it 1086 could reach another PE to which it wishes to establish a PW. That 1087 is, a local PE will receive a BGP advertisement containing L2VPN NLRI 1088 corresponding to an L2VPN instance in which the local PE has some 1089 attached members. The BGP next-hop for that L2VPN NLRI will be an 1090 ASBR of the local AS. Then, rather than building a control 1091 connection all the way to the remote PE, it builds one only to the 1092 ASBR. A pseudowire segment can now be established from the PE to the 1093 ASBR. The ASBR in turn can establish a PW to the ASBR of the next 1094 AS, and splice that PW to the PW from the PE as described in 1095 Section 3.5.4 and [PW-SWITCH]. Repeating the process at each ASBR 1096 leads to a sequence of PW segments that, when spliced together, 1097 connect the two PEs. 1099 Note that in the approach just described, the local PE may never 1100 learn the IP address of the remote PE. It learns the L2VPN NLRI 1101 advertised by the remote PE, which need not contain the remote PE 1102 address, and it learns the IP address of the ASBR that is the BGP 1103 next hop for that NLRI. 1105 When this approach is used for VPLS, or for full-mesh VPWS, it leads 1106 to a full mesh of pseudowires among the PEs, just as in the previous 1107 section, but it does not require a full mesh of control connections 1108 (LDP or L2TPv3 sessions). Instead the control connections within a 1109 single AS run among all the PEs of that AS and the ASBRs of the AS. 1110 A single control connection between the ASBRs of adjacent ASes can be 1111 used to support however many AS-to-AS pseudowire segments are needed. 1113 Note that the procedures described here will result in the splicing 1114 points being co-located with the ASBRs. It is of course possible to 1115 have multiple ASBR-ASBR connections between a given pair of ASes. In 1116 this case a given PE could choose among the available ASBRs based on 1117 a range of criteria, such as IGP metric, local configuration, etc., 1118 analogous to choosing an exit point in normal IP routing. The use of 1119 multiple ASBRs would lead to greater resiliency (at the timescale of 1120 BGP routing convergence) since a PE could select a new ASBR in the 1121 event of the failure of the one currently in use. 1123 As in layer 3 VPNs, building an L2VPN that spans the networks of more 1124 than one provider requires some co-ordination in the use of RTs and 1125 RDs. This subject is discussed in more detail in Section 4.4. 1127 4.3. Inter-Provider Application of Dist. VPLS Signaling 1129 An alternative approach to inter-provider VPLS can be derived from 1130 the Distributed VPLS approach described above. Consider the 1131 following topology: 1133 PE A --- Network 1 ----- Border ----- Border ----- Network 2 --- PE B 1134 Router 12 Router 21 | 1135 | 1136 PE C 1138 where A, B, and C are PEs in a common VPLS, but Networks 1 and 2 are 1139 networks of different Service Providers. Border Router 12 is Network 1140 1's border router to network 2, and Border Router 21 is Network 2's 1141 border router to Network 1. We suppose further that the PEs are not 1142 "distributed", i.e, that each provides both the U-PE and N-PE 1143 functions. 1145 In this topology, one needs two inter-provider pseudowires: A-B and 1146 A-C. 1148 Suppose a Service Provider decides, for whatever reason, that it does 1149 not want each of its PEs to have a control connection to any PEs in 1150 the other network. Rather, it wants the inter-provider control 1151 connections to run only between the two border routers. 1153 This can be achieved using the techniques of section 3.5, where the 1154 PEs behave like U-PEs, and the BRs behave like N-PEs. In the example 1155 topology, PE A would behave like a U-PE which is locally attached to 1156 BR12; PEs B and C would be have like U-PEs which are locally attached 1157 to BR21; and the two BRs would behave like N-PEs. 1159 As a result, the PW from A to B would consist of three segments: 1160 A-BR12, BR12-BR21, and BR21-B. The border routers would have to 1161 splice the corresponding segments together. 1163 This requires the PEs within a VPLS to be numbered from 1-n (relative 1164 to that VPLS) within a given network. 1166 4.4. RT and RD Assignment Considerations 1168 We note that, in order for any of the inter-AS procedures described 1169 above to work correctly, the two ASes must use RTs and RDs 1170 consistently, just as in layer 3 VPNs [RFC2547bis]. The structure of 1171 RTs and RDs is such that there is not a great risk of accidental 1172 collisions. The main challenge is that it is necessary for the 1173 operator of one AS to know what RT or RTs have been chosen in another 1174 AS for any VPN that has sites in both ASes. As in layer 3 VPNs, 1175 there are many ways to make this work, but all require some co- 1176 operation among the providers. For example, provider A may tag all 1177 the NLRI for a given VPN with a single RT, say RT_A, and provider B 1178 can then configure the PEs that connect to sites of that VPN to 1179 import NLRI that contains that RT. Provider B can choose a different 1180 RT, RT_B, tag all NLRI for this VPN with that RT, and then provider A 1181 can import NLRI with that RT at the appropriate PEs. However this 1182 does require both providers to communicate their choice of RTs for 1183 each VPN. Alternatively both providers could agree to use a common 1184 RT for a given VPN. In any case communication of RTs between the 1185 providers is essential. As in layer 3 VPNs, providers may configure 1186 RT filtering to ensure that only coordinated RT values are allowed 1187 across the AS boundary. 1189 5. Security Considerations 1191 This document describes a number of different L2VPN provisioning 1192 models, and specifies the endpoint identifiers that are required to 1193 support each of the provisioning models. It also specifies how those 1194 endpoint identifiers are mapped into fields of auto-discovery 1195 protocols and signaling protocols. 1197 The security considerations related to the signaling and auto- 1198 discovery protocols are discussed in the relevant protocol 1199 specifications ([BGP-AUTO], [L2TP-BASE], [L2TP-L2VPN], [LDP], [PWE3- 1200 CONTROL]). 1202 The security considerations related to the particular kind of L2VPN 1203 service being supported are discussed in [L2VPN-REQS], [L2VPN-FW], 1204 and [VPLS]. 1206 The security consideration of inter-AS operation are similar to those 1207 for inter-AS L3VPNs [2547bis]. 1209 The way in which endpoint identifiers are mapped into protocol fields 1210 does not create any additional security issues. 1212 6. IANA Considerations 1214 This document does not require any IANA actions. 1216 This document assumes the assignment of an AFI and a SAFI for L2VPN 1217 NLRI. Both AFI and SAFI may be the same as the values assigned for 1218 [BGP-VPLS]. 1220 [PWE3-IANA] defines registries for "Attachment Group Identifier (AGI) 1221 Type" and "Attachment Individual Identifier (AII) Type". Type 1 in 1222 each registry has been assigned to the AGI and AII formats defined in 1223 this document. 1225 7. Acknowledgments 1227 Thanks to Dan Tappan, Ted Qian, Ali Sajassi, Skip Booth, Luca 1228 Martini, Dave McDysan and Francois LeFaucheur for their comments, 1229 criticisms, and helpful suggestions. 1231 Thanks to Tissa Senevirathne, Hamid Ould-Brahim and Yakov Rekhter for 1232 discussing the auto-discovery issues. 1234 Thanks to Vach Kompella for a continuing discussion of the proper 1235 semantics of the generalized identifiers. 1237 8. Normative References 1239 [BRADNER] Bradner, S., "Key words for use in RFCs to Indicate 1240 Requirement Levels", BCP 14, RFC 2119, March 1997. 1242 [MP-BGP] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, 1243 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 1245 [EXT-COMM] Sangli, S., Tappan, D. and Y. Rekhter, "BGP Extended 1246 Communities Attribute", Internet-Draft 1247 draft-ietf-idr-bgp-ext-communities-09, July 2005. 1249 [L2TP-BASE] Lau et. al., "Layer Two Tunneling Protocol (Version 3)", 1250 RFC 3931, March 2005. 1252 [LDP] Anderson et al., "LDP Specification", RFC 3036, Jan 2001. 1254 [PWE3-CONTROL] "Pseudowire Setup and Maintenance using LDP", Martini, 1255 et. al., draft-ietf-pwe3-control-protocol-17.txt, June 2005. 1257 9. Informative References 1259 [BGP-AUTO] "Using BGP as an Auto-Discovery Mechanism for Network- 1260 based VPNs", Ould-Brahim et. al., 1261 draft-ietf-l3vpn-bgpvpn-auto-05.txt, February 2005 1263 [L2TP-L2VPN] "L2VPN Extensions for L2TP", Luo, 1264 draft-ietf-l2tpext-l2vpn-05.txt, June 2005 1266 [L2VPN-FW] "L2VPN Framework", Andersson et. al., 1267 draft-ietf-l2vpn-l2-framework-05.txt, June 2004 1269 [L2VPN-REQ] "Service Requirements for Layer 2 Provider Provisioned 1270 Virtual Private Network Services", Augustyn, Serbest, et. al., 1271 draft-ietf-l2vpn-requirements-04.txt, February 2005 1273 [L2VPN-TERM] Andersson, Madsen, "PPVPN Terminology", RFC 4026, March 1274 2005. 1276 [PWE3-ARCH] Bryant, Pate, et. al., "PWE3 Architecture", RFC 3985, 1277 March 2005. 1279 [PW-SWITCH] "Pseudo Wire Switching", Martini, et. al., 1280 draft-martini-pwe3-pw-switching-03.txt, April 2005 1282 [PWE3-IANA] "IANA Allocations for pseudo Wire Edge to Edge Emulation 1283 (PWE3)", Martini, draft-ietf-pwe3-iana-allocation-11.txt, June 2005 1285 [RFC2547bis], "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., 1286 draft-ietf-l3vpn-rfc2547bis-03.txt, October 2004 1288 [RFC2685] "Virtual Private Networks Identifier", Fox, Gleeson, RFC 1289 2685, September 1999 1291 [VPLS] "Virtual Private LAN Services over MPLS", Laserre, et. al., 1292 draft-ietf-l2vpn-vpls-ldp-06.txt, February 2005 1294 [BGP-VPLS] "Virtual Private LAN Service", Kompella et al., 1295 draft-ietf-l2vpn-vpls-bgp-05.txt, April 2005 1297 [AII-TYPES] "AII Types for Aggregation", Metz et al., 1298 draft-metz-aii-aggregate-00.txt, July 2005 1300 Authors' Addresses 1302 Eric Rosen 1303 Cisco Systems, Inc. 1304 1414 Mass. Ave. 1305 Boxborough, MA 01719 1306 USA 1308 Email: erosen@cisco.com 1310 Wei Luo 1311 Cisco Systems, Inc. 1312 170 W Tasman Dr. 1313 San Jose, CA 95134 1314 USA 1316 Email: luo@cisco.com 1318 Bruce Davie 1319 Cisco Systems, Inc. 1320 1414 Mass. Ave. 1321 Boxborough, MA 01719 1322 USA 1324 Email: bsd@cisco.com 1326 Vasile Radoaca 1328 Email: radoaca@hotmail.com 1330 Intellectual Property Statement 1332 The IETF takes no position regarding the validity or scope of any 1333 Intellectual Property Rights or other rights that might be claimed to 1334 pertain to the implementation or use of the technology described in 1335 this document or the extent to which any license under such rights 1336 might or might not be available; nor does it represent that it has 1337 made any independent effort to identify any such rights. Information 1338 on the procedures with respect to rights in RFC documents can be 1339 found in BCP 78 and BCP 79. 1341 Copies of IPR disclosures made to the IETF Secretariat and any 1342 assurances of licenses to be made available, or the result of an 1343 attempt made to obtain a general license or permission for the use of 1344 such proprietary rights by implementers or users of this 1345 specification can be obtained from the IETF on-line IPR repository at 1346 http://www.ietf.org/ipr. 1348 The IETF invites any interested party to bring to its attention any 1349 copyrights, patents or patent applications, or other proprietary 1350 rights that may cover technology that may be required to implement 1351 this standard. Please address the information to the IETF at 1352 ietf-ipr@ietf.org. 1354 Disclaimer of Validity 1356 This document and the information contained herein are provided on an 1357 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1358 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1359 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1360 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1361 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1362 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1364 Copyright Statement 1366 Copyright (C) The Internet Society (2005). This document is subject 1367 to the rights, licenses and restrictions contained in BCP 78, and 1368 except as set forth therein, the authors retain all their rights. 1370 Acknowledgment 1372 Funding for the RFC Editor function is currently provided by the 1373 Internet Society.