Network Working Group Wei Luo Internet Draft Cisco Systems, Inc. Jan 2004 L2VPN Extensions for L2TP draft-ietf-l2tpext-l2vpn-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Layer 2 Tunneling Protocol (L2TP) provides a standard method for setting up and managing L2TP sessions to tunnel a variety of L2 protocols. One of the reference models supported by L2TP describes the use of an L2TP session to connect two Layer 2 circuits attached to a pair of peering LACs, which is a basic form of Layer 2 Virtual Private Network (L2VPN). This document defines the protocol extensions for L2TP to set up different types of L2VPN in a unified fashion. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. Luo [Page 1] Internet Draft draft-ietf-l2tpext-l2vpn-00.txt Jan 2004 Table of Contents Status of this Memo.......................................... 1 1. Introduction.............................................. 2 2. Network Reference Model................................... 3 3. Forwarder Identifier...................................... 4 4. Protocol Components....................................... 4 4.1 Control Messages...................................... 4 4.2 Existing AVPs for L2VPN............................... 4 4.3 New AVPs for L2VPN.................................... 5 5. Signaling Procedures...................................... 7 5.1 Overview.............................................. 7 5.2 Pseudowire Tie Detection.............................. 7 5.3 Generic Algorithm..................................... 8 6. IANA Considerations....................................... 11 7. Security Considerations................................... 11 8. References................................................ 11 9. Authors' Address.......................................... 12 1. Introduction [L2TPv3] defines a dynamic tunneling mechanism to carry multiple L2 protocols besides PPP (as originally defined in [RFC 2661]) over a packet-based network. The baseline protocol supports various types of applications, which have been highlighted in the different L2TP reference models in [L2TPv3]. L2VPN applications are typically in the scope of the LAC-LAC reference model. This document discusses the commonalities as well as differences among L2VPN applications with respect to utilizing L2TPv3 as the signaling protocol. The acronym "L2TP" refers to L2TPv3 or L2TP in general in this document. Luo [Page 2] Internet Draft draft-ietf-l2tpext-l2vpn-00.txt Jan 2004 2. Network Reference Model In the LAC-LAC reference model, a LAC serves as a cross-connect between attachment circuits and L2TP sessions. Each L2TP session acts as an emulated circuit, also known as pseudowire. A pseudowire is used to bind two "forwarders" together. For different L2VPN applications, different types of forwarders are defined. In the L2VPN framework [L2VPN FW], a LAC is a Provider Edge (PE) device. LAC and PE are interchangable terms in the context of this document. Remote systems in the LAC-LAC reference model are Customer Edge (CE) devices. +----+ L2 +----+ +----+ L2 +----+ | CE |------| PE |....[core network]....| PE |------| CE | +----+ +----+ +----+ +----+ |<- emulated service ->| |<----------------- L2 service -------------->| L2VPN Network Reference Model In a simple cross-connect application, an attachment circuit is a forwarder directly bound to a pseudowire. It is a one-to-one mapping. Traffic received from the attachment circuit on a local PE is forwarded to the remote PE through the pseudowire. When the remote PE receives traffic from the pseudowire, it forwards the traffic to the corresponding attachment circuit on its end. The forwarding decision is based on the attachment circuit or pseudowire demultiplexing identifier. With Virtual Private LAN Service (VPLS), a Virtual Switching Instance (VSI) is a forwarder connected to one or more attachment circuits and pseudowires. A single pseudowire is used to connect a pair of VSIs on two peering PEs. Traffic received from an attachment circuit or a pseudowire is first forwarded to the corresponding VSI based on the attachment circuit or pseudowire demutiplexing identifier. The VSI performs additional lookup to determine where to further forward the traffic. With Virtual Private Wire Service (VPWS), attachment circuits are grouped into "colored pools". Each pool is a forwarder and connected through a network of point-to-point cross-connect. The data forwarding perspective is identical to the cross-connect application. However, constructing colored pools involves more complicated signaling procedures. Luo [Page 3] Internet Draft draft-ietf-l2tpext-l2vpn-00.txt Jan 2004 3. Forwarder Identifier A forwarder identifier is assigned to each forwarder on a given PE and is unique in the context of the PE. It is defined as the concatenation of an Attachment Group Identifier (AGI) and an Attachment Individual Identifier (AII), denoted as . The AGI is used to group a set of forwarders together for signaling purpose. An AII is used to distinguish forwarders within a group. AII can be unique at a per platform or per group basis. As far as the signaling procedures are concerned, a forwarder identifier is an arbitrary string of bytes. It is up to implementations to decide the values for AGI and AII. When connecting two forwarders together, both MUST have the same AGI as part of their forwarder identifiers. The AII of the source forwarder is known as the Source AII (SAII), and the AII of the target forwarder is known as the Target AII (TAII). Therefore, source forwarder and target forwarder can be denoted as and respectively. 4. Protocol Components 4.1 Control Messages L2TP defines two sets of session management procedures: incoming call and outgoing call. Even though it is entirely possible to use the outgoing call procedures to signaling L2VPNs, the incoming call procedures has some advantages in terms of the relevance of the semantics. [PWE3L2TP] gives more details on why the incoming call procedures are more appropriate for setting up pseudowires. The signaling procedures for L2VPNs described in the following sections are based on the Incoming Call procedures. 4.2 Existing AVPs for L2VPN Router ID The Router ID sent in SCCRQ and SCCRP during control connection setup establishes the unique identity of each PE. Pseudowire Capabilities List The Pseudowire Capabilities List sent in the SCCRQ and SCCRP indicates the pseudowire types supported by the sending PE. It merely serves as an advertisement to the receiving PE. Its content Luo [Page 4] Internet Draft draft-ietf-l2tpext-l2vpn-00.txt Jan 2004 should not affect the control connection setup. Before a local PE initiates a session of a particular pseudowire type to a remote PE, it MUST examine whether the remote PE has advertised this pseudowire type in this AVP, and SHOULD NOT attempt to initiate the session if the intended pseudowire type is not supported by the remote PE. Pseudowire Type The Pseudowire Type sent in ICRQ signals the intended pseudowire type to the receiving PE. The receiving PE checks it against its local pseudowire capabilities list. If it finds a match, it responds with an ICRP without a Pseudowire Type AVP, which implicitly acknowledges its acceptance of the intended pseudowire. If it does not find a match, it MUST respond with a CDN with an "unsupported pseudowire type" result code. Pseudowire Control Encapsulation The Pseudowire Control Encapsulation can be sent in ICRQ, ICRP, and ICCN. If the receiving PE supports the specified control encapsulation, it MUST include it in its data packets sent to the sending PE. Otherwise, it MUST reject the connection by sending a CDN to the sending PE. Circuit Status The Circuit Status is sent in both ICRQ and ICRP to inform the receiving PE about the circuit status on the sending PE. It can also be sent in ICCN and SLI to update the status. Remote End Identifier The TAII value is encoded in the Remote End ID AVP and sent in ICRQ along with the optional AGI to instruct the receiving PE to bind the proposed pseudowire to the forwarder that matches the specified forwarder identifier. 4.3 New AVPs for L2VPN Attachment Group Identifier The AGI AVP, Attribute Type TBA, is an identifier used to associate a forwarder to a logical group. The AGI AVP is used in conjunction with the Local End ID AVP and Remote End ID AVP, which encode the SAII and TAII respectively, to identify a specific forwarder. When the AGI AVP is omitted in the control messages or contains a zero- Luo [Page 5] Internet Draft draft-ietf-l2tpext-l2vpn-00.txt Jan 2004 length value, the forwarders are considered using the default AGI. Note that there is only one designated default AGI value for all forwarders. The Attribute Value field for this AVP has the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H|0|0|0|0| Length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBA | AGI (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The AGI field is a variable-length field. This AVP MAY be present in ICRQ. This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the AGI field. Local End ID The Local End ID AVP, Attribute Type TBA, encodes the SAII value. The SAII may also be used in conjunction with the TAII to detect pseudowire ties. When it is omitted in the control messages, it is assumed that it has the same value as the TAII. The Attribute Value field for this AVP has the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H|0|0|0|0| Length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBA | SAII (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The SAII field is a variable-length field. This AVP MAY be present in ICRQ. This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the SAII field. Luo [Page 6] Internet Draft draft-ietf-l2tpext-l2vpn-00.txt Jan 2004 5. Signaling Procedures 5.1 Overview Assume a PE assigns a forwarder identifier to one of its local forwarders, and knows it needs to set up a pseudowire to a remote forwarder on a remote PE that has a certain Forwarder ID. This knowledge can be obtained either through manual configuration or some auto-discovery procedure. Before establishing the intended pseudowire, each pair of peering PEs exchanges control connection messages to establish a control connection. Each advertises its supported pseudowire types in the Pseudowire Capabilities List AVP. After the control connection is established, the local PE examines whether the remote PE supports the pseudowire type it intends to set up. Only if the remote PE supports the intended pseudowire type, it should initiate a pseudowire connection request. When the local PE receives an ICRQ for a pseudowire connection, it examines the forwarder identifier encoded in the AGI, SAII, and TAII in order to determine the following: - whether it has a local forwarder with the forwarder identifier value specified in the ICRQ, - whether the remote forwarder with the forwarder identifier specified in the ICRQ is allowed to connect with this local forwarder. If both conditions are met, it sends an ICRP to the remote PE to accept the connection request. If either of the two conditions fails, it sends a CDN to the remote PE to reject the connection request. 5.2 Pseudowire Tie Detection Conceivably in the network reference models, as either PE may initiate a pseudowire to another PE at any time, the PEs could end up initiating a pseudowire to each other simultaneously. In order to avoid setting up duplicated pseudowires between two forwarders, each PE must be able to independently detect such a pseudowire tie. The following procedures need to be followed to detect a tie: If both TAII and SAII are present in the ICRQ, the receiving PE compares the TAII and SAII against the SAII and TAII itself previously sent to the sending PE. If the received TAII matches the Luo [Page 7] Internet Draft draft-ietf-l2tpext-l2vpn-00.txt Jan 2004 sent SAII and the received SAII matches the sent TAII, a tie is detected. If only the TAII is present in the ICRQ, the SAII is assumed to have the same value as the TAII. The receiving PE compares the received TAII with the SAII that it previously sent to the sending PE. If the SAII in that ICRQ is also omitted, then the value encoded in the sent TAII is used for comparison. If they match, a tie is detected. Once a tie has been discovered, the standard L2TP tie breaking procedure is used to disconnect the duplicated pseudowire. 5.3 Generic Algorithm The following uses a generic algorithm to illustrate the protocol interactions when constructing an L2VPN using L2TP signaling. Each PE first forms a list, SOURCE_FORWARDERS, consisting of all local forwarders of a given VPN. Then it puts all local forwarders that need to be interconnected and all remote forwarders of the same VPN into another list, TARGET_FORWARDERS. The formation of the network topology depends on the content in the SOURCE_FORWARDERS and TARGET_FORWARDERS list. These two lists can be constructed by manual configuration and/or some auto-discovery procedure. The algorithm is used to set up pseudowires among all the forwarders that intend to be interconnected by iterating through each source and target forwarder. An L2VPN is formed upon finishing the algorithm in every participating PE of this L2VPN. 1. Pick the next forwarder, from SOURCE_FORWARDERS. If no forwarder is available for processing, the processing is complete. 2. Pick the next forwarder, from TARGET_FORWARDERS. If no forwarder is available for processing, go back to step 1. 3. If the two forwarders are associated with different Router IDs, a pseudowire must be established between them. Proceed to step 6. 4. Compare the values of the two forwarders. If they match, the source and target forwarders are the same, so no more action is necessary. Go back to step 2. 5. As the source and target forwarders both reside on the local PE, no pseudowire is needed. The PE simply creates a local cross-connect between the two forwarders. Go back to step 2. Luo [Page 8] Internet Draft draft-ietf-l2tpext-l2vpn-00.txt Jan 2004 6. As the source and target forwarders reside on different PEs, a pseudowire must be established between them. The PE first examines if the source forwarder has already established a pseudowire to the target forwarder. If so, go back to step 2. 7. If no pseudowire is already established between the source and target forwarders, the local PE obtains the address of the remote PE, and establishes a control connection to the remote PE if one does not already exist. 8. The local PE sends an ICRQ to the remote PE. The AGI, TAII, and SAII values are encoded in the AGI AVP, the Remote End ID AVP, and the Local End ID AVP respectively. 9. If the local PE receives a response corresponding to the ICRQ it just sent, proceed to step 10. Otherwise, if the local PE receives an ICRQ from the same remote PE, proceed to step 11. 10. The local PE receives a response from the remote PE. If it is a CDN, go back to step 2. If it's an ICRP, the local PE binds the source forwarder to the pseudowire and sends an ICCN to the remote PE. Go back to step 2. 11. If the local PE receives an ICRQ from the same remote PE, it needs to perform session tie detection, as described in Section 5.2. If a session tie is detected, the PE performs tie breaking. 12. If the local PE loses the tie breaker, it sends a CDN with the result code that indicates the disconnection is due to losing the tie breaker. Proceed to step 14. 13. If the local PE wins the tie breaker, it ignores the remote PE's ICRQ, but acknowledges receipt of the control message and continues waiting for the response from the remote PE. Go to step 10. 14. The local PE determines whether it should accept the connection request, as described in the Section 5.1. If it accepts the ICRQ, it sends an ICRP to the remote PE. 15. The local PE receives a response from the remote PE. If it is a CDN, go back to step 2. If it is an ICCN, the local PE binds the source forwarder to the pseudowire, go back to step 2. The following diagram illustrates the above procedure: Luo [Page 9] Internet Draft draft-ietf-l2tpext-l2vpn-00.txt Jan 2004 ---------> Pick Next | Source Forwarder | | | | | v N | Found Source Forwarder? ----------> End | | | Y | | v | Pick Next <-------------------------------- | Target Forwarder | | | | | | | | N v | -------- Found Target Forwarder? | | | Y | | v Y Y | Same Router ID? ------> Same Forwarder ID? ------| | | | N | N | | | v | | Create Local -------| v Cross-connect | Pseudowire Already Y | Established Between -------------------------------| Source and Target? | | | N | | v | Local Initiates Pseudowire | Connection Request to Remote | | | | | v | -------> Local Wait for Message | | ----- from Remote -------------- | | | | | | | | | | v v | | Local Receives Pseudowire Local Receives Pseudowire | | Connection Request Connection Response | | from Remote from Remote | | | | | | | | | | v v N | | Perform Pseudowire Connection Accepted? --------| | Tie Detection | | Luo [Page 10] Internet Draft draft-ietf-l2tpext-l2vpn-00.txt Jan 2004 | | Y | | | | v | | | Local Binds Source ---------| | | Forwarder to Pseudowire | | | | | v N N | | Tie Detected? -----> Accept Remote -----> Reject ------| | | Connection Request? Remote Request | | Y | ^ | | | v | | Y | | Perform Tie Breaking | ------> Local Binds ---- | | | Source Forwarder | | | to Pseudowire | v N | | Won Tie Breaking? ------> Disconnect | | Local Connection | Y | | v ------ Ignore Remote Connection Request 6. IANA Considerations This document defines two new L2TP AVPs to be maintained by the IANA. 7. Security Considerations The signaling procedures described in this document does not incur additional security considerations that L2TP already provisions. 8. References [L2TPv3] J. Lau et. al., "Layer Two Tunneling Protocol (version3)", draft-ietf-l2tpext-l2tp-base-04.txt, November 2002 [L2VPN FW] L. Andersson et. al., "PPVPN L2 Framework", draft-ietf-l2vpn-l2-framework-03.txt, October 2003 [PWE3L2TP] W. Townsley, "Pseudowires and L2TPv3", draft-townsley-pwe3-l2tpv3-00.txt, June 2002 [RFC 2661] W. Townsley et. al., "Layer 2 Tunnel Protocol (L2TP)", RFC 2661, August 1999. Luo [Page 11] Internet Draft draft-ietf-l2tpext-l2vpn-00.txt Jan 2004 9. Authors' Address Wei Luo Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Email: luo@cisco.com Luo [Page 12]