Provider-Provisioned VPN Working Group Giles Heron Internet Draft PacketExchange Ltd. Expiration Date: January 2002 Rick Wilder Masurgy Juha Heinanen Song Networks Tom Soon SBC Communications Luca Martini Level3 Communications Vach Kompella Joe Regan Sunil Khandekar TiMetra Networks July 2001 Requirements for Virtual Private Switched Networks draft-heron-ppvpn-vpsn-reqmts-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. Heron, et al. [Page 1] Internet Draft draft-heron-ppvpn-vpsn-reqmts-00.txt July 2001 Abstract This document defines requirements for provision of Virtual Private Switched Network services over tunneled packet switched networks. These requirements are common for both IP and MPLS networks. Table of Contents 1 Specification of Requirements ............................. 3 2 Placement of this Memo in Sub-IP Area ..................... 3 3 Introduction .............................................. 3 4 Virtual Private Switched Network .......................... 4 5 Attributes of VPSN ........................................ 5 5.1 Simplicity ................................................ 5 5.2 Ease of Provisioning ...................................... 5 5.3 Virtual Bridging .......................................... 5 5.4 Protocol Independence ..................................... 6 5.5 Routing Independence ...................................... 6 5.6 Sub-Rate Services ......................................... 6 5.7 Quality of Service ........................................ 6 5.8 Scaling ................................................... 7 6 VPSN Requirements ......................................... 7 6.1 Network Infrastructure .................................... 7 6.2 Network Transport ......................................... 8 6.3 Frame Size ................................................ 8 6.4 Data Delivery ............................................. 8 6.5 Traffic Separation ........................................ 9 6.6 Membership Integrity ...................................... 9 6.7 Protocol Independence ..................................... 9 6.8 VPSN Instance ............................................. 10 6.9 Duplicate MAC Addresses ................................... 10 6.10 MAC Address Limiting ...................................... 10 6.11 Any to Any Connectivity ................................... 10 6.12 Provisioning .............................................. 11 6.13 Network Management ........................................ 11 7 Security Considerations ................................... 11 8 Intellectual Property Disclaimer .......................... 12 9 References ................................................ 12 10 Author Information ........................................ 12 Heron, et al. [Page 2] Internet Draft draft-heron-ppvpn-vpsn-reqmts-00.txt July 2001 1. 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 2. Placement of this Memo in Sub-IP Area RELATED DOCUMENTS draft-vkompella-ppvpn-vpsn-mpls-00.txt WHERE DOES THIS FIT IN THE PICTURE OF THE SUB-IP WORK This fits in the PPVPN box. WHY IS IT TARGETED AT THIS WG Because it specifies requirements for layer 2 VPNs which emulate a LAN segment (or "Virtual Private Switched Networks") JUSTIFICATION We believe the WG should consider this draft because it specifies requirements for a class of layer 2 VPN that has up to now not been sufficiently addressed in this WG. 3. Introduction This document describes service provider requirements for providing Virtual Private Switched Networks over an IP or MPLS based network infrastructure. A Virtual Private Switched Network (or VPSN) is a class of VPN that allows the connection of multiple sites in a sin- gled bridged domain over a provider managed IP or MPLS network. All customer sites in the VPSN appear to be on the same LAN regardless of their location. VPSN services (often known in this context as "Transparent LAN" ser- vices, or TLS) have traditionally been offered by service providers over an ATM infrastructure. The TLS service is provisioned using mesh of ATM PVCs between locations. Some customers prefer TLSs to point-to-point Frame Relay circuits since a TLS hides the complexity of designing and managing multiple Frame Relay circuits. While this reduces the complexity for the customer, the service provider must deal with managing and operating the ATM network in addition to edge Ethernet switches. This model does not scale well and is expensive Heron, et al. [Page 3] Internet Draft draft-heron-ppvpn-vpsn-reqmts-00.txt July 2001 to maintain and manage for the service provider. It should be noted that while VPSNs provide certain advantages to both customers and service providers, they have properties that do not scale over large numbers of sites or where there are large num- bers of hosts in the VPSN. In addition the single metric that a routing protocol will assign to a layer 2 subnet emulated using VPSN makes this model unsuitable if the costs of connectivity between dif- ferent sites in the VPSN differ. The most likely application of this model is to connect a few, or a few tens of, sites over a metropoli- tan or regional reach and with only a single customer router (or a few customer hosts) connected to the VPSN at each site. The customer and provider should choose judiciously whether to imple- ment VPSN or some other network connectivity model. VPSN can be contrasted with two other service models. One is the Virtual Private Routed Network (VPRN) [1], in which the service provider participates in the customer's routing protocol. This involves minimal change to configuration on the customer edge (CE) router, but adds complexity in the provider edge (PE) router. The second model is a set of point-to-point circuits (L2VPN) [2], which involves configuration on the CE router, but simplifies the PE router operation. VPSN, on the other hand, requires very little CE or PE router configuration. The scope of this document will be limited to supporting Ethernet as the access framing technology for VPSN implementation. This document discusses the motivation and requirements of network- based, provider provisioned VPSN over a native IP or MPLS network. A proposal for the implementation of VPSN over MPLS is given in [3]. 4. Virtual Private Switched Network We define a Virtual Private Switched Network or VPSN as a service where the service provider provides an emulated layer-2 bridged net- work that connects multiple customer sites over an IP or MPLS network infrastructure. To the customer, this appears as a single VLAN or a layer-2 switched LAN segment where a single connection into the LAN (VPSN) offers any- to-any connectivity between all sites. All traffic is switched based on MAC addresses but forwarded between all participating PE devices using IP or MPLS tunnels. Tunneling traffic, using either IP or MPLS, allows the service provider to use a single network for multiple ser- vices without requiring any overlay networks. Heron, et al. [Page 4] Internet Draft draft-heron-ppvpn-vpsn-reqmts-00.txt July 2001 5. Attributes of VPSN 5.1. Simplicity With VPSN, the CE has a single logical attachment to the PE. A mesh of point-to-point tunnels is built between the participating PE devices to carry multiple services. This offers any-to-any connec- tivity without requiring the customer to manage connectivity to every site. For the customer, this simplifies manageability by reducing the operational complexity of managing circuits to every site. Each CE device requires minimal to no configuration since this is analogous to connecting a device into a VLAN. If the CE device is a router, it only needs to be configured with a network address and mask for the VPSN subnet and the customer specific routing protocol. For smaller locations, customers can simply connect a layer-2 device into the VPSN. This eliminates the need for trained internetworking personnel at each site. 5.2. Ease of Provisioning Participating PE devices must be configured with knowledge of all other endpoints (PEs) for the service. When a new customer site is commissioned on the VPSN, the existing PE devices are told about the PE where the new site is connected. The service provider is not required to over-provision each PE in anticipation of new customer sites being added later. Note that it is also possible for participating PE devices to auto- matically discover all other PE devices for a service. This is con- sidered to be preferable to configuring each PE with knowledge of the other PEs, since it makes it easier to add new sites to a VPSN and also removes the risk of a VPSN being configured as a partial rather than as a full mesh of PEs. 5.3. Virtual Bridging The service provider is responsible for providing a true layer-2 switched service between customer sites. The customer specific VPSN instance, in the PE, acts as a virtual bridge and performs normal bridging functions. Heron, et al. [Page 5] Internet Draft draft-heron-ppvpn-vpsn-reqmts-00.txt July 2001 5.4. Protocol Independence The customer is free to run any Ethernet encapsulated layer-3 proto- col between multiple sites since the traffic is switched based on layer-2 MAC addresses. IP or MPLS based transport tunnels are used to carry traffic for multiple VPSNs between common PEs. 5.5. Routing Independence As in case of L2VPN [2], the service provider does not participate in any customer routing. The customer is free to run any routing proto- col. There is no interaction between the service provider and cus- tomer routing protocols. Since the VPSN depends on the service provider routing protocol to provide a resilient network service it will generally be the case that this protocol will be tuned for faster reconvergence than the customer routing protocols that are likely to run over the service. Note that instability may occur if the customer routing protocol detects a failure and starts to reroute traffic before the service provider routing protocol has been able to do so. 5.6. Sub-Rate Services Since Ethernet is the service interface, the access speeds available for the VPSN can match the standard Ethernet LAN speeds. At the same time, sub-rate access speeds can be offered in granular increments by leveraging the traffic management capabilities of the PE equipment. This enables service providers to customize access rates that best suit each customer. 5.7. Quality of Service MPLS-TE tunnels that offer specific quality of service can be set up between PE devices. Customer Ethernet packets marked with IEEE 802.1p [4] bits can be mapped to tunnels that offer differentiated quality of service. In addition the IEEE 802.1p bits may be mapped to MPLS EXP bits or IP DSCPs. Heron, et al. [Page 6] Internet Draft draft-heron-ppvpn-vpsn-reqmts-00.txt July 2001 5.8. Scaling Each customer VPSN instance on the PE router is required to maintain a Forwarding Information Base (FIB) of the MAC addresses that are part of the customer VPSN. This raises the question of scalability on the part of the PE routers that support the VPSN implementation. Each PE router must deal with maintaining a MAC address FIB per VPSN instance. No interaction is required with the routing protocol on the PE router. The solution must scale to large numbers of VPSN instances per PE router. Unlike a VPRN implementation, where the virtual router instance must deal with all the network routes behind CE devices at each site, the VPSN implementation requires the PE router to have knowledge of only the MAC addresses of a single broadcast domain. However, it is not practical to scale a VPSN implementation over a large number of hosts in the emulated network. This is because each PE router has to have knowledge of all MAC addresses in the emulated network. In addition it is not practical to scale VPSN implementation over a large number of sites. This will invariably lead to scaling issues associated with flooding, replication, aging and learning. It is likely that the most common implementation of VPSN will have a customer-managed router connected into the VPSN at each site. Thus, the MAC addresses are limited to the number of sites connected to the VPSN. 6. VPSN Requirements A network based, provider provisioned VPSN service MUST support the following features. 6.1. Network Infrastructure The VPSN service MUST be provided transparently over a shared IP or MPLS based network infrastructure. The network core MUST NOT require any knowledge of layer-3 protocols addressing to support VPSN ser- vice. It MUST NOT be necessary to introduce any spanning tree state into the service provider network to support the VPSN service. Resiliency and fail-over capabilities for the VPSN MAY be offered using IP or MPLS techniques only. This does not preclude running a spanning tree protocol (STP) on the customer-facing network. Heron, et al. [Page 7] Internet Draft draft-heron-ppvpn-vpsn-reqmts-00.txt July 2001 The network core MUST provide any-to-any connectivity between the PE devices. The service provider SHOULD be able to offer different levels of ser- vice to its customers by building service specific tunnels or tunnels based on differing quality of service. 6.2. Network Transport Customer packets belonging to different VPSN services may be carried over an IP network or an MPLS network using L2TP, GRE or MPLS tunnel- ing techniques. The tunneling techniques used SHOULD be those defined in the PWE3 Working Group. Broadcast, multicast and unknown frames MUST either be replicated by the ingress PE router or by the use of pre-configured multicast tunnels. In the former case performance will be severely limited by the requirement to replicate packets at the ingress, and hence this architecture SHOULD not be used to support broadcast or multicast services. 6.3. Frame Size The service SHOULD support the standard Ethernet frame size of between 64 and 1518 octets, as defined in [5]. In addition the service MAY offer support for larger frame sizes ("jumbo frames"). Any frame smaller than 64 octets or larger than the supported maximum frame size MUST be discarded at the ingress PE. 6.4. Data Delivery Valid frames offered to the service MUST be delivered in order and without duplication. Frames MAY be discarded under network failure or under very high network load. Note that the responsibility for delivering frames in order and without duplication SHOULD be dele- gated to the underlying network. Invalid frames (i.e. invalid frames as defined in [5], and short or long frames as defined above) MUST be discarded at the ingress PE. Frames MUST NOT be corrupted in transit. The Ethernet FCS MAY be Heron, et al. [Page 8] Internet Draft draft-heron-ppvpn-vpsn-reqmts-00.txt July 2001 carried across the network and optionally verified before the frame is forwarded by the egress PE. Alternatively the FCS MAY be stripped at the ingress PE and regenerated by the egress PE, in which case all links in the underlying network MUST utilise a 32 bit or better FCS. 6.5. Traffic Separation Complete separation MUST be maintained between multiple VPSN instances. Traffic separation between different VPSN instances MUST be provided using IEEE 802.1Q tags [4] on the customer facing ports or by assigning a different Ethernet port for each VPSN instance. Traffic separation in the core MUST be provided by using an appropri- ate encapsulation (for example that defined in [6]) in the provider network. In addition multiple VLANs MAY be provisioned over a single VPSN instance. In this case traffic separation between the different VLANs MUST be provided using IEEE 802.1Q tags [4] in the customer facing ports and in the provider network. Traffic separation between this and other VPSN instances MUST be provided by assigning a dedi- cated Ethernet port for this instance and by using an appropriate encapsulation (for example that defined in [6]) in the provider net- work. 6.6. Membership Integrity The signalling used to establish membership of the VPSN MUST be secured to prevent any unauthorised participation in a VPSN. The underlying tunneling protocol used to transport frames from one PE to another MUST be secured to prevent injection of unauthorised traffic into the VPSN. 6.7. Protocol Independence The VPSN service MUST be able to support any Ethernet encapsulated layer-3 protocol, and MUST NOT rely on protocol specific features to enhance support for particular layer-3 protocols. Heron, et al. [Page 9] Internet Draft draft-heron-ppvpn-vpsn-reqmts-00.txt July 2001 6.8. VPSN Instance A VPSN instance per emulated network per PE MUST be supported. Each VPSN instance MUST be capable of supporting normal LAN bridging functions such as MAC learning and aging at the PE on customer and provider facing ports (learning tunnels) and replication of frames with broadcast, multicast and unknown MACs. If multiple VLANs are being supported over a single VPSN, as described above, the VPSN instance MUST associate learned MAC addresses with the correct VLAN. In addition, some form of loop detection SHOULD be provided at the PE. Loop prevention MAY be provided at the PE. 6.9. Duplicate MAC Addresses The PE router MUST be able to support duplicate MAC addresses that are part of separate VPSN instances. If multiple VLANs are being supported over a single VPSN, as described above, the PE router MUST be able to support duplicate MAC addresses that are part of the same VPSN instance but which are asso- ciated with different VLANs. 6.10. MAC Address Limiting The PE SHOULD be able to limit the number of MAC addresses per VPSN instance. This will limit the amount of memory consumed by the VPSN FIB. 6.11. Any to Any Connectivity A single physical or logical (802.1Q VLAN) customer connection from each site MUST be sufficient to provide any-to-any connectivity just like a LAN. Heron, et al. [Page 10] Internet Draft draft-heron-ppvpn-vpsn-reqmts-00.txt July 2001 6.12. Provisioning VPSN MUST require minimal or no configuration on the CE device, depending on the CE device that connects into the VPSN. In addition, service providers MUST be able to offer VPSN service without requir- ing substantial configuration at each participating PE. When addi- tional sites are provisioned, minimal configuration MAY be required on the existing PEs that have CE devices connected in the same VPSN. 6.13. Network Management Management of the underlying tunnels SHOULD be delegated to the man- agement function of the underlying packet switched network, and man- agement of the Ethernet layer SHOULD be delegated to the customer's network management function. Each VPSN instance MUST maintain appropriate state information of other VPSN instances in the VPSN. This state information MUST include, but is not limited to, physical interface state and reacha- bility from the local VPSN instance. While further OAM functional- ity, such as the ability to trigger remote network loopbacks or to verify that frames are successfully delivered to the intended remote VPSN instance, is desirable it is to be considered out of scope for this effort. Other groups are defining such functionality, for exam- ple the LSP-ping effort [7] and the MPLS OAM effort [8], and it may be possible to leverage this work in VPSN implementations. Each VPSN instance MUST maintain counts of the number of frames transmitted to and received from each remote PE, as well as counts of the number of frames replicated to all available remote PEs for each of the three categories: broadcast, multicast and unknown. 7. Security Considerations The traffic separation and membership integrity requirements described above MUST be adhered to in order for the solution to be considered minimally secure. It is recommended that any security measures over and above this level (for example data authentication or encryption) be applied by the VPSN customer on an edge-to-edge (i.e. CE router to CE router) or an end-to-end (i.e. application to application) basis. Heron, et al. [Page 11] Internet Draft draft-heron-ppvpn-vpsn-reqmts-00.txt July 2001 8. Intellectual Property Disclaimer This document is being submitted for use in IETF standards discus- sions. 9. References [1] "A Framework for IP Based Virtual Private Networks", B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis. RFC 2764. February 2000. [2] "MPLS-Based Layer 2 VPNs", K. Kompella, M. Leelanivas, Q. Vohra, R. Bonica, E. Metz. draft-kompella-mpls-l2vpn-02.txt. Work in progress. [3] "Virtual Private Switched Network Services over an MPLS Network", V. Kompella et al. draft-vkompella-ppvpn-vpsn-mpls-00.txt. Work in progress. [4] IEEE STD 802.1Q-1998. December 1998. [5] IEEE STD 802.3-2000. October 2000. [6] "Encapsulation Methods for Transport of Layer 2 Frames Over MPLS", L. Martini et. al. draft-martini-l2circuit-encap-mpls-02.txt. Work in progress. [7] "Detecting Data Plane Liveliness in RSVP-TE", P. Pan, N. Sheth, D. Cooper. draft-pan-lsp-ping-00.txt. Work in progress. [8] "OAM Functionality for MPLS Networks", N. Harrison et al. draft-harrison-mpls-oam-00.txt. Work in progress. 10. Author Information Giles Heron PacketExchange Ltd. The Truman Brewery 91 Brick Lane LONDON E1 6QL United Kingdom Tel.: +44 7880 506185 Email: giles@packetexchange.net Heron, et al. [Page 12] Internet Draft draft-heron-ppvpn-vpsn-reqmts-00.txt July 2001 Rick Wilder Masergy Inc. 2901 Telestar Ct. Falls Church, VA 22042 Juha Heinanen Song Networks, Inc. Tom S. C. Soon SBC Technology Resources Inc. 4698 Willow Road Pleasanton, CA 94588 Tel.: +1 (925) 598-1227 Email: sxsoon@tri.sbc.com Luca Martini Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO, 80021 Email: luca@level3.net Vach Kompella TiMetra Networks 274 Ferguson Dr. Mountain View, CA 94043 Tel.: +1 (650) 237-5152 Email: vkompella@timetra.com Joe Regan TiMetra Networks 274 Ferguson Dr. Mountain View, CA 94043 Tel.: +1 (650) 237-5103 Email: jregan@timetra.com Sunil Khandekar TiMetra Networks 274 Ferguson Dr. Mountain View, CA 94043 Tel.: +1 (650) 237-5105 Email: sunil@timetra.com Heron, et al. [Page 13]