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

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 0298-1107 Project P1107 For full publication April 2002

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 0298-1107 2002 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..

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. 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(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 0298-1107 2002 EURESCOM Participants in Project P1107

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 0298-1107

(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...12 1 Introduction...13 1.1 Scope...13 1.2 Organization of the document...13 2 Definition of IPVPN and basic IPVPN types...14 2.1 What is an IPVPN...14 2.2 Reference models...15 2.3 Overlay vs. Peer-to-peer VPNs...17 2.3.1 The overlay model...17 2.3.2 The peer-to-peer model...18 2.4 P1107 scope...18 3 IPVPN requirements...19 3.1 General Service Requirements...19 3.2 Customer Requirements...19 3.3 Service Provider Requirements...20 3.4 Management requirements Service provider view...21 3.4.1 Fault management...21 3.4.2 Configuration Management related requirements...22 3.4.3 Accounting management...22 3.4.4 Performance Management...23 3.4.5 Security Management...23 4 CPE-based VPNs...25 4.1 IPSec VPNs...25 4.2 Other CPE-based VPNs...26 4.2.1 Layer 2 Tunnelling Protocol (L2TP)...26 4.2.2 Generic Routing Encapsulation (GRE)...27 4.3 Evaluation...28 4.3.1 Suitability for IPVPN deployment...28 4.3.2 Security considerations...28 4.3.3 Market trends...29 5 Network-based VPNs...30 5.1 BGP/MPLS VPNs...30 5.1.1 Network Architecture...30 5.1.2 BGP/MPLS VPN operation control and data flows...31 5.1.3 BGP/MPLS VPN operational issues...32 5.2 Virtual router IPVPNs...34 5.2.1 The VR concept...34 5.2.2 VR VPN implementations...35 5.2.3 VPN auto-discovery...36 5.3 MPLS-based Layer 2 VPNs...36 5.4 Experimentation and validation...38 6 QoS in IPVPNs...41 6.1 IntServ...41 6.2 DiffServ...42 6.3 MPLS...43 6.3.1 Integrated Services across MPLS domains using CR-LDP signaling...43 6.3.2 MPLS and DiffServ...43 6.3.3 DiffServ-aware Traffic Engineering (DS-TE )...44 6.3.4 QoS in MPLS VPNs...45 7 Management of IPVPNs...47 7.1 QoS management needs...47 7.1.1 Generic QoS management capabilities for IPVPN provisioning...47 7.1.2 QoS management for Service Level Agreements...48 7.1.3 QoS management features to be implemented...48 EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 7 (70) 7.2 Applicable management concepts and recommended models...49 7.2.1 Policy based management with a layered functional architecture...50 7.2.2 Integrated SLA and QoS Data Management...51 7.2.3 Separation of managing VPN services network and VPN transport network...52 8 Conclusions - recommendations and guidelines...55 8.1 Basic enabling technologies: IPsec and MPLS...55 8.2 Network-based VPN models which one is best for the SP...56 8.2.1 Layer 2 vs. Layer 3 models...56 8.2.2 Layer 3 VPNs: BGP/MPLS vs. Virtual routers...57 8.2.3 Interworking issues...58 8.2.4 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...66 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(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 101 329-3 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 0298-1107 2002 EURESCOM Participants in Project P1107

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 0298-1107

(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 0298-1107 2002 EURESCOM Participants in Project P1107

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 0298-1107

(70) EURESCOM Project Report Definitions A list of definitions is provided in the P1107 Glossary [Glossary]. EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

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). 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(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 0298-1107 2002 EURESCOM Participants in Project P1107

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. 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(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 0298-1107 2002 EURESCOM Participants in Project P1107

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 2.3.1 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. 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(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. 2.3.2 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 0298-1107 2002 EURESCOM Participants in Project P1107

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. 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(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 0298-1107 2002 EURESCOM Participants in Project P1107

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 3.4.1 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. 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) 3.4.2 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. 3.4.3 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 0298-1107 2002 EURESCOM Participants in Project P1107

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. 3.4.4 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. 3.4.5 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. 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) EURESCOM Project Report For user access control, and authentication based resource usage authorisation, the scalability is critical as the number of nomadic/mobile clients is increasing rapidly. The authentication scheme implemented for such deployments must be manageable for large numbers of users and VPN access points. The NMS must support standard protocols to authenticate users attempting to access management services as well. EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 25 (70) 4 CPE-based VPNs CPE-based VPNs are build solely with customer equipment devices. In the overlay model the service provider is not involved in the operation of the customer s VPN. In the peer-to-peer model on the other hand the service provider and the customer exchange layer 3 routing information. The customer may also use connections from different service providers for the construction of CPE-based VPN. However, some of the standards and technologies described here (mainly IPsec) may also been used by the service provider to provide value added services or an advanced security for the VPN service. 4.1 IPSec VPNs IPSec specifies several mechanisms aiming at securing traffic at the IP level. Optional in IPv4, it has become mandatory for all implementations of IPv6. It offers to the higher level protocols: - data integrity (in a non-connected mode) - authentication of the data source - protection against replay - confidentiality - network layer tunnelling The IPSec VPN is based on secure tunnel establishment between two peers. The equipments used to built the VPN are: Security gateways, A Service Provider management platform (optional), A Policy server (optional), A Certificate Authority server (optional), An LDAP server (optional). Radius Enterprise 1 LDAP CA1 SG11 Site A Router Mobile Extranet Security policy CA2 Intranet Security policy Site B Public IP Network Router SG21 LDAP Radius PS13 SG12 Router PS3 Router Security Policy Server Enterprise 2 CA VPN Management Figure 6 Generic architecture of an IPVPN based on IPSec technology. 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) EURESCOM Project Report Figure 6 illustrates an IPVPN, which allows secure connection between two sites of the Enterprise 1 and the site of the Enterprise 2. The mobile worker may be connected to the IPVPN through the Internet. He first establishes a connection to the Internet via an ISP and then establishes a secure tunnel between his PC and a Secure Gateway (SG11). The tunnels between the sites are established by the security gateways (SG11, SG12 and SG21). A service provider may remotely manage the security gateways (SG) or they are managed by the customer himself. If the SGs are configured by the service provider, the security services related to the tunnels are selected in conformance to the rules stored in the Security Policy Server of the IPVPN provider. The authentication of the gateways and the remote users is either based on shared keys or on certificates. In the latter case the IPVPN provider or another entity issues certificates via a Certificate Authority server (CA). When certificates are used, a Certificate Revocation List (CRL) needs to be managed, especially if remote users are involved. Several scenarios may be discussed regarding the CRL management. The most convenient scenario is the one where the enterprise manages the CRL. In that case, the CRL update should be quick. If the update of the CRL is the responsibility of the VPN provider, the Enterprise has to transmit the necessary information to the VPN Provider. The CRL should be stored in an LDAP directory and the gateways should retrieve it automatically in regular intervals. 4.2 Other CPE-based VPNs Beside IPSec on the network layer there are the layer 2 tunnelling protocols, namely L2F, PPTP, L2TP and GRE. L2F (Layer 2 Forwarding, Cisco) and PPTP (Point-to-Point Tunnelling Protocol, Microsoft) were combined into L2TP (Layer 2 Tunnelling Protocol) by a consortium led by Cisco and Microsoft. Hence L2TP can be considered as best of L2F and PPTP. 4.2.1 Layer 2 Tunnelling Protocol (L2TP) All the layer 2 security protocols described in this section extend the well-known PPP protocol beyond its natural reach: Normally PPP is used by ISPs to grant access to an IP network over a dial-up telephone line. PPP is also used for direct modem connections to Intranets. However, since the AAA (Authentication, Authorisation, Accounting) features of PPP are well understood and reliably implemented, many people also wish to use PPP over IP connections, especially to connect remote clients to an intranet. This nomadic user scenario is the basis of the following descriptions. A layer 2 tunnel is established between two of the three following entities: Client. A client software on the nomadic users PC wants to get access to an intranet. The client must at least store the AAA related identification data of the user, and must be able to perform PPP. In some cases, he must also be able to set up the layer 2 tunnel. Network Access Server (NAS). The NAS connects the client to an IP network. The NAS can either simply terminate the PPP session of the client (e.g. if he is not able to perform layer 2 tunnelling), or he can forward the PPP session to the Home-Gateway of the client (using layer 2 tunnelling). Home-Gateway. The Home-GW terminates the PPP session from the client, and performs AAA to decide whether to grant the client access to the intranet or not. In a layer 2 tunnelling environment, one has to distinguish between client-initiated tunnel and NAS-initiated tunnel: In a client-initiated tunnel, the client is responsible for the tunnel set-up. As a consequence, he first has to establish an IP connection to the Home-GW, and then encapsulate a PPP session within the IP connection, using Layer 2 tunnelling (Figure 7). In a NAS initiated tunnel, the client s only task is to set up a PPP connection to the NAS. The NAS will then forward the PPP session to the Home-GW, and the Home-GW performs AAA (Figure 8). EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 27 (70) Remote User IP2 PPP GRE/UDP IP1 PPP ISDN ISP NAS IP2 PPP GRE/UDP IP1 Internet Home-GW IP2 Intranet Figure 7 Example of a client-initiated tunnel Remote User IP2 PPP ISDN ISP NAS IP2 PPP GRE/UDP IP1 Internet Home-GW IP2 Intranet Figure 8 Example of a NAS-initiated tunnel 4.2.2 Generic Routing Encapsulation (GRE) Generic Routing Encapsulation (GRE) is a generic mechanism for encapsulating any network layer protocol over any other network layer protocol. The general specification is described in RFC 1701, and RFC 1702 defines the encapsulation of IP packets over IP as a specific implementation of GRE. The main use of the RFC 1702 standard is to route IP packets between private IP networks across an Internet (portion) that uses globally assigned IP addresses. Delivery Header GRE Header Payload Figure 9 Format of a packet with GRE encapsulation. In the general case the payload packet is encapsulated in a GRE packet, which may also include source route information. The resulting GRE packet is encapsulated in the delivery protocol, and then forwarded (Figure 9). RFC 1701 does not say much about security issues. It only admits 32 Bit of space in the GRE header to include some security information. Since 32 Bit is not enough for any current cryptographic algorithm, this may only be used as a reference value like the IPSec SPI. The real work, namely to design a robust security framework, is left open. 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) 4.3 Evaluation EURESCOM Project Report 4.3.1 Suitability for IPVPN deployment IPSec performs tunnelling mechanisms on the network layer. As a consequence only IP originated traffic can be passed through IPSec-based VPNs. If other network protocols beside IP are used at a site one has to consider the usage of a layer 2 tunnelling protocol. L2TP and GRE are also suitable for the VPN forwarding of non-ip traffic such as IPX. In addition specifically L2TP has the advantage of being more suitable for remote access to VPN sites. For IPSec there are still problems with remote access, especially when using dynamic IP addresses provided by an ISP. The IETF IPSRA working group aims to solve these issues. IPSec adds less encapsulation overhead when tunnelling packets. Furthermore, the computational overhead is lower, because IPSec (namely ESP/AH) relies on symmetric encryption schemes. On the other hand, this requires frequent key-exchange, if a certain amount of information is exchanged. Therefore the basic IPSec protocols, ESP and AH are rarely used without IKE. While IKE supports the asymmetric key negotiation, it slows down the tunnel establishment significantly. Thus, the fast tunnel has to be paid by a slow tunnel establishment. IKE not only provides countermeasures for all known security attacks, but it also allows to integrate new encryption and authentication algorithms in the future. So the complexity of IKE is related to its features and its flexibility. Unfortunately, this complexity makes it more difficult to implement, deploy, configure, or maintain an IPSec VPN. The layer 2 tunnelling protocols are well understood, easy to configure, and commonly available. Nowadays, simple IPSec VPNs are working seamlessly, too. But in complex scenarios, the interoperability between implementations is still an issue. Furthermore, if many feature are used (especially PKI), there are some requirements regarding the underlying infrastructure (e.g. a CA or an LDAP server). Practically, most problems with IPSec are due to configuration mismatches or infrastructure limitations, i.e. they are often related to features not offered by layer 2 tunnelling protocols at all! In contrast to the layer 2 protocols, IPSec is also available for IPv6, and it is even part of the IPv6 specification. Combined with its ability to integrate new encryption algorithms like AES, this makes IPSec the right choice when investing in a long term. L2TP and its relatives were originally designed for remote access, but there usage was extended to VPN scenarios. Their limitations are obviously in the area of security and performance. Nevertheless, they are still favoured for remote access, because ease of use is required when the tunnels are set up by road-warriors. 4.3.2 Security considerations Immediately after the publication of the RFCs, IPSec has been criticised at a theoretical level [Ferguson2], mainly because the only mandatory encryption algorithm was DES-CBC and because of the many possible options and modes. Today there are many interoperable IPSec implementations using stronger cryptographic algorithms than DES. In addition the IETF IPSec working group published Internet Drafts describing the use of the new AES with IPSec. There are also some arguments to use the ESP tunnel mode only [Ferguson2]. Recently the IPSec key agreement protocol IKE has been brought into focus by a position statement of IESG and IAB members. As IKE is a generic and extensible protocol, it is, as a consequence, very complex. In the past this led to implementation weaknesses and missing interoperability. For this reason, IKE may be derived to a Son of IKE protocol which will either be a less complex evolution of the current IKE or a completely new development. In spite of all these facts IPSec is still the best choice to protect all non-secured, or insufficiently secured IP traffic. Until now, no practical or even theoretically possible attacks have been found to break the security of IPSec. EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 29 (70) In contrast to IPSec neither L2TP nor GRE have build-in security mechanisms. For the fulfilment of some basic security requirements such as data confidentiality, integrity and authentication additional cryptographic algorithms have to be used, which are not specified by L2TP or GRE by themselves. In a first phase, the two consortiums led by Microsoft on one side (PPTP) and Cisco on the other (L2F) tried to define their own encryption techniques based on proprietary implementations. Microsoft used MS-CHAP as a basis, and Cisco used the encryption capabilities of Cisco IOS. Both approaches turned out to be problematic, since Mudge and Schneier found serious security holes in PPTPv1 (see: [Schneier]), and the CISCO IOS encryption scheme is not very interoperable. Today s recommendation by both major companies seems to be to use PPP for AAA purposes, and to use IPSec for encryption. This is possible since most Layer2 tunnelling implementations use IP as a transport medium. 4.3.3 Market trends The layer 2 tunnelling protocols are commonly available. At least PPTP is available on all MS Windows computers. Furthermore, they are supported by most commercial routers. The configuration is simply part of the access configuration. So the administrator of the tunnels is a network specialist. In contrast to this, IPSec was originally offered on separate gateways. Due to the complexity of the protocol, IPSec was always regarded a security mechanism that allows to interconnect networks, while the layer 2 protocols were regarded as transit technologies that allowed to add some security. Therefore, IPSec was configured by security specialists, and the configuration dialogues were focussing on security parameters. Nowadays, both worlds are merging because IPSec functionality is added to routers and firewall and routing functionality is added to IPSec gateways. Often the preferences of administrators depend on the area they come from. The layer 2 tunnelling protocols started as proprietary solutions. Later they were standardised by the IETF. IPSec, on the other hand, was developed within the IETF by a number of major network operators and manufacturers. This lead to a protocol addressing exactly the (expected) needs and needs of the users and vendors. And the manufacturers are permanently improving their IPSec implementations, especially the aspects of administration and interoperability. Publications show that IPSec gains importance. The number of VPNs relying on IPSec is increasing. Even Microsoft added an IPSec implementation to its TCP/IP stack. It is expected that IPSec will play the dominant role in CPE-based VPNs in the near future. Nevertheless, layer 2 tunnelling protocols will remain meaningful for remote access. 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) EURESCOM Project Report 5 Network-based VPNs In this section three basic types of network-based VPNs are described: BGP/MPLS VPNs, virtual router-based VPNs and Layer 2 MPLS VPNs. These approaches correspond to the three fundamental methods to build network-based VPN architectures specified by the IETF until now. A number of challenges have to be faced by any network-based IPVPN solution: How to learn VPN membership (VPN auto-discovery); How to tunnel traffic among customer sites; How to learn and distribute customer routes (in layer 3 VPNs only); How to guarantee VPN traffic isolation. Different IPVPN models propose different solutions for these problems, as will be described in the following sub-sections. 5.1 BGP/MPLS VPNs BGP/MPLS VPNs are network-based IPVPNs which are described in RFC 2547bis [RFC2547] (actually, RFC 2547bis has been made obsolete by subsequent Internet drafts [draft-rosen-2547], but the term is still widely used to identify this type of VPNs). RFC 2547bis defines a method that allows service providers to use their IP backbone in order to provide VPN services to their customers. The customer may be an enterprise or a group of enterprises, which need an Extranet, an Internet Service Provider, an Application Service Provider, or another VPN Service Provider, using the same mechanism to offer VPNs to its own customers. BGP/MPLS VPNs use: a. BGP to distribute VPN routing information across the provider s backbone and b. MPLS to forward VPN traffic from one VPN site to another. 5.1.1 Network Architecture A VPN according to RFC 2547bis can be viewed as a collection of policies and rules, which control IP connectivity among a set of sites. A customer site is connected to the service provider network by one or more interfaces; the service provider associates each interface with a VPN routing table. This VPN routing table is called a VPN routing and forwarding (VRF) table. Figure 10 illustrates the main building blocks of a BGP/MPLS VPN. Site 1 VPN A Service provider network Site 2 VPN A Site 3 VPN B PE P P P PE Site 4 VPN B Figure 10 RFC 2547 Network entities routers advertise the site s local VPN routes to the PE router, and learns remote VPN routes from the PE router. EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 31 (70) PE routers exchange routing information with routers using static routing, RIP, OSPF or EBGP. The PE router maintains VPN routing information for those VPNs to which it is directly attached. This design enhances the scalability of RFC 2547bis model because it eliminates the need for PE routers to maintain all of the service provider s VPN routes. Each customer connection is mapped to a specific VRF. The interface on the PE router is associated with a VRF, multiple interfaces on a PE router can be associated with a single VRF. PE routers have the ability to maintain multiple forwarding tables that support the per-vpn separation of routing information. A PE router exchanges VPN routing information with other PE routers using IBGP. Rather than having a complete IBGP mesh among the PEs, PE routers can maintain IBGP sessions to BGP route reflectors to improve scalability. Deploying multiple route reflectors enhances the scalability of the RFC 2547bis model because it eliminates the need for any single network component to maintain all VPN routes. Finally, P routers function as MPLS transit LSRs when forwarding VPN data traffic between PE routers. Since traffic is forwarded across the MPLS backbone using a two layer label stack, P routers are only required to maintain routes to the provider s PE routers; they are not required to maintain specific VPN routing information for each customer site. 5.1.2 BGP/MPLS VPN operation control and data flows A BGP/MPLS VPN uses two main traffic flows to operate, the control flow and the data flow. The control flow is used to distribute VPN routes and to establish label switched paths (LSP), while the data flow is used to forward customer data traffic. The control flow is responsible for Œ the distribution of routing information between the and PE routers at the edge of the provider s backbone and between the PE routers across the provider s backbone; Œ the establishment of LSPs across the provider s backbone between PE routers. Distribution of Routing Information Each PE is configured to associate a VRF with each interface or subinterface over which it learns routes from each, which is connected to the PE. When the advertises a route for a certain prefix to the PE, PE installs a local route in the corresponding VRF. The PE then advertises the route for this prefix to all other PEs (which connect sites that participate into the VPN) using IBGP. Before advertising the route, the PE selects an MPLS label to advertise with the route and assigns its loopback address as the BGP next hop for the route. RFC 2547bis supports overlapping address spaces by the use of route distinguishers (RDs) and the VPN-IPv4 address family. RFC 2547bis constrains the distribution of routing information among PE routers by the use of route filtering based on BGP extended community attributes (route targets). When a PE receives a route advertisement from another PE, it determines if it should install the route into a particular VRF by performing route filtering based on the BGP extended community attributes carried with the route. If the route is installed in the VRF, the PE then advertises the route to the associated. LSP Establishment In order to use MPLS to forward VPN traffic across the provider s backbone, LSPs must be established between the PE routers. LSPs are established and maintained across the service provider s network using either Label Distribution Protocol (LDP) or one that supports traffic engineering like Resource Reservation Protocol (RSVP). The provider uses LDP to establish a best-effort LSP between two PE routers. The provider uses RSVP to either assign bandwidth to the LSP or use traffic engineering to select an explicit path for the LSP. RSVP-based LSPs support specific quality of service (QoS) guarantees and/or specific traffic engineering objectives. There can be a single LSP or several parallel LSPs (perhaps with different QoS capabilities) established between PE routers. Also, a route reflector simply acts as server that reflects routes from an ingress PE router to egress PE routers. If a provider uses route reflection, it is still required to establish LSPs between PE routers because route reflectors are not necessarily part of the transit path between PE routers. 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) EURESCOM Project Report The data flow forwards data traffic across the service provider s backbone from one customer site to another customer site. 5.1.3 BGP/MPLS VPN operational issues Several mechanisms are used in RFC 2547bis to enhance the scalability of the approach and solve specific VPN operational issues, which include the following: Supporting overlapping customer address spaces Constraining network connectivity Maintaining updated VPN routing information Saving backbone bandwidth and PE router processing resources Overlapping Customer Address Spaces In Customer networks that do not use globally unique IP addresses (e.g. RFC 1918 private addresses [RFC1918]), the same IPv4 address can be used to identify different systems in different VPNs which result to routing difficulties because BGP assumes that each IPv4 address it carries is globally unique. This problem is solved in BGP/MPLS VPNs with the support a mechanism that converts non-unique IP addresses into globally unique addresses using the VPN-IPv4 address family together with the Multiprotocol BGP Extensions (MP-BGP). In order to allow the installation of completely different routes to the same IPv4 address, one for each VPN, RFC 2547bis defines the VPN-IPv4 address family. A VPN-IPv4 address is a 12-byte quantity composed of an 8-byte Route Distinguisher (RD) followed by a 4-byte IPv4 address prefix. The 8-byte RD is composed of a 2-byte Type field and a 6-byte Value field. The Type field determines the lengths of the Value field s two subfields (Administrator and Assigned Number), as well as the semantics of the Administrator field. When configuring RDs on PE routers, RFC 2547bis does not require that all the routes within a VPN use the same RD, and in fact each VRF within a VPN can use its own RD. However, the service provider must ensure that each RD is globally unique. The use of the public ASN space or the public IP address space guarantees that each RD is globally unique. Globally unique RDs provide a mechanism that allows each service provider to administer its own address space and create globally unique VPN-IPv4 addresses without conflicting with the RD assignments made by other service providers. Conventional BGP4 was originally designed to carry routing information only for the IPv4 address family. Realizing this limitation, the IETF is working to standardize the Multiprotocol Extensions for BGP4. These extensions were originally defined in [RFC2283] and later updated in [RFC2858]. The extensions allow BGP4 to carry routing information for multiple Network Layer protocols (IPv6, IPX, VPN-IPv4, etc.). Therefore, to deploy BGP/MPLS VPNs and support the distribution of VPN-IPv4 routes, PE routers are required to support the MP-BGP extensions and not just conventional BGP. Before exchanging VPN-IPv4 routing information, RFC 2547bis requires that BGP capabilities negotiation takes place to ensure that the BGP peers are both capable of processing the VPN-IPv4 address family. Constraining Network Connectivity By constraining the flow of routing information, service providers can efficiently control the flow of customer VPN data traffic. The BGP/MPLS VPN model constrains the flow of routing information using two mechanisms: multiple forwarding tables and BGP extended community attributes. a. Multiple Forwarding Tables Each PE router holds one or more per-site forwarding tables known as VRFs. A PE router is configured in a such way that each of its VRFs is associated with one or more interfaces (subinterfaces) on the PE router that connects directly to the service provider s customers. If a given site contains hosts that are members of multiple VPNs, the VRF associated with the customer site contains routes for all VPNs of which the site is a member. EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 33 (70) When receiving an outbound customer data packet from a directly attached router, the PE router performs a route lookup in the VRF that is associated with that site. The specific VRF is determined by the subinterface over which the data packet is received. Support for multiple forwarding tables makes it easy for the PE router to provide the per-vpn segregation of routing information. b. BGP Extended Community Attributes The VPN routing information is distributed through the use of BGP extended community attributes. Extended community attributes are carried in BGP messages as attributes of the route. They identify the route as belonging to a specific collection of routes, all of which are treated the same with respect to routing policy. Each BGP extended community must be globally unique (contains either a public IP address or ASN) and can be used by only one VPN. However, a given customer VPN can participate in multiple globally unique BGP extended communities to help control the distribution of routing information. BGP/MPLS VPNs use 32- bit BGP extended community attributes instead of conventional 16-bit BGP community attributes. Since each community attribute contains the provider s globally unique autonomous system (AS) number, the service provider can control local assignment while also maintaining the global uniqueness of that assignment. RFC 2547bis VPNs can use up to three different types of BGP extended community attributes. The route target attribute identifies a collection of sites (VRFs) to which a PE router distributes routes. A PE router uses this attribute to constrain the import of remote routes into its VRFs. The VPN-of-origin attribute identifies a collection of sites and establishes the associated route as coming from one of the sites in that set. The site-of-origin attribute identifies the specific site from which a PE router learns a route. It is encoded as a route origin extended community attribute, which can be used to prevent routing loops. Local routes are distributed to other PE routers after the ingress PE router attaches a route target attribute to each route learned from directly connected sites. The route target is based on the value of the VRFs configured export target policy. The ingress PE router can be configured to assign a single route target attribute to all routes learned from a given site or one route target attribute to a set of routes learned from a site and other route target attributes to other sets of routes learned from a site. Before installing remote routes that have been distributed by another PE router, each VRF on an egress PE router is configured with an import target policy. A PE router can only install a VPN-IPv4 route in a VRF if the route target attribute carried with the route matches one of the PE router VRFs import targets. This approach allows a service provider to use a single mechanism to support VPN customers that have a wide range of inter-site connectivity policies. By careful configuration of export target and import target policies, service providers can construct different types of VPN topologies. The mechanisms that implement the VPN topologies can be completely restricted to the service provider so VPN customers are not aware of this process. A VPN can be configured in a mesh topology or in a hub-and-spoke topology. In the mesh topology a single globally unique route target is configured for each VRF as both the import target and the export target. In a hub and spoke topology two globally unique route target values, hub and spoke, are created. The hub site s VRF is configured with an export target = hub and an import target = spoke. The VRF at the hub site distributes all of the routes in its VRF with a hub attribute that causes the routes to be imported by the spoke sites. The VRF at the hub site imports all remote routes with a spoke attribute. The VRF at each spoke site is configured with an export target = spoke and an import target = hub. The VRF at each spoke site distributes its routes with a spoke attribute, which causes the routes to be imported by the hub site, but dropped by other spoke sites. The VRF, at a spoke site, imports only routes with a hub attribute, which causes its VRF to be populated only with routes advertised by the hub site. Maintaining Updated VPN Routing Information Changes in the configuration of a PE router (i.e. creating a new VRF or by adding one or more new import target policies to an existing VRF) may require the PE router to obtain VPN-IPv4 routes 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) EURESCOM Project Report that it previously discarded. The speed of delivering updated routing information can present a problem with conventional BGP4 because it does not support the exchange of route refresh request messages and the subsequent re-advertisement of routes. A solution to this design feature is provided by the BGP route refresh capability. During the establishment of an MP-IBGP session, a BGP speaker that wants to receive a route refresh message from its peer or route reflector advertises the BGP route refresh capability using a BGP capability advertisement. The BGP route refresh capability states that a BGP speaker can send a route refresh message to a peer or route reflector only if it has received a route refresh capabilities advertisement from that peer or route reflector. Whenever the configuration of a PE router is changed, the PE router can request the retransmission of routing information from its MP-IBGP peers to obtain routing information it previously discarded. When the routes are re-advertised, the updated import target policy is applied as the PE router populates its VRFs. Saving Backbone Bandwidth and PE Router Processing Resources In the process of populating the VRFs, a BGP speaker often receives and then filters unwanted routes from peers based on each VRF s import target policy. Since the generation, transmission, and processing of routing updates consumes backbone bandwidth and router packet processing resources. Minimizing the transmission of unnecessary routing updates the bandwidth can be conserved. This can be achieved by enabling the new BGP co-operative route filtering capability. During the establishment of the MP-IBGP session, a BGP speaker that wants to send or receive outbound route filters (ORFs) to or from its peer or route reflector advertises the co-operative route filtering capability using a BGP capabilities advertisement. The BGP speaker sends its peer a set of ORFs that are expressed in terms of BGP communities. The ORF entries are carried in BGP route refresh messages. The peer applies the received ORFs in addition to its locally configured export target policy, to constrain and filter outbound routing updates to the BGP speaker. 5.2 Virtual router IPVPNs 5.2.1 The VR concept The virtual router (VR) concept is functionally equivalent to a physical router: it must support exactly the same mechanisms and tools and should appear for all purposes (configuration, management, monitoring and troubleshooting) like a dedicated physical router. Each virtual router has its own separate set of IP interfaces, forwarding table and instances of routing protocols. Any routing protocol can be used, and no modification or extension is needed to the standard routing protocols (e.g. RIP, OSPF, IS-IS, and BGP). Figure 11 compares the concepts of virtual router and physical router. VR 1 VR 2 VR 3 VR 1 VR 2 VR 3 Router A Router B Figure 11 Virtual router (VR) vs. physical router A major application of VRs is IPVPNs. Since, from the VPN user point of view, a virtual router provides the same functionality as a physical router, separate routing and forwarding capabilities are able to guarantee isolation from other VPN traffic while running on shared network resources. A VR-based VPN can be created by assigning interfaces that are attached to the VPN customer sites and establishing a connection (e.g. ATM VC, Frame Relay DLCI) to another system that also EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 35 (70) supports customers of the same VPN. Isolation of VPN routing tables enables the overlapping of address spaces by different VPNs. Simplicity is a major advantage of VR-based VPNs. Because a VR is in principle capable of running any standard protocol, interoperability between different vendors, and between VRs and conventional routers, is not an issue. The price to pay for this simplicity is the need to create an independent VR in each router for each VPN that it supports, which may represent a strong scalability limitation. This limitation can be overcome by restricting the establishment of VRs to the network edge and interconnecting these VRs through the network core, as shown in Figure 12. PE VR VR VR P P P P PE VR VR VR 5.2.2 VR VPN implementations Figure 12 - VR VPN reference model Vendors such as Lucent and Nortel have developed VPN architectures based on this concept. A VPN is created by interconnecting VRs located in PE routers through tunnels through the service provider core network (usually, MPLS tunnels, although any other tunnelling mechanism could be used). These tunnels may be configured either statically or dynamically. Presently there are two IETF Drafts that specify VR VPNs: Network based IP VPN Architecture using Virtual Routers [draft-ipvpn-arch-vr] and A Core MPLS IP VPN Architecture [draft-coreipvpn]. The tunnels between PEs may be configured in several different ways. One of the alternatives is the direct connectivity between VRs, as shown in Figure 13. PE VR PE VR VR Tunnels VR VR VR Figure 13 VR VPN with direct connectivity between VRs An alternative approach (proposed in [draft-ipvpn-arch-vr]), is based on the utilisation of a single backbone VR to interconnect all the VRs from two PEs, as shown in Figure 14. The backbone VR connects each PE to a shared backbone infrastructure, allowing the aggregation of VRs from multiple VPNs and improving the scalability of the solution. 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) EURESCOM Project Report PE VR PE VR VR Tunnel VR VR VR Figure 14 VR VPN with a backbone VR 5.2.3 VPN auto-discovery VPN membership information refers to the set of PEs that have customers in a particular VPN. Auto-discovery of VPN members is an essential component of a VPN solution. In order to establish VPN-specific connectivity, the VRs belonging to a given VPN, physically located in several PE routers, need to learn about each other. Because a solution based on manual configuration is not scalable, an auto-discovery mechanism is required. Contrary to RFC2547 VPNs, in which a single auto-discovery mechanism is possible (through MP- BGP), several VPN discovery approaches can be implemented in VR VPNs: Œ Directory servers (VRs query a server to determine their neighbours); Œ Configuration through a management platform; Œ Distributing VPN membership and topology information with BGP; Œ Multicast. It should be noted that a single PE may accommodate several different mechanisms for different VPNs. The two last options from the list above (BGP and multicast) are currently the most relevant approaches. The draft [draft-bgpvpn-auto] defines a BGP-based auto-discovery mechanism, which can be used by layer 2 and layer 3 VPN architectures, similar to the approached used by RFC2547 VPNs for distributing VPN routing information within the service provider backbone. BGP multiprotocol extensions are used to carry information about VPNs for both layer 2 and layer 3 VPN architectures. An alternative solution for VPN auto-discovery, based on IP multicast, is presented in [draft-vpndisc]. This solution uses dynamic ARP to discover the neighbour VR s PE address, and link broadcast is achieved using encapsulation of VPN link broadcast packets in the multicast address assigned to the VPN. The virtual router approach specified in [draft-ipvpn-arch-vr] assumes a mechanism that provides services similar to BGP to achieve auto-discovery of VPN members through automatic exchange of VPN control information between VRs. However, unlike the RFC2547 VPNs, BGP is not used to include VPN information in the BGP routing process. The draft [draft-core-ipvpn] does not recommend any auto-discovery method explicitly, but it is mainly associated with the multicast approach. 5.3 MPLS-based Layer 2 VPNs Traditionally, the most common way for companies to build their own wide area networks is to set up a layer 3 infrastructure on top of a number of point-to-point links (based on leased lines or virtual circuits) provided by a service provider. This model corresponds to what is usually known as layer 2 VPN (also known as L2 VPN ). EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 37 (70) Although layer 2 VPNs based on ATM or Frame Relay have been extensively deployed, several drawbacks related to this kind of VPN can be identified. First, the service provider VPN infrastructure is dependent on a single layer 2 technology (e.g., ATM, Frame Relay). In addition, the Internet infrastructure and the VPN infrastructure, even if they share the same physical network, need separate administration and maintenance. Finally, provisioning is difficult - for example, adding a site to an existing VPN is usually a complex task. Migration to layer 3 VPNs has often been the solution followed by service providers. However, there are many cases where customers would prefer to keep their present layer 2 VPN service (for example, because they would like to avoid a complex migration process). In the cases where a service provider intends to offer both layer 2 and layer 3 VPN services, an MPLS-based layer 2 VPN allows the use of a single MPLS-based network infrastructure to offer a wide range of services, including IP traffic, layer 2 VPNs, layer 3 VPNs (e.g. RFC2547-based), MPLS traffic engineering and Diffserv-based QoS control. Easy migration from traditional layer 2 VPNs is a significant advantage of this model, as the two VPN types are indistinguishable from the customer s point of view. Basically, in an MPLS-based Layer 2 VPN the service provider uses an MPLS network to provide layer 2 services to the customer. From the customer s point of view, a layer 2 MPLS VPN is exactly the same as a layer 2 VPN, with layer 2 circuits interconnecting the various sites. For example, a customer device may be configured with a DLCI on which to transmit to other s through the provider network, which appears as a traditional layer 2 cloud to the customer. Within the service provider network, the layer 2 packets are transported in MPLS LSPs. The service provider does not participate in the customer's Layer 3 network routing. The establishment of emulated VCs, also called Virtual Leased Lines (VLL), or layer 2 point-topoint connectivity across an MPLS backbone is specified in the IETF drafts usually known as drafts martini [draft-martini] and [draft-martini2]. These drafts define how MPLS can be used to support Layer 2 protocols such as Ethernet, Frame Relay or ATM. [draft-martini] concentrates on encapsulation methods, while [draft-martini2] specifies signalling to set up point-to-point layer 2 circuits over an MPLS network. Figure 15 represents an example of an MPLS-based layer 2 VPN [kompella]. The connection between two customer s devices is composed of three segments: two -PE attachment VCs and one emulated VC in the core. The routing tables of the source router and the ingress and egress PE routers are indicated. Basically, the first router forwards the traffic to DLCIs 600 and 610 to sites B and C respectively, as in a normal Frame Relay network, whereas the ingress and egress PE routers perform the mapping between the DLCIs and the appropriate LSPs. In LSP 1 Out DLCI 605 VPN site B 10.0.0.0 VPN site A DLCI 605 Source DLCI 600 DLCI 610 LSP 2 LSP 1 DLCI 608 VPN site C 20.0.0.0 In Out 10/8 20/8 DLCI 600 DLCI 610 In DLCI 600 Out LSP 1 In LSP 2 Out DLCI 608 DLCI 610 LSP 2 Figure 15 MPLS-based Layer 2 VPN It should be noted that MPLS layer 2 VPNs make provisioning much easier in comparison to conventional layer 2 VPNs. In particular, adding a site to an existing VPN should simply require 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) EURESCOM Project Report the configuration of the PE router connected to the new site, and not the reconfiguration of a high number of s. The IETF draft An architecture for L2VPNs [draft-rosen-l2vpn], proposes a layer 2 VPN solution, which is based on the emulation of layer 2 circuits. In the service provider core, tunnels are established using a proper tunnelling technology (usually MPLS, but L2TP or IPsec should also be possible) to emulate layer 2 VCs. This draft can be seen as an evolution of a previous draft, called MPLS-based Layer 2 VPNs [draft-kompella] (now obsolete) which originally described how to build layer 2 -to- VPNs using MPLS in the provider core. [draft-rosen-l2vpn] is based on the drafts martini indicated above for encapsulation of data frames and for the signalling used to setup and maintain the emulated VCs. The need to specify an auto-discovery mechanism is indicated but no solution is proposed for the time being. Recently, the PPVPN IETF group has reutilize the VPLS concept (Virtual Private LAN Service, following a term originally defined in [RFC2764]) as a layer 2 service that emulates a LAN across a WAN [draft-andersson][draft-augustyn]. The basic purpose of a VPLS is to offer layer 2 connectivity to multiple customer sites in a manner that is transparent to the devices. The service provider is responsible for transporting customer Layer 2 frames and switching them across the service provider network between customer sites. From the customer s point of view the service is equivalent to connecting the devices via a switch, i.e., all in the same broadcast domain / LAN segment. In the light of this concept, a layer 2 VPN can now be one of two possible variants: Œ Œ VPLS (Virtual Private LAN Service), which corresponds to a VPN service that emulates a LAN; VPWS (i.e. Virtual Private Wire Service), which corresponds to a VPN service that supplies a layer 2 point-to-point service (as presented before in this section). 5.4 Experimentation and validation In the framework of P1107 an MPLS VPN experimentation activity was carried out. The basic objective was to validate some of the most typical VPN configurations and evaluate the main limitations and shortcomings in the VPN establishment mainly from a service provider s point of view. The tests were performed using BGP/MPLS VPN platforms at three different sites (Portugal, Greece, Hungary). The choice for this VPN model was based on two main reasons: it was easily available in a laboratory environment at the testing sites and corresponds to the most widely deployed Network-based VPN model (at least, based on the number of implementations from leading vendors). The diagrams on Figure 16, Figure 17 and Figure 18 show the testbed configuration on the three testing sites. The following areas have been tested: MPLS Traffic Engineering, including constraint-based Routing, explicit routes, tunnel preemption, affinity bits; MPLS VPN setup and control, including full-mesh, hub-and-spoke VPNs, multi-provider VPNs, routing (at the access and in the core); QoS in MPLS VPN (including QoS control with the pipe model, QoS control with the hose model, QoS control with Diffserv, Traffic engineering); Setup of VPDN configuration; Deployment of VoIP services over IPVPN infrastructure; MPLS VPN management and provisioning. EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

Pow er CI SCO SY STEMS Cisco AS5800SERI ES EURESCOM Project Report page 39 (70) By performing these tests, the basic BGP/MPLS VPN functionalities have been demonstrated and validated. The results of these tests can be found in PIR 2.3 Experimentations and deployment guidelines [PIR2.3] and Deliverable 3 QoS issues in IPVPNs [D3]. PT Comunicações, Lisboa 7500a 7500c 192.168.100.4 IT, Aveiro 7200c 192.168.100.11 PT Inovação, Aveiro 7200b 192.168.100.9 7500b 192.168.100.3 7200a 3600a 192.168.100.1 192.168.100.8 192.168.100.10 routers PE routers P routers PE routers routers MPLS domain Figure 16 PT BGP/MPLS VPN testbed %3;Ã &,6&2 %3;Ã &,6&2 SD $;'Ã (5,&6621 3ÃURXWHUV 0*;Ã &,6&2 0*;Ã &,6&2 5Ã &,6&2 5Ã &,6&2 3(ÃURXWHUV 5Ã &,6&2 5Ã &,6&2 5Ã &,6&2 5Ã &,6&2 &(ÃURXWHUV $6Ã $6Ã Figure 17 OG BGP/MPLS VPN testbed 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

Su n E\dbQÃ(17(535,6( E\dbQÃ(17(535,6( page 40 (70) EURESCOM Project Report 'UDJRQ Sun $O %DUW 7DQWDORV] 6XQ 3&Ã/LQX[ (QWHUSULVH $$$,06 $$$ 057* 6103 6HUYHU )DUP.XDOD 3( 0DQDJHPHQWÃ03/6 (WK 7XSROMHY (WK (WK 6]RMX] (WK (WK 0DGULG &DWDO\VWÃ /65 &( 6SHHG\Ã* 1$6Ã)DUP 5RPDÃ /65 /6& 03/6 39&Ã %XGD 3( 3( %2&,Ã%3; 3& 39&Ã '6/$0 3& 6LHPHQV ;SUHVVÃ/LQN'Ã 3& 3& Figure 18 Test environment used by HT for the VPDN experiments EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 41 (70) 6 QoS in IPVPNs Quality of service generally describes the assurance of sufficiently low delay or packet loss for certain types of applications or traffic. Traditional corporate networks were able to guarantee a fixed level of resources available in all conditions by using dedicated leased circuits. Layer 2 VPNs using Frame Relay and ATM technology have been used for some time and can provide comparable performance to private line solutions. Likewise, IPVPN service providers are expected to provide the same kind of QoS support. Two frameworks have been devised by the IETF as QoS architectures in IP-based networks: Integrated Services (IntServ) and Differentiated Services (DiffServ). MPLS, with traffic engineering and constraint-based routing, also provided new tools to manage and control QoS. 6.1 IntServ In the integrated services model [[RFC2211], [RFC2212]] the applications know the characteristics of their traffic and signal the intermediate network nodes to reserve certain resources to meet their traffic properties. According to the availability of resources, the network either reserves the resources and sends back a positive acknowledgment, or answers in the negative. This part of the standard is called Admissions Control. The signaling protocol used is called Resource reservation Protocol - RSVP. IntServ differentiates between the following categories of applications: 1. Elastic Applications that do not have delay or bandwidth requirements for delivery as long as packets reach their destination. Applications over TCP fall into this category since TCP does all the hard work of ensuring that packets are delivered e.g. web browsing and email. 2. Real Time Tolerant (RTT) Applications, they require weak bounds on the maximum delay over the network. Occasional packet loss is acceptable, e.g. video applications that use buffering, which hides the packet losses from the application. 3. Real Time Intolerant (RTI) Applications that demand minimal latency and jitter. e.g. videoconference. The above classes of applications are served by RSVP with the various mechanisms at the network elements in order to deliver the following classes of service: 1. Guaranteed Service: This service is meant for RTI applications. This service guarantees bandwidth for the application traffic deterministic upper bound on delay. 2. Controlled Load Service: This is meant to service the RTT traffic. The average delay is guaranteed, but the end-to-end delay experienced by some arbitrary packet cannot be determined deterministically. The main drawbacks of the Integrated services approach are inherited from the use of RSVP. RSVP assigns QoS with the granularity of single application's flows. Heavy signalling traffic is then needed to be exchanged between network elements belonging to a core area of the network, as they must serve a high number of flows and their reservation requests. In addition, after a reservation has been established, each network element must classify each incoming IP packet to determine whether it belongs to a QoS flow or not and, in the former case, to assign the needed resources to the flow. The IntServ classifier is based on a MultiField classification, because it checks five parameters in each IP packet (Source IP address, Destination IP address, Protocol ID, Source transport port, Destination transport port). Hence, the use of RSVP poses the scalability issues in the domain of signalling, classification and scheduling mechanisms. 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) 6.2 DiffServ EURESCOM Project Report DiffServ [RFC2475] is a method for providing QoS across a network through a set of mechanisms that can be used together in order to achieve an end-customer service. One of these key mechanisms is the Per Hop Behavior (PHB). DiffServ defines a number of data treatments, known as a PHB, that can be applied to the packets (all packets traveling through a link and requiring the same behavior form a Behavior Aggregate-BA) in each node. The PHB is used to identify the treatment that will be given to the packet within the node. This treatment includes selection of the queue and scheduling discipline to apply at the egress interface and congestion thresholds. The packets are marked to identify the treatment that the packets need using the DS byte. The DS byte replaces the TOS byte in the IP header. Within the DS byte, a DiffServ CodePoint (DSCP) field has been defined. The value in this field identifies the treatment to be applied to the packet within that node in the network. The DS byte contains 6 bits for the DSCP, plus 2 bits that are currently unused and reserved for the future. The 6 bits are used as an indexed table to identify the PHB. This allows for 64 independent codepoints. These are mapped in the node to determine the treatment to apply. Depending on this mapping, it is possible to have multiple codepoints selecting the same behavior, allowing local use of existing behaviors for different purposes. The defined PHBs are: Expedited Forwarding (EF) The EF PHB provides a low-loss, low-jitter, and low-delay within the node. To provide the low delay, the EF handling further defines that the maximum aggregated reception rate of data for this PHB at any time must be no greater than the minimum transmission rate available for this PHB per egress. This requirement ensures that there is no queue buildup occurring for this service within the node, which minimizes the delay and the delay variation. EF recommended codepoints can be seen in Figure 19. Figure 19 EF recommended code points Assured Forwarding (AF) The PHB group defines N independent forwarding classes (4 defined currently) denoted as AF1 to AFn. Within each of these forwarding classes, there are also M subclasses (3 defined currently)for probability of delivery. Each forwarding class within this group is configured independently for resources such as buffer space and minimum egress capacity that should be ensured by the scheduling mechanism. EF recommended codepoints can be seen in Figure 20. Figure 20 AF recommended codepoints Default Behavior (DE) The DE PHB identifies the existing best effort traffic. The behavior defines that the node will deliver as many of these packets as possible, as soon as possible. DE recommended codepoints are shown in Figure 21. Figure 21 DE recommended codepoints EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 43 (70) The DSCP identifies the treatment to be applied in each node. Within a DiffServ domain, the DSCP must be set in each packet for the nodes to determine the required treatment. Therefore, the node at the ingress edge of the DiffServ domain must ensure that this field is set appropriately in each packet. This is just part of the role of traffic conditioning. It has been noted that there can be other conditions applicable to the use of a PHB. For example, the EF PHB has a requirement that the egress capacity of a link for this class is greater than the traffic rate into ingress. Since the PHB definition can specify the admissible traffic profiles, the ingress node of the DiffServ domain actually provides more functions than simply marking the DS byte. All of the functions that are combined in the role of traffic conditioning are then examined in turn. Since the bearer service class is dependent on the individual Service Level Agreement (SLA), the traffic conditioning is performed independently for each logical access. 6.3 MPLS The Integrated Services architecture and the Differentiated Services architecture can be used for QoS services in an IP network but need some modifications to work on an MPLS architecture due to the use of labels. Two approaches have been proposed to the IEFT to overcome these problems: the Integrated Services across MPLS Domains using CR-LDP and the MPLS support of Differentiated services. 6.3.1 Integrated Services across MPLS domains using CR-LDP signaling An important consequence of the scalability problems posed in IntServ is that IntServ-level QoS can be provided only within peripheral areas of the network, preventing its extension inside core areas and the implementation of end-to-end QoS. The use of MPLS protocol in the core network alleviates some of the scalability issues since the CR-LDP protocol allows the definition of Label Switched Path (LSP) with QoS constraints performing QoS classification using a single valued label. The mechanisms proposed in this approach describe how end-to-end QoS is reached between MPLS domains and IntServ areas. In order to achieve this, the MPLS Ingress LSR acts like an MPLS/IntServ QoS gateway. The MPLS domain participates using its native CR-LDP messages, to obtain a level of service inside the domain comparable with the IntServ QoS requested by RSVP applications. After the receipt of an RSVP message, which reserves resources, the Ingress LSR establishes a CR-LSP (Constraint Routed LSP) towards the Egress LSRs. The values of the Traffic Parameters (i.e. QoS parameters associated to the CR-LSP) are derived from the corresponding Resv message. The RSVP sender s traffic crosses the MPLS domain using this CR-LSP. The Ingress LSR is responsible for performing the message translation to create this CR-LSP. LSRs that are not on the edge of the MPLS domains will only process CR-LDP messages. Although the above method can be used to alleviate some of the scalability problems of IntServ, the better synergy of Differentiated services method with MPLS it seems that has more change to prevail in the core network. 6.3.2 MPLS and DiffServ An LSP may be associated with QoS properties, which need to be enforced by QoS mechanisms in LSRs via other, non-mpls means. The main requirement for MPLS to support DiffServ is to ensure that packets get the appropriate QoS treatment by each LSR in the network. However, since the LSR by definition does not inspect the IP header, it is necessary to provide the DSCP information through the label header. This can be achieved in two ways. If all MPLS packets in an LSP always belong to a single DiffServ forwarding class, there is no need to indicate the forwarding class of each packet in the Exp field of the MPLS header, because it can be derived from the label information. This LSP type is called L-LSP (Label-Only-Inferred-PSC LSP). On the contrary, if the MPLS packets that are sent along an LSP may belong to more than one DiffServ forwarding class, the service class of each packet (along with the possible drop precedence) needs to be indicated in the 3-bit Exp field of the MPLS packet header. This LSP type is called E-LSP (EXP-inferred-PSC LSP). Each MPLS packet of an E-LSP is assigned forwarding resources at each hop from the aggregate that corresponds to the service class information in the MPLS packet 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) EURESCOM Project Report header. The mapping from Exp field to PHB (i.e. to PSC and drop precedence) for an E-LSP, is either explicitly signalled at label set-up or pre-configured [draft-ganty]. PHB1 + PHB2 E-LSP PHB1 L-LSP (PHB2) PHB2 L-LSP (PHB1) Figure 22 E-LSP vs. L-LSP DiffServ MPLS approaches E-LSP and L-LSP may be established with or without bandwidth reservation. Establishing an E- LSP or L-LSP with bandwidth reservation means that bandwidth requirements for the LSP are signalled at the LSP establishment time. Such signalled bandwidth requirements may be used at establishment time by LSRs to perform admission control depending on the DiffServ resources provisioned. Extended label distribution protocols such as CR-LDP or RSVP-TE can be used to establish LSPs with reserved resources. In order to use QoS policies for the MPLS VPNs the Pipe Model and the Uniform, the two models for DiffServ tunneling over IP Tunnels are applicable to DiffServ over MPLS. 6.3.3 DiffServ-aware Traffic Engineering (DS-TE ) Traffic engineering allows network designs that fully and efficiently utilize network links and network elements resources to carry customer traffic and avoid routing congestion points and resulting unpredictable network performance. DiffServ mechanisms may be work in parallel with existing MPLS Traffic Engineering mechanisms in some networks, where some optimization of transmission resources is sought. This combination gives a new spot in the QoS spectrum, as it is presented in Figure 23: No state Best effort Aggregated state DiffServ MPLS DiffServ + MPLS DS-TE MPLS guaranteed bandwidth Per-flow state RSVP v1/ Intserv Figure 23 QoS spectrum These Traffic Engineering mechanisms operate on an aggregate basis across all DiffServ Behavior Aggregates. DiffServ and MPLS TE both provides their respective benefits i.e. DiffServ performs service differentiation at every hop and Traffic Engineering achieves better distribution of the aggregate traffic load across the set of network resources. There exists a need in some networks for fine optimization of transmission resources. In such cases the use of traffic engineering on a perclass level may further enhance networks in performance and efficiency. In DiffServ-aware Traffic Engineering (DS-TE) approach a traffic trunk in a given class is mapped on a separate LSP. The traffic trunk can utilize resources available to the given class on both shortest path(s) and nonshortest paths and follow paths that meet specific constraints to the given class. DiffServ-aware Traffic Engineering (DS-TE) not only allows the configuration of a global pool for bandwidth accounting, it also provides a restrictive sub-pool configuration that may be used for high-priority network traffic such as voice or other applications. Available bandwidth both on the global pool and in the sub-pool are advertised by IGP, ensuring each router keeps track of the available bandwidth when admitting new LSPs for voice or high-priority traffic. In this manner, service providers, depending on their service level agreement requirement, can choose to overbook lower-priority classes or even underbook higher-priority traffic to meet tight QoS requirements. EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 45 (70) DiffServ-aware TE extends MPLS TE to perform constraint-based routing (path computation) on a specific (restrictive) set of sub-pools where bandwidth is dedicated to the high-priority traffics. This ability to satisfy a more restrictive bandwidth constraint translates into the capability to achieve higher QoS (in terms of delay, jitter or loss) for the traffic using the sub-pool. DS-TE involves extending OSPF and IS-IS so that the available sub-pool bandwidth at each preemption level is advertised in addition to the available global pool bandwidth at each pre-emption level. Further, DS-TE modifies constrained based routing to take this more complex advertised information into account, during path computation. A typical use for DS-TE would be for toll bypass/voice trunking or leased line services emulation, where a point-to-point guarantee is needed in term of bandwidth/delay and jitter bounds. 6.3.4 QoS in MPLS VPNs Traditional VPNs based on layer 2 technologies or leased lines offer a minimum guaranteed QoS level, expressed by parameters such as CIR (in the case of Frame Relay), CBR and SCR (in the case of ATM), or the circuit bandwidth (in the case of leased lines). Of course, in the case of MPLS VPNs users should expect similar QoS guarantees. There are two basic QoS control approaches in MPLS VPNs the pipe model and the hose model. The hose model is based on two parameters defined for each /PE interface the ICR (Ingress Committed Rate) and ECR (Egress Committed Rate). These two parameters specify the traffic that each router is able to transmit/receive to/from the other VPN sites. Figure 24 shows an example of the Hose model. In this case, the router connected to site 1 is able to receive up to 512 kbit/s from other sites of the same VPN, and transmit up to 256 kbit/s. It should be noted that these values are not dependent on the traffic distribution among the remote sites [Davie] for example, site 1 is allowed to send 256 kbit/s to site 2 in a specific time interval, as long as it does not send any traffic to site 3 in the same interval. QoS control in the MPLS core may be performed by means of DiffServ, as described in section 6.3.2. In this case, the basic hose model approach can be applied separately for each class of service. Site 3 ICR 512k PE PE ECR 512K MPLS ICR 256k Site 1 PE ECR 512K ICR 768k PE ECR 512K Site 2 ECR Egress Committed Rate ICR Ingress Committed Rate Figure 24 Hose model From the customer viewpoint, an advantage of the hose model is that it does not require a detailed knowledge of the traffic distribution between the VPN sites, which makes the implementation simple. The alternative to the hose model is the pipe model. It consists of providing QoS guarantees, for example minimum bandwidth, between each pair of routers. Guaranteed bandwidth LSPs between PEs can be used to support the pipe model. One guaranteed bandwidth LSP can be 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) EURESCOM Project Report established for each pair of s but, for scalability reasons, a single LSP should be used to support multiple - pipes. The pipe model inherits the basic QoS approach used in traditional ATM or Frame Relay VPNs (apart from the fact that the pipe model is unidirectional, whereas in ATM or Frame Relay the connection is normally defined as bi-directional). In the example shown in Figure 25 the two connections site 3 - site 1 and site 3 - site 2 are provided 5 Mbit/s and 7 Mbit/s, respectively. Again, the pipe model can be applied to a number of classes of service, possibly using DS-TE mechanisms, as explained in section 6.3.3. Site 3 PE To Site 2: 7 Mbit/s PE To Site 1: 5 Mbit/s PE MPLS PE Site 1 Site 2 Figure 25 Pipe model For an MPLS VPN customer migrating from an ATM or Frame Relay VPN, the pipe model is probably the easiest approach as it emulates the same kind of QoS control. A disadvantage of this model is the need to specify a specific bandwidth for each pair of VPN sites, which requires a detailed knowledge of the VPN traffic matrix. Of course, there is not a single solution that fits all the requirements. In practice, the combined implementation of both models may be the most appropriate solution. EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 47 (70) 7 Management of IPVPNs Based on the latest version of the IETF document [draft-requirements], using the ITU-T inputs from [Y.1311], the functional capabilities considered also as management support service component for IPVPN provisioning are discussed at first. In order to outline recommendations on implementing QoS management, this is followed by an overview of relevant management aspects according to the related TMN concept. Finally, based on the recently developed versions of QoS and management models from international project results, the IP carrier platform and VPN specific management architecture variants are shown. 7.1 QoS management needs VPNs are usually secured private network connections built on top of a publicly accessible infrastructure, such as the Internet or the public telephone network. Therefore, ideally, a VPN should behave similarly to a private network; it should be secure, highly available and have predictable performance. Traditionally, according to the TMN model, the management aspects of the network were treated separately from the control aspects. Management purpose functional capabilities has been often implemented as an overlay layer that was performing typical FCAPS tasks, mostly not in real time. Currently, this clear separation between the control plane and the management plane and to implement the MFAs separately is not so obvious. Certain network management issues have already been embedded in (higher layer) protocols and the trend is to invest more and more in service management and to develop sophisticated management mechanisms to automate certain procedures and reduce as much as possible the time to market. One of the keys issues for the success of a VPN solution is QoS. The combination of both VPN and QoS will lead to highly competitive products. Therefore, both VPN and QoS must be managed in an integrated manner no matter which architecture is chosen for the VPN or which technology is supporting the QoS. IPVPN services represent a good opportunity for service providers to realise new and more revenues. Service providers who can offer customised, rapidly deployed, and manageable IPVPN services will gain competitive advantage. The key to success and ultimate profitability of IPVPN services goes beyond simply the enabling technology. Equally important is service manageability and the management of the entire life cycle of service: planning, provisioning, monitoring, operations, and billing. Generic guidelines given by the TeleManagement Forum documents on the management processes and defining the related building blocks to be implemented (see:[gib910],[gib917]) are also applicable for the IPVPNs. Service management depends on the management of the underlying network infrastructure and on the provisioning of interfaces to data and mechanisms that drive the provider s overall business process [QoSRef2]. Service providers are not competing any more on price but on delivery time. Therefore, the key to profitably deploying VPN service is management. Following the ITU-T Recommendations, the following QoS related VPN service support and management capabilities should be implemented: 7.1.1 Generic QoS management capabilities for IPVPN provisioning Means to support a variety of user s traffic (QoS) requirements as defined by the user; Means to offer, support and maintain agreed levels of service (e.g. via Service Level Agreements); Provision of appropriate VPN management services (e.g. configuration, fault, performance, security, etc). Any FCAPS should be compared against the SLA. Any violation of QoS and SLA should be automatically detected. Provision of performance information, statistics, etc; meaning activation of monitoring mechanisms and metrics appropriate to SLA and QoS requirements; Analysis of QoS information (e.g. bandwidth, response time, availability, packet loss, etc); Prediction of trends, likely problems and/or recommendations in relation to current SLAs, traffic patterns, QoS, etc. 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) 7.1.2 QoS management for Service Level Agreements EURESCOM Project Report There are management capabilities to be fixed in the SLAs, to be formulated per VPN and/or per VPN site, and/or per VPN route. The SLA management is to be based on: Service Level Objectives comprising some or all of: IP Transfer Capability, QoS parameters, Availability, Reliability, Delivery confirmation, Mobility and Portability support, Security, Bandwidth, Priority, Authentication, Protocols supported, Flexibility - scaling and connectivity, Life of the SLA. Service monitoring objectives: QoS monitoring comparison against objectives, Flow tracking, Reports as necessary, Financial compensation objectives, Billing option, Penalties, Pricing, Early termination charges. QoS management aims to ensure that critical traffic has acceptable performance. However, there are two, contradictory assumptions: i) In the real world where the bandwidth is limited and the resources are scarce, QoS becomes a vital tool to ensure that all the application coexist and function at acceptable levels of performance, ii) In the real world, resources and bandwidth are abundant. Providers are making decisions, e.g., based on return of investment (ROI) calculations, comparing the profitability of capacity (bandwidth) over-dimensioning or to add new QoS systems. 7.1.3 QoS management features to be implemented Users normally do not care about the network topology or the high level of security or even the specific technology or protocol that support the VPN they are using. They usually care about acceptable response time when they access their application from a remote site and quality enough when they are using the services. Service providers must be able to deliver end-to-end SLAs and guarantee QoS. As part of their VPNs, service providers may wish to offer premium services defined by SLAs. QoS in IP networks gives devices the intelligence to preferably handle traffic as dictated by the network policy. According to the separation of the service level and the network level, the required management features can be divided into two groups. At the service level, QoS management applications should provide at least the following functionality (QoS management techniques): VPN Automated Service Provisioning According to the customer demands, connectivity requests should be fulfilled quickly and QoS should be guaranteed. QoS management tools, solutions should allow to create VPNs to support selectable CoS profiles, providing VPN specific SLA and performance reports, etc. Performance Monitoring It should be possible to get traffic information from the network and aggregate it from various perspectives and at different time intervals. It should be possible to define how QoS metrics map into service-level performance parameters in order to be presented to customers. SLA attributes, such as delay, availability, throughput, jitter, should be monitored and aggregated at different levels. Standard IP packet transfer performance parameters and QoS classes are defined in [Y.1540] and [Y.1541]. Customer Service Management Customers should be provided with management services such as: self-provisioning, performance monitoring and reporting, QoS configuration services, scheduling reports of SLA conformance, etc. At the network level, the following QoS management techniques should be considered: Packet classification Aims to group packets based on predefined criteria so that the resulting groups of packets can be subjected to specific packet treatments. Criteria to classify traffic before it enters the VPN covers IP addresses, URL, MAC addresses, TCP/UDP port numbers, IP precedence, or scheduling in time. Packet Marking/ Colouring After classification, packets should be marked with a single id in order to ensure that classification is respected end to end (using IP ToS field, DSCP, ) EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 49 (70) Bandwidth Management After traffic is classified, it should be ensured that it receives proper treatment (scheduling and queuing) in the routers. Traffic Shaping This technique is used to smooth traffic streams. Token Bucket shaper can be used to prevent bursty traffic and also to reduce traffic peaks. Instead of using feature of the PE routers, shaper devices may be implemented per site, between and PE, by the customers, too. Congestion Avoidance Shaping in every instance might result in very long queues in edge routers, thus policing/dropping of packets from flows generated by non-critical applications is also a possible solution under higher loads to avoid congestion. Random Early Detection (RED) provides treatment of traffic by adding per-class queue thresholds to determine the drop probability of a packet. Weighted RED (WRED) (called also weighted random early discard technique) is an implementation variant of the RED algorithm which allows differential treatment of traffic, dropping at first packets with low priority (based on drop precedence marking). 7.2 Applicable management concepts and recommended models In order to provide the proofs of proper and managed VPN service delivery, the critical issues for consideration of network operator(s) and transport service provider(s) are the following: a) To implement usage metering tools, resource usage efficiency measurements, and all the types of measurement access points, interfaces which allow to obtain relevant data from measurement results (solutions are however platform and network technology dependent, and might be proprietary). b) To select and implement appropriate data acquisition, administration, documentation, data handling tools, rules and solutions. Required resources and features cover the data handling and storage capabilities, as well as data transformation, data processing means. Standard MIB is to be applied. Management and operation support database systems should be integrated or have to be interoperable to avoid duplication of data. c) To introduce network element related fault management. To implement event logging and status monitoring capabilities, with selectable alarm levels for alarm indication signalling. Integration of the fault reporting and trouble ticketing processes and systems is recommended. d) To support automation in configuration management. The main provider concept based IPVPN service delivery model is recommended, which allows negotiations on the site topology and related traffic forecasts (capacity, types of payload to be transferred), and on demand changes in resource reservation integrated customer care & order handling interface(s) of the PPVPN service provider s delivery support system (e.g., by integrating the customer care, SLA and configurations management support centres). e) To apply properly selected performance monitoring tools, standard performance measurement solutions, and evaluation schemes in performance management. Parameters, metrics, objectives, thresholds are to be selected from SLAs of typical products, and agreed with relevant user groups. Statistical evaluation is also needed. Information exchange and reporting templates are to be harmonised, especially for multi-provisioning (co-operative management). f) To implement standard based support systems for authentication, authorisation and accounting management purposes. To apply standard based security architecture, to implement the capability of provisioning security audits, and proofs of the ability to prevent fraud. By the IETF [draft-requirements], there are three possible options to deploy the VPN management systems and QoS support systems for VPN service delivery: it is possible to use a call-centre model for customer control 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) EURESCOM Project Report to deploy custom-made and often proprietary management systems and control, monitoring implementation solutions for the management of the IPVPN provisioning (dedicated, often multi-service) backbone and the VPN service delivery to implement standard, and also policy-based VPN management solutions, based on interoperator management interface & process specifications, interworking solutions. 7.2.1 Policy based management with a layered functional architecture The IETF policy based QoS architecture model contains four functional areas: configuration; network element; policy engine; and billing. This approach allows the implementation of especially scalable and flexible management processes, together with supporting of usage based and QoS charging (other ways: authentication, authorisation and accounting management). Documents of IETF policing framework are [RFC2251], [RFC2940], [RFC3060], [RFC3084], [draft-mahon], [draft-policy-req]. Such a management functional architecture model is presented within the still running 3GPP UMTS project, and it is considered for supporting end-to-end QoS control and SLA management, with traffic control and congestion control in IP based networks also by ITU-T SG13 and SG4. This approach allows offering the practically real time presentation of different views also for the customers, filtering management data per VPN basis, and taking into account also the required security requirements. In general it is also compliant with the new charging model introduced by ETSI NA (Network Aspects), developed to be applicable also for business to business (provider to provider, wholesale) type, and IP network based services. The tailored variant of the policy based management model, with standard protocols, is shown in Figure 26, as proposed recently for the QoS management within 3GPP and ETSI UMTS works: Network Management Layer NMS/OSS QoS Policy Provisioning IRP(CORBA, LDUP ) = Policy Repository Element Management Layer 'RPDLQ 3ROLF\Ã6HUYHU (06Ã 4R6Ã3ROLF\ HJÃ$FFHVV 3URYLVLRQLQJ Policy Decision Control Function Point (PCF) 'RPDLQ 3ROLF\Ã6HUYHU (06Ã 4R6Ã3ROLF\ HJÃ&RUH 3URYLVLRQLQJ LDUP/SNMP Network Element Layer COPS-PR/SNMP/CLI Policy Decision Control Function Point (PCF) COPS-PR/SNMP/CLI Policy Control Decision Function Point (PCF) COPS-PR/SNMP/CLI Policy Enforcement Point Policy Enforcement Point Policy Enforcement Point COPS & Diffserv MIB Diffserv MIB COPS & Diffserv MIB Diffserv MIB Figure 26 QoS management with policy based functional architecture In this architecture, the policy enforcement points (PEP) are responsible to introduce the policy based control, by implementing the metering policy and process in the NE layer, then to apply the control in the element management (EM) layer, while the policy is selected and implemented by the network management layer. Based on the NMS/OSS QoS policy, the SLA management and QoS charging capabilities may be implemented as well (the service/business management layer, on the top of the network management layer, is not shown in this figure). A special case for the usage of the above model is when there is a main (for the given area practically global) provider, having different access systems and solutions for collect network provisioning, and also a core network, an IP backbone. With peering agreements towards other IP network operators, IP based LAN interconnect management may support the Provider offered managed -based Layer 2 IPVPNs, too. L2TP solutions may be also offered with IP packet transfer performance monitoring / CoS management. EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 51 (70) 7.2.2 Integrated SLA and QoS Data Management The challenge to provide truly integrated SLA Management is the effective management of all the related Service and Customer data. SLA Management functions need to combine, to correlate, to assess, and manage a wide variety of data sources to effectively manage the fulfilment and assurance of SLAs. There is a need to draw on many data sources within a SP s Operational Support System (OSS) environment, such as information on Customers, services, and service performance, as shown in Figure 27. TeleManagement Forum provided the guidelines [GIB917 GIB917]. Service Instances Customer Details SLA Contracts Customer SLA Performance Data SLA Reports Service QoS & Performance Data Service Descriptions SLA Templates QoS Reports Product & Service Development Raw Performance Data Implementation Negotiation & Sales Execution & Assessment Figure 27 SLA/QoS Related Data Data types and legend: Customer Details Information about the Customer, sometimes called Customer profile. Service Descriptions - details of the service product catalogue offered by the SP. Service Instances - the individual service instances active in the network. SLA Templates - definitions of the standard grades of service, which can be offered with a SLA, for example, templates to describe gold and silver service characteristics. SLA Contracts - individual-specific SLA contracts between the SP and the Customer with the specific service details, agreed levels of service quality, reporting schedules, and details of actions to be taken when the service quality guarantees are not met. Raw Performance Data - raw performance data collected from various data sources including the network and service resources, such as network elements, network & element management systems, and network and application servers. Also data collected for the SPs OSSs, such as trouble ticketing, order processes, maintenance and support, Customer care, etc. Service QoS & Performance Data - aggregated service quality and performance data combined from the many disparate raw data sources. Customer SLA Performance Data - correlation of the service quality and performance data against specific Customer service instances to provide specific performance data against individual service instances and SLAs. QoS Reports - reports generated from the service quality and performance data to report the performance of the service as a whole. SLA Reports - reports generated from the Customer SLA quality and performance data to report the performance of the specific service instance for a specific Customer against a SLA. 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) EURESCOM Project Report 7.2.3 Separation of managing VPN services network and VPN transport network Separated services network and transport network layers are introduced and applied by the ITU-T SG 13 developed IP services and IPVPN support framework (see: [Y.1241],[Y.1311]), and such a layering concept is a basic approach for the QoS and network management model of the ETSI TIPHON project [ETR101303]. By this concept Network (and QoS) Management, especially the performance measurements, monitoring and alarm generation functions are based on selectable parameter objectives, existing standard measurement and management tools. Reference points, i.e., implemented management interfaces should be used for QoS measurements/monitoring, QoS information exchange and interactions. QoS management systems and reference points are to be tailored for the different end-to-end traffic types and for communication attributes of the VPNs. Similar interface model based approach is applied by the EURESCOM [P1008] project, defining the IP Inter-operator QoS management framework, interfaces and processes. As the IPVPN scenario with multi-provisioning, provider presented VPN and layer3 tunnelling implementations are discussed, with the hub and the chain models of QoS management. Figure 28 shows the hub. Management plane SLA Service Customer Service Provider Customer service management functions SLA Xm Xmu (Unbundled) A-IPND Network management CPE / CPN functions management Xm SLA T-IPND Network management functions Xm SLA CC Xmu (Unbundled) Z-IPND Xmu Network management functions CPE / CPN management Service Customer Client Control plane Qn BGP Routing tables / OSPF tables Qn BGP Qn p Tunnel protocol for the establishment, maintenance & clearing of tunnels, e.g. L2TP Network address translation scope Customer address scope d EL- A CR BR CR BR CR EL- C Xnu Xnu ER CR BR Xn CR BR Xn CR ER Xnu Xnu EL- B Customer access: eg. Dial, ADSL, Cable, Frame Relay, ATM & Mobile A-IPND T-IPND Z-IPND Network Link e.g. ATM PVC User plane (indicating SDH, WDM router network) EL- D Customer client access: eg. Dial, ADSL, Cable, Frame Relay, ATM & Mobile Legend: IP: Internet Protocol OSS: Operational Support System IPND: IP Network Domain ER: Edge Router BR: Border Router CR: Core Router L2TP: Layer 2 Tunnelling Protocol EL- A, - B, - C, - D : Enterprise Locations connected by the IP VPN CC: Communications link (unspecified) A: Access T-: Transit Z-: Terminating Mngt: Management VPN: Virtual Private Network Xm: Inter-domain Management interface Xn: Inter-domain network interface OSPF: Open Shortest Path First Xnu: User-IPND network interface Xmu: User-IPND management interface BGP: Border Gateway Protocol Qn: Network technology interface ATM: Asynchronous Transfer Mode SLA: Service Level Agreement PVC: Permanent Virtual Circuit SDH: Synchronous Digital Hierarchy ADSL: Asynchronous Digital Subscriber Line WDM: Wavelength Division Multiplexing CPE / CPN: Customer (or User) Private Network / Equipment Figure 28 Generic IP VPN scenario hub model The scenario in Figure 28 does not extend to considering specific traffic matrices, which would model possible mixes of services in relation to the total available bandwidth for the VPN. Although containing much detail, the IP VPN scenario is aligned with the structure of the technical, organisational and business models where three operators are interconnected at network and network management levels and interactions are depicted in terms of Management, User and Control planes. A Service Customer s Enterprise Locations (EL-A, B, C, D) are shown interconnected to the IPND A and IPND Z domains, with management organisation in accordance EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 53 (70) with the Hub model. (Of course, more or fewer than 3 operators may be involved in the provision of any given IP VPN service, but Figure 28 should be sufficient to indicate the fundamental principles of such service provision. A given IP VPN service instance could, for example, include several more cross-connection, network interconnections, supporting different QoS technologies and allowing (bandwidth and QoS) brokerage, as well. Inter-domain QoS management and end-to-end delivery chain model variants are proposed for the four identified network technology interconnect scenarios of providing virtual call completion over IP described in recent ETSI and ITU-T documents. Managed QoS provisioning is needed for application aware VPN provisioning offered by the virtual services networks. Selectable QoS classes have been defined at first by ETSI TIPHON QoS WG in [ETR101329s], end-to-end packet transfer quality classes are introduced also by the ITU-T, in [Y.1541]. QoS management support is dealt with by the IP related ITU-T network management framework, including traffic control and congestion management guidelines for IP networks, [Y.iptc]. Monitoring and QoS signalling based approach has been implemented by ETSI TIPHON project for call-model based application services over the VPNs, and this is proposed for call-based service provisioning over VPNs for the UMTS (see [P1103]). For end-to-end application services provided over Layer3 VPNs, different interconnected technology domains are included, according to the accessibility options, and to the different QoS models and technology variants in the transport carrier (core), IPVPN provisioning backbone segment. Both the overlay concepts with one main provider, and the multi-provisioning approach are calling for management tools, solutions and QoS measurements by layers. For real time, interactive communication managed services provisioning and differentiated QoS is considered, both by the ETSI TIPHON project and for multimedia conferencing. Media control functionality, and QoS management capabilities may be implemented to support ToIP/VoIP purpose usage of the IPVPN. Based on control and management purpose QoS signalling, TIPHON WG5 presents the example of provisioned VPN based implementation by Figure 29, showing manager roles, information exchange types and related interactions. Service Domain 1 Service Domain 2 QoSPE QoSPE QoSM QoSM Application Plane Transport Plane TRM Management Plane VPN Provisioning process TRM Transport Domain 1 TRM Transport Domain 4 Media Path VPN Transport Domain 2 TRM VPN Transport Domain 3 QoS Signalling Call Signalling Configuration Instruction Configuration Information TRM Transport Resource Manager Figure 29 QoS management architecture for ToIP over IPVPN (ETSI TIPHON Draft TS 101 329-3 V.0.9.2) In general, end-to-end cross-connect QoS management can be dynamic or static. Dynamic QoS signalling allows an IP Application Service Provider (ASP) to signal the QoS requirements on a per call (user-to-user communication session) base to the Transport Domain operator(s). Selecting of actual the profile for the session specific flows should be on the basis of SLAs, (e.g., using the Layer3 service select feature deployed). Static Service Level Agreements apply when the SLA is fixing the QoS profiles in terms of performance classes per sites and user classes (application 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) EURESCOM Project Report categories to be supported), and the end-to-end signalling over the carrier domains is restricted to resource availability. Resource aggregation may be performed in the transport plane, under the control of Network Operators, or of SP(s). When the NO controls, the transport resource manager system (TRMS) is to monitor the allocation using resource mechanisms, such as MPLS and IntServ/RSVP. When the SP is to control, the service provider s quality management (QoSM) may reserve a quantity of transport resource with guaranteed QoS prior to set up of an individual media flow; thus bandwidth management and admission control (based on resource usage monitoring) is always required for QoS services. EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 55 (70) 8 Conclusions - recommendations and guidelines The previous chapters provided an overview of the main models and architectures to build IPVPNs. Each of these models provide different ways to fulfil the requirements identified in chapter 3. It is clear that the setup and provisioning of an IPVPN service is not a straightforward process due to the large number and diversity of components involved. The wide range of available technologies and the number of IPVPN variants make the design of an IPVPN solution a nontrivial task. Unfortunately, there are no strict rules on the best practices to be followed to setup IPVPNs. The merits and drawbacks of a specific IPVPN solution should be evaluated in the light of the specific requirements in each case. An overall evaluation and comparison of the several IPVPN technologies and architectures is attempted in the following sections. 8.1 Basic enabling technologies: IPsec and MPLS IPsec and MPLS are undoubtedly the two main enabling technologies to build IPVPNs. To a large extent, these two technologies have developed independently from each other. While IPsec is particularly suited to handle security, MPLS is mainly oriented to cope with such requirements as scalability, traffic engineering and QoS control. In fact, both technologies should have their place in the service provider networks. The most obvious (although not entirely accurate) criterion to define the field of application of each solution is the size factor IPsec is the natural choice for small enterprise network environments, whereas MPLS is used when scalability is a concern (both in terms of the average customer network size and the number of customers). IPsec has a number of strong points: IPsec is the only VPN technology to support data encryption, which is a crucial requirement in the cases where a VPN is established across non-secure network segments (unlike MPLS, which does not provide any built-in security mechanism); IPsec does not impose any special requirements on the supporting IP backbone; in principle an IPsec VPN could be deployed over any IP-based network (unlike an MPLS VPN, which requires an MPLS-enabled backbone infrastructure); IPsec provides an easy VPN service deployment and a fast time to market (unlike MPLS, which needs a fully functional MPLS backbone and requires a considerable time to deploy). A VPN based on IPsec tunnels can be, in principle, extended to any place connected to the Internet and is limited by the scope of the service provider network domain. In spite of the merits indicated above, IPsec VPNs target a restricted market, as it typically cannot be sold to large enterprises or other carriers. In fact, MPLS is the only feasible solution to support large-scale IPVPN implementations (actually, this has probably been the main reason for the deployment of this technology by an increasing number of IP service providers and network operators). MPLS allows an effective control of the network resources through the use of traffic engineering and, together with other technologies, (e.g. BGP) enables the easy deployment of large-scale VPNs. In terms of security, MPLS VPNs provide no encryption or any specific security mechanism (in the same way as traditional layer 2 VPNs based on Frame Relay or ATM an important market segment for MPLS VPNs to compete with). In any case, assuming the service provider to be trustworthy, VPN security is guaranteed by traffic isolation and address and routing separation, which most MPLS VPN implementations can provide. In certain VPN scenarios, both IPsec and MPLS can be used as complementary technologies. IPsec should be used in those cases where strong authentication and confidentiality are required (typically, remote VPN access through the public Internet or any non-trusted network) whereas 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) EURESCOM Project Report MPLS provides flexible VPN control functions and enables traffic engineering and traffic differentiation required by large VPN implementations [MPLS-IPsec]. 8.2 Network-based VPN models which one is best for the SP It is clear that MPLS is the best technology for building large-scale VPNs. Most VPNs supported by MPLS follow the so-called Network-based model, in which all the relevant VPN control mechanisms are executed in the service provider network domain. However, there are several different ways to achieve the same goal, with their specific merits and limitations. No networkbased VPN solution can be deemed as the best in all cases. Therefore, VPN service providers should perform a careful analysis of customer requirements and then select the best solution for each case. In the following sections a summary of the main advantages and disadvantages of several models is provided. 8.2.1 Layer 2 vs. Layer 3 models Both layer 3 and layer 2 VPNs have strong and weak points. In this section, a brief summary of advantages/disadvantages of each model is presented. Layer 3 MPLS-based VPNs have several advantages when compared to layer 2 VPNs: Œ Layer 3 VPNs are easy to configure and provision. The addition of a new site to an existing layer 3 VPN requires the configuration of the respective and PE routers only. By contrast, in a fully meshed layer 2 VPN with n sites, n-1 connections must be configured at each (although this problem could be minimized by the implementation of signalling protocols). Œ In a layer 3 VPN, a router has a single neighbour, the PE router, and needs only to maintain a single routing adjacency. By contrast, in a layer 2 VPN with n sites, each router must have n routing peers (although a hub-and-spoke VPN topology could alleviate this problem). Œ In layer 3 VPNs, the customer is responsible for routing within each site only. In layer 2 VPNs, the customer has to build and operate the whole network, which may be inappropriate for customers with little routing expertise. Œ Layer 3 VPNs are totally independent from layer 2 technologies. Œ Layer 3 VPNs are able to handle IP QoS. Since the PE router has layer 3 visibility, it can perform QoS classification and the applicable Diffserv edge router functions. Layer 2 MPLS-based VPNs have also some advantages when compared to layer 3 VPNs: Œ Because MPLS-based layer 2 VPNs are functionally equivalent to traditional Layer 2 VPNs (e.g. ATM, Frame Relay based), the migration process should be straightforward. Œ Œ Œ Layer 2 VPNs guarantee privacy of customer routing, as the service provider does not participate in routing. The SP routers need not do anything special to keep customer routes separate from other customers or from the Internet; Per-VPN routing tables are not needed on PE routers. The scalability of layer 2 VPNs depends on the number of VPN sites but not on the number of customer routes. By contrast, in Layer 3 VPNs each may have an arbitrary number of routes that need to be learned and carried by the SP. For many critics of layer 3 VPNs, routing scalability will be a major problem in large networks. By pushing management of VPN routing tables to customers, layer 2 VPNs will have fewer scalability problems, as far as routing in concerned. In layer 2 VPNs there is a clear separation between Service Provider responsibility (layer 2 connectivity) and the customer responsibility (layer 3 connectivity, including routing). EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 57 (70) Œ Layer 2 VPNs provide independence from layer 3. Because the service provider simply provides layer 2 connectivity, the customer can run any layer 3 protocol. By contrast, in layer 3 VPNs, the customer and the SP must use the same layer 3 protocol(s) and routing protocols. Œ In layer 2 VPNs the routers run native multicast routing directly. The SP backbone just provides interconnection of the routers; whether the routers run IP unicast or IP multicast or some other network protocol is irrelevant to the SP routers. In layer 3 MPLSbased VPNs, IP multicast support is much more complicated (for example, with regard to BGP/MPLS VPNs, Internet Draft Multicast in MPLS/BGP VPNs [draft_rosen_vpn_mcast] addresses this issue but so far very few implementations, if any, are able to support it). In summary, from the point of view of the service provider the decision to implement layer 2 or layer 3 VPNs may be influenced by a number of factors such as: Œ Is the service provider willing to manage a high number (potentially hundreds) of VPN routing tables or does he prefer to push this responsibility to the customer? Œ What kind of approach is used by the service provider to manage and control QoS? In addition, from the VPN customer s point of view, the decision to go for a layer 2 or layer 3 VPN service may depend on a number of questions: Œ Is the customer willing to manage and control VPN layer 3 routing or does he prefer to outsource this responsibility to the VPN service provider? Œ Is privacy of VPN routing a requirement for the customer? Œ What is the size of the VPN both in terms of number of sites and number of customer routes? Œ Is the present customer s corporate network based on a layer 2 VPN (e.g. Frame Relay, ATM) and, if so, is he prepared for a significant change of his network? Œ What kinds of services are needed (expected) to be supported by the customer? Œ What layer 3 protocols (namely, other than IPv4) are supported by the customer? Œ Is multicast a major requirement for the customer? Finally, it should be stressed that layer 2 and layer 3 VPNs are not mutually exclusive. As was mentioned before (see section 5.3), the same MPLS-based backbone allows the deployment of both VPN models simultaneously. This may represent an important advantage for service providers wishing a smooth migration to MPLS (for example to take advantage of layer 3 VPNs) but having a large installed base of layer 2 ATM or Frame Relay VPNs. 8.2.2 Layer 3 VPNs: BGP/MPLS vs. Virtual routers The MPLS/BGP and VR VPN models implement different layer 3 approaches to manage and provision a VPN service using an MPLS core network. The two models are identical in relation to several aspects, for example, data forwarding, VPN multiplexing, label distribution, supported VPN types and topologies. However, there are important differences regarding the management of the VPN and the SP network, the router and network resources used by each model, and the implementation effort that should be noted. The main difference between the two methods resides in the model used to achieve VPN reachability and membership functions. In BGP/MPLS IPVPNs a backbone routing protocol (BGP) is responsible for disseminating the VPN membership and reachability information between provider edge routers (PE) for all the VPNs configured on the PE. By contrast, in the VR model, each VR in the VPN domain is running an instance of routing protocol responsible for disseminating VPN reachability information between VRs. Therefore, VPN membership and VPN reachability are treated as separate functions, and separate mechanisms are used to implement these functions. VPN reachability is carried out by a per-vpn instance of routing. 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) EURESCOM Project Report The BGP/MPLS model uses a single BGP instance per PE router, regardless on the number of VPNs it supports. The utilisation of BGP within the SP cloud implies some limitations in certain -PE peering cases (for example, when OSPF is used) but permits a more compact implementation. By contrast, the VR VPN model uses an independent routing instance for each VPN, which requires higher consumption of router resources and network bandwidth. The difference between the BGP/MPLS and VR approaches is illustrated in Figure 30. CPE A VRF A CPE A VR A Routing protocol CPE B CPE C VRF B VRF C BGP4 + Extensions CPE B CPE C VR B VR C Routing protocol Routing protocol BGP/MPLS VPN VR-based VPN Figure 30 BGP/MPLS VPN vs. VR-based VPN The VR model clearly separates the management domain for a given customer from the rest of the SP network, which can be exploited to give the customer simple self-service management. The management responsibilities can be split between two different entities the Service Provider, which provides the network resources, and the Administrator of Private Network, which manages the layer 3 resources provisioned specifically for that VPN. The full set of standard management tools for the routing protocols running in the VRs can be used to manage the VPN topology. These tools are already familiar to the SP or customer network administrator. Another advantage of VR VPNs is the fact that no changes to existing routing protocols (e.g. RIP, BGP, OSPF, and IS-IS) are required. By contrast, the BGP/MPLS architecture follows a more centralised approach where the VPN management, troubleshooting and monitoring is performed by a single entity. VPN customers do not have a backbone or a virtual backbone to administer (thus, customers do not need management access to PE or P routers). The BGP/MPLS model is based on extensions to standard BGP (BGP extended communities), which could represent a limiting factor to the wide deployment of this VPN solution. The relative merits and drawbacks of the two approaches, especially in terms of scalability, have been hotly debated, but the final verdict will be provided by real large-scale implementations. In any case, the BGP/MPLS model should be in principle particularly suited for customers that need to outsource the complexity of routing management to their VPN service provider, shifting the complexities of managing full-mesh inter-site connectivity from the subscriber CPE router to the PE router and the provider s IBGP. VR VPNs require more bandwidth and router resources, but gives finer-grained control over the routing topology. It could be specially appropriate in the cases where a clear separation between the management of the customer s private network and the management of the SP network infrastructure is desired (including customer self-service management) or to support very complex VPN topologies. 8.2.3 Interworking issues At this point in time it is not clear what the future will bring and whether a single VPN solution will prevail or the market will be split by different VPN solutions. In the latter case, interworking between different solutions will be a crucial issue. In the above sections, each VPN solution was analysed and evaluated on its own. However, in today s and tomorrow s highly dynamic business environment, it should not be uncommon that, as a result of a merger or restructuring process, VPNs used by different organisations (possibly connected to different service providers) need to interwork. Apart from the conventional problems associated to such situations (e.g. address EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 59 (70) overlapping), VPN interworking is a non-trivial problem that has to be faced. Up to now, no clean interworking solution between different VPN implementation models has been specified, and some workarounds have to be devised. Figure 31 represents an interworking scenario where a single customer site is connected to two different VPNs, based on different VPN models, through different s. PE Customer site IGP PE VR VPN MPLS/BGP VPN Figure 31 Network-based VPN interworking scenario Since direct PE-PE interworking is not possible, a possible solution is the redistribution of routes between routers through an IGP protocol. Of course, the two s could be physically located at the same physical router, in which case the solution would be even simpler. Although this could be a workable solution, it is obviously not satisfactory from several points of view. Firstly, it transfers the VPN control to the customer network, which somehow contradicts the purpose of a VPN service. In addition, the routers, which are responsible for the interconnection, become a single point of failure and have to carry all the traffic between the two VPN segments. Of course, PE-PE interworking would be a much more desirable solution, if available. 8.2.4 Standardization gaps and future evolutions The IPVPN standardization has been led by the IETF and the ITU. There are several fields, which have not been addressed so far, or have been addressed only partially by the standardization groups. In the following paragraphs some examples are indicated. QoS and SLS in MPLS-based VPNs The provisioning of a VPN service is often based on the definition of an SLS to characterize the QoS level expected from the service provided to the customer. From the customer point of view, the main concern is to get enough resources to allow an acceptable performance of his applications. The implementation of QoS control mechanisms in IPVPNs, which can be used as the basis for SLS specification, may follow different approaches (e.g. pipe model, hose model). However, the VPN QoS engineering issues (independently from the backbone QoS engineering), have been relatively overlooked. Utilisation of traffic engineering techniques to meet VPN QoS objectives is another topic, which has been relatively ignored. MPLS interworking and multi-provider VPNs Several methods to implement the IPVPN models have been described before. A lot of effort has been spent by the IETF on the specification of several individual technical IPVPN approaches and architectures. However, as was noted in the previous section, very little has been done on interworking issues. The multi-provider scenarios available so far in IETF drafts cover only the case where multiple MPLS domains support the same VPN type (e.g. multi-provider BGP/MPLS VPNs) but very little, if anything, was done regarding the interworking of different solutions (e.g. VR-VPNs and BGP/MPLS VPNs) IPv6 VPNs As seen before, the RFC2547 MPLS VPN model is based on the definition of the concept of IPv4 VPN address family. To support IPv6 VPNs the definition of a new address family is required: the 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) EURESCOM Project Report IPv6 VPN address family. This work has already started at the IETF PPVPN group and a draft is already available [draft-bgp-mpls-ipv6-vpn]. To support IPv6 VPNs, an MPLS backbone supporting RFC2547 VPNs needs to update the PE routers that are connected to IPv6 VPN customers. This means that, from the point of view of the service providers, the VPN customer s migration to IPv6 will not require the migration of the backbone to IPv6. Mobility User mobility, fostered by IPv6 and the dissemination of wireless terminals, will be crucial requirement in future corporate networks. Up to now, mobility issues have been largely ignored by network based VPN standardization efforts. Multicast Multicast is presently an essential feature in a high number of corporate networks and this trend will likely increase in the future. VR-based VPNs should be able to support multicast traffic, (assuming that the routers in the core support multicast protocols) as the VR model does not require any significant modification to standard IP routing protocols. For layer 2 VPNs this should not be a problem either, as IP multicast should be transparent to the layer 2 protocols underneath. However, for BGP/MPLS VPNs, based on BGP extensions, multicast support is not so straightforward. The draft Multicast in MPLS/BGP VPNs draft_rosen_vpn_mcast extends the RFC 2547 specification by describing the protocols and procedures which must be implemented in order to support multicast traffic in a VPN, using PIM as the multicast routing protocol used within the VPN. This draft is now obsolete and it is not clear what will be the future direction of this activity. EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 61 (70) Appendix A. Commercial IPVPN implementations In order to get an evaluation of how the most important IPVPN-related drafts have been implemented by the major industry players and perceive the maturity status of some of the most relevant VPN features, P1107 carried out a survey. Two separate RFIs were sent to a number of IPsec and MPLS vendors. For confidentiality reasons the results can not be shown in this document in its entirety (full results are available in a separate P1107 document, classified as Eurescom confidential). However, some overall conclusions are presented, showing the present status of major VPN implementations. The number of vendors contacted and answers received was as follows: Vendors contacted Answers received IPsec RFI 14 8 MPLS RFI 10 7 The answers received from vendors are mostly based on the characteristics of one or more commercial products. The charts presented below are based on the number of received answers (for example, 100% in a certain feature means that all of the answers indicated that feature to be supported). A.1 IPsec-based implementations survey The following diagram shows the overall results of the IPsec RFI, based on a number of different topics. IP sec-based VPN survey 100% 90% 80% 70% 60% No info Roadmap Supported Not supported 50% 40% 30% 20% 10% 0% Offers Client Software Additional Firewall integrated/optional Supports clustering Supports SNMP for Configuration Supports AES encryption Algorithm Supports external PKI Supports Certificate Import Method SP Support of Certificate Revocation List (CRL) Figure A. 1 IPsec-based VPN survey 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) A.2 MPLS-based implementations EURESCOM Project Report A.2.1 Overview of available models and implementations Table 1 presents five VPN implementations based on IETF Drafts, supported by major vendors, and can be seen as representing the state-of-the-art in Network-based VPNs. Note: the information shown on this table is based on widely available sources (e.g. vendors web pages) and is not by any means related to the information obtained through the vendor RFI. Standard / IETF Draft Main proponents (vendors) Examples of vendors with available commercial implementations Auto-discovery mechanism Tunnelling techniques Table 1 - Main network-based VPN implementations BGP/MPLS VPN (RFC2547) draft-ietf-ppvpnrfc2547bis-00.txt (July 2001) Cisco, Juniper, Cosine, Alcatel Cisco, Juniper, Ericsson, Unisphere, Alcatel, Cosine VR architecture draft-ietf-ppvpn-vr- 00.txt (July 2001) Core VPN (RFC2917) draft-ietf-ppvpnrfc2917bis-00.txt (July 2001) L2 MPLS VPN Draft-kompellampls-l2vpn-02.txt (June 2001) Nortel, Cosine Lucent Juniper, Cosine, Cisco Nortel Lucent Juniper, Cisco BGP BGP Multicast VPN Mechanisms MPLS MPLS, IPsec, IP in IP, GRE MPLS MPLS BGP/MPLS VPN : corresponds to the model presented in section 5.1 and specified in [draftrosen-2547]. Cisco has been one of the driving forces behind this proposal, however a number of different implementations are available from different vendors. VR architecture : based on the IETF draft Network based IP VPN Architecture using Virtual Routers [draft-ipvpn-arch-vr], is one of the VR VPN model implementations (section 5.2). Nortel is its main proponent. Core VPN : another VR-based VPN model, proposed by Lucent. It is specified in the draft A Core MPLS IP VPN Architecture [draft-core-ipvpn]. It includes an auto-discovery mechanism based on multicast. Layer 2 VPN MPLS : has had Juniper as one of the main proponents. Recently, this area has been one of the most active within the IETF PPVPN Working Group. Both Juniper and Cisco have implementations of this VPN model. A.2.2 MPLS VPN vendor survey The RFI was sent to ten vendors, seven of which provided the requested information on their products. The information provided in the figures below is related to: General MPLS features (Figure A. 2) Implementation of three major VPN IETF drafts (Figure A. 3): o draft-ietf-ppvpn-rfc2547bis-00.txt o draft-ietf-ppvpn-vr-00.txt o draft-ietf-ppvpn-rfc2917bis-00.txt EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 63 (70) Specific features related to the IETF drafts indicated above (Figure A. 4, Figure A. 5, Figure A. 6). General MPLS features 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Frame-mode data forwarding is supported Cell-mode data forwarding is supported (ATM LSR) LDP is supported CR-LDP is supported RSVP-TE is supported MPLS tunnel restoration is supported LSP setup with bandwidth reservation is supported Diffserv is supported by means of E-LSPs Diffserv is supported by means of L-LSPs ATM-based QoS class differentiation is supported IS-IS is supported as IGP with enhancements for traffic engineering OSPF is supported as IGP with enhancements for traffic engineering. Penultimate Hop Popping is supported. Figure A. 2 General MPLS features 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) EURESCOM Project Report Basic VPN standards/drafts 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% The IETF draft BGP/MPLS VPNs (draft-ietf-ppvpnrfc2547bis-00.txt, July 2001) is supported. The IETF Draft A Core MPLS IP VPN Architecture (draft-ietf-ppvpn-rfc2917bis- 00.txt, July 2001) is supported The IETF Draft Network based IP VPN Architecture using Virtual Routers (draftietf-ppvpn-vpn-vr-00.txt, July 2001) is supported Figure A. 3 Basic VPN standards/drafts BGP/MPLS VPN features 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Edge device ( PE router ) functionality is supported. SP Backbone router ( P router ) functionality is supported. Multiple route targets can be imported/exported to/from a single VRF. VPN-IPv4 address family is supported as per RFC2547. BGP multiprotocol extensions are supported, according to RFC 2858. BGP route reflector functionality is supported. BGP is supported at the PE- interface RIP is supported at the PE- interface OSPF is supported at the PE- interface OSPF as the PE/ Protocol in BGP/MPLS VPNs (draft-ietf-ppvpn-ospf-2547-00.txt) is supported. Multicast in MPLS/BGP VPNs, (draft-rosen-vpn-mcast-02.txt) MPLS/BGP VPN Management Information Base Using SMIv2 (draft-ietf-ppvpn-mpls-vpn-mib- 00.txt) is supported Use of PE-PE IPsec in RFC2547 VPNs (draft-ietf-ppvpn-ipsec-2547-00.txt) is supported Use of PE-PE GRE or IP in RFC2547 VPNs (draft-ietf-ppvpn-gre-ip-2547-00.txt) is supported Using BGP as an Auto-Discovery Mechanism for Network-based VPNs (draft-ietf-ppvpn-bgpvpnauto-00.txt) is supported Figure A. 4 BGP/MPLS VPN features EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 65 (70) Core MPLS IP VPN Architecture features 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% MD5 authentication between VRs is supported. Dynamic discovery of VRs is supported. BGP is supported between VRs RIP is supported between VRs OSPF is supported between VRs ISIS is supported between VRs Private (per-vpn) LSPs are supported. VPNID encapsulation over shared LSPs using label stacks is supported. Diffserv can be configured on a VPN-by-VPN basis. 100% Figure A. 5 Core MPLS IP VPN Architecture features Network-based IP VPN Architecture using VR features 80% 60% 40% 20% 0% ATM is supported as backbone technology FR is supported as backbone technology IP tunneling (IPsec, GRE,...) is supported as backbone technology MPLS is supported as backbone technology BGP is supported between VRs RIP is supported between VRs OSPFis supported between VRs ISIS is supported between VRs VR-VR connectivity over layer 2 connections is supported Aggregation of multiple VRs over a single backbone VR is supported MPLS tunnelling is supported. IPSec tunnelling is supported. Query to directory server is supported as discovery mechanism Explicit configuration via management platform is supported as discovery mechanism ID draft-ietf-ppvpn-bgpvpn-auto-00.txt is supported. Figure A. 6 Network-based IP VPN Architecture using VR features 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) EURESCOM Project Report References [D3] P1107 Deliverable 3, QoS issues of IPVPN provisioning and SLA management, May 2002 [Davie] B. Davie, Y. Rekhter, MPLS Technology and Applications, Morgan Kaufmann Publishers, 2000 [draft_ietf_ppvpn_framework_03] R. Callon et al., A Framework for Provider Provisioned Virtual Private Networks, Internet Draft, <draft-ietfppvpn-framework-00.txt>, January 2002 [draft_rosen_vpn_mcast] E. C. Rosen et al., Multicast in MPLS/BGP VPNs, Internet draft, <draft-rosen-vpn-mcast-02.txt>, July 2001 [draft-andersson] PPVPN L2 Framework, draft-andersson-ppvpn-l2- framework-00.txt, March 2002 [draft-augustyn] Requirements for Virtual Private LAN Services (VPLS), draft-augustyn-vpls-requirements-02.txt, February 2002 [draft-bgp-mpls-ipv6-vpn] T. Nguyen et al, BGP-MPLS VPN extension for IPv6 VPN over an IPv4 infrastructure, draft-ietf-ppvpn-bgpipv6-vpn-01.txt, November 2001 [draft-bgpvpn-auto] H. Ould-Brahim et al, Using BGP as an Auto-Discovery Mechanism for Network-based VPNs, draft-ietf-ppvpnbgpvpn-auto-02.txt, January 2002 [draft-core-ipvpn] Karthik Muthukrishnan et al, A Core MPLS IP VPN Architecture, IETF Internet Draft draft-ietf-ppvpnrfc2917bis-00.txt, July 2001 [draft-diffserv] New Terminology for DiffServ, IETF Draft, draft-ietf- DiffServ-new-terms-04.txt, March 2001 [draft-ganty] S. Ganty et al, IETF Draft,, MPLS Support of Differentiated Services using E-LSP, draft-ganti-mplsdiffserv-elsp-00.txt, April 2001. [draft-ipsra-reqmts] Requirements for IPsec Remote Access Scenarios, Internet draft, draft-ietf-ipsra-reqmts-03.txt, January 2001 [draft-ipvpn-arch-vr] P. Knight et al, Network based IP VPN Architecture using Virtual Routers, draft-ietf-ppvpn-vpn-vr-02.txt, February 2002 [draft-kompella] MPLS-based Layer 2 VPNs, IETF draft, draft-kompellampls-l2vpn-02.txt, May 2001 [draft-mahon] Mahon et al., IETF Draft, Usage Cases for a Policy Management System, November 9 2000, draft-mahonpolicy-use-00.txt [draft-martini] L. Martini et al., IETF draft, Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks, draft-martini-l2circuit-encap-mpls-04.txt, November 2001 [draft-martini2] L. Martini et al., IETF draft, Transport of Layer 2 Frames Over MPLS, draft-martini-l2circuit-trans-mpls-08.txt, November 2001 [draft-mpls-diff] François Le Faucher et al, MPLS Support of Differentiated Services draft-ietf-mpls-diff-ext-09.txt, EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 67 (70) April, 2001 [draft-mpls-rsvp] D. Awduche et al, IETF Draft, RSVP-TE: Extensions to RSVP for LSP Tunnels, draft-ietf-mpls-rsvp-lsp-tunnel- 08.txt, February 2001 [draft-msec-gsakmp] H. Harney et al., Group Secure Association Key Management Protocol, Internet draft, <draft-ietf-msecgsakmp-sec-00.txt>, March 2001 [draft-policy-req] Mahon et al., IETF Draft, Requirements for a Policy Management System, November 9 2000, draft-ietfpolicy-req-02.txt [draft-ppvpn-frame] R. Callon et al, A Framework for Provider Provisioned Virtual Private Networks, draft-ietf-ppvpn-framework- 01.txt, July 2001 [draft-requirements] M. Carugi et al, Service requirements for Provider Provisioned Virtual Private Networks, Internet Draft, IETF, draft-ietf-ppvpn-requirements-03.txt, August 2001 [draft-rosen-2547] E. Rosen et al., BGP/MPLS VPNs, draft-ietf-ppvpnrfc2547bis-01.txt, IETF draft, January 2002 [draft-rosen-l2vpn] E. Rosen et al., An architecture for LSVPNs, draft-ietfppvpn-l2vpn-00.txt, July 2001 [draft-vpn-disc] C. Kathirvelu A Core MPLS IP VPN Link Broadcast And Virtual Router Discovery, draft-ietf-ppvpn-corevpn-disc- 00.txt, July 2001 [ETR101303] ETSI, TIPHON, Release 3 ervice and Network management framework: Part1: Overview and introduction, DTS/TIPHON 01006, 2001 [ETR101329s] ETSI, TIPHON: End to End Quality of service in TIPHON Systems, ETR 101329 series, Part 1& 3 [Ferguson1] P. Ferguson, G. Huston What is a VPN?, http://www.cisco.com/warp/public/759/ipj_1-1/ipj_1-1_vpn1.html, June 1998 [Ferguson2] A Cryptographic Evaluation of IPSec, available at www.conterpane.com/ipsec.html [GIB910] TeleManagement Forum, Telecoms Operations Map, version 2.1, March 2000 [GIB917] TeleManagement Forum, SLA Management Handbook, version 1.0 for Members evaluation [Glossary] Erik Neumann et al., Glossary, Work in Progress, Eurescom P1107 VPN terminology vocabulary [Guichard] Jim Guichard, Ivan Pepelnjak: MPLS and VPN architectures, February 2001 [ITU-T Y.1311] ITU - Study Group 13, Draft Recommendation Y.1311, Network based IPVPN Service - Generic Framework and Service Requirements, November 2000 [kompella] Kireeti Kompella, et al., MPLS-based Layer 2 Virtual Private Networks, http://www.juniper.net/techcenter/techpapers/200009.pdf, 2001 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) EURESCOM Project Report [MPLS-IPsec] A Comparison Between IPsec and Multiprotocol Label Switching Virtual Private Networks, Cisco White Paper, Cisco Systems, http://www.cisco.com/warp/public/cc/pd/hb/vp5000/prodli t/iplsc_wp.htm [nat-wp] SSH NAT Traversal White Paper, SSH Communications Security Corp [NMF503] TeleManagement Forum, Service Provider to Customer Performance Reporting Business Agreement [NMF506] TeleManagement Forum, Service Quality Management Business Agreement, TMF506, Public Evaluation Version 1.5, February 2001 [NMF701] TeleManagement Forum, Performance Reporting Concepts and Definitions Document, TMF 701 [P1008] EURESCOM P1108 Project Inter-operator interfaces for ensuring end to end QoS, Deliverable2 Selected scenarios and requirements for end-to-end IP QoS management, February 2001, EDIN 0070-1008, and Deliverable 3 Specification of Inter-Domain QoS management Interfaces, March 2001, EDIN 0107-1008 [P1103] EURESCOM P1103 Project Inter-operator IP QoS Framework ToIP and UMTS Case Studies, D4 and D6 [PIR2.3] P1107 PIR 2.3, Experimentations and deployment guidelines, February 2002 [QoSRef2] Network Management Solutions for IP VPN Services, Cisco White Paper, Oct 2000 [RFC1633] R. Braden et al, IETF RFC 1633, Integrated Services in the Internet Architecture: an Overview, June 1994 [RFC1771] Y. Rekhter, T.J. Watson, T. Li, A Border Gateway Protocol 4 (BGP-4), RFC1771, March 1995 [RFC1918] Y. Rekhter at al, Address Allocation for Private Internets, RFC 1918, February 1996 [RFC1997] RFC 1997, BGP Communities Attribute, Chandra, Traina, and Li, August 1996. [RFC2205] R. Braden et al, IETF RFC 2205, Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification [RFC2211] J. Wroclawski, IETF RFC 2211, Specification of the Controlled-Load Network Element Service, September 1997 [RFC2212] S. Shenker et al, IETF RFC 2212, Specification of Guaranteed Quality of Service, September 1997 [RFC2251] IETF RFC 2251 Lightweight Directory Access Protocol (v3), M. Wahl, T. Howes, S. Kille, December 1997. http://www.ietf.org/rfc/rfc2251.txt [RFC2283] Bates, Chandra, Katz, Rekhter, IETF RFC 2283, Multiprotocol Extensions for BGP4, February 1998. [RFC2328] J. Moy, OSPF Version 2, RFC2328, April 1998 [RFC2401] Kent & Atkinson, RFC 2401 Security Architecture for EDIN 0298-1107 2002 EURESCOM Participants in Project P1107

EURESCOM Project Report page 69 (70) [RFC2402] [RFC2474] [RFC2475] [RFC2547] [RFC2597] [RFC2598] [RFC2764] [RFC2858] [RFC2940] [RFC3031] [RFC3032] [RFC3060] [RFC3084] [Schneier] [Sharma] [TMF GB917] [Y.1241] [Y.1311.1] [Y.1311] IP, Standards Track, November 1998 Kent & Atkinson, RFC 2402, IP Authentication Header, IETF, Standards Track, November 1998 K. Nichols et al, IETF RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, December 1998 S. Blake et al, IETF RFC 2475, An Architecture for Differentiated Services, December 1998 Rosen, E. and Rekhter, Y., "BGP/MPLS VPN," RFC2547, March 1999 J. Heinanen et al, IETF RFC 2597, Assured Forwarding PHB Group, June 1999 V. Jacobson et al, IETF RFC 2598, An Expedited Forwarding PHB, June 1999 B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis, A Framework for IP Based Virtual Private Networks, RFC2764, February 2000 RFC 2858, Multiprotocol Extensions for BGP4, Bates, Chandra, Katz, and Rekhter, June 2000. IETF RFC 2940 Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients. A. Smith, D. Partain, J. Seligson. October 2000. E. Rosen, Cisco Systems, Inc., A. Viswanathan, Force10 Networks, Inc., R. Callon, Juniper Networks, Inc., "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001 Moore et al, IETF RFC 3060, Policy Core Information Model Version 1 Specification, February 2001. IETF RFC 3084 COPS Usage for Policy Provisioning (COPS-PR). K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith, March 2001. Bruce Schneier, Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2), http://www.counterpane.com/pptpv2-paper.html Vishal Sharma, et. All Framework for MPLS-based Recovery, March 2001, work in progress. Telemanagement Forum: SLA management handbook ITU-T Recommendation Y.1241: Support of IP based Services using IP transfer Capability ITU-T Recommendation Y.1311.1, Network Based IP VPN over MPLS Architecture, 2001 ITU-T, Study Group 13 Temporary Document 4 (WP 3/13), Y.I311 - IP VPNs - Generic Architecture and Service Requirements, Caracas, 14-25 May 2001 2002 EURESCOM Participants in Project P1107 EDIN 0298-1107

(70) [Y.1540] [Y.1541] [Y.iptc] EURESCOM Project Report ITU-T Recommendation Y.1540, IP Packet Transfer and Availability Performance Parameters ITU-T Draft Recommendation Y.1541 : IP Performance And Availability Objectives and Allocations ITU-T Draft Recommendation Y.iptc: Traffic control and congestion control in IP based networks, by SG13 EDIN 0298-1107 2002 EURESCOM Participants in Project P1107