idnits 2.17.1 draft-ietf-l2vpn-signaling-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([PWE3-CONTROL], [L2VPN-FW], [RFC3036], [PWE3-ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and 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? RFC 2119 keyword, line 242: '... IT MUST BE UNDERSTOOD THAT THIS NOT...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 183 has weird spacing: '...warders being...' == Line 239 has weird spacing: '...sist of an At...' == Line 246 has weird spacing: '...ntifier may b...' == Line 247 has weird spacing: '...r, some attri...' == Line 265 has weird spacing: '...r which has ...' == (11 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2003) is 7528 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: 'RFC 3036' is mentioned on line 102, but not defined ** Obsolete undefined reference: RFC 3036 (Obsoleted by RFC 5036) == Missing Reference: 'DTLS' is mentioned on line 635, but not defined == Missing Reference: 'LPE' is mentioned on line 635, but not defined == Unused Reference: 'LDP' is defined on line 910, but no explicit reference was found in the text == Unused Reference: 'RFC2685' is defined on line 924, but no explicit reference was found in the text == Unused Reference: 'RFC3036' is defined on line 927, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-l3vpn-bgpvpn-auto-00 ** Downref: Normative reference to an Informational draft: draft-ietf-l3vpn-bgpvpn-auto (ref. 'BGP-AUTO') -- Possible downref: Normative reference to a draft: ref. 'BGP-SIGNALING' -- Possible downref: Normative reference to a draft: ref. 'RADIUS-L2TP-VPLS' == Outdated reference: A later version (-05) exists of draft-ietf-l2vpn-l2-framework-00 ** Downref: Normative reference to an Informational draft: draft-ietf-l2vpn-l2-framework (ref. 'L2VPN-FW') == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-requirements-00 ** Downref: Normative reference to an Informational draft: draft-ietf-l2vpn-requirements (ref. 'L2VPN-REQ') == Outdated reference: A later version (-04) exists of draft-andersson-ppvpn-terminology-03 -- Possible downref: Normative reference to a draft: ref. 'L2VPN-TERM' ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) -- No information found for draft-luo-l2tpext-l2vpn- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LUO-L2TP' == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-arch-04 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-arch (ref. 'PWE3-ARCH') == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-03 == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-rfc2547bis-00 -- Duplicate reference: RFC3036, mentioned in 'RFC3036', was also mentioned in 'LDP'. ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-09) exists of draft-ietf-l2vpn-vpls-ldp-00 Summary: 14 errors (**), 0 flaws (~~), 21 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Eric C. Rosen 3 Internet Draft Cisco Systems, Inc. 4 Expiration Date: March 2004 5 Vasile Radoaca 6 Nortel Networks 8 September 2003 10 Provisioning Models and Endpoint Identifiers in L2VPN Signaling 12 draft-ietf-l2vpn-signaling-00.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 [PWE3-CONTROL] specifies a "signaling protocol" which uses extensions 37 of LDP [RFC 3036] to set up and maintain pseudowires [PWE3-ARCH]. 38 Like any protocol which sets up connections, the signaling protocol 39 provides a method by which each endpoint can identify the other. 40 [L2VPN-FW] describes a number of different ways in which sets of 41 pseudowires may be combined together into "Provider Provisioned Layer 42 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of different 43 kinds of L2VPN. Different kinds of L2VPN may have different 44 "provisioning models", i.e., different models for what information 45 needs to be configured in what entities. Once configured, the 46 provisioning information is distributed by a "discovery process", and 47 once the information is discovered, the signaling protocol is 48 automatically invoked to set up the required pseudowires. The 49 semantics of the endpoint identifiers which the signaling protocol 50 uses for a particular type of L2VPN are determined by the 51 provisioning model. This document specifies a number of PPVPN 52 provisioning models, and specifies the semantic structure of the 53 endpoint identifiers required. It further specifies how the endpoint 54 identifiers are carried in the "Generalized Identifier FEC" of 55 [PWE3-CONTROL]. It is believed that the specified identifiers can 56 also be carried within the L2TP signaling protocol, though this is 57 currently not specified. 59 Contents 61 1 Introduction ......................................... 4 62 2 Signaling Protocol Framework ......................... 5 63 2.1 Endpoint Identification .............................. 5 64 2.2 Association of two LSPs as one Pseudowire ............ 6 65 2.3 Attachment Identifiers and Forwarders ................ 6 66 3 ..................................................... 8 67 4 ..................................................... 8 68 5 Applications ......................................... 8 69 5.1 Individual Point-to-Point VCs ........................ 8 70 5.1.1 Provisioning Models .................................. 8 71 5.1.1.1 Double Sided Provisioning ............................ 8 72 5.1.1.2 Single Sided Provisioning with Discovery ............. 9 73 5.1.2 Signaling ............................................ 9 74 5.2 Virtual Private LAN Service .......................... 10 75 5.2.1 Provisioning ......................................... 10 76 5.2.2 Auto-Discovery ....................................... 10 77 5.2.2.1 BGP-based auto-discovery ............................. 10 78 5.2.2.2 Radius-based auto-discovery .......................... 11 79 5.2.3 Signaling ............................................ 12 80 5.2.4 Pseudowires as VPLS Attachment Circuits .............. 12 81 5.3 Colored Pools: Full Mesh of Point-to-Point VCs ....... 12 82 5.3.1 Provisioning ......................................... 13 83 5.3.2 Auto-Discovery ....................................... 13 84 5.3.2.1 BGP-based auto-discovery ............................. 13 85 5.3.2.2 Radius-based Auto-Discovery .......................... 14 86 5.3.3 Signaling ............................................ 14 87 5.4 Colored Pools: Partial Mesh .......................... 15 88 5.5 Distributed VPLS ..................................... 15 89 5.5.1 Signaling ............................................ 17 90 5.5.2 Provisioning and Discovery ........................... 18 91 5.5.3 Non-distributed VPLS as a sub-case ................... 19 92 5.5.4 Inter-Provider Application of Dist. VPLS Signaling ... 19 93 5.5.5 Splicing and the Data Plane .......................... 20 94 6 Security Considerations .............................. 21 95 7 Acknowledgments ...................................... 21 96 8 References ........................................... 21 97 9 Author's Information ................................. 22 99 1. Introduction 101 [PWE3-CONTROL] specifies a "signaling protocol" which uses extensions 102 of LDP [RFC 3036] to set up and maintain pseudowires [PWE3-ARCH]. 103 Like any protocol which sets up connections, the signaling protocol 104 provides a method by which each endpoint can identify the other. 105 [L2VPN-FW] describes a number of different ways in which sets of 106 pseudowires may be combined together into "Provider Provisioned Layer 107 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of different 108 kinds of L2VPN. Different kinds of L2VPN may have different 109 "provisioning models", i.e., different models for what information 110 needs to be configured in what entities. Once configured, the 111 provisioning information is distributed by a "discovery process", and 112 once the information is discovered, the signaling protocol is 113 automatically invoked to set up the required pseudowires. The 114 semantics of the endpoint identifiers which the signaling protocol 115 uses for a particular type of L2VPN are determined by the 116 provisioning model. This document specifies a number of PPVPN 117 provisioning models, and specifies the semantic structure of the 118 endpoint identifiers required. It further specifies how the endpoint 119 identifiers are carried in the "Generalized Identifier FEC" of 120 [PWE3-CONTROL]. It is believed that the specified identifiers can 121 also be carried within the L2TP signaling protocol, though this is 122 currently not specified. 124 We make free use of terminology from [L2VPN-FW], [L2VPN-TERM], and 125 [PWE3-ARCH], in particular the terms "Attachment Circuit", 126 "pseudowire", "PE", "CE". 128 Section 2 provides an overview of the relevant aspects of [PWE3- 129 CONTROL]. 131 Section 5 details various provisioning models and relates them to the 132 signaling process (using the Generalized Identifier FEC) and to the 133 discovery process. 135 We do not specify an auto-discovery procedure in this draft, but we 136 do specify the information which needs to be obtained via auto- 137 discovery in order for the signaling procedures to begin. The way in 138 which the LDP-based signaling mechanisms can be integrated with BGP- 139 based auto-discovery is covered in some detail. Later revisions of 140 this draft will provide equivalent detail for other discovery 141 mechanisms. 143 (Sections 3 and 4 don't exist, but section 5 retains the same section 144 number it had in previous versions as it has been referenced by 145 number during working group discussions.) 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119 150 2. Signaling Protocol Framework 152 2.1. Endpoint Identification 154 Per [L2VPN-FW], a pseudowire can be thought of as a relationship 155 between a pair of "Forwarders". In simple instances of VPWS, a 156 Forwarder binds a pseudowire to a single Attachment Circuit, such 157 that frames received on the one are sent on the other, and vice 158 versa. In VPLS, a Forwarder binds a set of pseudowires to a set of 159 Attachment Circuits; when a frame is received from any member of that 160 set, a MAC address table is consulted (and various 802.1d procedures 161 executed) to determine the member or members of that set on which the 162 frame is to be transmitted. In more complex scenarios, Forwarders 163 may bind PWs to PWs, thereby "splicing" two PWs together; this is 164 needed, e.g., to support distributed VPLS. 166 In simple VPWS, where a Forwarder binds exactly one PW to exactly one 167 Attachment Circuit, a Forwarder can be identified by identifying its 168 Attachment Circuit. In simple VPLS, a Forwarder can be identified by 169 identifying its PE device and its VPN. 171 To set up a PW between a pair of Forwarders, the signaling protocol 172 must allow the Forwarder at one endpoint to identify the Forwarder at 173 the other. In [PWE3-CONTROL], the term "Attachment Identifier", or 174 "AI", to refer to a quantity whose purpose is to identify a 175 Forwarder. 177 [PWE3-CONTROL] specifies two FEC elements which can be used for when 178 setting up pseudowires, the PWid FEC element, and the Generalized Id 179 FEC element. The PWid FEC element carries only one Forwarder 180 identifier; it can be thus be used only when both forwarders have the 181 same identifier, and when that identifier can be coded as a 32-bit 182 quantity. The Generalized Id FEC element carries two Forwarder 183 identifiers, one for each of the two Forwarders being connected. 184 (The concept of carrying a local identifier and a remote identifier 185 is also used in the L2TP signaling proposal described in [LUO-L2TP].) 186 Each identifier is known as an Attachment Identifier, and a signaling 187 message carries both a "Source Attachment Identifier" (SAI) and a 188 "Target Attachment Identifier" (TAI). 190 The Generalized ID FEC element also provides some additional 191 structuring of the identifiers. It is assumed that the SAI and TAI 192 will sometimes have a common part, called the "Attachment Group 193 Identifier" (AGI), such that the SAI and TAI can each be thought of 194 as the concatenation of the AGI with an "Attachment Individual 195 Identifier" (AII). So the pair of identifiers is encoded into three 196 fields: AGI, Source AII (SAII), and Target AII (TAII). The SAI is 197 the concatenation of the AGI and the SAII, while the TAI is the 198 concatenation of the AGI and the TAII. This additional structuring 199 differs from the proposal in [LUO-L2TP], which specifies only that 200 there be two "endpoint identifiers". 202 In applications that group sets of PWs into "Layer 2 Virtual Private 203 Networks", the AGI can be thought of as a "VPN Identifier". 205 It should be noted that while different forwarders support different 206 applications, the type of application (e.g., VPLS vs. VPWS) cannot 207 necessarily be inferred from the forwarders' identifiers. A router 208 receiving a signaling message with a particular TAI will have to be 209 able to determine which of its local forwarders is identified by that 210 TAI, and to determine the application provided by that forwarder. 211 But other nodes may not be able to infer the application simply by 212 inspection of the signaling messages. 214 2.2. Association of two LSPs as one Pseudowire 216 In any form of LDP-based signaling, each PW endpoint must initiate 217 the creation of a unidirectional LSP. A PW is a pair of such LSPs. 218 In most of the PPVPN provisioning models, the two endpoints of a 219 given PW can simultaneously initiate the signaling for it. They must 220 therefore have some way of determining when a given pair of LSPs are 221 intended to be associated together as a single PW. 223 The way in which this association is done is different for the 224 various different L2VPN services and provisioning models. The 225 details appear in later sections. 227 2.3. Attachment Identifiers and Forwarders 229 Every Forwarder in a PE must be associated with an Attachment 230 Identifier (AI), either through configuration or through some 231 algorithm. The Attachment Identifier must be unique in the context 232 of the PE router in which the Forwarder resides. The combination must be globally unique. 235 It is frequently convenient to a set of Forwarders as being members 236 of a particular "group", where PWs may only be set up among members 237 of a group. In such cases, it is convenient to identify the 238 Forwarders relative to the group, so that an Attachment Identifier 239 would consist of an Attachment Group Identifier (AGI) plus an 240 Attachment Individual Identifier (AII). 242 IT MUST BE UNDERSTOOD THAT THIS NOTION OF "GROUP" HAS NOTHING 243 WHATSOEVER TO DO WITH THE "GROUP ID" THAT IS PART OF THE PWID FEC IN 244 [PWE3-CONTROL]. 246 An Attachment Group Identifier may be thought of as a VPN-id, or 247 a VLAN identifier, some attribute which is shared by all the 248 Attachment VCs (or pools thereof) which are allowed to be connected. 250 The details for how to construct the AGI and AII fields identifying 251 the pseudowire endpoints in particular provisioning models are 252 discussed later in this paper. 254 We can now consider an LSP to be identified by: 256 , PE2, >, 258 and the LSP in the opposite direction will be identified by: 260 , PE1, >; 262 a pseudowire is a pair of such LSPs. 264 When a signaling message is sent from PE1 to PE2, and PE1 needs to 265 refer to an Attachment Identifier which has been configured on 266 one of its own Attachment VCs (or pools), the Attachment 267 Identifier is called a "Source Attachment Identifier". If PE1 268 needs to refer to an Attachment Identifier which has been 269 configured on one of PE2's Attachment VCs (or pools), the 270 Attachment Identifier is called a "Target Attachment Identifier". 271 (So an SAI at one endpoint is a TAI at the remote endpoint, and vice 272 versa.) 274 In the signaling protocol, we define encodings for the following 275 three fields: 277 - Attachment Group Identifier (AGI). 279 - Source Attachment Individual Identifier (SAII) 281 - Target Attachment Individual Identifier (TAII) 283 If the AGI is non-null, then the SAI consists of the AGI together 284 with the SAII, and the TAI consists of the TAII together with the 285 AGI. If the AGI is null, then the SAII and TAII are the SAI and TAI 286 respectively. 288 The intention is that the PE which receives a Label Mapping 289 Message containing a TAI will be able to map that TAI uniquely 290 to one of its Attachment VCs (or pools). The way in which a 291 PE maps a TAI to an Attachment VC (or pool) should be a 292 local matter. So as far as the signaling procedures are 293 concerned, the TAI is really just an arbitrary string of bytes, a 294 "cookie". 296 3. 298 4. 300 5. Applications 302 In this section, we specify the way in which the pseudowire signaling 303 using the Generalized ID FEC Element is applied for a number of 304 different applications. For some of the applications, we specify the 305 way in which different provisioning models can be used. However, 306 this is not meant to be an exhaustive list of the applications, or an 307 exhaustive list of the provisioning models that can be applied to 308 each application. 310 5.1. Individual Point-to-Point VCs 312 The signaling specified in this document can be used to set up 313 individually provisioned point-to-point pseudowires. In this 314 application, each Forwarder binds a single PW to a single Attachment 315 Circuit. Each PE must be provisioned with the necessary set of 316 Attachment Circuits, and then certain parameters must be provisioned 317 for each Attachment Circuit. 319 5.1.1. Provisioning Models 321 5.1.1.1. Double Sided Provisioning 323 In this model, the Attachment Circuit must be provisioned with a 324 local name, a remote PE address, and a remote name. During 325 signaling, the local name is sent as the SAII, the remote name as the 326 TAII, and the AGI is null. If two Attachment Circuits are to be 327 connected by a PW, the local name of each must be the remote name of 328 the other. 330 Note that if the local name and the remote name are the same, the 331 PWid FEC element can be used instead of the Generalized ID FEC 332 element. 334 5.1.1.2. Single Sided Provisioning with Discovery 336 In this model, each Attachment Circuit must be provisioned with a 337 local name. The local name consists of a VPN-id (signaled as the 338 AGI) and an Attachment Individual Identifier which is unique relative 339 to the AGI. If two Attachment circuits are to be connected by a PW, 340 only one of them needs to be provisioned with a remote name (which of 341 course is the local name of the other Attachment Circuit). Neither 342 needs to be provisioned with the address of the remote PE, but both 343 must have the same VPN-id. 345 As part of an auto-discovery procedure, each PE advertises its pairs. Each PE compares its local pairs with the pairs advertised by the other 348 PEs. If PE1 has a local pair with value , and PE2 has a local pair with value , PE1 will thus be able to discover that it needs to connect to 351 PE2. When signaling, it will use "fred" as the TAII, and will use V 352 as he AGI. PE1's local name for the Attachment Circuit is sent as 353 the SAII. 355 The primary benefit of this provisioning model when compared to 356 Double Sided Provisioning is that it enables one to move an 357 Attachment Circuit from one PE to another without having to 358 reconfigure the remote endpoint. 360 5.1.2. Signaling 362 Signaling is as specified in section 4 above, with the addition of 363 the following: 365 When a PE receives a Label Mapping Message, and the TAI identifiers a 366 particular Attachment Circuit which is configured to be bound to a 367 point-to-point PW, then the following checks must be made. 369 If the Attachment Circuit is already bound to a pseudowire (including 370 the case where only one of the two LSPs currently exists), and the 371 remote endpoint is not PE1, then PE2 sends a Label Release message to 372 PE1, with a Status Code meaning "Attachment Circuit bound to 373 different PE", and the processing of the Mapping message is complete. 375 If the Attachment Circuit is already bound to a pseudowire (including 376 the case where only one of the two LSPs currently exists, but the AI 377 at PE1 is different than that specified in the AGI/SAII fields of the 378 Mapping message) then PE2 sends a Label Release message to PE1, with 379 a Status Code meaning "Attachment Circuit bound to different remote 380 Attachment Circuit", and the processing of the Mapping message is 381 complete. 383 These errors could occur as the result of misconfigurations. 385 5.2. Virtual Private LAN Service 387 In the VPLS application [L2VPN-REQ, VPLS], the Attachment Circuits 388 can be though of as LAN interfaces which attach to "virtual LAN 389 switches", or, in the terminology of [L2VPN-FW], "Virtual Switching 390 Instances" (VSIs). Each Forwarder is a VSI that attaches to a number 391 of PWs and a number of Attachment Circuits. The VPLS service 392 [L2VPN-REQ, VPLS] requires that a single pseudowire be created 393 between each pair of VSIs that are in the same VPLS. Each PE device 394 may have a multiple VSIs, where each VSI belongs to a different VPLS. 396 5.2.1. Provisioning 398 Each VPLS must have a globally unique identifier, which we call a 399 VPN-id. Every VSI must be configured with the VPN-id of the VPLS to 400 which it belongs. 402 Each VSI must also have a unique identifier, but this can be formed 403 automatically by concatenating its VPN-id with the IP address of its 404 PE router. 406 5.2.2. Auto-Discovery 408 5.2.2.1. BGP-based auto-discovery 410 The framework for BGP-based auto-discovery for a VPLS service is as 411 specified in [BGP-AUTO], section 3.2. 413 The AFI/SAFI used would be: 415 - An AFI specified by IANA for L2VPN. (This is the same for all 416 L2VPN schemes.) 418 - An SAFI specified by IANA specifically for an L2VPN (VPLS or 419 VPWS) service whose pseudowires are set up using the procedures 420 described in the current document. 422 In order to use BGP-based auto-discovery as specified in [BGP-AUTO], 423 the globally unique identifier associated with a VPLS must be 424 encodable as an 8-byte Route Distinguisher (RD). If the globally 425 unique identifier for a VPLS is an RFC2685 VPN-id, it can be encoded 426 as an RD as specified in [BGP-AUTO]. However, any other method of 427 assigning a unique identifier to a VPLS and encoding it as an RD 428 (using the encoding techniques of [RFC2547bis]) will do. 430 Each VSI needs to have a unique identifier, which can be encoded as a 431 BGP NLRI. This is formed by prepending the RD (from the previous 432 paragraph) to an IP address of the PE containing the virtual LAN 433 switch. 435 (Note that it is not strictly necessary for all the VSIs in the same 436 VPLS to have the same RD, all that is really necessary is that the 437 NLRI uniquely identify a virtual LAN switch.) 439 Each VSI needs to be associated with one or more Route Target (RT) 440 Extended Communities, as discussed in [BGP-AUTO}. These control the 441 distribution of the NLRI, and hence will control the formation of the 442 overlay topology of pseudowires that constitutes a particular VPLS. 444 Auto-discovery proceeds by having each PE distribute, via BGP, the 445 NLRI for each of its VSIs, with itself as the BGP next hop, and with 446 the appropriate RT for each such NLRI. Typically, each PE would be a 447 client of a small set of BGP route reflectors, which would 448 redistribute this information to the other clients. 450 If a PE has a VSI with a particular RT, it can then receive all the 451 NLRI which have that same RT, and from the BGP next hop attribute of 452 these NLRI will learn the IP addresses of the other PE routers which 453 have VSIs with the same RT. The considerations of [RFC2547bis] 454 section 4.3.3 on the use of route reflectors apply. 456 If a particular VPLS is meant to be a single fully connected LAN, all 457 its VSIs will have the same RT, in which case the RT could be (though 458 it need not be) an encoding of the VPN-id. If a particular VPLS 459 consists of multiple VLANs, each VLAN must have its own unique RT. A 460 VSI can be placed in multiple VLANS (or even in multiple VPLSes) by 461 assigning it multiple RTs. 463 Note that hierarchical VPLS can be set up by assigning multiple RTs 464 to some of the virtual LAN switches; the RT mechanism allows one to 465 have complete control over the pseudowire overlay which constitutes 466 the VPLS topology. 468 5.2.2.2. Radius-based auto-discovery 470 [RADIUS-L2TP-VPLS] includes a proposal for using RADIUS-based auto- 471 discovery. 473 5.2.3. Signaling 475 It is necessary to create Attachment Identifiers which identify the 476 VSIs. Given that each VPLS has at most one VSI per PE, and that only 477 one PW is permitted between any pair of VSIs, a VSI can be uniquely 478 identified (relative to its PE) by the VPN-id of its VPLS. Therefore 479 the signaling messages can encode the VPN-id in the AGI field, and 480 use the null values of the SAII and TAII fields. 482 The VPN-id may be encoded as an [RFC2547bis] RD, in which case the 483 AGI field consist of a length field of value 8, followed by the 8 484 bytes of the RD. If the VPN-id is an RFC2685 VPN-id, it should be 485 encoded as an RD (as specified in [BGP-AUTO]), and then the RD should 486 be carried in the AGI field. 488 Note that it is not possible using this technique to set up more than 489 one PW per pair of VSIs. 491 5.2.4. Pseudowires as VPLS Attachment Circuits 493 It is also possible using this technique to set up a PW which 494 attaches at one endpoint to a VSI, but at the other endpoint only to 495 an Attachment Circuit. However, in this case there may be more than 496 one PW between a pair of PEs, so that AIIs cannot be null. Rather, 497 each such PW must have AII which is unique relative to the VPN-id. 498 This value would be carried in both the SAII and the TAII field of 499 the signaling messages. 501 5.3. Colored Pools: Full Mesh of Point-to-Point VCs 503 In the "Colored Pools" model of operation, each PE may contain 504 several pools of Attachment Circuits, each pool associated with a 505 particular VPN. A PE may contain multiple pools per VPN, as each 506 pool may correspond to a particular CE device. It may be desired to 507 create one pseudowire between each pair of pools that are in the same 508 VPN; the result would be to create a full mesh of CE-CE VCs for each 509 VPN. (This application was originally suggested in [BGP-SIGNALING]; 510 we show here that it can be done with LDP-based signaling.) 512 5.3.1. Provisioning 514 Each pool is configured, and associated with: 516 - a set of Attachment Circuits; whether these Attachment Circuits 517 must themselves be provisioned, or whether they can be auto- 518 allocated as needed, is independent of and orthogonal to the 519 procedures described in this document; 521 - a "color", which can be thought of as a VPN-id of some sort; 523 - a relative pool identifier, which is unique relative to the 524 color. 526 The pool identifier, and color, taken together, constitute a globally 527 unique identifier for the pool. Thus if there are n pools of a given 528 color, their pool identifiers can be (though they do not need to be) 529 the numbers 1-n. 531 The semantics are that a pseudowire will be created between every 532 pair of pools that have the same color, where each such pseudowire 533 will be bound to one Attachment Circuit from each of the two pools. 535 If each pool is a set of Attachment Circuits leading to a single CE 536 device, then the layer 2 connectivity among the CEs is controlled by 537 the way the colors are assigned to the pools. To create a full mesh, 538 the "color" would just be a VPN-id. 540 Optionally, a particular Attachment Circuit may be configured with 541 the relative pool identifier of a remote pool. Then that Attachment 542 Circuit would be bound to a particular pseudowire only if that 543 pseudowire's remote endpoint is the pool with that relative pool 544 identifier. With this option, the same pairs of Attachment Circuits 545 will always be bound via pseudowires. 547 5.3.2. Auto-Discovery 549 5.3.2.1. BGP-based auto-discovery 551 The framework for BGP-based auto-discovery for a colored pool service 552 is as specified in [BGP-AUTO], section 3.2. 554 The AFI/SAFI used would be: 556 - An AFI specified by IANA for L2VPN. (This is the same for all 557 L2VPN schemes.) 559 - An SAFI specified by IANA specifically for an L2VPN (VPLS or 560 VPWS) service whose pseudowires are set up using the procedures 561 described in the current document. 563 In order to use BGP-based auto-discovery, the color associated with a 564 colored pool must be encodable as both an RT (Route Target) and an RD 565 (Route Distinguisher). The globally unique identifier of a pool must 566 be encodable as NLRI; the color would be encoded as the RD and the 567 pool identifier as a four-byte quantity which is appended to the RD 568 to create the NLRI. 570 Auto-discovery procedures by having each PE distribute, via BGP, the 571 NLRI for each of its pools, with itself as the BGP next hop, and with 572 the RT that encodes the pool's color. If a given PE has a pool with 573 a particular color (RT), it must receive, via BGP, all NLRI with that 574 same color (RT). Typically, each PE would be a client of a small set 575 of BGP route reflectors, which would redistribute this information to 576 the other clients. 578 If a PE has a pool with a particular color, it can then receive all 579 the NLRI which have that same color, and from the BGP next hop 580 attribute of these NLRI will learn the IP addresses of the other PE 581 routers which have pools switches with the same color. It also 582 learns the unique identifier of each such remote pool, as this is 583 encoded in the NLRI. The remote pool's relative identifier can be 584 extracted from the NLRI and used in the signaling, as specified 585 below. 587 5.3.2.2. Radius-based Auto-Discovery 589 The use of Radius-based auto-discovery for the colored pool model of 590 operation is for further study. 592 5.3.3. Signaling 594 When a PE sends a Label Mapping message to set up a PW between two 595 pools, it encodes the color as the AGI, the local pool's relative 596 identifier as the SAII, and the remote pool's relative identifier as 597 the TAII. 599 When PE2 receives a Label Mapping message from PE1, and the TAI 600 identifies to a pool, and there is already an pseudowire connecting 601 an Attachment Circuit in that pool to an Attachment Circuit at PE1, 602 and the AI at PE1 of that pseudowire is the same as the SAI of the 603 Label Mapping message, then PE2 sends a Label Release message to PE1, 604 with a Status Code meaning "Attachment Circuit bound to different 605 remote Attachment Circuit". This prevents the creation of multiple 606 pseudowires between a given pair of pools. 608 Note that the signaling itself only identifies the remote pool to 609 which the pseudowire is to lead, not the remote Attachment Circuit 610 which is to be bound to the the pseudowire. However, the remote PE 611 may examine the SAII field to determine which Attachment Circuit 612 should be bound to the pseudowire. 614 5.4. Colored Pools: Partial Mesh 616 The procedures for creating a partial mesh of pseudowires among a set 617 of colored pools are substantially the same as those for creating a 618 full mesh, with the following exceptions: 620 - Each pool is optionally configured with a set of "import RTs" and 621 "export RTs"; 623 - During BGP-based auto-discovery, the pool color is still encoded 624 in the RD, but if the pool is configured with a set of "export 625 RTs", these are are encoded in the RTs of the BGP Update 626 messages, INSTEAD the color. 628 - If a pool has a particular "import RT" value X, it will create a 629 PW to every other pool which has X as one of its "export RTs". 630 The signaling messages and procedures themselves are as in 631 section 5.3.3 633 5.5. Distributed VPLS 635 In Distributed VPLS ([L2VPN-FW], [DTLS], [LPE]), the VPLS 636 functionality of a PE router is divided among two systems: a U-PE and 637 an N-PE. The U-PE sits between the user and the N-PE. VSI 638 functionality (e.g., MAC address learning and bridging) is performed 639 on the U-PE. A number of U-PEs attach to an N-PE. For each VPLS 640 supported by a U-PE, the U-PE maintains a pseudowire to each other 641 U-PE in the same VPLS. However, the U-PEs do not maintain signaling 642 control connections with each other. Rather, each U-PE has only a 643 single signaling connection, to its N-PE. In essence, each U-PE-to- 644 U-PE pseudowire is composed of three pseudowires spliced together: 645 one from U-PE to N-PE, one from N-PE to N-PE, and one from N-PE to 646 U-PE. 648 Consider for example the following topology: 650 U-PE A-----| |----U-PE C 651 | | 652 | | 653 N-PE E--------N-PE F 654 | | 655 | | 656 U-PE B-----| |-----U-PE D 658 where the four U-PEs are in a common VPLS. We now illustrate how PWs 659 get spliced together in the above topology in order to establish the 660 necessary PWs from U-PE A to the other U-PEs. 662 There are three PWs from A to E. Call these A-E/1, A-E/2, and A-E/3. 663 In order to connect A properly to the other U-PEs, there must be two 664 PWs from E to F (call these E-F/1 and E-F/2), one PW from E to B (E- 665 B/1), one from F to C (F-C/1), and one from F to D (F-D/1). 667 The N-PEs must then splice these pseudowires together to get the 668 equivalent of what the non-distributed VPLS signaling mechanism would 669 provide: 671 - PW from A to B: A-E/1 gets spliced to E-B/1. 673 - PW from A to C: A-E/2 gets spliced to E-F/1 gets spliced to F- 674 C/1. 676 - PW from A to D: A-E/3 gets spliced to E-F/2 gets spliced to F- 677 D/1. 679 It doesn't matter which PWs get spliced together, as long as the 680 result is one from A to each of B, C, and D. 682 Similarly, there are additional PWs which must get spliced together 683 to properly interconnect U-PE B with U-PEs C and D, and to 684 interconnect U-PE C with U-PE D. 686 One can see that distributed VPLS does not reduce the number of 687 pseudowires per U-PE, but it does reduce the number of control 688 connections per U-PE. Whether this is worthwhile depends, of course, 689 on what the bottleneck is. 691 5.5.1. Signaling 693 The signaling to support Distributed VPLS can be done with the 694 mechanisms described in this paper. However, the procedures for VPLS 695 (section 5.2.3) presuppose that, between a pair of PEs, there is only 696 one PW per VPLS. In distributed VPLS, this isn't so. In the 697 topology above, for example, there are two PWs between A and E for 698 the same VPLS. For distributed VPLS therefore, one cannot identify 699 the Forwarders merely by using the VPN-id as the AGI, while using 700 null values of the SAII and TAII. Rather, the SAII and TAII must be 701 used to identify particular U-PE devices. 703 At a given N-PE, the directly attached U-PEs in a given VPLS can be 704 numbered from 1 to n. This number identifies the U-PE relative to a 705 particular VPN-id and a particular PE. (That is, to uniquely 706 identify the U-PE, the N-PE, the VPN-id, and the U-PE number must be 707 known.) 709 As a result of configuration/discovery, each U-PE must be given a 710 list of pairs. Each element in this list tells the 711 U-PE to set up j PWs to the specified IP address. When the U-PE 712 signals to the N-PE, it sets the AGI to the proper-VPN-id, and sets 713 the SAII to the PW number, and sets the TAII to null. 715 In the above example, U-PE A would be told <3, E>, telling it to set 716 up 3 PWs to E. When signaling, A would set the AGI to the proper 717 VPN-id, and would set the SAII to 1, 2, or 3, depending on which of 718 the three PWs it is signaling. 720 As a result of configuration/discovery, each N-PE must be given the 721 following information for each VPLS: 723 - A "Local" list: {}, where each element tells it to 724 set up j PWs to the locally attached U-PE at the specified 725 address. The number of elements in this list will be n, the 726 number of locally attached U-PEs in this VPLS. In the above 727 example, E would be given the local list: {<3, A>, <3, B>}, 728 telling it to set up 3 PWs to A and 3 to B. 730 - A local numbering, relative to the particular VPLS and the 731 particular N-PE, of its U-PEs. In the above example, E could be 732 told that U-PE A is 1, and U-PE B is 2. 734 - A "Remote" list: {}, telling it to set up k PWs, 735 for each U-PE, to the specified IP address. Each of these IP 736 addresses identifies a N-PE, and k specifies the number of U-PEs 737 at that N-PE which are in the VPLS. In the above example, E 738 would be given the remote list: {<2, F>}. Since N-PE E has two 739 U-PEs, this tells it to set up 4 PWs to N-PE F, 2 for each of its 740 E's U-PEs. 742 The signaling of a PW from N-PE to U-PE is based on the local list 743 and the local numbering of U-PEs. When signaling a particular PW 744 from an N-PE to a U-PE, the AGI is set to the proper VPN-id, and SAII 745 is set to null, and the TAII is set to the PW number (relative to 746 that particular VPLS and U-PE). In the above example, when E signals 747 to A, it would set the TAII to be 1, 2, or 3, respectively, for the 748 three PWs it must set up to A. It would similarly signal three PWs 749 to B. 751 The LSP signaled from U-PE to N-PE is associated with an LSP from N- 752 PE to U-PE in the usual manner, as specified in section 4. A PW 753 between a U-PE and an N-PE is known as a "U-PW". 755 The signaling of a PW from N-PE to N-PE is based on the remote list. 756 When signaling a particular PW from an N-PE to an N-PE, the AGI is 757 set to the appropriate VPN-id. The remote list specifies the number 758 of PWs to set up, per local U-PE, to a particular remote N-PE. If 759 there are n such PWs, they are distinguished by the setting of the 760 TAII, which will be a number from 1 to n inclusive. The SAII is set 761 to the local number of the U-PE. In the above example, E would set 762 up 4 PWs to F. The SAII/TAII fields would be set to 1/1, 1/2, 2/1, 763 and 2/2 respectively. A PW between two N-PEs is known as an "N-PW". 765 Each U-PW must be "spliced" to an N-PW. This is based on the remote 766 list. If the remote list contains an element , then i U-PWs 767 from each local U-PE must be spliced to i N-PWs from the remote N-PE 768 F. It does not matter which U-PWs are spliced to which N-PWs, as 769 long as this constraint is met. 771 If an N-PE has more than one local U-PE for a given VPLS, it must 772 also ensure that a U-PW from each such U-PE is spliced to a U-PW 773 from each of the other U-PEs. 775 5.5.2. Provisioning and Discovery 777 Every N-PE must be provisioned with the set of VPLS instances it 778 supports, a VPN-id for each one, and a list of local U-PEs for each 779 such VPLS. As part of the discovery procedure, the N-PE advertises 780 the number of U-PEs for each VPLS. 782 Auto-discovery (e.g., BGP-based) can be used to discover all the 783 other N-PEs in the VPLS, and for each, the number of U-PEs local to 784 that N-PE. From this, one can compute the total number of U-PEs in 785 the VPLS. This information is sufficient to enable one to compute 786 the local list and the remote list for each N-PE. 788 5.5.3. Non-distributed VPLS as a sub-case 790 A PE which is providing "non-distributed VPLS" (i.e., a PE which 791 performs both the U-PE and N-PE functions) can interoperate with N- 792 PE/U-PE pairs that are providing distributed VPLS. The "non- 793 distributed PE" simply advertises, in the discovery procedure, that 794 it has one local U-PE per VPLS. And of course, the non-distributed 795 PE does no splicing. 797 If every PE in a VPLS is providing non-distributed VPLS, and thus 798 every PE advertises itself as an N-PE with one local U-PE, the 799 resultant signaling is exactly the same as that specified in section 800 5.2.3 above, except that SAII and TAII values of 1 are used instead 801 of SAII and TAII values of null. (A PE providing non-distributed 802 VPLS should therefore treat AII values of 1 the same as it treats AII 803 values of null.) 805 5.5.4. Inter-Provider Application of Dist. VPLS Signaling 807 Consider the following topology: 809 PE A ---- Network 1 ----- Border ----- Border ----- Network 2 ---- PE B 810 Router 12 Router 21 | 811 | 812 PE C 814 where A, B, and C are PEs in a common VPLS, but Networks 1 and 2 are 815 networks of different Service Providers. Border Router 12 is 816 Network 1's border router to network 2, and Border Router 21 is 817 Network 2's border router to Network 1. We suppose further that the 818 PEs are not "distributed", i.e, that each provides both the U-PE and 819 N-PE functions. 821 In this topology, one needs two inter-provider pseudowires: A-B and 822 A-C. 824 Suppose a Service Provider decides, for whatever reason, that it does 825 not want each of its PEs to have a control connection to any PEs in 826 the other network. Rather, it wants the inter-provider control 827 connections to run only between the two border routers. 829 This can be achieved using the techniques of section 5.5, where the 830 PEs behave like U-PEs, and the BRs behave like N-PEs. In the example 831 topology, PE A would behave like a U-PE which is locally attached to 832 BR12; PEs B and C would be have like U-PEs which are locally attached 833 to BR21; and the two BRs would behave like N-PEs. 835 As a result, the PW from A to B would consist of three segments: A- 836 BR12, BR12-BR21, and BR21-B. The border routers would have to splice 837 the corresponding segments together. 839 This requires the PEs within a VPLS to be numbered from 1-n (relative 840 to that VPLS) within a given network. 842 5.5.5. Splicing and the Data Plane 844 Splicing two PWs together is quite straightforward in the MPLS data 845 plane, as moving a packet from one PW directly to another is just a 846 label replace operation on the PW label. When a PW consists of two 847 PWs spliced together, it is assumed that the data will go to the node 848 where the splicing is being done, i.e., that the data path will 849 include the control points. 851 In some cases, it may be desired to have the data go on a more direct 852 route from one "true endpoint" to another, without necessarily 853 passing through the splice points. This could be done by means of a 854 new LDP TLV carried in the LDP mapping message; call it the "direct 855 route" TLV. A direct route TLV would be placed in an LDP Label 856 Mapping message by the LSP's "true endpoint". The TLV would specify 857 the IP address of the true endpoint, and would also specify a label, 858 representing the pseudowire, which is assigned by that endpoint. 859 When PWs are spliced together at intermediate control points, this 860 TLV would simply be passed upstream. Then when a frame is first put 861 on the pseudowire, it can be given this pseudowire label, and routed 862 to the true endpoint, thereby possibly bypassing the intermediate 863 control points. 865 6. Security Considerations 867 Each L2VPN service has its own set of security considerations, and 868 each signaling mechanism used for L2VPN has its own set of security 869 considerations. The semantics of the identifiers used in the 870 signaling protocols does not pose any additional security 871 considerations. The choice of provisioning model also does not 872 impose any security considerations, except insofar as the associated 873 auto-discovery and signaling procedures may have security 874 considerations. 876 7. Acknowledgments 878 Thanks to Dan Tappan, Ted Qian, Bruce Davie, Ali Sajassi, Wei Luo, 879 Skip Booth, and Francois LeFaucheur for their comments, criticisms, 880 and helpful suggestions. 882 Thanks to Tissa Senevirathne, Hamid Ould-Brahim and Yakov Rekhter for 883 discussing the auto-discovery issues. 885 Thanks to Vach Kompella and Wei Luo for a continuing discussion of 886 the proper semantics of the generalized identifiers. 888 8. References 890 [BGP-AUTO] "Using BGP as an Auto-Discovery Mechanism for Network- 891 based VPNs", Ould-Brahim et. al., draft-ietf-l3vpn-bgpvpn-auto- 892 00.txt, May 2003. 894 [BGP-SIGNALING] "Layer 2 VPNs over Tunnels", Kompella et. al., 895 draft-kompella-ppvpn-l2vpn-03.txt, Apr 2003 897 [RADIUS-L2TP-VPLS] "Radius/L2TP Based VPLS", Heinanen, draft- 898 heinanen-radius-l2tp-vpls-00.txt, Feb 2003 900 [L2VPN-FW] "L2VPN Framework", Andersson et. al., draft-ietf-l2vpn- 901 l2-framework-00.txt, Feb 2003 903 [L2VPN-REQ] "Service Requirements for Layer 2 Provider Provisioned 904 Virtual Private Network Services", Augustyn, Serbest, et. al., 905 draft-ietf-l2vpn-requirements-00.txt, May 2003 907 [L2VPN-TERM] "PPVPN Terminology", Andersson, Madsen, draft- 908 andersson-ppvpn-terminology-03.txt, Apr 2002 910 [LDP] "LDP Specification", Andersson, et. al., RFC 3036, Jan 2001 912 [LUO-L2TP] "L2VPN Signaling Using L2TPv3", Luo, draft-luo-l2tpext- 913 l2vpn- signaling-02.txt, Jun 2003 915 [PWE3-ARCH] "PWE3 Architecture", Bryant, Pate, et. al., draft-ietf- 916 pwe3-arch-04.txt, Jun 2003 918 [PWE3-CONTROL] "Pseudowire Setup and Maintenance using LDP", Martini, 919 et. al., draft-ietf-pwe3-control-protocol-03.txt, Jul 2003 921 [RFC2547bis], "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., draft- 922 ietf-l3vpn-rfc2547bis-00.txt, May 2003 924 [RFC2685] "Virtual Private Networks Identifier", Fox, Gleeson, 925 September 1999 927 [RFC3036] "LDP Specification", January 2001 929 [VPLS] "Virtual Private LAN Services over MPLS", Laserre, et. al., 930 draft-ietf-l2vpn-vpls-ldp-00.txt, Jun 2003 932 9. Author's Information 934 Eric C. Rosen 935 Cisco Systems, Inc. 936 1414 Massachusetts Avenue 937 Boxborough, MA, 01719 938 E-mail: erosen@cisco.com 940 Vasile Radoaca 941 Nortel Networks 942 600 Technology Park 943 Billerica, MA 01821 944 Phone: (781) 856-0590/978-288-6097