Network Working Group Wei Luo Internet Draft Cisco Systems, Inc. June 2003 L2VPN Signaling Using L2TPv3 draft-luo-l2tpext-l2vpn-signaling-02.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 (L2TPv3) 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 L2TPv3 describes the use of an L2TP session to cross-connect two Layer 2 circuits attached to a pair of peering LACs. A cross-connect is a basic form of Layer 2 Virtual Private Networks (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-02.txt June 2003 Table of Contents Status of this Memo.......................................... 1 1. Introduction.............................................. 3 2. Network Reference Models and L2VPN Applications........... 3 3. L2TP Protocol Components.................................. 5 3.1 Control Messages...................................... 5 3.2 Existing AVPs for L2VPN............................... 5 3.3 New AVPs for L2VPN.................................... 6 4. Common L2VPN Addressing................................... 7 4.1 Forwarder Identifiers................................. 7 4.2 Provisioning Forwarders............................... 7 4.3 Heterogeneous L2VPNs.................................. 8 5. L2VPN Signaling Procedures................................ 8 5.1 Overview.............................................. 8 5.2 Pseudowire Tie Detection.............................. 9 5.3 Generic Algorithm..................................... 9 5.4 Application-specific Processing....................... 13 5.4.1 Cross-connect.................................... 13 5.4.2 Virtual Private LAN Service...................... 13 5.4.3 Colored Pools.................................... 14 5.5 Distributed L2VPN Applications........................ 14 5.5.1 Splicing Point-to-point Connections.............. 14 5.5.2 Distributed VPLS................................. 15 6. BGP-based Auto-discovery.................................. 16 6.1 NLRI Encoding of L2VPN Addresses...................... 16 6.2 AFI/SAFI and BGP Capabilities......................... 17 6.3 Route Targets......................................... 17 6.4 Inter-AS L2VPN Applications........................... 18 7. Intellectual Property Notice.............................. 19 8. IANA Considerations....................................... 19 9. Security Considerations................................... 19 10. Acknowledgement.......................................... 19 11. References............................................... 19 12. Authors' Address......................................... 20 Luo [Page 2] Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003 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. 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 Models and L2VPN Applications 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 [L2 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 -------------->| Non-distributed 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 Luo [Page 3] Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003 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. [L2 FW] describes an L2VPN application called 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. Another network reference model is the distributed reference model for L2VPN applications [L2 FW]. Instead of a single device, the PE functionality is divided into two PE devices: U-PE and N-PE. PE Functionality PE Functionality ................... ................... . . . . +----+ L2 +----+ +----+ . . +----+ +----+ L2 +----+ | CE |--.-|U-PE|---|N-PE|-..[core network]..-|N-PE|---|U-PE|-.--| CE | +----+ . +----+ +----+ . . +----+ +----+ . +----+ ................... ................... |<--------- emulated service --------->| |<---------------------- L2 service --------------------->| Distributed L2VPN Network Reference Model Unlike the non-distributed reference model where the emulated service is provided by a single pseudowire, the emulated service is provided by splicing multiple pseudowires together in the distributed reference model. Pseudowire splicing is applicable to all the L2VPN applications described above, therefore for each application there will be a non- distributed and a distributed version of deployment. Luo [Page 4] Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003 3. L2TP Protocol Components 3.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 all based on the Incoming Call procedures. 3.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 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 Luo [Page 5] Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003 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 ID The Remote End ID sent in ICRQ instructs the receiving PE to bind the proposed pseudowire to the forwarder that has been assigned with the encoded value. 3.3 New AVPs for L2VPN Local End ID The Local End ID AVP, Attribute Type TBA, is an identifier used to associate a pseudowire to a local forwarder. The Local End ID AVP may also be used in conjunction with the Remote End ID AVP to detect pseudowire ties. When it is omitted in the control messages, it is 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The End Identifier field is a variable-length field whose value is unique for a given PE. 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 field. Luo [Page 6] Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003 4. Common L2VPN Addressing 4.1 Forwarder Identifiers A forwarder identifier is assigned to each forwarder on a given PE that supports L2VPN applications. The Forwarder ID is unique in the context of the Router ID. A Forwarder ID is locally significant and allocated to forwarders regardless their types. A common L2VPN address is defined as the concatenation of the Router ID and the Forwarder ID. It's called "common" because the Forwarder ID value is assigned from a common name space for different types of forwarders. The common L2VPN addressing scheme makes it possible to interconnect not only forwarders of the same type, but those of different types. 4.2 Provisioning Forwarders In simple cross-connect, each individual attachment circuit is assigned with a Forwarder ID value. The value may be an arbitrary integer or a descriptive string. Each attachment circuit is provisioned with the L2VPN address of the remote attachment circuit and the next-hop PE address. In VPLS, each VSI is assigned with a Forwarder ID value. The value may be the VPN-ID of the VPLS domain. Each VSI is provisioned with the L2VPN addresses of the remote VSIs and the next-hop PE address. In colored pool, each pool is assigned with a Forwarder ID and a "color". The Forwarder ID value may be an arbitrary integer or a descriptive string. The "color" can be a VPN-ID. Each pool is provisioned with the L2VPN addresses of the remote pools and the next-hop PE address. If the remote Router ID in the L2VPN address is also the next-hop PE address, the provisioning parameters can be reduced to just the L2VPN address, i.e. the Router ID and Forwarder ID of the remote forwarder. In addition, the provisioning can be accomplished through either manual configuration or some auto-discovery procedure. Luo [Page 7] Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003 4.3 Heterogeneous L2VPNs Often there is more than one form of L2VPN application required in a network. For example, an individual attachment circuit on one PE needs to be connected to a VSI or colored pool on another PE 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. 5. L2VPN Signaling Procedures 5.1 Overview Assume a PE assigns a Forwarder ID 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 ID values encoded in the Local and Remote End ID AVPs in order to determine the following: - whether it has a local forwarder with the Forwarder ID value specified in the Remote End ID AVP, Luo [Page 8] Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003 - whether the remote forwarder with the Forwarder ID value specified in the Local End ID AVP 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 Remote End ID and Local End ID AVPs are present in the ICRQ, the receiving PE compares them against the Local End ID and Remote End ID that it already sent in an ICRQ, respectively. 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 the Remote End ID AVP is present in the ICRQ, the Local End ID is assumed to have the same value as the Remote End ID. The receiving PE compares the received Remote End ID with the Local End ID that it already sent in an ICRQ. If the Local End ID in that 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. 5.3 Generic Algorithm Despite the apparent disparity among different L2VPN applications, a common set of signaling procedures can be defined. 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 Luo [Page 9] Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003 TARGET_FORWARDERS list. These two lists can be constructed by manual configuration and/or some auto-discovery procedure. SOURCE_FORWARDERS TARGET_FORWARDERS ------------------------------------------------------------------ s1: t1: s2: t2: s3: t3: ... ... The following 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 PE participating in 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 Forwarder ID 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. 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 Forwarder IDs of source and target forwarders are encoded in the Local and Remote End ID AVPs, respectively. Luo [Page 10] Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003 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 in order to maintain the control connection's reliable transport, 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 11] Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003 ---------> 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 12] Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003 | | 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 5.4 Application-specific Processing 5.4.1 Cross-connect When a PE learns the L2VPN address of the remote attach circuit, 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 PE binds the attachment circuit to the pseudowire. 5.4.2 Virtual Private LAN Service A PE may have multiple VSIs. When a PE learns the L2VPN address of the remote VSIs, 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 PE binds the VSI to the pseudowire by making the pseudowire a member link of the bridging domain defined by the VSI. Luo [Page 13] Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003 5.4.3 Colored Pools A CE may have multiple physical or logical attachment circuits, such as Frame Relay DLCIs attached to a PE, which form a "pool" of attachment circuits. Each pool corresponds to a particular CE and is associated with a particular VPN. If there are multiple CEs of the same VPN attached to a PE, the PE will have multiple pools associated with the same VPN. 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 PE, and the pseudowire is bound to an unused attachment circuit from each pool. For pools on the same PE, a local cross-connect is formed to bind two attachment circuits. 5.5 Distributed L2VPN Applications The advantages of this generic L2VPN signaling procedure include not only being able to interconnect heterogeneous L2VPN applications but providing a unified signaling procedure for both non-distributed and distributed L2VPN applications. In other words, no special signaling or provisioning is required for distributed L2VPN applications. A local forwarder needs not to know whether the remote forwarder is an attachment circuit, a VSI, a colored pool, or even a pseudowire that acts as a "proxy" of some other forwarder. The following sections illustrate how to apply the generic L2VPN signaling procedures to distributed L2VPN applications. 5.5.1 Splicing Point-to-point Connections Suppose U-PE 1 and U-PE 2 each have an attachment circuit or colored pool that needs to be interconnected via pseudowires. The end-to-end connection is considered as point-to-point regardless of the number of pseudowires spliced together. The forwarders on U-PE 1 and U-PE 2 are denoted in the form of their L2VPN addresses. AC/Pool 1: AC/Pool 2: U-PE 1 --- N-PE 3 --- N-PE 4 --- U-PE 2 As described in Section 4.2 on U-PE 1, AC/Pool 1 is provisioned to Luo [Page 14] Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003 connect to with AC/Pool 2 and N-PE 3 is the next-hop PE address. Similarly on U-PE 2, AC/Pool 2 is provisioned to connect to AC/Pool 1 and N-PE 4 is the next-hop PE. N-PE 3 has two "proxy" forwarders that represent the two actual forwarders. The "proxy" AC/Pool 1 is provisioned to connect with the AC/Pool 2 and N-PE 4 is the next-hop PE address. The "proxy" AC/Pool 2 is provisioned to connect to AC/Pool 1 and U-PE 1 is the next-hop PE address. N-PE 4 is similarly provisioned. The knowledge of how to provision each forwarder can be obtained from manual configuration or some auto-discovery procedure. The signaling procedures are excuted on all U-PEs and N-PEs. When the targeted L2VPN address in the pseudowire setup message matches a local forwarder, real or "proxy", the PE binds the pseudowire to it. N-PEs bind pseudowires to "proxy" forwarders and U-PEs bind pseudowires to real forwarders. 5.5.2 Distributed VPLS In distributed VPLS the U-PE has the VSI functionality and the N-PE is responsible for splicing the pseudowires from the U-PE to other U-PEs and N-PEs. Suppose each U-PE has a VSI belonging to the same VPLS domain. Even though each VSI could have a different Forwarder ID on each U-PE, it does not makes any difference in this example. So let's say it has a common value, VPN-ID, for the sake of simplicity. The forwarders on U-PEs are denoted in the form of their L2VPN addresses. VSI 1: VSI 2: VSI 3: VSI 4: U-PE 1 ----+ +---- U-PE 3 | | | | N-PE 5 ------- N-PE 6 | | | | U-PE 2 ----+ +---- U-PE 4 To set up full-mesh connectivity among the VSIs, each U-PE needs to Luo [Page 15] Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003 have three pseudowires to the adjacent N-PE. N-PE then needs to splice these three pseudowires to another three pseudowires which go to other U-PE and N-PE respectively. U-PE 1 learns three remote forwarders: VSI 2, VSI 3 and VSI 4. And VSI 1 is provisioned to connect to all three and the next-hop PE address for all three is N-PE 5. Other U-PEs are similarly provisioned. N-PE 5 has four "proxy" forwarders representing the four actual VSI forwarders on the U-PEs. The "proxy" VSI 1 is provisioned to connect to VSI 3 and VSI 4 with the next-hop PE address as N-PE 6, and to VSI 2 with the next-hop PE address as U-PE 2. Other "proxy" forwarders are provisioned in the similar fashion. Other N-PEs are also similarly provisioned. The knowledge of how to provision each forwarder can be obtained from manual configuration or some auto-discovery procedure. The signaling procedures are excuted on all U-PEs and N-PEs. When the targeted L2VPN address in the pseudowire setup message matches a local forwarder, real or "proxy", the pseudowire is bound to it. N- PEs bind pseudowires to "proxy" forwarders and U-PEs bind pseudowires to real forwarders. 6. 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 is conceivably useful for LDP-based L2VPN signaling as well. 6.1 NLRI Encoding of L2VPN Addresses As defined in Section 4, a L2VPN address is the concatenation of the 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. Luo [Page 16] Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003 - Prefix: variable-length The Prefix fields carry the L2VPN address. When using BGP-based auto-discovery, care needs to be taken to ensure the Forwarder 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. This makes it easy to deploy heterogeneous L2VPNs with BGP-based auto-discovery. 6.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 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]. 6.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 PE 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 Luo [Page 17] Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003 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 PE, the "hub" RT is assigned to local forwarders as the "export RT", and the hub PE is configured to "import" only the Common L2VPN addresses that have the "spoke" RT. On the spoke PE, the "spoke" RT is assigned to local forwarders as the "export RT", and the spoke PE is configured to "import" only the Common L2VPN addresses that have the "hub" RT. This distribution policy will result in (1) spoke PEs only seeing the forwarders configured on the hub PE, and (2) a hub PE seeing all forwarders configured on every spoke PE. 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. 6.4 Inter-AS L2VPN Applications When L2VPN PEs span across AS boundries, for non-distributed L2VPN applications we need to ensure the inter-AS connectivity among the PEs. In the case that L2TP use IP or UDP as transport, this means inter-AS IP reachability, which is provided by BGP. Sometimes service providers want to enforce certain policies at the AS boundries including those for L2VPN applications. And they want the inter-AS L2VPN control connections and pseudowires to run only between the ASBRs. PE 1 ----+ +---- PE 3 | | | | ASBR 1 ------- ASBR 2 | | | | PE 2 ----+ +---- PE 4 This is very similar to the network reference model of distributed L2VPN applications. Thus, the objectives can be accomplished by designating the PEs as U-PE and the ASBRs as N-PE. The BGP sessions between U-PE and N-PE are iBGP sessions, and those between N-PEs are eBGP sessions. In addition to operations described in Section 5.5, each ASBR needs to rewrite the BGP next-hop attribute of the received L2VPN NLRIs to be itself or another ASBR in the same AS before Luo [Page 18] Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003 propagating them to its iBGP and eBGP peers. 7. 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. 8. IANA Considerations This document defines a new L2TP AVP and a pair of AFI/SAFI to be maintained by the IANA. 9. Security Considerations The signaling procedures described in this document does not incur additional security considerations that L2TP already provisions. 10. Acknowledgement Many thanks to Mark Townsley, Jed Lau and Dmitry Bokotey for their review and insightful feedback. 11. 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", Luo [Page 19] Internet Draft draft-luo-l2tpext-l2vpn-signaling-02.txt June 2003 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 12. Authors' Address Wei Luo Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Email: luo@cisco.com Luo [Page 20]