INTERNET DRAFT Ron Bonica, WorldCom Network Working Group Shahram Davari, PMC-Sierra Paul Doolan, Ennovate Networks Avri Doria, Nortel Networks Tim Dwight, Marconi Tom Worster, Ennovate Networks Expires Aug 22 2001 A PPVPN Layer Separation: VPN Tunnels and Core Connectivity This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract A protocol layering is proposed for the PPVPN WG's framework and architecture work in which VPN Tunnels are separated from core network connectivity services. Worster, et. al. Expires Aug 22 2001 [Page 1] Internet Draft PPVPN Layer Separation Feb 23 2001 Table of Contents 1. Motivation ................................................... 2 2. Layering definition .......................................... 3 3. Proposals .................................................... 6 4. Security Considerations ...................................... 6 1. Motivation A great many examples have shown that protocol layering can successfully be used to simplify the design of communications systems by partitioning responsibilities within a communications system into sub-systems (e.g. layers). Such partitioning helps designers manage the overall complexity of system-internal interactions through the definition of formal inter-sub-system interactions. Sometimes, overall design complexity can be reduced by adding one or more sub-systems or protocol layers. The authors have noticed that a useful protocol layering is emerging in the PPVPN design space, i.e. the separation of the "VPN Client Application" from "Core Connectivity Services." We say that the layering is emerging in the sense that it is already visible in several network based VPN deployments (see e.g. [1], [2], and [3]) and some published protocol work (see e.g. [5] Chapter 5 "Forwarding Across the Backbone"). We say that it is useful in the sense that it simplifies the VPN Client Application, and therefore also the PPVPN WG's work, by providing the client with a uniform service access point (SAP) to core connectivity services. The client then becomes core network protocol agnostic and may be designed to be completely unaware of core network protocols. The layering is particularly valuable in two ways: - it allows separation of the design of encapsulations from the design of control protocols for the VPN Client Application, and - it allows such control protocol to be fully independent of core connectivity protocols. Worster, et. al. Expires Aug 22 2001 [Page 2] Internet Draft PPVPN Layer Separation Feb 23 2001 2. Layering definition The following diagram shows the client-server relationship between what we call here the "VPN Client Application" (or just VPN Client) and the PE Node's common, or platform level, "Core Connectivity Services." +--------------------+ +--------------------+ | PE Node | | PE Node | | | VPN | | | +--------+ | Control | +--------+ | | | VPN | | Protocol | | VPN | | | | Client |<-------------------------->| Client | | | | Appl. | | | | Appl. | | | +---+----+ | | +---+----+ | | | | | | | | +-+-+-+----------+| |+-----+-+-+------+ | | | |SAP| || || |SAP| | | | | +---+ || || +---+ | | | | Core || Core || Core | | | | Connectivity || Protocols || Connectivity | | | | Services ||<============>|| Services | | | | || || | | | +----------------+| |+----------------+ | +--------------------+ +--------------------+ Examples of Core Protocols are IPv4, IPv4+MPLS, or ATM; they provide connectivity between PE (Provider Edge) Nodes across a core (inter)network*. Such connectivity may be provided with certain service level assurances such as those derived from the use of Diff-serv, MPLS or ATM in the core network. Core Connectivity Services may be used by other client applications, for example by routeing protocols or other service applications such as VoIP. If, as in the case with MPLS or ATM, tunnels or connections are inherent to the Core Protocols (we call such tunnels collectively Core Tunnels) and these Core Tunnels are used for inter-PE connectivity, then a Core Tunnel may be shared by the VPN Client and other clients. If inter-PE connectivity is provided with some service level assurance then the Core Connectivity Service is responsible for assuring that level of service to its clients, for example by ________________________ * The "core network" in this text is equivalent to the "backbone" in [5] Worster, et. al. Expires Aug 22 2001 [Page 3] Internet Draft PPVPN Layer Separation Feb 23 2001 reserving appropriate core network resources for these clients, collectively or individually. The Core Connectivity Service must therefore be made aware of the needs of its clients in terms of bandwidth and QoS. The VPN Client Application is responsible for VPN specific functions such as: separation of traffic from different VPNs, knowing to which remote PEs given packets ought to be sent, and much besides, see [4]. The VPN Client needs core connectivity to certain remote PEs and it may also need that connectivity with a certain level of service assurance. The client may or may not actively inform the Core Connectivity Service of its needs (this is essentially the signalling vs. provisioning design choice). A VPN Control Protocol may be used between VPN Client Applications on different PE Nodes. Such a protocol can be useful for authentication of peer PE Nodes, auto-discovery of peer PEs' involvement in certain VPNs, learning about remote VPN sites attached to on peer PE nodes, and controlling VPN Tunnels between PE Nodes. The control protocol is optional, all of these functions may be handled by other means, for example, through the automated use of management protocols. Worster, et. al. Expires Aug 22 2001 [Page 4] Internet Draft PPVPN Layer Separation Feb 23 2001 The PPVPN Framework [4] has defined the VPN Tunnel as the multiplexing structure that separates the traffic belonging to different VPNs. That, together with the proposed network architectural layering leads to a natural layering of protocol data units, as shown below. + - - +---------------------------+--------+-------------+ | Private | VPN | Core | | CPT | User | Tunnel | Protocol | | Payload | Header | Headers | + - - +---------------------------+--------+-------------+ The Private User Payload is the customer's packet that is to be forwarded across the VPN to another customer site. The Core Protocol Headers are used by the PE and Core Network to deliver the packet to the appropriate PE Node (CPT is a Core Protocol Trailer e.g. AAL5-CPCS). The VPN Tunnel Header is used by the receiving PE Node to determine to which VPN the packet belongs and potentially also its next-hop. Examples of each of these protocols are shown in the diagram below. | Examples of | Exmpls.| Examples | Private User | of VPN | of Core CPT | Payload Protocols | Tunnels| Protocols ------+---------------------------+--------+-------------- -AAL5 | -Priv. addr. IPv4 | -MPLS | -MPLS LSE(s) Trlr | -Pub. addr. IPv6 | LSP | -MPLS-in-1483 | -IPSec | | -MPLS-in-IPv4 | -IPX | | -GRE-in-IPv4 | -NetBEUI | | -IPSec | -Appletalk | | -L2TP The fundamental benefit of this layering can now be stated thus: - Without such layering PPVPN would need to provide solutions, for both the VPN Control Protocol as well as the protocol encapsulations, that address the N-by-M matrix of protocol interactions where N is the number of in scope Private User Payload Protocols and M is the number of in scope Core Protocols. - With the proposed layering PPVPN need only provide: o a VPN Tunnel encapsulation protocol with multi-protocol payload support, o encapsulations of the VPN Tunnel into the in scope Core Protocols, and Worster, et. al. Expires Aug 22 2001 [Page 5] Internet Draft PPVPN Layer Separation Feb 23 2001 o a VPN Control Protocol for controlling VPN Tunnels. An immediate follow on benefit is that the control protocol does not need to refer to Core Protocols or entities within Core Protocols such as Core Tunnels. For example, generalisation of BGP/MPLS VPNs [5] to operate across core networks types other than MPLS, such as over IPSec tunnels as was proposed in [6], would not affect the BGP/MPLS VPNs protocol itself since the layering hides such tunnels from that protocol. 3. Proposals The authors propose that the PPVPN WG: - adopt the above layering into the PPVPN Framework, - formally separate encapsulation work from control protocol work, and - consider the use of MPLS LSPs as a suitable canonical VPN Tunnel. 4. Security Considerations Security is not addressed in this document at this stage. The proposal is intended to fold into the PPVPN Framework. If it is adopted for that purpose the security considerations will be addressed there. References [1] Luyuan Fang, "Incremental Deployment of MPLS VPN in Large ISP Networks," MPLS World Congress 2001, Paris, Feb 2001. [2] Chris Gibbings, "Migrating to an MPLS backbone," MPLS World Congress 2001, Paris, Feb 2001. [3] Ron Rydz, "Advanced IP Services using PASTA Servcies," MPLS World Congress 2001, Paris, Feb 2001. [4] Callon et al, "PPVPN Framework," work in progress, Internet-Draft, Feb 2001. [5] Rosen et al, "BGP/MPLS VPNs," work in progress, Internet- Draft rev-02, July 2000. Worster, et. al. Expires Aug 22 2001 [Page 6] Internet Draft PPVPN Layer Separation Feb 23 2001 [6] De Clercq et al, "BGP/IPsec VPN," work in progress, Internet-Draft rev-00, July 2000. Authors' Addresses Ronald P. Bonica WorldCom 22001 Loudoun County Parkway Ashburn, Virginia 20147 Email: ronald.p.bonica@wcom.com Tel: +1 703 886 1681 Shahram Davari PMC-Sierra, Inc. 411 Legget Drive, Kanata, Ontario, Canada Tel: +1 613 271-4018 Fax: +1 613 271-7007 Paul Doolan Ennovate Networks, Inc. 60 Codman Hill Road Boxborough, Mass, 01719 Email: pdoolan@ennovatenetworks.com Tel: +1 978 206 0529 Fax: +1 978 263 1099 Avri Doria Nortel Networks 600 Technology Park Drive Billerica, Mass Email: avri@nortelnetworks.com Tel: +1 978 288 6627 Tim Dwight Marconi Communications 8616 Freeport Parkway Access Products Irving, Texas, 75063 Email: tim.dwight@marconi.com Tel: +1 972-916-4170 Worster, et. al. Expires Aug 22 2001 [Page 7] Internet Draft PPVPN Layer Separation Feb 23 2001 Tom Worster (contact for comments) Ennovate Networks, Inc. 60 Codman Hill Road Boxborough, Mass, 01719 Email: tom@ennovatenetworks.com A.I.M.: "the fsb" Tel: +1 978 206 0490 Fax: +1 978 263 1099 Worster, et. al. Expires Aug 22 2001 [Page 8]