idnits 2.17.1 draft-ietf-l2vpn-signaling-08.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 1499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1489. ** 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 (May 3, 2006) is 6567 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: 'RFC2685' is defined on line 1363, but no explicit reference was found in the text == Unused Reference: 'RFC2858' is defined on line 1366, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-02 ** 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-07 == 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: November 4, 2006 B. Davie 5 Cisco Systems, Inc. 6 V. Radoaca 7 May 3, 2006 9 Provisioning, Autodiscovery, and Signaling in L2VPNs 10 draft-ietf-l2vpn-signaling-08.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 November 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 . . . . . . . . . . . . . . . . . . . . . . . 17 82 3.3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . 17 83 3.3.2. Auto-Discovery . . . . . . . . . . . . . . . . . . . . 18 84 3.3.2.1. BGP-based auto-discovery . . . . . . . . . . . . . 18 85 3.3.3. Signaling . . . . . . . . . . . . . . . . . . . . . . 19 86 3.4. Colored Pools: Partial Mesh . . . . . . . . . . . . . . . 20 87 3.5. Distributed VPLS . . . . . . . . . . . . . . . . . . . . . 21 88 3.5.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 23 89 3.5.2. Provisioning and Discovery . . . . . . . . . . . . . . 25 90 3.5.3. Non-distributed VPLS as a sub-case . . . . . . . . . . 25 91 3.5.4. Splicing and the Data Plane . . . . . . . . . . . . . 25 93 4. Inter-AS Operation . . . . . . . . . . . . . . . . . . . . . . 27 94 4.1. Multihop EBGP redistribution of L2VPN NLRIs . . . . . . . 27 95 4.2. EBGP redistribution of L2VPN NLRIs with Multi-Segment 96 Pseudowires . . . . . . . . . . . . . . . . . . . . . . . 28 97 4.3. Inter-Provider Application of Distributed VPLS 98 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 29 99 4.4. RT and RD Assignment Considerations . . . . . . . . . . . 30 101 5. Security Considerations . . . . . . . . . . . . . . . . . . . 32 103 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 105 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 106 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 107 8.1. Normative References . . . . . . . . . . . . . . . . . . . 35 108 8.2. Informative References . . . . . . . . . . . . . . . . . . 36 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 111 Intellectual Property and Copyright Statements . . . . . . . . . . 39 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 in [I-D.ietf- 488 l2vpn-vpls-ldp] is referred to as the VPLS identifier (or VPLS-id). 489 Every VSI must be configured with the VPLS-id of the VPLS to which it 490 belongs. 492 Each VSI must also have a unique identifier, which we call a VSI-ID. 493 This can be formed automatically by concatenating its VPLS-id with an 494 IP address of its PE router. (Note that the PE address here is used 495 only as a form of unique identifier; a service provider could choose 496 to use some other numbering scheme if that was desired, as long as 497 each VSI is assigned an identifier that is unique within the VPLS 498 instance. See Section 4.4 for a discussion of the assignment of 499 identifiers in the case of multiple providers.) 501 3.2.2. Auto-Discovery 503 3.2.2.1. BGP-based auto-discovery 505 In this section we specify how BGP can be used to discover the 506 information necessary to build 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 Each VSI needs to have a unique identifier that is encodable as a BGP 527 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, but it must be unique within the VPLS instance. An 532 alternate scheme to assign unique identifiers to each VSI within a 533 VPLS instance (e.g. numbering the VSIs of a single VPN from 1 to n) 534 could be used if desired. 536 When using the procedures described in this document, it is necessary 537 to assign a single, globally unique VPLS-id to each VPLS instance[I- 538 D.ietf-l2vpn-vpls-ldp]. This VPLS-id must be encodable as a BGP 539 Extended Community[RFC4360]. As described in Section 6, two Extended 540 Community subtypes are defined by this draft for this purpose. The 541 Extended Community MUST be transitive. 543 The first Extended Community subtype is a two-octet AS specific 544 Extended Community. The second Extended Community subtype is an IPv4 545 address specific Extended Community. The encoding of such 546 Communities is defined in [RFC4360]. These encodings ensure that a 547 service provider can allocate a VPLS-id without risk of collision 548 with another provider. However, note that co-ordination of VPLS-ids 549 among providers is necessary for inter-provider L2VPNs, as described 550 in Section 4.4. 552 Each VSI also needs to be associated with one or more Route Target 553 (RT) Extended Communities. These control the distribution of the 554 NLRI, and hence will control the formation of the overlay topology of 555 pseudowires that constitutes a particular VPLS. 557 Auto-discovery proceeds by having each PE distribute, via BGP, the 558 NLRI for each of its VSIs, with itself as the BGP next hop, and with 559 the appropriate RT for each such NLRI. Typically, each PE would be a 560 client of a small set of BGP route reflectors, which would 561 redistribute this information to the other clients. 563 If a PE receives a BGP update from which any of the elements 564 specified above is absent, the update should be ignored. 566 If a PE has a VSI with a particular RT, it can then import all the 567 NLRI which have that same RT, and from the BGP next hop attribute of 568 these NLRI it will learn the IP addresses of the other PE routers 569 which have VSIs with the same RT. The considerations of [RFC4364] 570 section 4.3.3 on the use of route reflectors apply. 572 If a particular VPLS is meant to be a single fully connected LAN, all 573 its VSIs will have the same RT, in which case the RT could be (though 574 it need not be) an encoding of the VPN-id. A VSI can be placed in 575 multiple VPLSes by assigning it multiple RTs. 577 Note that hierarchical VPLS can be set up by assigning multiple RTs 578 to some of the VSIs; the RT mechanism allows one to have complete 579 control over the pseudowire overlay which constitutes the VPLS 580 topology. 582 If Distributed VPLS (described in Section 3.5) is deployed, only the 583 N-PEs participate in BGP-based autodiscovery. This means that an 584 N-PE would need to advertise reachability to each of the VSIs that it 585 supports, including those located in U-PEs to which it is connected. 586 To create a unique identifier for each such VSI, an IP address of 587 each U-PE combined with the RD for the VPLS instance could be used. 589 In summary, the BGP advertisement for a particular VSI at a given PE 590 will contain: 592 o an NLRI of AFI = L2VPN, SAFI = TBA, encoded as RD:PE_addr 593 o a BGP next hop equal to the loopback address of the PE 595 o an extended community attribute containing the VPLS-id 597 o an extended community attribute containing one or more RTs. 599 See Section Section 6 for discussion of the AFI and SAFI values. 601 Note that this advertisement is quite similar to the NLRI format 602 defined in [I-D.ietf-l2vpn-vpls-bgp], the main difference being that 603 [I-D.ietf-l2vpn-vpls-bgp] also includes a label block in the NLRI. 604 Interoperability between the VPLS scheme defined here and that 605 defined in [I-D.ietf-l2vpn-vpls-bgp] is beyond the scope of this 606 document. 608 3.2.3. Signaling 610 It is necessary to create Attachment Identifiers which identify the 611 VSIs. In the preceding section, a VSI-ID was encoded as RD:PE_addr, 612 and the VPLS-id was carried in a BGP Extended Community. For 613 signaling purposes, this information is encoded as follows. We 614 encode the VPLS-id in the AGI field, and place the PE_addr (or, more 615 precisely, the VSI-ID that was contained in the NLRI in BGP, minus 616 the RD) in the TAII field. The combination of AGI and TAII is 617 sufficient to fully specify the VSI to which this pseudowire is to be 618 connected, in both single AS and inter-AS environments. The SAII 619 MUST be set to the PE_addr of the sending PE (or, more precisely, the 620 VSI-ID, without the RD, of the VSI associated with this VPLS in the 621 sending PE), to enable signaling of the reverse half of the PW if 622 needed. 624 The structure of the AGI and AII fields for the Generalized ID FEC in 625 LDP is defined in [I-D.ietf-pwe3-control-protocol]. The AGI field in 626 this case consists of a Type of 1, a length field of value 8, and the 627 8 bytes of the VPLS-id. The AIIs consist of a Type of 1, a length 628 field of value 4, followed by the 4-byte PE address (or other 4-byte 629 identifier). See Section 6 for discussion of the AGI and AII Type 630 assignment. 632 The encoding of the AGI and AII in L2TP is specified in [I-D.ietf- 633 l2tpext-l2vpn]. 635 Note that it is not possible using this technique to set up more than 636 one PW per pair of VSIs. 638 3.2.4. Pseudowires as VPLS Attachment Circuits 640 It is also possible using this technique to set up a PW which 641 attaches at one endpoint to a VSI, but at the other endpoint only to 642 an Attachment Circuit. There may be more than one PW terminating on 643 a given VSI, which must somehow be distinguished, so each PW must 644 have an SAII which is unique relative to the VSI-ID. 646 3.3. Colored Pools: Full Mesh of Point-to-Point Pseudowires 648 The "Colored Pools" model of operation provides an automated way to 649 deliver Virtual Private Wire Service (VPWS). In this model, each PE 650 may contain several pools of Attachment Circuits, each pool 651 associated with a particular VPN. A PE may contain multiple pools 652 per VPN, as each pool may correspond to a particular CE device. It 653 may be desired to create one pseudowire between each pair of pools 654 that are in the same VPN; the result would be to create a full mesh 655 of CE-CE VCs for each VPN. 657 3.3.1. Provisioning 659 Each pool is configured, and associated with: 661 o a set of Attachment Circuits; 663 o a "color", which can be thought of as a VPN-id of some sort; 665 o a relative pool identifier, which is unique relative to the color. 667 [Note: depending on the technology used for Attachment Circuits, it 668 may or may not be necessary to provision these circuits as well. For 669 example, if the ACs are frame relay circuits, there may be some 670 separate provisioning system to set up such circuits. Alternatively, 671 "provisioning" an AC may be as simple as allocating an unused VLAN ID 672 on an interface, and communicating the choice to the customer. These 673 issues are independent of the procedures described in this document.] 675 The pool identifier, and color, taken together, constitute a globally 676 unique identifier for the pool. Thus if there are n pools of a given 677 color, their pool identifiers can be (though they do not need to be) 678 the numbers 1-n. 680 The semantics are that a pseudowire will be created between every 681 pair of pools that have the same color, where each such pseudowire 682 will be bound to one Attachment Circuit from each of the two pools. 684 If each pool is a set of Attachment Circuits leading to a single CE 685 device, then the layer 2 connectivity among the CEs is controlled by 686 the way the colors are assigned to the pools. To create a full mesh, 687 the "color" would just be a VPN-id. 689 Optionally, a particular Attachment Circuit may be configured with 690 the relative pool identifier of a remote pool. Then that Attachment 691 Circuit would be bound to a particular pseudowire only if that 692 pseudowire's remote endpoint is the pool with that relative pool 693 identifier. With this option, the same pairs of Attachment Circuits 694 will always be bound via pseudowires. 696 3.3.2. Auto-Discovery 698 3.3.2.1. BGP-based auto-discovery 700 In this section we specify how BGP can be used to discover the 701 information necessary to build VPWS instances. 703 When BGP-based autodiscovery is used for VPWS, the AFI/SAFI will be: 705 o An AFI specified by IANA for L2VPN. (This is the same for all 706 L2VPN schemes.) 708 o A SAFI specified by IANA specifically for an L2VPN service whose 709 pseudowires are set up using the procedures described in the 710 current document. 712 See Section 6 for further discussion of AFI/SAFI assignment. 714 In order to use BGP-based auto-discovery, there must be one or more 715 unique identifiers associated with a particular VPWS instance. Each 716 identifier must be encodable as an RD (Route Distinguisher). The 717 globally unique identifier of a pool must be encodable as NLRI; the 718 pool identifier, which we define to be a four-byte quantity, is 719 appended to the RD to create the NLRI. 721 When using the procedures described in this document, it is necessary 722 to assign a single, globally unique identifier to each VPWS instance. 723 This identifier must be encodable as a BGP Extended 724 Community[RFC4360]. As described in Section 6, two Extended 725 Community subtypes are defined by this draft for this purpose. The 726 Extended Community MUST be transitive. 728 The first Extended Community subtype is a Two-octet AS specific 729 Extended Community. The second Extended Community subtype is an IPv4 730 address specific Extended Community. The encoding of such 731 Communities is defined in [RFC4360]. These encodings ensure that a 732 service provider can allocate a VPWS identifier without risk of 733 collision with another provider. However, note that co-ordination of 734 VPWS identifiers among providers is necessary for inter-provider 735 L2VPNs, as described in Section 4.4. 737 Each pool must also be associated with an RT (route target), which 738 may also be an encoding of the color. If the desired topology is a 739 full mesh of pseudowires, all pools may have the same RT. See 740 Section 3.4 for a discussion of other topologies. 742 Auto-discovery proceeds by having each PE distribute, via BGP, the 743 NLRI for each of its pools, with itself as the BGP next hop, and with 744 the RT that encodes the pool's color. If a given PE has a pool with 745 a particular color (RT), it must receive, via BGP, all NLRI with that 746 same color (RT). Typically, each PE would be a client of a small set 747 of BGP route reflectors, which would redistribute this information to 748 the other clients. 750 If a PE receives a BGP update from which any of the elements 751 specified above is absent, the update should be ignored. 753 If a PE has a pool with a particular color, it can then receive all 754 the NLRI which have that same color, and from the BGP next hop 755 attribute of these NLRI will learn the IP addresses of the other PE 756 routers which have pools switches with the same color. It also 757 learns the unique identifier of each such remote pool, as this is 758 encoded in the NLRI. The remote pool's relative identifier can be 759 extracted from the NLRI and used in the signaling, as specified 760 below. 762 In summary, the BGP advertisement for a particular pool of attachment 763 circuits at a given PE will contain: 765 o an NLRI of AFI = L2VPN, SAFI = TBA, encoded as RD:pool_num; 767 o a BGP next hop equal to the loopback address of the PE; 769 o an extended community attribute containing the VPWS identifier; 771 o an extended community attribute containing one or more RTs. 773 See Section Section 6 for discussion of the AFI and SAFI values. 775 3.3.3. Signaling 777 The LDP-based signaling follows the procedures specified in 778 [I-D.ietf-pwe3-control-protocol]. That is, one PE (PE1) sends a 779 Label Mapping Message to another PE (PE2) to establish an LSP in one 780 direction. The address of PE2 is the next-hop address learned via 781 BGP as described above. If the message is processed successfully, 782 and there is not yet an LSP for the pseudowire in the opposite 783 (PE1->PE2) direction, then PE2 sends a Label Mapping Message to PE1. 784 Similarly, the L2TPv3-based signaling follows the procedures of 786 [I-D.ietf-l2tpext-l2vpn]. Additional details on the use of these 787 signaling protocols follow. 789 When a PE sends a Label Mapping message or an ICRQ message to set up 790 a PW between two pools, it encodes the VPWS identifier (as 791 distributed in the Extended Community Attribute by BGP) as the AGI, 792 the local pool's relative identifier as the SAII, and the remote 793 pool's relative identifier as the TAII. 795 The structure of the AGI and AII fields for the Generalized ID FEC in 796 LDP is defined in [I-D.ietf-pwe3-control-protocol]. The AGI field in 797 this case consists of a Type of 1, a length field of value 8, and the 798 8 bytes of the VPWS identifier. The TAII consists of a Type of 1, a 799 length field of value 4, followed by the 4-byte remote pool number. 800 The SAII consists of a Type of 1, a length field of value 4, followed 801 by the 4-byte local pool number. See Section 6 for discussion of the 802 AGI and AII Type assignment. Note that the VPLS and VPWS procedures 803 defined in this document can make use of the same AGI Type (1) and 804 the same AII Type (1). 806 The encoding of the AGI and AII in L2TP is specified in [I-D.ietf- 807 l2tpext-l2vpn]. 809 When PE2 receives a Label Mapping message or an ICRQ message from 810 PE1, and the TAI identifies a pool, and there is already a 811 pseudowire connecting an Attachment Circuit in that pool to an 812 Attachment Circuit at PE1, and the AI at PE1 of that pseudowire is 813 the same as the SAI of the Label Mapping or ICRQ message, then PE2 814 sends a Label Release or CDN message to PE1, with a Status Code 815 meaning "Attachment Circuit already bound to remote Attachment 816 Circuit". This prevents the creation of multiple pseudowires between 817 a given pair of pools. 819 Note that the signaling itself only identifies the remote pool to 820 which the pseudowire is to lead, not the remote Attachment Circuit 821 which is to be bound to the the pseudowire. However, the remote PE 822 may examine the SAII field to determine which Attachment Circuit 823 should be bound to the pseudowire. 825 3.4. Colored Pools: Partial Mesh 827 The procedures for creating a partial mesh of pseudowires among a set 828 of colored pools are substantially the same as those for creating a 829 full mesh, with the following exceptions: 831 o Each pool is optionally configured with a set of "import RTs" and 832 "export RTs"; 834 o During BGP-based auto-discovery, the pool color is still encoded 835 in the RD, but if the pool is configured with a set of "export 836 RTs", these are are encoded in the RTs of the BGP Update messages, 837 INSTEAD of the color; 839 o If a pool has a particular "import RT" value X, it will create a 840 PW to every other pool which has X as one of its "export RTs". 841 The signaling messages and procedures themselves are as in section 842 3.3.3. 844 As a simple example, consider the task of building a hub-and-spoke 845 topology with a single hub. One pool, the "hub" pool, is configured 846 with an export RT of RT_hub and an import RT of RT_spoke. All other 847 pools (the spokes) are configured with an export RT of RT_spoke and 848 an import RT of RT_hub. Thus the Hub pool will connect to the 849 spokes, and vice-versa, but the spoke pools will not connect to each 850 other. More complex examples are presented in section 4.2.2 of 851 [I-D.ietf-l3vpn-bgpvpn-auto]. 853 3.5. Distributed VPLS 855 In Distributed VPLS ([I-D.ietf-l2vpn-l2-framework]), the VPLS 856 functionality of a PE router is divided among two systems: a U-PE and 857 an N-PE. The U-PE sits between the user and the N-PE. VSI 858 functionality (e.g., MAC address learning and bridging) is performed 859 on the U-PE. A number of U-PEs attach to an N-PE. For each VPLS 860 supported by a U-PE, the U-PE maintains a pseudowire to each other 861 U-PE in the same VPLS. However, the U-PEs do not maintain signaling 862 control connections with each other. Rather, each U-PE has only a 863 single signaling connection, to its N-PE. In essence, each U-PE-to- 864 U-PE pseudowire is composed of three pseudowires spliced together: 865 one from U-PE to N-PE, one from N-PE to N-PE, and one from N-PE to 866 U-PE. In the terminology of [I-D.ietf-pwe3-ms-pw-arch], the N-PEs 867 perform the pseudowire switching function to establish multi-segment 868 PWs from U-PE to U-PE. 870 Consider for example the following topology: 872 U-PE A-----| |----U-PE C 873 | | 874 | | 875 N-PE E--------N-PE F 876 | | 877 | | 878 U-PE B-----| |-----U-PE D 880 where the four U-PEs are in a common VPLS. We now illustrate how PWs 881 get spliced together in the above topology in order to establish the 882 necessary PWs from U-PE A to the other U-PEs. 884 There are three PWs from A to E. Call these A-E/1, A-E/2, and A-E/3. 885 In order to connect A properly to the other U-PEs, there must be two 886 PWs from E to F (call these E-F/1 and E-F/2), one PW from E to B 887 (E-B/1), one from F to C (F-C/1), and one from F to D (F-D/1). 889 The N-PEs must then splice these pseudowires together to get the 890 equivalent of what the non-distributed VPLS signaling mechanism would 891 provide: 893 o PW from A to B: A-E/1 gets spliced to E-B/1. 895 o PW from A to C: A-E/2 gets spliced to E-F/1 gets spliced to F-C/1. 897 o PW from A to D: A-E/3 gets spliced to E-F/2 gets spliced to F-D/1. 899 It doesn't matter which PWs get spliced together, as long as the 900 result is one from A to each of B, C, and D. 902 Similarly, there are additional PWs which must get spliced together 903 to properly interconnect U-PE B with U-PEs C and D, and to 904 interconnect U-PE C with U-PE D. 906 The following figure illustrates the PWs from A to C and from B to D. 907 For clarity of the figure, the other four PWs are not shown. 909 splicing points 910 | | 911 V V 912 A-C PW <-----><-----------><------> 914 U-PE A-----| |----U-PE C 915 | | 916 | | 917 N-PE E--------N-PE F 918 | | 919 | | 920 U-PE B-----| |-----U-PE D 922 B-D PW <-----><-----------><------> 923 ^ ^ 924 | | 925 splicing points 927 One can see that distributed VPLS does not reduce the number of 928 pseudowires per U-PE, but it does reduce the number of control 929 connections per U-PE. Whether this is worthwhile depends, of course, 930 on what the bottleneck is. 932 3.5.1. Signaling 934 The signaling to support Distributed VPLS can be done with the 935 mechanisms described in this document. However, the procedures for 936 VPLS (section 3.2.3) need some additional machinery to ensure that 937 the appropriate number of PWs are established between the various 938 N-PEs and U-PEs, and among the N-PEs. 940 At a given N-PE, the directly attached U-PEs in a given VPLS can be 941 numbered from 1 to n. This number identifies the U-PE relative to a 942 particular VPN-id and a particular N-PE. (That is, to uniquely 943 identify the U-PE, the N-PE, the VPN-id, and the U-PE number must be 944 known.) 946 As a result of configuration/discovery, each U-PE must be given a 947 list of pairs. Each element in this list tells the 948 U-PE to set up j PWs to the specified IP address. When the U-PE 949 signals to the N-PE, it sets the AGI to the proper-VPN-id, and sets 950 the SAII to the PW number, and sets the TAII to null. 952 In the above example, U-PE A would be told <3, E>, telling it to set 953 up 3 PWs to E. When signaling, A would set the AGI to the proper 954 VPN-id, and would set the SAII to 1, 2, or 3, depending on which of 955 the three PWs it is signaling. 957 As a result of configuration/discovery, each N-PE must be given the 958 following information for each VPLS: 960 o A "Local" list: {}, where each element tells it to 961 set up j PWs to the locally attached U-PE at the specified 962 address. The number of elements in this list will be n, the 963 number of locally attached U-PEs in this VPLS. In the above 964 example, E would be given the local list: {<3, A>, <3, B>}, 965 telling it to set up 3 PWs to A and 3 to B. 967 o A local numbering, relative to the particular VPLS and the 968 particular N-PE, of its U-PEs. In the above example, E could be 969 told that U-PE A is 1, and U-PE B is 2. 971 o A "Remote" list: {}, telling it to set up k PWs, 972 for each U-PE, to the specified IP address. Each of these IP 973 addresses identifies a N-PE, and k specifies the number of U-PEs 974 at that N-PE which are in the VPLS. In the above example, E would 975 be given the remote list: {<2, F>}. Since N-PE E has two U-PEs, 976 this tells it to set up 4 PWs to N-PE F, 2 for each of its E's 977 U-PEs. 979 The signaling of a PW from N-PE to U-PE is based on the local list 980 and the local numbering of U-PEs. When signaling a particular PW 981 from an N-PE to a U-PE, the AGI is set to the proper VPN-id, and SAII 982 is set to null, and the TAII is set to the PW number (relative to 983 that particular VPLS and U-PE). In the above example, when E signals 984 to A, it would set the TAII to be 1, 2, or 3, respectively, for the 985 three PWs it must set up to A. It would similarly signal three PWs to 986 B. 988 The LSP signaled from U-PE to N-PE is associated with an LSP from 989 N-PE to U-PE in the usual manner. A PW between a U-PE and an N-PE is 990 known as a "U-PW". 992 The signaling of the appropriate set of PWs from N-PE to N-PE is 993 based on the remote list. The PWs between the N-PEs can all be 994 considered equivalent. As long as the correct total number of PWs 995 are established, the N-PEs can splice these PWs to appropriate U-PWs. 996 The signaling of the correct number of PWs from N-PE to N-PE is based 997 on the remote list. The remote list specifies the number of PWs to 998 set up, per local U-PE, to a particular remote N-PE. 1000 When signaling a particular PW from an N-PE to an N-PE, the AGI is 1001 set to the appropriate VPN-id. The TAII identifies the remote N-PE, 1002 as in the non-distributed case, i.e. it contains an IP address of the 1003 remote N-PE. If there are n such PWs, they are distinguished by the 1004 setting of the SAII. In order to allow multiple different SAII 1005 values in a single VPLS, the sending N-PE needs to have as many VSI- 1006 IDs as it has U-PEs. As noted above in Section 3.2.2, this may be 1007 achieved by using an IP address of each attached U-PE, for example. 1008 A PW between two N-PEs is known as an "N-PW". 1010 Each U-PW must be "spliced" to an N-PW. This is based on the remote 1011 list. If the remote list contains an element , then i U-PWs 1012 from each local U-PE must be spliced to i N-PWs from the remote N-PE 1013 F. It does not matter which U-PWs are spliced to which N-PWs, as long 1014 as this constraint is met. 1016 If an N-PE has more than one local U-PE for a given VPLS, it must 1017 also ensure that a U-PW from each such U-PE is spliced to a U-PW from 1018 each of the other U-PEs. 1020 3.5.2. Provisioning and Discovery 1022 Every N-PE must be provisioned with the set of VPLS instances it 1023 supports, a VPN-id for each one, and a list of local U-PEs for each 1024 such VPLS. As part of the discovery procedure, the N-PE advertises 1025 the number of U-PEs for each VPLS. See Section 3.2.2 for details. 1027 Auto-discovery (e.g., BGP-based) can be used to discover all the 1028 other N-PEs in the VPLS, and for each, the number of U-PEs local to 1029 that N-PE. From this, one can compute the total number of U-PEs in 1030 the VPLS. This information is sufficient to enable one to compute 1031 the local list and the remote list for each N-PE. 1033 3.5.3. Non-distributed VPLS as a sub-case 1035 A PE which is providing "non-distributed VPLS" (i.e., a PE which 1036 performs both the U-PE and N-PE functions) can interoperate with 1037 N-PE/U-PE pairs that are providing distributed VPLS. The "non- 1038 distributed PE" simply advertises, in the discovery procedure, that 1039 it has one local U-PE per VPLS. And of course, the non-distributed 1040 PE does no PW switching. 1042 If every PE in a VPLS is providing non-distributed VPLS, and thus 1043 every PE advertises itself as an N-PE with one local U-PE, the 1044 resultant signaling is exactly the same as that specified in 1045 Section 3.2.3 above. 1047 3.5.4. Splicing and the Data Plane 1049 Splicing two PWs together is quite straightforward in the MPLS data 1050 plane, as moving a packet from one PW directly to another is just a 1051 label replace operation on the PW label. When a PW consists of two 1052 or more PWs spliced together, it is assumed that the data will go to 1053 the node where the splicing is being done, i.e., that the data path 1054 will pass through the nodes that participate in PW signaling. 1056 Further details on splicing are discussed in [I-D.ietf-pwe3- 1057 segmented-pw]. 1059 4. Inter-AS Operation 1061 The provisioning, autodiscovery and signaling mechanisms described 1062 above can all be applied in an inter-AS environment. As in [RFC4364] 1063 there are a number of options for inter-AS operation. 1065 4.1. Multihop EBGP redistribution of L2VPN NLRIs 1067 This option is most like option (c) in [RFC4364]. That is, we use 1068 multihop EBGP redistribution of L2VPN NLRIs between source and 1069 destination ASes, with EBGP redistribution of labeled IPv4 or IPv6 1070 routes from AS to neighboring AS. 1072 An ASBR must maintain labeled IPv4 /32 (or IPv6 /128) routes to the 1073 PE routers within its AS. It uses EBGP to distribute these routes to 1074 other ASes, and sets itself as the BGP next hop for these routes. 1075 ASBRs in any transit ASes will also have to use EBGP to pass along 1076 the labeled /32 (or /128) routes. This results in the creation of a 1077 set of label switched paths from all ingress PE routers to all egress 1078 PE routers. Now PE routers in different ASes can establish multi-hop 1079 EBGP connections to each other, and can exchange L2VPN NLRIs over 1080 those connections. Following such exchanges a pair of PEs in 1081 different ASes could establish an LDP session to signal PWs between 1082 each other. 1084 For VPLS, the BGP advertisement and PW signaling are exactly as 1085 described in Section 3.2. As a result of the multihop EBGP session 1086 that exists between source and destination AS, the PEs in one AS that 1087 have VSIs of a certain VPLS will discover the PEs in another AS that 1088 have VSIs of the same VPLS. These PEs will then be able to establish 1089 the appropriate PW signaling protocol session and establish the full 1090 mesh of VSI-VSI pseudowires to build the VPLS as described in Section 1091 3.2.3. 1093 For VPWS, the BGP advertisement and PW signaling are exactly as 1094 described in Section 3.3. As a result of the multihop EBGP session 1095 that exists between source and destination AS, the PEs in one AS that 1096 have pools of a certain color (VPN) will discover PEs in another AS 1097 that have pools of the same color. These PEs will then be able to 1098 establish the appropriate PW signaling protocol session and establish 1099 the full mesh of pseudowires as described in Section 3.2.3. A 1100 partial mesh can similarly be established using the procedures of 1101 Section 3.4. 1103 As in layer 3 VPNs, building an L2VPN that spans the networks of more 1104 than one provider requires some co-ordination in the use of RTs and 1105 RDs. This subject is discussed in more detail in Section 4.4. 1107 4.2. EBGP redistribution of L2VPN NLRIs with Multi-Segment Pseudowires 1109 A possible drawback of the approach of the previous section is that 1110 it creates PW signaling sessions among all the PEs of a given L2VPN 1111 (VPLS or VPWS). This means a potentially large number of LDP or 1112 L2TPv3 sessions will cross the AS boundary and that these session 1113 connect to many devices within an AS. In the case were the ASes 1114 belong to different providers, one might imagine that providers would 1115 like to have fewer signaling sessions crossing the AS boundary and 1116 that the entities that terminate the sessions could be restricted to 1117 a smaller set of devices. Furthermore, by forcing the LDP or L2TPv3 1118 signaling sessions to terminate on a small set of ASBRs, a provider 1119 could use standard authentication procedures on a small set of inter- 1120 provider sessions. These concerns motivate the approach described 1121 here. 1123 [I-D.ietf-pwe3-segmented-pw] describes an approach to "switching" 1124 packets from one pseudowire to another at a particular node. This 1125 approach allows an end-to-end, multi-segment pseudowire to be 1126 constructed out of several pseudowire segments, without maintaining 1127 an end-to-end control connection. We can use this approach to 1128 produce an inter-AS solution that more closely resembles option (b) 1129 in [RFC4364]. 1131 In this model, we use EBGP redistribution of L2VPN NLRI from AS to 1132 neighboring AS. First, the PE routers use IBGP to redistribute L2VPN 1133 NLRI either to an Autonomous System Border Router (ASBR), or to a 1134 route reflector of which an ASBR is a client. The ASBR then uses 1135 EBGP to redistribute those L2VPN NLRI to an ASBR in another AS, which 1136 in turn distributes them to the PE routers in that AS, or perhaps to 1137 another ASBR which in turn distributes them, and so on. 1139 In this case, a PE can learn the address of an ASBR through which it 1140 could reach another PE to which it wishes to establish a PW. That 1141 is, a local PE will receive a BGP advertisement containing L2VPN NLRI 1142 corresponding to an L2VPN instance in which the local PE has some 1143 attached members. The BGP next-hop for that L2VPN NLRI will be an 1144 ASBR of the local AS. Then, rather than building a control 1145 connection all the way to the remote PE, it builds one only to the 1146 ASBR. A pseudowire segment can now be established from the PE to the 1147 ASBR. The ASBR in turn can establish a PW to the ASBR of the next 1148 AS, and splice that PW to the PW from the PE as described in 1149 Section 3.5.4 and [I-D.ietf-pwe3-segmented-pw]. Repeating the 1150 process at each ASBR leads to a sequence of PW segments that, when 1151 spliced together, connect the two PEs. 1153 Note that in the approach just described, the local PE may never 1154 learn the IP address of the remote PE. It learns the L2VPN NLRI 1155 advertised by the remote PE, which need not contain the remote PE 1156 address, and it learns the IP address of the ASBR that is the BGP 1157 next hop for that NLRI. 1159 When this approach is used for VPLS, or for full-mesh VPWS, it leads 1160 to a full mesh of pseudowires among the PEs, just as in the previous 1161 section, but it does not require a full mesh of control connections 1162 (LDP or L2TPv3 sessions). Instead the control connections within a 1163 single AS run among all the PEs of that AS and the ASBRs of the AS. 1164 A single control connection between the ASBRs of adjacent ASes can be 1165 used to support however many AS-to-AS pseudowire segments are needed. 1167 Note that the procedures described here will result in the splicing 1168 points (S-PEs in the terminology of [I-D.ietf-pwe3-ms-pw-arch]) being 1169 co-located with the ASBRs. It is of course possible to have multiple 1170 ASBR-ASBR connections between a given pair of ASes. In this case a 1171 given PE could choose among the available ASBRs based on a range of 1172 criteria, such as IGP metric, local configuration, etc., analogous to 1173 choosing an exit point in normal IP routing. The use of multiple 1174 ASBRs would lead to greater resiliency (at the timescale of BGP 1175 routing convergence) since a PE could select a new ASBR in the event 1176 of the failure of the one currently in use. 1178 As in layer 3 VPNs, building an L2VPN that spans the networks of more 1179 than one provider requires some co-ordination in the use of RTs and 1180 RDs. This subject is discussed in more detail in Section 4.4. 1182 4.3. Inter-Provider Application of Distributed VPLS Signaling 1184 An alternative approach to inter-provider VPLS can be derived from 1185 the Distributed VPLS approach described above. Consider the 1186 following topology: 1188 PE A --- Network 1 ----- Border ----- Border ----- Network 2 --- PE B 1189 Router 12 Router 21 | 1190 | 1191 PE C 1193 where A, B, and C are PEs in a common VPLS, but Networks 1 and 2 are 1194 networks of different Service Providers. Border Router 12 is Network 1195 1's border router to network 2, and Border Router 21 is Network 2's 1196 border router to Network 1. We suppose further that the PEs are not 1197 "distributed", i.e, that each provides both the U-PE and N-PE 1198 functions. 1200 In this topology, one needs two inter-provider pseudowires: A-B and 1201 A-C. 1203 Suppose a Service Provider decides, for whatever reason, that it does 1204 not want each of its PEs to have a control connection to any PEs in 1205 the other network. Rather, it wants the inter-provider control 1206 connections to run only between the two border routers. 1208 This can be achieved using the techniques of section 3.5, where the 1209 PEs behave like U-PEs, and the BRs behave like N-PEs. In the example 1210 topology, PE A would behave like a U-PE which is locally attached to 1211 BR12; PEs B and C would be have like U-PEs which are locally attached 1212 to BR21; and the two BRs would behave like N-PEs. 1214 As a result, the PW from A to B would consist of three segments: 1215 A-BR12, BR12-BR21, and BR21-B. The border routers would have to 1216 splice the corresponding segments together. 1218 This requires the PEs within a VPLS to be numbered from 1-n (relative 1219 to that VPLS) within a given network. 1221 4.4. RT and RD Assignment Considerations 1223 We note that, in order for any of the inter-AS procedures described 1224 above to work correctly, the two ASes must use RTs and RDs 1225 consistently, just as in layer 3 VPNs [RFC4364]. The structure of 1226 RTs and RDs is such that there is not a great risk of accidental 1227 collisions. The main challenge is that it is necessary for the 1228 operator of one AS to know what RT or RTs have been chosen in another 1229 AS for any VPN that has sites in both ASes. As in layer 3 VPNs, 1230 there are many ways to make this work, but all require some co- 1231 operation among the providers. For example, provider A may tag all 1232 the NLRI for a given VPN with a single RT, say RT_A, and provider B 1233 can then configure the PEs that connect to sites of that VPN to 1234 import NLRI that contains that RT. Provider B can choose a different 1235 RT, RT_B, tag all NLRI for this VPN with that RT, and then provider A 1236 can import NLRI with that RT at the appropriate PEs. However this 1237 does require both providers to communicate their choice of RTs for 1238 each VPN. Alternatively both providers could agree to use a common 1239 RT for a given VPN. In any case communication of RTs between the 1240 providers is essential. As in layer 3 VPNs, providers may configure 1241 RT filtering to ensure that only coordinated RT values are allowed 1242 across the AS boundary. 1244 Note that a single VPN identifier (carried in a BGP Extended 1245 Community) is required for each VPLS or VPWS instance. The encoding 1246 rules for these identifiers [RFC4360] ensure that collisions do not 1247 occur with other providers. However, for a single VPLS or VPWS 1248 instance that spans the networks of two or more providers, one 1249 provider will need to allocate the identifier and communicate this 1250 choice to the other provider(s), who must use the same value for 1251 sites in the same VPLS or VPWS instance. 1253 5. Security Considerations 1255 This document describes a number of different L2VPN provisioning 1256 models, and specifies the endpoint identifiers that are required to 1257 support each of the provisioning models. It also specifies how those 1258 endpoint identifiers are mapped into fields of auto-discovery 1259 protocols and signaling protocols. 1261 The security considerations related to the signaling protocols are 1262 discussed in the relevant protocol specifications ([RFC3036] 1263 [I-D.ietf-pwe3-control-protocol] [RFC3931] [I-D.ietf-l2tpext-l2vpn]). 1265 The security considerations related to BGP-based autodiscovery, 1266 including inter-AS issues, are discussed in [RFC4364]. L2VPNs that 1267 use BGP-based autodiscovery may automate setup of security mechanisms 1268 as well. Specification of automated security mechansims are outside 1269 the scope of this document, but are recommended as a future work 1270 item. 1272 The security considerations related to the particular kind of L2VPN 1273 service being supported are discussed in [I-D.ietf-l2vpn-l2- 1274 framework], [I-D.ietf-l2vpn-requirements], and [I-D.ietf-l2vpn-vpls- 1275 ldp]. 1277 The way in which endpoint identifiers are mapped into protocol fields 1278 does not create any additional security issues. 1280 6. IANA Considerations 1282 This document assumes the assignment of an AFI and a SAFI for L2VPN 1283 NLRI. Both AFI and SAFI should be the same as the values assigned 1284 for [I-D.ietf-l2vpn-vpls-bgp]. That is, the AFI should be 25 (L2VPN) 1285 and the SAFI should be 65 (already allocated for VPLS). The same AFI 1286 and SAFI are used for both VPLS and VPWS autodiscovery as described 1287 in this document. 1289 [I-D.ietf-pwe3-iana-allocation] defines registries for "Attachment 1290 Group Identifier (AGI) Type" and "Attachment Individual Identifier 1291 (AII) Type". Type 1 in each registry has been assigned to the AGI 1292 and AII formats defined in this document. 1294 This document requires two new LDP status codes. IANA already 1295 maintains a registry of name "STATUS CODE NAME SPACE" defined by 1296 [RFC3036]. The following values are suggested for assignment: 1298 0x0000002C "Attachment Circuit bound to different PE" 1300 0x0000002D "Attachment Circuit bound to different remote Attachment 1301 Circuit". 1303 The document requires two new L2TP Result Codes for the CDN message. 1304 IANA already maintains a registry of L2TP Result Code Values for the 1305 CDN message, defined by [RFC3438]. The following values are 1306 requested for assignment: 1308 RC-TBD1: Attachment Circuit bound to different PE 1310 RC-TBD2: Attachment Circuit bound to different remote Attachment 1311 Circuit 1313 [RFC4360] defines a registry entitled "Two-octet AS Specific Extended 1314 Community". This document requests the assigment of a value in this 1315 registry from the "transitive" range (0x0000-0x00FF). The proposed 1316 value is as follows: 1318 o 0x000A Two-octet AS specific Layer 2 VPN Identifier 1320 [RFC4360] defines a registry entitled "IPv4 Address Specific Extended 1321 Community". This document requests the assigment of a value in this 1322 registry from the "transitive" range (0x0100-0x01FF). The proposed 1323 value is as follows: 1325 o 0x010A IPv4 address specific Layer 2 VPN Identifier 1327 7. Acknowledgments 1329 Thanks to Dan Tappan, Ted Qian, Ali Sajassi, Skip Booth, Luca 1330 Martini, Dave McDysan, Francois LeFaucheur, Russ Gardo, Keyur Patel, 1331 Sam Henderson, and Matthew Bocci for their comments, criticisms, and 1332 helpful suggestions. 1334 Thanks to Tissa Senevirathne, Hamid Ould-Brahim and Yakov Rekhter for 1335 discussing the auto-discovery issues. 1337 Thanks to Vach Kompella for a continuing discussion of the proper 1338 semantics of the generalized identifiers. 1340 8. References 1342 8.1. Normative References 1344 [I-D.ietf-l2tpext-l2vpn] 1345 Luo, W., "L2VPN Extensions for L2TP", 1346 draft-ietf-l2tpext-l2vpn-07 (work in progress), 1347 March 2006. 1349 [I-D.ietf-pwe3-control-protocol] 1350 Martini, L., "Pseudowire Setup and Maintenance using the 1351 Label Distribution Protocol", 1352 draft-ietf-pwe3-control-protocol-17 (work in progress), 1353 June 2005. 1355 [I-D.ietf-pwe3-segmented-pw] 1356 Martini, L., "Segmented Pseudo Wire", 1357 draft-ietf-pwe3-segmented-pw-02 (work in progress), 1358 March 2006. 1360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1361 Requirement Levels", BCP 14, RFC 2119, March 1997. 1363 [RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks 1364 Identifier", RFC 2685, September 1999. 1366 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 1367 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 1369 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 1370 B. Thomas, "LDP Specification", RFC 3036, January 2001. 1372 [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) 1373 Internet Assigned Numbers Authority (IANA) Considerations 1374 Update", BCP 68, RFC 3438, December 2002. 1376 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 1377 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 1379 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1380 Communities Attribute", RFC 4360, February 2006. 1382 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1383 Networks (VPNs)", RFC 4364, February 2006. 1385 8.2. Informative References 1387 [I-D.ietf-l2vpn-l2-framework] 1388 Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 1389 Private Networks (L2VPNs)", 1390 draft-ietf-l2vpn-l2-framework-05 (work in progress), 1391 June 2004. 1393 [I-D.ietf-l2vpn-requirements] 1394 Augustyn, W. and Y. Serbest, "Service Requirements for 1395 Layer 2 Provider Provisioned Virtual Private Networks", 1396 draft-ietf-l2vpn-requirements-06 (work in progress), 1397 January 2006. 1399 [I-D.ietf-l2vpn-vpls-bgp] 1400 Kompella, K. and Y. Rekhter, "Virtual Private LAN 1401 Service", draft-ietf-l2vpn-vpls-bgp-06 (work in progress), 1402 December 2005. 1404 [I-D.ietf-l2vpn-vpls-ldp] 1405 Lasserre, M. and V. Kompella, "Virtual Private LAN 1406 Services over MPLS", draft-ietf-l2vpn-vpls-ldp-08 (work in 1407 progress), November 2005. 1409 [I-D.ietf-l3vpn-bgpvpn-auto] 1410 Ould-Brahim, H., "Using BGP as an Auto-Discovery Mechanism 1411 for VR-based Layer-3 VPNs", 1412 draft-ietf-l3vpn-bgpvpn-auto-07 (work in progress), 1413 April 2006. 1415 [I-D.ietf-pwe3-iana-allocation] 1416 Martini, L., "IANA Allocations for pseudo Wire Edge to 1417 Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-15 1418 (work in progress), November 2005. 1420 [I-D.ietf-pwe3-ms-pw-arch] 1421 Bocci, M. and S. Bryant, "An Architecture for Multi- 1422 Segment Pseudo Wire Emulation Edge-to-Edge", 1423 draft-ietf-pwe3-ms-pw-arch-00 (work in progress), 1424 January 2006. 1426 [I-D.metz-aii-aggregate] 1427 Metz, C., "AII Types for Aggregation", 1428 draft-metz-aii-aggregate-01 (work in progress), 1429 October 2005. 1431 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 1432 Edge (PWE3) Architecture", RFC 3985, March 2005. 1434 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 1435 Private Network (VPN) Terminology", RFC 4026, March 2005. 1437 Authors' Addresses 1439 Eric Rosen 1440 Cisco Systems, Inc. 1441 1414 Mass. Ave. 1442 Boxborough, MA 01719 1443 USA 1445 Email: erosen@cisco.com 1447 Wei Luo 1448 Cisco Systems, Inc. 1449 170 W Tasman Dr. 1450 San Jose, CA 95134 1451 USA 1453 Email: luo@cisco.com 1455 Bruce Davie 1456 Cisco Systems, Inc. 1457 1414 Mass. Ave. 1458 Boxborough, MA 01719 1459 USA 1461 Email: bsd@cisco.com 1463 Vasile Radoaca 1465 Email: radoaca@hotmail.com 1467 Intellectual Property Statement 1469 The IETF takes no position regarding the validity or scope of any 1470 Intellectual Property Rights or other rights that might be claimed to 1471 pertain to the implementation or use of the technology described in 1472 this document or the extent to which any license under such rights 1473 might or might not be available; nor does it represent that it has 1474 made any independent effort to identify any such rights. Information 1475 on the procedures with respect to rights in RFC documents can be 1476 found in BCP 78 and BCP 79. 1478 Copies of IPR disclosures made to the IETF Secretariat and any 1479 assurances of licenses to be made available, or the result of an 1480 attempt made to obtain a general license or permission for the use of 1481 such proprietary rights by implementers or users of this 1482 specification can be obtained from the IETF on-line IPR repository at 1483 http://www.ietf.org/ipr. 1485 The IETF invites any interested party to bring to its attention any 1486 copyrights, patents or patent applications, or other proprietary 1487 rights that may cover technology that may be required to implement 1488 this standard. Please address the information to the IETF at 1489 ietf-ipr@ietf.org. 1491 Disclaimer of Validity 1493 This document and the information contained herein are provided on an 1494 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1495 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1496 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1497 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1498 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1499 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1501 Copyright Statement 1503 Copyright (C) The Internet Society (2006). This document is subject 1504 to the rights, licenses and restrictions contained in BCP 78, and 1505 except as set forth therein, the authors retain all their rights. 1507 Acknowledgment 1509 Funding for the RFC Editor function is currently provided by the 1510 Internet Society.