Internet Engineering Task Force CY Lee INTERNET DRAFT M Higashiyama July 2002 CE-based Virtual Private LAN 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." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This draft describes how some existing technologies can be leveraged to realize provider provisioned Virtual Private LAN (VPL) service. 1. Overview In CE-based VPL, tunnels are setup between sites of a VPL. At a CE (Customer Edge, See [PPVPN-REQ]),Ethernet traffic from a VPL is encapsulated in for e.g. a L2TP/GRE/IP tunnel or FR/ATM VC and transported over the (IP/FR/ATM) network to another CE of the VPL. The receiving CE decapsulates the Ethernet frame and forward the frame to the destination node in the VPL. In this initial version of the draft, the focus is on using L2TP [L2TP, L2TPv3] tunnels over an IP PSN (Packet Switching Network) Other tunneling protocols shall be considered later. The following two figures [adapted from [LT2P-ETH]] describe the Expires January 2003 [Page 1] Internet Draft CE-based VPL July 2002 reference models to support VPL services. Emulated Service (Broadcast Domain/"LAN", within dotted lines) .................................. Native . . Native Ethernet . . Ethernet or . |<-- PSN Tunnel-->| . or VLAN . . VLAN Service . +----+ +----+ . Service | . |CE1 | | CE2| . | Customer-------.--| |=================| |-.------- Customer LAN | . | | | | . | LAN Site 1 | . +----+ +----+ . | Site 2 . \\ // . . \\ // . . \\ // . . PSN \\ // PSN . . Tunnel \\ +----+ // Tunnel. . \\|CE3 |// . . \| |/ . . +----+ . . | . .................................. | | Native Ethernet or VLAN Service | | Customer LAN Site 3 | | Customer ----------------|----------------Customer LAN Site 1 | LAN Site 2 | |----------------Customer | LAN Site 3 Fig 1 Emulated Ethernet Segment Expires January 2003 [Page 2] Internet Draft CE-based VPL July 2002 +-------------+ +-------------+ | Emulated | | Emulated | | Ethernet | | Ethernet | | (including | Emulated Service | (including | | VLAN) |<==============================>| VLAN) | | Services | | Services | +-------------+ Ethernet Pseudo Wire +-------------+ |Encapsulation|<==============================>|Encapsulation| |& Bridging | |& Bridging | +-------------+ +-------------+ | | PSN Tunnel | | | IP |<==============================>| IP | +-------------+ +-------------+ | Physical | | Physical | +-----+-------+ +-----+-------+ | | | PSN | | ____ ___ ____ | | _/ \___/ \ _/ \__ | | / \__/ \_ | | / \ | +========/ |===+ \ / \ / \ ___ ___ __ _/ \_/ \____/ \___/ \____/ Fig 3: VPL Protocol Stack Reference Model 2. Leveraging existing solutions - CE-based VPL CE-based VPL over different types of tunneling technologies has been used for a number of years now, and could be viewed as a proven technology. A network user provisions the required tunnels (or circuits) at a CE to remote CE(s) and the CEs bridge Ethernet traffic over the tunnels. Providers already has the management infrastructure to manage and configure remote CEs, although automated discovery of configuration parameters can be introduced where possible to reduce manual configuration of CEs. Should CE-based VPL approach be leveraged by providers to offer VPL service to customers? 2.1 CE-based VPL features * connectivity states incurred only in CEs, no VPL connectivity states incurred in PEs (Provider Edge Equipment) or Ps (Provider's Expires January 2003 [Page 3] Internet Draft CE-based VPL July 2002 network equipment) [See PPVPN-REQ]. * CEs belonging to the same VPL learn, store, manage VPL forwarding information and bridges traffic within the VPL, PEs do not have to learn MAC addresses from different VPLs, hence this approach scales for large number of VPLs and total MAC addresses in a network. The provider need not set limits on the number of MAC addresses in each VPL/CE at PEs. * bridging within a VPL does not affect other VPLs (or customers). A CE bridge which is not functioning correctly will only affect a VPL. In contrast, if bridging is also performed at PEs, a malfunctioning CE may cause network instability and affect other VPLs as well. Hence a CE-based VPL would be operationally stabler. * allow routers of a VPN to peer using a VPL, hence routing overlay is invisible to routers and appear as a broadcast domain instead. This simplifies VPN router configuration for the customer. * CEs may be located intra-domain or inter-domain as long as CEs have IP reachability to each other. CEs in different metro network or rings can send VPL traffic to each other without resorting to Stackable VLAN as long as there is IP reachability in the network. (Note: This does not imply routing is required e.g. the CEs may all be in the same subnet in the provider's network) * optimal bridging or forwarding of traffic from one CE to another CE within PSN, but VPL traffic is not bridged optimally unless full meshed of IP tunnels are used. Network based VPL (where bridging is performed in the network) is more optimal in forwarding traffic * In a network based VPL, as the number of customers/VPLS and total MAC addresses grow in a provider's network, existing devices in the network will need to be upgraded or replace by new devices. A CE- based VPL approach scales as the number of VPLs and total number of MAC addresses in VPLs grows and allows CEs in different metro network to be interconnected seamlessly. * Multiple virtual tunnels to other CE sites can be automatically configured on CEs if a tunnel endpoint information discovery mechanism is used. * CE-based VPL can be offered over an existing VLAN (802.1q) network and co-exist with existing VLANs * new VPLs can be added transparently in an IP/MPLS network, without having to upgrade PEs with bridging functions Expires January 2003 [Page 4] Internet Draft CE-based VPL July 2002 * existing customers' Ethernet switches can be connected to a provider provisioned CE-based VPL. 3. PSN Tunnels A CE setup PSN tunnels (L2TP/GRE/IPSec) to other remote CE sites. CEs may be configured with or auto-discover the addresses of remote CE sites. See Section on "Tunnel Endpoint Information". In this initial version of the draft, only L2TP tunnels shall be considered. 4. Ethernet over L2TP [L2TP] was originally specified for tunneling PPP sessions. [L2TPv3] The base L2TP protocol which does not include the PPP specific mechanisms is now being specified in [L2TPv3]. [L2TPv3] provides new extensions for tunneling other L2 protocols such as Ethernet, ATM and Frame Relay, but the specific L2TP extensions required for each L2 technology are being specified in other documents e.g. [L2TP-FR], [L2TP-ETH]. 4.1 Alternatives Two different variants of providing VPL service are identified: i) using [BCP], tunneling over PPP and [L2TP] is described in [EOL2TP] as voluntary tunneling. This approach does not require any change in [L2TP] or [BCP] specifications. ii) directly over L2TPv3. The changes required to tunnel point to point Ethernet pseudo wire (from one PE to another PE) directly over L2TP are being specified in [L2TP-ETH]. [Lassere-Vkompella] describes point to multipoint Ethernet over MPLS, where the bridging of VPL traffic is performed at the PEs. This rest of Section 4 describes how L2TP tunneling in [L2TP-ETH] can be used to tunnel Ethernet over L2TP from one CE to another CE (where the pseudo wire endpoints are CEs), how bridging is performed at CEs and how multipoint Ethernet pseudo wire (or a virtual broadcast domain/LAN service) can be realized. Section 6 describes how traffic forwarding over a VPL can be improved for both (i) and (ii). 4.1.1 Establishing L2TPv3 session A CE establishes a L2TPv3 control connection and session to remote sites of the VPL. [See section on "Tunnel Endpoint Information"] The L2TPv3 parameters defined in [L2TP-ETH] for e.g. pseudo wire type, Expires January 2003 [Page 5] Internet Draft CE-based VPL July 2002 session id, speed and MTU are signaled during the session setup. A virtual interface is created for every L2TP session setup to a remote site. 4.1.1.1 Tunnel Endpoint Authentication If a CE authenticate the remote CE using L2TP, a Challenge AVP is included in the L2TP control connection setup message, as described in [L2TPv3]. If the expected response received from a CE does not match, the establishment of the control connection MUST be disallowed. A CHAP-like [RFC1994] authentication is used at each CE. To use L2TP tunnel authentication, a single shared secret MUST exist between the two CEs. [See section on "Tunnel Endpoint Information" on shared key configuration]. L2TP (Layer Two Tunneling Protocol) may use IPsec for tunnel authentication as described in [L2TP-IPSEC] instead. 4.1.2 Bridging A CE learns MAC addresses from the customer facing ports and the virtual interfaces (or the tunnels to remote CE sites). When a new MAC address is learned, the MAC address is associated with the virtual interface or ports where the frame arrives. When a frame with the cached MAC address is received, the CE knows which virtual interface or port to forward the frame to. When a frame with a new MAC address is received, a CE floods the frame to all other ports or virtual interfaces, except the interface where the frame is received from. To optimize forwarding of traffic over a VPL see the next section. The learning, bridging, filtering and forwarding procedures are as defined in [802.1d] and [802.1q], except that the ports on a switch in this case can be a virtual interface as well as a physical port. 5. Optimizing bridging over a VPL To optimize the forwarding of traffic in a VPL, a full mesh of tunnels may be setup among CE sites. Bridging is modified such that traffic is not flooded to interfaces participating in the fully- meshed VPL connectivity. In this case, since each CE has a direct tunnel to other CEs, traffic arriving at a CE need not be forwarded to other CEs. Spanning Tree should be turned off if CEs are fully- meshed. The states in setting up a full meshed of tunnels (over an IP network) are only incurred at CEs. [Note: If the number of sites of Expires January 2003 [Page 6] Internet Draft CE-based VPL July 2002 a VPL is very large, the VPL should be split into multiple subnets/VPLs instead]. 6. Tunnel Endpoints Information The tunnel endpoints information may be pre-configured or remotely provisioned or, a mechanism to discover and distribute the tunnel endpoints information may be used or a mechanism where tunnel endponts information are retrieved from a server (e.g. RADIUS) may be used. To avoid having to provision deployed CEs, a mechanism to auto discover and distribute VPL site information is useful. [RADIUS], [VPLS-DNS] and [CE-AUTOCONFIG] are examples of mechanisms that may be used for this purpose. If previously the provisioning of a full- meshed of CEs is performed directly on the CEs, an auto discovery mechanism reduces the provisioning required for a VPL to O(n), where n is the number of sites in a VPL. More detailed management or troubleshooting of CEs may be performed over existing infrastructure used to manage remote CEs. 7. Fault Detection The procedures for PW monitoring and fault detection described in [L2TP-ETH] may be used to monitor the virtual interfaces or L2TP sessions. Any alarms generated may be sent to the NOC via e.g. the existing infrastructure used to manage remote CEs. 8. Acknowledgment The authors would like to thank Jeremy deClercq and Jeanne DeJaegher for their helpful comments on this draft. The draft benefited from discussions with Sasha Cirkovic, Jeff Smith, Roy Nighswander, Neil Harrison, Alexis Berthillier, Dean Welsh and Arnold Jansen. Normative References [802.1D] IEEE, "ISO/IEC 15802-3:1998,(802.1D, 1998 Edition), Information technology --Telecommunications and information exchange between systems --IEEE standard for local and metropolitan area networks --Common specifications-Media access control (MAC) Bridges", June, 1998. [802.1Q] ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", 1998 . Expires January 2003 [Page 7] Internet Draft CE-based VPL July 2002 [802.3] IEEE, "ISO/IEC 8802-3: 2000 (E), Information technology--Telecommunications and information exchange between systems --Local and metropolitan area networks --Specific requirements --Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", 2000. [BCP] Mitsuru H. and Baker, "PPP Bridging Control Protocol (BCP)", RFC 2878, July 2000. [L2TP] Townsley, W., Valencia, A., Rubens, A., Singh Pall, G., Zorn, G., Palter, B., "Layer Two Tunneling Protocol (L2TP)", RFC 2661 August 1999 [L2TPv3] Lau, J., Townsley, M., Valencia, A., Zorn, G., Goyret, I., Pall, G., Rubens, A., Palter, B., "Layer Two Tunneling Protocol "L2TP"", (draft-ietf-l2tpext- l2tp-base-01.txt), work in progress, July 2001. [L2TP-IPSEC] RFC 3193, B. Patel,B. Aboba,W. Dixon, G. Zorn, S. Booth "Securing L2TP using IPSec" [L2TP-ETH] So, et al., Ethernet Pseudo Wire Emulation Edge-to-Edge (PWE3). draft-so-pwe3-ethernet-01.txt, March 2002. Informational References [EOL2TP] M. Higashiyama, "Ethernet Over L2TP", (draft-higashiyama- eol2tp-01.txt), November 2001 [PPVPN-REQ] M. Carugi,D. McDysan, L. Fang, F. Johansson, Ananth Nagarajan, J. Sumimoto, R. Wilder, "Service requirements for Layer 3 Provider Provisioned Virtual Private Networks" (draft-ietf-ppvpn- requirements-04.txt) [CEVPN] De Clercq J., et al., "Provider Provisioned CE-based Virtual Private Networks using IPsec", draft-ietf-ppvpn-ce-based-01.txt, work in progress. [Kompella] Kompella, K., Leelanivas, M., Vohra, Q., Bonica, R., Metz, E., Ould-Brahim, H., Achirica, J., Z., "MPLS-based Layer 2 VPNs", (draft-kompella- ppvpn-l2vpn-00.txt), work in progress, July 2001. [Martini-encap] Martini, L., El-Aawar, N., Tappan, D., Rosen, E., Jayakumar, J., Vlachos, D., Liljenstolpe, C., Heron, G., Kompella, K., Vogelsang, S., Shirron, J., Smith, T., Radoaca, V., Malis, A., Sirkay, V., Cooper, D., "Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks", (draft-martini- l2circuit- Expires January 2003 [Page 8] Internet Draft CE-based VPL July 2002 encap-mpls-03.txt), work in progress, July 2001. [PWE3-frame] Pate, P., Xiao, X., So, T., Malis, A., Nadeau, T., White, C., Kompella, K., Johnson, T., "Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3)" (draft- pate-pwe3-framework-02.txt), work in progress, July 2001. [Laserre-Vkompella] Lasserre, M, Kompella, V, et al, "Virtual Private LAN Services over MPLS" draft-lasserre-vkompella-ppvpn-vpls-01.txt, March 2002 [VPLS-DNS] Heinanen, "DNS/LDP Based VPLS". draft-heinanen-dns-ldp- vpls-00.txt, January 2002. [CE-AUTOCONFIG] CY Lee, "CE Auto-Configuration", (draft-lee-ppvpn-ce- auto-config-01.txt), work in progress, July 2002 [RADIUS] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial in User Service (RADIUS)", RFC 2865, June 2000. Authors' Information Cheng-Yin Lee Cheng-Yin.Lee@alcatel.com Mitsuru Higashiyama Mitsuru.Higashiyama@yy.anritsu.co.jp Expires January 2003 [Page 9]