Network Working Group Wei Luo Internet Draft Cisco Systems, Inc. November 2002 L2VPN Signaling Using L2TPv3 draft-luo-l2tpext-l2vpn-signaling-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 L2TPv3 provides a standard method for setting up and managing L2TP sessions to tunnel a variety of L2 protocols. The LAC-LAC reference model describes the use of an L2TP session to cross-connect two L2 circuits attached to the peering LACs. A cross-connect is a basic form of L2VPNs. This document describes mechanisms which utilize the building blocks that L2TP provides to construct different types of L2VPNs. 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-luo-l2tpext-l2vpn-signaling-00.txt November 2002 Table of Contents Status of this Memo.......................................... 1 1. Introduction.............................................. 3 2. Network Reference Model and L2VPN Applications............ 3 3. Forwarders and End Identifiers............................ 4 4. L2TP Control Messages..................................... 5 5. Existing AVPs for L2VPNs.................................. 5 5.1 Router ID............................................. 5 5.2 Pseudowire Capabilities List.......................... 5 5.3 Pseudowire Type....................................... 5 5.4 Pseudowire Control Encapsulation...................... 6 5.5 Circuit Status........................................ 6 5.6 Remote End ID......................................... 6 6. New AVPs for L2VPN........................................ 6 6.1 Local End ID.......................................... 6 7. Pseudowire Tie Detection.................................. 7 8. L2VPN Signaling Procedures................................ 8 8.1 Overview.............................................. 8 8.2 Generic Algorithm..................................... 8 8.3 Application-specified Processing...................... 10 8.3.1 Cross-connect.................................... 10 8.3.2 Virtual Private LAN Service...................... 10 8.3.3 Colored Pools.................................... 10 9. BGP-based Auto-discovery.................................. 11 9.1 Common L2VPN Addressing and NLRI Encoding............. 11 9.2 AFI/SAFI and BGP Capabilities......................... 12 9.3 Route Targets......................................... 12 10. Heterogeneous L2VPN Deployment........................... 13 11. Intellectual Property Notice............................. 13 12. IANA Considerations...................................... 14 13. Security Considerations.................................. 14 14. Acknowledgement.......................................... 14 Luo [Page 2] Internet Draft draft-luo-l2tpext-l2vpn-signaling-00.txt November 2002 15. References............................................... 14 16. Authors' Address......................................... 15 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 has been hightlighted 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 commonality as well as difference among L2VPN applications with respect to utilizing L2TPv3 as the signaling protocol. It also specifies the necessary information required by BGP-based auto-discovery for the integration with the L2TPv3-based signaling protocol. Other auto-discovery mechanisms are left for future studies. The acronym "L2TP" refers to L2TPv3 or L2TP in general in this document. 2. Network Reference Model and L2VPN Applications In the LAC-LAC reference mode, 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. +-----+ L2 +-----+ +-----+ L2 +-----+ | |------| LAC |...[packet network]...| LAC |------| | +-----+ +-----+ +-----+ +-----+ remote remote system system |<- emulated service ->| |<----------------- L2 service ----------------->| In a simple cross-connect application, an attachment circuit is directly bound to a pseudowire. It's a one-to-one mapping. Traffic received from the attachment circuit on a LAC is forwarded to its peer LAC through the pseudowire. When the peer LAC 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 respectively. Luo [Page 3] Internet Draft draft-luo-l2tpext-l2vpn-signaling-00.txt November 2002 With Virtual Private LAN Service (VPLS), one or more attachment circuits and pseudowires are connected to a Virtual Switching Instance (VSI) on a LAC. A single pseudowire is used to connect a pair of VSIs on two peering LACs. 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. [L2 FW] describes an L2VPN application called Colored Pools, which is essentially made of a network of point-to-point cross-connect. The data forwarding perspective is identical to the cross-connect application, while constructing Colored Pools involves more complicated signaling procedures. 3. Forwarders and End Identifiers As described in [L2 FW], a pseudowire is bound to a "forwarder", which in turn binds to one or more attachment circuits. For different L2VPN applications, different types of forwarders are defined. An End Identifier is assigned to each forwarder on a given LAC that supports L2VPN applications. It must be unique in the context of the LAC. In simple cross-connect, each individual attachment circuit is a forwarder, and provisioned with an End ID value. Without any auto- discovery, each attachment circuit needs to be manually provisioned with the remote Router ID and the End ID of the remote attachment circuit. The End ID value for an attachment circuit may be an arbitrary integer or a descriptive string. In VPLS, each VSI is a forwarder, and provisioned with an End ID value. Without any auto-discovery, each VSI needs to be manually provisioned with its remote LAC addresses and the End IDs of the remote VSIs. The End ID value for a VSI may be the VPN ID of the VPLS domain. In Colored Pools, each pool is a forwarder, and provisioned with an End ID value. Without any auto-discovery, each pool needs to be manually provisioned with its remote LAC addresses and the End IDs of the remote pools. The End ID value for a pool may be an arbitrary integer or a descriptive string. Luo [Page 4] Internet Draft draft-luo-l2tpext-l2vpn-signaling-00.txt November 2002 4. L2TP Control Messages L2TP defines two sets of session management procedures: Incoming Call and Outgoing Call. Even though it's entirely possible to use the Outgoing Call procedures to signaling L2VPNs, the Incoming Call procedures has some advantages in terms of the relevance of semantics and being able to offer moderate capability negotiation between two LCCEs. [PWE3L2TP] gives more details on why Incoming Call is more appropriate for setting up pseudowires. The signaling procedures for L2VPNs described in the following sections are all based on the Incoming Call procedures. 5. Existing AVPs for L2VPNs Besides the AVPs required to establish and manage control connections and sessions, the following AVPs defined in [L2TPv3] are directly relevant to L2VPN applications. 5.1 Router ID The Router ID sent in SCCRQ and SCCRP during control connection setup establishes the unique identity of each LAC. 5.2 Pseudowire Capabilities List The Pseudowire Capabilities List sent in SCCRQ and SCCRP indicates the pseudowire types supported by the sending LAC. It merely serves as an advertisement to the receiving LAC. Its content should not affect the control connection setup. Before a LAC initiates a session of a particular pseudowire type to its peer, it MUST examine whether the peer has advertised such a capability in this AVP, and SHOULD NOT attempt to initiate the session if the intended pseudowire type is not supported by the peer. 5.3 Pseudowire Type The Pseudowire Type sent in ICRQ signals the intended pseudowire type to the receiving LAC. The receiving LAC checks it against its local pseudowire capability 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 initiated by its peer. If it does not find a match, it MUST respond with a CDN with an Luo [Page 5] Internet Draft draft-luo-l2tpext-l2vpn-signaling-00.txt November 2002 "unsupported pseudowire type" result code. 5.4 Pseudowire Control Encapsulation The Pseudowire Control Encapsulation can be sent in ICRQ, ICRP, and ICCN. If the receiving LAC supports the specified control encapsulation, it MUST include it in its data packets sent to the sending LAC. Otherwise, it MUST reject the connection by sending a CDN to the sending LAC. 5.5 Circuit Status The Circuit Status is sent in both ICRQ and ICRP to inform the receiving LAC about the circuit status on the sending LAC. It can also be sent in ICCN and SLI to update the status. 5.6 Remote End ID The Remote End ID sent in ICRQ instructs the receiving LAC to bind the proposed pseudowire to the forwarder that has been assigned with the encoded End Identifier value. 6. New AVPs for L2VPN 6.1 Local End ID The Local End ID AVP, Attribute Type TBA, encodes the End Identifier value of the forwarder to be bound to the proposed pseudowire on the sending LAC. The Local End ID AVP may also be used in conjunction with the Remote End ID AVP to detect session-level ties. When it's omitted in the control messages, it's assumed that it has the same value as the Remote End ID. 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 | End ID ... (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Luo [Page 6] Internet Draft draft-luo-l2tpext-l2vpn-signaling-00.txt November 2002 The End Identifier field is a variable-length field whose value is unique for a given LCCE. 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 End Identifier value. 7. Pseudowire Tie Detection Conceivably in the LAC-LAC network reference model, as either LAC may initiate a session to its peer LAC at any time, they could end up initiating a session to each other simultaneously. In order to avoid setting up duplicated pseudowires between two forwarders, each LAC must be able to independently detect such a pseudowire tie. The following procedures need to be followed to detect a tie: If both Remote End ID and Local End ID are present in ICRQ, the receiving LAC compares them with the Remote End ID and Local End ID, in reverse order, encoded in the ICRQ it has already sent to the sending LAC. If the received Remote End ID matches the sent Local End ID and the received Local End ID matches the sent Remote End ID, a tie is detected. If only Remote End ID is present in ICRQ, the Local End ID is assumed to have the same value as the Remote End ID. The receiving LAC compares the received Remote End ID with the Local End ID, encoded in the ICRQ it has already sent to the sending LAC. If the Local End ID in this ICRQ is also omitted, then the Remote End ID is compared. If they match, a tie is detected. Once a tie has been discovered, the standard L2TP tie breaking procedure is employed to disconnect the duplicated pseudowire. Luo [Page 7] Internet Draft draft-luo-l2tpext-l2vpn-signaling-00.txt November 2002 8. L2VPN Signaling Procedures 8.1 Overview Assume a LAC assigns an End ID to one of its local forwarders, and knows it needs to set up a pseudowire to a remote forwarder on a remote LAC that has a certain End ID. This knowledge can be obtained either through manual configuration or some auto-discovery procedure. Before establishing the intended pseudowire, each pair of peering LACs 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, a LAC examines whether its peer LAC supports the pseudowire type it intends to set up. Only if the peer supports the intended pseudowire type, it should initiate a pseudowire connection request. When a LAC receives an ICRQ for a pseudowire connection, it examines the Remote End ID encoded in the ICRQ to determine the following: - whether it has a local forwarder assigned with an End ID value specified in the Remote End ID, - whether the peer LAC is allowed to connect with this local forwarder. If both conditions are met, it sends an ICRP to the peer to accept the connection request. If either of the two conditions fails, it sends a CDN to the peer to reject the connection request. 8.2 Generic Algorithm Despite the apparent disparity among different L2VPN applications, a common set of signaling procedures can be defined. Each LAC 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 that are learnt into another list, TARGET_FORWARDERS. The following steps can be taken to set up an L2VPN: 1. Pick a forwarder, f_1, from SOURCE_FORWARDERS. If no forwarder is available for processing, the processing is Luo [Page 8] Internet Draft draft-luo-l2tpext-l2vpn-signaling-00.txt November 2002 complete. 2. Pick a forwarder, f_2, from TARGET_FORWARDERS. If no more forwarder is available for processing, go back to step 1. 3. If the two forwarders are associated with different Router IDs, go to step 6. 4. Compare the End ID values of the two forwarders, if they match, go back to step 2. 5. As f_1 and f_2 both reside on the local LAC, no signaling is needed. LAC simply makes a local cross-connect between the two forwarders. Go back to step 2. 6. As f_1 and f_2 reside on different LACs, signaling is needed. LAC first examines if f_1 has already established a pseudowire to f_2. If it has, go back to step 2. 7. If it has not, it obtains the address of the remote LAC, and establishes a control connection with the remote LAC if one does not already exist. 8. The local LAC sends an ICRQ to the remote LAC. The End IDs of f_1 and f_2 are encoded as the Local End ID and Remote End ID respectively. 9. If the local LAC receives an ICRQ from the same remote LAC, it needs to perform session tie detection, as described in Section 7. If a session tie is detected, it performs tie breaking. 10. If it lost in tie breaking, the local LAC sends a CDN to the remote LAC to withdraw the connection request it made in the ICRQ, go to step 13. 11. If it won in tie breaking, the local LAC ignores the peer's ICRQ (while it should acknowledge the reception of the ICRQ by sending a ZLB message), and continues waiting for the response from the remote LAC. 12. The local LAC receives a response from the remote LAC. If it's a CDN, go back to step 2. If it's an ICRP, the local LAC binds f_1 to the pseudowire and sends an ICCN to the remote LAC, go back to step 2. 13. The local LAC determines whether it should accept the connection request, as described in the previous section. Luo [Page 9] Internet Draft draft-luo-l2tpext-l2vpn-signaling-00.txt November 2002 If it accepts the ICRQ, it sends an ICRP to the remote LAC. 14. The local LAC receives a response from the remote LAC. If it's a CDN, go back to step 2. If it's an ICCN, the local LAC binds f_1 to the pseudowire, go back to step 2. Upon finishing the above algorithm in every LAC participating in L2VPN, an L2VPN is established. 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. 8.3 Application-specified Processing 8.3.1 Cross-connect When a LAC learns the remote Router ID and remote End ID, it may start the signaling right away or wait for the circuit status of the local attachment circuit to become active. After the pseudowire has been successfully established, a LAC binds the attachment circuit to the pseudowire. 8.3.2 Virtual Private LAN Service A VSI is a forwarder in VPLS and consists of a number of attachment circuits and a number of pseudowires. A LAC may have multiple VSIs. When a LAC learns the remote Router IDs and remote End IDs, it may start the signaling right away or wait for the first attachment circuit to join the local VSI. After the pseudowire has been successfully established, a LAC binds the VSI to the pseduowire by making the pseudowire a member link of the bridging domain defined by the VSI. 8.3.3 Colored Pools In the LAC-LAC network reference model, a remote system may have multiple physical or logical attachment circuits, such as Frame Relay DLCIs attached to a LAC, which form a "pool" of attachment circuits. Each pool corresponds to a particular remote system, and is associated with a particular VPN. If there are multiple remote systems of the same VPN attached to a LAC, the LAC will have multiple pools associated with the same VPN. Luo [Page 10] Internet Draft draft-luo-l2tpext-l2vpn-signaling-00.txt November 2002 Each pool is provisioned with an End ID that differentiates itself from other forwarders residing in the same LAC, and a "color", which represents a particular VPN. The format of "color" can be a VPN ID. If pools with a certain color need to be connected in a full-mesh fashion, a pseudowire is created between every pair of pools except the pools residing on the same LAC, and the pseudowire is bound to an unused attachment circuit from each pool. For pools on the same LAC, a local cross-connect is formed to bind two attachment circuits. 9. BGP-based Auto-discovery The BGP-based auto-discovery specified in this document is similar to the schemes described in [BGPVPN] and [LDPVPN], but further optimized. Although this mechanism is only discussed in the L2TP context, it's conceivably useful for LDP-based L2VPN signaling as well. 9.1 Common L2VPN Addressing and NLRI Encoding As outlined in Section 3, each forwarder is assigned with an End Identifier value. An End ID is locally significant and unique regardless what type of forwarder it's associated with. A Router ID is a 32-bit global unique value. A Common L2VPN Address is defined as the concatenation of Router ID and End ID. The Network Layer Reachability Information (NLRI) for BGP Multiprotocol Extension [RFC 2858] is encoded as one or more tuples of the form : - Length: 1 octet The Length field indicates the length in bits of the common L2VPN address. - Prefix: variable-length The Prefix fields carry the Common L2VPN Address. As the Router ID is 32-bit in length, the maximum length of the End ID is 223-bit, which is rounded to 27 whole octets. When using BGP-based auto-discovery, care needs to be taken to ensure the End ID values assigned to the local forwarders do not exceed the maximum length allowed. Unlike the NLRI encoding described in [BGPVPN] and [LDPVPN], the Common L2VPN Addressing scheme uses a single format for all L2VPN applications, and no Route Distinguisher is needed to guarantee the Luo [Page 11] Internet Draft draft-luo-l2tpext-l2vpn-signaling-00.txt November 2002 uniqueness of the prefix, as a Common L2VPN Address is globally unique by definition. 9.2 AFI/SAFI and BGP Capabilities An AFI, to be assigned by IANA, is used for all L2VPN applications. When L2VPN applications choose to use the Common L2VPN Addressing scheme, an SAFI, to be assigned by IANA, is used to identify that the NLRI carried in BGP has such an address format. In order for two BGP speakers to exchange Common L2VPN NLRI, they MUST use the negotiation scheme defined in [RFC 2842] to ensure that both of them are capable of processing such NLRI correctly. This is done by using the Capability Code 1 for Multiprotocol Extensions, and the Capability Value containing the AFI and SAFI specified in this document. The format of the Capabilities parameter is defined in [RFC 2858]. 9.3 Route Targets If a forwarder wishes to be discovered via BGP, it needs to create a Common L2VPN Address, and associate the address with one or more Route Target (RT) Extended Community attributes [BGPEXT]. These attributes are carried in BGP as part of the Path Attributes, along with the LAC itself as the BGP next hop. RTs are used in BGP to control the NLRI distribution. Each BGP speaker can define a set of distribution policies using RTs to control how addresses are advertised and learnt, thereby governing the formation of the L2VPN network topology. To form a full mesh among the forwarders that belong to the same VPN, each forwarder is configured with the same RT value as both the "export RT" and "import RT". This distribution policy will allow these forwarders to be visible to all BGP speakers having this policy. Therefore, the L2VPN signaling will set up a full mesh of pseudowires among these forwarders using the algorithm described the previous section. Sometimes, a hub-and-spoke L2VPN network is desired. This can be achieved by using two different RTs for distribution processing, where one stands for "hub" and the other stands for "spoke". On the hub LAC, the "hub" RT is assigned to local forwarders as the "export RT", and the hub LAC is configured to "import" only the Common L2VPN addresses that have the "spoke" RT. On the spoke LAC, the "spoke" RT is assigned to local forwarders as the "export RT", and the spoke LAC Luo [Page 12] Internet Draft draft-luo-l2tpext-l2vpn-signaling-00.txt November 2002 is configured to "import" only the Common L2VPN addresses that have the "hub" RT. This distribution policy will result in (1) spoke LACs only seeing the forwarders configured on the hub LAC, and (2) a hub LAC seeing all forwarders configured on every spoke LAC. The L2VPN signaling then sets up pseudowires that form the hub-and-spoke topology. A more complex topology is partial mesh. It can be done by using a set of "import RTs" and "export RTs" for distribution processing. 10. Heterogeneous L2VPN Deployment Often there is more than one form of L2VPN application required in a network. For example, an individual attachment circuit on one LAC needs to be connected to a VSI or Colored Pool on another LAC by a pseudowire. In such a case, different L2VPN applications are deployed concurrently and different types of forwarders are inter- connected by pseudowires. The use of Common L2VPN Addressing makes this mix-and-match L2VPN deployment scenario feasible and easy to manage. As forwarders are addressed in the same fashion despite different forwarding behaviors that each may have, a common set of signaling and auto-discovery procedures can be implemented for a heterogeneous L2VPN deployment. In addition, the forwarding behavior of each forwarder is determined by its local characteristics, not those of its peer forwarder. This gives great flexibility to deploy a heterogeneous L2VPN. 11. Intellectual Property Notice The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Luo [Page 13] Internet Draft draft-luo-l2tpext-l2vpn-signaling-00.txt November 2002 12. IANA Considerations This document defines a new L2TP AVP and a pair of AFI/SAFI to be maintained by the IANA. 13. Security Considerations The signaling procedures described in this document does not incur additional security considerations that L2TP already provisions. 14. Acknowledgement Many thanks to Jed Lau and Dmitry Bokotey for their review and insightful feedback. 15. References [RFC 2661] W. Townsley et. al., "Layer 2 Tunnel Protocol (L2TP)", RFC 2661, August 1999. [L2TPv3] J. Lau et. al., "Layer Two Tunneling Protocol (version3)", draft-ietf-l2tpext-l2tp-base-04.txt, November 2002 [L2 FW] L. Andersson et. al., "PPVPN L2 Framework", draft-ietf-ppvpn-l2-framework-00.txt, August 2002 [PWE3L2TP] W. Townsley, "Pseudowires and L2TPv3", draft-townsley-pwe3-l2tpv3-00.txt, June 2002 [BGPVPN] H. Ould-Brahim et. al. "Using BGP as an Auto-Discovery Mechanism for Network-based VPNs", draft-ietf-ppvpn-bgpvpn-auto-03.txt, August 2002 [LDPVPN] E. Rosen, "LDP-based Signaling for L2VPNs", draft-rosen-ppvpn-l2-signaling-02.txt, September 2002 [RFC 2858] T. Bates et. al., "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000 [RFC 2842] R. Chandra et. al., "Capabilities Advertisement with BGP-4", RFC2842, May 2000 [BGPEXT] S. Sangli et. al., "BGP Extended Communities Attribute", draft-ietf-idr-bgp-ext-communities-05.txt, May 2002 Luo [Page 14] Internet Draft draft-luo-l2tpext-l2vpn-signaling-00.txt November 2002 16. Authors' Address Wei Luo Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Email: luo@cisco.com Luo [Page 15]