Project Report. IP Virtual Private Networks. Guidelines on IPVPN deployment: models, architectures and technologies.

Transcription

1 Project Report IP Virtual Private Networks Guidelines on IPVPN deployment: models, architectures and technologies Editor: Gizella Kovacs, MATÁV Hungarian Telecommunications Company Ltd. (HT) Suggested readers Product managers, network designers, staff involved in deployment, operation and management of IPVPNs, equipment vendors. Abstract This report provides an overall picture of IP-based VPNs: the main requirements are identified; the most important architectures and technologies are described and compared; main deployment issues are analysed. Both IPsec and MPLS technologies are studied as the two main enabling technologies for IPVPN implementation. Issues related to quality of service and VPN management are given a special focus. The document closes with an overview of the IPVPN features implemented by commercial products, based on a survey carried out by P1107. EDIN Project P1107 For full publication April 2002

2 EURESCOM PARTICIPANTS in Project P1107 are: France Télécom (FT) Elisa Communications Corporation (AF) Deutsche Telekom AG (DT) Hellenic Telecommunications Organization S:A. OTE (OG) Portugal Telecom S.A. (PT) MATÁV Hungarian Telecommunications Company Ltd. (HT) EURESCOM P1107 IP Virtual Networks Deliverable 1, Guidelines on IPVPN deployment: models, architectures and technologies Editor: Gizella Kovacs, Matav Project leader: Jorge Carapinha, Portugal Telecom Project supervisor: Valérie Blavette, EURESCOM GmbH EURESCOM published project result; EDIN EURESCOM Participants in Project P1107 Disclaimer This document contains material which is the copyright of certain EURESCOM PARTICIPANTS, and may not be reproduced or copied without permission. All PARTICIPANTS have agreed to full publication of this document. The commercial use of any information contained in this document may require a license from the proprietor of that information. Neither the PARTICIPANTS nor EURESCOM warrant that the information contained in the report is capable of use, or that use of the information is free from risk, and accept no liability for loss or damage suffered by any person using this information..

3 EURESCOM Project Report page 3 (70) Preface The IP-based VPN (IPVPN) has emerged as one of most promising services for network providers. However, until now, the IPVPN concept has been mainly shaped by vendors. The widespread deployment of IPVPNs has been delayed by the lack of interoperable implementations and confusion over the high number of solutions that are described by the term IPVPN. Indeed several challenges like security, quality of service or scalability are associated with the implementation of VPNs over IP-based networks. A wide variety of models and network solutions have been proposed by the networking and telecommunications industries to deal with these requirements. It is crucial to get a global picture and understand the strengths and shortcomings of all the available tools and network solutions and related interoperability problems. Therefore, the approach followed by the EURESCOM P1107 project is as wide-ranging as possible, without any bias towards a specific technology or architecture. The network operators, through EURESCOM, should play an active role in this area, in order to promote interoperable and flexible IPVPN implementations, and take advantage of new opportunities provided by recent advances in this field, like for instance MPLS. This document is the first project report from the project. It is completed by a second Project Report dealing with IP-VPN security, and different Technical Information documents dealing with specific aspects of IP-VPN technologies such as the QoS issues of IPVPN provisioning and SLA management, the encryption of IP Multicast streams (comparison of the IETF MSEC and EURESCOM IP-VPN demonstrator) as well as a glossary. This project had 6 participating companies and a budget of 85 men months EURESCOM Participants in Project P1107 EDIN

4 page 4 (70) EURESCOM Project Report Executive Summary Why you should read this project report IPVPNs have emerged as one of the fastest growing segments in the field of corporate communication services. According to most predictions, this growth will continue and even accelerate in the coming years as a result of new market conditions (globalisation, increased competition) and technological innovation (new security technologies, MPLS, enhanced QoS techniques). Several IPVPN implementations are already available from the industry and a growing number of service providers have launched IPVPN services, both in Europe and in North America. In spite of this success, the deployment of interoperable IPVPN implementations has been limited by the wide variety of technical solutions, often not compatible, pushed mainly by vendors. This report puts the main IPVPN models and technologies into perspective and provides useful information for managers (who need to understand the IPVPN concept and the main technical foundations) and technical staff (who need to obtain the technical skills). The benefits for your company The successful introduction of IPVPNs requires the understanding by operators, service providers and customers, of the main strengths and shortcomings of the IPVPN technology. While it is true that there is a vast amount of literature in the field of IPVPNs, most papers and books on the subject are usually oriented to a specific technical approach, ignoring alternatives and missing the global picture of the available technical solutions. One of the main objectives of this report is to provide an integrated and unbiased view of IPVPNs including the full range of available technical solutions. For operators and service providers, the investment in IPVPN technology requires a proper understanding of the technology strengths and limitations, as well as the variety of technical options available in the market. In addition, customers must not overlook the opportunities for enhanced corporate communication services. The information contained in this document should be useful for product managers, network designers and staff involved in deployment, operation and management of IPVPNs. Aspects addressed by this project report Two unique and complementary IPVPN technologies are IPsec and MPLS. This report puts both technologies in perspective and evaluates their applicability to implement the IPVPN concept. The following aspects are addressed: ΠIPVPN requirements ΠDescription and evaluation of the basic IPVPN models (CPE-based and Network-based), as well as the most relevant implementation variants of each model. ΠIPVPN QoS issues ΠIPVPN management issues ΠConclusions recommendations and guidelines. Conclusions In summary, this deliverable provides a succinct description of the main issues and challenges related to the provisioning of IPVPNs using a variety of available methods and technologies. EDIN EURESCOM Participants in Project P1107

5 EURESCOM Project Report page 5 (70) List of Authors Jari Oja... AF Miika Malinen... AF Erik Neumann... DT Tobias Martin... DT Geza Gaal... MATAV Gizella Kovacs... MATAV Constantinos Boukouvalas... OTE Panagiota Bosdogianni... OTE Paraskevi Paschou... OTE Jorge Carapinha... PT 2002 EURESCOM Participants in Project P1107 EDIN

6 page 6 (70) EURESCOM Project Report Table of Contents Preface...3 Executive Summary...4 List of Authors...5 Table of Contents...6 List of Figures...8 Abbreviations...9 Definitions Introduction Scope Organization of the document Definition of IPVPN and basic IPVPN types What is an IPVPN Reference models Overlay vs. Peer-to-peer VPNs The overlay model The peer-to-peer model P1107 scope IPVPN requirements General Service Requirements Customer Requirements Service Provider Requirements Management requirements Service provider view Fault management Configuration Management related requirements Accounting management Performance Management Security Management CPE-based VPNs IPSec VPNs Other CPE-based VPNs Layer 2 Tunnelling Protocol (L2TP) Generic Routing Encapsulation (GRE) Evaluation Suitability for IPVPN deployment Security considerations Market trends Network-based VPNs BGP/MPLS VPNs Network Architecture BGP/MPLS VPN operation control and data flows BGP/MPLS VPN operational issues Virtual router IPVPNs The VR concept VR VPN implementations VPN auto-discovery MPLS-based Layer 2 VPNs Experimentation and validation QoS in IPVPNs IntServ DiffServ MPLS Integrated Services across MPLS domains using CR-LDP signaling MPLS and DiffServ DiffServ-aware Traffic Engineering (DS-TE ) QoS in MPLS VPNs Management of IPVPNs QoS management needs Generic QoS management capabilities for IPVPN provisioning QoS management for Service Level Agreements QoS management features to be implemented...48 EDIN EURESCOM Participants in Project P1107

7 EURESCOM Project Report page 7 (70) 7.2 Applicable management concepts and recommended models Policy based management with a layered functional architecture Integrated SLA and QoS Data Management Separation of managing VPN services network and VPN transport network Conclusions - recommendations and guidelines Basic enabling technologies: IPsec and MPLS Network-based VPN models which one is best for the SP Layer 2 vs. Layer 3 models Layer 3 VPNs: BGP/MPLS vs. Virtual routers Interworking issues Standardization gaps and future evolutions...59 Appendix A. Commercial IPVPN implementations...61 A.1 IPsec-based implementations survey...61 A.2 MPLS-based implementations...62 A.2.1 Overview of available models and implementations...62 A.2.2 MPLS VPN vendor survey...62 References EURESCOM Participants in Project P1107 EDIN

8 page 8 (70) EURESCOM Project Report List of Figures Figure 1 Reference model for CPE-based VPN...15 Figure 2 Reference model for network-based layer 3 IPVPN...16 Figure 3 Reference model for network-based layer 2 IPVPN...16 Figure 4 Overlay vs. peer-to-peer VPN models...17 Figure 5 Basic taxonomy of IPVPNs...18 Figure 6 Generic architecture of an IPVPN based on IPSec technology...25 Figure 7 Example of a client-initiated tunnel...27 Figure 8 Example of a NAS-initiated tunnel...27 Figure 9 Format of a packet with GRE encapsulation...27 Figure 10 RFC 2547 Network entities...30 Figure 11 Virtual router (VR) vs. physical router...34 Figure 12 - VR VPN reference model...35 Figure 13 VR VPN with direct connectivity between VRs...35 Figure 14 VR VPN with a backbone VR...36 Figure 15 MPLS-based Layer 2 VPN...37 Figure 16 PT BGP/MPLS VPN testbed...39 Figure 17 OG BGP/MPLS VPN testbed...39 Figure 18 Test environment used by HT for the VPDN experiments...40 Figure 19 EF recommended code points...42 Figure 20 AF recommended codepoints...42 Figure 21 DE recommended codepoints...42 Figure 22 E-LSP vs. L-LSP DiffServ MPLS approaches...44 Figure 23 QoS spectrum...44 Figure 24 Hose model...45 Figure 25 Pipe model...46 Figure 26 QoS management with policy based functional architecture...50 Figure 27 SLA/QoS Related Data...51 Figure 28 Generic IP VPN scenario hub model...52 Figure 29 QoS management architecture for ToIP over IPVPN (ETSI TIPHON Draft TS V.0.9.2)...53 Figure 30 BGP/MPLS VPN vs. VR-based VPN...58 Figure 31 Network-based VPN interworking scenario...59 Figure A. 1 IPsec-based VPN survey...61 Figure A. 2 General MPLS features...63 Figure A. 3 Basic VPN standards/drafts...64 Figure A. 4 BGP/MPLS VPN features...64 Figure A. 5 Core MPLS IP VPN Architecture features...65 Figure A. 6 Network-based IP VPN Architecture using VR features...65 EDIN EURESCOM Participants in Project P1107

9 EURESCOM Project Report page 9 (70) Abbreviations AAA Authentication, Authorisation, Accounting AF Assured Forwarding AH Authentication Header AS Autonomous System ASN Autonomous System Number ATM Asynchronous Transfer Mode BA Behaviour Aggregate BGP Border Gateway Protocol BGP4 BGP version 4 CA Certification authority CBR Constant Bit Rate Customer Edge CHAP Challenge Handshake Authentication Protocol CIR Committed Information Rate CMS Cryptographic Message Syntax CoS Class of Service CRL Certificate Revocation List CR-LDP Constraint Based Routing LDP CR-LSP Constraint Routed LSP CUG Closed User Group DES Data Encryption Standard DH Diffie-Hellman DLCI Data Link Connection Identifier DNS Domain Name System DoS Denial-of-Service DSCP DiffServ Code Point DS-TE DiffServ-aware Traffic Engineering EBGP External Border Gateway Protocol EF Expedited Forwarding E-LSP EXP-inferred-PSC LSP ESP Encapsulating Security Payload ETSI European Telecommunications Standards Institute FCAPS Fault, Configuration, Accounting, Performance, Security FEC Forwarding Equivalence Class FTP File Transfer Protocol GRE Generic Routing Encapsulation GW Gateway HTTP Hypertext Transfer Protocol IBGP Internal Border Gateway Protocol IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force IKE Internet Key Exchange IOS Internetworking Operating System IP Internet Protocol IPER IP packet Error Ratio IPLR IP packet Loss Ratio IPND IP Network (operator s) Domain 2002 EURESCOM Participants in Project P1107 EDIN

10 page 10 (70) EURESCOM Project Report IPSec Internet Protocol Security IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 IPVPN Internet Protocol-based Virtual Private Network (same as IP VPN) IPX Internetwork Packet Exchange ISDN Integrated Services Digital Network IS-IS Intermediate System to Intermediate System ISO International Standardisation Organisation ISP Internet Service Provider ITU International Telecommunication Union ITU-T ITU Telecommunication Standardization Sector L2F Layer 2 Forwarding L2TP Layer 2 Tunnelling Protocol LAN Local Area Network LDAP Lightweight Directory Access Protocol LDP Label Distribution Protocol LER Label Edge Router L-LSP Label-Only-Inferred-PSC LSP LSP Labelled Switched Path LSR Label Switch Router MAC Media Access Control MFA Management Functional Area MIB Management Information Base MP-BGP Multiprotocol BGP MPLS Multiprotocol Label Switching MS Microsoft MSEC Multicast Security MTU Maximum Transfer Unit NAS Network Access Server NAT Network Address Translation NMS Network Management System OA Ordered Aggregate OAM Operations and Management ORA Organizational Registration Authority ORF Outbound Route Filter OSI Open Systems Interconnection OSPF Open Shortest Path First OSS Operations Supervisory/Support System P Provider (core) router PCA Policy Certification Authority PE Provider Edge router PHB Per Hop Behaviour PIR Project Internal Result PKI Public Key Infrastructure PLMN Public Land Mobile Network PPP Point-to-Point Protocol PPTP Point-to-Point Tunnelling Protocol PPVPN Provider Provisioned Virtual Private Network PSC PHB Scheduling Class EDIN EURESCOM Participants in Project P1107

11 EURESCOM Project Report page 11 (70) PSTN PVC QoS RADIUS RD RED RFC RIP RSVP RSVP-TE RTI RTT SA SAP SCR SG SLA SLS SMTP SMUG SNMP SP SSL TCP TEK TIPHON TLS TMN ToIP ToS UDP UMTS URL VC VFI VLAN VLL VoIP VPDN VPLS VPN VPWS VR VRF VSI WAN WG WRED Public Switched Telephone Network Permanent Virtual Circuit Quality of Service Remote Authentication Dial In User Service Route Distinguisher Random Early Detection Request For Comments Routing Information Protocol Resource Reservation Protocol RSVP - Traffic Engineering Real Time Intolerant Real Time Tolerant Security Association Service Access Point Sustainable Cell Rate Security Gateway Service Level Agreement Service Level Specification Simple Mail Transfer Protocol Secure Multicast Group Simple Network Management Protocol Service Provider Secure Sockets Layer Transmission Control Protocol Traffic Encryption Key Telecommunications and Internet Protocol Harmonisation Over Network Transport Layer Security Telecommunications Management Network Telephony over IP Type of Service User Datagram Protocol Universal Mobile Telecommunications Services Uniform Resource Locator Virtual Circuit VPN Forwarding Instance Virtual LAN Virtual Leased Line Voice over IP Virtual Private Dial-up Network Virtual Private LAN Service Virtual Private Network Virtual Private Wire Service Virtual Router VPN Routing and Forwarding VPN Switching Instance Wide Area Network Working Group Weighted RED 2002 EURESCOM Participants in Project P1107 EDIN

12 page 12 (70) EURESCOM Project Report Definitions A list of definitions is provided in the P1107 Glossary [Glossary]. EDIN EURESCOM Participants in Project P1107

13 EURESCOM Project Report page 13 (70) 1 Introduction 1.1 Scope This deliverable provides an overall picture of the state-of-the-art of IPVPN architectures and technologies. It is based on results from several activities carried out in the framework of the P1107 project: PIR 2.1 concentrated on IPVPN deployment requirements and architectures. The main IPVPN models have been characterized and a general IPVPN taxonomy has been created. IPVPN deployment scenarios and solutions offered by providers to deliver IPVPN services have also been described. PIR 2.2 provided an overview and an evaluation of the most important IPVPN implementations and IPVPN-related standards (e.g. security, tunneling, QoS). PIR 2.3 carried out experimental activities, focused on MPLS-based IPVPNs, based on three testbeds located in Greece, Hungary and Portugal. PIR 4.1 concentrated on IPVPN QoS issues. In parallel with PIR activities, a Request for Information was carried out. Major IPVPN vendors have been contacted and, based on their feedback, an evaluation of the current status of commercial equipment in terms of IPVPN features (both IPsec-based and MPLS-based) has been performed. This deliverable is the first of two P1107 public deliverables. In addition, Deliverable 2 IPVPN Security provides recommendations and guidelines on IPVPN security. 1.2 Organization of the document This report contains seven main Chapters and one Appendix: Chapter 2 Definition of IPVPN and basic IPVPN types presents the concept of IPVPN and provides a general taxonomy of IPVPNs. Several VPN types are defined in particular, CPE-based vs. Network-based (both of which are to be described in more detail in subsequent chapters of this report) and Overlay vs. Peer-to-peer VPNs. Chapter 3 IPVPN requirements enumerates the basic IPVPN requirements to be followed by any IPVPN implementation. Chapters 4 and 5 describe two basic IPVPN types CPE-based VPNs and Network-based VPNs as well as supporting technologies. Chapter 6 QoS in IPVPNs is focused on QoS as one of the main IPVPN requirements. Chapter 7 Management of IPVPNs is focused on management aspects of IPVPNs and presents a number of related issues. Finally, Chapter 8 Conclusions - recommendations and guidelines provides some overall conclusions. IPsec and MPLS are compared as the two main IPVPN enabling technologies and an evaluation of the main Network-based models is provided. Guidelines on the implementation of the main IPVPN models are also provided. Appendix A Commercial IPVPN implementations provides an overview of the results of a survey of IPVPN commercial products carried out by the P1107 project (the complete results of this survey are available in a Eurescom-confidential Technical Information provided by P1107) EURESCOM Participants in Project P1107 EDIN

14 page 14 (70) EURESCOM Project Report 2 Definition of IPVPN and basic IPVPN types 2.1 What is an IPVPN The concept of Virtual Private Network (VPN) is not new technologies such as ISDN, IN, Frame Relay or ATM have been used over the last decades as a basis for the implementation of this concept. Whatever the format or the technology behind it, a VPN provides a service functionally equivalent to a private network using resources of a public network. In recent years, with the overwhelming success of the Internet, the landscape of telecommunications has changed radically and the IP protocol has been pervasively deployed in corporate networks. IP-based VPNs (IPVPNs), in several forms and based on different network technologies, have shown potential to become the foundation for a wide range of corporate network services. An increasing number of service providers offer value-added applications and services on their IPVPN transport networks to generate new revenue and gain competitive advantage. A VPN can be defined as a service in which customer connectivity amongst multiple sites is deployed on a shared infrastructure with the same access or security policies as a private network. A VPN should be comparable to a private network in performance, reliability, management security and Quality of Service (QoS). Customers of VPN services use shared facilities and equipment, which are managed, engineered and operated by a public network operator, either totally or partly. An IP Virtual Private Network (IPVPN) can be defined as a VPN implementation that uses public or shared IP network resources to emulate the characteristics of an IP-based private network. (Note: since the focus of this document is IP-based VPNs, the terms VPN and IPVPN are used interchangeably in most cases). Compared to classic connection-oriented VPN models, based on technologies such as ATM or Frame Relay, the implementation of IP-based VPNs poses a number of challenges: Πhow to make a shared IP network secure for private enterprise use; Πhow to ensure that quality and network capacity required by a wide variety of users and applications are fulfilled. Usually, two basic types of IPVPNs are identified [draft_ietf_ppvpn_framework_03]: ΠCustomer Premise Equipment (CPE) based VPNs; ΠNetwork-based VPNs In a CPE-based VPN, knowledge of the customer network is limited to the Customer Premise Equipment. Provisioning and management of the VPN is up to the customer network administration, typically by manual configuration of the tunnels between CPE. However, it is common for a service provider to be responsible for managing and provisioning the Customer Edge equipment, in order to reduce the management requirements of the customer. The tunnels between CPE equipment may be implemented as simple link layer connections such as ATM or Frame Relay, or by means of various encapsulation formats such as GRE, IP-in-IP, IPsec, L2TP, or MPLS. Routing in the customer network views the tunnels as simple point-to-point links. Network-based VPNs and all related configuration, operation and control are provided by equipment of the service provider s network. Customer network is supported by tunnels, which are set up between pairs of edge routers. The tunnels may make use of various encapsulations to send traffic over the Service Provider (SP) network. Examples of tunnel encapsulations are GRE, IPsec, IP-in-IP and MPLS. There are two basic types of Network-based VPNs: layer 2-based and layer 3- based. EDIN EURESCOM Participants in Project P1107

15 EURESCOM Project Report page 15 (70) 2.2 Reference models Figure 1 and Figure 2 provide a general reference model for network-based and CPE-based VPNs respectively. This reference model is based on three fundamental components, or entities [draft_ietf_ppvpn_framework_03]: Customer edge () device: device on the customer site, which has an access connection to a PE router. In most cases this corresponds to a router but it may be a host or a switch located at the edge of the user site. Provider edge (PE): router attached via an access connection to one or more devices. In the context of network-based VPNs, a PE router implements one or more (potentially a large number of) VFIs and maintains per-vpn state. A VPN Forwarding Instance (VFI) can be defined as a logical entity that resides in a PE, which includes the router information base and forwarding information base for a specific VPN. A VFI enables router functions dedicated to serving a particular VPN. In general a VFI terminates tunnels for interconnection with other VFIs and also terminates access connections to s. Depending on the VPN architecture, the VFI concept may take different names for example VRF, VR. P router: router within a provider network, which is used to interconnect PE routers, and does not have any direct attachment to devices. The -PE connection is supported by an access connection, which may consist of dedicated physical circuits, logical circuits (such as Frame Relay and ATM), or IP tunnels (e.g., using IPsec, L2TP). In the SP core, VPN tunnels are normally used to interconnect PEs. Customer interface Customer interface device VPN A device VPN B PE router P router VPN tunnel VPN tunnel PE router PE router device VPN A device VPN B Customer management function Network management function Access network Service Provider network Access network Figure 1 Reference model for CPE-based VPN The reference models represented in Figure 1 and Figure 2 highlight the basic differences between CPE-based and network-based VPN models: while in the CPE-based model the service provider network is transparent from the point of view of the control mechanisms of the VPN, in the network-based model all the service intelligence resides at the service provider s PE routers. In addition, the support of the VFI concept is a requirement for routers playing the role of PE routers in the network-based model EURESCOM Participants in Project P1107 EDIN

16 page 16 (70) EURESCOM Project Report Customer interface Customer interface device VPN A PE router VFI Network interface P router VPN tunnel PE router VFI device VPN A device VPN B VFI Customer management function VPN tunnel Network management function VFI PE router device VPN B Access network Service Provider network Access network Figure 2 Reference model for network-based layer 3 IPVPN A variant of the network-based layer 3 model is the network-based layer 2 model, represented by the reference model shown in Figure 3. Customer interface Customer interface device VPN A PE router VSI Network interface P router VPN tunnel PE router VSI device VPN A device VPN B VSI Customer management function VPN tunnel Network management function VSI PE router device VPN B Access network Service Provider network Access network Figure 3 Reference model for network-based layer 2 IPVPN In a layer 2 VPN the concept of Virtual Switching Instance (VSI) replaces the VFI from the layer 3 model. As the VFI, the VSI resides in a PE router. It supports functions regarding the forwarding of layer 2 frames, cells or packets for a VPN and terminates the tunnels associated to a specific VPN. In addition, the IETF defines the concept of Provider Provisioned IPVPN (PPVPN). A PPVPN is a kind of VPN in which the service provider is responsible for management and provisioning. The alternative to a PPVPN is a user-managed VPN in which the network service provider does not participate in the VPN management and provisioning and is normally not aware of the existence of the VPN. Although most PPVPNs will be network-based VPNs, the two concepts are not entirely equivalent - for example, a PPVPN may be a CPE-based VPN managed by the SP. Virtual private dial-up networks (VPDN) represent a typical on demand access solution for reaching certain fixed, central sites (and servers, facilities) from and through a public, switched local telephony network. The VPDN customer is the company, typically an ISP, with groups of remote users but without own access carrier network resources. VPDN users are to be identified, and authenticated before establishing the IP based connectivity in order to transport the payload forming IP datagrams. In VPDNs, the PSTN, PLMN, ISDN network provides the physical layer EDIN EURESCOM Participants in Project P1107

17 EURESCOM Project Report page 17 (70) between the client users (IP hosts) and the interworking unit(s) (gateways) towards the IP based transport carrier network of the VPDN provider(s). 2.3 Overlay vs. Peer-to-peer VPNs Another common VPN classification is based on whether the customer s CPE (Customer Premises Equipment) and the service provider exchange layer 3 routing information. Two VPN implementation models can be defined based on this criterion [Ferguson1]: ΠThe overlay model, where the VPN service is functionally equivalent to emulated leased lines and the service provider and the customer do not exchange layer 3 routing information. This model provides a clear separation between the customer s and provider s responsibilities. ΠThe peer-to-peer model, where the service provider and the customer exchange layer 3 routing information. Such implementations normally simplify customer routing and provide easier VPN service provisioning. Figure 4 illustrates the basic distinction between the two models. Site 4 Site 4 Site 3 Site 3 PE PE PE PE PE PE PE PE Site 1 Site 2 Site 1 Site 2 Overlay model Peer-to-peer model The overlay model Figure 4 Overlay vs. peer-to-peer VPN models In the overlay VPN model, QoS guarantees are usually expressed in terms of bandwidth guaranteed on a certain VC (Committed Information Rate) and maximum bandwidth available on a certain VC (Peak Information Rate). The committed bandwidth guarantee is usually provided through the statistical nature of the Layer 2 service, but depends on the overbooking strategy of the service provider. This means that the committed rate may not be actually guaranteed although the provider can provision a Minimum Information Rate across the Layer 2 infrastructure. Overlay VPNs can be implemented with a number of switched WAN Layer 2 technologies, including X.25, Frame Relay or ATM. Overlay VPN networks have also been implemented with IP-over-IP tunnelling, both in private IP backbones and over the public Internet. The two most commonly used IP-over-IP tunnelling methods are Generic Route Encapsulation (GRE) tunnelling and IP Security (IPsec) tunnel mode. The overlay VPN model nevertheless has a number of drawbacks: ΠIt s well suited to configurations with a few central sites and many remote sites, but becomes exceedingly hard to manage in a more meshed configuration EURESCOM Participants in Project P1107 EDIN

18 page 18 (70) EURESCOM Project Report ΠΠProper provisioning of the VC capacities requires detailed knowledge of site-to-site traffic profiles, which are not easily available. When implemented with Layer 2 technologies, the overlay VPN model introduces another unnecessary layer of complexity and increases operational costs The peer-to-peer model The peer-to-peer VPN model was introduced to alleviate the drawbacks of the overlay VPN model. In the peer-to-peer model, the Provider Edge router directly exchanges routing information with the CPE router. The peer-to-peer model provides a number of advantages over the traditional overlay model: ΠRouting becomes simple, as the customer router exchanges routing information with only one Provider Edge (PE) router, whereas in the overlay VPN network the number of neighbour routers depends on the number of remote sites, which means that it can grow to a large number. ΠAdding a new site is simpler, because the service provider provisions only an additional site and changes the configuration on the attached PE router. Under the overlay VPN model, the service provider must provision a whole set of VCs leading from that site to other sites of the customer VPN. In practice, if there is a clear criterion by which the adoption of overlay or peer-to-peer should be decided, this criterion is size. For small-scale implementations the overlay model is probably the simplest way to build a VPN. For larger VPNs, the overlay model is clearly limited in terms of scalability and the peer-to-peer model should be the appropriate option. 2.4 P1107 scope Based on the concepts discussed above, Figure 5 provides a non-exhaustive table of the basic taxonomy proposed by P1107 and defines the project scope. What kind of tunnel is used? Traditional Layer 2 VPNs What protocol is used? X.25 VPNs Frame relay VPNs ATM VPNs Overlay VPNs Layer 2 MPLS VPNs VPNs Peer-to-peer VPNs IP tunneling VPNs GRE VPNs IPsec VPNs Dedicated router VPNs BGP/MPLS VPNs P1107 scope Is there layer 3 routing exchange between the customer and the Service Provider? Virtual Router VPNs What approach is used to build VPNs? Figure 5 Basic taxonomy of IPVPNs EDIN EURESCOM Participants in Project P1107

19 EURESCOM Project Report page 19 (70) 3 IPVPN requirements This chapter outlines the requirements on network and service provisioning, based on the latest version of the IPVPN requirements draft provided by the IETF PPVPN Working Group [draftrequirements]. The IETF, using inputs also from ITU-T SG13, gives a detailed list and description of requirements for Provider Provisioned Virtual Private Network. Requirements are presented for the VPNs to be utilised by customers, as well as requirements identified for the IPVPN service providers. 3.1 General Service Requirements General requirements are identified based upon the past experience of IP based service offering. Traffic types to be supported: There are different traffic types, which are to be supported depending on the types of the IPVPN services and utilization purposes. As a rule, an IPVPN services must support both unicast and multicast traffic. Support of arbitrary topology: Inter-site connectivity options, ranging from hub-and-spoke, partial mesh to full mesh topology should be supported, as well as multiple VPNs per customer site. Constrained distribution of data and routing information: A means to constrain, or isolate the distribution of routing information to only those VPN sites which are determined by customer routing and/or configuration must be provided. The VPN solution must ensure that traffic is exchanged only with those sites that are in the same VPN, while the internal structure of the VPN should be invisible to the public Internet. Support of overlapping IP addresses: A layer 3 VPN service shall support overlapping customer addresses, as IP addresses must be unique only within the set of sites reachable from the VPNs of which a particular site is member (but non-unique as for different customers VPNs). Security for data, routing, & access: Security features such as user data security (to achieve confidentiality, integrity, authentication and reply attack prevention), access control (to activate filtering capabilities upon request of a customer), and site authentication and authorization must be supported by the VPN solutions. Management of service and resources: A service provider and its customers must be able to manage the capabilities and characteristics of their VPN services based on a proper management model (e.g. ITU-T TMN model). Interoperability: Compatibility with applicable Internet standards is required. Multi-vendor interoperability should be supported at the network element, network and service levels. Multi-vendor interoperability is required not only within the SP network infrastructure but also with the customer s network equipment and services which make use of PPVPN service. Interworking scenarios must consider traffic routing isolation, security, QoS, access and management aspects. Interworking between different (technology and implementation) solutions: As IPVPN provisioning based on interconnection of different transport (core) network domains and multi-provisioning are considered, to reach interworking between different VPN service components and provisioning solutions is desirable. 3.2 Customer Requirements From the customer perspective, the following requirements should be considered [draftrequirements]: VPN membership is to be approved - e.g., for adding a new site or, when configuring extranets, by both organizations EURESCOM Participants in Project P1107 EDIN

20 page 20 (70) EURESCOM Project Report Service provider independence is needed, as the VPN service may span multiple AS and SP networks. QoS and traffic parameters should be selectable and supported, according to application level QoS objectives for different traffic types. No restriction on -PE routing protocol: static routing or such routing protocols as RIP, OSPF, IS-IS or BGP should be supported. Service Level Agreement support is needed: a customer agent must have access to the SP s SLA monitoring/ delivery performance database, or on demand reporting on conformance is needed. Customer management of a VPN should be available, i.e., view of topology, operational state, resource usage monitoring and control. Security & Integrity mechanisms should be supported (in addition to the SP deployed mechanisms and solutions). Security services shall apply to all VPN traffic or to a subset of VPN traffic between certain sites. Minimal migration impact is desirable support of full migration and partial migration is needed, e.g., for changing the customer site technology, types and number of routers, or PPVPN services and solutions. Different access network options should be offered, including requirements on selectable network access and usage of various physical/link layer technology, dedicated and dial-in access, permanent or temporary access solutions, possibility of shared access network usage, different access connectivity topology/availability support solutions (multi-homing, load balance links, etc.) Internet access the public Internet must be reachable over VPN access network when the customer requires (network address translation or similar mechanism must be supported when necessary). Access to other services is to be offered in conjunction with a VPN service, as this might be needed for the customers (like access to DNS, FTP, HTTP, SMTP, VoIP, LDAP, Videoconferencing, Streaming, Directory, Firewall, business-to-business and e-commerce services offered by the VPN SP, or third parties). Hybrid VPN service scenarios, more than one VPN solution type and hybrid network usage might be desirable an appropriate framework for interoperability and interworking, with scalable, managed VPN implementation solutions is needed. 3.3 Service Provider Requirements In this clause, a list of major service provider requirements is identified. Scalability this covers SP capacity sizing projections, number and types of site interfaces and routes per VPN. Dynamic learning of VPN related information, like membership, is required. Service Level Agreements and specs support of SLA and SLS is required, and conformance is to be controlled based on measuring of parameters (e.g., payload transfer quality, availability, response times, configuration intervals). Quality of service support and implementing of appropriate traffic engineering techniques is needed in order to provide either managed QoS access service or edge-to-edge QoS (transport) service, especially when more network (domain operator) are included. Isolation of traffic and routing (between different, parallel provisioned VPNs) requires that: i) processing of data and traffic handling techniques applied within the SP domain supports the creation of appropriate number of L2 switching or L3 forwarding tables (at EDIN EURESCOM Participants in Project P1107

21 EURESCOM Project Report page 21 (70) each PE and for all the VPNs they have access ports), and ii) the effects of congestion situations produced by certain sites must be isolated. Tunnelling mechanism and backbone technology independence is desired to allow different technology implementations and networking solutions. Possible migration between different solutions while still providing services for customers, which requires an appropriate level of interoperability between vendors and interworking between solutions. Provide protection and restoration options the provisioning network systems should support the SPs to offer different service protection and service restoration (priority, precedence handling options), as part of the SLS to be agreed for the contracted SLA. Support of inter-as and carrier s carrier type provisioning solutions (i.e., VPN wholesale products, not only retail ones). Management: At least the TMN model specified FCAPS is to be implemented and applied. Security features and services should be available covering requirements related to securing customer flows, providing authentication services for temporary, remote or mobile users, as well as to protection of the SP resources against attacks and unauthorised access. Provide access to value-added services is not only a customer requirement but also an SP requirement, particularly on the provisioning support system capabilities. 3.4 Management requirements Service provider view Fault management Support features and required functionality for fault management include: indication of customers impacted by failure, fault detection (incidents reports, alarms, failure visualisation), fault localisation (analysis of alarms reports, diagnostics), incident recording or logs, creation and follow through of trouble tickets), corrective actions (traffic, routing, resource allocation). Network-based VPNs rely on a common network infrastructure, therefore the network management system must provide a means to inform the provider on the VPN customers impacted by a relevant failure. Network element status monitoring, partial and total service outage event logging is necessary, and not only trouble ticketing but alarm indication signalling is desirable, especially in multi-provisioning environment, for providing the VPNs based on interconnected networks. It is desirable to detect faults caused by different types of configuration errors, and service outages due to serious performance degradation, but detection of such errors and fault clearing might be difficult when the problem involves more nodes and interconnected provider domains. Fault management should be supported by introducing event and status monitoring, e.g., using (new) control protocol(s) to check that the customer specified accessibility, routing/forwarding constraints are presented, and proper configuration parameter settings are used. As a minimum requirement, capability to verify the L2 connectivity or L3 reachability within a VPN must be provided, at least for diagnostic purposes. To support layer 2 VPNs with their own fault management protocols and procedures, the PPVPN service should emulate alarm reporting and defect indications on an edge-to-edge basis. A capability to verify the parameter configuration of a device supporting a PPVPN must be provided for diagnostic purposes EURESCOM Participants in Project P1107 EDIN

22 page 22 (70) Configuration Management related requirements EURESCOM Project Report The IETF PPVPN WG, by the last version of [draft-requirements], has recently defined detailed requirements, separately for the -based and the network (PE) based provisioning, as follows. Configuration Management for Network-Based VPNs Requirements for configuration management, unique to a PE-based VPN are as follows. The Network Management System (NMS) must support configuration of at least the following aspects of a L3 PE routers: intranet and extranet membership, routing protocol for each access connection, routing metrics, tunnels, etc. The NMS should use identifiers for SPs, PPVPNs, PEs, s, and to support hierarchical tunnels and access connections. Tunnels must be configured between PE and P devices. This requires co-ordination of identifiers of tunnels, hierarchical tunnels, VPNs, and any associated service information, for example, a QoS/SLA service. Routing protocols running between PE routers and devices must be configured per VPN. For multicast service, multicast routing protocols must also be configurable. Routing protocols running between PE routers and between PE and P routers must also be configured. The configuration of a PE-based PPVPN must be co-ordinated with the configuration of the underlying infrastructure, including Layer1 and Layer2 networks interconnecting components of a PPVPN. Configuration management for -based VPN Requirements for configuration management, unique to a -based VPN are as follows. Tunnels must be configured between devices. This requires Co-ordination of identifiers of tunnels, VPNs, and any associated service information, for example, a QoS/SLA service. Routing protocols running between PE routers and devices must be configured. For multicast service, multicast routing protocols must be also configurable. Provisioning resource management support for VPNs A service provider must have a means to dynamically provision resources associated with VPN services. For example, in a network-based service, the number and size of virtual switching and forwarding table instances must be provisionable. Dynamic VPN resource assignment is crucial to cope with the frequent changes requests from customer s (e.g., sites joining or leaving a VPN), as well as to achieve scalability. The PEs should be able to dynamically assign the VPN resources, especially for dial and wireless (access) VPN services. However, if an SP offers a "Dynamic Bandwidth management" service, then the dates, times, amounts and interval required to perform requested bandwidth allocation change(s) must be also traceable Accounting management Many service providers offer usage based charging, thus collection of measurements regarding resource usage should be completed (using support systems and protocols) for accounting purposes. The NMS may need to correlate accounting information also with performance and fault management information to produce billing that takes into account SLA provisions for periods of time with service degradation (conditional billing) and to apply compensation schemes where and as long as the SLS is not met. Therefore all the PPVPN deployment solutions must describe how the following accounting management support functions can be provided: measurements of resource utilization, collection of accounting information, storage and administration of measurements. EDIN EURESCOM Participants in Project P1107

23 EURESCOM Project Report page 23 (70) Some providers may require near-real time reporting of measurement information, and may offer this as part of a customer network management service Performance Management Performance management includes functions involved with monitoring and collecting performance data regarding devices, facilities, and services, as well as determination of conformance to Service Level Specifications (SLS), such as QoS and availability measurements. Performance management should also support analysis of important aspects of a PPVPN, such as bandwidth utilisation, response time, availability, QoS statistics, and trends based on collected data. Performance Monitoring The NMS must monitor device behaviour to evaluate performance metrics associated with a service level agreement. Different measurement techniques (intrusive or non-intrusive depending on the usage of generated probes of analysing live packet flow performance parameters) can be used for performance monitoring. Measurements, reference points and metrics, data processing schemes should be those fixed by the SLAs. Therefore, standard based methods and performance evaluation is highly recommended. However, different end-to-end transfer performance (QoS) classes, service availability and security levels, multicast, and temporary access use cases are calling for specific reference architecture, various metrics ranges, (and delivery failure criteria), and different test traffic (probe) types might be needed. In addition, the NMS must also monitor aspects of the VPN not directly associated with an SLA, such as resource utilization levels, load condition specific performance changes. SLA and QoS management features The NMS should support SLAs between the SP and the various customers according to the corresponding SLSs by measurement of the indicators defined within the context of the SLA, on a regular basis. The NMS of the SP should use the QoS parameter measurement definitions, techniques, and methods as defined by the related standards. It is recommended using metrics defined by the IETF IP Performance Metrics (IPPM) WG for delay, loss, and delay variation, according to the IP definition of performance metrics and MIBs defined by IETF, to offer and contract provisioning of site-to-site QoS (transfer service classes for cross-conect services) in accordance with performance parameter types and ranges given as standard IP performance classes, to apply parameter allocation models, to consider traffic control and service protection etc. guidelines and standards recently defined by ITU-T SG13. Devices supporting PPVPN SLAs should have real-time performance measurements that have indicators and threshold crossing alerts. Such thresholds should be configurable Security Management The security management function of the operational NMS must include management features to guarantee the security of devices, access connections, and protocols within the PPVPN network(s), as well as the security of customer data and control. Management Access Control and AAA requirements Management access control determines the privileges that a user has for particular applications and parts of the network. Without such control, only the security of the data and control traffic is protected, leaving the devices providing the PPVPN network unprotected. Access control capabilities protect these devices to ensure that users have access to only the resources and applications which they are authorized to use. In particular, access to the routing and switching resources managed by the SP must be tightly controlled to prevent and/or effectively mitigate a malicious attack EURESCOM Participants in Project P1107 EDIN