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