idnits 2.17.1 draft-ietf-l2tpext-l2vpn-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 580. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 586. ** 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, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 162 has weird spacing: '...part of their...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 2005) is 6893 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 47, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-14 Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Wei Luo 3 Internet Draft Cisco Systems, Inc. 4 May 2005 6 L2VPN Extensions for L2TP 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 or will be disclosed, and any of which I become aware will be 13 disclosed, in accordance with RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The Layer 2 Tunneling Protocol (L2TP) provides a standard method for 34 setting up and managing L2TP sessions to tunnel a variety of L2 35 protocols. One of the reference models supported by L2TP describes 36 the use of an L2TP session to connect two Layer 2 circuits attached 37 to a pair of peering LACs, which is a basic form of Layer 2 Virtual 38 Private Network (L2VPN). This document defines the protocol 39 extensions for L2TP to set up different types of L2VPN in a unified 40 fashion. 42 Specification of Requirements 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in [RFC 2119]. 48 Table of Contents 50 Status of this Memo.......................................... 1 52 1. Introduction.............................................. 3 54 2. Network Reference Model................................... 3 56 3. Forwarder Identifier...................................... 4 58 4. Protocol Components....................................... 5 59 4.1 Control Messages...................................... 5 60 4.2 Existing AVPs for L2VPN............................... 5 61 4.3 New AVPs for L2VPN.................................... 6 63 5. Signaling Procedures...................................... 8 64 5.1 Overview.............................................. 8 65 5.2 Pseudowire Tie Detection.............................. 9 66 5.3 Generic Algorithm..................................... 9 68 6. IANA Considerations....................................... 13 70 7. Security Considerations................................... 14 72 8. Intellectual Property Statement........................... 14 74 9. Full Copyright Statement.................................. 14 76 10. Acknowledgement.......................................... 15 78 11. References............................................... 15 79 11.1 Normative References................................. 15 80 11.2 Informative References............................... 15 82 12. Authors' Address......................................... 15 84 1. Introduction 86 [L2TPv3] defines a dynamic tunneling mechanism to carry multiple L2 87 protocols besides PPP (as originally defined in [RFC 2661]) over a 88 packet-based network. The baseline protocol supports various types 89 of applications, which have been highlighted in the different L2TP 90 reference models in [L2TPv3]. L2VPN applications are typically in 91 the scope of the LAC-LAC reference model. 93 This document discusses the commonalities as well as differences 94 among L2VPN applications with respect to utilizing L2TPv3 as the 95 signaling protocol. 97 The acronym "L2TP" refers to L2TPv3 or L2TP in general in this 98 document. 100 2. Network Reference Model 102 In the LAC-LAC reference model, a LAC serves as a cross-connect 103 between attachment circuits and L2TP sessions. Each L2TP session 104 acts as an emulated circuit, also known as pseudowire. A pseudowire 105 is used to bind two "forwarders" together. For different L2VPN 106 applications, different types of forwarders are defined. 108 In the L2VPN framework [L2VPN FW], a LAC is a Provider Edge (PE) 109 device. LAC and PE are interchangeable terms in the context of this 110 document. Remote systems in the LAC-LAC reference model are Customer 111 Edge (CE) devices. 113 +----+ L2 +----+ +----+ L2 +----+ 114 | CE |------| PE |....[core network]....| PE |------| CE | 115 +----+ +----+ +----+ +----+ 117 |<- emulated service ->| 118 |<----------------- L2 service -------------->| 120 L2VPN Network Reference Model 122 In a simple cross-connect application, an attachment circuit is a 123 forwarder directly bound to a pseudowire. It is a one-to-one 124 mapping. Traffic received from the attachment circuit on a local PE 125 is forwarded to the remote PE through the pseudowire. When the 126 remote PE receives traffic from the pseudowire, it forwards the 127 traffic to the corresponding attachment circuit on its end. The 128 forwarding decision is based on the attachment circuit or pseudowire 129 demultiplexing identifier. 131 With Virtual Private LAN Service (VPLS), a Virtual Switching Instance 132 (VSI) is a forwarder connected to one or more attachment circuits and 133 pseudowires. A single pseudowire is used to connect a pair of VSIs 134 on two peering PEs. Traffic received from an attachment circuit or a 135 pseudowire is first forwarded to the corresponding VSI based on the 136 attachment circuit or pseudowire demultiplexing identifier. The VSI 137 performs additional lookup to determine where to further forward the 138 traffic. 140 With Virtual Private Wire Service (VPWS), attachment circuits are 141 grouped into "colored pools". Each pool is a forwarder and connected 142 through a network of point-to-point cross-connect. The data 143 forwarding perspective is identical to the cross-connect application. 144 However, constructing colored pools involves more complicated 145 signaling procedures. 147 3. Forwarder Identifier 149 A forwarder identifier is assigned to each forwarder on a given PE 150 and is unique in the context of the PE. It is defined as the 151 concatenation of an Attachment Group Identifier (AGI) and an 152 Attachment Individual Identifier (AII), denoted as . The 153 AGI is used to group a set of forwarders together for signaling 154 purpose. An AII is used to distinguish forwarders within a group. 155 AII can be unique at a per platform or per group basis. 157 As far as the signaling procedures are concerned, a forwarder 158 identifier is an arbitrary string of bytes. It is up to 159 implementations to decide the values for AGI and AII. 161 When connecting two forwarders together, both MUST have the same AGI 162 as part of their forwarder identifiers. The AII of the source 163 forwarder is known as the Source AII (SAII), and the AII of the 164 target forwarder is known as the Target AII (TAII). Therefore, 165 source forwarder and target forwarder can be denoted as 166 and respectively. 168 4. Protocol Components 170 4.1 Control Messages 172 L2TP defines two sets of session management procedures: incoming call 173 and outgoing call. Even though it is entirely possible to use the 174 outgoing call procedures to signaling L2VPNs, the incoming call 175 procedures has some advantages in terms of the relevance of the 176 semantics. [PWE3L2TP] gives more details on why the incoming call 177 procedures are more appropriate for setting up pseudowires. 179 The signaling procedures for L2VPNs described in the following 180 sections are based on the Incoming Call procedures. 182 4.2 Existing AVPs for L2VPN 184 Router ID 186 The Router ID sent in SCCRQ and SCCRP during control connection setup 187 establishes the unique identity of each PE. 189 Pseudowire Capabilities List 191 The Pseudowire Capabilities List sent in the SCCRQ and SCCRP 192 indicates the pseudowire types supported by the sending PE. It 193 merely serves as an advertisement to the receiving PE. Its content 194 should not affect the control connection setup. 196 Before a local PE initiates a session of a particular pseudowire type 197 to a remote PE, it MUST examine whether the remote PE has advertised 198 this pseudowire type in this AVP, and SHOULD NOT attempt to initiate 199 the session if the intended pseudowire type is not supported by the 200 remote PE. 202 Pseudowire Type 204 The Pseudowire Type sent in ICRQ signals the intended pseudowire type 205 to the receiving PE. The receiving PE checks it against its local 206 pseudowire capabilities list. If it finds a match, it responds with 207 an ICRP without a Pseudowire Type AVP, which implicitly acknowledges 208 its acceptance of the intended pseudowire. If it does not find a 209 match, it MUST respond with a CDN with an "unsupported pseudowire 210 type" result code. 212 L2-Specific Sublayer 214 The L2-Specific Sublayer can be sent in ICRQ, ICRP, and ICCN. If the 215 receiving PE supports the specified L2-Specific Sublayer, it MUST 216 include the identified L2-Specific Sublayer in its data packets sent 217 to the sending PE. Otherwise, it MUST reject the connection by 218 sending a CDN to the sending PE. 220 Circuit Status 222 The Circuit Status is sent in both ICRQ and ICRP to inform the 223 receiving PE about the circuit status on the sending PE. It can also 224 be sent in ICCN and SLI to update the status. 226 Remote End Identifier 228 The TAII value is encoded in the Remote End ID AVP and sent in ICRQ 229 along with the optional AGI to instruct the receiving PE to bind the 230 proposed pseudowire to the forwarder that matches the specified 231 forwarder identifier. 233 4.3 New AVPs for L2VPN 235 Attachment Group Identifier 237 The AGI AVP, Attribute Type TBA, is an identifier used to associate a 238 forwarder to a logical group. The AGI AVP is used in conjunction 239 with the Local End ID AVP and Remote End ID AVP, which encode the 240 SAII and TAII respectively, to identify a specific forwarder. When 241 the AGI AVP is omitted in the control messages or contains a zero- 242 length value, the forwarders are considered using the default AGI. 243 Note that there is only one designated default AGI value for all 244 forwarders. 246 The Attribute Value field for this AVP has the following format: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 |M|H|0|0|0|0| Length | 0 | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | TBA | AGI (variable length) | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 The AGI field is a variable-length field. This AVP MAY be present in 257 ICRQ. 259 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 260 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6 261 plus the length of the AGI field. 263 Local End ID 264 The Local End ID AVP, Attribute Type TBA, encodes the SAII value. 265 The SAII may also be used in conjunction with the TAII to detect 266 pseudowire ties. When it is omitted in the control messages, it is 267 assumed that it has the same value as the TAII. 269 The Attribute Value field for this AVP has the following format: 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 |M|H|0|0|0|0| Length | 0 | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | TBA | SAII (variable length) | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 The SAII field is a variable-length field. This AVP MAY be present 280 in ICRQ. 282 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 283 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6 284 plus the length of the SAII field. 286 Interface Maximum Transmission Unit 288 The Interface Maximum Transmission Unit (MTU) AVP, Attribute Type 289 TBA, indicates the MTU in octets of an L2 packet, excluding L2TP 290 encapsulation, that can be sent out from the CE-facing interface. 291 The MTU values of a given pseudowire, if advertised in both 292 directions, MUST be identical. If they do not match, the pseudowire 293 SHOULD NOT be established. When this AVP is omitted in the control 294 messages in either direction, it is assumed that the remote PE has 295 the same interface MTU as the local PE for the pseudowire being 296 signaled. 298 The Attribute Value field for this AVP has the following format: 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 |M|H|0|0|0|0| Length | 0 | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | TBA | Interface MTU | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 The Interface MTU is a 2-octet value. This AVP MAY be present in 309 ICRQ and ICRP. When a PE receives an Interface MTU AVP with an MTU 310 value different from its own, it MAY respond with a CDN with a new 311 result code indicating the disconnect cause. 313 RC-TBA-1 - Mismatching interface MTU 315 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 316 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 8. 318 5. Signaling Procedures 320 5.1 Overview 322 Assume a PE assigns a forwarder identifier to one of its local 323 forwarders, and knows it needs to set up a pseudowire to a remote 324 forwarder on a remote PE that has a certain Forwarder ID. This 325 knowledge can be obtained either through manual configuration or some 326 auto-discovery procedure. 328 Before establishing the intended pseudowire, each pair of peering PEs 329 exchanges control connection messages to establish a control 330 connection. Each advertises its supported pseudowire types in the 331 Pseudowire Capabilities List AVP. 333 After the control connection is established, the local PE examines 334 whether the remote PE supports the pseudowire type it intends to set 335 up. Only if the remote PE supports the intended pseudowire type, it 336 should initiate a pseudowire connection request. 338 When the local PE receives an ICRQ for a pseudowire connection, it 339 examines the forwarder identifier encoded in the AGI, SAII, and TAII 340 in order to determine the following: 342 - whether it has a local forwarder with the forwarder identifier 343 value specified in the ICRQ, 345 - whether the remote forwarder with the forwarder identifier 346 specified in the ICRQ is allowed to connect with this local 347 forwarder. 349 If both conditions are met, it sends an ICRP to the remote PE to 350 accept the connection request. If either of the two conditions 351 fails, it sends a CDN to the remote PE to reject the connection 352 request. 354 The local PE can optionally include a result code in the CDN to 355 indicate the disconnect cause. The possible result codes are: 357 RC-TBA-2 - Attempt to connect to non-existent forwarder 358 RC-TBA-3 - Attempt to connect to unauthorized forwarder 360 5.2 Pseudowire Tie Detection 362 Conceivably in the network reference models, as either PE may 363 initiate a pseudowire to another PE at any time, the PEs could end up 364 initiating a pseudowire to each other simultaneously. In order to 365 avoid setting up duplicated pseudowires between two forwarders, each 366 PE must be able to independently detect such a pseudowire tie. The 367 following procedures need to be followed to detect a tie: 369 If both TAII and SAII are present in the ICRQ, the receiving PE 370 compares the TAII and SAII against the SAII and TAII itself 371 previously sent to the sending PE. If the received TAII matches the 372 sent SAII and the received SAII matches the sent TAII, a tie is 373 detected. 375 If only the TAII is present in the ICRQ, the SAII is assumed to have 376 the same value as the TAII. The receiving PE compares the received 377 TAII with the SAII that it previously sent to the sending PE. If the 378 SAII in that ICRQ is also omitted, then the value encoded in the sent 379 TAII is used for comparison. If they match, a tie is detected. 381 If the AGI is present, it is first prepended to the TAII and SAII 382 values before the tie detection occurs. 384 Once a tie has been discovered, the standard L2TP tie breaking 385 procedure is used to disconnect the duplicated pseudowire. 387 5.3 Generic Algorithm 389 The following uses a generic algorithm to illustrate the protocol 390 interactions when constructing an L2VPN using L2TP signaling. 392 Each PE first forms a list, SOURCE_FORWARDERS, consisting of all 393 local forwarders of a given VPN. Then it puts all local forwarders 394 that need to be interconnected and all remote forwarders of the same 395 VPN into another list, TARGET_FORWARDERS. The formation of the 396 network topology depends on the content in the SOURCE_FORWARDERS and 397 TARGET_FORWARDERS lists. These two lists can be constructed by 398 manual configuration and/or some auto-discovery procedure. 400 The algorithm is used to set up pseudowires among all the forwarders 401 that intend to be interconnected by iterating through each source and 402 target forwarder. An L2VPN is formed upon finishing the algorithm in 403 every participating PE of this L2VPN. 405 1. Pick the next forwarder, from SOURCE_FORWARDERS. If no 406 forwarder is available for processing, the processing is 407 complete. 409 2. Pick the next forwarder, from TARGET_FORWARDERS. If no 410 forwarder is available for processing, go back to step 1. 412 3. If the two forwarders are associated with different Router 413 IDs, a pseudowire must be established between them. Proceed 414 to step 6. 416 4. Compare the values of the two forwarders. If 417 they match, the source and target forwarders are the same, 418 so no more action is necessary. Go back to step 2. 420 5. As the source and target forwarders both reside on the local 421 PE, no pseudowire is needed. The PE simply creates a local 422 cross-connect between the two forwarders. Go back to step 2. 424 6. As the source and target forwarders reside on different PEs, 425 a pseudowire must be established between them. The PE first 426 examines if the source forwarder has already established a 427 pseudowire to the target forwarder. If so, go back to step 2. 429 7. If no pseudowire is already established between the source and 430 target forwarders, the local PE obtains the address of the 431 remote PE, and establishes a control connection to the remote 432 PE if one does not already exist. 434 8. The local PE sends an ICRQ to the remote PE. The AGI, TAII, 435 and SAII values are encoded in the AGI AVP, the Remote End ID 436 AVP, and the Local End ID AVP respectively. 438 9. If the local PE receives a response corresponding to the 439 ICRQ it just sent, proceed to step 10. Otherwise, if the 440 local PE receives an ICRQ from the same remote PE, proceed 441 to step 11. 443 10. The local PE receives a response from the remote PE. If 444 it is a CDN, go back to step 2. If it's an ICRP, the local 445 PE binds the source forwarder to the pseudowire and sends 446 an ICCN to the remote PE. Go back to step 2. 448 11. If the local PE receives an ICRQ from the same remote PE, 449 it needs to perform session tie detection, as described in 450 Section 5.2. If a session tie is detected, the PE performs 451 tie breaking. 453 12. If the local PE loses the tie breaker, it sends a CDN with 454 the result code that indicates the disconnection is due to 455 losing the tie breaker. Proceed to step 14. 457 13. If the local PE wins the tie breaker, it ignores the remote 458 PE's ICRQ, but acknowledges receipt of the control message 459 and continues waiting for the response from the remote PE. 460 Go to step 10. 462 14. The local PE determines whether it should accept the 463 connection request, as described in the Section 5.1. 464 If it accepts the ICRQ, it sends an ICRP to the remote PE. 466 15. The local PE receives a response from the remote PE. If 467 it is a CDN, go back to step 2. If it is an ICCN, the local 468 PE binds the source forwarder to the pseudowire, go back 469 to step 2. 471 The following diagram illustrates the above procedure: 473 ---------> Pick Next 474 | Source Forwarder 475 | | 476 | | 477 | v N 478 | Found Source Forwarder? ----------> End 479 | | 480 | Y | 481 | v 482 | Pick Next <-------------------------------- 483 | Target Forwarder | 484 | | | 485 | | | 486 | N v | 487 -------- Found Target Forwarder? | 488 | | 489 Y | | 490 v Y Y | 491 Same Router ID? ------> Same Forwarder ID? ------| 492 | | | 493 N | N | | 494 | v | 495 | Create Local -------| 496 v Cross-connect | 497 Pseudowire Already Y | 498 Established Between -------------------------------| 499 Source and Target? | 500 | | 501 N | | 502 v | 503 Local Initiates Pseudowire | 504 Connection Request to Remote | 505 | | 506 | | 507 v | 508 -------> Local Wait for Message | 509 | ----- from Remote -------------- | 510 | | | | 511 | | | | 512 | v v | 513 | Local Receives Pseudowire Local Receives Pseudowire | 514 | Connection Request Connection Response | 515 | from Remote from Remote | 516 | | | | 517 | | | | 518 | v v N | 519 | Perform Pseudowire Connection Accepted? --------| 520 | Tie Detection | | 521 | | Y | | 522 | | v | 523 | | Local Binds Source ---------| 524 | | Forwarder to Pseudowire | 525 | | | 526 | v N N | 527 | Tie Detected? -----> Accept Remote -----> Reject ------| 528 | | Connection Request? Remote Request | 529 | Y | ^ | | 530 | v | | Y | 531 | Perform Tie Breaking | ------> Local Binds ---- 532 | | | Source Forwarder 533 | | | to Pseudowire 534 | v N | 535 | Won Tie Breaking? ------> Disconnect 536 | | Local Connection 537 | Y | 538 | v 539 ------ Ignore Remote 540 Connection Request 542 6. IANA Considerations 544 This document defines three new L2TP control message Attribute Value 545 Pairs (AVPs) to be assigned by the IANA. These are described in 546 Section 4.3 are summarized below: 548 AVP-TBA-1 - Attachment Group Identifier 549 AVP-TBA-2 - Local End Identifier 550 AVP-TBA-3 - Interface Maximum Transmission Unit 552 Section 4.3 and Section 5.1 define three new result codes for the CDN 553 message are to be assigned by the IANA: 555 RC-TBA-1 - Mismatching interface MTU 556 RC-TBA-2 - Attempt to connect to non-existent forwarder 557 RC-TBA-3 - Attempt to connect to unauthorized forwarder 559 7. Security Considerations 561 The signaling procedures described in this document does not incur 562 additional security considerations that L2TP already provisions. 564 8. Intellectual Property Statement 566 The IETF takes no position regarding the validity or scope of any 567 Intellectual Property Rights or other rights that might be claimed to 568 pertain to the implementation or use of the technology described in 569 this document or the extent to which any license under such rights 570 might or might not be available; nor does it represent that it has 571 made any independent effort to identify any such rights. Information 572 on the procedures with respect to rights in RFC documents can be 573 found in BCP 78 and BCP 79. 575 Copies of IPR disclosures made to the IETF Secretariat and any 576 assurances of licenses to be made available, or the result of an 577 attempt made to obtain a general license or permission for the use of 578 such proprietary rights by implementers or users of this 579 specification can be obtained from the IETF on-line IPR repository at 580 http://www.ietf.org/ipr. 582 The IETF invites any interested party to bring to its attention any 583 copyrights, patents or patent applications, or other proprietary 584 rights that may cover technology that may be required to implement 585 this standard. Please address the information to the IETF at ietf- 586 ipr@ietf.org. 588 9. Full Copyright Statement 590 Copyright (C) The Internet Society (2004). This document is subject 591 to the rights, licenses and restrictions contained in BCP 78 and 592 except as set forth therein, the authors retain all their rights. 594 This document and the information contained herein are provided on an 595 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 596 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 597 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 598 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 599 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 600 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 602 10. Acknowledgement 604 The author would like to thank Mark Townsley and Carlos Pignataro for 605 their valuable input. 607 11. References 609 11.1 Normative References 611 [L2TPv3] J. Lau et. al., "Layer Two Tunneling Protocol (version3)", 612 draft-ietf-l2tpext-l2tp-base-14.txt, June 2004 614 11.2 Informative References 616 [L2VPN FW] L. Andersson et. al., "PPVPN L2 Framework", 617 draft-ietf-l2vpn-l2-framework-05.txt, June 2004 619 [PWE3L2TP] W. Townsley, "Pseudowires and L2TPv3", 620 draft-townsley-pwe3-l2tpv3-01.txt, June 2003 622 [RFC 2661] W. Townsley et. al., "Layer 2 Tunnel Protocol (L2TP)", 623 RFC 2661, August 1999. 625 12. Authors' Address 627 Wei Luo 628 Cisco Systems, Inc. 629 170 West Tasman Drive 630 San Jose, CA 95134 631 Email: luo@cisco.com