idnits 2.17.1 draft-ietf-l2vpn-signaling-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1266. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1279. ** 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 214 has weird spacing: '...warders being...' == Line 303 has weird spacing: '...sist of an At...' == Line 310 has weird spacing: '...ntifier may b...' == Line 311 has weird spacing: '...r, some attri...' == Line 331 has weird spacing: '...r which has ...' == (7 more instances...) == 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 (July 18, 2005) is 6856 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DTLS' is mentioned on line 769, but not defined == Missing Reference: 'LPE' is mentioned on line 769, but not defined == Missing Reference: '2547bis' is mentioned on line 1146, but not defined == Missing Reference: 'L2VPN-REQS' is mentioned on line 1142, but not defined == Missing Reference: 'BGP-VPLS' is mentioned on line 1154, but not defined == Unused Reference: 'BRADNER' is defined on line 1171, but no explicit reference was found in the text == Unused Reference: 'MP-BGP' is defined on line 1174, but no explicit reference was found in the text == Unused Reference: 'EXT-COMM' is defined on line 1177, but no explicit reference was found in the text == Unused Reference: 'RFC2685' is defined on line 1217, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2858 (ref. 'MP-BGP') (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) == Outdated reference: A later version (-09) exists of draft-ietf-l3vpn-bgpvpn-auto-05 == Outdated reference: A later version (-07) exists of draft-ietf-l2tpext-l2vpn-05 == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-requirements-04 == Outdated reference: A later version (-09) exists of draft-ietf-l2vpn-vpls-ldp-06 Summary: 6 errors (**), 0 flaws (~~), 22 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: January 19, 2006 B. Davie 5 Cisco Systems, Inc. 6 V. Radoaca 7 Nortel Networks 8 July 18, 2005 10 Provisioning Models and Endpoint Identifiers in L2VPN Signaling 11 draft-ietf-l2vpn-signaling-04.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 19, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 There are a number of different kinds of "Provider Provisioned Layer 45 2 VPNs" (L2VPNs). The different kinds of L2VPN may have different 46 "provisioning models", i.e., different models for what information 47 needs to be configured in what entities. Once configured, the 48 provisioning information is distributed by a "discovery process". 50 When the discovery process is complete, a signaling protocol is 51 automatically invoked. The signaling protocol sets up the mesh of 52 Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. Any 53 PW signaling protocol needs to have a method which allows each PW 54 endpoint to identify the other; thus a PW signaling protocol will 55 have the notion of an endpoint identifier. The semantics of the 56 endpoint identifiers which the signaling protocol uses for a 57 particular type of L2VPN are determined by the provisioning model. 58 This document specifies a number of L2VPN provisioning models, and 59 further specifies the semantic structure of the endpoint identifiers 60 required by each provisioning model. It discusses the way in which 61 the endpoint identifiers are distributed by the discovery process, 62 especially when the discovery process is based upon the Border 63 Gateway Protocol (BGP). It then specifies how the endpoint 64 identifiers are carried in the two signaling protocols that are used 65 to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2 66 Tunneling Protocol (L2TPv3). 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2. Signaling Protocol Framework . . . . . . . . . . . . . . . . . 7 73 2.1 Endpoint Identification . . . . . . . . . . . . . . . . . 7 74 2.2 Creating a Single Bidirectional Pseudowire . . . . . . . . 8 75 2.3 Attachment Identifiers and Forwarders . . . . . . . . . . 9 77 3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 3.1 Individual Point-to-Point VCs . . . . . . . . . . . . . . 11 79 3.1.1 Provisioning Models . . . . . . . . . . . . . . . . . 11 80 3.1.1.1 Double Sided Provisioning . . . . . . . . . . . . 11 81 3.1.1.2 Single Sided Provisioning with Discovery . . . . . 11 82 3.1.2 Signaling . . . . . . . . . . . . . . . . . . . . . . 12 83 3.2 Virtual Private LAN Service . . . . . . . . . . . . . . . 13 84 3.2.1 Provisioning . . . . . . . . . . . . . . . . . . . . . 13 85 3.2.2 Auto-Discovery . . . . . . . . . . . . . . . . . . . . 13 86 3.2.2.1 BGP-based auto-discovery . . . . . . . . . . . . . 14 87 3.2.3 Signaling . . . . . . . . . . . . . . . . . . . . . . 15 88 3.2.4 Pseudowires as VPLS Attachment Circuits . . . . . . . 16 89 3.3 Colored Pools: Full Mesh of Point-to-Point VCs . . . . . . 16 90 3.3.1 Provisioning . . . . . . . . . . . . . . . . . . . . . 16 91 3.3.2 Auto-Discovery . . . . . . . . . . . . . . . . . . . . 17 92 3.3.2.1 BGP-based auto-discovery . . . . . . . . . . . . . 17 93 3.3.3 Signaling . . . . . . . . . . . . . . . . . . . . . . 18 94 3.4 Colored Pools: Partial Mesh . . . . . . . . . . . . . . . 19 95 3.5 Distributed VPLS . . . . . . . . . . . . . . . . . . . . . 19 96 3.5.1 Signaling . . . . . . . . . . . . . . . . . . . . . . 21 97 3.5.2 Provisioning and Discovery . . . . . . . . . . . . . . 23 98 3.5.3 Non-distributed VPLS as a sub-case . . . . . . . . . . 23 99 3.5.4 Splicing and the Data Plane . . . . . . . . . . . . . 23 101 4. Inter-AS Operation . . . . . . . . . . . . . . . . . . . . . . 25 102 4.1 Multihop EBGP redistribution of L2VPN NLRIs . . . . . . . 25 103 4.2 EBGP redistribution of L2VPN NLRIs with Pseudowire 104 Switching . . . . . . . . . . . . . . . . . . . . . . . . 25 105 4.3 Inter-Provider Application of Dist. VPLS Signaling . . . . 27 107 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29 109 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 111 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 113 8. Normative References . . . . . . . . . . . . . . . . . . . . . 32 115 9. Informative References . . . . . . . . . . . . . . . . . . . . 33 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33 118 Intellectual Property and Copyright Statements . . . . . . . . 35 120 1. Introduction 122 [L2VPN-FW] describes a number of different ways in which sets of 123 pseudowires may be combined together into "Provider Provisioned Layer 124 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of different 125 kinds of L2VPN. Different kinds of L2VPN may have different 126 "provisioning models", i.e., different models for what information 127 needs to be configured in what entities. Once configured, the 128 provisioning information is distributed by a "discovery process", and 129 once the information is discovered, the signaling protocol is 130 automatically invoked to set up the required pseudowires. The 131 semantics of the endpoint identifiers which the signaling protocol 132 uses for a particular type of L2VPN are determined by the 133 provisioning model. That is, different kinds of L2VPN, with 134 different provisioning models, require different kinds of endpoint 135 identifiers. This document specifies a number of PPVPN provisioning 136 models, and specifies the semantic structure of the endpoint 137 identifiers required for each provisioning model. 139 Either LDP (as specified in [LDP] and extended in [PWE3-CONTROL]) or 140 L2TP version 3 (as specified in [L2TP-BASE] and extended in [L2TP- 141 L2VPN]) can be used as signaling protocols to set up and maintain 142 pseudowires (PWs) [PWE3-ARCH]. Any protocol which sets up 143 connections must provide a way for each endpoint of the connection to 144 identify the other; each PW signaling protocol thus provides a way to 145 identify the PW endpoints. Since each signaling protocol needs to 146 support all the different kinds of L2VPN and provisioning models, the 147 signaling protocol must have a very general way of representing 148 endpoint identifiers, and it is necessary to specify rules for 149 encoding each particular kind of endpoint identifier into the 150 relevant fields of each signaling protocol. This document specifies 151 how to encode the endpoint identifiers of each provisioning model 152 into the LDP and L2TPv3 signaling protocols. 154 We make free use of terminology from [L2VPN-FW], [L2VPN-TERM], and 155 [PWE3-ARCH], in particular the terms "Attachment Circuit", 156 "pseudowire", "PE", "CE". 158 Section 2 provides an overview of the relevant aspects of [PWE3- 159 CONTROL] and [L2TP-L2VPN]. 161 Section 3 details various provisioning models and relates them to the 162 signaling process and to the discovery process. 164 Section 4 explains how the procedures for discovery and signaling can 165 be applied in a multi-AS environment and outlines several options for 166 the establishment of multi-AS L2VPNs. 168 We do not specify an auto-discovery procedure in this draft, but we 169 do specify the information which needs to be obtained via auto- 170 discovery in order for the signaling procedures to begin. The way in 171 which the signaling mechanisms can be integrated with BGP-based auto- 172 discovery is covered in some detail. 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC 2119 178 2. Signaling Protocol Framework 180 2.1 Endpoint Identification 182 Per [L2VPN-FW], a pseudowire can be thought of as a relationship 183 between a pair of "Forwarders". In simple instances of VPWS, a 184 Forwarder binds a pseudowire to a single Attachment Circuit, such 185 that frames received on the one are sent on the other, and vice 186 versa. In VPLS, a Forwarder binds a set of pseudowires to a set of 187 Attachment Circuits; when a frame is received from any member of that 188 set, a MAC address table is consulted (and various 802.1d procedures 189 executed) to determine the member or members of that set on which the 190 frame is to be transmitted. In more complex scenarios, Forwarders 191 may bind PWs to PWs, thereby "splicing" two PWs together; this is 192 needed, e.g., to support distributed VPLS and some inter-AS 193 scenarios. 195 In simple VPWS, where a Forwarder binds exactly one PW to exactly one 196 Attachment Circuit, a Forwarder can be identified by identifying its 197 Attachment Circuit. In simple VPLS, a Forwarder can be identified by 198 identifying its PE device and its VPN. 200 To set up a PW between a pair of Forwarders, the signaling protocol 201 must allow the Forwarder at one endpoint to identify the Forwarder at 202 the other. In [PWE3-CONTROL], the term "Attachment Identifier", or 203 "AI", is used to refer to a quantity whose purpose is to identify a 204 Forwarder. In [L2TP-L2VPN], the term "Forwarder Identifier" is used 205 for the same purpose. In the context of this document, "Attachment 206 Identifier" and "Forwarder Identifier" are used interchangeably. 208 [PWE3-CONTROL] specifies two FEC elements that can be used when 209 setting up pseudowires, the PWid FEC element, and the Generalized Id 210 FEC element. The PWid FEC element carries only one Forwarder 211 identifier; it can be thus be used only when both forwarders have the 212 same identifier, and when that identifier can be coded as a 32-bit 213 quantity. The Generalized Id FEC element carries two Forwarder 214 identifiers, one for each of the two Forwarders being connected. 215 Each identifier is known as an Attachment Identifier, and a signaling 216 message carries both a "Source Attachment Identifier" (SAI) and a 217 "Target Attachment Identifier" (TAI). 219 The Generalized ID FEC element also provides some additional 220 structuring of the identifiers. It is assumed that the SAI and TAI 221 will sometimes have a common part, called the "Attachment Group 222 Identifier" (AGI), such that the SAI and TAI can each be thought of 223 as the concatenation of the AGI with an "Attachment Individual 224 Identifier" (AII). So the pair of identifiers is encoded into three 225 fields: AGI, Source AII (SAII), and Target AII (TAII). The SAI is 226 the concatenation of the AGI and the SAII, while the TAI is the 227 concatenation of the AGI and the TAII. 229 Similarly, [L2TP-L2VPN] allows using one or two Forwarder Identifiers 230 to set up pseudowires. If only the target Forwarder Identifier is 231 used in L2TP signaling messages, both the source and target 232 Forwarders are assumed to have the same value. If both the source 233 and target Forwarder Identifiers are carried in L2TP signaling 234 messages, each Forwarder uses a locally significant identifier value. 236 The Forwarder Identifier in [L2TP-L2VPN] is an equivalent term as 237 Attachment Identifier in [PWE3-CONTROL]. A Forwarder Identifier also 238 consists of an Attachment Group Identifier and an Attachment 239 Individual Identifier. Unlike the Generalized ID FEC element, the 240 AGI and AII are carried in distinct L2TP Attribute-Value-Pairs 241 (AVPs). The AGI is encoded in the AGI AVP, and the SAII and TAII are 242 encoded in the Local End ID AVP and the Remote End ID AVP 243 respectively. The source Forwarder Identifier is the concatenation 244 of the AGI and SAII, while the target Forwarder Identifier is the 245 concatenation of the AGI and TAII. 247 In applications that group sets of PWs into "Layer 2 Virtual Private 248 Networks", the AGI can be thought of as a "VPN Identifier". 250 It should be noted that while different forwarders support different 251 applications, the type of application (e.g., VPLS vs. VPWS) cannot 252 necessarily be inferred from the forwarders' identifiers. A router 253 receiving a signaling message with a particular TAI will have to be 254 able to determine which of its local forwarders is identified by that 255 TAI, and to determine the application provided by that forwarder. 256 But other nodes may not be able to infer the application simply by 257 inspection of the signaling messages. 259 In this document some further structure of the AGI and AII is 260 proposed for certain L2VPN applications. We note that an operator 261 who chooses to use the AII structure defined here would not be at 262 liberty to use a completely different structure for these identifiers 263 for some other application. For example, it would be unwise to use 264 ASCII strings for AII values when setting up individual pseudowires 265 and at the same time to use the structure for AII 266 values in VPLS signaling. 268 2.2 Creating a Single Bidirectional Pseudowire 270 In any form of LDP-based signaling, each PW endpoint must initiate 271 the creation of a unidirectional LSP. A PW is a pair of such LSPs. 272 In most of the PPVPN provisioning models, the two endpoints of a 273 given PW can simultaneously initiate the signaling for it. They must 274 therefore have some way of determining when a given pair of LSPs are 275 intended to be associated together as a single PW. 277 The way in which this association is done is different for the 278 various different L2VPN services and provisioning models. The 279 details appear in later sections. 281 L2TP signaling inherently establishes a bidirectional session that 282 carries a PW between two PW endpoints. The two endpoints can also 283 simultaneously initiate the signaling for a given PW. It is possible 284 that two PWs can be established for a pair of Forwarders. 286 In order to avoid setting up duplicated pseudowires between two 287 Forwarders, each PE must be able to independently detect such a 288 pseudowire tie. The procedures of detecting a pseudowire tie is 289 described in [L2TP-L2VPN] 291 2.3 Attachment Identifiers and Forwarders 293 Every Forwarder in a PE must be associated with an Attachment 294 Identifier (AI), either through configuration or through some 295 algorithm. The Attachment Identifier must be unique in the context 296 of the PE router in which the Forwarder resides. The combination must be globally unique. 299 It is frequently convenient to a set of Forwarders as being members 300 of a particular "group", where PWs may only be set up among members 301 of a group. In such cases, it is convenient to identify the 302 Forwarders relative to the group, so that an Attachment Identifier 303 would consist of an Attachment Group Identifier (AGI) plus an 304 Attachment Individual Identifier (AII). 306 IT MUST BE UNDERSTOOD THAT THIS NOTION OF "GROUP" HAS NOTHING 307 WHATSOEVER TO DO WITH THE "GROUP ID" THAT IS PART OF THE PWID FEC IN 308 [PWE3-CONTROL]. 310 An Attachment Group Identifier may be thought of as a VPN-id, or 311 a VLAN identifier, some attribute which is shared by all the 312 Attachment Circuits (or pools thereof) which are allowed to be 313 connected. 315 The details for how to construct the AGI and AII fields identifying 316 the pseudowire endpoints in particular provisioning models are 317 discussed later in this paper. 319 We can now consider an LSP to be identified by: 321 o , PE2, > 323 and the LSP in the opposite direction will be identified by: 325 o , PE1, > 327 A pseudowire is a pair of such LSPs. In the case of using L2TP 328 signaling, these refer to the two directions of an L2TP session. 330 When a signaling message is sent from PE1 to PE2, and PE1 needs to 331 refer to an Attachment Identifier which has been configured on 332 one of its own Attachment Circuits (or pools), the Attachment 333 Identifier is called a "Source Attachment Identifier". If PE1 334 needs to refer to an Attachment Identifier which has been 335 configured on one of PE2's Attachment Circuits (or pools), the 336 Attachment Identifier is called a "Target Attachment Identifier". 337 (So an SAI at one endpoint is a TAI at the remote endpoint, and vice 338 versa.) 340 In the signaling protocol, we define encodings for the following 341 three fields: 343 o Attachment Group Identifier (AGI) 345 o Source Attachment Individual Identifier (SAII) 347 o Target Attachment Individual Identifier (TAII) 349 If the AGI is non-null, then the SAI consists of the AGI together 350 with the SAII, and the TAI consists of the TAII together with the 351 AGI. If the AGI is null, then the SAII and TAII are the SAI and TAI 352 respectively. 354 The intention is that the PE which receives an LDP Label Mapping 355 message or an L2TP Incoming Call Request (ICRQ) message containing a 356 TAI will be able to map that TAI uniquely to one of its Attachment 357 Circuits (or pools). The way in which a PE maps a TAI to an 358 Attachment Circuit (or pool) should be a local matter. So as far as 359 the signaling procedures are concerned, the TAI is really just an 360 arbitrary string of bytes, a "cookie". 362 3. Applications 364 In this section, we specify the way in which the pseudowire signaling 365 using the notion of source and target Forwarder is applied for a 366 number of different applications. For some of the applications, we 367 specify the way in which different provisioning models can be used. 368 However, this is not meant to be an exhaustive list of the 369 applications, or an exhaustive list of the provisioning models that 370 can be applied to each application. 372 3.1 Individual Point-to-Point VCs 374 The signaling specified in this document can be used to set up 375 individually provisioned point-to-point pseudowires. In this 376 application, each Forwarder binds a single PW to a single Attachment 377 Circuit. Each PE must be provisioned with the necessary set of 378 Attachment Circuits, and then certain parameters must be provisioned 379 for each Attachment Circuit. 381 3.1.1 Provisioning Models 383 3.1.1.1 Double Sided Provisioning 385 In this model, the Attachment Circuit must be provisioned with a 386 local name, a remote PE address, and a remote name. During 387 signaling, the local name is sent as the SAII, the remote name as the 388 TAII, and the AGI is null. If two Attachment Circuits are to be 389 connected by a PW, the local name of each must be the remote name of 390 the other. 392 Note that if the local name and the remote name are the same, the 393 PWid FEC element can be used instead of the Generalized ID FEC 394 element in the LDP based signaling. 396 With L2TP signaling, the local name is sent in Local End ID AVP, the 397 remote name in Remote End ID AVP. The AGI AVP is optional. If 398 present, it contains a zero-length AGI value. If the local name and 399 the remote name are the same, Local End ID AVP can be omitted from 400 L2TP signaling messages. 402 3.1.1.2 Single Sided Provisioning with Discovery 404 In this model, each Attachment Circuit must be provisioned with a 405 local name. The local name consists of a VPN-id (signaled as the 406 AGI) and an Attachment Individual Identifier which is unique relative 407 to the AGI. If two Attachment circuits are to be connected by a PW, 408 only one of them needs to be provisioned with a remote name (which of 409 course is the local name of the other Attachment Circuit). Neither 410 needs to be provisioned with the address of the remote PE, but both 411 must have the same VPN-id. 413 As part of an auto-discovery procedure, each PE advertises its 414 pairs. Each PE compares its local pairs with the pairs advertised by 416 the other PEs. If PE1 has a local pair with 417 value , and PE2 has a local pair with 418 value , PE1 will thus be able to discover that it needs to 419 connect to PE2. When signaling, it will use "fred" as the TAII, and 420 will use V as he AGI. PE1's local name for the Attachment Circuit is 421 sent as the SAII. 423 The primary benefit of this provisioning model when compared to 424 Double Sided Provisioning is that it enables one to move an 425 Attachment Circuit from one PE to another without having to 426 reconfigure the remote endpoint. However, compared to the approach 427 described in Section 3.3 below, it imposes a greater burden on the 428 discovery mechanism, because each attachment circuit's name must be 429 advertised individually (i.e. there is no aggregation of AC names in 430 this simple scheme). 432 3.1.2 Signaling 434 The LDP-based signaling follows the procedures specified in [PWE3- 435 CONTROL]. That is, one PE (PE1) sends a Label Mapping Message to 436 another PE (PE2) to establish a pseudowire in one direction. If that 437 message is processed successfully, and there is not yet a pseudowire 438 in the opposite (PE1->PE2) direction, then PE2 sends a Label Mapping 439 Message to PE1. 441 In addition to the procedures of [PWE3-CONTROL], when a PE receives a 442 Label Mapping Message, and the TAI identifies a particular Attachment 443 Circuit which is configured to be bound to a point-to-point PW, then 444 the following checks must be made. 446 If the Attachment Circuit is already bound to a pseudowire (including 447 the case where only one of the two LSPs currently exists), and the 448 remote endpoint is not PE1, then PE2 sends a Label Release message to 449 PE1, with a Status Code meaning "Attachment Circuit bound to 450 different PE", and the processing of the Mapping message is complete. 452 If the Attachment Circuit is already bound to a pseudowire (including 453 the case where only one of the two LSPs currently exists), but the AI 454 at PE1 is different than that specified in the AGI/SAII fields of the 455 Mapping message then PE2 sends a Label Release message to PE1, with a 456 Status Code meaning "Attachment Circuit bound to different remote 457 Attachment Circuit", and the processing of the Mapping message is 458 complete. 460 Similarly with the L2TP-based signaling, when a PE receives an ICRQ 461 message, and the TAI identifies a particular Attachment Circuit which 462 is configured to be bound to a point-to-point PW, it performs the 463 following checks. 465 If the Attachment Circuit is already bound to a pseudowire, and the 466 remote endpoint is not PE1, then PE2 sends a Call Disconnect Notify 467 (CDN) message to PE1, with a Status Code meaning "Attachment Circuit 468 bound to different PE", and the processing of the ICRQ message is 469 complete. 471 If the Attachment Circuit is already bound to a pseudowire, but the 472 pseudowire is bound to a Forwarder on PE1 with the AI different than 473 that specified in the SAI fields of the ICRQ message, then PE2 sends 474 a CDN message to PE1, with a Status Code meaning "Attachment Circuit 475 bound to different remote Attachment Circuit", and the processing of 476 the ICRQ message is complete. 478 These errors could occur as the result of misconfigurations. 480 3.2 Virtual Private LAN Service 482 In the VPLS application [L2VPN-REQ, VPLS], the Attachment Circuits 483 can be though of as LAN interfaces which attach to "virtual LAN 484 switches", or, in the terminology of [L2VPN-FW], "Virtual Switching 485 Instances" (VSIs). Each Forwarder is a VSI that attaches to a number 486 of PWs and a number of Attachment Circuits. The VPLS service [L2VPN- 487 REQ, VPLS] requires that a single pseudowire be created between each 488 pair of VSIs that are in the same VPLS. Each PE device may have a 489 multiple VSIs, where each VSI belongs to a different VPLS. 491 3.2.1 Provisioning 493 Each VPLS must have a globally unique identifier, which we call a 494 VPN-id. Every VSI must be configured with the VPN-id of the VPLS to 495 which it belongs. 497 Each VSI must also have a unique identifier, but this can be formed 498 automatically by concatenating its VPN-id with the IP address of its 499 PE router. (Note that the PE address here is used only as a form of 500 unique identifier; a service provider could choose to use some other 501 numbering scheme if that was desired.) 503 3.2.2 Auto-Discovery 504 3.2.2.1 BGP-based auto-discovery 506 The framework for BGP-based auto-discovery for a VPLS service is as 507 specified in [BGP-AUTO], section 3.2. 509 The AFI/SAFI used would be: 511 o An AFI specified by IANA for L2VPN. (This is the same for all 512 L2VPN schemes.) 514 o An SAFI specified by IANA specifically for an L2VPN (VPLS or VPWS) 515 service whose pseudowires are set up using the procedures 516 described in the current document. 518 In order to use BGP-based auto-discovery as specified in [BGP-AUTO], 519 the globally unique identifier associated with a VPLS must be 520 encodable as an 8-byte Route Distinguisher (RD). If the globally 521 unique identifier for a VPLS is an RFC2685 VPN-id, it can be encoded 522 as an RD as specified in [BGP-AUTO]. However, any other method of 523 assigning a unique identifier to a VPLS and encoding it as an RD 524 (using the encoding techniques of [RFC2547bis]) will do. 526 Each VSI needs to have a unique identifier, which can be encoded as a 527 BGP NLRI. This is formed by prepending the RD (from the previous 528 paragraph) to an IP address of the PE containing the virtual LAN 529 switch. Note that the role of this address is simply as a readily 530 available unique identifier for the VSIs within a VPN; it does not 531 need to be globally routable. An alternate numbering scheme (e.g. 532 numbering the VSIs of a single VPN from 1 to n) could be used if 533 desired. 535 (Note also that it is not strictly necessary for all the VSIs in the 536 same VPLS to have the same RD, all that is really necessary is that 537 the NLRI uniquely identify a virtual LAN switch.) 539 Each VSI needs to be associated with one or more Route Target (RT) 540 Extended Communities, as discussed in [BGP-AUTO}. These control the 541 distribution of the NLRI, and hence will control the formation of the 542 overlay topology of pseudowires that constitutes a particular VPLS. 544 Auto-discovery proceeds by having each PE distribute, via BGP, the 545 NLRI for each of its VSIs, with itself as the BGP next hop, and with 546 the appropriate RT for each such NLRI. Typically, each PE would be a 547 client of a small set of BGP route reflectors, which would 548 redistribute this information to the other clients. 550 If a PE has a VSI with a particular RT, it can then receive all the 551 NLRI which have that same RT, and from the BGP next hop attribute of 552 these NLRI will learn the IP addresses of the other PE routers which 553 have VSIs with the same RT. The considerations of [RFC2547bis] 554 section 4.3.3 on the use of route reflectors apply. 556 If a particular VPLS is meant to be a single fully connected LAN, all 557 its VSIs will have the same RT, in which case the RT could be (though 558 it need not be) an encoding of the VPN-id. If a particular VPLS 559 consists of multiple VLANs, each VLAN must have its own unique RT. A 560 VSI can be placed in multiple VLANS (or even in multiple VPLSes) by 561 assigning it multiple RTs. 563 Note that hierarchical VPLS can be set up by assigning multiple RTs 564 to some of the virtual LAN switches; the RT mechanism allows one to 565 have complete control over the pseudowire overlay which constitutes 566 the VPLS topology. 568 If Distributed VPLS (described in Section 3.5) is deployed, only the 569 N-PEs participate in BGP-based autodiscovery. This means that an 570 N-PE would need to advertise reachability to each of the VSIs that it 571 supports, including those located in U-PEs to which it is connected. 572 To create a unique identifier for each such VSI, an IP address of 573 each U-PE combined with the RD for the VPLS instance could be used. 575 In summary, the BGP advertisement for a particular VSI at a given PE 576 will contain: 578 o an NLRI of AFI = L2VPN, SAFI = TBD, encoded as RD:PE_addr 580 o a BGP next hop equal to the loopback address of the PE 582 o an extended community attribute containing one or more RTs 584 3.2.3 Signaling 586 It is necessary to create Attachment Identifiers which identify the 587 VSIs. In the preceding section, a VSI-ID was encoded as RD:PE_addr 588 for the purposes of autodiscovery. For signaling purposes, the same 589 information is carried but is encoded slightly differently. Noting 590 that the RD is effectively a VPN identifier, we therefore encode the 591 RD in the AGI field, and place the PE_addr in the TAII field. The 592 SAII can be null. 594 The AGI field therefore consists of a length field of value 8, 595 followed by the 8 bytes of the RD. The TAII consists of a length 596 field of value 4 followed by the 4-byte PE address. 598 Note that it is not possible using this technique to set up more than 599 one PW per pair of VSIs. 601 3.2.4 Pseudowires as VPLS Attachment Circuits 603 It is also possible using this technique to set up a PW which 604 attaches at one endpoint to a VSI, but at the other endpoint only to 605 an Attachment Circuit. However, in this case there may be more than 606 one PW between a pair of PEs, so that AIIs cannot be null. Rather, 607 each such PW must have AII which is unique relative to the VPN-id. 608 This value would be carried in both the SAII and the TAII field of 609 the signaling messages. 611 3.3 Colored Pools: Full Mesh of Point-to-Point VCs 613 In the "Colored Pools" model of operation, each PE may contain 614 several pools of Attachment Circuits, each pool associated with a 615 particular VPN. A PE may contain multiple pools per VPN, as each 616 pool may correspond to a particular CE device. It may be desired to 617 create one pseudowire between each pair of pools that are in the same 618 VPN; the result would be to create a full mesh of CE-CE VCs for each 619 VPN. 621 3.3.1 Provisioning 623 Each pool is configured, and associated with: 625 o a set of Attachment Circuits; 627 o a "color", which can be thought of as a VPN-id of some sort; 629 o a relative pool identifier, which is unique relative to the color. 631 [Note: depending on the technology used for Attachment Circuits, it 632 may or may not be necessary to provision these circuits as well. For 633 example, if the ACs are frame relay circuits, there may be some 634 separate provisioning system to set up such circuits. Alternatively, 635 "provisioning" an AC may be as simple as allocating an unused VLAN ID 636 on an interface. This issue is independent of the procedures 637 described in this document.] 639 The pool identifier, and color, taken together, constitute a globally 640 unique identifier for the pool. Thus if there are n pools of a given 641 color, their pool identifiers can be (though they do not need to be) 642 the numbers 1-n. 644 The semantics are that a pseudowire will be created between every 645 pair of pools that have the same color, where each such pseudowire 646 will be bound to one Attachment Circuit from each of the two pools. 648 If each pool is a set of Attachment Circuits leading to a single CE 649 device, then the layer 2 connectivity among the CEs is controlled by 650 the way the colors are assigned to the pools. To create a full mesh, 651 the "color" would just be a VPN-id. 653 Optionally, a particular Attachment Circuit may be configured with 654 the relative pool identifier of a remote pool. Then that Attachment 655 Circuit would be bound to a particular pseudowire only if that 656 pseudowire's remote endpoint is the pool with that relative pool 657 identifier. With this option, the same pairs of Attachment Circuits 658 will always be bound via pseudowires. 660 3.3.2 Auto-Discovery 662 3.3.2.1 BGP-based auto-discovery 664 The framework for BGP-based auto-discovery for a colored pool service 665 is as specified in [BGP-AUTO], section 3.2. 667 The AFI/SAFI used would be: 669 o An AFI specified by IANA for L2VPN. (This is the same for all 670 L2VPN schemes.) 672 o An SAFI specified by IANA specifically for an L2VPN (VPLS or VPWS) 673 service whose pseudowires are set up using the procedures 674 described in the current document. 676 In order to use BGP-based auto-discovery, the color associated with a 677 colored pool must be encodable as both an RT (Route Target) and an RD 678 (Route Distinguisher). The globally unique identifier of a pool must 679 be encodable as NLRI; the color would be encoded as the RD and the 680 pool identifier as a four-byte quantity which is appended to the RD 681 to create the NLRI. 683 Auto-discovery procedures by having each PE distribute, via BGP, the 684 NLRI for each of its pools, with itself as the BGP next hop, and with 685 the RT that encodes the pool's color. If a given PE has a pool with 686 a particular color (RT), it must receive, via BGP, all NLRI with that 687 same color (RT). Typically, each PE would be a client of a small set 688 of BGP route reflectors, which would redistribute this information to 689 the other clients. 691 If a PE has a pool with a particular color, it can then receive all 692 the NLRI which have that same color, and from the BGP next hop 693 attribute of these NLRI will learn the IP addresses of the other PE 694 routers which have pools switches with the same color. It also 695 learns the unique identifier of each such remote pool, as this is 696 encoded in the NLRI. The remote pool's relative identifier can be 697 extracted from the NLRI and used in the signaling, as specified 698 below. 700 In summary, the BGP advertisement for a particular pool of attachment 701 circuits at a given PE will contain: 703 o an NLRI of AFI = L2VPN, SAFI = TBD, encoded as RD:pool_num; 705 o a BGP next hop equal to the loopback address of the PE; 707 o an extended community attribute containing one or more RTs. 709 3.3.3 Signaling 711 The LDP-based signaling follows the procedures specified in [PWE3- 712 CONTROL]. That is, one PE (PE1) sends a Label Mapping Message to 713 another PE (PE2) to establish a pseudowire in one direction. If that 714 message is processed successfully, and there is not yet a pseudowire 715 in the opposite (PE1->PE2) direction, then PE2 sends a Label Mapping 716 Message to PE1. Similarly, the L2TPv3-based signaling follows the 717 procedures of [L2TP-BASE]. Additional details on the use of these 718 signaling protocols follow. 720 When a PE sends a Label Mapping message or an ICRQ message to set up 721 a PW between two pools, it encodes the color as the AGI, the local 722 pool's relative identifier as the SAII, and the remote pool's 723 relative identifier as the TAII. 725 When PE2 receives a Label Mapping message or an ICRQ message from 726 PE1, and the TAI identifies to a pool, and there is already an 727 pseudowire connecting an Attachment Circuit in that pool to an 728 Attachment Circuit at PE1, and the AI at PE1 of that pseudowire is 729 the same as the SAI of the Label Mapping or ICRQ message, then PE2 730 sends a Label Release or CDN message to PE1, with a Status Code 731 meaning "Attachment Circuit already bound to remote Attachment 732 Circuit". This prevents the creation of multiple pseudowires between 733 a given pair of pools. 735 Note that the signaling itself only identifies the remote pool to 736 which the pseudowire is to lead, not the remote Attachment Circuit 737 which is to be bound to the the pseudowire. However, the remote PE 738 may examine the SAII field to determine which Attachment Circuit 739 should be bound to the pseudowire. 741 3.4 Colored Pools: Partial Mesh 743 The procedures for creating a partial mesh of pseudowires among a set 744 of colored pools are substantially the same as those for creating a 745 full mesh, with the following exceptions: 747 o Each pool is optionally configured with a set of "import RTs" and 748 "export RTs"; 750 o During BGP-based auto-discovery, the pool color is still encoded 751 in the RD, but if the pool is configured with a set of "export 752 RTs", these are are encoded in the RTs of the BGP Update messages, 753 INSTEAD of the color; 755 o If a pool has a particular "import RT" value X, it will create a 756 PW to every other pool which has X as one of its "export RTs". 757 The signaling messages and procedures themselves are as in section 758 3.3.3. 760 As a simple example, consider the task of building a hub-and-spoke 761 topology. One pool, the "hub" pool, is configured with an export RT 762 of RT_hub and an import RT of RT_spoke. All other pools (the spokes) 763 are configured with an export RT of RT_spoke and an import RT of 764 RT_hub. Thus the Hub pool will connect to the spokes, and vice- 765 versa, but the spoke pools will not connect to each other. 767 3.5 Distributed VPLS 769 In Distributed VPLS ([L2VPN-FW], [DTLS], [LPE]), the VPLS 770 functionality of a PE router is divided among two systems: a U-PE and 771 an N-PE. The U-PE sits between the user and the N-PE. VSI 772 functionality (e.g., MAC address learning and bridging) is performed 773 on the U-PE. A number of U-PEs attach to an N-PE. For each VPLS 774 supported by a U-PE, the U-PE maintains a pseudowire to each other 775 U-PE in the same VPLS. However, the U-PEs do not maintain signaling 776 control connections with each other. Rather, each U-PE has only a 777 single signaling connection, to its N-PE. In essence, each U-PE-to- 778 U-PE pseudowire is composed of three pseudowires spliced together: 779 one from U-PE to N-PE, one from N-PE to N-PE, and one from N-PE to 780 U-PE. 782 Consider for example the following topology: 784 U-PE A-----| |----U-PE C 785 | | 786 | | 787 N-PE E--------N-PE F 788 | | 789 | | 790 U-PE B-----| |-----U-PE D 792 where the four U-PEs are in a common VPLS. We now illustrate how PWs 793 get spliced together in the above topology in order to establish the 794 necessary PWs from U-PE A to the other U-PEs. 796 There are three PWs from A to E. Call these A-E/1, A-E/2, and A-E/3. 797 In order to connect A properly to the other U-PEs, there must be two 798 PWs from E to F (call these E-F/1 and E-F/2), one PW from E to B 799 (E-B/1), one from F to C (F-C/1), and one from F to D (F-D/1). 801 The N-PEs must then splice these pseudowires together to get the 802 equivalent of what the non-distributed VPLS signaling mechanism would 803 provide: 805 o PW from A to B: A-E/1 gets spliced to E-B/1. 807 o PW from A to C: A-E/2 gets spliced to E-F/1 gets spliced to F-C/1. 809 o PW from A to D: A-E/3 gets spliced to E-F/2 gets spliced to F-D/1. 811 It doesn't matter which PWs get spliced together, as long as the 812 result is one from A to each of B, C, and D. 814 Similarly, there are additional PWs which must get spliced together 815 to properly interconnect U-PE B with U-PEs C and D, and to 816 interconnect U-PE C with U-PE D. 818 The following figure illustrates the PWs from A to C and from B to D. 819 For clarity of the figure, the other four PWs are not shown. 821 splicing points 822 | | 823 V V 824 A-C PW <-----><-----------><------> 826 U-PE A-----| |----U-PE C 827 | | 828 | | 829 N-PE E--------N-PE F 830 | | 831 | | 832 U-PE B-----| |-----U-PE D 834 B-D PW <-----><-----------><------> 835 ^ ^ 836 | | 837 splicing points 839 One can see that distributed VPLS does not reduce the number of 840 pseudowires per U-PE, but it does reduce the number of control 841 connections per U-PE. Whether this is worthwhile depends, of course, 842 on what the bottleneck is. 844 3.5.1 Signaling 846 The signaling to support Distributed VPLS can be done with the 847 mechanisms described in this paper. However, the procedures for VPLS 848 (section 3.2.3) need some additional machinery to ensure that the 849 appropriate number of PWs are established between the various N-PEs 850 and U-PEs, and among the N-PEs. 852 At a given N-PE, the directly attached U-PEs in a given VPLS can be 853 numbered from 1 to n. This number identifies the U-PE relative to a 854 particular VPN-id and a particular N-PE. (That is, to uniquely 855 identify the U-PE, the N-PE, the VPN-id, and the U-PE number must be 856 known.) 858 As a result of configuration/discovery, each U-PE must be given a 859 list of pairs. Each element in this list tells the 860 U-PE to set up j PWs to the specified IP address. When the U-PE 861 signals to the N-PE, it sets the AGI to the proper-VPN-id, and sets 862 the SAII to the PW number, and sets the TAII to null. 864 In the above example, U-PE A would be told <3, E>, telling it to set 865 up 3 PWs to E. When signaling, A would set the AGI to the proper 866 VPN-id, and would set the SAII to 1, 2, or 3, depending on which of 867 the three PWs it is signaling. 869 As a result of configuration/discovery, each N-PE must be given the 870 following information for each VPLS: 872 o A "Local" list: {}, where each element tells it to 873 set up j PWs to the locally attached U-PE at the specified 874 address. The number of elements in this list will be n, the 875 number of locally attached U-PEs in this VPLS. In the above 876 example, E would be given the local list: {<3, A>, <3, B>}, 877 telling it to set up 3 PWs to A and 3 to B. 879 o A local numbering, relative to the particular VPLS and the 880 particular N-PE, of its U-PEs. In the above example, E could be 881 told that U-PE A is 1, and U-PE B is 2. 883 o A "Remote" list: {}, telling it to set up k PWs, 884 for each U-PE, to the specified IP address. Each of these IP 885 addresses identifies a N-PE, and k specifies the number of U-PEs 886 at that N-PE which are in the VPLS. In the above example, E would 887 be given the remote list: {<2, F>}. Since N-PE E has two U-PEs, 888 this tells it to set up 4 PWs to N-PE F, 2 for each of its E's 889 U-PEs. 891 The signaling of a PW from N-PE to U-PE is based on the local list 892 and the local numbering of U-PEs. When signaling a particular PW 893 from an N-PE to a U-PE, the AGI is set to the proper VPN-id, and SAII 894 is set to null, and the TAII is set to the PW number (relative to 895 that particular VPLS and U-PE). In the above example, when E signals 896 to A, it would set the TAII to be 1, 2, or 3, respectively, for the 897 three PWs it must set up to A. It would similarly signal three PWs to 898 B. 900 The LSP signaled from U-PE to N-PE is associated with an LSP from 901 N-PE to U-PE in the usual manner. A PW between a U-PE and an N-PE is 902 known as a "U-PW". 904 The signaling of the appropriate set of PWs from N-PE to N-PE is 905 based on the remote list. The PWs between the N-PEs can all be 906 considered equivalent. As long as the correct total number of PWs 907 are established, the N-PEs can splice these PWs to appropriate U-PWs. 908 The signaling of the correct number of PWs from N-PE to N-PE is based 909 on the remote list. The remote list specifies the number of PWs to 910 set up, per local U-PE, to a particular remote N-PE. 912 When signaling a particular PW from an N-PE to an N-PE, the AGI is 913 set to the appropriate VPN-id. The TAII identifies the remote N-PE, 914 as in the non-distributed case, i.e. it contains an IP address of the 915 remote N-PE. If there are n such PWs, they are distinguished by the 916 setting of the SAII, which will be a number from 1 to n inclusive. A 917 PW between two N-PEs is known as an "N-PW". 919 Each U-PW must be "spliced" to an N-PW. This is based on the remote 920 list. If the remote list contains an element , then i U-PWs 921 from each local U-PE must be spliced to i N-PWs from the remote N-PE 922 F. It does not matter which U-PWs are spliced to which N-PWs, as long 923 as this constraint is met. 925 If an N-PE has more than one local U-PE for a given VPLS, it must 926 also ensure that a U-PW from each such U-PE is spliced to a U-PW 927 from each of the other U-PEs. 929 3.5.2 Provisioning and Discovery 931 Every N-PE must be provisioned with the set of VPLS instances it 932 supports, a VPN-id for each one, and a list of local U-PEs for each 933 such VPLS. As part of the discovery procedure, the N-PE advertises 934 the number of U-PEs for each VPLS. See Section 3.2.2 for details. 936 Auto-discovery (e.g., BGP-based) can be used to discover all the 937 other N-PEs in the VPLS, and for each, the number of U-PEs local to 938 that N-PE. From this, one can compute the total number of U-PEs in 939 the VPLS. This information is sufficient to enable one to compute 940 the local list and the remote list for each N-PE. 942 3.5.3 Non-distributed VPLS as a sub-case 944 A PE which is providing "non-distributed VPLS" (i.e., a PE which 945 performs both the U-PE and N-PE functions) can interoperate with 946 N-PE/U-PE pairs that are providing distributed VPLS. The "non- 947 distributed PE" simply advertises, in the discovery procedure, that 948 it has one local U-PE per VPLS. And of course, the non-distributed 949 PE does no splicing. 951 If every PE in a VPLS is providing non-distributed VPLS, and thus 952 every PE advertises itself as an N-PE with one local U-PE, the 953 resultant signaling is exactly the same as that specified in section 954 3.2.3 above, except that an SAII value of 1 is used instead of null. 955 (A PE providing non-distributed VPLS should therefore treat SAII 956 values of 1 the same as it treats SAII values of null.) 958 3.5.4 Splicing and the Data Plane 960 Splicing two PWs together is quite straightforward in the MPLS data 961 plane, as moving a packet from one PW directly to another is just a 962 label replace operation on the PW label. When a PW consists of two 963 or more PWs spliced together, it is assumed that the data will go to 964 the node where the splicing is being done, i.e., that the data path 965 will pass through the nodes that participate in PW signaling. 967 Further details on splicing are discussed in [PW-SWITCH]. 969 4. Inter-AS Operation 971 The provisioning, autodiscovery and signaling mechanisms described 972 above can all be applied in an inter-AS environment. As in [2547bis] 973 there are a number of options for inter-AS operation. 975 4.1 Multihop EBGP redistribution of L2VPN NLRIs 977 This option is most like option (c) in [2547bis]. That is, we use 978 multihop EBGP redistribution of L2VPN NLRIs between source and 979 destination ASes, with EBGP redistribution of labeled IPv4 routes 980 from AS to neighboring AS. 982 An ASBR must maintain labeled IPv4 /32 routes to the PE routers 983 within its AS. It uses EBGP to distribute these routes to other 984 ASes. ASBRs in any transit ASes will also have to use EBGP to pass 985 along the labeled /32 routes. This results in the creation of a 986 label switched path from the ingress PE router to the egress PE 987 router. Now PE routers in different ASes can establish multi-hop 988 EBGP connections to each other, and can exchange L2VPN NLRIs over 989 those connections. Following such exchanges a pair of PEs in 990 different ASes could establish an LDP session to signal PWs between 991 each other. 993 For VPLS, the BGP advertisement and PW signaling are exactly as 994 described in Section 3.2. As a result of the multihop EBGP session 995 that exists between source and destination AS, the PEs in one AS that 996 have VSIs of a certain VPLS will discover the PEs in another AS that 997 have VSIs of the same VPLS. These PEs will then be able to establish 998 the appropriate PW signaling protocol session and establish the full 999 mesh of VSI-VSI pseudowires to build the VPLS as described in Section 1000 3.2.3. 1002 For VPWS, the BGP advertisement and PW signaling are exactly as 1003 described in Section 3.3. As a result of the multihop EBGP session 1004 that exists between source and destination AS, the PEs in one AS that 1005 have pools of a certain color (VPN) will discover PEs in another AS 1006 that have pools of the same color. These PEs will then be able to 1007 establish the appropriate PW signaling protocol session and establish 1008 the full mesh of pseudowires as described in Section 3.2.3. A 1009 partial mesh can similarly be established using the procedures of 1010 Section 3.4. 1012 4.2 EBGP redistribution of L2VPN NLRIs with Pseudowire Switching 1014 A possible drawback of the approach of the previous section is that 1015 it creates PW signaling sessions among all the PEs of a given L2VPN 1016 (VPLS or VPWS). This means a potentially large number of LDP or 1017 L2TPv3 sessions will cross the AS boundary and that these session 1018 connect to many devices within an AS. In the case were the ASes 1019 belong to different providers, one might imagine that providers would 1020 like to have fewer signaling sessions crossing the AS boundary and 1021 that the entities that terminate the sessions could be restricted to 1022 a smaller set of devices. These concerns motivate the approach 1023 described here. 1025 [PW-SWITCH] describes an approach to "switching" packets from one 1026 pseudowire to another at a particular node. This approach allows an 1027 end-to-end pseudowire to be constructed out of several pseudowire 1028 segments, without maintaining an end-to-end control connection. We 1029 can use this approach to produce an inter-AS solution that more 1030 closely resembles option (b) in [2547bis]. 1032 In this model, we use EBGP redistribution of L2VPN NLRI from AS to 1033 neighboring AS. First, the PE routers use IBGP to redistribute L2VPN 1034 NLRI either to an Autonomous System Border Router (ASBR), or to a 1035 route reflector of which an ASBR is a client. The ASBR then uses 1036 EBGP to redistribute those L2VPN NLRI to an ASBR in another AS, which 1037 in turn distributes them to the PE routers in that AS, or perhaps to 1038 another ASBR which in turn distributes them, and so on. 1040 In this case, a PE can learn the address of an ASBR through which it 1041 could reach another PE to which it wishes to establish a PW. That 1042 is, a local PE will receive a BGP advertisement containing L2VPN NLRI 1043 corresponding to an L2VPN instance in which the local PE has some 1044 attached members. The BGP next-hop for that L2VPN NLRI will be an 1045 ASBR of the local AS. Then, rather than building a control 1046 connection all the way to the remote PE, it builds one only to the 1047 ASBR. A pseudowire segment can now be established from the PE to the 1048 ASBR. The ASBR in turn can establish a PW to the ASBR of the next 1049 AS, and use "PW switching" to splice that PW to the PW from the PE. 1050 Repeating the process at each ASBR leads to a sequence of PW segments 1051 that, when spliced together, connect the two PEs. 1053 When this approach is used for VPLS, or for full-mesh VPWS, it leads 1054 to a full mesh of pseudowires among the PEs, just as in the previous 1055 section, but it does not produce a full mesh of control connections 1056 (LDP or L2TPv3 sessions). Instead the control connections within a 1057 single AS run among all the PEs of that AS and the ASBRs of the AS. 1058 A single control connection between the ASBRs of adjacent ASes can be 1059 used to support however many AS-to-AS pseudowire segments are needed. 1061 Note that the procedures described here will result in the splicing 1062 points being co-located with the ASBRs. It is of course possible to 1063 have multiple ASBR-ASBR connections between a given pair of ASes. In 1064 this case a given PE could choose among the available ASBRs based on 1065 a range of criteria, such as IGP metric, local configuration, etc., 1066 analogous to choosing an exit point in normal IP routing. The use of 1067 multiple ASBRs would lead to greater resiliency (at the timescale of 1068 BGP routing convergence) since a PE could select a new ASBR in the 1069 event of the failure of the one currently in use. 1071 We note that, in order for this approach to work correctly, the two 1072 ASes must use RTs and RDs consistently, just as in layer 3 VPNs 1073 [RFC2547bis]. The structure of RTs and RDs is such that there is not 1074 a great risk of accidental collisions. The main challenge is that it 1075 is necessary for the operator of one AS to know what RT or RTs have 1076 been chosen in another AS for any VPN that has sites in both ASes. 1077 As in layer 3 VPNs, there are many ways to make this work, but all 1078 require some co-operation among the providers. For example, provider 1079 A may tag all the NLRI for a given VPN with a single RT, say RT_A, 1080 and provider B can then configure the PEs that connect to sites of 1081 that VPN to import NLRI that contains that RT. Provider B can choose 1082 a different RT, RT_B, tag all NLRI for this VPN with that RT, and 1083 then provider A can import NLRI with that RT at the appropriate PEs. 1084 However this does require both providers to communicate their choice 1085 of RTs for each VPN. Alternatively both providers could agree to use 1086 a common RT for a given VPN. In any case communication of RTs 1087 between the providers is essential. 1089 4.3 Inter-Provider Application of Dist. VPLS Signaling 1091 An alternative approach to inter-provider VPLS can be derived from 1092 the Distributed VPLS approach described above. Consider the 1093 following topology: 1095 PE A ---- Network 1 ----- Border ----- Border ----- Network 2 ---- PE B 1096 Router 12 Router 21 | 1097 | 1098 PE C 1100 where A, B, and C are PEs in a common VPLS, but Networks 1 and 2 are 1101 networks of different Service Providers. Border Router 12 is 1102 Network 1's border router to network 2, and Border Router 21 is 1103 Network 2's border router to Network 1. We suppose further that the 1104 PEs are not "distributed", i.e, that each provides both the U-PE and 1105 N-PE functions. 1107 In this topology, one needs two inter-provider pseudowires: A-B and 1108 A-C. 1110 Suppose a Service Provider decides, for whatever reason, that it does 1111 not want each of its PEs to have a control connection to any PEs in 1112 the other network. Rather, it wants the inter-provider control 1113 connections to run only between the two border routers. 1115 This can be achieved using the techniques of section 3.5, where the 1116 PEs behave like U-PEs, and the BRs behave like N-PEs. In the example 1117 topology, PE A would behave like a U-PE which is locally attached to 1118 BR12; PEs B and C would be have like U-PEs which are locally attached 1119 to BR21; and the two BRs would behave like N-PEs. 1121 As a result, the PW from A to B would consist of three segments: 1122 A-BR12, BR12-BR21, and BR21-B. The border routers would have to 1123 splice the corresponding segments together. 1125 This requires the PEs within a VPLS to be numbered from 1-n (relative 1126 to that VPLS) within a given network. 1128 5. Security Considerations 1130 This document describes a number of different L2VPN provisioning 1131 models, and specifies the endpoint identifiers that are required to 1132 support each of the provisioning models. It also specifies how those 1133 endpoint identifiers are mapped into fields of auto-discovery 1134 protocols and signaling protocols. 1136 The security considerations related to the signaling and auto- 1137 discovery protocols are discussed in the relevant protocol 1138 specifications ([BGP-AUTO], [L2TP-BASE], [L2TP-L2VPN], [LDP], [PWE3- 1139 CONTROL]). 1141 The security considerations related to the particular kind of L2VPN 1142 service being supported are discussed in [L2VPN-REQS], [L2VPN-FW], 1143 and [VPLS]. 1145 The security consideration of inter-AS operation are similar to those 1146 for inter-AS L3VPNs [2547bis]. 1148 The way in which endpoint identifiers are mapped into protocol fields 1149 does not create any additional security issues. 1151 6. IANA Considerations 1153 This document requires IANA to assign an AFI and a SAFI. The AFI 1154 could be the same as that assigned for [BGP-VPLS]. The SAFI should 1155 be assigned specifically for this draft. 1157 7. Acknowledgments 1159 Thanks to Dan Tappan, Ted Qian, Ali Sajassi, Skip Booth, Luca Martini 1160 and Francois LeFaucheur for their comments, criticisms, and helpful 1161 suggestions. 1163 Thanks to Tissa Senevirathne, Hamid Ould-Brahim and Yakov Rekhter for 1164 discussing the auto-discovery issues. 1166 Thanks to Vach Kompella for a continuing discussion of the proper 1167 semantics of the generalized identifiers. 1169 8. Normative References 1171 [BRADNER] Bradner, S., "Key words for use in RFCs to Indicate 1172 Requirement Levels", BCP 14, RFC 2119, March 1997. 1174 [MP-BGP] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, 1175 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 1177 [EXT-COMM] Sangli, S., Tappan, D. and Y. Rekhter, "BGP Extended 1178 Communities Attribute", Internet-Draft 1179 draft-ietf-idr-bgp-ext-communities-09, July 2005. 1181 [L2TP-BASE] Lau et. al., "Layer Two Tunneling Protocol (Version 3)", 1182 RFC 3931, March 2005. 1184 [LDP] Anderson et al., "LDP Specification", RFC 3036, Jan 2001. 1186 [PWE3-CONTROL] "Pseudowire Setup and Maintenance using LDP", Martini, 1187 et. al., draft-ietf-pwe3-control-protocol-17.txt, June 2005. 1189 9. Informative References 1191 [BGP-AUTO] "Using BGP as an Auto-Discovery Mechanism for Network- 1192 based VPNs", Ould-Brahim et. al., 1193 draft-ietf-l3vpn-bgpvpn-auto-05.txt, February 2005 1195 [L2TP-L2VPN] "L2VPN Extensions for L2TP", Luo, 1196 draft-ietf-l2tpext-l2vpn-05.txt, June 2005 1198 [L2VPN-FW] "L2VPN Framework", Andersson et. al., 1199 draft-ietf-l2vpn-l2-framework-05.txt, June 2004 1201 [L2VPN-REQ] "Service Requirements for Layer 2 Provider Provisioned 1202 Virtual Private Network Services", Augustyn, Serbest, et. al., 1203 draft-ietf-l2vpn-requirements-04.txt, February 2005 1205 [L2VPN-TERM] Andersson, Madsen, "PPVPN Terminology", RFC 4026, March 1206 2005. 1208 [PWE3-ARCH] Bryant, Pate, et. al., "PWE3 Architecture", RFC 3985, 1209 March 2005. 1211 [PW-SWITCH] "Pseudo Wire Switching", Martini, et. al., 1212 draft-martini-pwe3-pw-switching-03.txt, April 2005 1214 [RFC2547bis], "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., 1215 draft-ietf-l3vpn-rfc2547bis-03.txt, October 2004 1217 [RFC2685] "Virtual Private Networks Identifier", Fox, Gleeson, 1218 September 1999 1220 [VPLS] "Virtual Private LAN Services over MPLS", Laserre, et. al., 1221 draft-ietf-l2vpn-vpls-ldp-06.txt, February 2005 1223 Authors' Addresses 1225 Eric Rosen 1226 Cisco Systems, Inc. 1227 1414 Mass. Ave. 1228 Boxborough, MA 01719 1229 USA 1231 Email: erosen@cisco.com 1232 Wei Luo 1233 Cisco Systems, Inc. 1234 170 W Tasman Dr. 1235 San Jose, CA 95134 1236 USA 1238 Email: luo@cisco.com 1240 Bruce Davie 1241 Cisco Systems, Inc. 1242 1414 Mass. Ave. 1243 Boxborough, MA 01719 1244 USA 1246 Email: bsd@cisco.com 1248 Vasile Radoaca 1249 Nortel Networks 1250 600 Technology Park 1251 Billerica, MA 01821 1252 USA 1254 Phone: +1 978 288 6097 1255 Email: vasile@nortelnetworks.com 1257 Intellectual Property Statement 1259 The IETF takes no position regarding the validity or scope of any 1260 Intellectual Property Rights or other rights that might be claimed to 1261 pertain to the implementation or use of the technology described in 1262 this document or the extent to which any license under such rights 1263 might or might not be available; nor does it represent that it has 1264 made any independent effort to identify any such rights. Information 1265 on the procedures with respect to rights in RFC documents can be 1266 found in BCP 78 and BCP 79. 1268 Copies of IPR disclosures made to the IETF Secretariat and any 1269 assurances of licenses to be made available, or the result of an 1270 attempt made to obtain a general license or permission for the use of 1271 such proprietary rights by implementers or users of this 1272 specification can be obtained from the IETF on-line IPR repository at 1273 http://www.ietf.org/ipr. 1275 The IETF invites any interested party to bring to its attention any 1276 copyrights, patents or patent applications, or other proprietary 1277 rights that may cover technology that may be required to implement 1278 this standard. Please address the information to the IETF at 1279 ietf-ipr@ietf.org. 1281 Disclaimer of Validity 1283 This document and the information contained herein are provided on an 1284 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1285 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1286 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1287 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1288 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1289 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1291 Copyright Statement 1293 Copyright (C) The Internet Society (2005). This document is subject 1294 to the rights, licenses and restrictions contained in BCP 78, and 1295 except as set forth therein, the authors retain all their rights. 1297 Acknowledgment 1299 Funding for the RFC Editor function is currently provided by the 1300 Internet Society.