idnits 2.17.1 draft-ietf-l2vpn-signaling-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1184. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1161. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1168. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1174. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 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 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 295: '... IT MUST BE UNDERSTOOD THAT THIS NOT...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 212 has weird spacing: '...warders being...' == Line 292 has weird spacing: '...sist of an At...' == Line 299 has weird spacing: '...ntifier may b...' == Line 300 has weird spacing: '...r, some attri...' == Line 319 has weird spacing: '...r which has ...' == (7 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 (February 19, 2005) is 7000 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DTLS' is mentioned on line 716, but not defined == Missing Reference: 'LPE' is mentioned on line 716, but not defined == Missing Reference: '2547bis' is mentioned on line 1058, but not defined == Missing Reference: 'L2VPN-REQS' is mentioned on line 1054, but not defined == Unused Reference: 'RFC2685' is defined on line 1111, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-l3vpn-bgpvpn-auto-05 ** Downref: Normative reference to an Informational draft: draft-ietf-l3vpn-bgpvpn-auto (ref. 'BGP-AUTO') == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-14 == Outdated reference: A later version (-07) exists of draft-ietf-l2tpext-l2vpn-01 ** 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-02 ** Downref: Normative reference to an Informational draft: draft-ietf-l2vpn-requirements (ref. 'L2VPN-REQ') ** Downref: Normative reference to an Informational draft: draft-ietf-l3vpn-ppvpn-terminology (ref. 'L2VPN-TERM') ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) ** 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-14 == Outdated reference: A later version (-03) exists of draft-martini-pwe3-pw-switching-01 -- Possible downref: Normative reference to a draft: ref. 'PW-SWITCH' == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-rfc2547bis-02 == Outdated reference: A later version (-09) exists of draft-ietf-l2vpn-vpls-ldp-05 Summary: 15 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 E. Rosen 3 Internet-Draft W. Luo 4 Expires: August 23, 2005 B. Davie 5 Cisco Systems, Inc. 6 V. Radoaca 7 Nortel Networks 8 February 19, 2005 10 Provisioning Models and Endpoint Identifiers in L2VPN Signaling 11 draft-ietf-l2vpn-signaling-03.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 23, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 There are a number of different kinds of "Provider Provisioned Layer 47 2 VPNs" (L2VPNs). The different kinds of L2VPN may have different 48 "provisioning models", i.e., different models for what information 49 needs to be configured in what entities. Once configured, the 50 provisioning information is distributed by a "discovery process". 51 When the discovery process is complete, a signaling protocol is 52 automatically invoked. The signaling protocol sets up the mesh of 53 Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. Any 54 PW signaling protocol needs to have a method which allows each PW 55 endpoint to identify the other; thus a PW signaling protocol will 56 have the notion of an endpoint identifier. The semantics of the 57 endpoint identifiers which the signaling protocol uses for a 58 particular type of L2VPN are determined by the provisioning model. 59 This document specifies a number of L2VPN provisioning models, and 60 further specifies the semantic structure of the endpoint identifiers 61 required by each provisioning model. It discusses the way in which 62 the endpoint identifiers are distributed by the discovery process, 63 especially when the discovery process is based upon the Border 64 Gateway Protocol (BGP). It then specifies how the endpoint 65 identifiers are carried in the two signaling protocols that are used 66 to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2 67 Tunneling Protocol (L2TPv3). 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Signaling Protocol Framework . . . . . . . . . . . . . . . . . 6 74 2.1 Endpoint Identification . . . . . . . . . . . . . . . . . 6 75 2.2 Creating a Single Bidirectional Pseudowire . . . . . . . . 7 76 2.3 Attachment Identifiers and Forwarders . . . . . . . . . . 8 78 3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.1 Individual Point-to-Point VCs . . . . . . . . . . . . . . 10 80 3.1.1 Provisioning Models . . . . . . . . . . . . . . . . . 10 81 3.1.1.1 Double Sided Provisioning . . . . . . . . . . . . 10 82 3.1.1.2 Single Sided Provisioning with Discovery . . . . . 10 83 3.1.2 Signaling . . . . . . . . . . . . . . . . . . . . . . 11 84 3.2 Virtual Private LAN Service . . . . . . . . . . . . . . . 12 85 3.2.1 Provisioning . . . . . . . . . . . . . . . . . . . . . 12 86 3.2.2 Auto-Discovery . . . . . . . . . . . . . . . . . . . . 12 87 3.2.2.1 BGP-based auto-discovery . . . . . . . . . . . . . 12 88 3.2.3 Signaling . . . . . . . . . . . . . . . . . . . . . . 14 89 3.2.4 Pseudowires as VPLS Attachment Circuits . . . . . . . 14 90 3.3 Colored Pools: Full Mesh of Point-to-Point VCs . . . . . . 14 91 3.3.1 Provisioning . . . . . . . . . . . . . . . . . . . . . 15 92 3.3.2 Auto-Discovery . . . . . . . . . . . . . . . . . . . . 15 93 3.3.2.1 BGP-based auto-discovery . . . . . . . . . . . . . 15 94 3.3.3 Signaling . . . . . . . . . . . . . . . . . . . . . . 16 95 3.4 Colored Pools: Partial Mesh . . . . . . . . . . . . . . . 17 96 3.5 Distributed VPLS . . . . . . . . . . . . . . . . . . . . . 17 97 3.5.1 Signaling . . . . . . . . . . . . . . . . . . . . . . 18 98 3.5.2 Provisioning and Discovery . . . . . . . . . . . . . . 20 99 3.5.3 Non-distributed VPLS as a sub-case . . . . . . . . . . 20 100 3.5.4 Splicing and the Data Plane . . . . . . . . . . . . . 21 102 4. Inter-AS Operation . . . . . . . . . . . . . . . . . . . . . . 22 103 4.1 Multihop EBGP redistribution of L2VPN NLRIs . . . . . . . 22 104 4.2 EBGP redistribution of L2VPN NLRIs with Pseudowire 105 Switching . . . . . . . . . . . . . . . . . . . . . . . . 22 106 4.3 Inter-Provider Application of Dist. VPLS Signaling . . . . 23 108 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 110 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 112 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 116 Intellectual Property and Copyright Statements . . . . . . . . 29 118 1. Introduction 120 [L2VPN-FW] describes a number of different ways in which sets of 121 pseudowires may be combined together into "Provider Provisioned Layer 122 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of different 123 kinds of L2VPN. Different kinds of L2VPN may have different 124 "provisioning models", i.e., different models for what information 125 needs to be configured in what entities. Once configured, the 126 provisioning information is distributed by a "discovery process", and 127 once the information is discovered, the signaling protocol is 128 automatically invoked to set up the required pseudowires. The 129 semantics of the endpoint identifiers which the signaling protocol 130 uses for a particular type of L2VPN are determined by the 131 provisioning model. That is, different kinds of L2VPN, with 132 different provisioning models, require different kinds of endpoint 133 identifiers. This document specifies a number of PPVPN provisioning 134 models, and specifies the semantic structure of the endpoint 135 identifiers required for each provisioning model. 137 Either LDP (as specified in [LDP] and extended in [PWE3-CONTROL]) or 138 L2TP version 3 (as specified in [L2TP-BASE] and extended in 139 [L2TP-L2VPN]) can be used as signaling protocols to set up and 140 maintain pseudowires (PWs) [PWE3-ARCH]. Any protocol which sets up 141 connections must provide a way for each endpoint of the connection to 142 identify the other; each PW signaling protocol thus provides a way to 143 identify the PW endpoints. Since each signaling protocol needs to 144 support all the different kinds of L2VPN and provisioning models, the 145 signaling protocol must have a very general way of representing 146 endpoint identifiers, and it is necessary to specify rules for 147 encoding each particular kind of endpoint identifier into the 148 relevant fields of each signaling protocol. This document specifies 149 how to encode the endpoint identifiers of each provisioning model 150 into the LDP and L2TPv3 signaling protocols. 152 We make free use of terminology from [L2VPN-FW], [L2VPN-TERM], and 153 [PWE3-ARCH], in particular the terms "Attachment Circuit", 154 "pseudowire", "PE", "CE". 156 Section 2 provides an overview of the relevant aspects of 157 [PWE3-CONTROL] and [L2TP-L2VPN]. 159 Section 3 details various provisioning models and relates them to the 160 signaling process and to the discovery process. 162 Section 4 explains how the procedures for discovery and signaling can 163 be applied in a multi-AS environment and outlines several options for 164 the establishment of multi-AS L2VPNs. 166 We do not specify an auto-discovery procedure in this draft, but we 167 do specify the information which needs to be obtained via 168 auto-discovery in order for the signaling procedures to begin. The 169 way in which the signaling mechanisms can be integrated with 170 BGP-based auto-discovery is covered in some detail. 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 176 2. Signaling Protocol Framework 178 2.1 Endpoint Identification 180 Per [L2VPN-FW], a pseudowire can be thought of as a relationship 181 between a pair of "Forwarders". In simple instances of VPWS, a 182 Forwarder binds a pseudowire to a single Attachment Circuit, such 183 that frames received on the one are sent on the other, and vice 184 versa. In VPLS, a Forwarder binds a set of pseudowires to a set of 185 Attachment Circuits; when a frame is received from any member of that 186 set, a MAC address table is consulted (and various 802.1d procedures 187 executed) to determine the member or members of that set on which the 188 frame is to be transmitted. In more complex scenarios, Forwarders 189 may bind PWs to PWs, thereby "splicing" two PWs together; this is 190 needed, e.g., to support distributed VPLS and some inter-AS 191 scenarios. 193 In simple VPWS, where a Forwarder binds exactly one PW to exactly one 194 Attachment Circuit, a Forwarder can be identified by identifying its 195 Attachment Circuit. In simple VPLS, a Forwarder can be identified by 196 identifying its PE device and its VPN. 198 To set up a PW between a pair of Forwarders, the signaling protocol 199 must allow the Forwarder at one endpoint to identify the Forwarder at 200 the other. In [PWE3-CONTROL], the term "Attachment Identifier", or 201 "AI", to refer to a quantity whose purpose is to identify a 202 Forwarder. In [L2TP-L2VPN], the term "Forwarder Identifier" is used 203 for the same purpose. In the context of this document, "Attachment 204 Identifier" and "Forwarder Identifier" are used interchangably. 206 [PWE3-CONTROL] specifies two FEC elements which can be used for when 207 setting up pseudowires, the PWid FEC element, and the Generalized Id 208 FEC element. The PWid FEC element carries only one Forwarder 209 identifier; it can be thus be used only when both forwarders have the 210 same identifier, and when that identifier can be coded as a 32-bit 211 quantity. The Generalized Id FEC element carries two Forwarder 212 identifiers, one for each of the two Forwarders being connected. 213 Each identifier is known as an Attachment Identifier, and a signaling 214 message carries both a "Source Attachment Identifier" (SAI) and a 215 "Target Attachment Identifier" (TAI). 217 The Generalized ID FEC element also provides some additional 218 structuring of the identifiers. It is assumed that the SAI and TAI 219 will sometimes have a common part, called the "Attachment Group 220 Identifier" (AGI), such that the SAI and TAI can each be thought of 221 as the concatenation of the AGI with an "Attachment Individual 222 Identifier" (AII). So the pair of identifiers is encoded into three 223 fields: AGI, Source AII (SAII), and Target AII (TAII). The SAI is 224 the concatenation of the AGI and the SAII, while the TAI is the 225 concatenation of the AGI and the TAII. 227 Similarly, [L2TP-L2VPN] allows using one or two Forwarder Identifiers 228 to set up pseudowires. If only the target Forwarder Identifier is 229 used in L2TP signaling messages, both the source and target 230 Forwarders are assumed to have the same value. If both the source 231 and target Forwarder Identifiers are carried in L2TP signaling 232 messages, each Forwarder uses a locally significant identifier value. 234 The Forwarder Identifier in [L2TP-L2VPN] is an equivalent term as 235 Attachment Identifier in [PWE3-CONTROL]. A Forwarder Identifier also 236 consists of an Attachment Group Identifier and an Attachment 237 Individual Identifier. Unlike the Generalized ID FEC element, the 238 AGI and AII are carried in distinct L2TP Attribute-Value-Pairs 239 (AVPs). The AGI is encoded in the AGI AVP, and the SAII and TAII are 240 encoded in the Local End ID AVP and the Remote End ID AVP 241 respectively. The source Forwarder Identifier is the concatenation 242 of the AGI and SAII, while the target Forwarder Identifier is the 243 concatenation of the AGI and TAII. 245 In applications that group sets of PWs into "Layer 2 Virtual Private 246 Networks", the AGI can be thought of as a "VPN Identifier". 248 It should be noted that while different forwarders support different 249 applications, the type of application (e.g., VPLS vs. VPWS) cannot 250 necessarily be inferred from the forwarders' identifiers. A router 251 receiving a signaling message with a particular TAI will have to be 252 able to determine which of its local forwarders is identified by that 253 TAI, and to determine the application provided by that forwarder. 254 But other nodes may not be able to infer the application simply by 255 inspection of the signaling messages. 257 2.2 Creating a Single Bidirectional Pseudowire 259 In any form of LDP-based signaling, each PW endpoint must initiate 260 the creation of a unidirectional LSP. A PW is a pair of such LSPs. 261 In most of the PPVPN provisioning models, the two endpoints of a 262 given PW can simultaneously initiate the signaling for it. They must 263 therefore have some way of determining when a given pair of LSPs are 264 intended to be associated together as a single PW. 266 The way in which this association is done is different for the 267 various different L2VPN services and provisioning models. The 268 details appear in later sections. 270 L2TP signaling inherently establishes a bidirectional session that 271 carries a PW between two PW endpoints. The two endpoints can also 272 simultaneously initiate the signaling for a given PW. It is possible 273 that two PWs can be established for a pair of Forwarders. 275 In order to avoid setting up duplicated pseudowires between two 276 Forwarders, each PE must be able to independently detect such a 277 pseudowire tie. The procedures of detecting a pseudowire tie is 278 described in [L2TP-L2VPN] 280 2.3 Attachment Identifiers and Forwarders 282 Every Forwarder in a PE must be associated with an Attachment 283 Identifier (AI), either through configuration or through some 284 algorithm. The Attachment Identifier must be unique in the context 285 of the PE router in which the Forwarder resides. The combination must be globally unique. 288 It is frequently convenient to a set of Forwarders as being members 289 of a particular "group", where PWs may only be set up among members 290 of a group. In such cases, it is convenient to identify the 291 Forwarders relative to the group, so that an Attachment Identifier 292 would consist of an Attachment Group Identifier (AGI) plus an 293 Attachment Individual Identifier (AII). 295 IT MUST BE UNDERSTOOD THAT THIS NOTION OF "GROUP" HAS NOTHING 296 WHATSOEVER TO DO WITH THE "GROUP ID" THAT IS PART OF THE PWID FEC IN 297 [PWE3-CONTROL]. 299 An Attachment Group Identifier may be thought of as a VPN-id, or 300 a VLAN identifier, some attribute which is shared by all the 301 Attachment VCs (or pools thereof) which are allowed to be connected. 303 The details for how to construct the AGI and AII fields identifying 304 the pseudowire endpoints in particular provisioning models are 305 discussed later in this paper. 307 We can now consider an LSP to be identified by: 309 o , PE2, > 311 and the LSP in the opposite direction will be identified by: 313 o , PE1, > 315 A pseudowire is a pair of such LSPs. In the case of using L2TP 316 signaling, these refer to the two directions of an L2TP session. 318 When a signaling message is sent from PE1 to PE2, and PE1 needs to 319 refer to an Attachment Identifier which has been configured on 320 one of its own Attachment VCs (or pools), the Attachment 321 Identifier is called a "Source Attachment Identifier". If PE1 322 needs to refer to an Attachment Identifier which has been 323 configured on one of PE2's Attachment VCs (or pools), the 324 Attachment Identifier is called a "Target Attachment Identifier". 325 (So an SAI at one endpoint is a TAI at the remote endpoint, and vice 326 versa.) 328 In the signaling protocol, we define encodings for the following 329 three fields: 331 o Attachment Group Identifier (AGI) 333 o Source Attachment Individual Identifier (SAII) 335 o Target Attachment Individual Identifier (TAII) 337 If the AGI is non-null, then the SAI consists of the AGI together 338 with the SAII, and the TAI consists of the TAII together with the 339 AGI. If the AGI is null, then the SAII and TAII are the SAI and TAI 340 respectively. 342 The intention is that the PE which receives an LDP Label Mapping 343 message or an L2TP Incoming Call Request (ICRQ) message containing a 344 TAI will be able to map that TAI uniquely to one of its Attachment 345 VCs (or pools). The way in which a PE maps a TAI to an Attachment 346 VC (or pool) should be a local matter. So as far as the signaling 347 procedures are concerned, the TAI is really just an arbitrary string 348 of bytes, a "cookie". 350 3. Applications 352 In this section, we specify the way in which the pseudowire signaling 353 using the notion of source and target Forwarder is applied for a 354 number of different applications. For some of the applications, we 355 specify the way in which different provisioning models can be used. 356 However, this is not meant to be an exhaustive list of the 357 applications, or an exhaustive list of the provisioning models that 358 can be applied to each application. 360 3.1 Individual Point-to-Point VCs 362 The signaling specified in this document can be used to set up 363 individually provisioned point-to-point pseudowires. In this 364 application, each Forwarder binds a single PW to a single Attachment 365 Circuit. Each PE must be provisioned with the necessary set of 366 Attachment Circuits, and then certain parameters must be provisioned 367 for each Attachment Circuit. 369 3.1.1 Provisioning Models 371 3.1.1.1 Double Sided Provisioning 373 In this model, the Attachment Circuit must be provisioned with a 374 local name, a remote PE address, and a remote name. During 375 signaling, the local name is sent as the SAII, the remote name as the 376 TAII, and the AGI is null. If two Attachment Circuits are to be 377 connected by a PW, the local name of each must be the remote name of 378 the other. 380 Note that if the local name and the remote name are the same, the 381 PWid FEC element can be used instead of the Generalized ID FEC 382 element in the LDP based signaling. 384 With L2TP signaling, the local name is sent in Local End ID AVP, the 385 remote name in Remote End ID AVP. The AGI AVP is optional. If 386 present, it contains a zero-length AGI value. If the local name and 387 the remote name are the same, Local End ID AVP can be omitted from 388 L2TP signaling messages. 390 3.1.1.2 Single Sided Provisioning with Discovery 392 In this model, each Attachment Circuit must be provisioned with a 393 local name. The local name consists of a VPN-id (signaled as the 394 AGI) and an Attachment Individual Identifier which is unique relative 395 to the AGI. If two Attachment circuits are to be connected by a PW, 396 only one of them needs to be provisioned with a remote name (which of 397 course is the local name of the other Attachment Circuit). Neither 398 needs to be provisioned with the address of the remote PE, but both 399 must have the same VPN-id. 401 As part of an auto-discovery procedure, each PE advertises its 402 pairs. Each PE compares its local pairs with the pairs advertised by 404 the other PEs. If PE1 has a local pair with 405 value , and PE2 has a local pair with 406 value , PE1 will thus be able to discover that it needs to 407 connect to PE2. When signaling, it will use "fred" as the TAII, and 408 will use V as he AGI. PE1's local name for the Attachment Circuit is 409 sent as the SAII. 411 The primary benefit of this provisioning model when compared to 412 Double Sided Provisioning is that it enables one to move an 413 Attachment Circuit from one PE to another without having to 414 reconfigure the remote endpoint. 416 3.1.2 Signaling 418 The LDP-based signaling is as specified in [PWE3-CONTROL], with the 419 addition of the following: 421 When a PE receives a Label Mapping Message, and the TAI identifies a 422 particular Attachment Circuit which is configured to be bound to a 423 point-to-point PW, then the following checks must be made. 425 If the Attachment Circuit is already bound to a pseudowire (including 426 the case where only one of the two LSPs currently exists), and the 427 remote endpoint is not PE1, then PE2 sends a Label Release message to 428 PE1, with a Status Code meaning "Attachment Circuit bound to 429 different PE", and the processing of the Mapping message is complete. 431 If the Attachment Circuit is already bound to a pseudowire (including 432 the case where only one of the two LSPs currently exists), but the AI 433 at PE1 is different than that specified in the AGI/SAII fields of the 434 Mapping message then PE2 sends a Label Release message to PE1, with a 435 Status Code meaning "Attachment Circuit bound to different remote 436 Attachment Circuit", and the processing of the Mapping message is 437 complete. 439 Similarly with the L2TP-based signaling, when a PE receives an ICRQ 440 message, and the TAI identifies a particular Attachment Circuit which 441 is configured to be bound to a point-to-point PW, it performs the 442 following checks. 444 If the Attachment Circuit is already bound to a pseudowire, and the 445 remote endpoint is not PE1, then PE2 sends a Call Disconnect Notify 446 (CDN) message to PE1, with a Status Code meaning "Attachment Circuit 447 bound to different PE", and the processing of the ICRQ message is 448 complete. 450 If the Attachment Circuit is already bound to a pseudowire, but the 451 pseudowire is bound to a Forwarder on PE1 with the AI different than 452 that specified in the SAI fields of the ICRQ message, then PE2 sends 453 a CDN message to PE1, with a Status Code meaning "Attachment Circuit 454 bound to different remote Attachment Circuit", and the processing of 455 the ICRQ message is complete. 457 These errors could occur as the result of misconfigurations. 459 3.2 Virtual Private LAN Service 461 In the VPLS application [L2VPN-REQ, VPLS], the Attachment Circuits 462 can be though of as LAN interfaces which attach to "virtual LAN 463 switches", or, in the terminology of [L2VPN-FW], "Virtual Switching 464 Instances" (VSIs). Each Forwarder is a VSI that attaches to a number 465 of PWs and a number of Attachment Circuits. The VPLS service 466 [L2VPN-REQ, VPLS] requires that a single pseudowire be created 467 between each pair of VSIs that are in the same VPLS. Each PE device 468 may have a multiple VSIs, where each VSI belongs to a different VPLS. 470 3.2.1 Provisioning 472 Each VPLS must have a globally unique identifier, which we call a 473 VPN-id. Every VSI must be configured with the VPN-id of the VPLS to 474 which it belongs. 476 Each VSI must also have a unique identifier, but this can be formed 477 automatically by concatenating its VPN-id with the IP address of its 478 PE router. 480 3.2.2 Auto-Discovery 482 3.2.2.1 BGP-based auto-discovery 484 The framework for BGP-based auto-discovery for a VPLS service is as 485 specified in [BGP-AUTO], section 3.2. 487 The AFI/SAFI used would be: 489 o An AFI specified by IANA for L2VPN. (This is the same for all 490 L2VPN schemes.) 492 o An SAFI specified by IANA specifically for an L2VPN (VPLS or VPWS) 493 service whose pseudowires are set up using the procedures 494 described in the current document. 496 In order to use BGP-based auto-discovery as specified in [BGP-AUTO], 497 the globally unique identifier associated with a VPLS must be 498 encodable as an 8-byte Route Distinguisher (RD). If the globally 499 unique identifier for a VPLS is an RFC2685 VPN-id, it can be encoded 500 as an RD as specified in [BGP-AUTO]. However, any other method of 501 assigning a unique identifier to a VPLS and encoding it as an RD 502 (using the encoding techniques of [RFC2547bis]) will do. 504 Each VSI needs to have a unique identifier, which can be encoded as a 505 BGP NLRI. This is formed by prepending the RD (from the previous 506 paragraph) to an IP address of the PE containing the virtual LAN 507 switch. Note that the role of this address is simply a unique 508 identifier within the VPN; it does not need to be globally routable. 510 (Note also that it is not strictly necessary for all the VSIs in the 511 same VPLS to have the same RD, all that is really necessary is that 512 the NLRI uniquely identify a virtual LAN switch.) 514 Each VSI needs to be associated with one or more Route Target (RT) 515 Extended Communities, as discussed in [BGP-AUTO}. These control the 516 distribution of the NLRI, and hence will control the formation of the 517 overlay topology of pseudowires that constitutes a particular VPLS. 519 Auto-discovery proceeds by having each PE distribute, via BGP, the 520 NLRI for each of its VSIs, with itself as the BGP next hop, and with 521 the appropriate RT for each such NLRI. Typically, each PE would be a 522 client of a small set of BGP route reflectors, which would 523 redistribute this information to the other clients. 525 If a PE has a VSI with a particular RT, it can then receive all the 526 NLRI which have that same RT, and from the BGP next hop attribute of 527 these NLRI will learn the IP addresses of the other PE routers which 528 have VSIs with the same RT. The considerations of [RFC2547bis] 529 section 4.3.3 on the use of route reflectors apply. 531 If a particular VPLS is meant to be a single fully connected LAN, all 532 its VSIs will have the same RT, in which case the RT could be (though 533 it need not be) an encoding of the VPN-id. If a particular VPLS 534 consists of multiple VLANs, each VLAN must have its own unique RT. A 535 VSI can be placed in multiple VLANS (or even in multiple VPLSes) by 536 assigning it multiple RTs. 538 Note that hierarchical VPLS can be set up by assigning multiple RTs 539 to some of the virtual LAN switches; the RT mechanism allows one to 540 have complete control over the pseudowire overlay which constitutes 541 the VPLS topology. 543 In summary, the BGP advertisement for a particular VSI at a given PE 544 will contain: 546 o an NLRI of AFI = L2VPN, SAFI = TBD, encoded as RD:PE_addr 548 o a BGP next hop equal to the loopback address of the PE 550 o an extended community attribute containing one or more RTs 552 3.2.3 Signaling 554 It is necessary to create Attachment Identifiers which identify the 555 VSIs. In the preceding section, a VSI-ID was encoded as RD:PE_addr 556 for the purposes of autodiscovery. For signaling purposes, the same 557 information is carried but is encoded slightly differently. Noting 558 that the RD is effectively a VPN identifier, we therefore encode the 559 RD in the AGI field, and place the PE_addr in the TAII field. The 560 SAII can be null. 562 The AGI field therefore consists of a length field of value 8, 563 followed by the 8 bytes of the RD. The TAII consists of a length 564 field of value 4 followed by the 4-byte PE address. 566 Note that it is not possible using this technique to set up more than 567 one PW per pair of VSIs. 569 3.2.4 Pseudowires as VPLS Attachment Circuits 571 It is also possible using this technique to set up a PW which 572 attaches at one endpoint to a VSI, but at the other endpoint only to 573 an Attachment Circuit. However, in this case there may be more than 574 one PW between a pair of PEs, so that AIIs cannot be null. Rather, 575 each such PW must have AII which is unique relative to the VPN-id. 576 This value would be carried in both the SAII and the TAII field of 577 the signaling messages. 579 3.3 Colored Pools: Full Mesh of Point-to-Point VCs 581 In the "Colored Pools" model of operation, each PE may contain 582 several pools of Attachment Circuits, each pool associated with a 583 particular VPN. A PE may contain multiple pools per VPN, as each 584 pool may correspond to a particular CE device. It may be desired to 585 create one pseudowire between each pair of pools that are in the same 586 VPN; the result would be to create a full mesh of CE-CE VCs for each 587 VPN. 589 3.3.1 Provisioning 591 Each pool is configured, and associated with: 593 o a set of Attachment Circuits; whether these Attachment Circuits 594 must themselves be provisioned, or whether they can be 595 auto-allocated as needed, is independent of and orthogonal to the 596 procedures described in this document; 598 o a "color", which can be thought of as a VPN-id of some sort; 600 o a relative pool identifier, which is unique relative to the color. 602 The pool identifier, and color, taken together, constitute a globally 603 unique identifier for the pool. Thus if there are n pools of a given 604 color, their pool identifiers can be (though they do not need to be) 605 the numbers 1-n. 607 The semantics are that a pseudowire will be created between every 608 pair of pools that have the same color, where each such pseudowire 609 will be bound to one Attachment Circuit from each of the two pools. 611 If each pool is a set of Attachment Circuits leading to a single CE 612 device, then the layer 2 connectivity among the CEs is controlled by 613 the way the colors are assigned to the pools. To create a full mesh, 614 the "color" would just be a VPN-id. 616 Optionally, a particular Attachment Circuit may be configured with 617 the relative pool identifier of a remote pool. Then that Attachment 618 Circuit would be bound to a particular pseudowire only if that 619 pseudowire's remote endpoint is the pool with that relative pool 620 identifier. With this option, the same pairs of Attachment Circuits 621 will always be bound via pseudowires. 623 3.3.2 Auto-Discovery 625 3.3.2.1 BGP-based auto-discovery 627 The framework for BGP-based auto-discovery for a colored pool service 628 is as specified in [BGP-AUTO], section 3.2. 630 The AFI/SAFI used would be: 632 o An AFI specified by IANA for L2VPN. (This is the same for all 633 L2VPN schemes.) 635 o An SAFI specified by IANA specifically for an L2VPN (VPLS or VPWS) 636 service whose pseudowires are set up using the procedures 637 described in the current document. 639 In order to use BGP-based auto-discovery, the color associated with a 640 colored pool must be encodable as both an RT (Route Target) and an RD 641 (Route Distinguisher). The globally unique identifier of a pool must 642 be encodable as NLRI; the color would be encoded as the RD and the 643 pool identifier as a four-byte quantity which is appended to the RD 644 to create the NLRI. 646 Auto-discovery procedures by having each PE distribute, via BGP, the 647 NLRI for each of its pools, with itself as the BGP next hop, and with 648 the RT that encodes the pool's color. If a given PE has a pool with 649 a particular color (RT), it must receive, via BGP, all NLRI with that 650 same color (RT). Typically, each PE would be a client of a small set 651 of BGP route reflectors, which would redistribute this information to 652 the other clients. 654 If a PE has a pool with a particular color, it can then receive all 655 the NLRI which have that same color, and from the BGP next hop 656 attribute of these NLRI will learn the IP addresses of the other PE 657 routers which have pools switches with the same color. It also 658 learns the unique identifier of each such remote pool, as this is 659 encoded in the NLRI. The remote pool's relative identifier can be 660 extracted from the NLRI and used in the signaling, as specified 661 below. 663 In summary, the BGP advertisement for a particular pool of attachment 664 circuits at a given PE will contain: 666 o an NLRI of AFI = L2VPN, SAFI = TBD, encoded as RD:pool_num; 668 o a BGP next hop equal to the loopback address of the PE; 670 o an extended community attribute containing one or more RTs. 672 3.3.3 Signaling 674 When a PE sends a Label Mapping message or an ICRQ message to set up 675 a PW between two pools, it encodes the color as the AGI, the local 676 pool's relative identifier as the SAII, and the remote pool's 677 relative identifier as the TAII. 679 When PE2 receives a Label Mapping message or an ICRQ message from 680 PE1, and the TAI identifies to a pool, and there is already an 681 pseudowire connecting an Attachment Circuit in that pool to an 682 Attachment Circuit at PE1, and the AI at PE1 of that pseudowire is 683 the same as the SAI of the Label Mapping or ICRQ message, then PE2 684 sends a Label Release or CDN message to PE1, with a Status Code 685 meaning "Attachment Circuit already bound to remote Attachment 686 Circuit". This prevents the creation of multiple pseudowires between 687 a given pair of pools. 689 Note that the signaling itself only identifies the remote pool to 690 which the pseudowire is to lead, not the remote Attachment Circuit 691 which is to be bound to the the pseudowire. However, the remote PE 692 may examine the SAII field to determine which Attachment Circuit 693 should be bound to the pseudowire. 695 3.4 Colored Pools: Partial Mesh 697 The procedures for creating a partial mesh of pseudowires among a set 698 of colored pools are substantially the same as those for creating a 699 full mesh, with the following exceptions: 701 o Each pool is optionally configured with a set of "import RTs" and 702 "export RTs"; 704 o During BGP-based auto-discovery, the pool color is still encoded 705 in the RD, but if the pool is configured with a set of "export 706 RTs", these are are encoded in the RTs of the BGP Update messages, 707 INSTEAD the color; 709 o If a pool has a particular "import RT" value X, it will create a 710 PW to every other pool which has X as one of its "export RTs". 711 The signaling messages and procedures themselves are as in section 712 3.3.3. 714 3.5 Distributed VPLS 716 In Distributed VPLS ([L2VPN-FW], [DTLS], [LPE]), the VPLS 717 functionality of a PE router is divided among two systems: a U-PE and 718 an N-PE. The U-PE sits between the user and the N-PE. VSI 719 functionality (e.g., MAC address learning and bridging) is performed 720 on the U-PE. A number of U-PEs attach to an N-PE. For each VPLS 721 supported by a U-PE, the U-PE maintains a pseudowire to each other 722 U-PE in the same VPLS. However, the U-PEs do not maintain signaling 723 control connections with each other. Rather, each U-PE has only a 724 single signaling connection, to its N-PE. In essence, each 725 U-PE-to-U-PE pseudowire is composed of three pseudowires spliced 726 together: one from U-PE to N-PE, one from N-PE to N-PE, and one from 727 N-PE to U-PE. 729 Consider for example the following topology: 731 U-PE A-----| |----U-PE C 732 | | 733 | | 734 N-PE E--------N-PE F 735 | | 736 | | 737 U-PE B-----| |-----U-PE D 739 where the four U-PEs are in a common VPLS. We now illustrate how PWs 740 get spliced together in the above topology in order to establish the 741 necessary PWs from U-PE A to the other U-PEs. 743 There are three PWs from A to E. Call these A-E/1, A-E/2, and A-E/3. 744 In order to connect A properly to the other U-PEs, there must be two 745 PWs from E to F (call these E-F/1 and E-F/2), one PW from E to B 746 (E-B/1), one from F to C (F-C/1), and one from F to D (F-D/1). 748 The N-PEs must then splice these pseudowires together to get the 749 equivalent of what the non-distributed VPLS signaling mechanism would 750 provide: 752 o PW from A to B: A-E/1 gets spliced to E-B/1. 754 o PW from A to C: A-E/2 gets spliced to E-F/1 gets spliced to F-C/1. 756 o PW from A to D: A-E/3 gets spliced to E-F/2 gets spliced to F-D/1. 758 It doesn't matter which PWs get spliced together, as long as the 759 result is one from A to each of B, C, and D. 761 Similarly, there are additional PWs which must get spliced together 762 to properly interconnect U-PE B with U-PEs C and D, and to 763 interconnect U-PE C with U-PE D. 765 One can see that distributed VPLS does not reduce the number of 766 pseudowires per U-PE, but it does reduce the number of control 767 connections per U-PE. Whether this is worthwhile depends, of course, 768 on what the bottleneck is. 770 3.5.1 Signaling 772 The signaling to support Distributed VPLS can be done with the 773 mechanisms described in this paper. However, the procedures for VPLS 774 (section 3.2.3) need some additional machinery to ensure that the 775 appropriate number of PWs are established between the various N-PEs 776 and U-PEs, and among the N-PEs. 778 At a given N-PE, the directly attached U-PEs in a given VPLS can be 779 numbered from 1 to n. This number identifies the U-PE relative to a 780 particular VPN-id and a particular N-PE. (That is, to uniquely 781 identify the U-PE, the N-PE, the VPN-id, and the U-PE number must be 782 known.) 784 As a result of configuration/discovery, each U-PE must be given a 785 list of pairs. Each element in this list tells the 786 U-PE to set up j PWs to the specified IP address. When the U-PE 787 signals to the N-PE, it sets the AGI to the proper-VPN-id, and sets 788 the SAII to the PW number, and sets the TAII to null. 790 In the above example, U-PE A would be told <3, E>, telling it to set 791 up 3 PWs to E. When signaling, A would set the AGI to the proper 792 VPN-id, and would set the SAII to 1, 2, or 3, depending on which of 793 the three PWs it is signaling. 795 As a result of configuration/discovery, each N-PE must be given the 796 following information for each VPLS: 798 o A "Local" list: {}, where each element tells it to 799 set up j PWs to the locally attached U-PE at the specified 800 address. The number of elements in this list will be n, the 801 number of locally attached U-PEs in this VPLS. In the above 802 example, E would be given the local list: {<3, A>, <3, B>}, 803 telling it to set up 3 PWs to A and 3 to B. 805 o A local numbering, relative to the particular VPLS and the 806 particular N-PE, of its U-PEs. In the above example, E could be 807 told that U-PE A is 1, and U-PE B is 2. 809 o A "Remote" list: {}, telling it to set up k PWs, 810 for each U-PE, to the specified IP address. Each of these IP 811 addresses identifies a N-PE, and k specifies the number of U-PEs 812 at that N-PE which are in the VPLS. In the above example, E would 813 be given the remote list: {<2, F>}. Since N-PE E has two U-PEs, 814 this tells it to set up 4 PWs to N-PE F, 2 for each of its E's 815 U-PEs. 817 The signaling of a PW from N-PE to U-PE is based on the local list 818 and the local numbering of U-PEs. When signaling a particular PW 819 from an N-PE to a U-PE, the AGI is set to the proper VPN-id, and SAII 820 is set to null, and the TAII is set to the PW number (relative to 821 that particular VPLS and U-PE). In the above example, when E signals 822 to A, it would set the TAII to be 1, 2, or 3, respectively, for the 823 three PWs it must set up to A. It would similarly signal three PWs 824 to B. 826 The LSP signaled from U-PE to N-PE is associated with an LSP from 827 N-PE to U-PE in the usual manner. A PW between a U-PE and an N-PE is 828 known as a "U-PW". 830 The signaling of the appropriate set of PWs from N-PE to N-PE is 831 based on the remote list. The PWs between the N-PEs can all be 832 considered equivalent. As long as the correct total number of PWs 833 are established, the N-PEs can splice these PWs to appropriate U-PWs. 834 The signaling of the correct number of PWs from N-PE to N-PE is based 835 on the remote list. The remote list specifies the number of PWs to 836 set up, per local U-PE, to a particular remote N-PE. 838 When signaling a particular PW from an N-PE to an N-PE, the AGI is 839 set to the appropriate VPN-id. The TAII identifies the remote N-PE, 840 as in the non-distributed case, i.e. it contains an IP address of 841 the remote N-PE. If there are n such PWs, they are distinguished by 842 the setting of the SAII, which will be a number from 1 to n 843 inclusive. A PW between two N-PEs is known as an "N-PW". 845 Each U-PW must be "spliced" to an N-PW. This is based on the remote 846 list. If the remote list contains an element , then i U-PWs 847 from each local U-PE must be spliced to i N-PWs from the remote N-PE 848 F. It does not matter which U-PWs are spliced to which N-PWs, as 849 long as this constraint is met. 851 If an N-PE has more than one local U-PE for a given VPLS, it must 852 also ensure that a U-PW from each such U-PE is spliced to a U-PW 853 from each of the other U-PEs. 855 3.5.2 Provisioning and Discovery 857 Every N-PE must be provisioned with the set of VPLS instances it 858 supports, a VPN-id for each one, and a list of local U-PEs for each 859 such VPLS. As part of the discovery procedure, the N-PE advertises 860 the number of U-PEs for each VPLS. 862 Auto-discovery (e.g., BGP-based) can be used to discover all the 863 other N-PEs in the VPLS, and for each, the number of U-PEs local to 864 that N-PE. From this, one can compute the total number of U-PEs in 865 the VPLS. This information is sufficient to enable one to compute 866 the local list and the remote list for each N-PE. 868 3.5.3 Non-distributed VPLS as a sub-case 870 A PE which is providing "non-distributed VPLS" (i.e., a PE which 871 performs both the U-PE and N-PE functions) can interoperate with 872 N-PE/U-PE pairs that are providing distributed VPLS. The 873 "non-distributed PE" simply advertises, in the discovery procedure, 874 that it has one local U-PE per VPLS. And of course, the 875 non-distributed PE does no splicing. 877 If every PE in a VPLS is providing non-distributed VPLS, and thus 878 every PE advertises itself as an N-PE with one local U-PE, the 879 resultant signaling is exactly the same as that specified in section 880 3.2.3 above, except that an SAII value of 1 is used instead of null. 881 (A PE providing non-distributed VPLS should therefore treat SAII 882 values of 1 the same as it treats SAII values of null.) 884 3.5.4 Splicing and the Data Plane 886 Splicing two PWs together is quite straightforward in the MPLS data 887 plane, as moving a packet from one PW directly to another is just a 888 label replace operation on the PW label. When a PW consists of two 889 PWs spliced together, it is assumed that the data will go to the node 890 where the splicing is being done, i.e., that the data path will 891 include the control points. 893 In some cases, it may be desired to have the data go on a more direct 894 route from one "true endpoint" to another, without necessarily 895 passing through the splice points. This could be done by means of a 896 new LDP TLV carried in the LDP mapping message; call it the "direct 897 route" TLV. A direct route TLV would be placed in an LDP Label 898 Mapping message by the LSP's "true endpoint". The TLV would specify 899 the IP address of the true endpoint, and would also specify a label, 900 representing the pseudowire, which is assigned by that endpoint. 901 When PWs are spliced together at intermediate control points, this 902 TLV would simply be passed upstream. Then when a frame is first put 903 on the pseudowire, it can be given this pseudowire label, and routed 904 to the true endpoint, thereby possibly bypassing the intermediate 905 control points. 907 Further details on splicing are discussed in [PW-SWITCH]. 909 4. Inter-AS Operation 911 The provisioning, autodiscovery and signaling mechanisms described 912 above can all be applied in an inter-AS environment. As in [2547bis] 913 there are a number of options for inter-AS operation. 915 4.1 Multihop EBGP redistribution of L2VPN NLRIs 917 This option is most like option (c) in [2547bis]. That is, we use 918 multihop EBGP redistribution of L2VPN NLRIs between source and 919 destination ASes, with EBGP redistribution of labeled IPv4 routes 920 from AS to neighboring AS. 922 An ASBR must maintain labeled IPv4 /32 routes to the PE routers 923 within its AS. It uses EBGP to distribute these routes to other 924 ASes. ASBRs in any transit ASes will also have to use EBGP to pass 925 along the labeled /32 routes. This results in the creation of a 926 label switched path from the ingress PE router to the egress PE 927 router. Now PE routers in different ASes can establish multi-hop 928 EBGP connections to each other, and can exchange L2VPN NLRIs over 929 those connections. Following such exchanges a pair of PEs in 930 different ASs could establish an LDP session to signal PWs between 931 each other. 933 For VPLS, the BGP advertisement and PW signaling are exactly as 934 described in Section 3.2. As a result of the multihop EBGP session 935 that exists between source and destination AS, the PEs in one AS that 936 have VSIs of a certain VPLS will discover the PEs in another AS that 937 have VSIs of the same VPLS. These PEs will then be able to establish 938 the appropriate PW signaling protocol session and establish the full 939 mesh of VSI-VSI pseudowires to build the VPLS as described in Section 940 3.2.3. 942 For VPWS, the BGP advertisement and PW signaling are exactly as 943 described in Section 3.3. As a result of the multihop EBGP session 944 that exists between source and destination AS, the PEs in one AS that 945 have pools of a certain color (VPN) will discover PEs in another AS 946 that have pools of the same color. These PEs will then be able to 947 establish the appropriate PW signaling protocol session and establish 948 the full mesh of pseudowires as described in Section 3.2.3. A 949 partial mesh can similarly be established using the procedures of 950 Section 3.4. 952 4.2 EBGP redistribution of L2VPN NLRIs with Pseudowire Switching 954 A possible drawback of the approach of the previous section is that 955 it creates PW signaling sessions among all the PEs of a given L2VPN 956 (VPLS or VPWS). This means a potentially large number of LDP or 957 L2TPv3 sessions will cross the AS boundary and that these session 958 connect to many devices within an AS. In the case were the ASes 959 belong to different providers, one might imagine that providers would 960 like to have fewer signaling sessions crossing the AS boundary and 961 that the entities that terminate the sessions could be restricted to 962 a smaller set of devices. These concerns motivate the approach 963 described here. 965 [PW-SWITCH] describes an approach to "switching" packets from one 966 pseudowire to another at a particular node. This approach allows an 967 end-to-end pseudowire to be constructed out of several pseudowire 968 segments, without maintaining an end-to-end control connection. We 969 can use this approach to produce an inter-AS solution that more 970 closely resembles option (b) in [2547bis]. 972 In this model, we use EBGP redistribution of L2VPN NLRI from AS to 973 neighboring AS. First, the PE routers use IBGP to redistribute L2VPN 974 NLRI either to an Autonomous System Border Router (ASBR), or to a 975 route reflector of which an ASBR is a client. The ASBR then uses 976 EBGP to redistribute those L2VPN NLRI to an ASBR in another AS, which 977 in turn distributes them to the PE routers in that AS, or perhaps to 978 another ASBR which in turn distributes them, and so on. 980 In this case, a PE can learn the address of an ASBR through which it 981 could reach another PE to which it wishes to establish a PW. That 982 is, a local PE will receive a BGP advertisement containing L2VPN NLRI 983 corresponding to an L2VPN instance in which the local PE has some 984 attached members. The BGP next-hop for that L2VPN NLRI will be an 985 ASBR of the local AS. Then, rather than building a control 986 connection all the way to the remote PE, it builds one only to the 987 ASBR. A pseudowire segment can now be established from the PE to the 988 ASBR. The ASBR in turn can establish a PW to the ASBR of the next 989 AS, and use "PW switching" to splice that PW to the PW from the PE. 990 Repeating the process at each ASBR leads to a sequence of PW segments 991 that, when spliced together, connect the two PEs. 993 When this approach is used for VPLS, or for full-mesh VPWS, it leads 994 to a full mesh of pseudowires among the PEs, just as in the previous 995 section, but it does not produce a full mesh of control connections 996 (LDP or L2TPv3 sessions). Instead the control connections within a 997 single AS run among all the PEs of that AS and the ASBRs of the AS. 998 A single control connection between the ASBRs of adjacent ASes can be 999 used to support however many AS-to-AS pseudowire segments are needed. 1001 4.3 Inter-Provider Application of Dist. VPLS Signaling 1003 An alternative approach to inter-provider VPLS can be derived from 1004 the Distributed VPLS approach described above. Consider the 1005 following topology: 1007 PE A ---- Network 1 ----- Border ----- Border ----- Network 2 ---- PE B 1008 Router 12 Router 21 | 1009 | 1010 PE C 1012 where A, B, and C are PEs in a common VPLS, but Networks 1 and 2 are 1013 networks of different Service Providers. Border Router 12 is 1014 Network 1's border router to network 2, and Border Router 21 is 1015 Network 2's border router to Network 1. We suppose further that the 1016 PEs are not "distributed", i.e, that each provides both the U-PE and 1017 N-PE functions. 1019 In this topology, one needs two inter-provider pseudowires: A-B and 1020 A-C. 1022 Suppose a Service Provider decides, for whatever reason, that it does 1023 not want each of its PEs to have a control connection to any PEs in 1024 the other network. Rather, it wants the inter-provider control 1025 connections to run only between the two border routers. 1027 This can be achieved using the techniques of section 3.5, where the 1028 PEs behave like U-PEs, and the BRs behave like N-PEs. In the example 1029 topology, PE A would behave like a U-PE which is locally attached to 1030 BR12; PEs B and C would be have like U-PEs which are locally attached 1031 to BR21; and the two BRs would behave like N-PEs. 1033 As a result, the PW from A to B would consist of three segments: 1034 A-BR12, BR12-BR21, and BR21-B. The border routers would have to 1035 splice the corresponding segments together. 1037 This requires the PEs within a VPLS to be numbered from 1-n (relative 1038 to that VPLS) within a given network. 1040 5. Security Considerations 1042 This document describes a number of different L2VPN provisioning 1043 models, and specifies the endpoint identifiers that are required to 1044 support each of the provisioning models. It also specifies how those 1045 endpoint identifiers are mapped into fields of auto-discovery 1046 protocols and signaling protocols. 1048 The security considerations related to the signaling and 1049 auto-discovery protocols are discussed in the relevant protocol 1050 specifications ([BGP-AUTO], [L2TP-BASE], [L2TP-L2VPN], [LDP], 1051 [PWE3-CONTROL]). 1053 The security considerations related to the particular kind of L2VPN 1054 service being supported are discussed in [L2VPN-REQS], [L2VPN-FW], 1055 and [VPLS]. 1057 The security consideration of inter-AS operation are similar to those 1058 for inter-AS L3VPNs [2547bis]. 1060 The way in which endpoint identifiers are mapped into protocol fields 1061 does not create any additional security issues. 1063 6. Acknowledgments 1065 Thanks to Dan Tappan, Ted Qian, Ali Sajassi, Skip Booth, Luca Martini 1066 and Francois LeFaucheur for their comments, criticisms, and helpful 1067 suggestions. 1069 Thanks to Tissa Senevirathne, Hamid Ould-Brahim and Yakov Rekhter for 1070 discussing the auto-discovery issues. 1072 Thanks to Vach Kompella for a continuing discussion of the proper 1073 semantics of the generalized identifiers. 1075 7. References 1077 [BGP-AUTO] "Using BGP as an Auto-Discovery Mechanism for 1078 Network-based VPNs", Ould-Brahim et. al., 1079 draft-ietf-l3vpn-bgpvpn-auto-05.txt, February 2005 1081 [L2TP-BASE] "Layer Two Tunneling Protocol (Version 3)", Lau et. al., 1082 draft-ietf-l2tpext-l2tp-base-14.txt, June 2004 1084 [L2TP-L2VPN] "L2VPN Extensions for L2TP", Luo, 1085 draft-ietf-l2tpext-l2vpn-01.txt, Jul 2004 1087 [L2VPN-FW] "L2VPN Framework", Andersson et. al., 1088 draft-ietf-l2vpn-l2-framework-05.txt, June 2004 1090 [L2VPN-REQ] "Service Requirements for Layer 2 Provider Provisioned 1091 Virtual Private Network Services", Augustyn, Serbest, et. al., 1092 draft-ietf-l2vpn-requirements-02.txt, September 2004 1094 [L2VPN-TERM] "PPVPN Terminology", Andersson, Madsen, 1095 draft-ietf-l3vpn-ppvpn-terminology-04.txt, September 2004 1097 [LDP] "LDP Specification", Andersson, et. al., RFC 3036, Jan 2001 1099 [PWE3-ARCH] "PWE3 Architecture", Bryant, Pate, et. al., 1100 draft-ietf-pwe3-arch-07.txt, March 2004 1102 [PWE3-CONTROL] "Pseudowire Setup and Maintenance using LDP", Martini, 1103 et. al., draft-ietf-pwe3-control-protocol-14.txt, December 2004 1105 [PW-SWITCH] "Pseudo Wire Switching", Martini, et. al., 1106 draft-martini-pwe3-pw-switching-01.txt, October 2004 1108 [RFC2547bis], "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., 1109 draft-ietf-l3vpn-rfc2547bis-02.txt, September 2004 1111 [RFC2685] "Virtual Private Networks Identifier", Fox, Gleeson, 1112 September 1999 1114 [VPLS] "Virtual Private LAN Services over MPLS", Laserre, et. al., 1115 draft-ietf-l2vpn-vpls-ldp-05.txt, September 2004 1117 Authors' Addresses 1119 Eric Rosen 1120 Cisco Systems, Inc. 1121 1414 Mass. Ave. 1122 Boxborough, MA 01719 1123 USA 1125 Email: erosen@cisco.com 1127 Wei Luo 1128 Cisco Systems, Inc. 1129 170 W Tasman Dr. 1130 San Jose, CA 95134 1131 USA 1133 Email: luo@cisco.com 1135 Bruce Davie 1136 Cisco Systems, Inc. 1137 1414 Mass. Ave. 1138 Boxborough, MA 01719 1139 USA 1141 Email: bsd@cisco.com 1143 Vasile Radoaca 1144 Nortel Networks 1145 600 Technology Park 1146 Billerica, MA 01821 1147 USA 1149 Phone: +1 978 288 6097 1150 Email: vasile@nortelnetworks.com 1152 Intellectual Property Statement 1154 The IETF takes no position regarding the validity or scope of any 1155 Intellectual Property Rights or other rights that might be claimed to 1156 pertain to the implementation or use of the technology described in 1157 this document or the extent to which any license under such rights 1158 might or might not be available; nor does it represent that it has 1159 made any independent effort to identify any such rights. Information 1160 on the procedures with respect to rights in RFC documents can be 1161 found in BCP 78 and BCP 79. 1163 Copies of IPR disclosures made to the IETF Secretariat and any 1164 assurances of licenses to be made available, or the result of an 1165 attempt made to obtain a general license or permission for the use of 1166 such proprietary rights by implementers or users of this 1167 specification can be obtained from the IETF on-line IPR repository at 1168 http://www.ietf.org/ipr. 1170 The IETF invites any interested party to bring to its attention any 1171 copyrights, patents or patent applications, or other proprietary 1172 rights that may cover technology that may be required to implement 1173 this standard. Please address the information to the IETF at 1174 ietf-ipr@ietf.org. 1176 Disclaimer of Validity 1178 This document and the information contained herein are provided on an 1179 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1180 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1181 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1182 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1183 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1184 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1186 Copyright Statement 1188 Copyright (C) The Internet Society (2005). This document is subject 1189 to the rights, licenses and restrictions contained in BCP 78, and 1190 except as set forth therein, the authors retain all their rights. 1192 Acknowledgment 1194 Funding for the RFC Editor function is currently provided by the 1195 Internet Society.