idnits 2.17.1 draft-ietf-l2vpn-signaling-02.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 1033. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1006. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1013. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1019. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: 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 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 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 272: '... 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 189 has weird spacing: '...warders being...' == Line 269 has weird spacing: '...sist of an At...' == Line 276 has weird spacing: '...ntifier may b...' == Line 277 has weird spacing: '...r, some attri...' == Line 296 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 (September 2004) is 7156 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 676, but not defined == Missing Reference: 'LPE' is mentioned on line 676, but not defined == Missing Reference: 'L2VPN-REQS' is mentioned on line 920, but not defined == Unused Reference: 'RFC2685' is defined on line 971, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-l3vpn-bgpvpn-auto-04 ** 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-09 == 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: 17 errors (**), 0 flaws (~~), 19 warnings (==), 7 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 Wei Luo 4 Expiration Date: March 2005 Cisco Systems, Inc. 6 Vasile Radoaca 7 Nortel Networks 9 September 2004 11 Provisioning Models and Endpoint Identifiers in L2VPN Signaling 13 draft-ietf-l2vpn-signaling-02.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 There are a number of different kinds of "Provider Provisioned Layer 40 2 VPNs" (L2VPNs). The different kinds of L2VPN may have different 41 "provisioning models", i.e., different models for what information 42 needs to be configured in what entities. Once configured, the 43 provisioning information is distributed by a "discovery process". 44 When the discovery process is complete, a signaling protocol is 45 automatically invoked. The signaling protocol sets up the mesh of 46 Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. Any 47 PW signaling protocol needs to have a method which allows each PW 48 endpoint to identify the other; thus a PW signaling protocol will 49 have the notion of an endpoint identifier. The semantics of the 50 endpoint identifiers which the signaling protocol uses for a 51 particular type of L2VPN are determined by the provisioning model. 52 This document specifies a number of L2VPN provisioning models, and 53 further specifies the semantic structure of the endpoint identifiers 54 required by each provisioning model. It discusses the way in which 55 the endpoint identifiers are distributed by the discovery process, 56 especially when the discovery process is based upon the Border 57 Gateway Protocol (BGP). It then specifies how the endpoint 58 identifiers are carried in the two signaling protocols that are used 59 to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2 60 Tunneling Protocol (L2TPv3). 62 Contents 64 1 Introduction ......................................... 4 65 2 Signaling Protocol Framework ......................... 5 66 2.1 Endpoint Identification .............................. 5 67 2.2 Creating a Single Bidirectional Pseudowire ........... 6 68 2.3 Attachment Identifiers and Forwarders ................ 7 69 3 Applications ......................................... 8 70 3.1 Individual Point-to-Point VCs ........................ 9 71 3.1.1 Provisioning Models .................................. 9 72 3.1.1.1 Double Sided Provisioning ............................ 9 73 3.1.1.2 Single Sided Provisioning with Discovery ............. 9 74 3.1.2 Signaling ............................................ 10 75 3.2 Virtual Private LAN Service .......................... 11 76 3.2.1 Provisioning ......................................... 11 77 3.2.2 Auto-Discovery ....................................... 11 78 3.2.2.1 BGP-based auto-discovery ............................. 11 79 3.2.3 Signaling ............................................ 13 80 3.2.4 Pseudowires as VPLS Attachment Circuits .............. 13 81 3.3 Colored Pools: Full Mesh of Point-to-Point VCs ....... 13 82 3.3.1 Provisioning ......................................... 13 83 3.3.2 Auto-Discovery ....................................... 14 84 3.3.2.1 BGP-based auto-discovery ............................. 14 85 3.3.3 Signaling ............................................ 15 86 3.4 Colored Pools: Partial Mesh .......................... 16 87 3.5 Distributed VPLS ..................................... 16 88 3.5.1 Signaling ............................................ 18 89 3.5.2 Provisioning and Discovery ........................... 19 90 3.5.3 Non-distributed VPLS as a sub-case ................... 20 91 3.5.4 Inter-Provider Application of Dist. VPLS Signaling ... 20 92 3.5.5 Splicing and the Data Plane .......................... 21 93 4 Security Considerations .............................. 22 94 5 Acknowledgments ...................................... 22 95 6 References ........................................... 22 96 7 Author's Information ................................. 23 97 8 Intellectual Property Statement ...................... 24 98 9 Full Copyright Statement ............................. 24 100 1. Introduction 102 [L2VPN-FW] describes a number of different ways in which sets of 103 pseudowires may be combined together into "Provider Provisioned Layer 104 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of different 105 kinds of L2VPN. Different kinds of L2VPN may have different 106 "provisioning models", i.e., different models for what information 107 needs to be configured in what entities. Once configured, the 108 provisioning information is distributed by a "discovery process", and 109 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. That is, different kinds of L2VPN, with different 114 provisioning models, require different kinds of endpoint identifiers. 115 This document specifies a number of PPVPN provisioning models, and 116 specifies the semantic structure of the endpoint identifiers required 117 for each provisioning model. 119 Either LDP (as specified in [LDP] and extended in [PWE3-CONTROL]) or 120 L2TP version 3 (as specified in [L2TP-BASE] and extended in [L2TP- 121 L2VPN] can be used as signaling protocols to set up and maintain 122 pseudowires (PWs) [PWE3-ARCH]. Any protocol which sets up connections 123 must provide a way for each endpoint of the connection to identify 124 the other; each PW signaling protocol thus provides a way to identify 125 the PW endpoints. Since each signaling protocol needs to support 126 all the different kinds of L2VPN and provisioning models, the 127 signaling protocol must have a very general way of representing 128 endpoint identifiers, and it is necessary to specify rules for 129 encoding each particular kind of endpoint identifier into the 130 relevant fields of each signaling protocol. This document specifies 131 how to encode the endpoint identifiers of each provisioning model 132 into the LDP and L2TPv3 signaling protocols. 134 We make free use of terminology from [L2VPN-FW], [L2VPN-TERM], and 135 [PWE3-ARCH], in particular the terms "Attachment Circuit", 136 "pseudowire", "PE", "CE". 138 Section 2 provides an overview of the relevant aspects of [PWE3- 139 CONTROL] and [L2TP-L2VPN]. 141 Section 3 details various provisioning models and relates them to the 142 signaling process and to the discovery process. 144 We do not specify an auto-discovery procedure in this draft, but we 145 do specify the information which needs to be obtained via auto- 146 discovery in order for the signaling procedures to begin. The way in 147 which the signaling mechanisms can be integrated with BGP-based 148 auto-discovery is covered in some detail. 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 154 2. Signaling Protocol Framework 156 2.1. Endpoint Identification 158 Per [L2VPN-FW], a pseudowire can be thought of as a relationship 159 between a pair of "Forwarders". In simple instances of VPWS, a 160 Forwarder binds a pseudowire to a single Attachment Circuit, such 161 that frames received on the one are sent on the other, and vice 162 versa. In VPLS, a Forwarder binds a set of pseudowires to a set of 163 Attachment Circuits; when a frame is received from any member of that 164 set, a MAC address table is consulted (and various 802.1d procedures 165 executed) to determine the member or members of that set on which the 166 frame is to be transmitted. In more complex scenarios, Forwarders 167 may bind PWs to PWs, thereby "splicing" two PWs together; this is 168 needed, e.g., to support distributed VPLS. 170 In simple VPWS, where a Forwarder binds exactly one PW to exactly one 171 Attachment Circuit, a Forwarder can be identified by identifying its 172 Attachment Circuit. In simple VPLS, a Forwarder can be identified by 173 identifying its PE device and its VPN. 175 To set up a PW between a pair of Forwarders, the signaling protocol 176 must allow the Forwarder at one endpoint to identify the Forwarder at 177 the other. In [PWE3-CONTROL], the term "Attachment Identifier", or 178 "AI", to refer to a quantity whose purpose is to identify a 179 Forwarder. In [L2TP-L2VPN], the term "Forwarder Identifier" is used 180 for the same purpose. In the context of this document, "Attachment 181 Identifier" and "Forwarder Identifier" are used interchangably. 183 [PWE3-CONTROL] specifies two FEC elements which can be used for when 184 setting up pseudowires, the PWid FEC element, and the Generalized Id 185 FEC element. The PWid FEC element carries only one Forwarder 186 identifier; it can be thus be used only when both forwarders have the 187 same identifier, and when that identifier can be coded as a 32-bit 188 quantity. The Generalized Id FEC element carries two Forwarder 189 identifiers, one for each of the two Forwarders being connected. 190 Each identifier is known as an Attachment Identifier, and a signaling 191 message carries both a "Source Attachment Identifier" (SAI) and a 192 "Target Attachment Identifier" (TAI). 194 The Generalized ID FEC element also provides some additional 195 structuring of the identifiers. It is assumed that the SAI and TAI 196 will sometimes have a common part, called the "Attachment Group 197 Identifier" (AGI), such that the SAI and TAI can each be thought of 198 as the concatenation of the AGI with an "Attachment Individual 199 Identifier" (AII). So the pair of identifiers is encoded into three 200 fields: AGI, Source AII (SAII), and Target AII (TAII). The SAI is 201 the concatenation of the AGI and the SAII, while the TAI is the 202 concatenation of the AGI and the TAII. 204 Similiarly, [L2TP-L2VPN] allows using one or two Forwarder 205 Identifiers to set up pseudowires. If only the target Forwarder 206 Identifier is used in L2TP signaling messages, both the source and 207 target Forwarders are assumed to have the same value. If both the 208 source and target Forwarder Identifers are carried in L2TP siganling 209 messages, each Forwarder uses a locally significant identifier value. 211 The Forwarder Identifier in [L2TP-L2VPN] is an equivalent term as 212 Attachment Identifer in [PWE3-CONTROL]. A Forwarder Identifier also 213 consists of an Attachment Group Identifier and an Attachment 214 Individual Identifier. Unlike the Generalized ID FEC element, the 215 AGI and AII are carried in distinct L2TP Attribute-Value-Pairs 216 (AVPs). The AGI is encoded in the AGI AVP, and the SAII and TAII are 217 encoded in the Local End ID AVP and the Remote End ID AVP 218 respectively. The source Forwarder Identifier is the concatenation 219 of the AGI and SAII, while the target Forwarder Identifier is the 220 concatenation of the AGI and TAII. 222 In applications that group sets of PWs into "Layer 2 Virtual Private 223 Networks", the AGI can be thought of as a "VPN Identifier". 225 It should be noted that while different forwarders support different 226 applications, the type of application (e.g., VPLS vs. VPWS) cannot 227 necessarily be inferred from the forwarders' identifiers. A router 228 receiving a signaling message with a particular TAI will have to be 229 able to determine which of its local forwarders is identified by that 230 TAI, and to determine the application provided by that forwarder. 231 But other nodes may not be able to infer the application simply by 232 inspection of the signaling messages. 234 2.2. Creating a Single Bidirectional Pseudowire 236 In any form of LDP-based signaling, each PW endpoint must initiate 237 the creation of a unidirectional LSP. A PW is a pair of such LSPs. 238 In most of the PPVPN provisioning models, the two endpoints of a 239 given PW can simultaneously initiate the signaling for it. They must 240 therefore have some way of determining when a given pair of LSPs are 241 intended to be associated together as a single PW. 243 The way in which this association is done is different for the 244 various different L2VPN services and provisioning models. The 245 details appear in later sections. 247 L2TP signaling inherently establishes a bidirectional session that 248 carries a PW between two PW endpoints. The two endpoints can also 249 simultaneously initiate the signaling for a given PW. It is possible 250 that two PWs can be established for a pair of Forwarders. 252 In order to avoid setting up duplicated pseudowires between two 253 Forwarders, each PE must be able to independently detect such a 254 pseudowire tie. The procedures of detecting a pseudowire tie is 255 described in [L2TP-L2VPN] 257 2.3. Attachment Identifiers and Forwarders 259 Every Forwarder in a PE must be associated with an Attachment 260 Identifier (AI), either through configuration or through some 261 algorithm. The Attachment Identifier must be unique in the context 262 of the PE router in which the Forwarder resides. The combination must be globally unique. 265 It is frequently convenient to a set of Forwarders as being members 266 of a particular "group", where PWs may only be set up among members 267 of a group. In such cases, it is convenient to identify the 268 Forwarders relative to the group, so that an Attachment Identifier 269 would consist of an Attachment Group Identifier (AGI) plus an 270 Attachment Individual Identifier (AII). 272 IT MUST BE UNDERSTOOD THAT THIS NOTION OF "GROUP" HAS NOTHING 273 WHATSOEVER TO DO WITH THE "GROUP ID" THAT IS PART OF THE PWID FEC IN 274 [PWE3-CONTROL]. 276 An Attachment Group Identifier may be thought of as a VPN-id, or 277 a VLAN identifier, some attribute which is shared by all the 278 Attachment VCs (or pools thereof) which are allowed to be connected. 280 The details for how to construct the AGI and AII fields identifying 281 the pseudowire endpoints in particular provisioning models are 282 discussed later in this paper. 284 We can now consider an LSP to be identified by: 286 , PE2, >, 288 and the LSP in the opposite direction will be identified by: 290 , PE1, >; 292 a pseudowire is a pair of such LSPs. In the case of using L2TP 293 signaling, these refer to the two directions of an L2TP session. 295 When a signaling message is sent from PE1 to PE2, and PE1 needs to 296 refer to an Attachment Identifier which has been configured on 297 one of its own Attachment VCs (or pools), the Attachment 298 Identifier is called a "Source Attachment Identifier". If PE1 299 needs to refer to an Attachment Identifier which has been 300 configured on one of PE2's Attachment VCs (or pools), the 301 Attachment Identifier is called a "Target Attachment Identifier". 302 (So an SAI at one endpoint is a TAI at the remote endpoint, and vice 303 versa.) 305 In the signaling protocol, we define encodings for the following 306 three fields: 308 - Attachment Group Identifier (AGI) 310 - Source Attachment Individual Identifier (SAII) 312 - Target Attachment Individual Identifier (TAII) 314 If the AGI is non-null, then the SAI consists of the AGI together 315 with the SAII, and the TAI consists of the TAII together with the 316 AGI. If the AGI is null, then the SAII and TAII are the SAI and TAI 317 respectively. 319 The intention is that the PE which receives an LDP Label Mapping 320 message or an L2TP Incoming Call Request (ICRQ) message containing a 321 TAI will be able to map that TAI uniquely to one of its Attachment 322 VCs (or pools). The way in which a PE maps a TAI to an Attachment 323 VC (or pool) should be a local matter. So as far as the signaling 324 procedures are concerned, the TAI is really just an arbitrary string 325 of bytes, a "cookie". 327 3. Applications 329 In this section, we specify the way in which the pseudowire signaling 330 using the notion of source and target Forwarder is applied for a 331 number of different applications. For some of the applications, we 332 specify the way in which different provisioning models can be used. 333 However, this is not meant to be an exhaustive list of the 334 applications, or an exhaustive list of the provisioning models that 335 can be applied to each application. 337 3.1. Individual Point-to-Point VCs 339 The signaling specified in this document can be used to set up 340 individually provisioned point-to-point pseudowires. In this 341 application, each Forwarder binds a single PW to a single Attachment 342 Circuit. Each PE must be provisioned with the necessary set of 343 Attachment Circuits, and then certain parameters must be provisioned 344 for each Attachment Circuit. 346 3.1.1. Provisioning Models 348 3.1.1.1. Double Sided Provisioning 350 In this model, the Attachment Circuit must be provisioned with a 351 local name, a remote PE address, and a remote name. During 352 signaling, the local name is sent as the SAII, the remote name as the 353 TAII, and the AGI is null. If two Attachment Circuits are to be 354 connected by a PW, the local name of each must be the remote name of 355 the other. 357 Note that if the local name and the remote name are the same, the 358 PWid FEC element can be used instead of the Generalized ID FEC 359 element in the LDP based signaling. 361 With L2TP signaling, the local name is sent in Local End ID AVP, the 362 remote name in Remote End ID AVP. The AGI AVP is optional. If 363 present, it contains a zero-length AGI value. If the local name and 364 the remote name are the same, Local End ID AVP can be omitted from 365 L2TP signaling messages. 367 3.1.1.2. Single Sided Provisioning with Discovery 369 In this model, each Attachment Circuit must be provisioned with a 370 local name. The local name consists of a VPN-id (signaled as the 371 AGI) and an Attachment Individual Identifier which is unique relative 372 to the AGI. If two Attachment circuits are to be connected by a PW, 373 only one of them needs to be provisioned with a remote name (which of 374 course is the local name of the other Attachment Circuit). Neither 375 needs to be provisioned with the address of the remote PE, but both 376 must have the same VPN-id. 378 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 381 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 384 PE2. When signaling, it will use "fred" as the TAII, and will use V 385 as he AGI. PE1's local name for the Attachment Circuit is sent as 386 the SAII. 388 The primary benefit of this provisioning model when compared to 389 Double Sided Provisioning is that it enables one to move an 390 Attachment Circuit from one PE to another without having to 391 reconfigure the remote endpoint. 393 3.1.2. Signaling 395 The LDP-based signaling is as specified in [PWE3-CONTROL], with the 396 addition of the following: 398 When a PE receives a Label Mapping Message, and the TAI identifies a 399 particular Attachment Circuit which is configured to be bound to a 400 point-to-point PW, then the following checks must be made. 402 If the Attachment Circuit is already bound to a pseudowire (including 403 the case where only one of the two LSPs currently exists), and the 404 remote endpoint is not PE1, then PE2 sends a Label Release message to 405 PE1, with a Status Code meaning "Attachment Circuit bound to 406 different PE", and the processing of the Mapping message is complete. 408 If the Attachment Circuit is already bound to a pseudowire (including 409 the case where only one of the two LSPs currently exists), but the AI 410 at PE1 is different than that specified in the AGI/SAII fields of the 411 Mapping message then PE2 sends a Label Release message to PE1, with a 412 Status Code meaning "Attachment Circuit bound to different remote 413 Attachment Circuit", and the processing of the Mapping message is 414 complete. 416 Similarly with the L2TP-based signaling, when a PE receives an ICRQ 417 message, and the TAI identifies a particular Attachment Circuit which 418 is configured to be bound to a point-to-point PW, it performs the 419 following checks. 421 If the Attachment Circuit is already bound to a pseudowire, and the 422 remote endpoint is not PE1, then PE2 sends a Call Disconnect Notify 423 (CDN) message to PE1, with a Status Code meaning "Attachment Circuit 424 bound to different PE", and the processing of the ICRQ message is 425 complete. 427 If the Attachment Circuit is already bound to a pseudowire, but the 428 pseudowire is bound to a Forwarder on PE1 with the AI different than 429 that specified in the SAI fields of the ICRQ message, then PE2 sends 430 a CDN message to PE1, with a Status Code meaning "Attachment Circuit 431 bound to different remote Attachment Circuit", and the processing of 432 the ICRQ message is complete. 434 These errors could occur as the result of misconfigurations. 436 3.2. Virtual Private LAN Service 438 In the VPLS application [L2VPN-REQ, VPLS], the Attachment Circuits 439 can be though of as LAN interfaces which attach to "virtual LAN 440 switches", or, in the terminology of [L2VPN-FW], "Virtual Switching 441 Instances" (VSIs). Each Forwarder is a VSI that attaches to a number 442 of PWs and a number of Attachment Circuits. The VPLS service 443 [L2VPN-REQ, VPLS] requires that a single pseudowire be created 444 between each pair of VSIs that are in the same VPLS. Each PE device 445 may have a multiple VSIs, where each VSI belongs to a different VPLS. 447 3.2.1. Provisioning 449 Each VPLS must have a globally unique identifier, which we call a 450 VPN-id. Every VSI must be configured with the VPN-id of the VPLS to 451 which it belongs. 453 Each VSI must also have a unique identifier, but this can be formed 454 automatically by concatenating its VPN-id with the IP address of its 455 PE router. 457 3.2.2. Auto-Discovery 459 3.2.2.1. BGP-based auto-discovery 461 The framework for BGP-based auto-discovery for a VPLS service is as 462 specified in [BGP-AUTO], section 3.2. 464 The AFI/SAFI used would be: 466 - An AFI specified by IANA for L2VPN. (This is the same for all 467 L2VPN schemes.) 469 - An SAFI specified by IANA specifically for an L2VPN (VPLS or 470 VPWS) service whose pseudowires are set up using the procedures 471 described in the current document. 473 In order to use BGP-based auto-discovery as specified in [BGP-AUTO], 474 the globally unique identifier associated with a VPLS must be 475 encodable as an 8-byte Route Distinguisher (RD). If the globally 476 unique identifier for a VPLS is an RFC2685 VPN-id, it can be encoded 477 as an RD as specified in [BGP-AUTO]. However, any other method of 478 assigning a unique identifier to a VPLS and encoding it as an RD 479 (using the encoding techniques of [RFC2547bis]) will do. 481 Each VSI needs to have a unique identifier, which can be encoded as a 482 BGP NLRI. This is formed by prepending the RD (from the previous 483 paragraph) to an IP address of the PE containing the virtual LAN 484 switch. 486 (Note that it is not strictly necessary for all the VSIs in the same 487 VPLS to have the same RD, all that is really necessary is that the 488 NLRI uniquely identify a virtual LAN switch.) 490 Each VSI needs to be associated with one or more Route Target (RT) 491 Extended Communities, as discussed in [BGP-AUTO}. These control the 492 distribution of the NLRI, and hence will control the formation of the 493 overlay topology of pseudowires that constitutes a particular VPLS. 495 Auto-discovery proceeds by having each PE distribute, via BGP, the 496 NLRI for each of its VSIs, with itself as the BGP next hop, and with 497 the appropriate RT for each such NLRI. Typically, each PE would be a 498 client of a small set of BGP route reflectors, which would 499 redistribute this information to the other clients. 501 If a PE has a VSI with a particular RT, it can then receive all the 502 NLRI which have that same RT, and from the BGP next hop attribute of 503 these NLRI will learn the IP addresses of the other PE routers which 504 have VSIs with the same RT. The considerations of [RFC2547bis] 505 section 4.3.3 on the use of route reflectors apply. 507 If a particular VPLS is meant to be a single fully connected LAN, all 508 its VSIs will have the same RT, in which case the RT could be (though 509 it need not be) an encoding of the VPN-id. If a particular VPLS 510 consists of multiple VLANs, each VLAN must have its own unique RT. A 511 VSI can be placed in multiple VLANS (or even in multiple VPLSes) by 512 assigning it multiple RTs. 514 Note that hierarchical VPLS can be set up by assigning multiple RTs 515 to some of the virtual LAN switches; the RT mechanism allows one to 516 have complete control over the pseudowire overlay which constitutes 517 the VPLS topology. 519 3.2.3. Signaling 521 It is necessary to create Attachment Identifiers which identify the 522 VSIs. Given that each VPLS has at most one VSI per PE, and that only 523 one PW is permitted between any pair of VSIs, a VSI can be uniquely 524 identified (relative to its PE) by the VPN-id of its VPLS. Therefore 525 the signaling messages can encode the VPN-id in the AGI field, and 526 use the null values of the SAII and TAII fields. 528 The VPN-id may be encoded as an [RFC2547bis] RD, in which case the 529 AGI field consist of a length field of value 8, followed by the 8 530 bytes of the RD. If the VPN-id is an RFC2685 VPN-id, it should be 531 encoded as an RD (as specified in [BGP-AUTO]), and then the RD should 532 be carried in the AGI field. 534 Note that it is not possible using this technique to set up more than 535 one PW per pair of VSIs. 537 3.2.4. Pseudowires as VPLS Attachment Circuits 539 It is also possible using this technique to set up a PW which 540 attaches at one endpoint to a VSI, but at the other endpoint only to 541 an Attachment Circuit. However, in this case there may be more than 542 one PW between a pair of PEs, so that AIIs cannot be null. Rather, 543 each such PW must have AII which is unique relative to the VPN-id. 544 This value would be carried in both the SAII and the TAII field of 545 the signaling messages. 547 3.3. Colored Pools: Full Mesh of Point-to-Point VCs 549 In the "Colored Pools" model of operation, each PE may contain 550 several pools of Attachment Circuits, each pool associated with a 551 particular VPN. A PE may contain multiple pools per VPN, as each 552 pool may correspond to a particular CE device. It may be desired to 553 create one pseudowire between each pair of pools that are in the same 554 VPN; the result would be to create a full mesh of CE-CE VCs for each 555 VPN. 557 3.3.1. Provisioning 559 Each pool is configured, and associated with: 561 - a set of Attachment Circuits; whether these Attachment Circuits 562 must themselves be provisioned, or whether they can be auto- 563 allocated as needed, is independent of and orthogonal to the 564 procedures described in this document; 566 - a "color", which can be thought of as a VPN-id of some sort; 568 - a relative pool identifier, which is unique relative to the 569 color. 571 The pool identifier, and color, taken together, constitute a globally 572 unique identifier for the pool. Thus if there are n pools of a given 573 color, their pool identifiers can be (though they do not need to be) 574 the numbers 1-n. 576 The semantics are that a pseudowire will be created between every 577 pair of pools that have the same color, where each such pseudowire 578 will be bound to one Attachment Circuit from each of the two pools. 580 If each pool is a set of Attachment Circuits leading to a single CE 581 device, then the layer 2 connectivity among the CEs is controlled by 582 the way the colors are assigned to the pools. To create a full mesh, 583 the "color" would just be a VPN-id. 585 Optionally, a particular Attachment Circuit may be configured with 586 the relative pool identifier of a remote pool. Then that Attachment 587 Circuit would be bound to a particular pseudowire only if that 588 pseudowire's remote endpoint is the pool with that relative pool 589 identifier. With this option, the same pairs of Attachment Circuits 590 will always be bound via pseudowires. 592 3.3.2. Auto-Discovery 594 3.3.2.1. BGP-based auto-discovery 596 The framework for BGP-based auto-discovery for a colored pool service 597 is as specified in [BGP-AUTO], section 3.2. 599 The AFI/SAFI used would be: 601 - An AFI specified by IANA for L2VPN. (This is the same for all 602 L2VPN schemes.) 604 - An SAFI specified by IANA specifically for an L2VPN (VPLS or 605 VPWS) service whose pseudowires are set up using the procedures 606 described in the current document. 608 In order to use BGP-based auto-discovery, the color associated with a 609 colored pool must be encodable as both an RT (Route Target) and an RD 610 (Route Distinguisher). The globally unique identifier of a pool must 611 be encodable as NLRI; the color would be encoded as the RD and the 612 pool identifier as a four-byte quantity which is appended to the RD 613 to create the NLRI. 615 Auto-discovery procedures by having each PE distribute, via BGP, the 616 NLRI for each of its pools, with itself as the BGP next hop, and with 617 the RT that encodes the pool's color. If a given PE has a pool with 618 a particular color (RT), it must receive, via BGP, all NLRI with that 619 same color (RT). Typically, each PE would be a client of a small set 620 of BGP route reflectors, which would redistribute this information to 621 the other clients. 623 If a PE has a pool with a particular color, it can then receive all 624 the NLRI which have that same color, and from the BGP next hop 625 attribute of these NLRI will learn the IP addresses of the other PE 626 routers which have pools switches with the same color. It also 627 learns the unique identifier of each such remote pool, as this is 628 encoded in the NLRI. The remote pool's relative identifier can be 629 extracted from the NLRI and used in the signaling, as specified 630 below. 632 3.3.3. Signaling 634 When a PE sends a Label Mapping message or an ICRQ message to set up 635 a PW between two pools, it encodes the color as the AGI, the local 636 pool's relative identifier as the SAII, and the remote pool's 637 relative identifier as the TAII. 639 When PE2 receives a Label Mapping message or an ICRQ message from 640 PE1, and the TAI identifies to a pool, and there is already an 641 pseudowire connecting an Attachment Circuit in that pool to an 642 Attachment Circuit at PE1, and the AI at PE1 of that pseudowire is 643 the same as the SAI of the Label Mapping or ICRQ message, then PE2 644 sends a Label Release or CDN message to PE1, with a Status Code 645 meaning "Attachment Circuit already bound to remote Attachment 646 Circuit". This prevents the creation of multiple pseudowires between 647 a given pair of pools. 649 Note that the signaling itself only identifies the remote pool to 650 which the pseudowire is to lead, not the remote Attachment Circuit 651 which is to be bound to the the pseudowire. However, the remote PE 652 may examine the SAII field to determine which Attachment Circuit 653 should be bound to the pseudowire. 655 3.4. Colored Pools: Partial Mesh 657 The procedures for creating a partial mesh of pseudowires among a set 658 of colored pools are substantially the same as those for creating a 659 full mesh, with the following exceptions: 661 - Each pool is optionally configured with a set of "import RTs" and 662 "export RTs"; 664 - During BGP-based auto-discovery, the pool color is still encoded 665 in the RD, but if the pool is configured with a set of "export 666 RTs", these are are encoded in the RTs of the BGP Update 667 messages, INSTEAD the color. 669 - If a pool has a particular "import RT" value X, it will create a 670 PW to every other pool which has X as one of its "export RTs". 671 The signaling messages and procedures themselves are as in 672 section 3.3.3. 674 3.5. Distributed VPLS 676 In Distributed VPLS ([L2VPN-FW], [DTLS], [LPE]), the VPLS 677 functionality of a PE router is divided among two systems: a U-PE and 678 an N-PE. The U-PE sits between the user and the N-PE. VSI 679 functionality (e.g., MAC address learning and bridging) is performed 680 on the U-PE. A number of U-PEs attach to an N-PE. For each VPLS 681 supported by a U-PE, the U-PE maintains a pseudowire to each other 682 U-PE in the same VPLS. However, the U-PEs do not maintain signaling 683 control connections with each other. Rather, each U-PE has only a 684 single signaling connection, to its N-PE. In essence, each U-PE-to- 685 U-PE pseudowire is composed of three pseudowires spliced together: 686 one from U-PE to N-PE, one from N-PE to N-PE, and one from N-PE to 687 U-PE. 689 Consider for example the following topology: 691 U-PE A-----| |----U-PE C 692 | | 693 | | 694 N-PE E--------N-PE F 695 | | 696 | | 697 U-PE B-----| |-----U-PE D 699 where the four U-PEs are in a common VPLS. We now illustrate how PWs 700 get spliced together in the above topology in order to establish the 701 necessary PWs from U-PE A to the other U-PEs. 703 There are three PWs from A to E. Call these A-E/1, A-E/2, and A-E/3. 704 In order to connect A properly to the other U-PEs, there must be two 705 PWs from E to F (call these E-F/1 and E-F/2), one PW from E to B (E- 706 B/1), one from F to C (F-C/1), and one from F to D (F-D/1). 708 The N-PEs must then splice these pseudowires together to get the 709 equivalent of what the non-distributed VPLS signaling mechanism would 710 provide: 712 - PW from A to B: A-E/1 gets spliced to E-B/1. 714 - PW from A to C: A-E/2 gets spliced to E-F/1 gets spliced to F- 715 C/1. 717 - PW from A to D: A-E/3 gets spliced to E-F/2 gets spliced to F- 718 D/1. 720 It doesn't matter which PWs get spliced together, as long as the 721 result is one from A to each of B, C, and D. 723 Similarly, there are additional PWs which must get spliced together 724 to properly interconnect U-PE B with U-PEs C and D, and to 725 interconnect U-PE C with U-PE D. 727 One can see that distributed VPLS does not reduce the number of 728 pseudowires per U-PE, but it does reduce the number of control 729 connections per U-PE. Whether this is worthwhile depends, of course, 730 on what the bottleneck is. 732 3.5.1. Signaling 734 The signaling to support Distributed VPLS can be done with the 735 mechanisms described in this paper. However, the procedures for VPLS 736 (section 3.2.3) presuppose that, between a pair of PEs, there is only 737 one PW per VPLS. In distributed VPLS, this isn't so. In the 738 topology above, for example, there are two PWs between A and E for 739 the same VPLS. For distributed VPLS therefore, one cannot identify 740 the Forwarders merely by using the VPN-id as the AGI, while using 741 null values of the SAII and TAII. Rather, the SAII and TAII must be 742 used to identify particular U-PE devices. 744 At a given N-PE, the directly attached U-PEs in a given VPLS can be 745 numbered from 1 to n. This number identifies the U-PE relative to a 746 particular VPN-id and a particular PE. (That is, to uniquely 747 identify the U-PE, the N-PE, the VPN-id, and the U-PE number must be 748 known.) 750 As a result of configuration/discovery, each U-PE must be given a 751 list of pairs. Each element in this list tells the 752 U-PE to set up j PWs to the specified IP address. When the U-PE 753 signals to the N-PE, it sets the AGI to the proper-VPN-id, and sets 754 the SAII to the PW number, and sets the TAII to null. 756 In the above example, U-PE A would be told <3, E>, telling it to set 757 up 3 PWs to E. When signaling, A would set the AGI to the proper 758 VPN-id, and would set the SAII to 1, 2, or 3, depending on which of 759 the three PWs it is signaling. 761 As a result of configuration/discovery, each N-PE must be given the 762 following information for each VPLS: 764 - A "Local" list: {}, where each element tells it to 765 set up j PWs to the locally attached U-PE at the specified 766 address. The number of elements in this list will be n, the 767 number of locally attached U-PEs in this VPLS. In the above 768 example, E would be given the local list: {<3, A>, <3, B>}, 769 telling it to set up 3 PWs to A and 3 to B. 771 - A local numbering, relative to the particular VPLS and the 772 particular N-PE, of its U-PEs. In the above example, E could be 773 told that U-PE A is 1, and U-PE B is 2. 775 - A "Remote" list: {}, telling it to set up k PWs, 776 for each U-PE, to the specified IP address. Each of these IP 777 addresses identifies a N-PE, and k specifies the number of U-PEs 778 at that N-PE which are in the VPLS. In the above example, E 779 would be given the remote list: {<2, F>}. Since N-PE E has two 780 U-PEs, this tells it to set up 4 PWs to N-PE F, 2 for each of its 781 E's U-PEs. 783 The signaling of a PW from N-PE to U-PE is based on the local list 784 and the local numbering of U-PEs. When signaling a particular PW 785 from an N-PE to a U-PE, the AGI is set to the proper VPN-id, and SAII 786 is set to null, and the TAII is set to the PW number (relative to 787 that particular VPLS and U-PE). In the above example, when E signals 788 to A, it would set the TAII to be 1, 2, or 3, respectively, for the 789 three PWs it must set up to A. It would similarly signal three PWs 790 to B. 792 The LSP signaled from U-PE to N-PE is associated with an LSP from N- 793 PE to U-PE in the usual manner. A PW between a U-PE and an N-PE is 794 known as a "U-PW". 796 The signaling of a PW from N-PE to N-PE is based on the remote list. 797 When signaling a particular PW from an N-PE to an N-PE, the AGI is 798 set to the appropriate VPN-id. The remote list specifies the number 799 of PWs to set up, per local U-PE, to a particular remote N-PE. If 800 there are n such PWs, they are distinguished by the setting of the 801 TAII, which will be a number from 1 to n inclusive. The SAII is set 802 to the local number of the U-PE. In the above example, E would set 803 up 4 PWs to F. The SAII/TAII fields would be set to 1/1, 1/2, 2/1, 804 and 2/2 respectively. A PW between two N-PEs is known as an "N-PW". 806 Each U-PW must be "spliced" to an N-PW. This is based on the remote 807 list. If the remote list contains an element , then i U-PWs 808 from each local U-PE must be spliced to i N-PWs from the remote N-PE 809 F. It does not matter which U-PWs are spliced to which N-PWs, as 810 long as this constraint is met. 812 If an N-PE has more than one local U-PE for a given VPLS, it must 813 also ensure that a U-PW from each such U-PE is spliced to a U-PW 814 from each of the other U-PEs. 816 3.5.2. Provisioning and Discovery 818 Every N-PE must be provisioned with the set of VPLS instances it 819 supports, a VPN-id for each one, and a list of local U-PEs for each 820 such VPLS. As part of the discovery procedure, the N-PE advertises 821 the number of U-PEs for each VPLS. 823 Auto-discovery (e.g., BGP-based) can be used to discover all the 824 other N-PEs in the VPLS, and for each, the number of U-PEs local to 825 that N-PE. From this, one can compute the total number of U-PEs in 826 the VPLS. This information is sufficient to enable one to compute 827 the local list and the remote list for each N-PE. 829 3.5.3. Non-distributed VPLS as a sub-case 831 A PE which is providing "non-distributed VPLS" (i.e., a PE which 832 performs both the U-PE and N-PE functions) can interoperate with N- 833 PE/U-PE pairs that are providing distributed VPLS. The "non- 834 distributed PE" simply advertises, in the discovery procedure, that 835 it has one local U-PE per VPLS. And of course, the non-distributed 836 PE does no splicing. 838 If every PE in a VPLS is providing non-distributed VPLS, and thus 839 every PE advertises itself as an N-PE with one local U-PE, the 840 resultant signaling is exactly the same as that specified in section 841 3.2.3 above, except that SAII and TAII values of 1 are used instead 842 of SAII and TAII values of null. (A PE providing non-distributed 843 VPLS should therefore treat AII values of 1 the same as it treats AII 844 values of null.) 846 3.5.4. Inter-Provider Application of Dist. VPLS Signaling 848 Consider the following topology: 850 PE A ---- Network 1 ----- Border ----- Border ----- Network 2 ---- PE B 851 Router 12 Router 21 | 852 | 853 PE C 855 where A, B, and C are PEs in a common VPLS, but Networks 1 and 2 are 856 networks of different Service Providers. Border Router 12 is 857 Network 1's border router to network 2, and Border Router 21 is 858 Network 2's border router to Network 1. We suppose further that the 859 PEs are not "distributed", i.e, that each provides both the U-PE and 860 N-PE functions. 862 In this topology, one needs two inter-provider pseudowires: A-B and 863 A-C. 865 Suppose a Service Provider decides, for whatever reason, that it does 866 not want each of its PEs to have a control connection to any PEs in 867 the other network. Rather, it wants the inter-provider control 868 connections to run only between the two border routers. 870 This can be achieved using the techniques of section 3.5, where the 871 PEs behave like U-PEs, and the BRs behave like N-PEs. In the example 872 topology, PE A would behave like a U-PE which is locally attached to 873 BR12; PEs B and C would be have like U-PEs which are locally attached 874 to BR21; and the two BRs would behave like N-PEs. 876 As a result, the PW from A to B would consist of three segments: A- 877 BR12, BR12-BR21, and BR21-B. The border routers would have to splice 878 the corresponding segments together. 880 This requires the PEs within a VPLS to be numbered from 1-n (relative 881 to that VPLS) within a given network. 883 3.5.5. Splicing and the Data Plane 885 Splicing two PWs together is quite straightforward in the MPLS data 886 plane, as moving a packet from one PW directly to another is just a 887 label replace operation on the PW label. When a PW consists of two 888 PWs spliced together, it is assumed that the data will go to the node 889 where the splicing is being done, i.e., that the data path will 890 include the control points. 892 In some cases, it may be desired to have the data go on a more direct 893 route from one "true endpoint" to another, without necessarily 894 passing through the splice points. This could be done by means of a 895 new LDP TLV carried in the LDP mapping message; call it the "direct 896 route" TLV. A direct route TLV would be placed in an LDP Label 897 Mapping message by the LSP's "true endpoint". The TLV would specify 898 the IP address of the true endpoint, and would also specify a label, 899 representing the pseudowire, which is assigned by that endpoint. 900 When PWs are spliced together at intermediate control points, this 901 TLV would simply be passed upstream. Then when a frame is first put 902 on the pseudowire, it can be given this pseudowire label, and routed 903 to the true endpoint, thereby possibly bypassing the intermediate 904 control points. 906 4. Security Considerations 908 This document describes a number of different L2VPN provisioning 909 models, and specifies the endpoint identifiers that are required to 910 support each of the provisioning models. It also specifies how those 911 endpoint identifiers are mapped into fields of auto-discovery 912 protocols and signaling protocols. 914 The security considerations related to the signaling and auto- 915 discovery protocols are discussed in the relevant protocol 916 specifications ([BGP-AUTO], [L2TP-BASE], [L2TP-L2VPN], [LDP], [PWE3- 917 CONTROL]). 919 The security considerations related to the particular kind of L2VPN 920 service being supported are discussed in [L2VPN-REQS], [L2VPN-FW], 921 and [VPLS]. 923 The way in which endpoint identifiers are mapped into protocol fields 924 does not create any additional security issues. 926 5. Acknowledgments 928 Thanks to Dan Tappan, Ted Qian, Bruce Davie, Ali Sajassi, Skip Booth, 929 and Francois LeFaucheur for their comments, criticisms, and helpful 930 suggestions. 932 Thanks to Tissa Senevirathne, Hamid Ould-Brahim and Yakov Rekhter for 933 discussing the auto-discovery issues. 935 Thanks to Vach Kompella for a continuing discussion of the proper 936 semantics of the generalized identifiers. 938 6. References 940 [BGP-AUTO] "Using BGP as an Auto-Discovery Mechanism for Network- 941 based VPNs", Ould-Brahim et. al., draft-ietf-l3vpn-bgpvpn-auto- 942 04.txt, May 2004 944 [L2TP-BASE] "Layer Two Tunneling Protocol (Version 3)", Lau et. al., 945 draft-ietf-l2tpext-l2tp-base-14.txt, June 2004 947 [L2TP-L2VPN] "L2VPN Extensions for L2TP", Luo, draft-ietf-l2tpext- 948 l2vpn-01.txt, Jul 2004 950 [L2VPN-FW] "L2VPN Framework", Andersson et. al., draft-ietf-l2vpn- 951 l2-framework-05.txt, June 2004 953 [L2VPN-REQ] "Service Requirements for Layer 2 Provider Provisioned 954 Virtual Private Network Services", Augustyn, Serbest, et. al., 955 draft-ietf-l2vpn-requirements-02.txt, September 2004 957 [L2VPN-TERM] "PPVPN Terminology", Andersson, Madsen, draft-ietf- 958 l3vpn-ppvpn-terminology-04.txt, September 2004 960 [LDP] "LDP Specification", Andersson, et. al., RFC 3036, Jan 2001 962 [PWE3-ARCH] "PWE3 Architecture", Bryant, Pate, et. al., draft-ietf- 963 pwe3-arch-07.txt, March 2004 965 [PWE3-CONTROL] "Pseudowire Setup and Maintenance using LDP", Martini, 966 et. al., draft-ietf-pwe3-control-protocol-09.txt, September 2004 968 [RFC2547bis], "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., draft- 969 ietf-l3vpn-rfc2547bis-02.txt, September 2004 971 [RFC2685] "Virtual Private Networks Identifier", Fox, Gleeson, 972 September 1999 974 [VPLS] "Virtual Private LAN Services over MPLS", Laserre, et. al., 975 draft-ietf-l2vpn-vpls-ldp-05.txt, September 2004 977 7. Author's Information 979 Eric C. Rosen 980 Cisco Systems, Inc. 981 1414 Massachusetts Avenue 982 Boxborough, MA 01719 983 E-mail: erosen@cisco.com 985 Wei Luo 986 Cisco Systems, Inc. 987 170 W. Tasman Drive 988 San Jose, CA 95134 989 E-mail: luo@cisco.com 991 Vasile Radoaca 992 Nortel Networks 993 600 Technology Park 994 Billerica, MA 01821 995 Phone: (781) 856-0590/978-288-6097 997 8. Intellectual Property Statement 999 The IETF takes no position regarding the validity or scope of any 1000 Intellectual Property Rights or other rights that might be claimed to 1001 pertain to the implementation or use of the technology described in 1002 this document or the extent to which any license under such rights 1003 might or might not be available; nor does it represent that it has 1004 made any independent effort to identify any such rights. Information 1005 on the procedures with respect to rights in RFC documents can be 1006 found in BCP 78 and BCP 79. 1008 Copies of IPR disclosures made to the IETF Secretariat and any 1009 assurances of licenses to be made available, or the result of an 1010 attempt made to obtain a general license or permission for the use of 1011 such proprietary rights by implementers or users of this 1012 specification can be obtained from the IETF on-line IPR repository at 1013 http://www.ietf.org/ipr. 1015 The IETF invites any interested party to bring to its attention any 1016 copyrights, patents or patent applications, or other proprietary 1017 rights that may cover technology that may be required to implement 1018 this standard. Please address the information to the IETF at ietf- 1019 ipr@ietf.org. 1021 9. Full Copyright Statement 1023 Copyright (C) The Internet Society (2004). This document is subject 1024 to the rights, licenses and restrictions contained in BCP 78 and 1025 except as set forth therein, the authors retain all their rights. 1027 This document and the information contained herein are provided on an 1028 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1029 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1030 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1031 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1032 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1033 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.