Internet Engineering Task Force Juha Heinanen INTERNET DRAFT Song Networks Expires December 2002 June, 2002 DNS/L2TP Based VPLS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 This memo describes a simple mechanism to implement provider provisioned Virtual Private LAN Service (VPLS) using DNS and L2TP as control and data plane protocols. 1. Introduction This memo describes a simple mechanism to implement provider provisioned Virtual Private LAN Service (VPLS) [1] using DNS [2] and L2TP [3] as control and data plane protocols. DNS is deployed as is without modifications. L2TP is used as described in [4] with minor changes. An advantage of a DNS based solution for provider based VPNs is that it doesn't require BGP implementation or configuration complexity in the PE routers and can be easily deployed also in inter-AS cases where the VPN sites are attached to PEs in more than one AS. An Heinanen DNS/L2TP Based VPLS [Page 1] INTERNET DRAFT June, 2002 advantage of DNS as a directory is that it has been in wide use for years and can thus be deployed without any new standardization effort. See [2] for more discussion on the use of DNS for VPN discovery. A companion memo [5] describes a similar DNS based VPLS solution, which uses LDP for signaling and MPLS label stack encapsulation for data transport. An L2TP based solution may be preferable to providers who are already familiar with L2TP and are not deploying MPLS. An L2TP based solution may also be considered simpler to manage, because L2TP tunnels are bidirectional and L2TP bundles both control and data planes in a single protocol. 2. Service Description This memo supports VPLS service in a mode where each VPLS instance (also called VPN for short) connects one or more CEs (also called VPN sites) to a common virtual LAN. A VPN site can use either 802.1q tagged or untagged (but not both) Ethernet frames to communicate with the other sites of the VPN. In case of tagged frames, each VPN site MUST use a single VLAN ID for the same VPN, but the VLAN ID MAY differ at each VPN site. VPLS service MAY support Differentiated Services treatment of tagged or untagged Ethernet frames. In case of tagged frames, the desired treatment of the frame is coded in the 802.1p User Priority field. In case of untagged frames, all frames sent by a site receive a default treatment. Differentiated Services treatment as well as mapping of 802.1p User Priority values to DiffServ code points of L2TP tunnels is VPLS specific and outside the scope of this memo. 3. Addition of Sites 3.1 Configuration Actions A DNS/L2TP based VPLS is very easy to provision. Only the following two configuration actions are needed when a new site (CE) is added to a VPN (VPLS instance): (1) If the PE does not previously connect any sites of this VPN, the IP address (A record) of the PE is added to DNS under domain name vpn-name.domain The label "vpn-name" uniquely identifies the VPN within "domain", which belongs to the administrative "owner" of the VPN. An example of the domain name of a VPN is Heinanen DNS/L2TP Based VPLS [Page 2] INTERNET DRAFT June, 2002 bobsVpn.serviceProvider.net. (2) An Ethernet "interface" of the PE to which the site is connected to is configured to belong to the VPN by associating the interface with the domain name of the VPN. The interface MAY be 802.1Q tagged or untagged. In the former case, the VLAN ID that used to connect the site to the VPN MUST be specified. Note that also in the case of a multi-provider VPN, the administrative "owner" of the VPN is the single body that operates the master DNS server for the VPN zone. The "owner" of a VPN MAY choose to make all updates to the zone data of the VPN by itself or MAY allow other providers to dynamically update the zone data. 3.2 Protocol Actions After the above configuration actions, the following protocol actions take place in sequence at the PE of the new site if the PE of the new site doesn't previously connect site(s) of the VPN: (1) The PE of the new site checks that its own IP address has become available in the DNS under the domain name of the VPN. (2) The PE of the new site queries DNS for IP addresses of the other (remote) PEs of the VPN. (3) The PE of the new site establishes an L2TP Control Connection with each the remote PEs unless one already exists or is being established. The Control Connection is established as defined in section 6.2.1.1 of [5] with a restriction as described below. (4) The PE of the new site establishes for this VPN an L2TP session with each of the remote PEs unless one already exists or is being established. L2TP sessions are established as defined in section 6.2.1.2 of [5] with a change as described below. When establishing a Control Connection, the legal "Pseudo Wire Types" that may be included in the Pseudo Wire Capabilities List are: 0x0004 - Sessions without control word for connecting Ethernet VLANs are allowed 0x8004 - Sessions with control word for connecting Ethernet VLANs are allowed When establishing an L2TP session, a new L2TP AVP called VPN ID is Heinanen DNS/L2TP Based VPLS [Page 3] INTERNET DRAFT June, 2002 defined to indicate the VPLS instance with which the L2TP session is associated with. The VPN ID AVP has Vendor ID value 0 and Attribute Type TBD by IANA. Attribute Value field of the VPN ID 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Domain name (vpn-name.domain) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The VPN ID AVP replaces the PW ID and Group ID AVPs used in [5]. The following protocol actions take place in sequence at a PE when it receives an L2TP Incoming-Call-Request or Outgoing-Call-Request from another PE that includes a VPN ID AVP: (1) The PE checks from the DNS that the other PE belongs to the VPN indicated in the VPN ID AVP and that it itself has at least one site in that VPN. If not, the PE responds with a Call-Disconnect-Notify and no other protocol actions take place at the PE. (2) The PE checks if it already has (or is being established) an L2TP session with the calling PE for the VPN indicated in the VPN ID AVP. If so, the PE responds with a Call-Disconnect-Notify and no other protocol actions take place at the PE. (3) Otherwise the PE accepts the request with an Incoming-Call-Reply or an Outgoing-Call-Reply. If the PE of the new site already connects site(s) of this VPN, no protocol actions take place at either the PE of the new site or at the remote PEs. 4. Removal of Sites 4.1 Configuration Actions The following configuration actions are needed when an existing site (CE) is removed from a VPN: (1) If the site to be removed is the last site of the VPN at the PE, the IP address of the PE is removed from DNS under the domain name of the VPN. (2) The site is removed from the VPN by unconfiguring the VPN from Heinanen DNS/L2TP Based VPLS [Page 4] INTERNET DRAFT June, 2002 the "interface" of the PE to which the site is connected to. 4.2 Protocol Actions After the above configuration actions, the following protocol actions take place in sequence at the PE of the removed site if the removed site was the last site of the VPN at the PE: (1) The PE checks that its IP address does not anymore exist in the DNS under the domain name of the VPN. (2) The PE tears down any existing L2TP sessions for the VPN by sending each remote PE a Call-Disconnect-Notify. When a remote PE receives a Call-Disconnect-Notify from the PE of the removed site, no other protocol actions are needed in addition to normal clean up of the corresponding L2TP session. If the L2TP session that was teared down between two PEs was the last session associated with the Control Connection, either PE MAY tear down the Control Connection. 5. Failure Recovery If a PE looses its Control Connection with another PE having site(s) in a common VPN, the PE tries to re-establish the Control Connection until (a) the Control Connection gets re-established or (b) this PE or the other PE no longer have site(s) in this VPN. Once the Control Connection gets re-established, the PE re-establishes an L2TP session with the other PE for this VPN as described in section 3.2. If an L2TP session becomes disconnected, the two PEs try to re- establish it as described in section 3.2 as long as the two PEs have site(s) in the VPN associated with the session. When a PE recovers from a crash, it adds each of the configured VPN site(s) to their respective VPN(s) as described in section 3.2. 6. Exponential Back-off Behavior If any protocol action does not succeed immediately, normal behavior is that the PE keeps on trying with exponential back-off until the action either succeeds or becomes invalid due to a change in VPN configuration. If the protocol action fails for an implementation specific prolonged period of time, the PE SHOULD notify the "owner" of the VPN about the problem via a management action. Heinanen DNS/L2TP Based VPLS [Page 5] INTERNET DRAFT June, 2002 7. Data Plane The PEs that host the sites of a VPN act as virtual, fully connected learning bridges for the VPN. When a PE receives a Ethernet frame from a CE for a particular VPN, it adds to it a 802.1q tag (if not already present) and then sets the VLAN ID to zero. Treatment of the 802.1p User Priority field is VPLS specific and outside the scope of this memo. When a PE needs to send an Ethernet frame to a VPN site connected to it, it either overwrites the VLAN ID with the VLAN ID used by the site for this VPN or removes the 802.1q tag if the interface of the VPN site is untagged. Treatment of the 802.1p User Priority field is VPLS specific and outside the scope of this memo. When a PE needs to send an Ethernet frame to another PE, the PE processes the frame as described in section 6.1 of [4] using the L2TP session established for this VPLS instance. Mapping of the 802.1p User priority value to DiffServ code point of the L2TP packet is VPLS specific and outside the scope of this memo. 7. Security Considerations Security of DNS/L2TP based VPNs depends on security of DNS and L2TP. Security of DNS is covered in section 9 or [2] and security of L2TP is covered in section 9 of [3]. Acknowledgements TBD. References [1] Augustyn, et al., "Requirements for Virtual Private LAN Services (VPLS)". draft-ietf-ppvpn-vpls-requirements-00.txt, March 2002. [2] Luciani et al., "Using DNS for VPN Discovery". draft-luciani- ppvpn-vpn-discovery-02.txt, March 2002. [3] Lau, et al., "Layer Two Tunneling Protocol (Version 3) "L2TPv3"". draft-ietf-l2tpext-l2tp-base-02.txt, March 2002. [4] So, et al., Ethernet Pseudo Wire Emulation Edge-to-Edge (PWE3). draft-so-pwe3-ethernet-01.txt, March 2002. [5] Heinanen, "DNS/LDP Based VPLS". draft-heinanen-dns-ldp- vpls-00.txt, January 2002. Heinanen DNS/L2TP Based VPLS [Page 6] INTERNET DRAFT June, 2002 Author's Address Juha Heinanen Song Networks, Inc. Hallituskatu 16 33200 Tampere, Finland Email: jh@song.fi Full Copyright Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Heinanen DNS/L2TP Based VPLS [Page 7]