tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4110

Informational
Pages: 82
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: L3VPN

A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)

Part 1 of 4, p. 1 to 13
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                          R. Callon
Request for Comments: 4110                              Juniper Networks
Category: Informational                                        M. Suzuki
                                                         NTT Corporation
                                                               July 2005


                        A Framework for Layer 3
         Provider-Provisioned Virtual Private Networks (PPVPNs)

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document provides a framework for Layer 3 Provider-Provisioned
   Virtual Private Networks (PPVPNs).  This framework is intended to aid
   in the standardization of protocols and mechanisms for support of
   layer 3 PPVPNs.  It is the intent of this document to produce a
   coherent description of the significant technical issues that are
   important in the design of layer 3 PPVPN solutions.  Selection of
   specific approaches, making choices regarding engineering tradeoffs,
   and detailed protocol specification, are outside of the scope of this
   framework document.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1.  Objectives of the Document . . . . . . . . . . . . . . .  3
       1.2.  Overview of Virtual Private Networks . . . . . . . . . .  4
       1.3.  Types of VPNs. . . . . . . . . . . . . . . . . . . . . .  7
             1.3.1.  CE- vs PE-based VPNs . . . . . . . . . . . . . .  8
             1.3.2.  Types of PE-based VPNs . . . . . . . . . . . . .  9
             1.3.3.  Layer 3 PE-based VPNs. . . . . . . . . . . . . . 10
       1.4.  Scope of the Document. . . . . . . . . . . . . . . . . . 10
       1.5.  Terminology. . . . . . . . . . . . . . . . . . . . . . . 11
       1.6.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 13
   2.  Reference Models . . . . . . . . . . . . . . . . . . . . . . . 14
       2.1.  Reference Model for Layer 3 PE-based VPN . . . . . . . . 14
             2.1.1.  Entities in the Reference Model. . . . . . . . . 16
             2.1.2.  Relationship Between CE and PE . . . . . . . . . 18

Top      ToC       Page 2 
             2.1.3.  Interworking Model . . . . . . . . . . . . . . . 19
       2.2.  Reference Model for Layer 3 Provider-Provisioned
             CE-based VPN . . . . . . . . . . . . . . . . . . . . . . 21
             2.2.1.  Entities in the Reference Model. . . . . . . . . 22
   3.  Customer Interface . . . . . . . . . . . . . . . . . . . . . . 23
       3.1.  VPN Establishment at the Customer Interface. . . . . . . 23
             3.1.1.  Layer 3 PE-based VPN . . . . . . . . . . . . . . 23
                     3.1.1.1.  Static Binding . . . . . . . . . . . . 24
                     3.1.1.2.  Dynamic Binding. . . . . . . . . . . . 24
             3.1.2.  Layer 3 Provider-Provisioned CE-based VPN. . . . 25
       3.2.  Data Exchange at the Customer Interface. . . . . . . . . 25
             3.2.1.  Layer 3 PE-based VPN . . . . . . . . . . . . . . 25
             3.2.2.  Layer 3 Provider-Provisioned CE-based VPN. . . . 26
       3.3.  Customer Visible Routing . . . . . . . . . . . . . . . . 26
             3.3.1.  Customer View of Routing for Layer 3 PE-based
                     VPNs . . . . . . . . . . . . . . . . . . . . . . 26
                     3.3.1.1.  Routing for Intranets  . . . . . . . . 27
                     3.3.1.2.  Routing for Extranets  . . . . . . . . 28
                     3.3.1.3.  CE and PE Devices for Layer 3
                               PE-based VPNs. . . . . . . . . . . . . 29
             3.3.2.  Customer View of Routing for Layer 3 Provider-
                     Provisioned CE-based VPNs. . . . . . . . . . . . 29
             3.3.3.  Options for Customer Visible Routing . . . . . . 30
   4.  Network Interface and SP Support of VPNs . . . . . . . . . . . 32
       4.1.  Functional Components of a VPN . . . . . . . . . . . . . 32
       4.2.  VPN Establishment and Maintenance. . . . . . . . . . . . 34
             4.2.1.  VPN Discovery  . . . . . . . . . . . . . . . . . 35
                     4.2.1.1.  Network Management for Membership
                               Information. . . . . . . . . . . . . . 35
                     4.2.1.2.  Directory Servers. . . . . . . . . . . 36
                     4.2.1.3.  Augmented Routing for Membership
                               Information. . . . . . . . . . . . . . 36
                     4.2.1.4.  VPN Discovery for Inter-SP VPNs. . . . 37
             4.2.2.  Constraining Distribution of VPN Routing
                     Information  . . . . . . . . . . . . . . . . . . 38
             4.2.3.  Controlling VPN Topology . . . . . . . . . . . . 38
       4.3.  VPN Tunneling  . . . . . . . . . . . . . . . . . . . . . 40
             4.3.1.  Tunnel Encapsulations. . . . . . . . . . . . . . 40
             4.3.2.  Tunnel Multiplexing. . . . . . . . . . . . . . . 41
             4.3.3.  Tunnel Establishment . . . . . . . . . . . . . . 42
             4.3.4.  Scaling and Hierarchical Tunnels . . . . . . . . 43
             4.3.5.  Tunnel Maintenance . . . . . . . . . . . . . . . 45
             4.3.6.  Survey of Tunneling Techniques . . . . . . . . . 46
                     4.3.6.1.  GRE  . . . . . . . . . . . . . . . . . 46
                     4.3.6.2.  IP-in-IP Encapsulation . . . . . . . . 47
                     4.3.6.3.  IPsec. . . . . . . . . . . . . . . . . 48
                     4.3.6.4.  MPLS . . . . . . . . . . . . . . . . . 49
       4.4.  PE-PE Distribution of VPN Routing Information. . . . . . 51

Top      ToC       Page 3 
             4.4.1.  Options for VPN Routing in the SP. . . . . . . . 52
             4.4.2.  VPN Forwarding Instances . . . . . . . . . . . . 52
             4.4.3.  Per-VPN Routing  . . . . . . . . . . . . . . . . 53
             4.4.4.  Aggregated Routing Model . . . . . . . . . . . . 54
                     4.4.4.1.  Aggregated Routing with OSPF or IS-IS. 55
                     4.4.4.2.  Aggregated Routing with BGP. . . . . . 56
             4.4.5.  Scalability and Stability of Routing with Layer
                     3 PE-based VPNs. . . . . . . . . . . . . . . . . 59
       4.5.  Quality of Service, SLAs, and IP Differentiated Services 61
             4.5.1.  IntServ/RSVP . . . . . . . . . . . . . . . . . . 61
             4.5.2.  DiffServ . . . . . . . . . . . . . . . . . . . . 62
       4.6.  Concurrent Access to VPNs and the Internet . . . . . . . 62
       4.7.  Network and Customer Management of VPNs. . . . . . . . . 63
             4.7.1.  Network and Customer Management. . . . . . . . . 63
             4.7.2.  Segregated Access of VPN Information . . . . . . 64
   5.  Interworking Interface . . . . . . . . . . . . . . . . . . . . 66
       5.1.  Interworking Function. . . . . . . . . . . . . . . . . . 66
       5.2.  Interworking Interface . . . . . . . . . . . . . . . . . 66
             5.2.1.  Tunnels at the Interworking Interface. . . . . . 67
       5.3.  Support of Additional Services . . . . . . . . . . . . . 68
       5.4.  Scalability Discussion . . . . . . . . . . . . . . . . . 69
   6.  Security Considerations. . . . . . . . . . . . . . . . . . . . 69
       6.1.  System Security. . . . . . . . . . . . . . . . . . . . . 70
       6.2.  Access Control . . . . . . . . . . . . . . . . . . . . . 70
       6.3.  Endpoint Authentication  . . . . . . . . . . . . . . . . 70
       6.4.  Data Integrity . . . . . . . . . . . . . . . . . . . . . 71
       6.5.  Confidentiality. . . . . . . . . . . . . . . . . . . . . 71
       6.6.  User Data and Control Data . . . . . . . . . . . . . . . 72
       6.7.  Security Considerations for Inter-SP VPNs  . . . . . . . 72
   Appendix A: Optimizations for Tunnel Forwarding. . . . . . . . . . 73
       A.1.  Header Lookups in the VFIs . . . . . . . . . . . . . . . 73
       A.2.  Penultimate Hop Popping for MPLS . . . . . . . . . . . . 73
       A.3.  Demultiplexing to Eliminate the Tunnel Egress VFI Lookup 74
   Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 75
   Normative References . . . . . . . . . . . . . . . . . . . . . . . 76
   Informative References . . . . . . . . . . . . . . . . . . . . . . 76
   Contributors' Addresses. . . . . . . . . . . . . . . . . . . . . . 80

1.  Introduction

1.1.  Objectives of the Document

   This document provides a framework for Layer 3 Provider-Provisioned
   Virtual Private Networks (PPVPNs).  This framework is intended to aid
   in standardizing protocols and mechanisms to support interoperable
   layer 3 PPVPNs.

Top      ToC       Page 4 
   The term "provider-provisioned VPNs" refers to Virtual Private
   Networks (VPNs) for which the Service Provider (SP) participates in
   management and provisioning of the VPN, as defined in section 1.3.
   There are multiple ways in which a provider can participate in
   managing and provisioning a VPN; therefore, there are multiple
   different types of PPVPNs.  The framework document discusses layer 3
   VPNs (as defined in section 1.3).

   First, this document provides a reference model for layer 3 PPVPNs.
   Then technical aspects of layer 3 PPVPN operation are discussed,
   first from the customer's point of view, then from the providers
   point of view.  Specifically, this includes discussion of the
   technical issues which are important in the design of standards and
   mechanisms for the operation and support of layer 3 PPVPNs.
   Furthermore, technical aspects of layer 3 PPVPN interworking are
   clarified.  Finally, security issues as they apply to layer 3 PPVPNs
   are addressed.

   This document takes a "horizontal description" approach.  For each
   technical issue, it describes multiple approaches.  To specify a
   particular PPVPN strategy, one must choose a particular way of
   solving each problem, but this document does not make choices, and
   does not select any particular approach to support VPNs.

   The "vertical description" approach is taken in other documents,
   viz., in the documents that describe particular PPVPN solutions.
   Note that any specific solution will need to make choices based on SP
   requirements, customer needs, implementation cost, and engineering
   tradeoffs.  Solutions will need to chose between flexibility
   (supporting multiple options) and conciseness (selection of specific
   options in order to simplify implementation and deployment).  While a
   framework document can discuss issues and criteria which are used as
   input to these choices, the specific selection of a solution is
   outside of the scope of a framework document.

1.2.  Overview of Virtual Private Networks

   The term "Virtual Private Network" (VPN) refers to a set of
   communicating sites, where (a) communication between sites outside
   the set and sites inside the set is restricted, but (b) communication
   between sites in the VPN takes place over a network infrastructure
   that is also used by sites which are not in the VPN.  The fact that
   the network infrastructure is shared by multiple VPNs (and possibly
   also by non-VPN traffic) is what distinguishes a VPN from a private
   network.  We will refer to this shared network infrastructure as the
   "VPN Backbone".

Top      ToC       Page 5 
   The logical structure of the VPN, such as addressing, topology,
   connectivity, reachability, and access control, is equivalent to part
   of or all of a conventional private network using private facilities
   [RFC2764] [VPN-2547BIS].

   In this document, we are concerned only with the case where the
   shared network infrastructure (VPN backbone) is an IP and/or MPLS
   network.  Further, we are concerned only with the case where the
   Service Provider's edge devices, whether at the provider edge (PE) or
   at the Customer Edge (CE), determine how to route VPN traffic by
   looking at the IP and/or MPLS headers of the packets they receive
   from the customer's edge devices; this is the distinguishing feature
   of Layer 3 VPNs.

   In some cases, one SP may offer VPN services to another SP.  The
   former SP is known as a carrier of carriers, and the service it
   offers is known as "carrier of carriers" service.  In this document,
   in cases where the customer could be either an enterprise or SP
   network, we will make use of the term "customer" to refer to the user
   of the VPN services.  Similarly we will use the term "customer
   network" to refer to the user's network.

   VPNs may be intranets, in which the multiple sites are under the
   control of a single customer administration, such as multiple sites
   of a single company.  Alternatively, VPNs may be extranets, in which
   the multiple sites are controlled by administrations of different
   customers, such as sites corresponding to a company, its suppliers,
   and its customers.

   Figure 1.1.  illustrates an example network, which will be used in
   the discussions below.  PE1 and PE2 are Provider Edge devices within
   an SP network.  CE1, CE2, and CE3 are Customer Edge devices within a
   customer network.  Routers r3, r4, r5, and r6 are IP routers internal
   to the customer sites.

Top      ToC       Page 6 
      ............          .................          ............
      .          .          .               .          .          .
      .        +---+    +-------+       +-------+    +---+        .
      .   r3---|   |    |       |       |       |----|CE2|---r5   .
      .        |   |    |       |       |       |    +---+        .
      .        |CE1|----|  PE1  |       |  PE2  |      :          .
      .        |   |    |       |       |       |    +---+        .
      .   r4---|   |    |       |       |       |----|CE3|---r6   .
      .        +---+    +-------+       +-------+    +---+        .
      . Customer .          .    Service    .          . Customer .
      .  site 1  .          .  provider(s)  .          .  site 2  .
      ............          .................          ............

                Figure 1.1.: VPN interconnecting two sites.

   In many cases, Provider Edge (PE) and Customer Edge (CE) devices may
   be either routers or LSRs.

   In this document, the Service Providers' network is an IP or MPLS
   network.  It is desired to interconnect the customer network sites
   via the Service Providers' network.  Some VPN solutions require that
   the VPN service be provided either over a single SP network, or over
   a small set of closely cooperating SP networks.  Other VPN solutions
   are intended to allow VPN service to be provided over an arbitrary
   set of minimally cooperating SP networks (i.e., over the public
   Internet).

   In many cases, customer networks will make use of private IP
   addresses [RFC1918] or other non-unique IP address (i.e.,
   unregistered addresses); there is no guarantee that the IP addresses
   used in the customer network are globally unique.  The addresses used
   in one customer's network may overlap the addresses used in others.
   However, a single PE device can be used to provide VPN service to
   multiple customer networks, even if those customer networks have
   overlapping addresses.  In PE-based layer 3 VPNs, the PE devices may
   route the VPN traffic based on the customer addresses found in the IP
   headers; this implies that the PE devices need to maintain a level of
   isolation between the packets from different customer networks.  In
   CE-based layer 3 VPNs, the PEs do not make routing decisions based on
   the customer's private addresses, so this issue does not arise.  For
   either PE or CE-based VPNs, the fact that the VPNs do not necessarily
   use globally unique address spaces also implies that IP packets from
   a customer network cannot be transmitted over the SP network in their
   native form.  Instead, some form of encapsulation/tunneling must be
   used.

Top      ToC       Page 7 
   Tunneling is also important for other reasons, such as providing
   isolation between different customer networks, allowing a wide range
   of protocols to be carried over an SP network, etc.  Different QoS
   and security characteristics may be associated with different
   tunnels.

1.3.  Types of VPNs

   This section describes multiple types of VPNs, and some of the
   engineering tradeoffs between different types.  It is not up to this
   document to decide between different types of VPNs.  Different types
   of VPNs may be appropriate in different situations.

   There is a wide spectrum of types of possible VPNs, and it is
   difficult to split the types of VPNs into clearly distinguished
   categories.

   As an example, consider a company making use of a private network,
   with several sites interconnected via leased lines.  All routing is
   done via routers which are internal to the private network.

   At some point, the administrator of the private network might decide
   to replace the leased lines by ATM links (using an ATM service from
   an SP).  Here again all IP-level routing is done between customer
   premises routers, and managed by the private network administrator.

   In order to reduce the network management burden on the private
   network, the company may decide to make use of a provider-provisioned
   CE devices [VPN-CE].  Here the operation of the network might be
   unchanged, except that the CE devices would be provided by and
   managed by an SP.

   The SP might decide that it is too difficult to manually configure
   each CE-CE link.  This might lead the SP to replace the ATM links
   with a layer 2 VPN service between CE devices [VPN-L2].  Auto-
   discovery might be used to simplify configuration of links between CE
   devices, and an MPLS service might be used between CE devices instead
   of an ATM service (for example, to take advantage of the provider's
   high speed IP or MPLS backbone).

   After a while the SP might decide that it is too much trouble to be
   managing a large number of devices at the customers' premises, and
   might instead physically move these routers to be on the provider
   premises.  Each edge router at the provider premises might
   nonetheless be dedicated to a single VPN.  The operation might remain
   unchanged (except that links from the edge routers to other routers
   in the private network become MAN links instead of LAN links, and the
   link from the edge routers to provider core routers become LAN links

Top      ToC       Page 8 
   instead of MAN links).  The routers in question can now be considered
   to be provider edge routers, and the service provided by the SP has
   now become essentially a layer 3 VPN service.

   In order to minimize the cost of equipment, the provider might decide
   to replace several dedicated PE devices with a single physical router
   with the capability of running virtual routers (VR) [VPN-VR].
   Protocol operation may remain unchanged.  In this case the provider
   is offering a layer 3 VPN service making use of a VR capability.
   Note that autodiscovery might be used in a manner which is very
   similar to how it had been done in the layer 2 VPN case described
   above (for example, BGP might be used between VRs for discovery of
   other VRs supporting the same VPN).

   Finally, in order to simplify operation of routing protocols for the
   private network over the SP network, the provider might decide to
   aggregate multiple instances of routing into a single instance of BGP
   [VPN-2547BIS].

   In practice it is highly unlikely that any one network would actually
   evolve through all of these approaches at different points in time.
   However, this example illustrates that there is a continuum of
   possible approaches, and each approach is relatively similar to at
   least some of the other possible approaches for supporting VPN
   services.  Some techniques (such as auto-discovery of VPN sites) may
   be common between multiple approaches.

1.3.1.  CE- vs PE-based VPNs

   The term "CE-based VPN" (or Customer Edge-based Virtual Private
   Network) refers to an approach in which the PE devices do not know
   anything about the routing or the addressing of the customer
   networks.  The PE devices offer a simple IP service, and expect to
   receive IP packets whose headers contain only globally unique IP
   addresses.  What makes a CE-based VPN into a Provider-Provisioned VPN
   is that the SP takes on the task of managing and provisioning the CE
   devices [VPN-CE].

   In CE-based VPNs, the backbone of the customer network is a set of
   tunnels whose endpoints are the CE devices.  Various kinds of tunnels
   may be used (e.g., GRE, IP-in-IP, IPsec, L2TP, MPLS), the only
   overall requirement being that sending a packet through the tunnel
   requires encapsulating it with a new IP header whose addresses are
   globally unique.

   For customer provisioned CE-based VPNs, provisioning and management
   of the tunnels is the responsibility of the customer network
   administration.  Typically, this makes use of manual configuration of

Top      ToC       Page 9 
   the tunnels.  In this case the customer is also responsible for
   operation of the routing protocol between CE devices.  (Note that
   discussion of customer provisioned CE-based VPNs is out of scope of
   the document).

   For provider-provisioned CE-based VPNs, provisioning and management
   of the tunnels is the responsibility of the SP.  In this case the
   provider may also configure routing protocols on the CE devices.
   This implies that routing in the private network is partially under
   the control of the customer, and partially under the control of the
   SP.

   For CE-based VPNs (whether customer or provider-provisioned) routing
   in the customer network treats the tunnels as layer 2 links.

   In a PE-based VPN (or Provider Edge-based Virtual Private Network),
   customer packets are carried through the SP networks in tunnels, just
   as they are in CE-based VPNs.  However, in a PE-based VPN, the tunnel
   endpoints are the PE devices, and the PE devices must know how to
   route the customer packets, based on the IP addresses that they
   carry.  In this case, the CE devices themselves do not have to have
   any special VPN capabilities, and do not even have to know that they
   are part of a VPN.

   In this document we will use the generic term "VPN Edge Device" to
   refer to the device, attached to both the customer network and the
   VPN backbone, that performs the VPN-specific functions.  In the case
   of CE-based VPNs, the VPN Edge Device is a CE device.  In the case of
   PE-based VPNs, the VPN Edge Device is a PE device.

1.3.2.  Types of PE-based VPNs

   Different types of PE-based VPNs may be distinguished by the service
   offered.

   o Layer 3 service

     When a PE receives a packet from a CE, it determines how to forward
     the packet by considering both the packet's incoming link, and the
     layer 3 information in the packet's header.

   o Layer 2 service

     When a PE receives a frame from a CE, it determines how to forward
     the packet by considering both the packet's incoming link, and the
     layer 2 information in the frame header (such as FR, ATM, or MAC
     header).  (Note that discussion of layer 2 service is out of scope
     of the document).

Top      ToC       Page 10 
1.3.3.  Layer 3 PE-based VPNs

   A layer 3 PE-based VPN is one in which the SP takes part in IP level
   forwarding based on the customer network's IP address space.  In
   general, the customer network is likely to make use of private and/or
   non-unique IP addresses.  This implies that at least some devices in
   the provider network needs to understand the IP address space as used
   in the customer network.  Typically this knowledge is limited to the
   PE devices which are directly attached to the customer.

   In a layer 3 PE-based VPN, the provider will need to participate in
   some aspects of management and provisioning of the VPNs, such as
   ensuring that the PE devices are configured to support the correct
   VPNs.  This implies that layer 3 PE-based VPNs are by definition
   provider-provisioned VPNs.

   Layer 3 PE-based VPNs have the advantage that they offload some
   aspects of VPN management from the customer network.  From the
   perspective of the customer network, it looks as if there is just a
   normal network; specific VPN functionality is hidden from the
   customer network.  Scaling of the customer network's routing might
   also be improved, since some layer 3 PE-based VPN approaches avoid
   the need for the customer's routing algorithm to see "N squared"
   (actually N*(N-1)/2) point to point duplex links between N customer
   sites.

   However, these advantages come along with other consequences.
   Specifically, the PE devices must have some knowledge of the routing,
   addressing, and layer 3 protocols of the customer networks to which
   they attach.  One consequence is that the set of layer 3 protocols
   which can be supported by the VPN is limited to those supported by
   the PE (which in practice means, limited to IP).  Another consequence
   is that the PE devices have more to do, and the SP has more
   per-customer management to do.

   An SP may offer a range of layer 3 PE-based VPN services.  At one end
   of the range is a service limited to simply providing connectivity
   (optionally including QoS support) between specific customer network
   sites.  This is referred to as "Network Connectivity Service".  There
   is a spectrum of other possible services, such as firewalls, user or
   site of origin authentication, and address assignment (e.g., using
   Radius or DHCP).

1.4.  Scope of the Document

   This framework document will discuss methods for providing layer 3
   PE-based VPNs and layer 3 provider-provisioned CE-based VPNs.  This
   may include mechanisms which will can be used to constrain

Top      ToC       Page 11 
   connectivity between sites, including the use and placement of
   firewalls, based on administrative requirements [PPVPN-REQ]
   [L3VPN-REQ].  Similarly the use and placement of NAT functionality is
   discussed.  However, this framework document will not discuss methods
   for additional services such as firewall administration and address
   assignment.  A discussion of specific firewall mechanisms and
   policies, and detailed discussion of NAT functionality, are outside
   of the scope of this document.

   This document does not discuss those forms of VPNs that are outside
   of the scope of the IETF Provider-Provisioned VPN working group.
   Specifically, this document excludes discussion of PPVPNs using VPN
   native (non-IP, non-MPLS) protocols as the base technology used to
   provide the VPN service (e.g., native ATM service provided using ATM
   switches with ATM signaling).  However, this does not mean to exclude
   multiprotocol access to the PPVPN by customers.

1.5.  Terminology

   Backdoor Links: Links between CE devices that are provided by the end
   customer rather than the SP; may be used to interconnect CE devices
   in multiple-homing arrangements.

   CE-based VPN: An approach in which all the VPN-specific procedures
   are performed in the CE devices, and the PE devices are not aware in
   any way that some of the traffic they are processing is VPN traffic.

   Customer: A single organization, corporation, or enterprise that
   administratively controls a set of sites belonging to a VPN.

   Customer Edge (CE) Device: The equipment on the customer side of the
   SP-customer boundary (the customer interface).

   IP Router: A device which forwards IP packets, and runs associated IP
   routing protocols (such as OSPF, IS-IS, RIP, BGP, or similar
   protocols).  An IP router might optionally also be an LSR.  The term
   "IP router" is often abbreviated as "router".

   Label Switching Router: A device which forwards MPLS packets and runs
   associated IP routing and signaling protocols (such as LDP, RSVP-TE,
   CR-LDP, OSPF, IS-IS, or similar protocols).  A label switching router
   is also an IP router.

   PE-Based VPNs: The PE devices know that certain traffic is VPN
   traffic.  They forward the traffic (through tunnels) based on the
   destination IP address of the packet, and optionally on based on
   other information in the IP header of the packet.  The PE devices are

Top      ToC       Page 12 
   themselves the tunnel endpoints.  The tunnels may make use of various
   encapsulations to send traffic over the SP network (such as, but not
   restricted to, GRE, IP-in-IP, IPsec, or MPLS tunnels).

   Private Network: A network which allows communication between a
   restricted set of sites, over an IP backbone that is used only to
   carry traffic to and from those sites.

   Provider Edge (PE) Device: The equipment on the SP side of the
   SP-customer boundary (the customer interface).

   Provider-Provisioned VPNs (PPVPNs): VPNs, whether CE-based or
   PE-based, that are actively managed by the SP rather than by the end
   customer.

   Route Reflectors: An SP-owned network element that is used to
   distribute BGP routes to the SP's BGP-enabled routers.

   Virtual Private Network (VPN): Restricted communication between a set
   of sites, making use of an IP backbone which is shared by traffic
   that is not going to or coming from those sites.

   Virtual Router (VR): An instance of one of a number of logical
   routers located within a single physical router.  Each logical router
   emulates a physical router using existing mechanisms and tools for
   configuration, operation, accounting, and maintenance.

   VPN Forwarding Instance (VFI): A logical entity that resides in a PE
   that includes the router information base and forwarding information
   base for a VPN.

   VPN Backbone: IP and/or MPLS network which is used to carry VPN
   traffic between the customer sites of a particular VPN.

   VPN Edge Device: Device, attached to both the VPN backbone and the
   customer network, which performs VPN-specific functions.  For
   PE-based VPNs, this is the PE device; for CE-based VPNs, this is the
   CE device.

   VPN Routing: Routing that is specific to a particular VPN.

   VPN Tunnel: A logical link between two PE or two CE entities, used to
   carry VPN traffic, and implemented by encapsulating packets that are
   transmitted between those two entities.

Top      ToC       Page 13 
1.6.  Acronyms

   ATM             Asynchronous Transfer Mode
   BGP             Border Gateway Protocol
   CE              Customer Edge
   CLI             Command Line Interface
   CR-LDP          Constraint-based Routing Label Distribution Protocol
   EBGP            External Border Gateway Protocol
   FR              Frame Relay
   GRE             Generic Routing Encapsulation
   IBGP            Internal Border Gateway Protocol
   IKE             Internet Key Exchange
   IGP             Interior Gateway Protocol
                   (e.g., RIP, IS-IS and OSPF are all IGPs)
   IP              Internet Protocol (same as IPv4)
   IPsec           Internet Protocol Security protocol
   IPv4            Internet Protocol version 4 (same as IP)
   IPv6            Internet Protocol version 6
   IS-IS           Intermediate System to Intermediate System routing
                   protocol
   L2TP            Layer 2 Tunneling Protocol
   LAN             Local Area Network
   LDAP            Lightweight Directory Access Protocol
   LDP             Label Distribution Protocol
   LSP             Label Switched Path
   LSR             Label Switching Router
   MIB             Management Information Base
   MPLS            Multi Protocol Label Switching
   NBMA            Non-Broadcast Multi-Access
   NMS             Network Management System
   OSPF            Open Shortest Path First routing protocol
   P               Provider equipment
   PE              Provider Edge
   PPVPN           Provider-Provisioned VPN
   QoS             Quality of Service
   RFC             Request For Comments
   RIP             Routing Information Protocol
   RSVP            Resource Reservation Protocol
   RSVP-TE         Resource Reservation Protocol with Traffic
                   Engineering Extensions
   SNMP            Simple Network Management Protocol
   SP              Service Provider
   VFI             VPN Forwarding Instance
   VPN             Virtual Private Network
   VR              Virtual Router


Next RFC Part