idnits 2.17.1 draft-rosen-ppvpn-l2-signaling-03.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-FR,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 236: '... IT MUST BE UNDERSTOOD THAT THIS NOT...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 180 has weird spacing: '...warders being...' == Line 233 has weird spacing: '...sist of an At...' == Line 240 has weird spacing: '...ntifier may b...' == Line 241 has weird spacing: '...r, some attri...' == Line 259 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 (May 2003) is 7623 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 99, but not defined ** Obsolete undefined reference: RFC 3036 (Obsoleted by RFC 5036) == Missing Reference: 'DTLS' is mentioned on line 623, but not defined == Missing Reference: 'LPE' is mentioned on line 623, but not defined == Unused Reference: 'LDP' is defined on line 898, but no explicit reference was found in the text == Unused Reference: 'RFC2685' is defined on line 915, but no explicit reference was found in the text == Unused Reference: 'RFC3036' is defined on line 918, but no explicit reference was found in the text -- No information found for draft-ietf-ppvpn-bgpvpn-auto - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BGP-AUTO' -- Possible downref: Normative reference to a draft: ref. 'BGP-SIGNALING' -- Possible downref: Normative reference to a draft: ref. 'RADIUS-L2TP-VPLS' -- No information found for draft-ietf-ppvpn-l2-framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'L2VPN-FW' -- Possible downref: Normative reference to a draft: ref. 'L2VPN-REQ' == Outdated reference: A later version (-04) exists of draft-andersson-ppvpn-terminology-02 -- 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-02 ** 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-02 -- No information found for draft-ietf - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PWE3-FR' -- No information found for draft-ietf-ppvpn-rfc2547bis - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RFC2547bis' -- Duplicate reference: RFC3036, mentioned in 'RFC3036', was also mentioned in 'LDP'. ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) -- Possible downref: Normative reference to a draft: ref. 'VPLS' Summary: 11 errors (**), 0 flaws (~~), 16 warnings (==), 18 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: November 2003 6 May 2003 8 Provisioning Models and Endpoint Identifiers in L2VPN Signaling 10 draft-rosen-ppvpn-l2-signaling-03.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 [PWE3-CONTROL] specifies a "signaling protocol" which uses extensions 35 of LDP [RFC 3036] to set up and maintain pseudowires [PWE3-FR, PWE3- 36 ARCH]. Like any protocol which sets up connections, the signaling 37 protocol provides a method by which each endpoint can identify the 38 other. [L2VPN-FW] describes a number of different ways in which sets 39 of pseudowires may be combined together into "Provider Provisioned 40 Layer 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of 41 different kinds of L2VPN. Different kinds of L2VPN may have 42 different "provisioning models", i.e., different models for what 43 information needs to be configured in what entities. Once configured, 44 the provisioning information is distributed by a "discovery process", 45 and once the information is discovered, the signaling protocol is 46 automatically invoked to set up the required pseudowires. The 47 semantics of the endpoint identifiers which the signaling protocol 48 uses for a particular type of L2VPN are determined by the 49 provisioning model. This document specifies a number of PPVPN 50 provisioning models, and specifies the semantic structure of the 51 endpoint identifiers required. It further specifies how the endpoint 52 identifiers are carried in the "Generalized Identifier FEC" of 53 [PWE3-CONTROL]. It is believed that the specified identifiers can 54 also be carried within the L2TP signaling protocol, though this is 55 currently not specified. 57 Contents 59 1 Introduction ......................................... 4 60 2 Signaling Protocol Framework ......................... 5 61 2.1 Endpoint Identification .............................. 5 62 2.2 Association of two LSPs as one Pseudowire ............ 6 63 2.3 Attachment Identifiers and Forwarders ................ 7 64 3 ..................................................... 9 65 4 ..................................................... 9 66 5 Applications ......................................... 9 67 5.1 Individual Point-to-Point VCs ........................ 9 68 5.1.1 Provisioning Models .................................. 9 69 5.1.1.1 Double Sided Provisioning ............................ 9 70 5.1.1.2 Single Sided Provisioning with Discovery ............. 9 71 5.1.2 Signaling ............................................ 10 72 5.2 Virtual Private LAN Service .......................... 11 73 5.2.1 Provisioning ......................................... 11 74 5.2.2 Auto-Discovery ....................................... 11 75 5.2.2.1 BGP-based auto-discovery ............................. 11 76 5.2.2.2 Radius-based auto-discovery .......................... 12 77 5.2.3 Signaling ............................................ 13 78 5.3 Colored Pools: Full Mesh of Point-to-Point VCs ....... 13 79 5.3.1 Provisioning ......................................... 13 80 5.3.2 Auto-Discovery ....................................... 14 81 5.3.2.1 BGP-based auto-discovery ............................. 14 82 5.3.2.2 Radius-based Auto-Discovery .......................... 15 83 5.3.3 Signaling ............................................ 15 84 5.4 Colored Pools: Partial Mesh .......................... 16 85 5.5 Distributed VPLS ..................................... 16 86 5.5.1 Signaling ............................................ 18 87 5.5.2 Provisioning and Discovery ........................... 19 88 5.5.3 Non-distributed VPLS as a sub-case ................... 20 89 5.5.4 Inter-Provider Application of Dist. VPLS Signaling ... 20 90 5.5.5 Splicing and the Data Plane .......................... 21 91 6 Security Considerations .............................. 22 92 7 Acknowledgments ...................................... 22 93 8 References ........................................... 22 94 9 Author's Information ................................. 23 96 1. Introduction 98 [PWE3-CONTROL] specifies a "signaling protocol" which uses extensions 99 of LDP [RFC 3036] to set up and maintain pseudowires [PWE3-FR, PWE3- 100 ARCH]. Like any protocol which sets up connections, the signaling 101 protocol provides a method by which each endpoint can identify the 102 other. [L2VPN-FW] describes a number of different ways in which sets 103 of pseudowires may be combined together into "Provider Provisioned 104 Layer 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of 105 different kinds of L2VPN. Different kinds of L2VPN may have 106 different "provisioning models", i.e., different models for what 107 information needs to be configured in what entities. Once configured, 108 the provisioning information is distributed by a "discovery process", 109 and once the information is discovered, the signaling protocol is 110 automatically invoked to set up the required pseudowires. The 111 semantics of the endpoint identifiers which the signaling protocol 112 uses for a particular type of L2VPN are determined by the 113 provisioning model. This document specifies a number of PPVPN 114 provisioning models, and specifies the semantic structure of the 115 endpoint identifiers required. It further specifies how the endpoint 116 identifiers are carried in the "Generalized Identifier FEC" of 117 [PWE3-CONTROL]. It is believed that the specified identifiers can 118 also be carried within the L2TP signaling protocol, though this is 119 currently not specified. 121 We make free use of terminology from [L2VPN-FW], [L2VPN-TERM], 122 [PWE3-ARCH] and [PWE3-FR], in particular the terms "Attachment 123 Circuit", "pseudowire", "PE", "CE". 125 Section 2 provides an overview of the relevant aspects of [PWE3- 126 CONTROL]. 128 Section 5 details various provisioning models and relates them to the 129 signaling process (using the Generalized Identifier FEC) and to the 130 discovery process. 132 We do not specify an auto-discovery procedure in this draft, but we 133 do specify the information which needs to be obtained via auto- 134 discovery in order for the signaling procedures to begin. The way in 135 which the LDP-based signaling mechanisms can be integrated with BGP- 136 based auto-discovery is covered in some detail. Later revisions of 137 this draft will provide equivalent detail for other discovery 138 mechanisms. 140 (Sections 3 and 4 don't exist, but section 5 retains the same section 141 number it had in previous versions as it has been referenced by 142 number during working group discussions.) 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 147 2. Signaling Protocol Framework 149 2.1. Endpoint Identification 151 Per [L2VPN-FW], a pseudowire can be thought of as a relationship 152 between a pair of "Forwarders". In simple instances of VPWS, a 153 Forwarder binds a pseudowire to a single Attachment Circuit, such 154 that frames received on the one are sent on the other, and vice 155 versa. In VPLS, a Forwarder binds a set of pseudowires to a set of 156 Attachment Circuits; when a frame is received from any member of that 157 set, a MAC address table is consulted (and various 802.1d procedures 158 executed) to determine the member or members of that set on which the 159 frame is to be transmitted. In more complex scenarios, Forwarders 160 may bind PWs to PWs, thereby "splicing" two PWs together; this is 161 needed, e.g., to support distributed VPLS. 163 In simple VPWS, where a Forwarder binds exactly one PW to exactly one 164 Attachment Circuit, a Forwarder can be identified by identifying its 165 Attachment Circuit. In simple VPLS, a Forwarder can be identified by 166 identifying its PE device and its VPN. 168 To set up a PW between a pair of Forwarders, the signaling protocol 169 must allow the Forwarder at one endpoint to identify the Forwarder at 170 the other. In [PWE3-CONTROL], the term "Attachment Identifier", or 171 "AI", to refer to a quantity whose purpose is to identify a 172 Forwarder. 174 [PWE3-CONTROL] specifies two FEC elements which can be used for when 175 setting up pseudowires, the PWid FEC element, and the Generalized Id 176 FEC element. The PWid FEC element carries only one Forwarder 177 identifier; it can be thus be used only when both forwarders have the 178 same identifier, and when that identifier can be coded as a 32-bit 179 quantity. The Generalized Id FEC element carries two Forwarder 180 identifiers, one for each of the two Forwarders being connected. 181 (The concept of carrying a local identifier and a remote identifier 182 is also used in the L2TP signaling proposal described in [LUO-L2TP].) 183 Each identifier is known as an Attachment Identifier, and a signaling 184 message carries both a "Source Attachment Identifier" (SAI) and a 185 "Target Attachment Identifier" (TAI). 187 The Generalized ID FEC element also provides some additional 188 structuring of the identifiers. It is assumed that the SAI and TAI 189 will sometimes have a common part, called the "Attachment Group 190 Identifier" (AGI), such that the SAI and TAI can each be thought of 191 as the concatenation of the AGI with an "Attachment Individual 192 Identifier" (AII). So the pair of identifiers is encoded into three 193 fields: AGI, Source AII (SAII), and Target AII (TAII). The SAI is 194 the concatenation of the AGI and the SAII, while the TAI is the 195 concatenation of the AGI and the TAII. This additional structuing 196 differs from the proposal in [LUO-L2TP], which specifies only that 197 there be two "endpoint identifiers". 199 It should be noted that while different forwarders support different 200 applications, the type of application (e.g., VPLS vs. VPWS) cannot 201 necessarily be inferred from the forwarders' identifiers. A router 202 receiving a signaling message with a particular TAI will have to be 203 able to determine which of its local forwarders is identified by that 204 TAI, and to determine the application provided by that forwarder. 205 But other nodes may not be able to infer the application simply by 206 inspection of the signaling messages. 208 2.2. Association of two LSPs as one Pseudowire 210 In any form of LDP-based signaling, each PW endpoint must initiate 211 the creation of a unidirectional LSP. A PW is a pair of such LSPs. 212 In most of the PPVPN provisioning models, the two endpoints of a 213 given PW can simultaneously initiate the signaling for it. They must 214 therefore have some way of determining when a given pair of LSPs are 215 intended to be associated together as a single PW. 217 The way in which this association is done is different for the 218 various different L2VPN services and provisioning models. The 219 details appear in later sections. 221 2.3. Attachment Identifiers and Forwarders 223 Every Forwarder in a PE must be associated with an Attachment 224 Identifier (AI), either through configuration or through some 225 algorithm. The Attachment Identifier must be unique in the context 226 of the PE router in which the Forwarder resides. The combination must be globally unique. 229 It is frequently convenient to a set of Forwarders as being members 230 of a particular "group", where PWs may only be set up among members 231 of a group. In such cases, it is convenient to identify the 232 Forwarders relative to the group, so that an Attachment Identifier 233 would consist of an Attachment Group Identifier (AGI) plus an 234 Attachment Individual Identifier (AII). 236 IT MUST BE UNDERSTOOD THAT THIS NOTION OF "GROUP" HAS NOTHING 237 WHATSOEVER TO DO WITH THE "GROUP ID" THAT IS PART OF THE PWID FEC IN 238 [PWE3-CONTROL]. 240 An Attachment Group Identifier may be thought of as a VPN-id, or 241 a VLAN identifier, some attribute which is shared by all the 242 Attachment VCs (or pools thereof) which are allowed to be connected. 244 The details for how to construct the AGI and AII fields identifying 245 the pseudowire endpoints in particular provisioning models are 246 discussed later in this paper. 248 We can now consider an LSP to be identified by: 250 , PE2, >, 252 and the LSP in the opposite direction will be identified by: 254 , PE1, >; 256 a pseudowire is a pair of such LSPs. 258 When a signaling message is sent from PE1 to PE2, and PE1 needs to 259 refer to an Attachment Identifier which has been configured on 260 one of its own Attachment VCs (or pools), the Attachment 261 Identifier is called a "Source Attachment Identifier". If PE1 262 needs to refer to an Attachment Identifier which has been 263 configured on one of PE2's Attachment VCs (or pools), the 264 Attachment Identifier is called a "Target Attachment Identifier". 265 (So an SAI at one endpoint is a TAI at the remote endpoint, and vice 266 versa.) 268 In the signaling protocol, we define encodings for the following 269 three fields: 271 - Attachment Group Identifier (AGI). 273 - Source Attachment Individual Identifier (SAII) 275 - Target Attachment Individual Identifier (TAII) 277 If the AGI is non-null, then the SAI consists of the AGI together 278 with the SAII, and the TAI consists of the TAII together with the 279 AGI. If the AGI is null, then the SAII and TAII are the SAI and TAI 280 respectively. 282 The intention is that the PE which receives a Label Mapping 283 Message containing a TAI will be able to map that TAI uniquely 284 to one of its Attachment VCs (or pools). The way in which a 285 PE maps a TAI to an Attachment VC (or pool) should be a 286 local matter. So as far as the signaling procedures are 287 concerned, the TAI is really just an arbitrary string of bytes, a 288 "cookie". 290 3. 292 4. 294 5. Applications 296 In this section, we specify the way in which the pseudowire signaling 297 using the Generalized ID FEC Element is applied for a number of 298 different applications. For some of the applications, we specify the 299 way in which different provisioning models can be used. However, 300 this is not meant to be an exhaustive list of the applications, or an 301 exhaustive list of the provisioning models that can be applied to 302 each application. 304 5.1. Individual Point-to-Point VCs 306 The signaling specified in this document can be used to set up 307 individually provisioned point-to-point pseudowires. In this 308 application, each Forwarder binds a single PW to a single Attachment 309 Circuit. Each PE must be provisioned with the necessary set of 310 Attachment Circuits, and then certain parameters must be provisioned 311 for each Attachment Circuit. 313 5.1.1. Provisioning Models 315 5.1.1.1. Double Sided Provisioning 317 In this model, the Attachment Circuit must be provisioned with a 318 local name, a remote PE address, and a remote name. During 319 signaling, the local name is sent as the SAII, the remote name as the 320 TAII, and the AGI is null. If two Attachment Circuits are to be 321 connected by a PW, the local name of each must be the remote name of 322 the other. 324 Note that if the local name and the remote name are the same, the 325 PWid FEC element can be used instead of the Generalized ID FEC 326 element. 328 5.1.1.2. Single Sided Provisioning with Discovery 330 In this model, each Attachment circuit must be provisioned with a 331 local name. The local name consists of a VPN-id (signaled as the 332 AGI) and an Attachment Individual Identifier which is unique relative 333 to the AGI. If two Attachment circuits are to be connected by a PW, 334 only one of them needs to be provisioned with a remote name (which of 335 course is the local name of the other Attachment Circuit). Neither 336 needs to be provisioned with the address of the remote PE, but both 337 must have the same VPN-id. 339 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 342 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 345 PE2. When signaling, it will use "fred" as the TAII, and will use V 346 as he AGI. A null SAII is sent. 348 The primary benefit of this provisioning model when compared to 349 Double Sided Provisioning is that it enables one to move an 350 Attachment Circuit from one PE to another without having to 351 reconfigure the remote endpoint. 353 5.1.2. Signaling 355 Signaling is as specified in section 4 above, with the addition of 356 the following: 358 When a PE receives a Label Mapping Message, and the TAI identifiers a 359 particular Attachment Circuit which is configured to be bound to a 360 point-to-point PW, then the following checks must be made. 362 If the Attachment Circuit is already bound to a pseudowire (including 363 the case where only one of the two LSPs currently exists), and the 364 remote endpoint is not PE1, then PE2 sends a Label Release message to 365 PE1, with a Status Code meaning "Attachment Circuit bound to 366 different PE", and the processing of the Mapping message is complete. 368 If the Attachment Circuit is already bound to a pseudowire (including 369 the case where only one of the two LSPs currently exists, but the AI 370 at PE1 is different than that specified in the AGI/SAII fields of the 371 Mapping message) then PE2 sends a Label Release message to PE1, with 372 a Status Code meaning "Attachment Circuit bound to different remote 373 Attachment Circuit", and the processing of the Mapping message is 374 complete. 376 These errors could occur as the result of misconfigurations. 378 5.2. Virtual Private LAN Service 380 In the VPLS application [L2VPN-REQ, VPLS], the Attachment Circuits 381 can be though of as LAN interfaces which attach to "virtual LAN 382 switches", or, in the terminology of [L2VPN-FW], "Virtual Switching 383 Instances" (VSIs). Each Forwarder is a VSI that attaches to a number 384 of PWs and a number of Attachment Circuits. The VPLS service 385 [L2VPN-REQ, VPLS] requires that a single pseudowire be created 386 between each pair of VSIs that are in the same VPLS. Each PE device 387 may have a multiple VSIs, where each VSI belongs to a different VPLS. 389 5.2.1. Provisioning 391 Each VPLS must have a globally unique identifier, which we call a 392 VPN-id. Every VSI must be configured with the VPN-id of the VPLS to 393 which it belongs. 395 Each VSI must also have a unique identifier, but this can be formed 396 automatically by concatenating its VPN-id with the IP address of its 397 PE router. 399 5.2.2. Auto-Discovery 401 5.2.2.1. BGP-based auto-discovery 403 The framework for BGP-based auto-discovery for a VPLS service is as 404 specified in [BGP-AUTO], section 3.2. 406 The AFI/SAFI used would be: 408 - An AFI specified by IANA for L2VPN. (This is the same for all 409 L2VPN schemes.) 411 - An SAFI specified by IANA specifically for a VPLS service whose 412 pseudowires are set up using the procedures described in the 413 current document. 415 In order to use BGP-based auto-discovery as specified in [BGP-AUTO], 416 the globally unique identifier associated with a VPLS must be 417 encodable as an 8-byte Route Distinguisher (RD). If the globally 418 unique identifier for a VPLS is an RFC2685 VPN-id, it can be encoded 419 as an RD as specified in [BGP-AUTO]. However, any other method of 420 assigning a unique identifier to a VPLS and encoding it as an RD 421 (using the encoding techniques of [RFC2547bis]) will do. 423 Each VSI needs to have a unique identifier, which can be encoded as a 424 BGP NLRI. This is formed by prepending the RD (from the previous 425 paragraph) to an IP address of the PE containing the virtual LAN 426 switch. 428 (Note that it is not strictly necessary for all the VSIs in the same 429 VPLS to have the same RD, all that is really necessary is that the 430 NLRI uniquely identify a virtual LAN switch.) 432 Each VSI needs to be associated with one or more Route Target (RT) 433 Extended Communities, as discussed in [BGP-AUTO}. These control the 434 distribution of the NLRI, and hence will control the formation of the 435 overlay topology of pseudowires that constitutes a particular VPLS. 437 Auto-discovery proceeds by having each PE distribute, via BGP, the 438 NLRI for each of its VSIs, with itself as the BGP next hop, and with 439 the appropriate RT for each such NLRI. Typically, each PE would be a 440 client of a small set of BGP route reflectors, which would 441 redistribute this information to the other clients. 443 If a PE has a VSI with a particular RT, it can then receive all the 444 NLRI which have that same RT, and from the BGP next hop attribute of 445 these NLRI will learn the IP addresses of the other PE routers which 446 have VSIs with the same RT. The considerations of [RFC2547bis] 447 section 4.3.3 on the use of route reflectors apply. 449 If a particular VPLS is meant to be a single fully connected LAN, all 450 its VSIs will have the same RT, in which case the RT could be (though 451 it need not be) an encoding of the VPN-id. If a particular VPLS 452 consists of multiple VLANs, each VLAN must have its own unique RT. A 453 VSI can be placed in multiple VLANS (or even in multiple VPLSes) by 454 assigning it multiple RTs. 456 Note that hierarchical VPLS can be set up by assigning multiple RTs 457 to some of the virtual LAN switches; the RT mechanism allows one to 458 have complete control over the pseudowire overlay which constitutes 459 the VPLS topology. 461 5.2.2.2. Radius-based auto-discovery 463 [RADIUS-L2TP-VPLS] includes a proposal for using RADIUS-based auto- 464 discovery. 466 5.2.3. Signaling 468 It is necessary to create Attachment Identifiers which identify the 469 VSIs. Given that each VPLS has at most one VSI per PE, and that only 470 one PW is permitted between any pair of VSIs, a VSI can be uniquely 471 identified (relative to its PE) by the VPN-id of its VPLS. Therefore 472 the signaling messages can encode the VPN-id in the AGI field, and 473 use the null values of the SAII and TAII fields. 475 The VPN-id may be encoded as an [RFC2547bis] RD, in which case the 476 AGI field consist of a length field of value 8, followed by the 8 477 bytes of the RD. If the VPN-id is an RFC2685 VPN-id, it should be 478 encoded as an RD (as specified in [BGP-AUTO]), and then the RD should 479 be carried in the AGI field. 481 If the VPN-id is an alphanumeric name, the first byte of the AGI 482 field (immediately following the length) will be 0x90. This 483 distinguishes it from any RD. The alphanumeric name itself then 484 follows. 486 Note that it is not possible using this technique to set up more than 487 one PW per pair of VSIs. 489 5.3. Colored Pools: Full Mesh of Point-to-Point VCs 491 In the "Colored Pools" model of operation, each PE may contain 492 several pools of Attachment Circuits, each pool associated with a 493 particular VPN. A PE may contain multiple pools per VPN, as each 494 pool may correspond to a particular CE device. It may be desired to 495 create one pseudowire between each pair of pools that are in the same 496 VPN; the result would be to create a full mesh of CE-CE VCs for each 497 VPN. (This application was originally suggested in [BGP-SIGNALING]; 498 we show here that it can be done with LDP-based signaling.) 500 5.3.1. Provisioning 502 Each pool is configured, and associated with: 504 - a set of Attachment Circuits; whether these Attachment Circuits 505 must themselves be provisioned, or whether they can be auto- 506 allocated as needed, is independent of and orthogonal to the 507 procedures described in this document; 509 - a "color", which can be thought of as a VPN-id of some sort; 511 - a relative pool identifier, which is unique relative to the 512 color. 514 The pool identifier, and color, taken together, constitute a globally 515 unique identifier for the pool. Thus if there are n pools of a given 516 color, their pool identifiers can be (though they do not need to be) 517 the numbers 1-n. 519 The semantics are that a pseudowire will be created between every 520 pair of pools that have the same color, where each such pseudowire 521 will be bound to one Attachment Circuit from each of the two pools. 523 If each pool is a set of Attachment Circuits leading to a single CE 524 device, then the layer 2 connectivity among the CEs is controlled by 525 the way the colors are assigned to the pools. To create a full mesh, 526 the "color" would just be a VPN-id. 528 Optionally, a particular Attachment Circuit may be configured with 529 the relative pool identifier of a remote pool. Then that Attachment 530 Circuit would be bound to a particular pseudowire only if that 531 pseudowire's remote endpoint is the pool with that relative pool 532 identifier. With this option, the same pairs of Attachment Circuits 533 will always be bound via pseudowires. 535 5.3.2. Auto-Discovery 537 5.3.2.1. BGP-based auto-discovery 539 The framework for BGP-based auto-discovery for a colored pool service 540 is as specified in [BGP-AUTO], section 3.2. 542 The AFI/SAFI used would be: 544 - An AFI specified by IANA for L2VPN. (This is the same for all 545 L2VPN schemes.) 547 - An SAFI specified by IANA specifically for a Colored Pool L2VPN 548 service whose pseudowires are set up using the procedures 549 described in the current document. 551 In order to use BGP-based auto-discovery, the color associated with a 552 colored pool must be encodable as both an RT (Route Target) and an RD 553 (Route Distinguisher). The globally unique identifier of a pool must 554 be encodable as NLRI; the color would be encoded as the RD and the 555 pool identifier as a four-byte quantity which is appended to the RD 556 to create the NLRI. 558 Auto-discovery procedures by having each PE distribute, via BGP, the 559 NLRI for each of its pools, with itself as the BGP next hop, and with 560 the RT that encodes the pool's color. If a given PE has a pool with 561 a particular color (RT), it must receive, via BGP, all NLRI with that 562 same color (RT). Typically, each PE would be a client of a small set 563 of BGP route reflectors, which would redistribute this information to 564 the other clients. 566 If a PE has a pool with a particular color, it can then receive all 567 the NLRI which have that same color, and from the BGP next hop 568 attribute of these NLRI will learn the IP addresses of the other PE 569 routers which have pools switches with the same color. It also 570 learns the unique identifier of each such remote pool, as this is 571 encoded in the NLRI. The remote pool's relative identifier can be 572 extracted from the NLRI and used in the signaling, as specified 573 below. 575 5.3.2.2. Radius-based Auto-Discovery 577 The use of Radius-based auto-discovery for the colored pool model of 578 operation is for further study. 580 5.3.3. Signaling 582 When a PE sends a Label Mapping message to set up a PW between two 583 pools, it encodes the color as the AGI, the local pool's relative 584 identifier as the SAII, and the remote pool's relative identifier as 585 the TAII. 587 When PE2 receives a Label Mapping message from PE1, and the TAI 588 identifies to a pool, and there is already an pseudowire connecting 589 an Attachment Circuit in that pool to an Attachment Circuit at PE1, 590 and the AI at PE1 of that pseudowire is the same as the SAI of the 591 Label Mapping message, then PE2 sends a Label Release message to PE1, 592 with a Status Code meaning "Attachment Circuit bound to different 593 remote Attachment Circuit". This prevents the creation of multiple 594 pseudowires between a given pair of pools. 596 Note that the signaling itself only identifies the remote pool to 597 which the pseudowire is to lead, not the remote Attachment Circuit 598 which is to be bound to the the pseudowire. However, the remote PE 599 may examine the SAII field to determine which Attachment Circuit 600 should be bound to the pseudowire. 602 5.4. Colored Pools: Partial Mesh 604 The procedures for creating a partial mesh of pseudowires among a set 605 of colored pools are substantially the same as those for creating a 606 full mesh, with the following exceptions: 608 - Each pool is optionally configured with a set of "import RTs" and 609 "export RTs"; 611 - During BGP-based auto-discovery, the pool color is still encoded 612 in the RD, but if the pool is configured with a set of "export 613 RTs", these are are encoded in the RTs of the BGP Update 614 messages, INSTEAD the color. 616 - If a pool has a particular "import RT" value X, it will create a 617 PW to every other pool which has X as one of its "export RTs". 618 The signaling messages and procedures themselves are as in 619 section 5.3.3 621 5.5. Distributed VPLS 623 In Distributed VPLS ([L2VPN-FW], [DTLS], [LPE]), the VPLS 624 functionality of a PE router is divided among two systems: a U-PE and 625 an N-PE. The U-PE sits between the user and the N-PE. VSI 626 functionality (e.g., MAC address learning and bridging) is performed 627 on the U-PE. A number of U-PEs attach to an N-PE. For each VPLS 628 supported by a U-PE, the U-PE maintains a pseudowire to each other 629 U-PE in the same VPLS. However, the U-PEs do not maintain signaling 630 control connections with each other. Rather, each U-PE has only a 631 single signaling connection, to its N-PE. In essence, each U-PE-to- 632 U-PE pseudowire is composed of three pseudowires spliced together: 633 one from U-PE to N-PE, one from N-PE to N-PE, and one from N-PE to 634 U-PE. 636 Consider for example the following topology: 638 U-PE A-----| |----U-PE C 639 | | 640 | | 641 N-PE E--------N-PE F 642 | | 643 | | 644 U-PE B-----| |-----U-PE D 646 where the four U-PEs are in a common VPLS. We now illustrate how PWs 647 get spliced together in the above topology in order to establish the 648 necessary PWs from U-PE A to the other U-PEs. 650 There are three PWs from A to E. Call these A-E/1, A-E/2, and A-E/3. 651 In order to connect A properly to the other U-PEs, there must be two 652 PWs from E to F (call these E-F/1 and E-F/2), one PW from E to B (E- 653 B/1), one from F to C (F-C/1), and one from F to D (F-D/1). 655 The N-PEs must then splice these pseudowires together to get the 656 equivalent of what the non-distributed VPLS signaling mechanism would 657 provide: 659 - PW from A to B: A-E/1 gets spliced to E-B/1. 661 - PW from A to C: A-E/2 gets spliced to E-F/1 gets spliced to F- 662 C/1. 664 - PW from A to D: A-E/3 gets spliced to E-F/2 gets spliced to F- 665 D/1. 667 It doesn't matter which PWs get spliced together, as long as the 668 result is one from A to each of B, C, and D. 670 Similarly, there are additional PWs which must get spliced together 671 to properly interconnect U-PE B with U-PEs C and D, and to 672 interconnect U-PE C with U-PE D. 674 One can see that distributed VPLS does not reduce the number of 675 pseudowires per U-PE, but it does reduce the number of control 676 connections per U-PE. Whether this is worthwhile depends, of course, 677 on what the bottleneck is. 679 5.5.1. Signaling 681 The signaling to support Distributed VPLS can be done with the 682 mechanisms described in this paper. However, the procedures for VPLS 683 (section 5.2.3) presuppose that, between a pair of PEs, there is only 684 one PW per VPLS. In distributed VPLS, this isn't so. In the 685 topology above, for example, there are two PWs between A and E for 686 the same VPLS. For distributed VPLS therefore, one cannot identify 687 the Forwarders merely by using the VPN-id as the AGI, while using 688 null values of the SAII and TAII. Rather, the SAII and TAII must be 689 used to identify particular U-PE devices. 691 At a given N-PE, the directly attached U-PEs in a given VPLS can be 692 numbered from 1 to n. This number identifies the U-PE relative to a 693 particular VPN-id and a particular PE. (That is, to uniquely 694 identify the U-PE, the N-PE, the VPN-id, and the U-PE number must be 695 known.) 697 As a result of configuration/discovery, each U-PE must be given a 698 list of pairs. Each element in this list tells the 699 U-PE to set up j PWs to the specified IP address. When the U-PE 700 signals to the N-PE, it sets the AGI to the proper-VPN-id, and sets 701 the SAII to the PW number, and sets the TAII to null. 703 In the above example, U-PE A would be told <3, E>, telling it to set 704 up 3 PWs to E. When signaling, A would set the AGI to the proper 705 VPN-id, and would set the SAII to 1, 2, or 3, depending on which of 706 the three PWs it is signaling. 708 As a result of configuration/discovery, each N-PE must be given the 709 following information for each VPLS: 711 - A "Local" list: {}, where each element tells it to 712 set up j PWs to the locally attached U-PE at the specified 713 address. The number of elements in this list will be n, the 714 number of locally attached U-PEs in this VPLS. In the above 715 example, E would be given the local list: {<3, A>, <3, B>}, 716 telling it to set up 3 PWs to A and 3 to B. 718 - A local numbering, relative to the particular VPLS and the 719 particular N-PE, of its U-PEs. In the above example, E could be 720 told that U-PE A is 1, and U-PE B is 2. 722 - A "Remote" list: {}, telling it to set up k PWs, 723 for each U-PE, to the specified IP address. Each of these IP 724 addresses identifies a N-PE, and k specifies the number of U-PEs 725 at that N-PE which are in the VPLS. In the above example, E 726 would be given the remote list: {<2, F>}. Since N-PE E has two 727 U-PEs, this tells it to set up 4 PWs to N-PE F, 2 for each of its 728 E's U-PEs. 730 The signaling of a PW from N-PE to U-PE is based on the local list 731 and the local numbering of U-PEs. When signaling a particular PW 732 from an N-PE to a U-PE, the AGI is set to the proper VPN-id, and SAII 733 is set to null, and the TAII is set to the PW number (relative to 734 that particular VPLS and U-PE). In the above example, when E signals 735 to A, it would set the TAII to be 1, 2, or 3, respectively, for the 736 three PWs it must set up to A. It would similarly signal three PWs 737 to B. 739 The LSP signaled from U-PE to N-PE is associated with an LSP from N- 740 PE to U-PE in the usual manner, as specified in section 4. A PW 741 between a U-PE and an N-PE is known as a "U-PW". 743 The signaling of a PW from N-PE to N-PE is based on the remote list. 744 When signaling a particular PW from an N-PE to an N-PE, the AGI is 745 set to the appropriate VPN-id. The remote list specifies the number 746 of PWs to set up, per local U-PE, to a particular remote N-PE. If 747 there are n such PWs, they are distinguished by the setting of the 748 TAII, which will be a number from 1 to n inclusive. The SAII is set 749 to the local number of the U-PE. In the above example, E would set 750 up 4 PWs to F. The SAII/TAII fields would be set to 1/1, 1/2, 2/1, 751 and 2/2 respectively. A PW between two N-PEs is known as an "N-PW". 753 Each U-PW must be "spliced" to an N-PW. This is based on the remote 754 list. If the remote list contains an element , then i U-PWs 755 from each local U-PE must be spliced to i N-PWs from the remote N-PE 756 F. It does not matter which U-PWs are spliced to which N-PWs, as 757 long as this constraint is met. 759 If an N-PE has more than one local U-PE for a given VPLS, it must 760 also ensure that a U-PW from each such U-PE is spliced to a U-PW 761 from each of the other U-PEs. 763 5.5.2. Provisioning and Discovery 765 Every N-PE must be provisioned with the set of VPLS instances it 766 supports, a VPN-id for each one, and a list of local U-PEs for each 767 such VPLS. As part of the discovery procedure, the N-PE advertises 768 the number of U-PEs for each VPLS. 770 Auto-discovery (e.g., BGP-based) can be used to discover all the 771 other N-PEs in the VPLS, and for each, the number of U-PEs local to 772 that N-PE. From this, one can compute the total number of U-PEs in 773 the VPLS. This information is sufficient to enable one to compute 774 the local list and the remote list for each N-PE. 776 5.5.3. Non-distributed VPLS as a sub-case 778 A PE which is providing "non-distributed VPLS" (i.e., a PE which 779 peforms both the U-PE and N-PE functions) can interoperate with N- 780 PE/U-PE pairs that are providing distributed VPLS. The "non- 781 distributed PE" simply advertises, in the discovery procedure, that 782 it has one local U-PE per VPLS. And of course, the non-distributed 783 PE does no splicing. 785 If every PE in a VPLS is providing non-distributed VPLS, and thus 786 every PE advertises itself as an N-PE with one local U-PE, the 787 resultant signaling is exactly the same as that specified in section 788 5.2.3 above, except that SAII and TAII values of 1 are used instead 789 of SAII and TAII values of null. (A PE providing non-distributed 790 VPLS should therefore treat AII values of 1 the same as it treats AII 791 values of null.) 793 5.5.4. Inter-Provider Application of Dist. VPLS Signaling 795 Consider the following topology: 797 PE A ---- Network 1 ----- Border ----- Border ----- Network 2 ---- PE B 798 Router 12 Router 21 | 799 | 800 PE C 802 where A, B, and C are PEs in a common VPLS, but Networks 1 and 2 are 803 networks of different Service Providers. Border Router 12 is 804 Network 1's border router to network 2, and Border Router 21 is 805 Network 2's border router to Network 1. We suppose further that the 806 PEs are not "distributed", i.e, that each provides both the U-PE and 807 N-PE functions. 809 In this topology, one needs two inter-provider pseudowires: A-B and 810 A-C. 812 Suppose a Service Provider decides, for whatever reason, that it does 813 not want each of its PEs to have a control connection to any PEs in 814 the other network. Rather, it wants the inter-provider control 815 connections to run only between the two border routers. 817 This can be achieved using the techniques of section 5.5, where the 818 PEs behave like U-PEs, and the BRs behave like N-PEs. In the example 819 topology, PE A would behave like a U-PE which is locally attached to 820 BR12; PEs B and C would be have like U-PEs which are locally attached 821 to BR21; and the two BRs would behave like N-PEs. 823 As a result, the PW from A to B would consist of three segments: A- 824 BR12, BR12-BR21, and BR21-B. The border routers would have to splice 825 the corresponding segments together. 827 This requires the PEs within a VPLS to be numbered from 1-n (relative 828 to that VPLS) within a given network. 830 5.5.5. Splicing and the Data Plane 832 Splicing two PWs together is quite straightforward in the MPLS data 833 plane, as moving a packet from one PW directly to another is just a 834 label replace operation on the PW label. When a PW consists of two 835 PWs spliced together, it is assumed that the data will go to the node 836 where the splicing is being done, i.e., that the data path will 837 include the control points. 839 In some cases, it may be desired to have the data go on a more direct 840 route from one "true endpoint" to another, without necessarily 841 passing through the splice points. This could be done by means of a 842 new LDP TLV carried in the LDP mapping message; call it the "direct 843 route" TLV. A direct route TLV would be placed in an LDP Label 844 Mapping message by the LSP's "true endpoint". The TLV would specify 845 the IP address of the true endpoint, and would also specify a label, 846 representing the pseudowire, which is assigned by that endpoint. 847 When PWs are spliced together at intermediate control points, this 848 TLV would simply be passed upstream. Then when a frame is first put 849 on the pseudowire, it can be given this pseudowire label, and routed 850 to the true endpoint, thereby possibly bypassing the intermediate 851 control points. 853 6. Security Considerations 855 Each L2VPN service has its own set of security considerations, and 856 each signaling mechanism used for L2VPN has its own set of security 857 considerations. The semantics of the identifiers used in the 858 signaling protocols does not pose any additional security 859 considerations. The choice of provisioning model also does not 860 impose any security considerations, except insofar as the associated 861 auto-discovery and signaling procedures may have security 862 considerations. 864 7. Acknowledgments 866 Thanks to Dan Tappan, Ted Qian, Bruce Davie, Ali Sajassi, Wei Luo, 867 Skip Booth, and Francois LeFaucheur for their comments, criticisms, 868 and helpful suggestions. 870 Thanks to Tissa Senevirathne, Hamid Ould-Brahim and Yakov Rekhter for 871 discussing the auto-discovery issues. 873 Thanks to Vach Kompella and Wei Luo for a continuing discussion of 874 the proper semantics of the generalized identifiers. 876 8. References 878 [BGP-AUTO] "Using BGP as an Auto-Discovery Mechanism for Network- 879 based VPNs", Ould-Brahim et. al., draft-ietf-ppvpn-bgpvpn-auto- 880 03.txt, Aug 2002. 882 [BGP-SIGNALING] "Layer 2 VPNs over Tunnels", Kompella et. al., 883 draft-kompella-ppvpn-l2vpn-03.txt, Apr 2003 885 [RADIUS-L2TP-VPLS] "Radius/L2TP Based VPLS", Heinanen, draft- 886 heinanen-radius-l2tp-vpls-00.txt, Feb 2003 888 [L2VPN-FW] "PPVPN L2 Framework", Andersson et. al., draft-ietf- 889 ppvpn-l2-framework-03.txt, Mar 2003 891 [L2VPN-REQ] "Service Requirements for Layer 2 Provider Provisioned 892 Virtual Private Network Services", Augustyn, Serbest, et. al., 893 draft-augustyn-ppvpn-l2vpn-requirements-02.txt, Feb 2003 895 [L2VPN-TERM] "PPVPN Terminology", Andersson, Madsen, draft- 896 andersson-ppvpn-terminology-02.txt, Nov 2002 898 [LDP] "LDP Specification", Andersson, et. al., RFC 3036, Jan 2001 900 [LUO-L2TP] "L2VPN Signaling Using L2TPv3", Luo, draft-luo-l2tpext- 901 l2vpn- signaling-01.txt, Feb 2003 903 [PWE3-ARCH] "PWE3 Architecture", Bryant, Pate, et. al., draft-ietf- 904 pwe3-arch-02.txt, Feb 2003 906 [PWE3-CONTROL] "Pseudowire Setup and Maintenance using LDP", Martini, 907 et. al., draft-ietf-pwe3-control-protocol-02.txt, Feb. 2003 909 [PWE3-FR] "Framework for Pseudo Wire Emulation Edge-to-Edge ", 910 draft-ietf=pwe3-framework-01.txt, May 2002 912 [RFC2547bis], "BGP/MPLS VPNs", Rosen, Rekhter, et. al., draft-ietf- 913 ppvpn-rfc2547bis-04.txt, Apr 2003 915 [RFC2685] "Virtual Private Networks Identifier", Fox, Gleeson, 916 September 1999 918 [RFC3036] "LDP Specification", January 2001 920 [VPLS] "Transparent VLAN Services over MPLS", Laserre, et. al., 921 draft-lasserre-vkompella-ppvpn-vpls-04.txt, Mar 2003 923 9. Author's Information 925 Eric C. Rosen 926 Cisco Systems, Inc. 927 250 Apollo Drive 928 Chelmsford, MA, 01824 930 E-mail: erosen@cisco.com