Internet Engineering Task Force J. Sumimoto INTERNET-DRAFT M. Suzuki NTT Expires February 28, 2002 M. Carugi France Telecom C. Y. Lee Paragon Networks August 31, 2001 Guidelines of Applicability Statements for PPVPNs 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 This document provides guidelines of applicability statements for Provider Provisioned Virtual Private Networks (PPVPNs). The document is intended as guidelines to assist the development of applicability statements for each specific PPVPN solution. 1 Summary for Sub-IP Area 1.1 Summary Sumimoto Expires February 2002 [Page 1] INTERNET-DRAFT August 31, 2001 This document provides guidelines of applicability statements for Provider Provisioned Virtual Private Networks (PPVPNs). The document is intended as guidelines to assist the development of applicability statements for each specific PPVPN approach. 1.2 Where does it fit in the Picture of the Sub-IP Work This document fits in ppvpn WG. 1.3 Why is it Targeted at this WG As this document describes the contents for the following work item from the ppvpn WG charter: "An applicability statement will be developed for each approach that describes the environments in which the approaches are suitable for deployment, including analysis of scaling impact of the approach on SPs and threat analysis. " This document is intended as guidelines to assist the development of applicability statement documents for each specific PPVPN approach. (*)We do not need justification as this document directly fits in ppvpn WG. 2. Introduction (*** Objective and Scope ***) *** What is this document? *** This document is intended as guidelines to assist the development of applicability statement documents for each specific PPVPN solution. Towards this end, it provides a high level discussion of the applicability and limitations of PPVPNs and identifies a list of PPVPN requirements. Individual Applicability Statements may associate the applicability and limitations of the specific solution with this list of requirements. In this respect, this document may also help providers and users to define the applicability scenarios of each PPVPN solution and to position it against a set of requirements. *** Terminology (PPVPN, L3/L2 VPNs, technical approaches)*** The term "PPVPNs" refers to Virtual Private Networks (VPNs) for which the service provider participates in management and provisioning of the VPN, and there are multiple different types of PPVPNs. From the customer's layer viewpoint, PPVPNs are classified into two categories, layer 3 VPNs and layer 2 VPNs. Multiple technical approaches are possible in both categories (e.g. BGP VPNs as defined in [2547bis], VR VPNs as defined in [VPN-VR] or [2917bis] are Sumimoto Expires February 2002 [Page 2] INTERNET-DRAFT August 31, 2001 approaches included in layer 3 VPNs). This document provides a description of these individual approaches in Section 3. For more detail on definitions of all technical terms mentioned in this paragraph, see [VPN-FR]. *** Scope and organization of this draft, and scope expected in each individual AS draft *** Section 3 provides technical overview of each PPVPN approach to facilitate understanding of applicability and limitations content. Section 4 outlines requirements for PPVPNs as a basic list for discussing applicability and limitations. The same list may be used for individual AS documents to be developed in future. Section 5 presents applicability of PPVPNs and Section 6 presents limitations of PPVPNs. Section 7 is for security considerations, section 8 for references. This document focuses on discussion common to all approaches, however, it may play an introductory role toward individual AS documents to be developed in future. Detailed applicability and limitations sections are expected to be developed in these individual AS documents. 3. PPVPN technical overview *** Brief overview of PPVPN types *** This section provides a brief overview on the various types of PPVPNs as an introductory guidance toward discussions in the rest of this document and in developing individual AS documents. Individual solution-specific AS documents are expected to include more detailed technical overview of the respective solution. Note: As some of the engineering tradeoffs between different types of PPVPNs, this document will discuss them in a further version. First of all, PPVPNs may be distinguished by the service layer offered. - Layer 3 VPNs In a layer 3 VPN service, a customer site receives IP layer (i.e., layer 3) service from the SP. The CE and PE are adjacent to each other at the data link layer and the IP layer across the access network. The PE performs forwarding of user data packets based on information in the IP layer header, such as an IPv4 or IPv6 destination address. The CE sees the PE as a layer 3 device such as an IPv4 or IPv6 router. - Layer 2 VPNs Sumimoto Expires February 2002 [Page 3] INTERNET-DRAFT August 31, 2001 In a layer 2 VPN service, a CE receives data link layer (i.e., layer 2) service from the SP. The CE and PE are adjacent to each other at the data link layer and not at the IP layer across the access network. A PE performs forwarding of user data packets based on information in the packets' data link layer headers, such as a frame relay DLCI or 802.1q VLAN tag. That is, the CE sees the PE as a layer 2 device such as a FR switch or an Ethernet VLAN switch. Both layer 3 VPNs and layer 2 VPNs include various technical approaches. Specific approaches of layer 3 VPNs include BGP-VPNs as defined in [2547bis], virtual routers (VRs) as defined in [VPN-VR] or [2917bis]. Specific approaches of layer 2 VPNs include port-based VPNs (i.e., where the SP provides a Layer 2 interface, such as Frame Relay or ATM, to the VPN customer, while using IP-based mechanisms in the provider infrastructure to improve scalability and configurability over traditional L2 networks). All types of PPVPNs adopt some tunneling mechanisms in SP networks based on IP protocol, and service providers participate in management and provisioning of the PPVPNs. This is part of the requirements mentioned in following section. 4. Outline of requirements for PPVPNs *** Why and how does this document outline requirements? *** This section briefly outlines main requirements for PPVPNs provided in [VPN-REQ] as a basic list for discussing applicability and limitations in following sections. Detailed requirements are out of the scope of this document, detailed requirements are fully presented in [VPN-REQ]. This section classifies the requirements into 3 categories, general requirements (for both layer 3 and layer 2 VPNs), requirements specifically for layer 3 VPNs, and requirements specifically for layer 2 VPNs. Above distinction is just a suggestion to be discussed. Concept we want to raise here is that we should classify requirements according to the most appropriate way to develop individual AS documents. Apart from customer/service provider requirement distinction, a more extended classification could be : - general requirements, - service-specific requirements(L3 NB, L3 CE-based, L2 NB point-to-point, L2 NB transparent LAN service, etc.), basically following current framework/req ID taxonomy - solution-specific requirements, or approach-specific requirements (we may have in theory more than one solution per each approach) *** Concrete list of the requirements: 4.1 - 4.3 *** Sumimoto Expires February 2002 [Page 4] INTERNET-DRAFT August 31, 2001 4.1 General requirements - Security (including threat analysis as mentioned in charter) Each PPVPN solution should support a range of security related features. Lower levels of security service, like traffic isolation, and higher levels of security services, like edge-to- edge encryption, authentication, or replay attack prevention should be supported. Furthermore, firewall functionality may be desired when Internet access is provided. - QoS and SLA support With regards to QoS support, a PPVPN shall be able to support QoS in one or more of the following standard modes: - Best Effort (support mandatory for all PPVPN types) - Aggregate CE Interface Level QoS (i.e., hose level) - Site-to-site, or _pipe_ model QoS - Intserv (i.e., RSVP) signaled - Diffserv marked - Across packet-switched access networks - Manageability (including ease of monitoring/accounting) An SP and its customers must be able to manage the capabilities and characteristics of their VPN services. To the greatest possible extent, automated operations and interoperability with standard management platforms should be supported. - Interoperability Each technical solution should support the Internet standards (in terms of compatibility and modularity). Multi-vendor interoperability at network element, network and service levels among different implementations of the same technical solution should be guaranteed (that will likely rely on the completeness of the corresponding standard). This is a central requirement for SPs and customers. The technical solution must be multi-vendor interoperable not only within the SP network infrastructure, but also with the customer's network equipment and services making usage of the PPVPN service. (To be completed.) - Scalability (convergence time, routing tables, VPN size, routing instances, etc) Routing updates in VPNs shall not affect the stability of the SP network. Relation with parameters provided in 5.1.1 [PPVPN-REQ] Sumimoto Expires February 2002 [Page 5] INTERNET-DRAFT August 31, 2001 should be provided. (see 5.1.2 [PPVPN-REQ] for solution-specific metrics) - Migration impact (To be filled out.) - Learning VPN Related Information (*** Needed? ***) - Reliability (Including Protection/Restoration) (To be filled out.) - Network environment Functions required to PEs: Some PPVPN types or approaches require special functions to PEs. The less such special functions are, the easier to deploy. (To be completed.) - Support of various service scenarios (inter-AS, wholesale, Internet access, extranet, etc.) (To be filled out.) - Support of various connectivity scenarios (access network connectivity, etc.) (To be filled out.) - Topology A PPVPN should support arbitrary, customer agent defined inter-site connectivity, ranging, for example, from hub-and-spoke, partial mesh to full mesh topology. - Operation/Deployment considerations(Includes adding/moving sites) Ease of Operation/Deployment is highly desired. Special skill for operation/deployment may be an obstacle. (To be completed.) - Reliability (Includes Protection/Restoration) (To be filled out.) - Routing protocol and policy routing support Sumimoto Expires February 2002 [Page 6] INTERNET-DRAFT August 31, 2001 There should be no restriction on the routing protocols used between CE and PE routers, or between CE routers. At least the following protocols must be supported: static routing, IGP, such as RIP, OSPF, IS-IS, or BGP. (To be completed.) - Cost considerations (To be filled out.) 4.2 Requirements specifically for Layer 3 VPNs - Addressing The following support from PPVPN solutions are required: o globally unique/private IP addresses, IPv4/IPv6, for both unicast and multicast o obtained by the customer from IANA / statically assigned by the PPVPN service provider o on-demand, dynamically assigned IP addresses (e.g., DHCP), irrespective of whether the access is temporary (e.g., remote) or permanent (i.e., dedicated) Customer VPN address overlapping shall be supported - IP addresses have to be unique only within a given VPN, but not across VPNs. In the case where private IP addresses are used, a PPVPN solution must provide a means for an SP to translate such addresses to public IP addresses for communication with other VPNs using overlapping addresses, or the Internet. - Interworking with other solutions Service interworking among different solutions providing PPVPN services is highly desirable and should be supported in an as much as possible scalable manner. - Provisioning Value-Added Service Access (To be filled out.) 4.3 Requirements specifically for Layer 2 VPNs (Requirements from the following references are to be outlined here; draft-rosen-ppvpn-l2vpn-00.txt, draft-tsenevir-l2-req-01.txt, draft-ouldbrahim-ethernet-l2vpn-requirements-00.txt, draft-heron-ppvpn-vpsn-reqmts-00.txt draft-kb-ppvpn-l2vpn-motiv-00.txt.) Sumimoto Expires February 2002 [Page 7] INTERNET-DRAFT August 31, 2001 5. Applicability *** Applicability description of identified solutions *** - Security All of PPVPN approaches (BGP-VPNs, VR, port-based VPNs) achieve logical traffic isolation by adopting VPN tunnels operated by service providers. If IPsec (or other encryption mechnism) is used as tunneling mechanism or used over VPN tunnels, confidentiality, integrity, authentication, and replay attack prevention can be achieved. (To be completed.) - QoS support/SLA support (To be written.) - Manageability Defining MIBs for BGP-VPNs approach are on progress. VR approach- specific MIBs are on progress. MIBs for the port-based VPN approaches are not currently defined (some work in pwe3 WG may be used for that). Detailed descriptions are expected to be included in each AS document per technical solution. - Interoperability (To be filled out.) - Migration impact (To be filled out.) - Scalability (To be filled out.) - Learning VPN Related Information (*** Needed? ***) - Reliability (To be filled out.) - Network environment (To be filled out.) Sumimoto Expires February 2002 [Page 8] INTERNET-DRAFT August 31, 2001 - Support of various service scenarios (inter-AS, wholesale, Internet access, extranet, etc.) (To be filled out.) - Support of various connectivity scenarios (access network connectivity, etc.) (To be filled out.) - Topology As applicability of topology depends on each technical solution, each AS document for specific technical solution is expected to describe this issue for the solution. - Operation/Deployment considerations (Includes adding/moving sites) (To be filled out.) - Routing protocol and policy routing support (To be filled out.) - Cost considerations (To be filled out.) - Addressing (To be filled out.) - Interworking with other solutions (To be filled out.) - Provisioning Value-Added Service Access (To be filled out.) 6. Limitations *** Description of general limitations of identified solutions *** - Scalability (To be filled out.) Sumimoto Expires February 2002 [Page 9] INTERNET-DRAFT August 31, 2001 - Addressing In case that a site belongs to multiple PPVPNs, they cannot have duplicated IP adresses. (To be completed.) - Interoperability (To be filled out.) (*)Other items have to be added. 7. Security considerations (To be written.) 8. References [PPVPN-FR] Callon, R. et al., "A Framework for Provider Provisioned Virtual Private Networks," work in progress. [PPVPN-REQ] Carugi, M. et al., "Service Requirements for Provider Provisioned Virtual Private Networks," work in progress. [2547bis] Rosen E. et al., "BGP/MPLS VPNs," work in progress. [VPN-VR] Ould-Brahim, H. et al., "Network based IP VPN Architecture using Virtual Routers, " work in progress. [2917bis] Muthukrishnan, K. et al., "A Core MPLS IP VPN Architecture, " work in progress. (*) Additional references to be provided here. 9. Authors' address Junichi Sumimoto NTT Information Sharing Platform Labs. 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Email: sumimoto.junichi@lab.ntt.co.jp Muneyoshi Suzuki NTT Information Sharing Platform Labs. 3-9-11, Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: suzuki.muneyoshi@lab.ntt.co.jp Sumimoto Expires February 2002 [Page 10] INTERNET-DRAFT August 31, 2001 Marco Carugi France Telecom Research and Development Technopole Anticipa -- 2, av. Pierre Marzin 22307 Lannion cedex, France Phone : + 33 2 96 05 36 17 Email : marco.carugi@francetelecom.com Cheng-Yin Lee Paragon Networks leecy@paragon-networks.com Sumimoto Expires February 2002 [Page 11]