idnits 2.17.1 draft-ietf-l2tpext-l2vpn-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 632. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 603. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 616. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 == 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 (February 2006) is 6644 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 Summary: 6 errors (**), 0 flaws (~~), 4 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 February 2006 6 L2VPN Extensions for L2TP 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 62 4.4 AVP Interoperability.................................. 8 64 5. Signaling Procedures...................................... 8 65 5.1 Overview.............................................. 8 66 5.2 Pseudowire Tie Detection.............................. 9 67 5.3 Generic Algorithm..................................... 10 69 6. IANA Considerations....................................... 13 71 7. Security Considerations................................... 14 73 8. Intellectual Property Statement........................... 14 75 9. Copyright Notice.......................................... 14 77 10. Acknowledgement.......................................... 15 79 11. References............................................... 15 80 11.1 Normative References................................. 15 81 11.2 Informative References............................... 15 83 12. Authors' Address......................................... 15 85 1. Introduction 87 [RFC3931] defines a dynamic tunneling mechanism to carry multiple 88 Layer 2 protocols besides Point-to-Point Protocol (PPP), the only 89 protocol supported in [RFC 2661], over a packet-based network. The 90 baseline protocol supports various types of applications, which have 91 been highlighted in the different L2TP reference models in [RFC3931]. 92 An L2TP Access Concentrator (LAC) is an L2TP Control Connection 93 Endpoint (LCCE) that cross-connect attachment circuits and L2TP 94 sessions. L2VPN applications are typically in the scope of the LAC- 95 LAC reference model. 97 This document discusses the commonalities as well as differences 98 among L2VPN applications with respect to utilizing L2TPv3 as the 99 signaling protocol. The acronym "L2TP" refers to L2TPv3 or L2TP in 100 general in this document. 102 2. Network Reference Model 104 In the LAC-LAC reference model, a LAC serves as a cross-connect 105 between attachment circuits and L2TP sessions. Each L2TP session 106 acts as an emulated circuit, also known as pseudowire. A pseudowire 107 is used to bind two "forwarders" together. For different L2VPN 108 applications, different types of forwarders are defined. 110 In the L2VPN framework [L2VPN FW], a LAC is a Provider Edge (PE) 111 device. LAC and PE are interchangeable terms in the context of this 112 document. Remote systems in the LAC-LAC reference model are Customer 113 Edge (CE) devices. 115 +----+ L2 +----+ +----+ L2 +----+ 116 | CE |------| PE |....[core network]....| PE |------| CE | 117 +----+ +----+ +----+ +----+ 119 |<- emulated service ->| 120 |<----------------- L2 service -------------->| 122 L2VPN Network Reference Model 124 In a simple cross-connect application, an attachment circuit is a 125 forwarder directly bound to a pseudowire. It is a one-to-one 126 mapping. Traffic received from the attachment circuit on a local PE 127 is forwarded to the remote PE through the pseudowire. When the 128 remote PE receives traffic from the pseudowire, it forwards the 129 traffic to the corresponding attachment circuit on its end. The 130 forwarding decision is based on the attachment circuit or pseudowire 131 demultiplexing identifier. 133 With Virtual Private LAN Service (VPLS), a Virtual Switching Instance 134 (VSI) is a forwarder connected to one or more attachment circuits and 135 pseudowires. A single pseudowire is used to connect a pair of VSIs 136 on two peering PEs. Traffic received from an attachment circuit or a 137 pseudowire is first forwarded to the corresponding VSI based on the 138 attachment circuit or pseudowire demultiplexing identifier. The VSI 139 performs additional lookup to determine where to further forward the 140 traffic. 142 With Virtual Private Wire Service (VPWS), attachment circuits are 143 grouped into "colored pools". Each pool is a forwarder and connected 144 through a network of point-to-point cross-connects. The data 145 forwarding perspective is identical to the cross-connect application. 146 However, constructing colored pools involves more complicated 147 signaling procedures. 149 3. Forwarder Identifier 151 A forwarder identifier is assigned to each forwarder on a given PE 152 and is unique in the context of the PE. It is defined as the 153 concatenation of an Attachment Group Identifier (AGI) and an 154 Attachment Individual Identifier (AII), denoted as . The 155 AGI is used to group a set of forwarders together for signaling 156 purpose. An AII is used to distinguish forwarders within a group. 157 AII can be unique at a per platform or per group basis. 159 As far as the signaling procedures are concerned, a forwarder 160 identifier is an arbitrary string of bytes. It is up to 161 implementations to decide the values for AGI and AII. 163 When connecting two forwarders together, both MUST have the same AGI 164 as part of their forwarder identifiers. The AII of the source 165 forwarder is known as the Source AII (SAII), and the AII of the 166 target forwarder is known as the Target AII (TAII). Therefore, 167 source forwarder and target forwarder can be denoted as 168 and respectively. 170 4. Protocol Components 172 4.1 Control Messages 174 L2TP defines two sets of session management procedures: incoming call 175 and outgoing call. Even though it is entirely possible to use the 176 outgoing call procedures for signaling L2VPNs, the incoming call 177 procedures have some advantages in terms of the relevance of the 178 semantics. [PWE3L2TP] gives more details on why the incoming call 179 procedures are more appropriate for setting up pseudowires. 181 The signaling procedures for L2VPNs described in the following 182 sections are based on the Control Connection Management and the 183 Incoming Call procedures, defined in Section 3.3 and 3.4.1 of 184 [RFC3931] respectively. L2TP control message types are defined in 185 Section 3.1 of [RFC3931]. This document references the following 186 L2TP control messages: 188 Start-Control-Connection-Request (SCCRQ) 189 Start-Control-Connection-Reply (SCCRP) 190 Incoming-Call-Request (ICRQ) 191 Incoming-Call-Reply (ICRP) 192 Incoming-Call-Connected (ICCN) 193 Set-Link-Info (SLI) 195 4.2 Existing AVPs for L2VPN 197 The following AVPs, defined in Section 5.4.3, 5.4.4, and 5.4.5 of 198 [RFC3931], are used for signaling L2VPNs. 200 Router ID 202 The Router ID sent in SCCRQ and SCCRP during control connection setup 203 establishes the unique identity of each PE. 205 Pseudowire Capabilities List 207 The Pseudowire Capabilities List sent in the SCCRQ and SCCRP 208 indicates the pseudowire types supported by the sending PE. It 209 merely serves as an advertisement to the receiving PE. Its content 210 should not affect the control connection setup. 212 Before a local PE initiates a session of a particular pseudowire type 213 to a remote PE, it MUST examine whether the remote PE has advertised 214 this pseudowire type in this AVP, and SHOULD NOT attempt to initiate 215 the session if the intended pseudowire type is not supported by the 216 remote PE. 218 Pseudowire Type 220 The Pseudowire Type sent in ICRQ signals the intended pseudowire type 221 to the receiving PE. The receiving PE checks it against its local 222 pseudowire capabilities list. If it finds a match, it responds with 223 an ICRP without a Pseudowire Type AVP, which implicitly acknowledges 224 its acceptance of the intended pseudowire. If it does not find a 225 match, it MUST respond with a CDN with an "unsupported pseudowire 226 type" result code. 228 L2-Specific Sublayer 230 The L2-Specific Sublayer can be sent in ICRQ, ICRP, and ICCN. If the 231 receiving PE supports the specified L2-Specific Sublayer, it MUST 232 include the identified L2-Specific Sublayer in its data packets sent 233 to the sending PE. Otherwise, it MUST reject the connection by 234 sending a CDN to the sending PE. 236 Circuit Status 238 The Circuit Status is sent in both ICRQ and ICRP to inform the 239 receiving PE about the circuit status on the sending PE. It can also 240 be sent in ICCN and SLI to update the status. 242 Remote End Identifier 244 The TAII value is encoded in the Remote End ID AVP and sent in ICRQ 245 along with the optional AGI to instruct the receiving PE to bind the 246 proposed pseudowire to the forwarder that matches the specified 247 forwarder identifier. 249 4.3 New AVPs for L2VPN 251 Attachment Group Identifier 253 The AGI AVP, Attribute Type TBA, is an identifier used to associate a 254 forwarder to a logical group. The AGI AVP is used in conjunction 255 with the Local End ID AVP and Remote End ID AVP, which encode the 256 SAII and TAII respectively, to identify a specific forwarder. When 257 the AGI AVP is omitted in the control messages or contains a zero- 258 length value, the forwarders are considered using the default AGI. 259 Note that there is only one designated default AGI value for all 260 forwarders. 262 The Attribute Value field for this AVP has the following format: 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 |M|H|0|0|0|0| Length | 0 | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | TBA | AGI (variable length) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 The AGI field is a variable-length field. This AVP MAY be present in 273 ICRQ. 275 This AVP MAY be hidden (the H bit MAY be 0 or 1). The hidding of AVP 276 attribute values is defined in Section 5.3 of [RFC3931]. The M bit 277 for this AVP SHOULD be set to 0. The Length (before hiding) of this 278 AVP is 6 octets plus the length of the AGI field. 280 Local End ID 282 The Local End ID AVP, Attribute Type TBA, encodes the SAII value. 283 The SAII may also be used in conjunction with the TAII to detect 284 pseudowire ties. When it is omitted in the control messages, it is 285 assumed that it has the same value as the TAII. 287 The Attribute Value field for this AVP has the following format: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 |M|H|0|0|0|0| Length | 0 | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | TBA | SAII (variable length) | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 The SAII field is a variable-length field. This AVP MAY be present 298 in ICRQ. 300 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 301 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6 302 octets plus the length of the SAII field. 304 Interface Maximum Transmission Unit 306 The Interface Maximum Transmission Unit (MTU) AVP, Attribute Type 307 TBA, indicates the MTU in octets of a packet that can be sent out 308 from the CE-facing interface. The MTU values of a given pseudowire, 309 if advertised in both directions, MUST be identical. If they do not 310 match, the pseudowire SHOULD NOT be established. When this AVP is 311 omitted in the control messages in either direction, it is assumed 312 that the remote PE has the same interface MTU as the local PE for the 313 pseudowire being signaled. 315 The Attribute Value field for this AVP has the following format: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 |M|H|0|0|0|0| Length | 0 | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | TBA | Interface MTU | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 The Interface MTU field is a 2-octet integer value. This AVP MAY be 326 present in ICRQ and ICRP. When a PE receives an Interface MTU AVP 327 with an MTU value different from its own, it MAY respond with a CDN 328 with a new result code indicating the disconnect cause. 330 RC-TBA-1 - Mismatching interface MTU 332 This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this 333 AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 8 334 octets. 336 4.4 AVP Interoperability 338 To ensure interoperability, the mandatory (M) bit settings of the 339 existing AVPs used in L2VPN applications should be the same as those 340 specified in [RFC3931]. The generic M-bit processing is described in 341 Section 5.2 of [RFC3931]. Setting the M-bit of the new AVPs to 1 342 will impair interoperability. 344 5. Signaling Procedures 346 5.1 Overview 348 Assume a PE assigns a forwarder identifier to one of its local 349 forwarders, and knows it needs to set up a pseudowire to a remote 350 forwarder on a remote PE that has a certain Forwarder ID. This 351 knowledge can be obtained either through manual configuration or some 352 auto-discovery procedure. 354 Before establishing the intended pseudowire, each pair of peering PEs 355 exchanges control connection messages to establish a control 356 connection. Each advertises its supported pseudowire types, as 357 defined in [PWE3IANA], in the Pseudowire Capabilities List AVP. 359 After the control connection is established, the local PE examines 360 whether the remote PE supports the pseudowire type it intends to set 361 up. Only if the remote PE supports the intended pseudowire type, it 362 should initiate a pseudowire connection request. 364 When the local PE receives an ICRQ for a pseudowire connection, it 365 examines the forwarder identifiers encoded in the AGI, SAII, and TAII 366 in order to determine the following: 368 - whether it has a local forwarder with the forwarder identifier 369 value specified in the ICRQ, 371 - whether the remote forwarder with the forwarder identifier 372 specified in the ICRQ is allowed to connect with this local 373 forwarder. 375 If both conditions are met, it sends an ICRP to the remote PE to 376 accept the connection request. If either of the two conditions 377 fails, it sends a CDN to the remote PE to reject the connection 378 request. 380 The local PE can optionally include a result code in the CDN to 381 indicate the disconnect cause. The possible result codes are: 383 RC-TBA-2 - Attempt to connect to non-existent forwarder 384 RC-TBA-3 - Attempt to connect to unauthorized forwarder 386 5.2 Pseudowire Tie Detection 388 Conceivably in the network reference models, as either PE may 389 initiate a pseudowire to another PE at any time, the PEs could end up 390 initiating a pseudowire to each other simultaneously. In order to 391 avoid setting up duplicated pseudowires between two forwarders, each 392 PE must be able to independently detect such a pseudowire tie. The 393 following procedures need to be followed to detect a tie: 395 If both TAII and SAII are present in the ICRQ, the receiving PE 396 compares the TAII and SAII against the SAII and TAII itself 397 previously sent to the sending PE. If the received TAII matches the 398 sent SAII and the received SAII matches the sent TAII, a tie is 399 detected. 401 If only the TAII is present in the ICRQ, the SAII is assumed to have 402 the same value as the TAII. The receiving PE compares the received 403 TAII with the SAII that it previously sent to the sending PE. If the 404 SAII in that ICRQ is also omitted, then the value encoded in the sent 405 TAII is used for comparison. If they match, a tie is detected. 407 If the AGI is present, it is first prepended to the TAII and SAII 408 values before the tie detection occurs. 410 Once a tie is discovered, the PE uses the standard L2TP tie breaking 411 procedure, as described in Section 5.4.4 of [RFC3931], to disconnect 412 the duplicated pseudowire. 414 5.3 Generic Algorithm 416 The following uses a generic algorithm to illustrate the protocol 417 interactions when constructing an L2VPN using L2TP signaling. 419 Each PE first forms a list, SOURCE_FORWARDERS, consisting of all 420 local forwarders of a given VPN. Then it puts all local forwarders 421 that need to be interconnected and all remote forwarders of the same 422 VPN into another list, TARGET_FORWARDERS. The formation of the 423 network topology depends on the content in the SOURCE_FORWARDERS and 424 TARGET_FORWARDERS lists. These two lists can be constructed by 425 manual configuration and/or some auto-discovery procedure. 427 The algorithm is used to set up a full mesh of interconnections 428 between SOURCE_FORWARDERS and TARGET_FORWARDERS. An L2VPN is formed 429 upon finishing the algorithm in every participating PE of this L2VPN. 431 1. Pick the next forwarder, from SOURCE_FORWARDERS. If no 432 forwarder is available for processing, the processing is 433 complete. 435 2. Pick the next forwarder, from TARGET_FORWARDERS. If no 436 forwarder is available for processing, go back to step 1. 438 3. If the two forwarders are associated with different Router 439 IDs, a pseudowire must be established between them. Proceed 440 to step 6. 442 4. Compare the values of the two forwarders. If 443 they match, the source and target forwarders are the same, 444 so no more action is necessary. Go back to step 2. 446 5. As the source and target forwarders both reside on the local 447 PE, no pseudowire is needed. The PE simply creates a local 448 cross-connect between the two forwarders. Go back to step 2. 450 6. As the source and target forwarders reside on different PEs, 451 a pseudowire must be established between them. The PE first 452 examines if the source forwarder has already established a 453 pseudowire to the target forwarder. If so, go back to step 2. 455 7. If no pseudowire is already established between the source and 456 target forwarders, the local PE obtains the address of the 457 remote PE, and establishes a control connection to the remote 458 PE if one does not already exist. 460 8. The local PE sends an ICRQ to the remote PE. The AGI, TAII, 461 and SAII values are encoded in the AGI AVP, the Remote End ID 462 AVP, and the Local End ID AVP respectively. 464 9. If the local PE receives a response corresponding to the 465 ICRQ it just sent, proceed to step 10. Otherwise, if the 466 local PE receives an ICRQ from the same remote PE, proceed 467 to step 11. 469 10. The local PE receives a response from the remote PE. If 470 it is a CDN, go back to step 2. If it's an ICRP, the local 471 PE binds the source forwarder to the pseudowire and sends 472 an ICCN to the remote PE. Go back to step 2. 474 11. If the local PE receives an ICRQ from the same remote PE, 475 it needs to perform session tie detection, as described in 476 Section 5.2. If a session tie is detected, the PE performs 477 tie breaking. 479 12. If the local PE loses the tie breaker, it sends a CDN with 480 the result code that indicates the disconnection is due to 481 losing the tie breaker. Proceed to step 14. 483 13. If the local PE wins the tie breaker, it ignores the remote 484 PE's ICRQ, but acknowledges receipt of the control message 485 and continues waiting for the response from the remote PE. 486 Go to step 10. 488 14. The local PE determines whether it should accept the 489 connection request, as described in the Section 5.1. 490 If it accepts the ICRQ, it sends an ICRP to the remote PE. 492 15. The local PE receives a response from the remote PE. If 493 it is a CDN, go back to step 2. If it is an ICCN, the local 494 PE binds the source forwarder to the pseudowire, go back 495 to step 2. 497 The following diagram illustrates the above procedure: 499 ---------> Pick Next 500 | Source Forwarder 501 | | 502 | | 503 | v N 504 | Found Source Forwarder? ----------> End 505 | | 506 | Y | 507 | v 508 | Pick Next <-------------------------------- 509 | Target Forwarder | 510 | | | 511 | | | 512 | N v | 513 -------- Found Target Forwarder? | 514 | | 515 Y | | 516 v Y Y | 517 Same Router ID? ------> Same Forwarder ID? ------| 518 | | | 519 N | N | | 520 | v | 521 | Create Local -------| 522 v Cross-connect | 523 Pseudowire Already Y | 524 Established Between -------------------------------| 525 Source and Target? | 526 | | 527 N | | 528 v | 529 Local Initiates Pseudowire | 530 Connection Request to Remote | 531 | | 532 | | 533 v | 534 -------> Local Wait for Message | 535 | ----- from Remote -------------- | 536 | | | | 537 | | | | 538 | v v | 539 | Local Receives Pseudowire Local Receives Pseudowire | 540 | Connection Request Connection Response | 541 | from Remote from Remote | 542 | | | | 543 | | | | 544 | v v N | 545 | Perform Pseudowire Connection Accepted? --------| 546 | Tie Detection | | 547 | | Y | | 548 | | v | 549 | | Local Binds Source ---------| 550 | | Forwarder to Pseudowire | 551 | | | 552 | v N N | 553 | Tie Detected? -----> Accept Remote -----> Reject ------| 554 | | Connection Request? Remote Request | 555 | Y | ^ | | 556 | v | | Y | 557 | Perform Tie Breaking | ------> Local Binds ---- 558 | | | Source Forwarder 559 | | | to Pseudowire 560 | v N | 561 | Won Tie Breaking? ------> Disconnect 562 | | Local Connection 563 | Y | 564 | v 565 ------ Ignore Remote 566 Connection Request 568 6. IANA Considerations 570 The IANA registry procedure in this document follows that in Section 571 10 of [RFC3931]. The following are requests for new values for 572 existing registries managed by IANA. 574 This document defines three new L2TP control message Attribute Value 575 Pairs (AVPs) to be assigned by the IANA. These are described in 576 Section 4.3 are summarized below: 578 AVP-TBA-1 - Attachment Group Identifier 579 AVP-TBA-2 - Local End Identifier 580 AVP-TBA-3 - Interface Maximum Transmission Unit 582 Section 4.3 and Section 5.1 define three new result codes for the CDN 583 message are to be assigned by the IANA: 585 RC-TBA-1 - Mismatching interface MTU 586 RC-TBA-2 - Attempt to connect to non-existent forwarder 587 RC-TBA-3 - Attempt to connect to unauthorized forwarder 589 7. Security Considerations 591 This specification does not introduce any additional security 592 considerations beyond those discussed in [RFC3931] and [L2VPN FW]. 594 8. Intellectual Property Statement 596 The IETF takes no position regarding the validity or scope of any 597 Intellectual Property Rights or other rights that might be claimed to 598 pertain to the implementation or use of the technology described in 599 this document or the extent to which any license under such rights 600 might or might not be available; nor does it represent that it has 601 made any independent effort to identify any such rights. Information 602 on the procedures with respect to rights in RFC documents can be 603 found in BCP 78 and BCP 79. 605 Copies of IPR disclosures made to the IETF Secretariat and any 606 assurances of licenses to be made available, or the result of an 607 attempt made to obtain a general license or permission for the use of 608 such proprietary rights by implementers or users of this 609 specification can be obtained from the IETF on-line IPR repository at 610 http://www.ietf.org/ipr. 612 The IETF invites any interested party to bring to its attention any 613 copyrights, patents or patent applications, or other proprietary 614 rights that may cover technology that may be required to implement 615 this standard. Please address the information to the IETF at ietf- 616 ipr@ietf.org. 618 9. Copyright Notice 620 Copyright (C) The Internet Society (2006). 622 This document is subject to the rights, licenses and restrictions 623 contained in BCP 78, and except as set forth therein, the authors 624 retain all their rights. 626 This document and the information contained herein are provided on an 627 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 628 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 629 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 630 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 631 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 632 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 634 10. Acknowledgement 636 The author would like to thank Mark Townsley and Carlos Pignataro for 637 their valuable input. 639 11. References 641 11.1 Normative References 643 [RFC3931] J. Lau et. al., "Layer Two Tunneling Protocol - Version 3 644 (L2TPv3)", RFC 3931, March 2005 646 11.2 Informative References 648 [PWE3IANA] L. Martini, "IANA Allocations for Pseudo Wire Edge to Edge 649 Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-15.txt, 650 November 2005 652 [L2VPN FW] L. Andersson et. al., "PPVPN L2 Framework", 653 draft-ietf-l2vpn-l2-framework-05.txt, June 2004 655 [PWE3L2TP] W. Townsley, "Pseudowires and L2TPv3", 656 draft-townsley-pwe3-l2tpv3-01.txt, June 2003 658 [RFC 2661] W. Townsley et. al., "Layer 2 Tunnel Protocol (L2TP)", 659 RFC 2661, August 1999. 661 12. Authors' Address 663 Wei Luo 664 Cisco Systems, Inc. 665 170 West Tasman Drive 666 San Jose, CA 95134 667 Email: luo@cisco.com