Internet Draft draft-lasserre-tls-mpls-00.txt August 2001 Internet Draft Marc Lasserre Document: draft-lasserre-tls-mpls-00.txt Nick Slabakov Rob Nath Riverstone Networks Pascal Menezes Loa Andersson Terabeam Networks Utfors Andrew Smith Shahid Akhtar Consultant Ciena Tissa Sevenirathne Pierre Lin Force10 Networks Yipes Communication Lewis Eatherton Vasile Radoaca Excite@Home Nortel Networks Ivy Hsu Foundry Networks Expires: February 2002 August 2001 Transparent VLAN Services over MPLS 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. Lasserre et al. [Page 1] Internet Draft draft-lasserre-tls-mpls-00.txt August 2001 Abstract This document describes a transparent virtual LAN service (VLS) solution over MPLS, sometimes known as Transparent LAN Services (TLS). VLS simulates an Ethernet virtual 802.1d bridge [6] [7] for a given set of users. It delivers a layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses that is closed to a given set of users. Many VLS services can be supported from a single PE node. Conventions 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 Placement of this Memo in Sub-IP Area RELATED DOCUMENTS http:// search.ietf.org/internet-drafts/draft-martini-l2circuit- trans-mpls-06.txt http://search.ietf.org/internet-drafts/draft-martini-l2circuit- encap-mpls-02.txt WHERE DOES THIS FIT IN THE PICTURE OF THE SUB-IP WORK PPVPN WHY IS IT TARGETTED AT THIS WG The charter of the PPVPN WG includes L2 VPN services and this draft specifies a model for Ethernet L2 VPN services over MPLS. JUSTIFICATION Existing Internet drafts specify how to provide point-to-point Ethernet L2 VPN services over MPLS. This draft defines how multipoint Ethernet services can be provided. Lasserre et al. [Page 2] Internet Draft draft-lasserre-tls-mpls-00.txt August 2001 Table of Contents Status of this Memo................................................1 Abstract...........................................................2 Conventions........................................................2 Table of Contents..................................................3 1. Overview........................................................4 2. Bridging Model for MPLS.........................................4 2.1 Flooding and Forwarding........................................5 2.2 Address Learning...............................................6 2.3 LSP Topology...................................................6 2.4 Loop free L2 VPN...............................................6 2.5 L2 VPN Provisioning............................................7 2.6 LDP Based Discovery............................................7 3. Security Considerations.........................................8 4. References......................................................9 5. Author's Addresses.............................................10 Lasserre et al. [Page 3] Internet Draft draft-lasserre-tls-mpls-00.txt August 2001 1. Overview The following discussion applies to devices that serve as Label Edge Routers (LERs) on a MPLS network that is VLS capable. It will not discuss the behavior of transit Label Switch Routers (LSRs) that are considered a part of MPLS network. The MPLS network provides a number of Label Switch Paths (LSPs) that form the basis for connections between LERs attached to the same MPLS network. The resulting set of interconnected LERs forms a private MPLS VPN where each LSP is uniquely identified at each MPLS interface by a label. Ethernet has become a predominant technology initially for Local Area Networks (LANs) and now as an access technology, specifically in metropolitan networks. Ethernet ports or IEEE VLANs are dedicated to customers on Provider Edge (PE) routers acting as LERs. Customer traffic gets mapped to a specific MPLS L2 VPN by configuring L2 FECs based upon the input port and/or VLAN. Broadcast and multicast services are available over traditional LANs. MPLS does not support such services currently. Sites that belong to the same broadcast domain and that are connected via an MPLS network expect broadcast, multicast and unicast traffic to be forwarded to the proper location(s). This requires MAC address learning/aging on a per LSP basis, packet replication across LSPs for multicast/broadcast traffic and for flooding of unknown unicast destination traffic. [1] defines how to carry L2 PDUs over point-to-point MPLS LSPs. This document describes extensions to [1] for transporting Ethernet/802.3 and VLAN [8] traffic across multiple sites that belong to the same L2 broadcast domain. Note that the same model can be applied to other 802.1 technologies. It describes a simple and scalable way to offer Virtual LAN services, including the appropriate flooding of Broadcast, Multicast and unknown unicast destination traffic over MPLS, without the need for address resolution servers or other external servers, as discussed in [10]. 2. Bridging Model for MPLS An MPLS interface acting as a bridge must be able to flood, forward, and filter bridged frames. Lasserre et al. [Page 4] Internet Draft draft-lasserre-tls-mpls-00.txt August 2001 +----+ +----+ + C1 +---+ +---| C1 | +----+ | .................................. | +----+ Site A | .+----+ +----+. | Site B +--.| PE |---- MPLS Cloud ----| PE |.--+ .+----+ | +----+. . | . . | . . +----+ . . | PE | . . +----+ . .................................. | ^ +----+ | | C1 | +-- Logical bridge +----+ Site C The set of PE devices interconnected via MPLS appears as a single 802.1d bridge/switch to customer C1. Each PE device will learn remote MAC addresses on LSPs (and keeps learning directly attached MAC addresses on customer facing ports). 2.1 Flooding and Forwarding Flooding is performed by sending unknown unicast and multicast frames to all possible appropriate destinations. In the MPLS environment this means sending the PDU through each relevant VC LSP. This is accomplished by explicitly copying it to each VC LSP that is part of the corresponding VPN. Note that multicast frames do not necessarily have to be sent to all VPN members. For simplicity, the default approach of broadcasting multicast frames can be used. Extensions explaining how to interact with 802.1 GMRP protocol, IGMP snooping and static MAC multicast filters will be discussed in a future revision. To forward a frame, a bridge must be able to associate a destination MAC address with a VC LSP. It is unreasonable and perhaps impossible to require bridges to statically configure an association of every possible destination MAC address with a VC LSP. Therefore, MPLS bridges must provide enough information to allow an MPLS interface to dynamically learn about foreign destinations beyond the set of LSRs. To accomplish dynamic learning, a bridged PDU MUST conform to the encapsulation described within [1]. Lasserre et al. [Page 5] Internet Draft draft-lasserre-tls-mpls-00.txt August 2001 2.2 Address Learning Unlike BGP VPNs [8], reachability information does not need to be advertised and distributed via a control plane. Reachability is obtained by standard learning bridge functions in the data plane. Since VC LSPs are uni-directional, two LSPs of opposite directions are required to form a logical bi-directional link. When a new MAC address is learned on an inbound LSP, it needs to be associated with the outbound LSP that is part of the same pair. The state of this logical link can be considered as up as soon as both incoming and outgoing LSPs are established. Similarly, it can be considered as down as soon as one of these two LSPs is torn down. 2.3 LSP Topology PE routers run either an IGP or an EGP between them. Tunnel LSPs between PE routers are therefore established along routed paths. Note that tunnel LSPs can also be explicitly routed. Such tunnels form a full mesh. Partial mesh of tunnel LSPs will be discussed in a future revision. VC LSPs are then mapped onto these tunnel LSPs. The resulting VC LSP mesh for the corresponding VPN instance has to be loop free. In a Ethernet based topology, since VC LSPs are not terminated at the CE boundary, unlike Frame Relay or ATM, it is the responsibility of the Service Providers to offer a loop free topology. With Frame Relay or ATM, it is the customers' responsibility to run STP or a routing protocol to prevent loops. With Ethernet as the access medium, a port and/or a VLAN is used per customer. Customer facing ports can be used to tunnel untagged or 802.1q tagged traffic. The VC LSPs connected to each site in the corresponding VPN are only visible to the PE device. 2.4 Loop free L2 VPN In order to avoid running a STP instance per VPN, which would not scale, partial mesh configurations of VC LSPs are not allowed. Note that customers are allowed to run STP such as when a customer has a back door link used for backup. In such a case STP BPDUs are simply tunneled through the MPLS cloud. Each PE MUST create a rooted tree to every other PE router that serve the same L2 VPN. Each PE MUST support a "split-horizon" scheme in order to prevent loops, that is, a PE MUST NOT forward traffic from one VC LSP to another in the same VPN (since each PE has direct connectivity to all other PEs in the same VPN). Lasserre et al. [Page 6] Internet Draft draft-lasserre-tls-mpls-00.txt August 2001 2.5 L2 VPN Provisioning Provisioning of a full mesh can be automatic with a discovery protocol where each PE advertizes which VPN(s) it serves to other PEs in the same domain, reducing the provisioning complexity to O(1) PE to configure when a new site is added, and O(n) new LSPs to be set up. The number of sites per VPN and the number of VPNs per PE router define the total number of VC LSPs to be managed. Let's consider for example that each VPN has an average of 4 sites and that 1000 customers are supported in a PE, 4000 VC LSPs need to be established and maintained. Since VC LSPs are set up via LDP, there is no need to refresh LSP states like in the RSVP case. Tunnel LSPs can be either be established via LDP or via RSVP. Since LDP is required for establishing VC LSPs, LDP is a logical choice to exchange VPN membership between PE routers. BGP offers the advantage of being able to set up inter-provider VPNs. However, BGP is typically not enabled on PE routers, but only on core routers. The signaling of VPN membership via BGP will be discussed in a future revision. A possible method for exchanging VPN membership via BGP can be based on [5]. 2.6 LDP Based Discovery Once an LDP adjacency has been formed between two PEs, all VC LSPs get established over this single TCP session. Directly connected PEs multicast LDP hellos periodically. Non- directly connected PEs exchanged unicast targeted hellos to each desired peer. Once a hello adjacency is formed, a LDP TCP connection is established. A LDP session is established over this connection by exchanging LDP initialization messages. IGP extensions to automatically discover VLS capable PEs can be used, such as defined in [4]. This will allow a TLS capable PE node to automatically setup a LDP adjacency to the discovered node and automate provisioning for VC LSPs. If LDP is used to create tunnel LSPs, then this will be automated once the newly discovered TLS PE node has an IP entry in the IGP (this assumes that a loopback address is used to represent the newly discovered TLS capable PE node). However if RSVP-TE is used for the tunnel LSP, then it is important that the two PE nodes have a tunnel LSP between them (the means of doing this is beyond the scope of this document). In [2], the L2 VPN information is carried in a Label Mapping message sent in downstream unsolicited mode. This document defines a new Lasserre et al. [Page 7] Internet Draft draft-lasserre-tls-mpls-00.txt August 2001 parameter id, a 7-byte VPN Id as defined in [9], to the interface parameters field in the VC FEC described in [2]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter ID | Length | Variable Length Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Value | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The parameter ID is defined as follows: Parameter ID Length Description 0x01 4 Interface MTU in octets. 0x02 4 Maximum Number of concatenated ATM cells. 0x03 up to 82 Optional Interface Description string. 0x04 4 CEM [8] Payload Bytes. 0x05 4 CEM options. 0x06 7 VPN Id. The first five parameters are as described in [2]. The VPN Id field is a unique 7-byte number that identifies a specific L2 VPN instance in a service provider network. All VLS capable PE nodes MUST use the same VPN ID for a given L2 VPN. PE nodes belonging to the same VLS must be capable of mapping Ethernet ports and/or VLANs to the corresponding VPN Id. 3. Security Considerations This document does not affect the underlying security issues of MPLS. Lasserre et al. [Page 8] Internet Draft draft-lasserre-tls-mpls-00.txt August 2001 4. References [1] "Encapsulation Methods for Transport of Layer 2 Frames Over MPLS", draft-martini-l2circuit-encap-mpls-02.txt (Work in progress) [2] "Transport of Layer 2 Frames Over MPLS", draft-martini- l2circuit-trans-mpls-06.txt (Work in progress) [3] "LAN Emulation over ATM version 1.0", af-lane-0021.0000 (ATM Forum) [4] "Distribution of 802.1Q VLAN information using Opaque LSA", draft-tsenevir-8021qospf-00.txt (Work in progress) [5] "Use of BGP-MP for Layer 2 VPN Membership discovery", draft- tsenevir-bgp-l2vpn-00.txt (Work in progress) [6] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC Bridges". [7] 802.1D - "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3: 1998. [8] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", July 1998. [9] Fox, Gleeson, "Virtual Private Networks Identifier", RFC2685 [10] "Requirements for Network Based Layer 2 VPN", draft-tsenevir- l2-req-00.txt (Work in progress) Lasserre et al. [Page 9] Internet Draft draft-lasserre-tls-mpls-00.txt August 2001 5. Author's Addresses Marc Lasserre Riverstone Networks 5200 Great America Pkwy Phone: 1-408-878-6550 Santa Clara, CA 95054 Email: marc@riverstonenet.com Nick Slabakov Riverstone Networks 5200 Great America Pkwy Phone: 1-303-471-6926 Santa Clara, CA 95054 Email: nslabakov@riverstonenet.com Rob Nath Riverstone Networks 5200 Great America Pkwy Phone: 1-408-878-6742 Santa Clara, CA 95054 Email: rnath@riverstonenet.com Loa Andersson Utfors Bredband AB Phone: +46 8 5270 50 38 Rasundavagen 12 169 29 Solna Email: loa.andersson@utfors.se Pascal Menezes TeraBeam Networks 2300 Seventh Ave Seattle, WA 98121 Email: Pascal.Menezes@Terabeam.com Andrew Smith Fax: +1 415 345 1827 Consultant Email: ah_smith@pacbell.net Tissa Senevirathne Force10 Networks 1440 McCarthy Blvd Phone: 408-865-5103 Milpitas, CA Email: tsenevir@hotmail.com Pierre Lin Yipes Communication 114 Sansome St Phone: 415-218-9520 San Francisco, CA 94104 Email: pierre.lin@yipes.com Lewis Eatherton Excite@Home 450 Broadway Street Phone: 650-556-5022 Redwood City, CA 94063 Email: leathert@excitehome.net Vasile Radoaca Nortel Networks 600 Technology Park Phone: 978-288-6097 Billerica MA 01821 Email: vasile@nortelnetworks.com Ivy Hsu Lasserre et al. [Page 10] Internet Draft draft-lasserre-tls-mpls-00.txt August 2001 Foundry Networks 2100 Gold Street PO Box 649100 Phone: 408-586-1795 San Jose, CA 95164 Email: ihsu@foundrynet.com Lasserre et al. [Page 11]