idnits 2.17.1 draft-ietf-l2tpext-l2vpn-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 152 has weird spacing: '...part of their...' -- 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 (July 2004) is 7225 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 45, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-04 == 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 (-01) exists of draft-townsley-pwe3-l2tpv3-00 -- Possible downref: Normative reference to a draft: ref. 'PWE3L2TP' Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Wei Luo 2 Internet Draft Cisco Systems, Inc. 3 July 2004 5 L2VPN Extensions for L2TP 6 draft-ietf-l2tpext-l2vpn-01.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 The Layer 2 Tunneling Protocol (L2TP) provides a standard method for 32 setting up and managing L2TP sessions to tunnel a variety of L2 33 protocols. One of the reference models supported by L2TP describes 34 the use of an L2TP session to connect two Layer 2 circuits attached 35 to a pair of peering LACs, which is a basic form of Layer 2 Virtual 36 Private Network (L2VPN). This document defines the protocol 37 extensions for L2TP to set up different types of L2VPN in a unified 38 fashion. 40 Specification of Requirements 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in [RFC 2119]. 46 Table of Contents 48 Status of this Memo.......................................... 1 50 1. Introduction.............................................. 2 52 2. Network Reference Model................................... 3 54 3. Forwarder Identifier...................................... 4 56 4. Protocol Components....................................... 4 57 4.1 Control Messages...................................... 4 58 4.2 Existing AVPs for L2VPN............................... 4 59 4.3 New AVPs for L2VPN.................................... 5 61 5. Signaling Procedures...................................... 7 62 5.1 Overview.............................................. 7 63 5.2 Pseudowire Tie Detection.............................. 8 64 5.3 Generic Algorithm..................................... 8 66 6. IANA Considerations....................................... 12 68 7. Security Considerations................................... 12 70 8. References................................................ 12 72 9. Authors' Address.......................................... 13 74 1. Introduction 76 [L2TPv3] defines a dynamic tunneling mechanism to carry multiple L2 77 protocols besides PPP (as originally defined in [RFC 2661]) over a 78 packet-based network. The baseline protocol supports various types 79 of applications, which have been highlighted in the different L2TP 80 reference models in [L2TPv3]. L2VPN applications are typically in 81 the scope of the LAC-LAC reference model. 83 This document discusses the commonalities as well as differences 84 among L2VPN applications with respect to utilizing L2TPv3 as the 85 signaling protocol. 87 The acronym "L2TP" refers to L2TPv3 or L2TP in general in this 88 document. 90 2. Network Reference Model 92 In the LAC-LAC reference model, a LAC serves as a cross-connect 93 between attachment circuits and L2TP sessions. Each L2TP session 94 acts as an emulated circuit, also known as pseudowire. A pseudowire 95 is used to bind two "forwarders" together. For different L2VPN 96 applications, different types of forwarders are defined. 98 In the L2VPN framework [L2VPN FW], a LAC is a Provider Edge (PE) 99 device. LAC and PE are interchangable terms in the context of this 100 document. Remote systems in the LAC-LAC reference model are Customer 101 Edge (CE) devices. 103 +----+ L2 +----+ +----+ L2 +----+ 104 | CE |------| PE |....[core network]....| PE |------| CE | 105 +----+ +----+ +----+ +----+ 107 |<- emulated service ->| 108 |<----------------- L2 service -------------->| 110 L2VPN Network Reference Model 112 In a simple cross-connect application, an attachment circuit is a 113 forwarder directly bound to a pseudowire. It is a one-to-one 114 mapping. Traffic received from the attachment circuit on a local PE 115 is forwarded to the remote PE through the pseudowire. When the 116 remote PE receives traffic from the pseudowire, it forwards the 117 traffic to the corresponding attachment circuit on its end. The 118 forwarding decision is based on the attachment circuit or pseudowire 119 demultiplexing identifier. 121 With Virtual Private LAN Service (VPLS), a Virtual Switching Instance 122 (VSI) is a forwarder connected to one or more attachment circuits and 123 pseudowires. A single pseudowire is used to connect a pair of VSIs 124 on two peering PEs. Traffic received from an attachment circuit or a 125 pseudowire is first forwarded to the corresponding VSI based on the 126 attachment circuit or pseudowire demutiplexing identifier. The VSI 127 performs additional lookup to determine where to further forward the 128 traffic. 130 With Virtual Private Wire Service (VPWS), attachment circuits are 131 grouped into "colored pools". Each pool is a forwarder and connected 132 through a network of point-to-point cross-connect. The data 133 forwarding perspective is identical to the cross-connect application. 134 However, constructing colored pools involves more complicated 135 signaling procedures. 137 3. Forwarder Identifier 139 A forwarder identifier is assigned to each forwarder on a given PE 140 and is unique in the context of the PE. It is defined as the 141 concatenation of an Attachment Group Identifier (AGI) and an 142 Attachment Individual Identifier (AII), denoted as . The 143 AGI is used to group a set of forwarders together for signaling 144 purpose. An AII is used to distinguish forwarders within a group. 145 AII can be unique at a per platform or per group basis. 147 As far as the signaling procedures are concerned, a forwarder 148 identifier is an arbitrary string of bytes. It is up to 149 implementations to decide the values for AGI and AII. 151 When connecting two forwarders together, both MUST have the same AGI 152 as part of their forwarder identifiers. The AII of the source 153 forwarder is known as the Source AII (SAII), and the AII of the 154 target forwarder is known as the Target AII (TAII). Therefore, 155 source forwarder and target forwarder can be denoted as 156 and respectively. 158 4. Protocol Components 160 4.1 Control Messages 162 L2TP defines two sets of session management procedures: incoming call 163 and outgoing call. Even though it is entirely possible to use the 164 outgoing call procedures to signaling L2VPNs, the incoming call 165 procedures has some advantages in terms of the relevance of the 166 semantics. [PWE3L2TP] gives more details on why the incoming call 167 procedures are more appropriate for setting up pseudowires. 169 The signaling procedures for L2VPNs described in the following 170 sections are based on the Incoming Call procedures. 172 4.2 Existing AVPs for L2VPN 174 Router ID 176 The Router ID sent in SCCRQ and SCCRP during control connection setup 177 establishes the unique identity of each PE. 179 Pseudowire Capabilities List 181 The Pseudowire Capabilities List sent in the SCCRQ and SCCRP 182 indicates the pseudowire types supported by the sending PE. It 183 merely serves as an advertisement to the receiving PE. Its content 184 should not affect the control connection setup. 186 Before a local PE initiates a session of a particular pseudowire type 187 to a remote PE, it MUST examine whether the remote PE has advertised 188 this pseudowire type in this AVP, and SHOULD NOT attempt to initiate 189 the session if the intended pseudowire type is not supported by the 190 remote PE. 192 Pseudowire Type 194 The Pseudowire Type sent in ICRQ signals the intended pseudowire type 195 to the receiving PE. The receiving PE checks it against its local 196 pseudowire capabilities list. If it finds a match, it responds with 197 an ICRP without a Pseudowire Type AVP, which implicitly acknowledges 198 its acceptance of the intended pseudowire. If it does not find a 199 match, it MUST respond with a CDN with an "unsupported pseudowire 200 type" result code. 202 Pseudowire Control Encapsulation 204 The Pseudowire Control Encapsulation can be sent in ICRQ, ICRP, and 205 ICCN. If the receiving PE supports the specified control 206 encapsulation, it MUST include it in its data packets sent to the 207 sending PE. Otherwise, it MUST reject the connection by sending a 208 CDN to the sending PE. 210 Circuit Status 212 The Circuit Status is sent in both ICRQ and ICRP to inform the 213 receiving PE about the circuit status on the sending PE. It can also 214 be sent in ICCN and SLI to update the status. 216 Remote End Identifier 218 The TAII value is encoded in the Remote End ID AVP and sent in ICRQ 219 along with the optional AGI to instruct the receiving PE to bind the 220 proposed pseudowire to the forwarder that matches the specified 221 forwarder identifier. 223 4.3 New AVPs for L2VPN 225 Attachment Group Identifier 227 The AGI AVP, Attribute Type TBA, is an identifier used to associate a 228 forwarder to a logical group. The AGI AVP is used in conjunction 229 with the Local End ID AVP and Remote End ID AVP, which encode the 230 SAII and TAII respectively, to identify a specific forwarder. When 231 the AGI AVP is omitted in the control messages or contains a zero- 232 length value, the forwarders are considered using the default AGI. 233 Note that there is only one designated default AGI value for all 234 forwarders. 236 The Attribute Value field for this AVP has the following format: 238 0 1 2 3 239 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 |M|H|0|0|0|0| Length | 0 | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | TBA | AGI (variable length) | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 The AGI field is a variable-length field. This AVP MAY be present in 247 ICRQ. 249 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 250 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6 251 plus the length of the AGI field. 253 Local End ID 255 The Local End ID AVP, Attribute Type TBA, encodes the SAII value. 256 The SAII may also be used in conjunction with the TAII to detect 257 pseudowire ties. When it is omitted in the control messages, it is 258 assumed that it has the same value as the TAII. 260 The Attribute Value field for this AVP has the following format: 262 0 1 2 3 263 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 |M|H|0|0|0|0| Length | 0 | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | TBA | SAII (variable length) | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 The SAII field is a variable-length field. This AVP MAY be present 271 in ICRQ. 273 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 274 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6 275 plus the length of the SAII field. 277 Interface Maximum Transmission Unit 279 The Interface Maximum Transmission Unit (MTU) AVP, Attribute Type 280 TBA, indicates the MTU in octets of an L2 packet, excluding L2TP 281 encapsulation, that can be sent out from the CE-facing interface. 282 The MTU values of a given pseudowire, if advertised in both 283 directions, MUST be identical. If they do not match, the pseudowire 284 SHOULD NOT be established. When it is omitted in the control 285 messages in either direction, it is assumed that the remote PE has 286 the same interface MTU as the local PE for the pseudowire being 287 signaled. 289 The Attribute Value field for this AVP has the following format: 291 0 1 2 3 292 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 |M|H|0|0|0|0| Length | 0 | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | TBA | Interface MTU | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 The Interface MTU is a 2-octet value. This AVP MAY be present in 300 ICRQ and ICRP. 302 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 303 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 8. 305 5. Signaling Procedures 307 5.1 Overview 309 Assume a PE assigns a forwarder identifier to one of its local 310 forwarders, and knows it needs to set up a pseudowire to a remote 311 forwarder on a remote PE that has a certain Forwarder ID. This 312 knowledge can be obtained either through manual configuration or some 313 auto-discovery procedure. 315 Before establishing the intended pseudowire, each pair of peering PEs 316 exchanges control connection messages to establish a control 317 connection. Each advertises its supported pseudowire types in the 318 Pseudowire Capabilities List AVP. 320 After the control connection is established, the local PE examines 321 whether the remote PE supports the pseudowire type it intends to set 322 up. Only if the remote PE supports the intended pseudowire type, it 323 should initiate a pseudowire connection request. 325 When the local PE receives an ICRQ for a pseudowire connection, it 326 examines the forwarder identifier encoded in the AGI, SAII, and TAII 327 in order to determine the following: 329 - whether it has a local forwarder with the forwarder identifier 330 value specified in the ICRQ, 332 - whether the remote forwarder with the forwarder identifier 333 specified in the ICRQ is allowed to connect with this local 334 forwarder. 336 If both conditions are met, it sends an ICRP to the remote PE to 337 accept the connection request. If either of the two conditions 338 fails, it sends a CDN to the remote PE to reject the connection 339 request. 341 5.2 Pseudowire Tie Detection 343 Conceivably in the network reference models, as either PE may 344 initiate a pseudowire to another PE at any time, the PEs could end up 345 initiating a pseudowire to each other simultaneously. In order to 346 avoid setting up duplicated pseudowires between two forwarders, each 347 PE must be able to independently detect such a pseudowire tie. The 348 following procedures need to be followed to detect a tie: 350 If both TAII and SAII are present in the ICRQ, the receiving PE 351 compares the TAII and SAII against the SAII and TAII itself 352 previously sent to the sending PE. If the received TAII matches the 353 sent SAII and the received SAII matches the sent TAII, a tie is 354 detected. 356 If only the TAII is present in the ICRQ, the SAII is assumed to have 357 the same value as the TAII. The receiving PE compares the received 358 TAII with the SAII that it previously sent to the sending PE. If the 359 SAII in that ICRQ is also omitted, then the value encoded in the sent 360 TAII is used for comparison. If they match, a tie is detected. 362 Once a tie has been discovered, the standard L2TP tie breaking 363 procedure is used to disconnect the duplicated pseudowire. 365 5.3 Generic Algorithm 367 The following uses a generic algorithm to illustrate the protocol 368 interactions when constructing an L2VPN using L2TP signaling. 370 Each PE first forms a list, SOURCE_FORWARDERS, consisting of all 371 local forwarders of a given VPN. Then it puts all local forwarders 372 that need to be interconnected and all remote forwarders of the same 373 VPN into another list, TARGET_FORWARDERS. The formation of the 374 network topology depends on the content in the SOURCE_FORWARDERS and 375 TARGET_FORWARDERS list. These two lists can be constructed by manual 376 configuration and/or some auto-discovery procedure. 378 The algorithm is used to set up pseudowires among all the forwarders 379 that intend to be interconnected by iterating through each source and 380 target forwarder. An L2VPN is formed upon finishing the algorithm in 381 every participating PE of this L2VPN. 383 1. Pick the next forwarder, from SOURCE_FORWARDERS. If no 384 forwarder is available for processing, the processing is 385 complete. 387 2. Pick the next forwarder, from TARGET_FORWARDERS. If no 388 forwarder is available for processing, go back to step 1. 390 3. If the two forwarders are associated with different Router 391 IDs, a pseudowire must be established between them. Proceed 392 to step 6. 394 4. Compare the values of the two forwarders. If 395 they match, the source and target forwarders are the same, 396 so no more action is necessary. Go back to step 2. 398 5. As the source and target forwarders both reside on the local 399 PE, no pseudowire is needed. The PE simply creates a local 400 cross-connect between the two forwarders. Go back to step 2. 402 6. As the source and target forwarders reside on different PEs, 403 a pseudowire must be established between them. The PE first 404 examines if the source forwarder has already established a 405 pseudowire to the target forwarder. If so, go back to step 2. 407 7. If no pseudowire is already established between the source and 408 target forwarders, the local PE obtains the address of the 409 remote PE, and establishes a control connection to the remote 410 PE if one does not already exist. 412 8. The local PE sends an ICRQ to the remote PE. The AGI, TAII, 413 and SAII values are encoded in the AGI AVP, the Remote End ID 414 AVP, and the Local End ID AVP respectively. 416 9. If the local PE receives a response corresponding to the 417 ICRQ it just sent, proceed to step 10. Otherwise, if the 418 local PE receives an ICRQ from the same remote PE, proceed 419 to step 11. 421 10. The local PE receives a response from the remote PE. If 422 it is a CDN, go back to step 2. If it's an ICRP, the local 423 PE binds the source forwarder to the pseudowire and sends 424 an ICCN to the remote PE. Go back to step 2. 426 11. If the local PE receives an ICRQ from the same remote PE, 427 it needs to perform session tie detection, as described in 428 Section 5.2. If a session tie is detected, the PE performs 429 tie breaking. 431 12. If the local PE loses the tie breaker, it sends a CDN with 432 the result code that indicates the disconnection is due to 433 losing the tie breaker. Proceed to step 14. 435 13. If the local PE wins the tie breaker, it ignores the remote 436 PE's ICRQ, but acknowledges receipt of the control message 437 and continues waiting for the response from the remote PE. 438 Go to step 10. 440 14. The local PE determines whether it should accept the 441 connection request, as described in the Section 5.1. 442 If it accepts the ICRQ, it sends an ICRP to the remote PE. 444 15. The local PE receives a response from the remote PE. If 445 it is a CDN, go back to step 2. If it is an ICCN, the local 446 PE binds the source forwarder to the pseudowire, go back 447 to step 2. 449 The following diagram illustrates the above procedure: 451 ---------> Pick Next 452 | Source Forwarder 453 | | 454 | | 455 | v N 456 | Found Source Forwarder? ----------> End 457 | | 458 | Y | 459 | v 460 | Pick Next <-------------------------------- 461 | Target Forwarder | 462 | | | 463 | | | 464 | N v | 465 -------- Found Target Forwarder? | 466 | | 467 Y | | 468 v Y Y | 469 Same Router ID? ------> Same Forwarder ID? ------| 470 | | | 471 N | N | | 472 | v | 473 | Create Local -------| 474 v Cross-connect | 475 Pseudowire Already Y | 476 Established Between -------------------------------| 477 Source and Target? | 478 | | 479 N | | 480 v | 481 Local Initiates Pseudowire | 482 Connection Request to Remote | 483 | | 484 | | 485 v | 486 -------> Local Wait for Message | 487 | ----- from Remote -------------- | 488 | | | | 489 | | | | 490 | v v | 491 | Local Receives Pseudowire Local Receives Pseudowire | 492 | Connection Request Connection Response | 493 | from Remote from Remote | 494 | | | | 495 | | | | 496 | v v N | 497 | Perform Pseudowire Connection Accepted? --------| 498 | Tie Detection | | 499 | | Y | | 500 | | v | 501 | | Local Binds Source ---------| 502 | | Forwarder to Pseudowire | 503 | | | 504 | v N N | 505 | Tie Detected? -----> Accept Remote -----> Reject ------| 506 | | Connection Request? Remote Request | 507 | Y | ^ | | 508 | v | | Y | 509 | Perform Tie Breaking | ------> Local Binds ---- 510 | | | Source Forwarder 511 | | | to Pseudowire 512 | v N | 513 | Won Tie Breaking? ------> Disconnect 514 | | Local Connection 515 | Y | 516 | v 517 ------ Ignore Remote 518 Connection Request 520 6. IANA Considerations 522 This document defines two new L2TP AVPs to be maintained by the IANA. 524 7. Security Considerations 526 The signaling procedures described in this document does not incur 527 additional security considerations that L2TP already provisions. 529 8. References 531 [L2TPv3] J. Lau et. al., "Layer Two Tunneling Protocol (version3)", 532 draft-ietf-l2tpext-l2tp-base-04.txt, November 2002 534 [L2VPN FW] L. Andersson et. al., "PPVPN L2 Framework", 535 draft-ietf-l2vpn-l2-framework-03.txt, October 2003 537 [PWE3L2TP] W. Townsley, "Pseudowires and L2TPv3", 538 draft-townsley-pwe3-l2tpv3-00.txt, June 2002 540 [RFC 2661] W. Townsley et. al., "Layer 2 Tunnel Protocol (L2TP)", 541 RFC 2661, August 1999. 543 9. Authors' Address 545 Wei Luo 546 Cisco Systems, Inc. 547 170 West Tasman Drive 548 San Jose, CA 95134 549 Email: luo@cisco.com