idnits 2.17.1 draft-ietf-l2vpn-signaling-07.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 1435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1412. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1425. ** 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 (March 3, 2006) is 6629 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-idr-bgp-ext-communities' is defined on line 1278, but no explicit reference was found in the text == Unused Reference: 'RFC2858' is defined on line 1305, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-01 ** Obsolete normative reference: RFC 2858 (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-requirements-06 == Outdated reference: A later version (-08) exists of draft-ietf-l2vpn-vpls-bgp-06 == Outdated reference: A later version (-09) exists of draft-ietf-l2vpn-vpls-ldp-08 == Outdated reference: A later version (-09) exists of draft-ietf-l3vpn-bgpvpn-auto-06 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-arch-00 Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Rosen 3 Internet-Draft W. Luo 4 Expires: September 4, 2006 B. Davie 5 Cisco Systems, Inc. 6 V. Radoaca 7 March 3, 2006 9 Provisioning, Autodiscovery, and Signaling in L2VPNs 10 draft-ietf-l2vpn-signaling-07.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 September 4, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may 44 have different "provisioning models", i.e., models for what 45 information needs to be configured in what entities. Once 46 configured, the provisioning information is distributed by a 47 "discovery process". When the discovery process is complete, a 48 signaling protocol is automatically invoked to set up the mesh of 49 Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. 50 This document specifies a number of L2VPN provisioning models, and 51 further specifies the semantic structure of the endpoint identifiers 52 required by each model. It discusses the distribution of these 53 identifiers by the discovery process, especially when discovery is 54 based on the Border Gateway Protocol (BGP). It then specifies how 55 the endpoint identifiers are carried in the two signaling protocols 56 that are used to set up PWs, the Label Distribution Protocol (LDP) 57 and the Layer 2 Tunneling Protocol (L2TPv3). 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2. Signaling Protocol Framework . . . . . . . . . . . . . . . . . 7 64 2.1. Endpoint Identification . . . . . . . . . . . . . . . . . 7 65 2.2. Creating a Single Bidirectional Pseudowire . . . . . . . . 8 66 2.3. Attachment Identifiers and Forwarders . . . . . . . . . . 9 68 3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 3.1. Individual Point-to-Point Pseudowires . . . . . . . . . . 11 70 3.1.1. Provisioning Models . . . . . . . . . . . . . . . . . 11 71 3.1.1.1. Double Sided Provisioning . . . . . . . . . . . . 11 72 3.1.1.2. Single Sided Provisioning with Discovery . . . . . 11 73 3.1.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 12 74 3.2. Virtual Private LAN Service . . . . . . . . . . . . . . . 13 75 3.2.1. Provisioning . . . . . . . . . . . . . . . . . . . . . 13 76 3.2.2. Auto-Discovery . . . . . . . . . . . . . . . . . . . . 14 77 3.2.2.1. BGP-based auto-discovery . . . . . . . . . . . . . 14 78 3.2.3. Signaling . . . . . . . . . . . . . . . . . . . . . . 16 79 3.2.4. Pseudowires as VPLS Attachment Circuits . . . . . . . 16 80 3.3. Colored Pools: Full Mesh of Point-to-Point 81 Pseudowires . . . . . . . . . . . . . . . . . . . . . . . 16 82 3.3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . 17 83 3.3.2. Auto-Discovery . . . . . . . . . . . . . . . . . . . . 17 84 3.3.2.1. BGP-based auto-discovery . . . . . . . . . . . . . 17 85 3.3.3. Signaling . . . . . . . . . . . . . . . . . . . . . . 19 86 3.4. Colored Pools: Partial Mesh . . . . . . . . . . . . . . . 20 87 3.5. Distributed VPLS . . . . . . . . . . . . . . . . . . . . . 20 88 3.5.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 22 89 3.5.2. Provisioning and Discovery . . . . . . . . . . . . . . 24 90 3.5.3. Non-distributed VPLS as a sub-case . . . . . . . . . . 24 91 3.5.4. Splicing and the Data Plane . . . . . . . . . . . . . 24 93 4. Inter-AS Operation . . . . . . . . . . . . . . . . . . . . . . 26 94 4.1. Multihop EBGP redistribution of L2VPN NLRIs . . . . . . . 26 95 4.2. EBGP redistribution of L2VPN NLRIs with Multi-Segment 96 Pseudowires . . . . . . . . . . . . . . . . . . . . . . . 27 97 4.3. Inter-Provider Application of Distributed VPLS 98 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 28 99 4.4. RT and RD Assignment Considerations . . . . . . . . . . . 29 101 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 103 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 105 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 106 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 107 8.1. Normative References . . . . . . . . . . . . . . . . . . . 33 108 8.2. Informative References . . . . . . . . . . . . . . . . . . 34 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 111 Intellectual Property and Copyright Statements . . . . . . . . . . 37 113 1. Introduction 115 [I-D.ietf-l2vpn-l2-framework] describes a number of different ways in 116 which sets of pseudowires may be combined together into "Provider 117 Provisioned Layer 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a 118 number of different kinds of L2VPN. Different kinds of L2VPN may 119 have different "provisioning models", i.e., different models for what 120 information needs to be configured in what entities. Once 121 configured, the provisioning information is distributed by a 122 "discovery process", and once the information is discovered, the 123 signaling protocol is automatically invoked to set up the required 124 pseudowires. The semantics of the endpoint identifiers which the 125 signaling protocol uses for a particular type of L2VPN are determined 126 by the provisioning model. That is, different kinds of L2VPN, with 127 different provisioning models, require different kinds of endpoint 128 identifiers. This document specifies a number of L2VPN provisioning 129 models, and specifies the semantic structure of the endpoint 130 identifiers required for each provisioning model. 132 Either LDP (as specified in [RFC3036] and extended in [I-D.ietf-pwe3- 133 control-protocol]) or L2TP version 3 (as specified in [RFC3931] and 134 extended in [I-D.ietf-l2tpext-l2vpn]) can be used as signaling 135 protocols to set up and maintain pseudowires (PWs) [RFC3985]. Any 136 protocol which sets up connections must provide a way for each 137 endpoint of the connection to identify the other; each PW signaling 138 protocol thus provides a way to identify the PW endpoints. Since 139 each signaling protocol needs to support all the different kinds of 140 L2VPN and provisioning models, the signaling protocol must have a 141 very general way of representing endpoint identifiers, and it is 142 necessary to specify rules for encoding each particular kind of 143 endpoint identifier into the relevant fields of each signaling 144 protocol. This document specifies how to encode the endpoint 145 identifiers of each provisioning model into the LDP and L2TPv3 146 signaling protocols. 148 We make free use of terminology from [I-D.ietf-l2vpn-l2-framework], 149 [RFC4026], [RFC3985], and [I-D.ietf-pwe3-ms-pw-arch], in particular 150 the terms "Attachment Circuit", "pseudowire", "PE", "CE", and "multi- 151 segment pseudowire". 153 Section 2 provides an overview of the relevant aspects of [I-D.ietf- 154 pwe3-control-protocol] and [I-D.ietf-l2tpext-l2vpn]. 156 Section 3 details various provisioning models and relates them to the 157 signaling process and to the discovery process. The way in which the 158 signaling mechanisms can be integrated with BGP-based auto-discovery 159 is covered in some detail. 161 Section 4 explains how the procedures for discovery and signaling can 162 be applied in a multi-AS environment and outlines several options for 163 the establishment of multi-AS L2VPNs. 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119] 169 2. Signaling Protocol Framework 171 2.1. Endpoint Identification 173 Per [I-D.ietf-l2vpn-l2-framework], a pseudowire can be thought of as 174 a relationship between a pair of "Forwarders". In simple instances 175 of VPWS, a Forwarder binds a pseudowire to a single Attachment 176 Circuit, such that frames received on the one are sent on the other, 177 and vice versa. In VPLS, a Forwarder binds a set of pseudowires to a 178 set of Attachment Circuits; when a frame is received from any member 179 of that set, a MAC address table is consulted (and various 802.1d 180 procedures executed) to determine the member or members of that set 181 on which the frame is to be transmitted. In more complex scenarios, 182 Forwarders may bind PWs to PWs, thereby "splicing" two PWs together; 183 this is needed, e.g., to support distributed VPLS and some inter-AS 184 scenarios. 186 In simple VPWS, where a Forwarder binds exactly one PW to exactly one 187 Attachment Circuit, a Forwarder can be identified by identifying its 188 Attachment Circuit. In simple VPLS, a Forwarder can be identified by 189 identifying its PE device and its VPN. 191 To set up a PW between a pair of Forwarders, the signaling protocol 192 must allow the Forwarder at one endpoint to identify the Forwarder at 193 the other. In [I-D.ietf-pwe3-control-protocol] the term "Attachment 194 Identifier", or "AI", is used to refer to a quantity whose purpose is 195 to identify a Forwarder. In [I-D.ietf-l2tpext-l2vpn], the term 196 "Forwarder Identifier" is used for the same purpose. In the context 197 of this document, "Attachment Identifier" and "Forwarder Identifier" 198 are used interchangeably. 200 [I-D.ietf-pwe3-control-protocol] specifies two FEC elements that can 201 be used when setting up pseudowires, the PWid FEC element, and the 202 Generalized Id FEC element. The PWid FEC element carries only one 203 Forwarder identifier; it can be thus be used only when both 204 forwarders have the same identifier, and when that identifier can be 205 coded as a 32-bit quantity. The Generalized Id FEC element carries 206 two Forwarder identifiers, one for each of the two Forwarders being 207 connected. Each identifier is known as an Attachment Identifier, and 208 a signaling message carries both a "Source Attachment Identifier" 209 (SAI) and a "Target Attachment Identifier" (TAI). 211 The Generalized ID FEC element also provides some additional 212 structuring of the identifiers. It is assumed that the SAI and TAI 213 will sometimes have a common part, called the "Attachment Group 214 Identifier" (AGI), such that the SAI and TAI can each be thought of 215 as the concatenation of the AGI with an "Attachment Individual 216 Identifier" (AII). So the pair of identifiers is encoded into three 217 fields: AGI, Source AII (SAII), and Target AII (TAII). The SAI is 218 the concatenation of the AGI and the SAII, while the TAI is the 219 concatenation of the AGI and the TAII. 221 Similarly, [I-D.ietf-l2tpext-l2vpn] allows using one or two Forwarder 222 Identifiers to set up pseudowires. If only the target Forwarder 223 Identifier is used in L2TP signaling messages, both the source and 224 target Forwarders are assumed to have the same value. If both the 225 source and target Forwarder Identifiers are carried in L2TP signaling 226 messages, each Forwarder uses a locally significant identifier value. 228 The Forwarder Identifier in [I-D.ietf-l2tpext-l2vpn] is an equivalent 229 term to Attachment Identifier in [I-D.ietf-pwe3-control-protocol]. A 230 Forwarder Identifier also consists of an Attachment Group Identifier 231 and an Attachment Individual Identifier. Unlike the Generalized ID 232 FEC element, the AGI and AII are carried in distinct L2TP Attribute- 233 Value-Pairs (AVPs). The AGI is encoded in the AGI AVP, and the SAII 234 and TAII are encoded in the Local End ID AVP and the Remote End ID 235 AVP respectively. The source Forwarder Identifier is the 236 concatenation of the AGI and SAII, while the target Forwarder 237 Identifier is the concatenation of the AGI and TAII. 239 In applications that group sets of PWs into "Layer 2 Virtual Private 240 Networks", the AGI can be thought of as a "VPN Identifier". 242 It should be noted that while different forwarders support different 243 applications, the type of application (e.g., VPLS vs. VPWS) cannot 244 necessarily be inferred from the forwarders' identifiers. A router 245 receiving a signaling message with a particular TAI will have to be 246 able to determine which of its local forwarders is identified by that 247 TAI, and to determine the application provided by that forwarder. 248 But other nodes may not be able to infer the application simply by 249 inspection of the signaling messages. 251 In this document some further structure of the AGI and AII is 252 proposed for certain L2VPN applications. We note that [I-D.ietf- 253 pwe3-control-protocol] defines a TLV structure for AGI and AII 254 fields. Thus, an operator who chooses to use the AII structure 255 defined here could also make use of different AGI or AII types if he 256 also wanted to use a different structure for these identifiers for 257 some other application. For example, the long prefix type of 258 [I-D.metz-aii-aggregate] could be used to enable the communication of 259 administrative information, perhaps combined with information learned 260 during autodiscovery. 262 2.2. Creating a Single Bidirectional Pseudowire 264 In any form of LDP-based signaling, each PW endpoint must initiate 265 the creation of a unidirectional LSP. A PW is a pair of such LSPs. 266 In most of the L2VPN provisioning models, the two endpoints of a 267 given PW can simultaneously initiate the signaling for it. They must 268 therefore have some way of determining when a given pair of LSPs are 269 intended to be associated together as a single PW. 271 The way in which this association is done is different for the 272 various different L2VPN services and provisioning models. The 273 details appear in later sections. 275 L2TP signaling inherently establishes a bidirectional session that 276 carries a PW between two PW endpoints. The two endpoints can also 277 simultaneously initiate the signaling for a given PW. It is possible 278 that two PWs can be established for a pair of Forwarders. 280 In order to avoid setting up duplicated pseudowires between two 281 Forwarders, each PE must be able to independently detect such a 282 pseudowire tie. The procedures of detecting a pseudowire tie is 283 described in [I-D.ietf-l2tpext-l2vpn] 285 2.3. Attachment Identifiers and Forwarders 287 Every Forwarder in a PE must be associated with an Attachment 288 Identifier (AI), either through configuration or through some 289 algorithm. The Attachment Identifier must be unique in the context 290 of the PE router in which the Forwarder resides. The combination must be globally unique. 293 As specified in [I-D.ietf-pwe3-control-protocol], the Attachment 294 Identifier may consist of an Attachment Group Identifier (AGI) plus 295 an Attachment Individual Identifier (AII). In the context of this 296 document, an AGI may be thought of as a VPN-id, or some attribute 297 which is shared by all the Attachment Circuits which are allowed to 298 be connected. 300 It is sometimes helpful to consider a set of attachment circuits at a 301 single PE to belong to a common "pool". For example a set of 302 attachment circuits that connect a single CE to a given PE may be 303 considered a pool. The use of pools is described in detail in 304 Section 3.3. 306 The details for how to construct the AGI and AII fields identifying 307 the pseudowire endpoints in particular provisioning models are 308 discussed later in this document. 310 We can now consider an LSP for one direction of a pseudowire to be 311 identified by: 313 o , PE2, > 315 and the LSP in the opposite direction of the pseudowire will be 316 identified by: 318 o , PE1, > 320 A pseudowire is a pair of such LSPs. In the case of using L2TP 321 signaling, these refer to the two directions of an L2TP session. 323 When a signaling message is sent from PE1 to PE2, and PE1 needs to 324 refer to an Attachment Identifier which has been configured on one of 325 its own Attachment Circuits (or pools), the Attachment Identifier is 326 called a "Source Attachment Identifier". If PE1 needs to refer to an 327 Attachment Identifier which has been configured on one of PE2's 328 Attachment Circuits (or pools), the Attachment Identifier is called a 329 "Target Attachment Identifier". (So an SAI at one endpoint is a TAI 330 at the remote endpoint, and vice versa.) 332 In the signaling protocol, we define encodings for the following 333 three fields: 335 o Attachment Group Identifier (AGI) 337 o Source Attachment Individual Identifier (SAII) 339 o Target Attachment Individual Identifier (TAII) 341 If the AGI is non-null, then the SAI consists of the AGI together 342 with the SAII, and the TAI consists of the TAII together with the 343 AGI. If the AGI is null, then the SAII and TAII are the SAI and TAI 344 respectively. 346 The intention is that the PE which receives an LDP Label Mapping 347 message or an L2TP Incoming Call Request (ICRQ) message containing a 348 TAI will be able to map that TAI uniquely to one of its Attachment 349 Circuits (or pools). The way in which a PE maps a TAI to an 350 Attachment Circuit (or pool) should be a local matter (including the 351 choice of whether to use some or all of the bytes in the TAI for the 352 mapping). So as far as the signaling procedures are concerned, the 353 TAI is really just an arbitrary string of bytes, a "cookie". 355 3. Applications 357 In this section, we specify the way in which the pseudowire signaling 358 using the notion of source and target Forwarder is applied for a 359 number of different applications. For some of the applications, we 360 specify the way in which different provisioning models can be used. 361 However, this is not meant to be an exhaustive list of the 362 applications, or an exhaustive list of the provisioning models that 363 can be applied to each application. 365 3.1. Individual Point-to-Point Pseudowires 367 The signaling specified in this document can be used to set up 368 individually provisioned point-to-point pseudowires. In this 369 application, each Forwarder binds a single PW to a single Attachment 370 Circuit. Each PE must be provisioned with the necessary set of 371 Attachment Circuits, and then certain parameters must be provisioned 372 for each Attachment Circuit. 374 3.1.1. Provisioning Models 376 3.1.1.1. Double Sided Provisioning 378 In this model, the Attachment Circuit must be provisioned with a 379 local name, a remote PE address, and a remote name. During 380 signaling, the local name is sent as the SAII, the remote name as the 381 TAII, and the AGI is null. If two Attachment Circuits are to be 382 connected by a PW, the local name of each must be the remote name of 383 the other. 385 Note that if the local name and the remote name are the same, the 386 PWid FEC element can be used instead of the Generalized ID FEC 387 element in the LDP based signaling. 389 With L2TP signaling, the local name is sent in Local End ID AVP, the 390 remote name in Remote End ID AVP. The AGI AVP is optional. If 391 present, it contains a zero-length AGI value. If the local name and 392 the remote name are the same, Local End ID AVP can be omitted from 393 L2TP signaling messages. 395 3.1.1.2. Single Sided Provisioning with Discovery 397 In this model, each Attachment Circuit must be provisioned with a 398 local name. The local name consists of a VPN-id (signaled as the 399 AGI) and an Attachment Individual Identifier which is unique relative 400 to the AGI. If two Attachment circuits are to be connected by a PW, 401 only one of them needs to be provisioned with a remote name (which of 402 course is the local name of the other Attachment Circuit). Neither 403 needs to be provisioned with the address of the remote PE, but both 404 must have the same VPN-id. 406 As part of an auto-discovery procedure, each PE advertises its 407 pairs. Each PE compares its local pairs with the pairs advertised by 409 the other PEs. If PE1 has a local pair with 410 value , and PE2 has a local pair with 411 value , PE1 will thus be able to discover that it needs to 412 connect to PE2. When signaling, it will use "fred" as the TAII, and 413 will use V as the AGI. PE1's local name for the Attachment Circuit 414 is sent as the SAII. 416 The primary benefit of this provisioning model when compared to 417 Double Sided Provisioning is that it enables one to move an 418 Attachment Circuit from one PE to another without having to 419 reconfigure the remote endpoint. However, compared to the approach 420 described in Section 3.3 below, it imposes a greater burden on the 421 discovery mechanism, because each attachment circuit's name must be 422 advertised individually (i.e. there is no aggregation of AC names in 423 this simple scheme). 425 3.1.2. Signaling 427 The LDP-based signaling follows the procedures specified in 428 [I-D.ietf-pwe3-control-protocol]. That is, one PE (PE1) sends a 429 Label Mapping Message to another PE (PE2) to establish an LSP in one 430 direction. If that message is processed successfully, and there is 431 not yet an LSP for the pseudowire in the opposite (PE1->PE2) 432 direction, then PE2 sends a Label Mapping Message to PE1. 434 In addition to the procedures of [I-D.ietf-pwe3-control-protocol], 435 when a PE receives a Label Mapping Message, and the TAI identifies a 436 particular Attachment Circuit which is configured to be bound to a 437 point-to-point PW, then the following checks must be made. 439 If the Attachment Circuit is already bound to a pseudowire (including 440 the case where only one of the two LSPs currently exists), and the 441 remote endpoint is not PE1, then PE2 sends a Label Release message to 442 PE1, with a Status Code meaning "Attachment Circuit bound to 443 different PE", and the processing of the Mapping message is complete. 445 If the Attachment Circuit is already bound to a pseudowire (including 446 the case where only one of the two LSPs currently exists), but the AI 447 at PE1 is different than that specified in the AGI/SAII fields of the 448 Mapping message then PE2 sends a Label Release message to PE1, with a 449 Status Code meaning "Attachment Circuit bound to different remote 450 Attachment Circuit", and the processing of the Mapping message is 451 complete. 453 Similarly with the L2TP-based signaling, when a PE receives an ICRQ 454 message, and the TAI identifies a particular Attachment Circuit which 455 is configured to be bound to a point-to-point PW, it performs the 456 following checks. 458 If the Attachment Circuit is already bound to a pseudowire, and the 459 remote endpoint is not PE1, then PE2 sends a Call Disconnect Notify 460 (CDN) message to PE1, with a Status Code meaning "Attachment Circuit 461 bound to different PE", and the processing of the ICRQ message is 462 complete. 464 If the Attachment Circuit is already bound to a pseudowire, but the 465 pseudowire is bound to a Forwarder on PE1 with the AI different than 466 that specified in the SAI fields of the ICRQ message, then PE2 sends 467 a CDN message to PE1, with a Status Code meaning "Attachment Circuit 468 bound to different remote Attachment Circuit", and the processing of 469 the ICRQ message is complete. 471 These errors could occur as the result of misconfigurations. 473 3.2. Virtual Private LAN Service 475 In the VPLS application [I-D.ietf-l2vpn-vpls-ldp], the Attachment 476 Circuits can be thought of as LAN interfaces which attach to "virtual 477 LAN switches", or, in the terminology of [I-D.ietf-l2vpn-l2- 478 framework], "Virtual Switching Instances" (VSIs). Each Forwarder is 479 a VSI that attaches to a number of PWs and a number of Attachment 480 Circuits. The VPLS service requires that a single pseudowire be 481 created between each pair of VSIs that are in the same VPLS. Each PE 482 device may have multiple VSIs, where each VSI belongs to a different 483 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 A framework for BGP-based auto-discovery for a generic L2VPN service 504 is described in [I-D.ietf-l3vpn-bgpvpn-auto], section 3.2. In this 505 section we specify how BGP-based auto-discovery can be used to build 506 VPLS instances. 508 When BGP-based autodiscovery is used for VPLS, the AFI/SAFI will be: 510 o An AFI specified by IANA for L2VPN. (This is the same for all 511 L2VPN schemes.) 513 o A SAFI specified by IANA specifically for an L2VPN service whose 514 pseudowires are set up using the procedures described in the 515 current document. 517 See Section 6 for further discussion of AFI/SAFI assignment. 519 In order to use BGP-based auto-discovery, there must be at least one 520 globally unique identifier associated with a VPLS, and each such 521 identifier must be encodable as an 8-byte Route Distinguisher (RD). 522 Any method of assigning one or more unique identifiers to a VPLS and 523 encoding each of them as an RD (using the encoding techniques of 524 [RFC4364]) will do. 526 It is RECOMMENDED that a single VPN-ID be assigned to a VPLS 527 instance. That VPN-ID MAY be a VPN-ID as defined in [RFC2685], in 528 which case it SHOULD be encoded as an RD by placing the value 0x80 in 529 the first byte of the RD (to indicate the RD type) and the 7-byte 530 VPN-ID in the remaining bytes of the RD. However, any method of 531 assigning a unique VPN-ID to each VPLS instance and encoding that 532 VPN-ID in an RD MAY be used. 534 Each VSI needs to have a unique identifier, which can be encoded as a 535 BGP NLRI. This is formed by prepending the RD (from the previous 536 paragraph) to an IP address of the PE containing the VSI. Note that 537 the role of this address is simply as a readily available unique 538 identifier for the VSIs within a VPN; it does not need to be globally 539 routable. An alternate numbering scheme (e.g. numbering the VSIs of 540 a single VPN from 1 to n) could be used if desired. 542 Each VSI needs to be associated with one or more Route Target (RT) 543 Extended Communities. These control the distribution of the NLRI, 544 and hence will control the formation of the overlay topology of 545 pseudowires that constitutes a particular VPLS. 547 Auto-discovery proceeds by having each PE distribute, via BGP, the 548 NLRI for each of its VSIs, with itself as the BGP next hop, and with 549 the appropriate RT for each such NLRI. Typically, each PE would be a 550 client of a small set of BGP route reflectors, which would 551 redistribute this information to the other clients. 553 If a PE has a VSI with a particular RT, it can then import all the 554 NLRI which have that same RT, and from the BGP next hop attribute of 555 these NLRI it will learn the IP addresses of the other PE routers 556 which have VSIs with the same RT. The considerations of [RFC4364] 557 section 4.3.3 on the use of route reflectors apply. 559 If a particular VPLS is meant to be a single fully connected LAN, all 560 its VSIs will have the same RT, in which case the RT could be (though 561 it need not be) an encoding of the VPN-id. A VSI can be placed in 562 multiple VPLSes by assigning it multiple RTs. 564 Note that hierarchical VPLS can be set up by assigning multiple RTs 565 to some of the VSIs; the RT mechanism allows one to have complete 566 control over the pseudowire overlay which constitutes the VPLS 567 topology. 569 If Distributed VPLS (described in Section 3.5) is deployed, only the 570 N-PEs participate in BGP-based autodiscovery. This means that an 571 N-PE would need to advertise reachability to each of the VSIs that it 572 supports, including those located in U-PEs to which it is connected. 573 To create a unique identifier for each such VSI, an IP address of 574 each U-PE combined with the RD for the VPLS instance could be used. 576 In summary, the BGP advertisement for a particular VSI at a given PE 577 will contain: 579 o an NLRI of AFI = L2VPN, SAFI = TBA, encoded as RD:PE_addr 581 o a BGP next hop equal to the loopback address of the PE 583 o an extended community attribute containing one or more RTs. 585 See Section Section 6 for discussion of the AFI and SAFI values. 587 Note that this advertisement is quite similar to the NLRI format 588 defined in [I-D.ietf-l2vpn-vpls-bgp], the main difference being that 589 [I-D.ietf-l2vpn-vpls-bgp] also includes a label block in the NLRI. 590 Interoperability between the VPLS scheme defined here and that 591 defined in [I-D.ietf-l2vpn-vpls-bgp] is beyond the scope of this 592 document. 594 3.2.3. Signaling 596 It is necessary to create Attachment Identifiers which identify the 597 VSIs. In the preceding section, a VSI-ID was encoded as RD:PE_addr 598 for the purposes of autodiscovery. For signaling purposes, the same 599 information is carried but is encoded slightly differently. 600 Specifically, we encode the RD in the AGI field, and place the 601 PE_addr (or, more generally, the VSI-ID that was advertised in BGP, 602 minus the RD) in the TAII field. The combination of AGI and TAII is 603 sufficient to fully specify the VSI to which this pseudowire is to be 604 connected, in both single AS and inter-AS environments. The SAII 605 MUST be set to the PE_addr of the sending PE (or, more generally, the 606 VSI-ID, without the RD, of the VSI associated with this VPLS in the 607 sending PE), to enable signaling of the reverse half of the PW if 608 needed. 610 The structure of the AGI and AII fields for the Generalized ID FEC in 611 LDP is defined in [I-D.ietf-pwe3-control-protocol]. The AGI field in 612 this case consists of a Type of 1, a length field of value 8, and the 613 8 bytes of the RD. The TAII consists of a Type of 1, a length field 614 of value 4, followed by the 4-byte PE address (or other 4-byte 615 identifier). See Section 6 for discussion of the AGI and AII Type 616 assignment. 618 The encoding of the AGI and AII in L2TP is specified in [I-D.ietf- 619 l2tpext-l2vpn]. 621 Note that it is not possible using this technique to set up more than 622 one PW per pair of VSIs. 624 3.2.4. Pseudowires as VPLS Attachment Circuits 626 It is also possible using this technique to set up a PW which 627 attaches at one endpoint to a VSI, but at the other endpoint only to 628 an Attachment Circuit. There may be more than one PW terminating on 629 a given VSI, which must somehow be distinguished, so each PW must 630 have an SAII which is unique relative to the VSI-ID. 632 3.3. Colored Pools: Full Mesh of Point-to-Point Pseudowires 634 The "Colored Pools" model of operation provides an automated way to 635 deliver Virtual Private Wire Service (VPWS). In this model, each PE 636 may contain several pools of Attachment Circuits, each pool 637 associated with a particular VPN. A PE may contain multiple pools 638 per VPN, as each pool may correspond to a particular CE device. It 639 may be desired to create one pseudowire between each pair of pools 640 that are in the same VPN; the result would be to create a full mesh 641 of CE-CE VCs for each VPN. 643 3.3.1. Provisioning 645 Each pool is configured, and associated with: 647 o a set of Attachment Circuits; 649 o a "color", which can be thought of as a VPN-id of some sort; 651 o a relative pool identifier, which is unique relative to the color. 653 [Note: depending on the technology used for Attachment Circuits, it 654 may or may not be necessary to provision these circuits as well. For 655 example, if the ACs are frame relay circuits, there may be some 656 separate provisioning system to set up such circuits. Alternatively, 657 "provisioning" an AC may be as simple as allocating an unused VLAN ID 658 on an interface, and communicating the choice to the customer. These 659 issues are independent of the procedures described in this document.] 661 The pool identifier, and color, taken together, constitute a globally 662 unique identifier for the pool. Thus if there are n pools of a given 663 color, their pool identifiers can be (though they do not need to be) 664 the numbers 1-n. 666 The semantics are that a pseudowire will be created between every 667 pair of pools that have the same color, where each such pseudowire 668 will be bound to one Attachment Circuit from each of the two pools. 670 If each pool is a set of Attachment Circuits leading to a single CE 671 device, then the layer 2 connectivity among the CEs is controlled by 672 the way the colors are assigned to the pools. To create a full mesh, 673 the "color" would just be a VPN-id. 675 Optionally, a particular Attachment Circuit may be configured with 676 the relative pool identifier of a remote pool. Then that Attachment 677 Circuit would be bound to a particular pseudowire only if that 678 pseudowire's remote endpoint is the pool with that relative pool 679 identifier. With this option, the same pairs of Attachment Circuits 680 will always be bound via pseudowires. 682 3.3.2. Auto-Discovery 684 3.3.2.1. BGP-based auto-discovery 686 A framework for BGP-based auto-discovery for a generic L2VPN service 687 is described in [I-D.ietf-l3vpn-bgpvpn-auto], section 3.2. In this 688 section we specify how BGP-based auto-discovery can be used to build 689 VPWS instances. 691 When BGP-based autodiscovery is used for VPWS, the AFI/SAFI will be: 693 o An AFI specified by IANA for L2VPN. (This is the same for all 694 L2VPN schemes.) 696 o A SAFI specified by IANA specifically for an L2VPN service whose 697 pseudowires are set up using the procedures described in the 698 current document. 700 See Section 6 for further discussion of AFI/SAFI assignment. 702 In order to use BGP-based auto-discovery, there must be one or more 703 unique identifiers (the "color") associated with a particular VPWS 704 instance. Each identifier must be encodable as an RD (Route 705 Distinguisher). The globally unique identifier of a pool must be 706 encodable as NLRI; the color would be encoded as the RD and the pool 707 identifier as a four-byte quantity which is appended to the RD to 708 create the NLRI. 710 Each pool must also be associated with an RT (route target), which 711 may also be an encoding of the color. If the desired topology is a 712 full mesh of pseudowires, all pools may have the same RT. See 713 Section 3.4 for a discussion of other topologies. 715 Auto-discovery proceeds by having each PE distribute, via BGP, the 716 NLRI for each of its pools, with itself as the BGP next hop, and with 717 the RT that encodes the pool's color. If a given PE has a pool with 718 a particular color (RT), it must receive, via BGP, all NLRI with that 719 same color (RT). Typically, each PE would be a client of a small set 720 of BGP route reflectors, which would redistribute this information to 721 the other clients. 723 If a PE has a pool with a particular color, it can then receive all 724 the NLRI which have that same color, and from the BGP next hop 725 attribute of these NLRI will learn the IP addresses of the other PE 726 routers which have pools switches with the same color. It also 727 learns the unique identifier of each such remote pool, as this is 728 encoded in the NLRI. The remote pool's relative identifier can be 729 extracted from the NLRI and used in the signaling, as specified 730 below. 732 In summary, the BGP advertisement for a particular pool of attachment 733 circuits at a given PE will contain: 735 o an NLRI of AFI = L2VPN, SAFI = TBA, encoded as RD:pool_num; 737 o a BGP next hop equal to the loopback address of the PE; 738 o an extended community attribute containing one or more RTs. 740 See Section Section 6 for discussion of the AFI and SAFI values. 742 3.3.3. Signaling 744 The LDP-based signaling follows the procedures specified in 745 [I-D.ietf-pwe3-control-protocol]. That is, one PE (PE1) sends a 746 Label Mapping Message to another PE (PE2) to establish an LSP in one 747 direction. The address of PE2 is the next-hop address learned via 748 BGP as described above. If the message is processed successfully, 749 and there is not yet an LSP for the pseudowire in the opposite 750 (PE1->PE2) direction, then PE2 sends a Label Mapping Message to PE1. 751 Similarly, the L2TPv3-based signaling follows the procedures of 752 [I-D.ietf-l2tpext-l2vpn]. Additional details on the use of these 753 signaling protocols follow. 755 When a PE sends a Label Mapping message or an ICRQ message to set up 756 a PW between two pools, it encodes the color as the AGI, the local 757 pool's relative identifier as the SAII, and the remote pool's 758 relative identifier as the TAII. 760 The structure of the AGI and AII fields for the Generalized ID FEC in 761 LDP is defined in [I-D.ietf-pwe3-control-protocol]. The AGI field in 762 this case consists of a Type of 1, a length field of value 8, and the 763 8 bytes of the RD. The TAII consists of a Type of 1, a length field 764 of value 4, followed by the 4-byte remote pool number. The SAII 765 consists of a Type of 1, a length field of value 4, followed by the 766 4-byte local pool number. See Section 6 for discussion of the AGI 767 and AII Type assignment. Note that the VPLS and VPWS procedures 768 defined in this document can make use of the same AGI Type (1) and 769 the same AII Type (1). 771 The encoding of the AGI and AII in L2TP is specified in [I-D.ietf- 772 l2tpext-l2vpn]. 774 When PE2 receives a Label Mapping message or an ICRQ message from 775 PE1, and the TAI identifies to a pool, and there is already an 776 pseudowire connecting an Attachment Circuit in that pool to an 777 Attachment Circuit at PE1, and the AI at PE1 of that pseudowire is 778 the same as the SAI of the Label Mapping or ICRQ message, then PE2 779 sends a Label Release or CDN message to PE1, with a Status Code 780 meaning "Attachment Circuit already bound to remote Attachment 781 Circuit". This prevents the creation of multiple pseudowires between 782 a given pair of pools. 784 Note that the signaling itself only identifies the remote pool to 785 which the pseudowire is to lead, not the remote Attachment Circuit 786 which is to be bound to the the pseudowire. However, the remote PE 787 may examine the SAII field to determine which Attachment Circuit 788 should be bound to the pseudowire. 790 3.4. Colored Pools: Partial Mesh 792 The procedures for creating a partial mesh of pseudowires among a set 793 of colored pools are substantially the same as those for creating a 794 full mesh, with the following exceptions: 796 o Each pool is optionally configured with a set of "import RTs" and 797 "export RTs"; 799 o During BGP-based auto-discovery, the pool color is still encoded 800 in the RD, but if the pool is configured with a set of "export 801 RTs", these are are encoded in the RTs of the BGP Update messages, 802 INSTEAD of the color; 804 o If a pool has a particular "import RT" value X, it will create a 805 PW to every other pool which has X as one of its "export RTs". 806 The signaling messages and procedures themselves are as in section 807 3.3.3. 809 As a simple example, consider the task of building a hub-and-spoke 810 topology with a single hub. One pool, the "hub" pool, is configured 811 with an export RT of RT_hub and an import RT of RT_spoke. All other 812 pools (the spokes) are configured with an export RT of RT_spoke and 813 an import RT of RT_hub. Thus the Hub pool will connect to the 814 spokes, and vice-versa, but the spoke pools will not connect to each 815 other. More complex examples are presented in section 4.2.2 of 816 [I-D.ietf-l3vpn-bgpvpn-auto]. 818 3.5. Distributed VPLS 820 In Distributed VPLS ([I-D.ietf-l2vpn-l2-framework]), the VPLS 821 functionality of a PE router is divided among two systems: a U-PE and 822 an N-PE. The U-PE sits between the user and the N-PE. VSI 823 functionality (e.g., MAC address learning and bridging) is performed 824 on the U-PE. A number of U-PEs attach to an N-PE. For each VPLS 825 supported by a U-PE, the U-PE maintains a pseudowire to each other 826 U-PE in the same VPLS. However, the U-PEs do not maintain signaling 827 control connections with each other. Rather, each U-PE has only a 828 single signaling connection, to its N-PE. In essence, each U-PE-to- 829 U-PE pseudowire is composed of three pseudowires spliced together: 830 one from U-PE to N-PE, one from N-PE to N-PE, and one from N-PE to 831 U-PE. In the terminology of [I-D.ietf-pwe3-ms-pw-arch], the N-PEs 832 perform the pseudowire switching function to establish multi-segment 833 PWs from U-PE to U-PE. 835 Consider for example the following topology: 837 U-PE A-----| |----U-PE C 838 | | 839 | | 840 N-PE E--------N-PE F 841 | | 842 | | 843 U-PE B-----| |-----U-PE D 845 where the four U-PEs are in a common VPLS. We now illustrate how PWs 846 get spliced together in the above topology in order to establish the 847 necessary PWs from U-PE A to the other U-PEs. 849 There are three PWs from A to E. Call these A-E/1, A-E/2, and A-E/3. 850 In order to connect A properly to the other U-PEs, there must be two 851 PWs from E to F (call these E-F/1 and E-F/2), one PW from E to B 852 (E-B/1), one from F to C (F-C/1), and one from F to D (F-D/1). 854 The N-PEs must then splice these pseudowires together to get the 855 equivalent of what the non-distributed VPLS signaling mechanism would 856 provide: 858 o PW from A to B: A-E/1 gets spliced to E-B/1. 860 o PW from A to C: A-E/2 gets spliced to E-F/1 gets spliced to F-C/1. 862 o PW from A to D: A-E/3 gets spliced to E-F/2 gets spliced to F-D/1. 864 It doesn't matter which PWs get spliced together, as long as the 865 result is one from A to each of B, C, and D. 867 Similarly, there are additional PWs which must get spliced together 868 to properly interconnect U-PE B with U-PEs C and D, and to 869 interconnect U-PE C with U-PE D. 871 The following figure illustrates the PWs from A to C and from B to D. 872 For clarity of the figure, the other four PWs are not shown. 874 splicing points 875 | | 876 V V 877 A-C PW <-----><-----------><------> 879 U-PE A-----| |----U-PE C 880 | | 881 | | 882 N-PE E--------N-PE F 883 | | 884 | | 885 U-PE B-----| |-----U-PE D 887 B-D PW <-----><-----------><------> 888 ^ ^ 889 | | 890 splicing points 892 One can see that distributed VPLS does not reduce the number of 893 pseudowires per U-PE, but it does reduce the number of control 894 connections per U-PE. Whether this is worthwhile depends, of course, 895 on what the bottleneck is. 897 3.5.1. Signaling 899 The signaling to support Distributed VPLS can be done with the 900 mechanisms described in this document. However, the procedures for 901 VPLS (section 3.2.3) need some additional machinery to ensure that 902 the appropriate number of PWs are established between the various 903 N-PEs and U-PEs, and among the N-PEs. 905 At a given N-PE, the directly attached U-PEs in a given VPLS can be 906 numbered from 1 to n. This number identifies the U-PE relative to a 907 particular VPN-id and a particular N-PE. (That is, to uniquely 908 identify the U-PE, the N-PE, the VPN-id, and the U-PE number must be 909 known.) 911 As a result of configuration/discovery, each U-PE must be given a 912 list of pairs. Each element in this list tells the 913 U-PE to set up j PWs to the specified IP address. When the U-PE 914 signals to the N-PE, it sets the AGI to the proper-VPN-id, and sets 915 the SAII to the PW number, and sets the TAII to null. 917 In the above example, U-PE A would be told <3, E>, telling it to set 918 up 3 PWs to E. When signaling, A would set the AGI to the proper 919 VPN-id, and would set the SAII to 1, 2, or 3, depending on which of 920 the three PWs it is signaling. 922 As a result of configuration/discovery, each N-PE must be given the 923 following information for each VPLS: 925 o A "Local" list: {}, where each element tells it to 926 set up j PWs to the locally attached U-PE at the specified 927 address. The number of elements in this list will be n, the 928 number of locally attached U-PEs in this VPLS. In the above 929 example, E would be given the local list: {<3, A>, <3, B>}, 930 telling it to set up 3 PWs to A and 3 to B. 932 o A local numbering, relative to the particular VPLS and the 933 particular N-PE, of its U-PEs. In the above example, E could be 934 told that U-PE A is 1, and U-PE B is 2. 936 o A "Remote" list: {}, telling it to set up k PWs, 937 for each U-PE, to the specified IP address. Each of these IP 938 addresses identifies a N-PE, and k specifies the number of U-PEs 939 at that N-PE which are in the VPLS. In the above example, E would 940 be given the remote list: {<2, F>}. Since N-PE E has two U-PEs, 941 this tells it to set up 4 PWs to N-PE F, 2 for each of its E's 942 U-PEs. 944 The signaling of a PW from N-PE to U-PE is based on the local list 945 and the local numbering of U-PEs. When signaling a particular PW 946 from an N-PE to a U-PE, the AGI is set to the proper VPN-id, and SAII 947 is set to null, and the TAII is set to the PW number (relative to 948 that particular VPLS and U-PE). In the above example, when E signals 949 to A, it would set the TAII to be 1, 2, or 3, respectively, for the 950 three PWs it must set up to A. It would similarly signal three PWs to 951 B. 953 The LSP signaled from U-PE to N-PE is associated with an LSP from 954 N-PE to U-PE in the usual manner. A PW between a U-PE and an N-PE is 955 known as a "U-PW". 957 The signaling of the appropriate set of PWs from N-PE to N-PE is 958 based on the remote list. The PWs between the N-PEs can all be 959 considered equivalent. As long as the correct total number of PWs 960 are established, the N-PEs can splice these PWs to appropriate U-PWs. 961 The signaling of the correct number of PWs from N-PE to N-PE is based 962 on the remote list. The remote list specifies the number of PWs to 963 set up, per local U-PE, to a particular remote N-PE. 965 When signaling a particular PW from an N-PE to an N-PE, the AGI is 966 set to the appropriate VPN-id. The TAII identifies the remote N-PE, 967 as in the non-distributed case, i.e. it contains an IP address of the 968 remote N-PE. If there are n such PWs, they are distinguished by the 969 setting of the SAII. In order to allow multiple different SAII 970 values in a single VPLS, the sending N-PE needs to have as many VSI- 971 IDs as it has U-PEs. As noted above in Section 3.2.2, this may be 972 achieved by using an IP address of each attached U-PE, for example. 973 A PW between two N-PEs is known as an "N-PW". 975 Each U-PW must be "spliced" to an N-PW. This is based on the remote 976 list. If the remote list contains an element , then i U-PWs 977 from each local U-PE must be spliced to i N-PWs from the remote N-PE 978 F. It does not matter which U-PWs are spliced to which N-PWs, as long 979 as this constraint is met. 981 If an N-PE has more than one local U-PE for a given VPLS, it must 982 also ensure that a U-PW from each such U-PE is spliced to a U-PW from 983 each of the other U-PEs. 985 3.5.2. Provisioning and Discovery 987 Every N-PE must be provisioned with the set of VPLS instances it 988 supports, a VPN-id for each one, and a list of local U-PEs for each 989 such VPLS. As part of the discovery procedure, the N-PE advertises 990 the number of U-PEs for each VPLS. See Section 3.2.2 for details. 992 Auto-discovery (e.g., BGP-based) can be used to discover all the 993 other N-PEs in the VPLS, and for each, the number of U-PEs local to 994 that N-PE. From this, one can compute the total number of U-PEs in 995 the VPLS. This information is sufficient to enable one to compute 996 the local list and the remote list for each N-PE. 998 3.5.3. Non-distributed VPLS as a sub-case 1000 A PE which is providing "non-distributed VPLS" (i.e., a PE which 1001 performs both the U-PE and N-PE functions) can interoperate with 1002 N-PE/U-PE pairs that are providing distributed VPLS. The "non- 1003 distributed PE" simply advertises, in the discovery procedure, that 1004 it has one local U-PE per VPLS. And of course, the non-distributed 1005 PE does no PW switching. 1007 If every PE in a VPLS is providing non-distributed VPLS, and thus 1008 every PE advertises itself as an N-PE with one local U-PE, the 1009 resultant signaling is exactly the same as that specified in 1010 Section 3.2.3 above. 1012 3.5.4. Splicing and the Data Plane 1014 Splicing two PWs together is quite straightforward in the MPLS data 1015 plane, as moving a packet from one PW directly to another is just a 1016 label replace operation on the PW label. When a PW consists of two 1017 or more PWs spliced together, it is assumed that the data will go to 1018 the node where the splicing is being done, i.e., that the data path 1019 will pass through the nodes that participate in PW signaling. 1021 Further details on splicing are discussed in [I-D.ietf-pwe3- 1022 segmented-pw]. 1024 4. Inter-AS Operation 1026 The provisioning, autodiscovery and signaling mechanisms described 1027 above can all be applied in an inter-AS environment. As in [RFC4364] 1028 there are a number of options for inter-AS operation. 1030 4.1. Multihop EBGP redistribution of L2VPN NLRIs 1032 This option is most like option (c) in [RFC4364]. That is, we use 1033 multihop EBGP redistribution of L2VPN NLRIs between source and 1034 destination ASes, with EBGP redistribution of labeled IPv4 or IPv6 1035 routes from AS to neighboring AS. 1037 An ASBR must maintain labeled IPv4 /32 (or IPv6 /128) routes to the 1038 PE routers within its AS. It uses EBGP to distribute these routes to 1039 other ASes, and sets itself as the BGP next hop for these routes. 1040 ASBRs in any transit ASes will also have to use EBGP to pass along 1041 the labeled /32 (or /128) routes. This results in the creation of a 1042 set of label switched paths from all ingress PE routers to all egress 1043 PE routers. Now PE routers in different ASes can establish multi-hop 1044 EBGP connections to each other, and can exchange L2VPN NLRIs over 1045 those connections. Following such exchanges a pair of PEs in 1046 different ASes could establish an LDP session to signal PWs between 1047 each other. 1049 For VPLS, the BGP advertisement and PW signaling are exactly as 1050 described in Section 3.2. As a result of the multihop EBGP session 1051 that exists between source and destination AS, the PEs in one AS that 1052 have VSIs of a certain VPLS will discover the PEs in another AS that 1053 have VSIs of the same VPLS. These PEs will then be able to establish 1054 the appropriate PW signaling protocol session and establish the full 1055 mesh of VSI-VSI pseudowires to build the VPLS as described in Section 1056 3.2.3. 1058 For VPWS, the BGP advertisement and PW signaling are exactly as 1059 described in Section 3.3. As a result of the multihop EBGP session 1060 that exists between source and destination AS, the PEs in one AS that 1061 have pools of a certain color (VPN) will discover PEs in another AS 1062 that have pools of the same color. These PEs will then be able to 1063 establish the appropriate PW signaling protocol session and establish 1064 the full mesh of pseudowires as described in Section 3.2.3. A 1065 partial mesh can similarly be established using the procedures of 1066 Section 3.4. 1068 As in layer 3 VPNs, building an L2VPN that spans the networks of more 1069 than one provider requires some co-ordination in the use of RTs and 1070 RDs. This subject is discussed in more detail in Section 4.4. 1072 4.2. EBGP redistribution of L2VPN NLRIs with Multi-Segment Pseudowires 1074 A possible drawback of the approach of the previous section is that 1075 it creates PW signaling sessions among all the PEs of a given L2VPN 1076 (VPLS or VPWS). This means a potentially large number of LDP or 1077 L2TPv3 sessions will cross the AS boundary and that these session 1078 connect to many devices within an AS. In the case were the ASes 1079 belong to different providers, one might imagine that providers would 1080 like to have fewer signaling sessions crossing the AS boundary and 1081 that the entities that terminate the sessions could be restricted to 1082 a smaller set of devices. Furthermore, by forcing the LDP or L2TPv3 1083 signaling sessions to terminate on a small set of ASBRs, a provider 1084 could use standard authentication procedures on a small set of inter- 1085 provider sessions. These concerns motivate the approach described 1086 here. 1088 [I-D.ietf-pwe3-segmented-pw] describes an approach to "switching" 1089 packets from one pseudowire to another at a particular node. This 1090 approach allows an end-to-end, multi-segment pseudowire to be 1091 constructed out of several pseudowire segments, without maintaining 1092 an end-to-end control connection. We can use this approach to 1093 produce an inter-AS solution that more closely resembles option (b) 1094 in [RFC4364]. 1096 In this model, we use EBGP redistribution of L2VPN NLRI from AS to 1097 neighboring AS. First, the PE routers use IBGP to redistribute L2VPN 1098 NLRI either to an Autonomous System Border Router (ASBR), or to a 1099 route reflector of which an ASBR is a client. The ASBR then uses 1100 EBGP to redistribute those L2VPN NLRI to an ASBR in another AS, which 1101 in turn distributes them to the PE routers in that AS, or perhaps to 1102 another ASBR which in turn distributes them, and so on. 1104 In this case, a PE can learn the address of an ASBR through which it 1105 could reach another PE to which it wishes to establish a PW. That 1106 is, a local PE will receive a BGP advertisement containing L2VPN NLRI 1107 corresponding to an L2VPN instance in which the local PE has some 1108 attached members. The BGP next-hop for that L2VPN NLRI will be an 1109 ASBR of the local AS. Then, rather than building a control 1110 connection all the way to the remote PE, it builds one only to the 1111 ASBR. A pseudowire segment can now be established from the PE to the 1112 ASBR. The ASBR in turn can establish a PW to the ASBR of the next 1113 AS, and splice that PW to the PW from the PE as described in 1114 Section 3.5.4 and [I-D.ietf-pwe3-segmented-pw]. Repeating the 1115 process at each ASBR leads to a sequence of PW segments that, when 1116 spliced together, connect the two PEs. 1118 Note that in the approach just described, the local PE may never 1119 learn the IP address of the remote PE. It learns the L2VPN NLRI 1120 advertised by the remote PE, which need not contain the remote PE 1121 address, and it learns the IP address of the ASBR that is the BGP 1122 next hop for that NLRI. 1124 When this approach is used for VPLS, or for full-mesh VPWS, it leads 1125 to a full mesh of pseudowires among the PEs, just as in the previous 1126 section, but it does not require a full mesh of control connections 1127 (LDP or L2TPv3 sessions). Instead the control connections within a 1128 single AS run among all the PEs of that AS and the ASBRs of the AS. 1129 A single control connection between the ASBRs of adjacent ASes can be 1130 used to support however many AS-to-AS pseudowire segments are needed. 1132 Note that the procedures described here will result in the splicing 1133 points (S-PEs in the terminology of [I-D.ietf-pwe3-ms-pw-arch]) being 1134 co-located with the ASBRs. It is of course possible to have multiple 1135 ASBR-ASBR connections between a given pair of ASes. In this case a 1136 given PE could choose among the available ASBRs based on a range of 1137 criteria, such as IGP metric, local configuration, etc., analogous to 1138 choosing an exit point in normal IP routing. The use of multiple 1139 ASBRs would lead to greater resiliency (at the timescale of BGP 1140 routing convergence) since a PE could select a new ASBR in the event 1141 of the failure of the one currently in use. 1143 As in layer 3 VPNs, building an L2VPN that spans the networks of more 1144 than one provider requires some co-ordination in the use of RTs and 1145 RDs. This subject is discussed in more detail in Section 4.4. 1147 4.3. Inter-Provider Application of Distributed VPLS Signaling 1149 An alternative approach to inter-provider VPLS can be derived from 1150 the Distributed VPLS approach described above. Consider the 1151 following topology: 1153 PE A --- Network 1 ----- Border ----- Border ----- Network 2 --- PE B 1154 Router 12 Router 21 | 1155 | 1156 PE C 1158 where A, B, and C are PEs in a common VPLS, but Networks 1 and 2 are 1159 networks of different Service Providers. Border Router 12 is Network 1160 1's border router to network 2, and Border Router 21 is Network 2's 1161 border router to Network 1. We suppose further that the PEs are not 1162 "distributed", i.e, that each provides both the U-PE and N-PE 1163 functions. 1165 In this topology, one needs two inter-provider pseudowires: A-B and 1166 A-C. 1168 Suppose a Service Provider decides, for whatever reason, that it does 1169 not want each of its PEs to have a control connection to any PEs in 1170 the other network. Rather, it wants the inter-provider control 1171 connections to run only between the two border routers. 1173 This can be achieved using the techniques of section 3.5, where the 1174 PEs behave like U-PEs, and the BRs behave like N-PEs. In the example 1175 topology, PE A would behave like a U-PE which is locally attached to 1176 BR12; PEs B and C would be have like U-PEs which are locally attached 1177 to BR21; and the two BRs would behave like N-PEs. 1179 As a result, the PW from A to B would consist of three segments: 1180 A-BR12, BR12-BR21, and BR21-B. The border routers would have to 1181 splice the corresponding segments together. 1183 This requires the PEs within a VPLS to be numbered from 1-n (relative 1184 to that VPLS) within a given network. 1186 4.4. RT and RD Assignment Considerations 1188 We note that, in order for any of the inter-AS procedures described 1189 above to work correctly, the two ASes must use RTs and RDs 1190 consistently, just as in layer 3 VPNs [RFC4364]. The structure of 1191 RTs and RDs is such that there is not a great risk of accidental 1192 collisions. The main challenge is that it is necessary for the 1193 operator of one AS to know what RT or RTs have been chosen in another 1194 AS for any VPN that has sites in both ASes. As in layer 3 VPNs, 1195 there are many ways to make this work, but all require some co- 1196 operation among the providers. For example, provider A may tag all 1197 the NLRI for a given VPN with a single RT, say RT_A, and provider B 1198 can then configure the PEs that connect to sites of that VPN to 1199 import NLRI that contains that RT. Provider B can choose a different 1200 RT, RT_B, tag all NLRI for this VPN with that RT, and then provider A 1201 can import NLRI with that RT at the appropriate PEs. However this 1202 does require both providers to communicate their choice of RTs for 1203 each VPN. Alternatively both providers could agree to use a common 1204 RT for a given VPN. In any case communication of RTs between the 1205 providers is essential. As in layer 3 VPNs, providers may configure 1206 RT filtering to ensure that only coordinated RT values are allowed 1207 across the AS boundary. 1209 5. Security Considerations 1211 This document describes a number of different L2VPN provisioning 1212 models, and specifies the endpoint identifiers that are required to 1213 support each of the provisioning models. It also specifies how those 1214 endpoint identifiers are mapped into fields of auto-discovery 1215 protocols and signaling protocols. 1217 The security considerations related to the signaling protocols are 1218 discussed in the relevant protocol specifications ([RFC3036] 1219 [I-D.ietf-pwe3-control-protocol] [RFC3931] [I-D.ietf-l2tpext-l2vpn]). 1221 The security considerations related to BGP-based autodiscovery, 1222 including inter-AS issues, are discussed in [RFC4364]. 1224 The security considerations related to the particular kind of L2VPN 1225 service being supported are discussed in [I-D.ietf-l2vpn-l2- 1226 framework], [I-D.ietf-l2vpn-requirements], and [I-D.ietf-l2vpn-vpls- 1227 ldp]. 1229 The way in which endpoint identifiers are mapped into protocol fields 1230 does not create any additional security issues. 1232 6. IANA Considerations 1234 This document assumes the assignment of an AFI and a SAFI for L2VPN 1235 NLRI. Both AFI and SAFI should be the same as the values assigned 1236 for [I-D.ietf-l2vpn-vpls-bgp]. 1238 [I-D.ietf-pwe3-iana-allocation] defines registries for "Attachment 1239 Group Identifier (AGI) Type" and "Attachment Individual Identifier 1240 (AII) Type". Type 1 in each registry has been assigned to the AGI 1241 and AII formats defined in this document. 1243 This document requires two new LDP status codes. IANA already 1244 maintains a registry of name "STATUS CODE NAME SPACE" defined by 1245 [RFC3036]. The following values are suggested for assignment: 1247 0x0000002C "Attachment Circuit bound to different PE" 1249 0x0000002D "Attachment Circuit bound to different remote Attachment 1250 Circuit". 1252 The document requires two new L2TP Result Codes for the CDN message. 1253 IANA already maintains a registry of L2TP Result Code Values for the 1254 CDN message, defined by [RFC3438]. The following values are 1255 requested for assignment: 1257 RC-TBD1: Attachment Circuit bound to different PE 1259 RC-TBD2: Attachment Circuit bound to different remote Attachment 1260 Circuit 1262 7. Acknowledgments 1264 Thanks to Dan Tappan, Ted Qian, Ali Sajassi, Skip Booth, Luca 1265 Martini, Dave McDysan, Francois LeFaucheur, and Matthew Bocci for 1266 their comments, criticisms, and helpful suggestions. 1268 Thanks to Tissa Senevirathne, Hamid Ould-Brahim and Yakov Rekhter for 1269 discussing the auto-discovery issues. 1271 Thanks to Vach Kompella for a continuing discussion of the proper 1272 semantics of the generalized identifiers. 1274 8. References 1276 8.1. Normative References 1278 [I-D.ietf-idr-bgp-ext-communities] 1279 Rekhter, Y., "BGP Extended Communities Attribute", 1280 draft-ietf-idr-bgp-ext-communities-09 (work in progress), 1281 July 2005. 1283 [I-D.ietf-l2tpext-l2vpn] 1284 Luo, W., "L2VPN Extensions for L2TP", 1285 draft-ietf-l2tpext-l2vpn-07 (work in progress), 1286 March 2006. 1288 [I-D.ietf-pwe3-control-protocol] 1289 Martini, L., "Pseudowire Setup and Maintenance using the 1290 Label Distribution Protocol", 1291 draft-ietf-pwe3-control-protocol-17 (work in progress), 1292 June 2005. 1294 [I-D.ietf-pwe3-segmented-pw] 1295 Martini, L., "Segmented Pseudo Wire", 1296 draft-ietf-pwe3-segmented-pw-01 (work in progress), 1297 October 2005. 1299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1300 Requirement Levels", BCP 14, RFC 2119, March 1997. 1302 [RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks 1303 Identifier", RFC 2685, September 1999. 1305 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 1306 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 1308 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 1309 B. Thomas, "LDP Specification", RFC 3036, January 2001. 1311 [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) 1312 Internet Assigned Numbers Authority (IANA) Considerations 1313 Update", BCP 68, RFC 3438, December 2002. 1315 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 1316 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 1318 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1319 Networks (VPNs)", RFC 4364, February 2006. 1321 8.2. Informative References 1323 [I-D.ietf-l2vpn-l2-framework] 1324 Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 1325 Private Networks (L2VPNs)", 1326 draft-ietf-l2vpn-l2-framework-05 (work in progress), 1327 June 2004. 1329 [I-D.ietf-l2vpn-requirements] 1330 Augustyn, W. and Y. Serbest, "Service Requirements for 1331 Layer 2 Provider Provisioned Virtual Private Networks", 1332 draft-ietf-l2vpn-requirements-06 (work in progress), 1333 January 2006. 1335 [I-D.ietf-l2vpn-vpls-bgp] 1336 Kompella, K. and Y. Rekhter, "Virtual Private LAN 1337 Service", draft-ietf-l2vpn-vpls-bgp-06 (work in progress), 1338 December 2005. 1340 [I-D.ietf-l2vpn-vpls-ldp] 1341 Lasserre, M. and V. Kompella, "Virtual Private LAN 1342 Services over MPLS", draft-ietf-l2vpn-vpls-ldp-08 (work in 1343 progress), November 2005. 1345 [I-D.ietf-l3vpn-bgpvpn-auto] 1346 Ould-Brahim, H., "Using BGP as an Auto-Discovery Mechanism 1347 for Layer-3 and Layer-2 VPNs", 1348 draft-ietf-l3vpn-bgpvpn-auto-06 (work in progress), 1349 June 2005. 1351 [I-D.ietf-pwe3-iana-allocation] 1352 Martini, L., "IANA Allocations for pseudo Wire Edge to 1353 Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-15 1354 (work in progress), November 2005. 1356 [I-D.ietf-pwe3-ms-pw-arch] 1357 Bocci, M. and S. Bryant, "An Architecture for Multi- 1358 Segment Pseudo Wire Emulation Edge-to-Edge", 1359 draft-ietf-pwe3-ms-pw-arch-00 (work in progress), 1360 January 2006. 1362 [I-D.metz-aii-aggregate] 1363 Metz, C., "AII Types for Aggregation", 1364 draft-metz-aii-aggregate-01 (work in progress), 1365 October 2005. 1367 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 1368 Edge (PWE3) Architecture", RFC 3985, March 2005. 1370 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 1371 Private Network (VPN) Terminology", RFC 4026, March 2005. 1373 Authors' Addresses 1375 Eric Rosen 1376 Cisco Systems, Inc. 1377 1414 Mass. Ave. 1378 Boxborough, MA 01719 1379 USA 1381 Email: erosen@cisco.com 1383 Wei Luo 1384 Cisco Systems, Inc. 1385 170 W Tasman Dr. 1386 San Jose, CA 95134 1387 USA 1389 Email: luo@cisco.com 1391 Bruce Davie 1392 Cisco Systems, Inc. 1393 1414 Mass. Ave. 1394 Boxborough, MA 01719 1395 USA 1397 Email: bsd@cisco.com 1399 Vasile Radoaca 1401 Email: radoaca@hotmail.com 1403 Intellectual Property Statement 1405 The IETF takes no position regarding the validity or scope of any 1406 Intellectual Property Rights or other rights that might be claimed to 1407 pertain to the implementation or use of the technology described in 1408 this document or the extent to which any license under such rights 1409 might or might not be available; nor does it represent that it has 1410 made any independent effort to identify any such rights. Information 1411 on the procedures with respect to rights in RFC documents can be 1412 found in BCP 78 and BCP 79. 1414 Copies of IPR disclosures made to the IETF Secretariat and any 1415 assurances of licenses to be made available, or the result of an 1416 attempt made to obtain a general license or permission for the use of 1417 such proprietary rights by implementers or users of this 1418 specification can be obtained from the IETF on-line IPR repository at 1419 http://www.ietf.org/ipr. 1421 The IETF invites any interested party to bring to its attention any 1422 copyrights, patents or patent applications, or other proprietary 1423 rights that may cover technology that may be required to implement 1424 this standard. Please address the information to the IETF at 1425 ietf-ipr@ietf.org. 1427 Disclaimer of Validity 1429 This document and the information contained herein are provided on an 1430 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1431 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1432 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1433 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1434 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1435 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1437 Copyright Statement 1439 Copyright (C) The Internet Society (2006). This document is subject 1440 to the rights, licenses and restrictions contained in BCP 78, and 1441 except as set forth therein, the authors retain all their rights. 1443 Acknowledgment 1445 Funding for the RFC Editor function is currently provided by the 1446 Internet Society.