[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

Network Working Group                                         R. Callon
Internet Draft                                         Juniper Networks
Expires: January 2002                                         M. Suzuki
                                                        NTT Corporation
                                                             B. Gleeson
                                                             Consultant
                                                               A. Malis
                                                  Vivace Networks, Inc.
                                                       K. Muthukrishnan
                                                    Lucent Technologies
                                                             Eric Rosen
                                                          Cisco Systems
                                                         Chandru Sargor
                                                  CoSine Communications
                                                      Jieyun Jessica Yu

                                                          July 19, 2001


     A Framework for Provider Provisioned Virtual Private Networks
                  <draft-ietf-ppvpn-framework-01.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   This document provides a framework for Provider Provisioned Virtual
   Private Networks (PPVPNs).  This framework is intended to aid in the



Design Team               Expires January 2002                  [Page 1]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   standardization of protocols and mechanisms for support of PPVPNs.
   It is the intent of this document to produce a coherent description
   of the significant technical issues which are important in the design
   of PPVPN solutions.  Selection of  specific approaches, making
   choices regarding engineering tradeoffs, and detailed protocol
   specification, are outside of the scope of this framework document.


1. Introduction

1.1 Objectives of the Document

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

   The term "provider provisioned VPNs" refers to Virtual Private
   Networks (VPNs) for which the service provider 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 a VPN,
   and there are therefore multiple different types of PPVPNs.  The
   current draft of this framework document discusses layer 2 and layer
   3 VPNs (as defined in section 1.3).  Future revisions of this
   document will be enhanced to describe technical issues related to
   VPNs in which the provider participates in provisioning for CE-based
   equipment.

   This document gives a brief overview of requirements for PPVPNs.
   Requirements are discussed in more detail in [PPVPN-REQ].  We discuss
   reference models for PPVPNs.  We discuss technical aspects of PPVPN
   operation from the customers point of view.  We discuss technical
   aspects of PPVPNs 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 support of PPVPNs.  We
   also discuss security issues as they apply to PPVPNs.

   This document will take a "horizontal description" approach, in that
   it describes issues, technology, and the possible solutions to each
   problem.  We will therefore describe multiple possible solutions
   which may be used for each particular issue which arises in the
   design of VPN solutions.  This document does not make choices, and
   does not select any particular approach to support VPNs.

   Other documents will be needed to take a "vertical description"
   approach, in that they will specify one or more complete protocols
   for support of VPNs.  Note that any specific solution will need to
   make choices based on SP requirements, customer needs, implementation



Design Team               Expires January 2002                  [Page 2]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   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 the communication
   between a set of sites, making use of a shared network
   infrastructure.  Multiple sites of a private network may therefore
   communicate via the public infrastructure, in order to facilitate the
   operation of the private network.  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.

   In some cases VPN services may be used to interconnect multiple parts
   of a public or service provider network.  This case is generally
   known as a "carrier of carrier" service.  In this document, in cases
   where the user could be either a private or service provider 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 support intranets, in which the multiple sites are under the
   control of a single customer administration, such as multiple sites
   of a single company.  VPNs may also support 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 a 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.












Design Team               Expires January 2002                  [Page 3]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


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

                Figure 1.1: VPN interconnecting two sites.


   In general provider edge (PE) and customer edge (CE) devices may be
   either routers, hosts or switches or bridges of various kinds.  Some
   approaches may limit the type of PE and/or CE device that can be
   used.  For example, in some approaches the PE devices may be required
   to be IP routers.

   It is desired to interconnect the customer network sites via the
   service provider network.

   In many cases, customer networks will make use of private IP
   addresses [RFC1918].  This implies that there is no guarantee that
   the IP addresses used in the customer network are globally unique.
   In the case that a single PE router provides services to multiple
   different customer networks, this implies that the addresses uses in
   the different customer networks may overlap.  The internal operation
   of the PE device needs to maintain a level of isolation between the
   packets from different customer networks.  This also implies that the
   IP packets from the customer network cannot be transmitted in their
   native form across the public network.  Instead, some form of
   encapsulation/tunneling must be used.

   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 a public 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



Design Team               Expires January 2002                  [Page 4]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   of VPNs may be appropriate in different situations.

1.3.1 CE-based vs network-based VPNs

   The term "CE-based VPN" (or Customer Edge-based virtual private
   network) refers to an approach in which (ignoring management systems)
   knowledge of the customer network is limited to customer premise
   equipment.  In a classical CE-based VPN, the service provider is
   oblivious to the existence of the customer network.  The provider may
   be offering a simple IP service, ATM service, or Frame Relay service.
   However, it is common for a service provider to take on the task of
   managing and provisioning the Customer Edge equipment, in order to
   reduce the management requirements of the customer.  This results in
   provider provisioned CE-based VPNs.

   In CE-based VPNs, the customer network is supported by tunnels which
   are set up between CE devices.  If the provider offers an ATM or
   Frame Relay service, the tunnels may consist of simple link layer
   connections.  If the provider offers IP service, then the tunnels may
   make use of various encapsulations to sent traffic over IP (such as
   GRE, IP-in-IP, IPsec, L2TP, or MPLS tunnels).

   For classical CE-based VPNs, provisioning and management of the
   tunnels is up to the customer network administration.  Typically this
   may make use of manual configuration of the tunnels.  For Provider
   Provisioned CE-based VPNs, provisioning and management of the tunnels
   is up to the service provider.

   For CE-based VPNs (whether classical or provider provisioned) routing
   in the customer network thinks of the tunnels as simple point to
   point links, or in some cases as broadcast LANs.

   A network-based VPN (NBVPN) is one in which equipment in the SP
   network provides the VPN.  This allows the existence of the VPN to be
   hidden from the CE devices, which can operate as if part of a normal
   customer network.

   In NBVPNs, the customer network is supported by tunnels which are set
   up between PE equipment.  The tunnels may make use of various
   encapsulations to sent traffic over the SP network (such as GRE,
   IPsec, IP-in-IP, or MPLS tunnels).

1.3.2 Types of network-based VPNs

   Different types of NBVPNs may be distinguished by the service
   offered.





Design Team               Expires January 2002                  [Page 5]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   o Layer 3 service

     Provider forwards packets based on layer 3 information, as well as
     on the basis of the incoming link.

   o Layer 2 service

     Provider forwards packets based on layer 2 addresses (such as frame
     relay, ATM, MAC address or MPLS label) and/or on the basis of the
     incoming link.

1.3.2.1 Layer 3 network-based VPNs

   A layer 3 network-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 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
   Provider Edge (PE) equipment which is directly attached to the
   customer.  For a layer 3 NBVPN, the PE device must be an IP router.

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

   Layer 3 NBVPNs have the advantage that they offload some aspects of
   VPN management from the customer network.  Scaling of customer
   network routing is also improved, since it avoids the need for "N
   squared" (actually N*(N-1)/2) point to point links between n customer
   sites.  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).

   However, these advantages come along with other consequences.
   Specifically, the public network has to know about the customer
   network.  This adds work to the public network, and limits the
   protocols which can be supported by the VPN.  Given that PE equipment
   needs to forward packets directly from the customer network, using
   the customer network's address space, this implies that PE equipment
   needs to participate in some manner in routing for as many customer
   networks as the PE equipment supports.  The protocols supported are
   limited to those which are understood by the PE device, which
   typically means only IP is supported.





Design Team               Expires January 2002                  [Page 6]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   A service provider may offer a range of layer 3 NBVPN 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.3.2.2 Layer 2 network-based VPNs

   A layer 2 network-based VPN is one in which the network is aware of
   the VPN, but does only layer 2 forwarding and signaling.  This
   implies that the SP provisions and maintains layer 2 connections
   between CE equipment.

   Forwarding options include MAC addresses (such as LAN emulation), use
   of point-to-point link layer connections (ATM, Frame Relay, or MPLS),
   multipoint-to-point (using MPLS multipoint to point LSPs), and point-
   to-multipoint (e.g., ATM VCCs).

   For a layer 2 NBVPN, the PE device may be a router or a switch.  From
   the CE's perspective, the PE will be operating as a switch.

1.4 Scope of the Document

   This framework document will discuss methods for providing network
   connectivity service.  This may include mechanisms which will can be
   used to constrain connectivity between sites, including the use and
   placement of firewalls, based on administrative requirements.
   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 which are outside
   of the scope of the IETF Provider Provisioned VPN working group.
   Specifically, this document excludes discussion of:

   o NBVPNs 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 NBVPN by
     customers.

   o Virtual leased lines, which provide a point-to-point link between
     two customer sites based on SONET, optical, or physical links.



Design Team               Expires January 2002                  [Page 7]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


1.5 Terminology

   Backdoor Links
   CE-based VPN
   Customer
   Customer Edge Equipment
   Customer Premise Equipment
   Network-Based VPNs
   Port
   Port Based VPNs
   Provider Edge equipment
   Provider Provisioned VPNs
   Route Reflectors
   Virtual Forwarding Instance
   Virtual Private Network
   Virtual Router
   VPN Tunnels

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
   MIB             Management Information Base
   MPLS            Multi Protocol Label Switching
   NBMA            Non-Broadcast Multi-Access
   NBVPN           Network-Based VPN
   NMS             Network Management System



Design Team               Expires January 2002                  [Page 8]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   OSPF            Open Shortest Path First routing protocol
   P               Provider equipment
   PE              Provider Edge equipment
   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             Virtual Forwarding Instance
   VSI             Virtual Switching Instance
   VPN             Virtual Private Network
   VR              Virtual Router
   VRF             VPN Routing and Forwarding


2. A Brief Overview of Requirements

   Detailed requirements for PPVPNs are outside of the scope of this
   document, and are being pursued in a separate effort [PPVPN-REQ].
   This section gives only a very brief overview of requirements for
   PPVPNs.

   o Security/privacy

     The basic goal of a VPN service is to provide connectivity within a
     closed user group (CUG).  Other user sites (outside of a VPN)
     cannot reach them.  User traffic and control information relating
     to one customer network needs to be kept separate from user traffic
     and control information for other customer networks.  There are a
     wide range of different levels of security and privacy which may be
     offered.  Different levels may be appropriate in different cases.

   o Quality of service

     QoS/SLA services may for example provide guaranteed and/or
     differentiated communications with VPN-specific SLAs covering
     characteristics such as loss rates, delay, delay variation, and
     bandwidth etc.  Various classes of QoS are provided, although they
     may depend on the supporting technologies.

   o Scaling

     There are many aspects of scaling, which need to be considered in
     evaluation of methods for supporting VPNs.  Some dimensions of



Design Team               Expires January 2002                  [Page 9]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


     scaling include: The number of VPNs supported in a single piece of
     PE equipment, the total number of VPNs supported in a service
     provider network, the size of each VPN, scaling of the provisioning
     and management system, the amount of bandwidth supported (per VPN
     and in aggregate).  Scaling also has implications in multiple
     dimensions of the design of a solution, as is discussed later in
     this document.

   o Management

     Ease of management is an important consideration in the design and
     evaluation of VPN solutions.  Network management personnel are
     scarce, for both customer networks and service providers.  Also,
     network management errors can have significant adverse effects on
     network availability, reliability, and security.  It is therefore
     important to minimize the network management effort required in
     support of VPNs.

   o Intranets

     A VPN solution must support intranets: This is, networks in which
     multiple sites are interconnected, where each site belongs to one
     single administration.

   o Extranets

     A VPN solution should support extranets: That is, networks in which
     sites belonging to one administration desire constrained
     connectivity with multiple sites belonging to multiple other
     administrations.  For example, a equipment manufacturer might want
     extranet connectivity with suppliers and customers.  However, two
     companies which are both the customer of the same third company
     might nonetheless not want or need direct communication with each
     other.

   o VPN support across multiple service providers

     A PPVPN service over multiple SPs service enables a single VPN to
     cover sites supported by different SPs.

   o Multicast

     Some VPN services may require multicast support.








Design Team               Expires January 2002                 [Page 10]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


3. Reference Models

   This section describes reference models for PPVPN that provides
   services as mentioned in sections 1 and 2.  The purpose of discussing
   reference models is to clarify the common components and pieces that
   are needed to build and deploy a PPVPN.  Three types of VPNs, layer 3
   network-based VPN, layer 2 network-based VPN, and provider
   provisioned CE-based VPN, are covered in separated sections below.

3.1 Reference Model for Layer 3 NBVPN

   This subsection describes functional components and their
   relationship for implementing layer 3 network-based VPN.

   Figure 3.1 shows the reference model for layer 3 NBVPNs and Figures
   3.2 and 3.3 show relationship between entities in the reference
   model.

    +---------+  +------------------------------------+  +---------+
    |         |  |                                    |  |         |
    |         |  |                     +------+     +------+  : +------+
+------+ :    |  |                     |      |     |      |  : |  CE  |
|  CE  | :    |  |                     |  P   |     |  PE  |  : |device|
|device| :  +------+   VPN tunnel   :  |router|     |router|  : |  of  |
|  of  |-:--|      |================:===============|      |--:-|VPN  A|
|VPN  A| :  |      |                :  +------+     +------+  : +------+
+------+ :  |  PE  |                :                 |  |    :    |
+------+ :  |router|        Network interface         |  |    :    |
|  CE  | :  |      |                :               +------+  : +------+
|device|-:--|      |================:===============|      |--:-|  CE  |
|  of  | :  +------+                :  VPN tunnel   |  PE  |  : |device|
|VPN  B| :    |  |                                  |router|  : |  of  |
+------+ :    |  |  +------------+   +------------+ |      |  : |VPN  B|
    |    :    |  |  |  Customer  |   |  Network   | +------+  : +------+
    |Customer |  |  | management |   | management |   |  |    :    |
    |interface|  |  |  function  |   |  function  |   |  |Customer |
    |         |  |  +------------+   +------------+   |  |interface|
    |         |  |                                    |  |         |
    +---------+  +------------------------------------+  +---------+
    | Access  |  |<---------- SP network(s) --------->|  | Access  |
    | network |  |   single or multiple SP domains    |  | network |

             Figure 3.1: Reference model for layer 3 NBVPN.








Design Team               Expires January 2002                 [Page 11]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


               +----------+                  +----------+
+-----+        |PE router |                  |PE router |        +-----+
| CE  |        |          |                  |          |        | CE  |
| dev | Access | +------+ |                  | +------+ | Access | dev |
| of  |  conn. | |VFI of| |    VPN tunnel    | |VFI of| |  conn. | of  |
|VPN A|----------|VPN A |======================|VPN A |----------|VPN A|
+-----+        | +------+ |                  | +------+ |        +-----+
               |          |                  |          |
+-----+ Access | +------+ |                  | +------+ | Access +-----+
| CE  |  conn. | |VFI of| |    VPN tunnel    | |VFI of| |  conn. | CE  |
| dev |----------|VPN B |======================|VPN B |----------| dev |
| of  |        | +------+ |                  | +------+ |        | of  |
|VPN B|        |          |                  |          |        |VPN B|
+-----+        +----------+                  +----------+        +-----+

   Figure 3.2: Relationship between entities in reference model (1).


               +----------+                  +----------+
+-----+        |PE router |                  |PE router |        +-----+
| CE  |        |          |                  |          |        | CE  |
| dev | Access | +------+ |                  | +------+ | Access | dev |
| of  |  conn. | |VFI of| |                  | |VFI of| |  conn. | of  |
|VPN A|----------|VPN A | |                  | |VPN A |----------|VPN A|
+-----+        | +------+\|      Tunnel      |/+------+ |        +-----+
               |          >==================<          |
+-----+ Access | +------+/|                  |\+------+ | Access +-----+
| CE  |  conn. | |VFI of| |                  | |VFI of| |  conn. | CE  |
| dev |----------|VPN B | |                  | |VPN B |----------| dev |
| of  |        | +------+ |                  | +------+ |        | of  |
|VPN B|        |          |                  |          |        |VPN B|
+-----+        +----------+                  +----------+        +-----+

   Figure 3.3: Relationship between entities in reference model (2).


3.1.1 Entities in the reference model

   The entities in the reference model are described below.

   o Customer edge (CE) device

     A CE device is a device on the customer site which has an access
     connection to a PE router.  It may be a router, host, or switch
     located at the edge of a user site.






Design Team               Expires January 2002                 [Page 12]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   o P router

     A router within a provider network which is used to interconnect PE
     routers, but which does not have any VPN state and does not have
     any direct attachment to CE devices.

   o Provider edge (PE) router

     A PE router is attached via an access connection to one or more CE
     devices.  In the context of supporting layer 3 VPNs, a PE router
     implements one or more VFIs and maintains per-VPN state.  (Note
     that access connections are terminated by VFIs from the functional
     point of view.)

   o Customer site

     A customer site is a set of users that have mutual IP reachability
     without use of a specific service provider network.

   o SP networks

     An SP network is a network administered by a single service
     provider.

   o Access connection

     An access connection represents an isolated layer 2 connectivity
     between a CE device and a PE router.  This includes dedicated
     physical circuits, logical circuits (such as Frame Relay, ATM, and
     MPLS), plus IP tunnels (e.g., using IPsec, L2TP).

   o Access network

     An access network provides access connections between CE devices
     and PE routers.  It may be a TDM network, layer 2 network (e.g.,
     FR, ATM, and Ethernet), or IP network over which access is tunneled
     (e.g., using L2TP [RFC2661]).

   o VPN tunnel

     A VPN tunnel is a logical link between two entities which is
     created by encapsulating packets within an encapsulating header for
     purpose of transmission between those two entities for support of
     VPNs.  VFIs are typically interconnected via (per-)VPN tunnels.
     This is illustrated in Figure 3.2.

     Multiple tunnels at one level may be hierarchically multiplexed
     into a single tunnel at another level.  For example, multiple per-



Design Team               Expires January 2002                 [Page 13]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


     VPN tunnels may be multiplexed into a single PE to PE tunnel (e.g.,
     MPLS, GRE, IPsec, or IP-in-IP tunnel).  This is illustrated in
     Figure 3.3.  See section 5.3 for details.

   o VPN forwarding instance (VFI)

     A VFI is a logical entity that resides in a PE, that includes the
     router information base and forwarding information base for a 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 for accommodating
     CEs.  The interaction between routing and VFIs is discussed in
     section 5.4.2.

   o Customer management function

     Customer management function administrates customer specific
     attributes, such as customer ID, personal information (e.g., name,
     address, phone number, credit card number, etc), subscription
     services and parameters, access control policy information, billing
     and statistical information, and etc.

     Customer management function may use a combination of proprietary
     network management system, SNMP manager, or directory service
     (e.g., LDAP [RFC1777] [RFC2251]).

   o Network management function

     Network management function administrates devices attributes and
     their relationship, covering PE routers and other devices
     constructing the concerned NBVPN.

     Network management function may use a combination of proprietary
     network management system, SNMP manager, or directory service
     (e.g., LDAP [RFC1777] [RFC2251]).

3.1.2 Relationship between CE and PE

   A CE device is usually connected to a single PE router.  However,
   four types of dual homing arrangements, shown in Figure 3.4, may be
   supported.










Design Team               Expires January 2002                 [Page 14]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


                   +----------------                    +---------------
                   |                                    |
               +------+                             +------+
     +---------|  PE  |                   +---------|  PE  |
     |         |router|                   |         |router| SP network
     |         +------+                   |         +------+
  +------+         |                   +------+         |
  |  CE  |         |                   |  CE  |         +---------------
  |device|         |   SP network      |device|         +---------------
  +------+         |                   +------+         |
     |         +------+                   |         +------+
     |         |  PE  |                   |         |  PE  |
     +---------|router|                   +---------|router| SP network
               +------+                             +------+
                   |                                    |
                   +----------------                    +---------------
  This type includes a CE device connected
  to a PE router via two access lines.
                  (a)                                  (b)

                   +----------------                    +---------------
                   |                                    |
  +------+     +------+                +------+     +------+
  |  CE  |-----|  PE  |                |  CE  |-----|  PE  |
  |device|     |router|                |device|     |router| SP network
  +------+     +------+                +------+     +------+
     |             |                      |             |
     | Backdoor    |                      | Backdoor    +---------------
     | link        |   SP network         | link        +---------------
     |             |                      |             |
  +------+     +------+                +------+     +------+
  |  CE  |     |  PE  |                |  CE  |     |  PE  |
  |device|-----|router|                |device|-----|router| SP network
  +------+     +------+                +------+     +------+
                   |                                    |
                   +----------------                    +---------------

                  (c)                                  (d)

          Figure 3.4: Four types of double-homing arrangements.


3.1.3 Interworking model

   It is quite natural to assume that multiple differently implemented
   SP networks of layer 3 NBVPNs owned by one or more SPs co-exist,
   since it follows the expectation that (1)each SP chooses its best
   layer 3 NBVPN implementation out of multiple vendor's



Design Team               Expires January 2002                 [Page 15]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   implementations, and (2)an SP may deploy multiple networks of layer 3
   NBVPNs (e.g., an old network and a new network).  Thus layer 3 NBVPNs
   spanning multiple differently implemented SP networks are required
   [PPVPN-REQ].

   There are two scenarios that enable layer 3 NBVPNs interworking among
   different approaches.

   o Interworking function

     This scenario enables interworking using a PE that is located at
     the boarder of SP networks implemented with different approaches
     and is supporting both approaches [VPN-BGP-VR].  This PE is termed
     interworking function (IWF), and an example configuration is shown
     in Figure 3.5.

               +------------------+  +------------------+
               |                  |  |                  |
          +------+  VPN tunnel  +------+  VPN tunnel  +------+
          |      |==============|      |==============|      |
          |      |              |      |              |      |
          |  PE  |              |  PE  |              |  PE  |
          |      |              |router|              |      |
          |router|              |(IWF) |              |router|
          |      |  VPN tunnel  |      |  VPN tunnel  |      |
          |      |==============|      |==============|      |
          +------+              +------+              +------+
               |                  |  |                  |
               +------------------+  +------------------+
               |<-- SP Network -->|  |<-- SP Network -->|

                   Figure 3.5: Interworking function.


   o Interworking interface

     This scenario enables interworking using tunnels between PEs
     supported by different approaches.  As shown in Figure 3.6,
     interworking interface is defined as the interface which exists
     between a pair of PEs and connects two SP networks implemented with
     different approaches.  This interface is similar to the customer
     interface located between PE and CE, but the interface is supported
     by tunnels to identify VPNs, while the customer interface is
     supported by access connections.







Design Team               Expires January 2002                 [Page 16]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


       +------------------+                     +------------------+
       |                  |          :          |                  |
   +------+ VPN tunnel +------+Tunnel:      +------+ VPN tunnel +------+
   |      |============|      |======:======|      |============|      |
   |      |            |      |      :      |      |            |      |
   |  PE  |            |  PE  |      :      |  PE  |            |  PE  |
   |      |            |      |      :      |      |            |      |
   |router|            |router|      :      |router|            |router|
   |      | VPN tunnel |      |Tunnel:      |      | VPN tunnel |      |
   |      |============|      |======:======|      |============|      |
   +------+            +------+      :      +------+            +------+
       |                  |          :          |                  |
       +------------------+    Interworking     +------------------+
       |<-- SP Network -->|      interface      |<-- SP Network -->|

                  Figure 3.6: Interworking interface.


3.2 Reference Model for Layer 2 NBVPN

   This subsection describes functional components and their
   relationship for implementing layer 2 network-based VPN.

   Figure 3.7 shows the reference model for layer 2 NBVPNs and Figures
   3.8 and 3.9 show relationship between entities in the reference
   model.

























Design Team               Expires January 2002                 [Page 17]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


    +---------+  +------------------------------------+  +---------+
    |         |  |                                    |  |         |
    |         |  |                     +------+     +------+  : +------+
+------+ :    |  |                     |      |     |      |  : |  CE  |
|  CE  | :    |  |                     |  P   |     |  PE  |  : |device|
|device| :  +------+   VPN tunnel   :  |device|     |device|  : |  of  |
|  of  |-:--|      |================:===============|      |--:-|VPN  A|
|VPN  A| :  |      |                :  +------+     +------+  : +------+
+------+ :  |  PE  |                :                 |  |    :    |
+------+ :  |device|        Network interface         |  |    :    |
|  CE  | :  |      |                :               +------+  : +------+
|device|-:--|      |================:===============|      |--:-|  CE  |
|  of  | :  +------+                :  VPN tunnel   |  PE  |  : |device|
|VPN  B| :    |  |                                  |device|  : |  of  |
+------+ :    |  |  +------------+   +------------+ |      |  : |VPN  B|
    |    :    |  |  |  Customer  |   |  Network   | +------+  : +------+
    |Customer |  |  | management |   | management |   |  |    :    |
    |interface|  |  |  function  |   |  function  |   |  |Customer |
    |         |  |  +------------+   +------------+   |  |interface|
    |         |  |                                    |  |         |
    +---------+  +------------------------------------+  +---------+
    | Access  |  |<---------- SP network(s) --------->|  | Access  |
    | network |  |   single or multiple SP domains    |  | network |

             Figure 3.7: Reference model for layer 2 NBVPN.


               +----------+                  +----------+
+-----+        |PE device |                  |PE device |        +-----+
| CE  |        |          |                  |          |        | CE  |
| dev | Access | +------+ |                  | +------+ | Access | dev |
| of  |  conn. | |VSI of| |    VPN tunnel    | |VSI of| |  conn. | of  |
|VPN A|----------|VPN A |======================|VPN A |----------|VPN A|
+-----+        | +------+ |                  | +------+ |        +-----+
               |          |                  |          |
+-----+ Access | +------+ |                  | +------+ | Access +-----+
| CE  |  conn. | |VSI of| |    VPN tunnel    | |VSI of| |  conn. | CE  |
| dev |----------|VPN B |======================|VPN B |----------| dev |
| of  |        | +------+ |                  | +------+ |        | of  |
|VPN B|        |          |                  |          |        |VPN B|
+-----+        +----------+                  +----------+        +-----+

   Figure 3.8: Relationship between entities in reference model (1).








Design Team               Expires January 2002                 [Page 18]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


               +----------+                  +----------+
+-----+        |PE device |                  |PE device |        +-----+
| CE  |        |          |                  |          |        | CE  |
| dev | Access | +------+ |                  | +------+ | Access | dev |
| of  |  conn. | |VSI of| |                  | |VSI of| |  conn. | of  |
|VPN A|----------|VPN A | |                  | |VPN A |----------|VPN A|
+-----+        | +------+\|      Tunnel      |/+------+ |        +-----+
               |          >==================<          |
+-----+ Access | +------+/|                  |\+------+ | Access +-----+
| CE  |  conn. | |VSI of| |                  | |VSI of| |  conn. | CE  |
| dev |----------|VPN B | |                  | |VPN B |----------| dev |
| of  |        | +------+ |                  | +------+ |        | of  |
|VPN B|        |          |                  |          |        |VPN B|
+-----+        +----------+                  +----------+        +-----+

   Figure 3.9: Relationship between entities in reference model (2).


3.2.1 Entities in the reference model

   The entities in the reference model are described below.

   o Customer edge (CE) device

     A CE device is a device on the customer site which has an access
     connection to a PE device.  It may be a router, host, or switch
     located at the edge of a user site.

   o P device

     A switch or router within a provider network which is used to
     interconnect PE devices, but which does not have any VPN state and
     does not have any direct attachment to CE devices.  In its role as
     a P device, this device is acting as a switch, although it may also
     have routing capabilities.

   o Provider edge (PE) device

     A PE device is attached via an access connection to one or more CE
     devices.  In the context of supporting layer 2 NBVPNs, a PE device
     maps incoming layer 2 circuits (from CE) to internal layer 2
     circuits used in the provider network.  In its role as a PE device,
     this device is acting as a switch, although it may also have
     routing capabilities.







Design Team               Expires January 2002                 [Page 19]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   o Customer site

     A customer site is a set of users that have mutual layer 2
     reachability without use of a specific service provider network.

   o SP networks

     An SP network is a network administered by a single service
     provider.

   o Access connection

     An access connection represents an isolated layer 2 connectivity
     between a CE device and a PE device.  This includes dedicated
     physical circuits, logical circuits (such as Frame Relay, ATM, and
     MPLS), plus IP tunnels (e.g., using L2TP).

   o Access network

     An access network provides access connections between CE devices
     and PE devices.  It may be a TDM network, layer 2 network (e.g.,
     FR, ATM, and Ethernet), or IP network over which access is tunneled
     (e.g., using L2TP [RFC2661] or MPLS).

   o VPN tunnel

     A VPN tunnel is a logical link between two entities which is
     created by encapsulating packets within an encapsulating header for
     purpose of transmission between those two entities for support of
     VPNs.  VSIs are typically interconnected via (per-)VPN tunnels.
     This is illustrated in Figure 3.8.

     Multiple tunnels at one level may be hierarchically multiplexed
     into a single tunnel at another level.  For example, multiple per-
     VPN tunnels may be multiplexed into a single PE to PE tunnel (e.g.,
     MPLS, GRE, IPsec, or IP-in-IP tunnel).  This is illustrated in
     Figure 3.9.  See section 5.3 for details.

   o VPN switching instance (VSI)

     A VSI is a logical entity that resides in a PE, that includes
     information regarding how to forward layer 2 packets for a VPN.  A
     VSI enables switching functions dedicated to serving a particular
     VPN.  In general a VSI terminates tunnels for interconnection with
     other VSIs and also terminates access connections for accommodating
     CEs.





Design Team               Expires January 2002                 [Page 20]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   o Customer management function

     Customer management function administrates customer specific
     attributes, such as customer ID, personal information (e.g., name,
     address, phone number, credit card number, etc), subscription
     services and parameters, access control policy information, billing
     and statistical information, and etc.

     Customer management function may use a combination of proprietary
     network management system, SNMP manager, or directory service
     (e.g., LDAP [RFC1777] [RFC2251]).

   o Network management function

     Network management function administrates devices attributes and
     their relationship, covering PE routers and other devices
     constructing the concerned NBVPN.

     Network management function may use a combination of proprietary
     network management system, SNMP manager, or directory service
     (e.g., LDAP [RFC1777] [RFC2251]).

3.2.2 Interworking model

   TBD.

3.3 Reference Model for Provider Provisioned CE-based VPN

   This subsection describes functional components and their
   relationship for implementing provider provisioned CE-based VPN.

   Figure 3.10 shows the reference model for provider provisioned CE-
   based VPN.


















Design Team               Expires January 2002                 [Page 21]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


    +---------+  +------------------------------------+  +---------+
    |         |  |                                    |  |         |
    |         |  |                     +------+     +------+  : +------+
+------+ :    |  |                     |      |     |      |  : |  CE  |
|  CE  | :    |  |                     |  P   |     |  PE  |  : |device|
|device| :  +------+    VPN tunnel     |router|     |router|  : |  of  |
|  of  |=:====================================================:=|VPN  A|
|VPN  A| :  |      |                   +------+     +------+  : +------+
+------+ :  |  PE  |                                  |  |    :    |
+------+ :  |router|                                  |  |    :    |
|  CE  | :  |      |           VPN tunnel           +------+  : +------+
|device|=:====================================================:=|  CE  |
|  of  | :  +------+                                |  PE  |  : |device|
|VPN  B| :    |  |                                  |router|  : |  of  |
+------+ :    |  |  +------------+   +------------+ |      |  : |VPN  B|
    |    :    |  |  |  Customer  |   |  Network   | +------+  : +------+
    |Customer |  |  | management |   | management |   |  |    :    |
    |interface|  |  |  function  |   |  function  |   |  |Customer |
    |         |  |  +------------+   +------------+   |  |interface|
    |         |  |                                    |  |         |
    +---------+  +------------------------------------+  +---------+
    | Access  |  |<---------- SP network(s) --------->|  | Access  |
    | network |  |                                    |  | network |

   Figure 3.10: Reference model for provider provisioned CE-based VPN


3.3.1 Entities in the reference model

   The entities in the reference model are described below.

   o Customer edge (CE) device

     A CE device is a device on the customer site which has an access
     connection to a PE router.  In the context of provider provisioned
     CE-based VPNs, a CE device maintains one or more VPN tunnel
     endpoints.

   o P router (See section 3.1.1)

   o Provider edge (PE) router

     A PE router is attached via an access connection to one or more CE
     devices.  In the context of provider provisioned CE-based VPNs, the
     PE router has no VPN-specific functionality.






Design Team               Expires January 2002                 [Page 22]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   o Customer Site (See section 3.1.1)

   o SP networks

     A SP network is a network administrated by a single service
     provider.  In the context of provider provisioned CE-based VPNs,
     the SP network consists of the SP's network and the SP's management
     functions that manage both its own network and the customer's VPN
     functions on the CE device.

   o Access connection (See section 3.1.1)

   o Access network (See section 3.1.1)

   o VPN tunnel

     A VPN tunnel is a logical link between two entities which is
     created by encapsulating packets within an encapsulating header for
     purpose of transmission between those two entities for support of
     VPNs.  In the context of provider provisioned CE-based VPNs, a VPN
     tunnel is an IP tunnel (e.g., using IPsec, L2TP, GRE, IP-in-IP) or
     an MPLS tunnel between two CE devices over the SP's network.

   o Customer management function (See section 3.1.1)

   o Network management function

     Network management function administrates devices attributes and
     their relationship, covering PE routers, CE devices that define the
     VPN connectivity of the customer VPNs.

     Network management function may use a combination of proprietary
     network management system, SNMP manager, or directory service
     (e.g., LDAP [RFC1777] [RFC2251]).

3.3.2 Relationship between CE and PE

   A CE device is connected to one or more PE device for the purpose of
   receiving IP or MPLS connectivity with the SP network.












Design Team               Expires January 2002                 [Page 23]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


4. Customer Interface

4.1 VPN Establishment at the CE-PE Boundary

4.1.1 Layer 3 and 2 NBVPN

   It is necessary for each PE device to know which CEs it is attached
   to, and what VPNs each CE is associated with.

   VPN membership refers to the association of VPNs, CEs, and PEs.  A
   given CE belongs to one or more VPNs.  Each PE is therefore
   associated with a set of VPNs, and a given VPN has a set of
   associated PEs which are supporting that VPN.  If a PE has at least
   one attached CE belonging to a given VPN, then state information for
   that VPN (e.g., the VPN routes) must exist on that PE.

   The set of VPNs that exist on a PE may change over time as sites for
   new VPNs are added, or all sites for a VPN are removed.  Distributing
   VPN membership information thus refers to distributing information
   about which devices are associated with which VPNs.  This information
   may be used in different ways by different VPN schemes, for example,
   to constrain VPN route distribution or to establish VPN tunnels.

   A VPN site may be added or deleted as a result of a provisioning
   operation carried out by the network administrator, or may be
   dynamically added or deleted as a result of a subscriber initiated
   operation; thus VPN membership information may be either static or
   dynamic, as discussed below.

4.1.1.1 Static binding

   An example of a static binding between PE/CE access connection and
   the VPN associated with the access connection is where a network
   administrator sets up a dedicated link layer connection, such as an
   ATM VCC or a Frame Relay circuit, between a PE and a CE device at the
   customer site.  In this case the binding between the PE/CE access
   connection and the VPN to be used is fixed at provisioning time, and
   remains the same until another provisioning action that changes the
   binding.

4.1.1.2 Dynamic binding

   It is also possible for the PE/CE access connection to VPN binding to
   be dynamic.  For example a mobile user may dial up the provider
   network and carry out user authentication and VPN selection
   procedures.  Thus the PE to which the user is attached is not one
   permanently associated with the user, but rather one that is
   typically geographically close to where the mobile user happens to



Design Team               Expires January 2002                 [Page 24]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   be.  Another example of dynamic binding is that of a permanent access
   connection between a PE and a CE at a public facility such as a hotel
   or conference center, where the link may be accessed by multiple
   users in turn, each of which may wish to connect to a different VPN.

   To support dynamically connected users, PPP and RADIUS are commonly
   used, as these protocols provide for user identification,
   authentication and VPN selection.  Other mechanisms are also
   possible.  For example a user's HTTP traffic may be initially
   intercepted by a PE and diverted to a provider hosted web server.
   After a dialogue that includes user authentication and VPN selection,
   the user can then be connected to the required VPN.  This is
   sometimes referred to as a "captive portal."

   Independent of the particular mechanisms used for user authentication
   and VPN selection, an implication of dynamic binding is that a user
   for a given VPN may appear at any PE at any time.  Thus VPN
   membership may change at any time as a result of user initiated
   actions, rather than as a result of network provisioning actions.  As
   such there must be a way to dynamically distribute membership
   information to all devices that need it.

4.1.2 Provider provisioned CE-based VPN

   In the context of Provider Provisioned CE-based VPNs, the PE devices
   have no knowledge of the Establishment of VPNs at their CE-PE
   boundaries.

   CE devices have IP/MPLS connectivity via a connection to a PE device.
   The IP connectivity may be via a static binding, or via some kind of
   dynamic binding.

   The establishment of the VPNs is done at the CE devices, making use
   of the IP/MPLS connectivity to the SP network.

   For the VPN establishment in the context of CE-based VPNs, it is
   necessary for the CE devices to know which other CE devices belong to
   a specific VPN (or at least one other CE device, depending on the VPN
   topology).  In this context, VPN membership refers to the association
   of VPNs and CE devices.

4.2 Data Exchange at the CE-PE Boundary

4.2.1 Layer 3 and 2 NBVPN

   TBD





Design Team               Expires January 2002                 [Page 25]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


4.2.2 Provider provisioned CE-based VPN

   The data exchanged at the CE-PE boundary are always 'normal' IP
   packets that are routable in the SP's network or MPLS frames that can
   be label-switched across the SP network.  The PE device doesn't
   assign any VPN meaning to IP/MPLS packets on the CE-PE link.

4.3 Customer Visible Routing

   Once VPN tunnels are set up (between CE devices or between PE
   devices) it is necessary for the private customer network to make use
   of these tunnels.  It is therefore necessary for the customer network
   to know which addresses within the customer network are reachable
   over which tunnels.  This is a routing function.

4.3.1 Customer view of routing for layer 3 NBVPNs

   PE/CE routing interaction involves a PE obtaining customer prefixes
   reachable at its attached customer site via the local CE router and
   providing reachability information about other sites in the same VPN
   to the customer site.

   The possible PE/CE route distribution mechanisms are: static routing,
   IGP, such as RIP, OSPF, IS-IS, or BGP.  The extent of this routing
   instance generally involves the PE and the CE router.  However, if
   the customer site is running the same IGP as that used in its
   corresponding PE/PE routing instance, the domain may extend to the
   routing instance of the entire VPN.  If a different routing protocol
   runs in the customer site, the CE router redistributes the routes
   between the PE/CE routing instance and the customer site routing
   instance.

   For layer 3 NBVPNs, the PE devices are routers which forward IP
   packets for the customer network.  This implies that a PE router
   participates in some manner in routing for each customer network that
   it supports.  Thus, each PE router looks to the customer network as
   if it were a single router in the customer network.  The access
   connections from CE device to PE router are normal links between
   within the customer network.  The routing information exchanged on
   the CE-PE access connection is routing information of the customer
   network.  The options for routing across the CE-PE boundary are
   therefore the same as those available on any link within a customer
   IP network.  However, the manner in which routing for the VPN is
   accomplished across the SP network may have an impact on the choice
   of routing for the customer network.  For example, if BGP or static
   routing is used across the CE-PE access connections, then the routing
   in the customer network will need to be aware of this.




Design Team               Expires January 2002                 [Page 26]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   In the case of layer 3 NBVPNs a single PE router is likely to provide
   service for multiple different VPNs, implying that it is
   interconnected with multiple CE devices, including multiple CEs with
   one VPN as well as multiple different VPNs.  The PE device must
   therefore support independent forwarding of user data for each VPN
   which it supports.  The forwarding table used for each VPN will in
   general be different.  This implies that the PE router will therefore
   need to maintain multiple separate forwarding instances.  These will
   be referred to as Virtual Forwarding Instances (VFIs).  Each VFI is
   therefore a logical entity internal to the PE router.  VFIs are
   defined in section 3.1.1, and discussed in more detail in section
   5.4.2.

   The scaling and management of the customer network (as well as the
   operation of the VPN) will depend upon the implementation approach
   and the manner in which routing is done.

4.3.1.1 Routing for intranets

   In the intranet case all of the sites to be interconnected belong to
   the same administration (for example, the same company).  The options
   for routing within a single customer network include:

   o A single IGP area (using OSPF, IS-IS, or RIP)

   o Multiple areas within a single IGP

   o A separate IGP within each site, with routes redistributed from
     each site to backbone routing (i.e., to a backbone as seen by the
     customer network).

   Note that these options look at routing from the perspective of the
   overall routing in the customer network.  This list does not specify
   whether Provider Edge (PE) equipment is considered to be in a site or
   not.  This issue is discussed below.

   A single IGP area (such as a single OSPF area, a single IS-IS area,
   or a single instance of RIP between routers) may be used for small
   networks.  In this case, all routers within the customer network
   (including VFIs, for layer 3 NBVPNs) appear within a single area.
   Links between routers also appear as normal links (including tunnels
   between VFIs).

   In some cases the multi-level hierarchy of OSPF or IS-IS may be used.
   One way to apply this to VPNs would be to have each site be a single
   OSPF or IS-IS area.  The VFIs will participate in routing within each
   site as part of that area.  The VFIs may then be interconnected as
   the backbone (OSPF area 0 or IS-IS level 2).  If OSPF is used, the



Design Team               Expires January 2002                 [Page 27]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   VFIs therefore appear to the customer network as area border routers.
   If IS-IS is used, the VFIs therefore participate in level 1 routing
   within the local area, and appear to the customer network as if they
   are level 2 routers in the backbone.

   Where an IGP is used across the entire network, it is straightforward
   for VPN tunnels, access connections, and "backdoor" links to be mixed
   in a network.  Given that OSPF metrics will be assigned to all links,
   paths via alternate links can be compared and the shortest cost path
   will be used regardless of whether it is via VPN tunnels, access
   connections, or backdoor links.  If multiple sites of a VPN do not
   use a common IGP, or if the backbone does not use the same common IGP
   as the sites, then special procedures may be needed to ensure that
   routes to/from other sites are treated as intra-area routes, rather
   than as external routes (depending upon the VPN approach taken).

   Another option is to operate each site as a separate routing domain.
   For example each site could operate as a single OSPF area, a single
   IS-IS area, or a RIP domain.  In this case the per-site routing
   domains will need to redistribute routes into a backbone routing
   domain (Note: in this context the "backbone routing domain" refers to
   a backbone as viewed by the customer network).  In this case it is
   optional whether or not the VFIs participate in the routing within
   each site.

4.3.1.2 Routing for extranets

   In the extranet case the sites to be interconnected belong to
   multiple different administrations.  In this case IGPs (such as OSPF,
   IS-IS, or RIP) are normally not used across the interface between
   organizations.  Either static routes or BGP may be used between
   sites.  If the customer network administration wishes to maintain
   control of routing between its site and other networks, then either
   static routing or BGP may be used across the CE-PE interface.  If the
   customer wants to outsource all such control to the provider, then an
   IGP or static routes may be used at this interface.

   The use of BGP between sites allows for policy based routing between
   sites.  This is particularly useful in the extranet case.

4.3.1.3 Customer edge and provider edge equipment for layer 3 NBVPNs

   When using a single IGP area across an intranet, the entire customer
   network participates in a single area of an IGP.  In this case, for
   layer 3 NBVPNs both CE and PE routers participate as normal routers
   within the area.





Design Team               Expires January 2002                 [Page 28]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   The other options make a distinction between routing within a site,
   and routing between sites.  In this case the CE routers would
   normally be considered as part of the site where they are located.
   However, there is an option regarding how the PE routers should be
   considered.

   In some cases, from the perspective of routing within the customer
   network, the PE routers (or more precisely the virtual forwarding
   instances within a PE router) may be considered to be internal to the
   same area or routing domain as the site to which they are attached.
   This simplifies the management responsibilities of the customer
   network administration, since inter-area routing would be handled by
   the provider.

   For example, suppose that either static routes or BGP are used
   between sites.  With this approach each site could operate as a
   single IGP area, and the CE-PE access connection would simply be
   configured as internal links within that area.  Static routes or BGP
   for inter-site routing can be handled by the provider.

   In other cases, from the perspective of routing within the customer
   network, the CE routers may be the "edge" routers of the IGP area.
   In this case, static routing, BGP, or whatever routing is used in the
   backbone, may be used across the CE-PE boundary.

4.3.2 Customer view of routing for layer 2 NBVPNs

   For layer 2 NBVPNs, the VPN service provides tunnels which act as
   "VPN links" between CE devices.  These links may show up as point-to-
   point links in the customer network, or as broadcast LANs, switched
   LANs, or NBMA networks.

   Typically, once the VPN links are set up between CE devices, the
   customer will run one or more layer 3 routing protocols between CE
   devices over the VPN links.  In many cases, from the perspective of
   routing within the customer network, the VPN links will be considered
   to be internal links within the customer network.  An IGP (such as
   RIP, OSPF, or IS-IS) may for example be run between CE routers within
   the customer network.  Note that IGPs in general are able to
   automatically and dynamically discover the identity of the router on
   the other end of the link, as well as addresses reachable via the
   link.  This implies that once the links are set up, no additional
   configuration is needed to initialize the operation of the IGP (other
   than knowledge that the IGP is to be operated over the link).

   Layer 2 NBVPNs may also be used for support of extranets.  In this
   case the VPN link may be between corporate networks, rather than
   within a single corporate network.  This may imply that an exterior



Design Team               Expires January 2002                 [Page 29]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   routing protocol such as BGP may be used over the VPN link.  In this
   case (as with any layer 2 NBVPN) correct configuration of layer 3
   routing over the VPN link is up to the customers, and is not
   typically provided by the service provider.

4.3.3 Customer view of routing for provider provisioned CE-based VPNs

   For provider provisioned CE-based VPNs, the PE and P routers are not
   aware of the reachability within the customer sites.  The CE and PE
   devices don't exchange customer's routing information.  The routing
   in the customer VPN is transparent to the SP's network.

   This means no VPN routes need to be maintained in any of the SP's
   PE/P devices.

   Customer sites that belong to the same VPN may exchange routing
   information through the VPN tunnels that are seen as CE to CE
   interconnecting links from the customer's perspective.

   Routing within the customer site may be done in any possible way,
   using any kind of routing protocols (see section 4.3.4).

   As the CE device receives an IP/MPLS service from the Service
   Provider, the CE device and the PE device may exchange global routing
   information that is meaningful within the SP routing realm.

   Moreover, as the forwarding of tunneled customer packets in the SP
   network will be based on global IP forwarding, the routes to the
   various CE devices must be known in the entire SP's network.

   This means that a CE device may need to participate in two different
   routing processes:

   o routing in its own private network (VPN routing), within its own
     site and with the other VPN sites through the VPN tunnels, possibly
     using private addresses.

   o routing in the SP network (global routing), as such peering with
     its PE.

   Note that this does not impose the adoption of routing protocols
   between the PE and the CE device, as in lots of scenarios, the use of
   static/default routes might be sufficient.

4.3.4 Options for customer visible routing

   The following technologies are available for the exchange of routing
   information.



Design Team               Expires January 2002                 [Page 30]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   o Static routing

     Routing tables may be configured through a management system.

   o RIP (Routing Information Protocol) [RFC2453]

     RIP is an interior gateway protocol and is used within an
     autonomous system.  It sends out routing updates at regular
     intervals and whenever the network topology changes.  Routing
     information is then propagated by the adjacent routers to their
     neighbors and thus to the entire network.  A route from a source to
     a destination is the path with the least number of routers.  This
     number is called the "hop count" and its maximum value is 15.  This
     implies that RIP is suitable for a small- or medium-sized networks.

   o OSPF (Open Shortest Path First) [RFC1583]

     OSPF is an interior gateway protocol and is applied to a single
     autonomous system.  Each router distributes the state of its
     interfaces and neighboring routers as a link state advertisement,
     and maintains a database describing the autonomous system's
     topology.  A link state is advertised every 30 minutes or when the
     topology is reconfigured.

     Each router maintains an identical topological database, from which
     it constructs a tree of shortest paths with itself as the root.
     The algorithm is known as the Shortest Path First or SPF.  The
     router generates a routing table from the tree of shortest paths.
     OSPF supports a variable length subnet mask, which enables
     effective use of the IP address space.

     OSPF allows sets of networks to be grouped together into an area.
     Each area has its own topological database.  The topology of the
     area is invisible from outside its area.  The areas are
     interconnected via a "backbone" network.  The backbone network
     distributes routing information between the areas.  The area
     routing scheme can reduce the routing traffic and compute the
     shortest path trees and is indispensable for larger scale networks.

     Each multi-access network with multiple routers attached has a
     designated router.  The designated router generates a link state
     advertisement for the multi-access network and synchronizes the
     topological database with other adjacent routers in the area.  The
     concept of designated router can thus reduce the routing traffic
     and compute shortest path trees.  To achieve high availability, a
     backup designated router is used.





Design Team               Expires January 2002                 [Page 31]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   o IS-IS (intermediate system to intermediate system) [RFC1195]

     IS-IS is a routing protocol designed for the OSI (Open Systems
     Interconnection) protocol suites.  Integrated IS-IS is derived from
     IS-IS in order to support the IP protocol.  In the Internet
     community, IS-IS means integrated IS-IS.  In this, a link state is
     advertised over a connectionless network service.  IS-IS has the
     same basic features as OSPF.  They include: link state
     advertisement and maintenance of a topological database within an
     area, calculation of a tree of shortest paths, generation of a
     routing table from a tree of shortest paths, the area routing
     scheme, a designated router, and a variable length subnet mask.

   o BGP4 (Border Gateway Protocol version 4) [RFC1771]

     BGP4 is an exterior gateway protocol and is applied to the routing
     of inter-autonomous systems.  A BGP speaker establishes a session
     with other BGP speakers and advertises routing information to them.
     A session may be an External BGP (EBGP) that connects two BGP
     speakers within different autonomous systems, or an internal BGP
     (IBGP) that connects two BGP speakers within a single autonomous
     system.  Routing information is qualified with path attributes,
     which differentiate routes for the purpose of selecting an
     appropriate one from possible routes.  Also, routes are grouped by
     the community attribute [RFC1997] [BGP-COM].

     The IBGP mesh size tends to increase dramatically with the number
     of BGP speakers in an autonomous system.  BGP can reduce the number
     of IBGP sessions by dividing the autonomous system into smaller
     autonomous systems and grouping them into a single confederation
     [RFC1965].  Route reflection is another way to reduce the number of
     IBGP sessions [RFC1966].  BGP divides the autonomous system into
     clusters.  Each cluster establishes the IBGP full mesh within
     itself, and designates one or more BGP speakers as "route
     reflectors," which communicate with other clusters via their route
     reflectors.  Route reflectors in each cluster maintain path and
     attribute information across the autonomous system.  The autonomous
     system still functions like a fully meshed autonomous system.  On
     the other hand, confederations provide finer control of routing
     within the autonomous system by allowing for policy changes across
     confederation boundaries, while route reflection requires the use
     of identical policies.

4.4 QoS

   TBD.





Design Team               Expires January 2002                 [Page 32]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


5. Network Interface and Service Provider Support of VPNs

5.1 Functional Components of a VPN

   The basic functional components of an implementation of an VPN are:

   o A mechanism to acquire VPN membership/capability information

   o A mechanism to tunnel traffic among VPN sites

   o For layer 3 NBVPNs, a means to learn customer routes, distribute
     them across the provider network, and to advertise reachable
     destinations to customer sites.

   Based on the actual implementation, these functions could be
   implemented on a per-VPN basis or could be accomplished via a common
   mechanism shared by all VPNs.  For instance, a single process could
   handle the routing information for all the VPNs or a separate process
   may be created for each VPN.

   Before data can be exchanged across a VPN, the sites involved in the
   VPN must learn of one another, acquire information on VPN membership,
   determine or know the type of VPN that will be set up, and finally
   invoke mechanisms that will establish the tunnels and disseminate the
   routing information among the sites.  The establishment of a VPN can
   be thought of as composed of the following three stages.  It worth
   noting that separation of the VPN setup into three stages is logical.
   Depending on the actual means used to determine such information, one
   or more stages can be combined.

   In the membership/capability discovery stage, membership and
   capability information needs to be acquired to determine if any two
   PEs support common VPNs.  This can be accomplished, for instance, by
   exchanging VPN identifications of the configured VPNs at each PE for
   determining if there are any common VPNs between them.  The
   capabilities of the PEs need to be determined to be able to agree on
   a common mechanism to use for tunneling and/or routing.  For
   instance, if site A supports both IPsec and MPLS as tunneling
   mechanisms and site B supports only MPLS, they can both agree to use
   MPLS for tunneling.  In some cases the capability information may be
   determined implicitly, for example some service providers may
   implement a single VPN solution.  Likewise, the routing information
   for VPNs can be distributed using the methods discussed in section
   5.4.







Design Team               Expires January 2002                 [Page 33]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   In the tunnel establishment stage, the mechanisms for tunneling need
   to be invoked to actually set up the tunnels.  With IPsec, for
   instance, this could involve the use of IKE to exchange keys and
   policies for securing the data traffic.

   In the VPN routing stage, routing information for the VPN sites must
   be exchanged before data transfer between the sites can take place.
   Based on the VPN model, this could involve the use of static routes,
   IGPs such as OSPF/ISIS/RIP, or an EGP such as BGP.

   VPN membership and capability information can be distributed via
   routing protocols such as BGP, central management system such as LDAP
   or manual configuration.  Manual configuration does not scale and is
   error prone, and therefore is discouraged.

   While every VPN solution must address the functionality of all three
   components, the combinations of mechanisms used to provide the needed
   functionality, and the order in which different pieces of
   functionality are carried out, may differ.

   For layer 2 NBVPNs and CE-based VPNs, the VPN service is offering
   tunnels between CE equipment.  Routing for the VPN is done by the
   customer network.  With these solutions, the service provider is
   involved in the operation of the membership/capability discovery
   stage and the tunnel establishment stage.  However, the routing
   functional component is entirely up to the customer network.

5.2 VPN Establishment and Maintenance

   For a provider provisioned VPN the SP is responsible for the
   establishment and maintenance of the VPNs.  Many different approaches
   and schemes are possible in order to provide PPVPNs, however there
   are some generic problems that any VPN solution must address,
   including:

   o When a new VPN is added to a PE, how does the PE find out about the
     existing parts of the VPN and vice versa?

   o In order for layer 3 NBVPNs to scale, all routes for all VPNs
     cannot reside on all PEs.  How is the distribution of VPN routing
     information constrained to only those devices that need it?

   o An administrator may wish to use different topologies for different
     VPNs (e.g., a full mesh or a hub & spoke topology).  How can this
     be achieved?

     This section looks at some of these generic problems and at some of
     the mechanisms that can be used to solve them.



Design Team               Expires January 2002                 [Page 34]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


5.2.1 VPN discovery

   Mechanisms are needed to acquire information that allows the
   establishment and maintenance of VPNs.  This may include, for
   example, information on VPN membership, topology, and VPN device
   capabilities.  This information may be statically configured, or
   distributed by an automated protocol.  As a result of the operation
   of these mechanisms and protocols, a device is able to determine
   where to set up tunnels, and where to advertise the VPN routes for
   each VPN.

   With a physical network, the equivalent problem can by solved by the
   control of the physical interconnection of links, and by having a
   router run a discovery/hello protocol over its locally connected
   links.  With VPNs both the routers and the links (tunnels) may be
   logical entities and thus some other mechanisms are needed.

   A number of different approaches are possible for VPN discovery.  One
   scheme is where the network management system used to configure the
   PEs is also used to distribute VPN discovery information, either
   using proprietary protocols or using standard management protocols
   and MIBs.  Another approach is where the PEs act as clients of a
   centralized directory or database server that contains VPN discovery
   information.  Another is where VPN discovery information is
   piggybacked onto a routing protocol running between the PEs.

5.2.1.1 Network management for membership information

   Service Providers use network management extensively to configure and
   monitor various devices in their network, which may be distributed
   across geographically separate sites.  The same approach could be
   used for distributing VPN related information as well.  A central
   network management system could be used by the SP to configure VPNs
   on PE devices at various locations.  VPN configuration information
   could be entered into the system at the central location and
   distributed via SNMP, CLI, or other means to the remote sites.
   Security and access control could be achieved through the use of
   SNMPv3.  This approach can be very effectively used within an SP
   network, since the SP has access to all PEs in its domain.  A
   standardized VPN configuration MIB will need to be developed before
   this approach can be used to configure PEs across SP boundaries.

5.2.1.2 Directory servers

   A Service Provider typically needs to maintain a database of its
   customer's configuration/membership information regardless of the
   mechanisms used to distribute it.  LDAP [RFC1777] is a standard
   directory protocol which makes it possible to use a common mechanism



Design Team               Expires January 2002                 [Page 35]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   for both storing such information and distributing it.

   LDAP defines a schema, which is a standard format for representing
   information that will be stored in an LDAP server.  Having a standard
   schema ensures interoperability between different implementations of
   LDAP servers and clients.  Moreover, LDAPv3 [RFC2251] supports
   authentication of messages and associated access control, which can
   be used to limit access to VPN information to authorized entities.
   In addition, LDAP v3 supports the notion of extensions, which may be
   used to introduce new functionality without needing to change the
   base protocol itself.

   Using this feature, extensions to LDAP v3 are being proposed that
   will support a persistent search capability [LDAP-PERSIST] that
   allows an LDAP client to request a server to notify it when any
   information of interest to the client is modified.  This can be used
   to ensure timely delivery of VPN information.  LDAP extensions are
   also being proposed to support the replication of directory
   information across LDAP servers, which may reside in different
   administrative domains.  This is useful for automatically propagating
   local VPN information to remote sites and vice versa.

5.2.1.3 Augmented routing for membership information

   BGP supports extensions which allows it to carry VPN information.
   This allows the VPN discovery information and routing information to
   be combined in a single protocol.  BGP is also widely deployed by
   service providers.

   BGP also contains mechanisms to control route distribution.  Route
   filters can be used to constraining the distribution of routing
   information.  Information needed to establish per-VPN tunnels can
   also be carried by this routing instance.

   Augmented routing may be done in combination with aggregated routing,
   as discussed in section 5.4.

5.2.1.4 Multi-SP VPNs

   When two sites of a VPN belong to different SP networks, there must
   be a common mechanism for exchanging membership/capability
   information.  At least one mechanism for VPN information discovery
   must be standardized and supported across multiple SPs.  Inter-SP
   trust relationships will need to be established that will allow for
   exchange of membership information across SP boundaries.  Also, some
   mechanisms will be needed to control which membership information is
   exchanged between SPs.




Design Team               Expires January 2002                 [Page 36]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


5.2.2 Constraining distribution of VPN routing information

   With layer 2 NBVPNs and CE-based VPNs, the VPN service provides
   tunnels between customer edge equipment(which might optionally be
   routers).  In this case, distribution of routing information occurs
   between routers on the customer sites and is therefore outside of the
   scope of the provider aspects of VPN support.

   With layer 3 NBVPNs, the PE devices are routers, and the service
   provider participates directly in routing for the customer network.
   In this case, it is necessary to control the distribution of VPN
   routes between PE routers.

   In order to provide a scalable solution it is not possible to use a
   scheme where all PEs contain all routes for all VPNs.  Instead only
   PEs that have attached sites for a given VPN should contain the
   routing information for that VPN.  As VPN membership may change
   dynamically, it is necessary to have a mechanism that allows for VPN
   route information to be distributed to any PE where there is an
   attached user for that VPN, and to allow for the removal of this
   information when it is no longer needed.

   With the Virtual Router scheme (see section 5.4), per-VPN tunnels
   must be established before any routes for that VPN are distributed,
   and controlling the distribution of route information is thus
   achieved by controlling the establishment of these tunnels.  In this
   scheme, the distribution of membership information consists of the
   set of VPNs that exists on each PE, and also topology information, to
   allow a PE to determine its neighbors.  When a PE receives this
   information it checks to see if it has VPNs in common with its
   neighbors, and if so it establishes tunnels for those VPNs.

   With the aggregated routing scheme (see section 5.4.4), the
   distribution of VPN routing information can be constrained by means
   of route filtering.  As VPN membership changes on a PE, the route
   filters in use between the PE and its peers can be adjusted.  Each
   peer may then adjust the filters in use with each of its peers in
   turn, and thus the changes propagate across the network.  When BGP is
   used, this filtering may take place at route reflectors as discussed
   in section 5.4.4.

5.2.3 Controlling VPN topology

   The topology for a VPN consists of a set of nodes interconnected via
   tunnels.  The topology may be a full mesh, a hub and spoke topology,
   or an arbitrary topology.  For a VPN the set of nodes will include
   all PEs that have attached sites for that VPN, and may also include
   non-PE devices.  (Note that in this section topology is used to



Design Team               Expires January 2002                 [Page 37]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   indicate the interconnectivity between PEs, (e.g., traffic between PE
   A and PE B traverses PE C), rather than restricted reachability
   between VPN sites (e.g., A can talk to B, and B can talk to C, but A
   cannot talk to C)).

   For Layer 2 NBVPNs, the tunnels may be in fact between CE devices.
   However, in this case the CE to PE part of the tunnel is typically
   configured.  Even in this case therefore the major part of the effort
   of controlling VPN topology involves the PE to PE part of the
   tunnels.  However, there may also need to be mechanisms to allow PE
   to CE tunnels to be mapped to PE to PE tunnels, and to minimize the
   configuration required at the CE-PE boundary.

   The simplest topology is a full mesh, where a tunnel exists between
   every pair of PEs.  If we assume the use of point-to-point tunnels
   (rather than multipoint-to-point), then with a full mesh topology
   there are N*(N-1)/2 duplex tunnels or N*(N-1) simplex tunnels for N
   PEs.  Each tunnel consumes some resources at a PE, and depending on
   the type of tunnel, may or may not consume resources in intermediate
   routers or switches.  One reason for using a non full mesh topology
   is to reduce the number of tunnels a PE, and/or the network, needs to
   support.  Another reason is to support the scenario where an
   administrator requires all traffic from certain sites to traverse
   some particular site for policy or control reasons, such as to force
   traffic through a firewall, or for monitoring or accounting purposes.
   Note that the topologies used for each VPN are separate, and thus the
   same PE may be part of a full mesh topology for one VPN, and of a non
   full mesh topology for another VPN.

   An example of where a non full mesh topology could be suitable is for
   a VPN that supports a large number of telecommuters and one, or a
   small number of, corporate sites.  Most traffic will be between
   telecommuters and the corporate sites, not between pairs of
   telecommuters.  A hub and spoke topology for the VPN would thus map
   onto the underlying traffic flow, with the telecommuters attached to
   spoke PEs and the corporate sites attached to hub PEs.  Traffic
   between telecommuters is still supported, but this traffic traverses
   a hub PE.

   The selection of a topology for a VPN is an administrative choice,
   but it is useful to examine protocol mechanisms that can be used to
   automate the construction of the desired topology, and thus reduce
   the amount of configuration needed.  To this end it is useful for a
   PE to be able to advertise per-VPN topology information to other PEs.
   Typically this per-VPN topology information is advertised using the
   same mechanism that is used to advertise membership information.  The
   topology information may be associated with a PE, or with subsets of
   routes reachable via that PE.



Design Team               Expires January 2002                 [Page 38]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   A simple scheme is where a PE advertises itself either as a hub or as
   a spoke, for each VPN that it has.  When received by other PEs this
   information can be used when determining whether to establish a
   tunnel.  A more comprehensive scheme allows a PE to advertise a set
   of topology groups, with tunnels established between a pair of PEs if
   they have a group in common.

5.2.4 Constraining VPN connectivity

   TBD.

5.3 VPN Tunneling

   VPN solutions use tunneling in order to transport VPN packets across
   the service provider backbone.  There are different types of
   tunneling protocols, different ways of establishing and maintaining
   tunnels, and different ways to associate tunnels with VPNs (e.g.,
   shared versus dedicated per-VPN tunnels).  Sections 5.3.1 through
   5.3.5 discusses some common characteristics shared by all forms of
   tunneling, and some common problems to which tunnels provide a
   solution.  Section 5.3.6 provides a survey of available tunneling
   techniques.  Note that tunneling protocol issues are generally
   independent of the mechanisms used for VPN membership and VPN
   routing.

   One motivation for the use of tunneling is that the packet addressing
   used in a VPN may have no relation to the packet addressing used
   across the SP backbone.  For example the customer VPN traffic could
   use non-unique private IP addressing [RFC1918].  Also an IPv6 VPN
   could be implemented across an IPv4 provider backbone.  As such the
   packet forwarding across the SP backbone must use information other
   than that contained in the VPN packets themselves.  A tunneling
   protocol adds additional information, such an extra header or label,
   to a VPN packet, and this additional information is then used for
   forwarding the packet across the SP backbone.

   Another capability optionally provided by tunneling is that of
   isolation between different VPN traffic flows.  The QoS and security
   requirements for these traffic flows may differ, and can be met by
   using different tunnels with the appropriate characteristics.  This
   allows a provider to offer different service characteristics for
   traffic in different VPNs, or to subsets of traffic flows within a
   single VPN.

   The specific tunneling protocols considered in this section are
   IPsec, MPLS, GRE, and IP-in-IP as these are the most suitable for
   carrying VPN traffic across a provider backbone.  Other tunneling
   protocols, such as L2TP [RFC2661], are used primarily to tunnel users



Design Team               Expires January 2002                 [Page 39]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   across an access backbone to a PE or access server, or are used in a
   CE-based VPN.  As the tunneling protocol used across the SP backbone
   between PEs is orthogonal to how sites and subscribers access the
   VPN, these access side tunneling protocols are not discussed here.

5.3.1 Tunnel encapsulations

   All tunneling protocols use an encapsulation that adds additional
   information to the packet that is used for forwarding across the SP
   backbone.  Examples are provided in section 5.3.6.

   One characteristic of a tunneling protocol is whether per-tunnel
   state is needed in the SP backbone in order to forward the tunneled
   packets.  For IP tunneling schemes (IPsec, GRE, and IP-in-IP) no such
   per-tunnel state is needed since forwarding is carried out using the
   outer IP header.  When forwarding packets core routers make no
   distinction between tunneled and non-tunneled packets.  For MPLS,
   per-tunnel state is needed, since the top label in the label stack
   must be examined and swapped by intermediate LSRs.  The amount of
   state required can be minimized by hierarchical multiplexing, and by
   use of multi-point to point tunnels, as discussed below.

   Another characteristic is the tunneling overhead introduced.  With
   IPsec the overhead may be considerable as it may include, for
   example, an ESP header, ESP trailer and an additional IP header.  The
   other mechanisms listed use less overhead, with MPLS being the most
   lightweight.  The overhead inherent in any tunneling mechanism may
   result in additional IP packet fragmentation, if the resulting packet
   is too large to be carried by the underlying link layer.  As such it
   is important to report any reduced MTU sizes via mechanisms such as
   Path MTU discovery in order to avoid fragmentation where possible.

5.3.2 Tunnel multiplexing

   In order to support multiple VPNs on the same PE, a tunneling
   protocol must support a multiplexing field that allows a particular
   tunnel to be associated with a particular VPN.  Some tunneling
   protocols have a field explicitly designed for multiplexing, while
   others have a field that wasn't originally designed for this but can
   be pushed into service as a multiplexing field.  For example:

   o IPsec: SPI field.

   o MPLS: Label.

   o GRE: "Key" field, originally intended for authentication.

   o IP-in-IP: IP address in outer header.



Design Team               Expires January 2002                 [Page 40]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   Note that IP-in-IP tunneling does not have a real multiplexing field
   but if a different IP address is used for every VPN then the IP
   address field can be used for this purpose.  This solution has the
   significant disadvantage that it requires the allocation and
   assignment of a potentially large number of IP addresses, and that
   all these addresses have to be reachable via backbone routing.

5.3.3 Tunnel establishment

   In order to be to able associate a tunnel with a VPN, it is necessary
   to determine and distribute values for the multiplexing field used in
   the tunneling protocol.  There are two main approaches to this - the
   use of an explicit signaling protocol used between the two tunnel
   endpoints, or distribution without an explicit signaling exchange.

   With explicit signaling there is a protocol exchange between the
   tunnel endpoints which, among other things, determines a value for
   the multiplexing field.  For example IKE signaling is used to
   determine SPI values used with IPsec, and CR-LDP and RSVP-TE can be
   used to determine MPLS label values.  Thus given the identity of the
   remote party (e.g., IP address) the multiplexing values are generated
   automatically as a result of the protocol exchanges.  Information
   about the identity of the VPN with which thetunnel is to beassociated
   needs to be exchanged as part of the signaling protocol (e.g., a VPN-
   ID can be carried in the signaling protocol).  One advantage of this
   approach is that per-tunnel security, QoS and other characteristics
   may also be negotiable via the signaling protocol used.  A
   disadvantage is that there may be scalability constraints, discussed
   further below.

   Multiplexing field values can also be exchanged without the use of an
   explicit signaling protocol.  For example MPLS labels can be
   piggybacked on the protocol used for the distribution of VPN routes,
   or on a protocol used for VPN membership.  IP-in-IP and GRE have no
   associated signaling protocol, and thus by necessity the multiplexing
   values are distributed via some other mechanism, such as via
   configuration, or piggybacked in some manner on a VPN membership or
   VPN routing protocol.

   The resources used by the different tunneling establishment
   mechanisms may vary.  With a full mesh VPN topology, and explicit
   signaling, each PE has to establish a tunnel to all the other PEs for
   every VPN.  The resources needed for this on a PE may be significant
   and issues such as the time needed to recover following a device
   failure may also be taken into account, due to the need to have to
   reestablish a large number of tunnels.





Design Team               Expires January 2002                 [Page 41]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


5.3.4 Scaling and hierarchical tunnels

   For tunnels that require state to be maintained in the core of the
   network, simply using per-VPN tunnels between all adjacent devices in
   the VPN topology may not scale to large numbers of tunnels.  Such a
   scheme also breaks the principle that there should be no per-VPN
   state in the core of the network.  For example, MPLS tunnels require
   that core network devices maintain state for the topmost label in the
   label stack.  If per-VPN tunnels are visible in the core then this
   will not scale, particularly as the core devices can act as
   aggregation points and handle tunnels originating from many PEs.

   There are also scaling considerations related to the use of explicit
   signaling for tunnel establishment.  Even if the tunneling protocol
   does not maintain per tunnel state in the core, the number of tunnels
   that a single PE needs to handle may be large, as this grows
   according to the number of VPNs and the number of neighbors per VPN.
   One way to reduce the number of tunnels in a network is to use a VPN
   topology other than a full mesh.  However this may not always be
   desirable, and even with hub and spoke topologies the hubs PEs may
   need to handle large numbers of tunnels.

   Scaling can be achieved by using hierarchical tunnels.  One tunnel is
   established between a pair of PEs, which is then used to carry
   multiple VPN-specific tunnels inside this tunnel.  Many different
   ways of using hierarchical tunnels are possible.  A single PE-PE
   tunnel could be established, which is used by all the per-VPN
   tunnels, or multiple PE-PE tunnels (perhaps with different QoS or
   security characteristics) could be established, which are then used
   by other groups of tunnels.  The tunnels used in the hierarchy may be
   of the same type (e.g., an MPLS label stack) or may be different
   (e.g., GRE carried over IPsec).

   One example using hierarchical tunnels is the use of an MPLS label
   stack.  A single PE-PE LSP is used to carry all the per-VPN LSPs.
   The mechanisms used for label establishment are typically different.
   The PE-PE LSP could be established using LDP, as part or normal
   backbone operation, with the per-VPN LSP labels established by
   piggybacking on VPN routing (e.g., using BGP).  Another example is
   the establishment of a number of different IPsec security
   associations, providing different levels of security between PEs.
   Per-VPN GRE tunnels can then be grouped together and then carried
   over the appropriate IPsec tunnel, rather than having a separate
   IPsec tunnel per VPN.







Design Team               Expires January 2002                 [Page 42]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


5.3.5 Tunnel maintenance

   Once a tunnel is established it is necessary to know that the tunnel
   is operational.  Mechanisms are needed to detect tunnel failures, and
   to respond appropriately to restore service.  For example, where
   appropriate tunnels may be rerouted around failures.

   There is a potential issue regarding propagation of failures when
   multiple tunnels are multiplexed hierarchically.  Suppose that
   multiple VPN-specific tunnels are multiplexed inside a single PE to
   PE tunnel.  In this case, suppose that routing for the VPN is done
   over the VPN-specific tunnels (as may be the case for Layer 2, CE-
   based and VR approaches).  Suppose that the PE to PE tunnel fails.
   In this case multiple VPN-specific tunnels may fail, and layer 3
   routing may simultaneously respond for each VPN using the failed
   tunnel.  If the PE to PE tunnel is subsequently restored, there may
   then be multiple VPN-specific tunnels and multiple routing protocol
   instances which also need to recover.  Each of these could
   potentially require some exchange of control traffic.

   When a tunnel fails, if the tunnel can be restored quickly, it might
   therefore be preferable to restore the tunnel without any response by
   high levels (such as other tunnels which were multiplexed inside the
   failed tunnels).  By having high levels delay response to a lower
   level failed tunnel, this may limit the amount of control traffic
   needed to completely restore correct service.  However, if the failed
   tunnel cannot be quickly restored, then it is necessary for the
   tunnels or routing instances multiplexed over the failed tunnel to
   respond, and preferable for them to respond quickly and without
   explicit action by network operators.

   With CE-based VPNs, layer 2 NBVPNs, and the virtual router scheme, a
   per-VPN instance of routing is running over the tunnel, thus any loss
   of connectivity between the tunnel endpoints will be detected by the
   VPN routing instance.  This allows rapid detection of tunnel failure.
   Careful adjustment of timers might be needed to avoid failure
   propagation as discussed the above.  With the aggregated routing
   scheme, there isn't a per-VPN instance of routing running over the
   tunnel, and therefore some other scheme to detect loss of
   connectivity is needed in the event that the tunnel cannot be rapidly
   restored.

   A tunneling protocol may have an in-built keep alive mechanism that
   can be used to detect loss connectivity.  The base IPsec standard
   does not contain such a mechanism but there are proposals to extended
   IPsec in this manner.  GRE and IP-in-IP tunneling have no such
   mechanism.  MPLS detects failures as part of the signaling protocols.




Design Team               Expires January 2002                 [Page 43]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   With hierarchical tunnels it may suffice to only monitor the
   outermost tunnel for loss of connectivity.  However there may be
   failure modes in a device where the outermost tunnel is up but one of
   the inner tunnels is down.

5.3.6 Survey of tunneling techniques

   Tunneling mechanisms provide isolated and secure communication
   between two CE devices.  Available tunneling mechanisms include (but
   are not limited to): MPLS [RFC3031] [MPLS-FRAME] [RFC3035], GRE
   [RFC2784] [RFC2890], IPsec [RFC2401] [RFC2402], and IP-in-IP
   encapsulation [RFC2003].

   Tunnels may occur between PE devices, or between CE devices.  In the
   case of PE-to-PE encapsulation with layer 3 NBVPNs, a PE router
   encapsulates a data packet incoming from a CE device, and injects it
   into an appropriate tunnel.  The data packet traverses the network,
   and reaches the PE router on the far side.  The PE router then
   retrieves the data packet from a tunnel, and passes it to the
   destination CE device.

5.3.6.1 MPLS [RFC3031] [MPLS-FRAME] [RFC3035]

   Multiprotocol Label Switching (MPLS) is a method for forwarding
   packets through a network.  Routers at the edge of a network apply
   simple labels to packets.  A label may be inserted between the data
   link and network headers, or may be carried in the data link header
   (e.g., the VPI/VCI field in an ATM header).  Routers in the network
   switch packets according to the labels with minimal lookup overhead.
   A path, or a tunnel in the NBVPN, is called a "label switched path
   (LSP)."

   o Multiplexing

     LSPs may be multiplexed into another LSP.

   o Multiprotocol transport

     MPLS can carry data packets other than IP ones.

   o QoS/SLA

     MPLS does not have intrinsic QoS or SLA management mechanisms.
     Some other techniques such as DiffServ may be used with it [MPLS-
     DIFF].






Design Team               Expires January 2002                 [Page 44]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   o Tunnel setup and maintenance

     LSPs are set up and maintained by LDP (Label Distribution Protocol)
     or RSVP (Resource Reservation Protocol) [LSP-RSVP].

   o Large MTUs, minimization of tunnel overhead, and frame sequencing

     MPLS does not restrict the MTU size.  The overhead of label
     switching should be minimal.  MPLS guarantees in-order delivery of
     packets.

5.3.6.2 GRE [RFC2784] [RFC2890]

   Generic Routing Encapsulation (GRE) specifies a protocol for
   encapsulating an arbitrary payload protocol over an arbitrary
   delivery protocol [RFC2784].  In particular, it may encapsulate an IP
   payload packet over IP.  An endpoint encapsulates and decapsulates
   GRE packets.  A GRE tunnel is a communication path between two
   endpoints established by the use of GRE.

   o Multiplexing

     The GRE specification [RFC2784] does not explicitly support
     multiplexing.  But the key field extension to GRE is specified in
     [RFC2890] and it may be used as a multiplexing field.

   o Multiprotocol transport

     GRE is assumed to support any type of payload protocol.

   o QoS/SLA

     These capabilities depend on the delivery protocol.

   o Tunnel setup and maintenance

     GRE is not equipped with standard ways for setting up and
     maintaining GRE tunnels.

   o Large MTUs, minimization of tunnel overhead, and frame sequencing

     These capabilities depend on the delivery protocol, but the GRE
     header overhead is designed to be minimal.  The sequence field
     proposed in [RFC2890] may be used to achieve in-order delivery.







Design Team               Expires January 2002                 [Page 45]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


5.3.6.3 IPsec [RFC2401] [RFC2402] [RFC2406] [RFC2409]

   IP Security (IPsec) provides security services at the IP layer
   [RFC2401].  It comprises authentication header (AH) protocol
   [RFC2402], encapsulating security payload (ESP) protocol [RFC2406],
   and Internet key exchange (IKE) protocol [RFC2409].  AH protocol
   provides data integrity, data origin authentication, and an anti-
   replay service.  ESP protocol provides data confidentiality and
   limited traffic flow confidentiality.  It may also provide data
   integrity, data origin authentication, and an anti-replay service.
   AH and ESP may be used in combination.

   IPsec may be employed in either transport or tunnel mode.  In
   transport mode, either an AH or ESP header is inserted between the
   IPv4 header and the transport protocol header.  In tunnel mode, an IP
   packet is encapsulated with an outer IP packet header.  Either an AH
   or ESP header is inserted between them.  AH and ESP establish a
   unidirectional secure communication path between two endpoints, which
   is called a security association.  In tunnel mode, two security
   associations compose a tunnel between PE routers.  The IKE protocol
   is used to set up IPsec tunnels.

   o Multiplexing

     The SPI field of AH and ESP is used to multiplex security
     associations (or tunnels) between two peer devices.

   o Multiprotocol transport

     IPsec needs extensions to carry packets other than IP ones.
     Alternatively, GRE may be used with it.

   o QoS/SLA

     IPsec itself does not have intrinsic QoS/SLA capabilities.  Other
     mechanisms such as "RSVP Extensions for IPsec Data Flows" [RFC2207]
     or DiffServ may be used with it.

   o Tunnel setup and maintenance

     IKE is used for the setup and maintenance of tunnels.

   o Large MTUs, minimization of tunnel overhead, and frame sequencing

     IPsec does not restrict the MTU size.  IPsec may impose its own
     overhead.  IPsec has a sequence number field that is used by a
     receiver to perform an anti-replay check, not to guarantee in-
     order delivery of packets.



Design Team               Expires January 2002                 [Page 46]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


     Note: IPsec is applicable to a CE-based VPN as well as to an PPVPN.
     This document deals with the aspects of IPsec that are relevant to
     a PPVPN.

5.3.6.4 IP-in-IP encapsulation [RFC2003]

   TBD.

5.4 Routing for VPNs Across the Service Provider Network

   For layer 2 NBVPNs, routing is relatively straightforward: The
   provider network participates in setting up link layer tunnels
   between CE equipment.  However, once the tunnels are set up, then the
   provider does not participate in network layer routing.  This implies
   that in the case of layer 2 NBVPNs the routing occurs between CE
   routers over the VPN tunnels.

   For layer 3 NBVPNs, PE routers forward network layer packets (IP
   packets) on behalf of the customer network.  This implies that the PE
   routers need to participate in some manner in routing for the
   customer network.  Section 4.3 discussed how routing would be done in
   the customer network, including the CE-PE interface.  However,there
   are also significant issues regarding how routing is done in the
   provider network, which are discussed here.

   The provider network needs to carry two types of information: (i)
   Routing information about the public network (including routes to the
   public Internet); (ii) Routing information about routes within the
   customer networks served by the VPNs.  Routing for the Internet or
   for public IP networks are outside of the scope of this document.

5.4.1 Options for VPN routing in the service provider

   The following technologies can be used for exchanging routing
   information within an SP network:

   o Static routing (see section 4.3.4)

   o RIP (see section 4.3.4)

   o OSPF (see section 4.3.4)

   o BGP (see section 4.3.4)

   o Multiprotocol BGP4 [RFC2858]

     BGP4 has been extended to support IPv6, IPX, and others as well as
     IPv4 [RFC2283].  Multiprotocol BGP4 carries routes from multiple



Design Team               Expires January 2002                 [Page 47]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


     "address families," such as the "VPN-IPv4 address family" discussed
     in [VPN-2547BIS].

5.4.2 Virtual forwarding instances (VFIs)

   For layer 3 NBVPNs, the PE devices are routers which forward IP
   packets for the customer network.  This implies that PE devices must
   obtain routes for the customer networks.  This in turn implies that
   the PE device participates in some manner in routing for the customer
   network.  Thus each PE router looks to the customer network as if it
   were a router in the customer network.  The access connections from
   CE device to PE router are normal links between routers within the
   customer network.

   In layer 3 NBVPNs a single PE router is likely to be interconnected
   with multiple CE devices, including multiple CEs within one VPN as
   well as CE devices from multiple different VPNs.  The PE device must
   therefore support independent forwarding of user data for each VPN
   which it supports.  The forwarding table used for each VPN will in
   general be different.  This implies that the PE router will therefore
   need to maintain multiple separate forwarding instances.  These will
   be referred to as Virtual Forwarding Instances (VFIs), as defined in
   section 3.1.

   Note that each VFI will need to obtain routes from the customer
   network that is supports, implying that it needs to participate in
   the operation of routing within each customer network.  This implies
   that from the PE perspective, routing towards the edge of the network
   (on the CE to PE interfaces) must be separated on a per-VPN basis.
   However, note that in some cases routing across the CE-PE interface
   may be very simple.  For example,a static route may be used.
   Alternatively, BGP may be used, but with the provider advertising
   only a simple default route to the CE device, and with the CE device
   advertising only a single address prefix or a very small list of
   address prefixes to the provider.

   PE routers may end up supporting a large number of VPNs, and
   therefore a large number of virtual forwarding instances.  This
   implies that scaling may potentially be difficult in PE routers.  On
   the other hand, the resource load on a particular PE is largely
   linearly proportional to the number of VPNs that the PE router
   supports, and to the size of the VPNs.

   In general, a routing protocol instance may populate multiple VFIs,
   or a single VFI.  Also, a VFI may be populated by a single routing
   protocol, or multiple routing protocols.  Therefore there is not
   necessarily a one to one correspondence between VFI and routing
   protocol instance.



Design Team               Expires January 2002                 [Page 48]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   There are several options for how VPN routes are carried across the
   provider network, as discussed below.

5.4.3 Per-VPN routing

   One option is to operate separate instances of routing protocols
   across the provider network, one instance for each VPN.  When this is
   done, routing protocol packets for each customer network need to be
   tunneled between PEs.  This uses the same tunneling method, and
   optionally the same tunnels, as is used for transporting VPN user
   data traffic between PEs.

   With per-VPN routing, a distinct routing instance corresponding to
   each VPN exists within the corresponding PE device.  VPN-specific
   tunnels are set up between PE devices (using the control mechanisms
   that were discussed in sections 4 and 5).  Logically these tunnels
   are between the VFIs which are within the PE devices.  The tunnels
   then used as if they were normal links between normal routers.
   Routing protocols for each VPN operate between VFIs and the routers
   within the customer network.

   This approach minimizes the interactions between multiple different
   VPNs, in that routing is done independently for each VPN.  However,
   with this approach each PE device implements the capabilities of
   multiple different routers.  This implies that some sharing of
   resources may occur within the PE device.

   The multiple routing instances within the PE device may be separate
   processes, or may be in the same process with different data
   structures.  Similarly, there may be mechanisms internal to the PE
   routers to partition memory and other resources between routing
   instances.  The mechanisms for implementing multiple routing
   instances within a single physical PE are outside of the scope of
   this framework document, and are also outside of the scope of other
   standards documents.

5.4.4 Aggregated routing model

   Another option is to use one single instance of a routing protocol
   for carrying VPN routing information across the provider network.
   With this method the routing information for multiple different VPNs
   is aggregated into a single routing protocol.  This implies that
   whichever routing protocol is used in the provider network needs to
   be enhanced to allow routes from different VPNs to be distinguished.







Design Team               Expires January 2002                 [Page 49]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   In this approach, the number of routing protocol instances in a PE
   router does not depend on the number of CEs supported by the PE
   router, if the routing between PE router and CE device is static or
   BGP4.  However, CE devices and PE routers in a VPN exchange route
   information inside a VPN using a routing protocol except for BGP4,
   the number of routing protocol entities in a PE router depends on the
   number of CEs supported by the PE router.

   In principle it is possible for routing to be aggregated using either
   BGP or on an IGP.

5.4.4.1 Aggregated routing with OSPF or IS-IS

   When supporting VPNs, it is likely that there can be a large number
   of VPNs supported within any given provider network.  Also, in
   general only a small number of PE devices will be interested in the
   operation of any one VPN.  Thus the total amount of routing
   information related to the various customer networks will be very
   large.  However, any one PE needs to know about only a small number
   of such networks.

   Generally provider networks use OSPF or IS-IS for interior routing
   within the provider network.  There are very good reasons for this
   choice, which are outside of the scope of this document.

   Both OSPF and IS-IS are link state routing protocols.  With link
   state routing, the information used for routing is broadcast
   throughout all routers within an area of the network.  This implies
   that all routers within an area have identical information about the
   status of the network.

   In general, any given PE will only support a subset of the VPNs
   supported by the service provider.  It is important therefore to be
   able to restrict the distribution of routing information for any one
   VPN to those PEs which support that VPN.

   With link state routing protocols there is no provision for limiting
   the distribution of routing information to only a small number of
   routers within an area.  Thus if the VPN routing information is
   aggregated into OSPF or IS-IS, the information would need to be
   broadcast to all routers in the area, even routers which don't want
   to know about any one particular VPN.  Given the potential magnitude
   of the total routing information required for supporting a large
   number of VPNs, this broadcast may have unfortunate scaling
   implications.






Design Team               Expires January 2002                 [Page 50]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   In some cases VPNs may span multiple areas within a provider, or span
   multiple providers.  If VPN routing information is aggregated into
   the IGP used within the provider, then some method would need to be
   used to extend the reach of IGP routing information between areas and
   between providers.

5.4.4.2 Aggregated routing with BGP

   BGP is a path vector routing protocol.  This implies that any router
   participating in BGP has a great deal of flexibility concerning which
   routes it gives to any particular neighbor.  Specifically,a router x
   passes to a peer router y whatever routes x would like y to be able
   to use.  Each route includes a specification of what IP addresses are
   reachable via the route, and the path for the route (summarized to be
   on a routing domain by routing domain basis).  Flexible and
   configurable export policies control which routes x decides to pass
   to y.  Similarly, import policies control which routes y is willing
   to accept from x.

   In many cases, all routers within a routing domain, or at least all
   border routers within the domain (i.e., all routers which have
   neighbors outside the domain) may want to hear about the same routes.
   It is not efficient to have each router exchange routes directly with
   every other router in the domain.  Instead BGP allows certain routers
   (or devices running routing software) to operate as route reflectors.
   A route reflector can then receive routes from certain routers, and
   distribute those routes as desired to other routers.

   Also note that BGP can be run between routers which are physically
   adjacent, or alternatively can be run between two routers which are
   interconnected only by a longer path through other routers.  BGP is
   tunneled over IP in order to allow its operation between non-adjacent
   routers.

   When the VPN routing information is piggybacked on BGP, there is
   therefore a considerable amount of flexibility regarding which
   information is exchanged via which routers and route reflectors.
   This flexibility makes BGP a candidate for carrying BGP routes across
   a provider network [VPN-2547BIS].

   As noted above, there may be a large number of VPNs which are
   supported by any particular provider, and the total amount of routing
   information associated with all VPNs may be quite large.  However,
   any one PE will in general only need to be aware of a small number of
   VPNs.  This implies that where VPN routing information is aggregated
   into BGP, it is desirable to be able to limit which VPN information
   is distributed to which PEs.  BGP route filters can be used to
   control the distribution of routing information.



Design Team               Expires January 2002                 [Page 51]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   In some cases it may be desirable to simplify the design of PE
   equipment, and limit the number of systems which needs to be
   reconfigured when VPN membership changes.  It may also be desirable
   to avoid a full mesh of n-squared BGP associations between n PE
   routers within an organization.  BGP route reflectors can be used to
   control the redistribution of VPN routes between PE routers.  In many
   cases therefore it is likely that route reflectors may be used to
   distribute VPN routing information to PEs, and route filters will be
   used to ensure that information about a particular VPN will be
   distributed only to those PEs which participate in that VPN.

5.4.4.3 Partitioning of routing information with BGP

   BGP is used in most or all public networks for computing inter-domain
   routes to sites throughout the Internet.  If BGP is used for carrying
   VPN information, the total amount of information carried in BGP
   (including Internet routes and VPN routes) may be quite large.

   In some cases it may be desirable for any one route reflector to
   carry only a subset of the routing information.  For example, a set
   of one or more route reflectors might be used to carry Internet
   routes.  These route reflectors would therefore not carry any VPN
   routes.  A different set of one or more route reflectors might be
   used to carry all VPN routes.

   It is possible for the total number of VPN routes (across all VPNs
   supported by a service provider) to exceed the number which can be
   supported by a single route reflector.  For this reason, the VPN
   routes may themselves be partitioned, with some route reflectors
   carrying one subset of the VPN routes and other route reflectors
   carrying a different subset.

   Similarly each PE router would need to be aware of only those routes
   which it needs (specifically the VPN routes for VPNs which are
   present in that PE device, and optionally the Internet routes).

   BGP policies need to be configured to control which route reflectors
   and which PE routers need to pay attention to which pieces of routing
   information.

   Whether Internet routes are carried on the PE devices would again
   depend on configuration.  If the customer networks served by a
   particular PE do not need Internet access, then that PE does not need
   to be aware of Internet routes.  If some or all of the VPNs served by
   a particular PE need Internet access, then there are two options: (i)
   A default route may be used to route all Internet traffic from that
   PE to a different router within the service provider network, and
   that other router can handle the full Internet routing table.  With



Design Team               Expires January 2002                 [Page 52]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   this approach the PE router needs only a single default route for all
   Internet routes; (ii) The PE could instead obtain the full Internet
   routes from an appropriate route reflector.  In this case the PE
   router may be able to pick more optimal routes (avoiding an extra
   router hop), but at the cost of additional memory and CPU usage at
   the PE router.


5.4.4.4 Managing PE-to-PE backbone networks

   TBD.

5.5 Quality of Service, SLAs, and IP Differentiated Services

   The following technologies for QoS/SLA may be applicable to PPVPNs.

5.5.1 IntServ/RSVP [RFC2205] [RFC2208] [RFC2210] [RFC2746] [RSVP-LSP]

   Integrated services, or IntServ for short, is a mechanism for
   providing QoS/SLA by admission control.  RSVP is used to reserve
   network resources.  The network needs to maintain a state for each
   reservation.  The number of states in the network increases in
   proportion to the number of concurrent reservations.

   In some cases, IntServ on the edge of a network (e.g., over the CE-PE
   interface) may be mapped to DiffServ in the core of a network.

5.5.2 DiffServ [RFC2474] [RFC2475]

   IP differentiated service, or DiffServ for short, is a mechanism for
   providing QoS/SLA by differentiating traffic.  Traffic entering a
   network is classified into several behavior aggregates at the network
   edge and each is assigned a corresponding DiffServ codepoint.  Within
   the network, traffic is treated according to its DiffServ codepoint.
   Some behavior aggregates have already been defined.  Expedited
   forwarding behavior [RFC2598] guarantees the QoS, whereas assured
   forwarding behavior [RFC2597] differentiates traffic packet
   precedence values.

   When DiffServ is used, network provisioning is done on a per-traffic-
   class basis.  This ensures a specific class of service can be
   achieved for a class (assuming that the traffic load is controlled).
   All packets within a class are then treated equally within a service
   provider network.  Policing is done at input to prevent any one user
   from exceeding their allocation and therefore defeating the
   provisioning for the class as a whole.  If a user exceeds their
   traffic contract, then the excess packets may optionally be
   discarded, or may be marked as "over contract."  Routers throughout



Design Team               Expires January 2002                 [Page 53]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   the network can then preferentially discard over contract packets in
   response to congestion, in order to ensure that such packets do not
   defeat the service guarantees intended for in contract traffic.

5.5.3 MPLS Traffic Engineering

   LSPs with bandwidth guarantees can be set up using MPLS signaling and
   Constraint Based Routing.  More details are TBD.

5.6 Concurrent Access to VPNs and the Internet

   In some scenarios, customers will need to concurrently have access to
   their VPN network and to the public Internet.

   Two potential problems are identified in this scenario: the use of
   private addresses and the potential security threads.

   o The use of private addresses

     The IP addresses used in the customer's sites will possibly belong
     to a private routing realm, and as such be unusable in the public
     Internet.  This means that a translation function (NAT) will need
     to be implemented to allow VPN customers to access the Public
     Internet.

     In the case of layer 3 NBVPNs, this translation function will be
     implemented in the PE to which the CE device is connected.  In the
     case of provider provisioned CE-based VPNs, this translation
     function will be implemented on the CE device itself.  In the case
     of layer 2 NBVPNs, the Access to the Internet is not part of the
     layer 2 service offered by the SP.

   o Potential security thread

     As portions of the traffic that flow to and from the public
     Internet are not necessarily under nor the Service Provider's nor
     the customer's control, some traffic analyzing function (e.g., a
     firewall function) will be implemented to control the traffic
     entering and leaving the VPN.

     In the case of layer 3 NBVPNs, this traffic analyzing function will
     be implemented in the PE device (or in the VFI supporting a
     specific VPN), while in the case of provider provisioned CE-based
     VPNs, this function will be implemented in the CE device.







Design Team               Expires January 2002                 [Page 54]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   o Handling of a customer IP packet destined for the Internet

     In the case of layer 3 NBVPNs, an IP packet coming from a customer
     site will be handled in the corresponding VFI.  If the IP
     destination address in the packet's IP header belongs to the
     Internet, multiple scenarios are possible, based on the adapted
     policy.  As a first possibility, when Internet access is not
     allowed, the packet will be dropped.  As a second possibility, when
     (controlled) Internet access is allowed, the IP packet will go
     through the translation function and eventually through the traffic
     analyzing function before further processing in the PE's global
     Internet forwarding table.

   Note that different implementation choices are possible.  One can
   choose to implement the translation and/or the traffic analyzing
   function in every VFI (or CE device in the context of provider
   provisioned CE-based VPNs), or alternatively in a subset or even in
   only one VPN network element.  This would mean that the traffic
   to/from the Internet from/to any VPN site needs to be routed trough
   that single network element (this is what happens in a hub and spoke
   topology for example).

5.7 Network Management of VPNs

5.7.1 Customer management

   TBD.

5.7.2 Network management

   TBD.


6. Interworking Interface

   <Note: Currently, this section covers only layer 3 NBVPN.  IW
   discussions for layer 2 NBVPN and provider provisioned CE-based VPN
   are further study.>

6.1 Assumed Services to be Supported by Interworking

   This section assumes the five services, security/privacy, quality of
   service, extranet, dynamic routing, multicast, as services of layer 3
   NBVPNs to be mapped through interworking interface primarily.  Though
   other services may be required, interworking of these services are to
   be studied after detailed functions needed at interworking interface
   are made clear.




Design Team               Expires January 2002                 [Page 55]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   o Security/privacy (CUG)

     Security/Privacy (CUG) service provides communications between
     various specific customer sites through a layer 3 NBVPN.  Other
     customer sites cannot reach them.  This service prevents packets
     from being injected into the network without authorization.
     Private IP addressing may be used in a CUG.

   o Quality of service

     QoS/SLA services provide guaranteed and/or differentiated
     communications with layer 3 NBVPN-specific SLAs covering loss
     rates, delay variation, latency, and bandwidth etc.

   o Extranets

     Extranet service enables communications between specific CUGs or
     customer sites belonging to other CUGs within the networks.  Access
     control (including packet filtering and address translation) may be
     applied between CUGs according to policy.

   o Dynamic routing

     A dynamic routing service enables the exchange of unicast routing
     information between customer sites and a layer 3 NBVPN using a
     routing protocol such as Open Shortest Path First (OSPF) [RFC2328]
     or Border Gateway Protocol 4 (BGP-4) [RFC1771].  Routing
     information about each customer site can be distributed from one
     customer site to another.

     In Virtual Router approach [VPN-VR], scope of the routing
     information distribution is restricted within each layer 3 NBVPN by
     the security support.

     On the other hand, BGP-VPN [VPN-2547BIS] implements a different
     mechanism using BGP for dynamic routing information distribution.

   o Multicast

     A multicast service replicates multicast packets forwarded from
     customer sites in the networks and forwards them to multiple
     customer sites.  Multicast routing information is exchanged between
     customer sites and an layer 3 NBVPN using a multicast routing
     protocol.







Design Team               Expires January 2002                 [Page 56]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


6.2 Interworking Method

   This subsection describes the following fundamental usage and
   additional usages of the tunnels established across interworking
   interface to provide layer 3 NBVPN interworking, and then clarifies
   how each of the five required services is implemented through
   interworking interface.

6.2.1 Tunnels at interworking interface

   One or combination of the following methods can be used (although
   usage of multiple methods leads to the increased management burden)
   in establishing interworking interface.  Note that usage of other
   methods is not excluded as far as the established tunnel satisfies
   the requirements of layer 3 NBVPN interworking.

   o Use of MPLS

     The tunnels at interworking interface are provided by MPLS
     [RFC3031].

   o Use of GRE

     The tunnels at interworking interface are provided by GRE [RFC2784]
     with Key and Sequence Number Extensions [RFC2890].

   o Use of IPsec

     The tunnels at interworking interface are provided by IPsec
     [RFC2401].

   o Use of IP-in-IP

     The tunnels at interworking interface are provided by IP-in-IP
     [RFC2003].

   o Use of Frame Relay

     The tunnels at interworking interface are provided by Frame Relay.

   o Use of IP over ATM AAL5

     The tunnels at interworking interface are provided by IP over ATM
     AAL5 [RFC2684].  At least one VC is used for each of layer 3
     NBVPNs, and each VC is mapped to an layer 3 NBVPN.






Design Team               Expires January 2002                 [Page 57]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


6.2.2 Mapping of security/privacy (CUG)

   Each interworking tunnel is assigned for a specific layer 3 NBVPN; in
   other words, each end of the interworking tunnel is assigned for a
   specific layer 3 NBVPN at a PE router.  This mechanism results in
   implementation of CUG service spanning multiple SP networks of
   different technologies.  The procedures by which such an assignment
   is established are specific to the technology used by an SP network
   implementation.  The identity of layer 3 NBVPN at each end is
   meaningful only in the context of the specific technology of an SP
   network and need not be understood by another SP network interworking
   through the tunnel.  To avoid packets of a layer 3 NBVPN to be
   transferred to another layer 3 NBVPN, layer 3 NBVPNs do not share the
   same tunnel.

   Note that this document recommends that bandwidth of a tunnel does
   not interfere with bandwidth of any other tunnels, especially in case
   of QoS support service.  Detailed QoS specifications of the tunnel
   are for further study.

6.2.3 Support of extranet

   Extranet is supported by NAT/filtering function interconnecting two
   (or more) layer 3 NBVPNs.  Location of NAT/filtering function may be
   in one SP network supporting two layer 3 NBVPNs or in a customer site
   belonging to two (or more) layer 3 NBVPNs.  In any case, any special
   usage is not required for the NAT/filtering function between two
   layer 3 NBVPNs.  Furthermore, no specific functionality is required
   for the interworking interface between two SP networks.

6.2.4 Mapping of the quality of service

   Attributes of a QoS/CoS class may also be assigned to each tunnel.
   This enables provisioning of multiple QoS/CoS classes within each
   layer 3 NBVPN.
















Design Team               Expires January 2002                 [Page 58]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


           +-----------+                         +-----------+
     +-----+           +-----+             +-----+           +-----+
     |     +-----------+     |             |     +-----------+     |
     |     |           |     |-------------|     |           |     |
     | PE  |  NBVPN A  |  PE |-------------| PE  |  NBVPN A  |  PE |
     |     |           |     |-------------|     |           |     |
     |     +-----------+     |   Tunnels   |     +-----------+     |
     +-----+           +-----+     for     +-----+           +-----+
           +-----------+        different        +-----------+
          SP network(s) 1    QoS/CoS Classes    SP network(s) 2

      Figure 6.1: Using multiple tunnels for multiple QoS/CoS classes
                          for each layer 3 NBVPN.

   This may be achieved by using diffserv.  In this case, a bit-pattern
   in a field such as TOS of an IP header is used to identify a QoS/CoS
   class during packet transmission on the tunnel.


           +-----------+                         +-----------+
     +-----+           +-----+             +-----+           +-----+
     |     +-----------+     |             |     +-----------+     |
     |     |           |     |             |     |           |     |
     | PE  |  NBVPN A  |  PE |-------------| PE  |  NBVPN A  |  PE |
     |     |           |     |             |     |           |     |
     |     +-----------+     |    Tunnel   |     +-----------+     |
     +-----+           +-----+  supporting +-----+           +-----+
           +-----------+         diffserv        +-----------+
          SP network(s) 1                       SP network(s) 2

    Figure 6.2: Using diffserv for supporting multiple QoS/CoS classes
                          for each layer 3 NBVPN


6.2.5 Cooperation of dynamic routing service

   Route information packets, such as OSPF packets, are transmitted in
   isolated path of each layer 3 NBVPN in exactly the same manner as
   that for user data packets.  This enables dynamic routing information
   distribution within each layer 3 NBVPN.  One merit of this method is
   that the dynamic routing information distribution is executed with
   security of CUG service.  Another merit is that one of standard
   routing protocols such as BGP, OSPF, or RIP can be used without any
   extension.







Design Team               Expires January 2002                 [Page 59]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


6.2.6 Cooperation of multicast

   Multicast control packets, such as DVMRP, are transmitted in isolated
   path of each layer 3 NBVPN in the exactly same manner of the case of
   user data packets.  This enables dynamic routing information
   distribution for constructing multicast tree within each layer 3
   NBVPN.  One merit of this method is that the dynamic routing
   information distribution is executed with security of CUG service.
   Another merit is that one of standard multicast routing protocols
   such as DVMRP and PIM can be used without any extension.  After once
   constructed the multicast tree through interworking interface, it is
   obvious that data transfer over the multicast tree is supported as
   well.

6.3 Applicability and Scalability Discussion

   When constructing an inter-AS layer 3 NBVPN spanning multiple BGP-VPN
   capable SP networks, some interworking methods have been proposed
   [Section 10 of VPN-2547BIS].  However, among interworking methods
   which have been proposed so far, the method proposed in this document
   is applicable to various types of layer 3 NBVPN capable SP networks.
   The rest of this section discusses scalability of the proposed
   method.

   o Number of routing protocol instances

     As the proposed method requires as many routing protocol instances
     as layer 3 NBVPNs, there exists a limit in the number N of layer 3
     NBVPNs that one PE router can support (e.g., several hundreds) due
     to resource amount and performance of the PE router.  However, each
     interworking tunnels is expected to require some bandwidth and
     total of those bandwidth is limited by the capacity of an PE
     router, the number of the tunnels cannot be so large.  Then, this
     limit is not a critical drawback.

   o Performance of packet transmission

     The proposed method has the same degree of scalability as that of
     an interworking method using two layer label stacking of MPLS.

     In summary of this section, the proposed method has high
     applicability to various types of layer 3 NBVPN capable SP
     networks, while it's limit of scalability is not a critical
     drawback.







Design Team               Expires January 2002                 [Page 60]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


7. Security Considerations

   'Security' is one of the key requirements concerning VPNs.  In
   network environments, the term 'security' currently covers many
   different aspects of which the most important from a networking
   perspective are shortly discussed hereafter.

   Note that the Provider Provisioned VPN requirements document explains
   the different security requirements for Provider Provisioned VPNs in
   more detail.

7.1 System security

   Like in every network environment, system security is the most
   important security aspect that must be enforced.  Care must be taken
   that no unauthorized party can gain access to the network elements
   that control the VPN functionality (PE device, CE device).

   As the VPN customers are making use of the shared SP's backbone, the
   SP must ensure the system security of its network elements.

7.2 Access Control

   When a network or parts of a network are 'private', one of the
   requirements is that access to that network (part) must be restricted
   to a limited number of well-defined users.  To accomplish this
   requirement, the responsible authority must control every possible
   access to the network.

   In the context of NBVPNs, the access points to a VPN must be limited
   to the interfaces that are known by the SP.

7.3 Endpoint authentication

   When one receives data from a certain entity, one would like to be
   sure of the identity of the sending party.  One would like to be sure
   that the sending entity is who he claims he is, and that the sending
   entity is authorized to reach a particular destination.

   In the context of NBVPNs, both the data received by the PEs from the
   customer sites as the data received by the PEs via the SP network and
   destined for a customer site should be authenticated.

   Note that different methods for authentication exist.  In certain
   circumstances, identifying incoming packets with specific customer
   interfaces might be sufficient.  In other circumstances, like in
   temporary access (dial-in) scenarios, a preliminary authentication
   phase might be requested, e.g., when PPP is used.  Or alternatively,



Design Team               Expires January 2002                 [Page 61]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   an authentication prove might need to be present in every data packet
   transmitted (like in remote access via IPsec).

   For NBVPNs, VPN traffic will be tunneled from PE to PE and the tunnel
   endpoint will check the origin of the transmitted packet.  When e.g.,
   MPLS is used for VPN tunneling, the tunnel endpoint checks whether
   the correct labels are used.  When e.g., IPsec is used for VPN
   tunneling, the tunnel endpoint can make use of the IPsec
   authentication mechanisms.

   In the context of Provider Provisioned CE-based VPNs, the endpoint
   authentication is enforced by the CE devices.

7.4 Data Integrity

   When information is exchanged over a certain part of a network, one
   would like to be sure that the information that is received by the
   receiving party of the exchange is identical to the information that
   was sent by the sending party of the exchange.

   In the context of NBVPNs, the SP assures the data integrity by
   ensuring the system security of every network element.
   Alternatively, explicit mechanisms may be implemented in the used
   tunneling technique (e.g., IPsec).

   In the context of CE-based Provider Provisioned VPNs, the underlying
   network that will tunnel the encapsulated packets will not always be
   of a trusted nature, and the CE devices that are responsible for the
   tunneling will also ensure the data integrity, e.g., by making use of
   the IPsec architecture.

7.5 Confidentiality

   One would like that the information that is being sent from one party
   to another is not received and not readable by other parties.  With
   'traffic flow confidentiality' one would like that even the
   characteristics of the information sent is hidden for third parties.
   'Data Privacy' is the confidentiality of the user data.

   In the context of Provider Provisioned VPNs, 'confidentiality' is
   often seen as the basic service offered, as the functionalities of a
   private network are offered over a shared infrastructure.

   In the context of NBVPNs, as the SP network (and more precisely the
   PE devices) participates in the routing and forwarding of the
   customer VPN data, it is the SP's responsibility to ensure the data
   privacy.  The technique used in NBVPN solutions is the ensuring of PE
   to PE data separation.  By implementing VFI/VSI's in the PE devices



Design Team               Expires January 2002                 [Page 62]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   and by tunneling VPN packets through the shared network
   infrastructure between PE devices, the VPN data is always kept in a
   separate context and thus separated from the other data.

   In some situations, this 'data separation' might not be sufficient.
   Circumstances where the VPN tunnel traverses other than only trusted
   and SP controlled network parts require stronger confidentiality
   measures such as cryptographic data encryption.  This is the case in
   certain inter-SP VPN scenarios or when the considered SP is on itself
   a client of a third party 'network provider'.

   For Provider Provisioned CE-based VPNs, the SP network does not bare
   responsibility for confidentiality assurance, as the SP just offers
   IP connectivity.  The confidentiality will then be enforced at the CE
   and will lie in the tunneling (data separation) or in the
   cryptographic encryption (e.g., using IPsec) by the CE device.

   Note that for very sensitive user data (e.g., used in banking
   operations) the VPN customer will not outsource his data privacy
   enforcement to a trusted SP.  In those situations, PE-to-PE
   confidentiality will not be sufficient and end-to-end cryptographic
   encryption will be implemented by the VPN customer itself on its own
   private equipment (using CE-based VPN technologies or cryptographic
   encryption over the provided VPN connectivity).

7.6 User data and Control data

   An important remark is the fact that both the user data as the VPN
   control data must be protected.

   Previous subsections were focused on the protection of the user data,
   but all the control data (e.g., used to set up the VPN tunnels, used
   to configure the VFI/VSI's or the CE devices (in the context of
   Provider Provisioned CE-based VPNs)) will also be secured by the SP
   to prevent deliberate misconfiguration of Provider Provisioned VPNs.

7.7 Inter-SP VPNs

   In certain scenarios, a single VPN will need to cross multiple SPs.

   The fact that the edge-to-edge part of the data path does not fall
   under the control of the same entity can have security implications
   with regards to e.g., endpoint authentication.

   Another point is that the SPs involved must closely interact to avoid
   conflicting configuration information on VPN network elements (such
   as VFIs, VSIs, PEs, CE devices) connected to the different SPs.




Design Team               Expires January 2002                 [Page 63]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


Appendix A: Optimizations for Tunnel Forwarding

A.1 Header Lookups in the VFIs

   If layer 3 NBVPNs are implemented in the most straightforward manner,
   then it may be necessary for PE routers to perform multiple header
   lookups in order to forward a single data packet.  This section
   discusses an example of how multiple lookups might be needed with the
   most straightforward implementation.  Optimizations which might
   optionally be used to reduce the number of lookups are discussed in
   the following sections.

   As an example, in many cases a tunnel may be set up between VFIs
   within PEs for support of a given VPN.  When a packet arrives at the
   egress PE, the PE may need to do a lookup on the outer header to
   determine which VFI the packet belongs to.  The PE may then need to
   do a second lookup on the packet that was encapsulated across the
   tunnel, using the forwarding table specific to that VPN, before
   forwarding the packet.

   For scaling reasons it may be desired in some cases to set up PE to
   PE tunnels, and then multiplex multiple VPN-specific tunnels within
   the PE to PE tunnels.

   This implies that in the most straightforward implementation three
   header lookups might be necessary in a single PE device: One lookup
   may identify that this is the end of the PE to PE tunnel (implying
   the need to strip off the associated header).  A second lookup may
   identify that this is the end of the VPN-specific tunnel.  This
   lookup will result in stripping off the second encapsulating header,
   and will identify the VFI context for the final lookup.  The last
   lookup will make use of the IP address space associated with the VPN,
   and will result in the packet being forwarded to the correct CE
   within the correct VPN.

A.2 Penultimate Hop Popping for MPLS

   Penultimate hop popping is an optimization which is described in the
   MPLS architecture document [RFC3031].

   Consider the egress node of any MPLS LSP.  The node looks at the
   label, and discovers that it is the last node.  It then strips off
   the label header, and looks at the next header in the packet (which
   may be an IP header, or which may have another MPLS header in the
   case that hierarchical nesting of LSPs is used).  For the last node
   on the LSP, the outer MPLS header doesn't actually convey any useful
   information (except for one situation discussed below).




Design Team               Expires January 2002                 [Page 64]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   For this reason, the MPLS standards allow the egress node to request
   that the penultimate node strip the MPLS header.  If requested, this
   implies that the penultimate node does not have a valid label for the
   LSP, and must strip the MPLS header.  In this case, the egress node
   receives the packet with the corresponding MPLS header already
   stripped, and can forward the packet properly without needing to
   strip the header for the LSP which ends at that egress node.

   There is one case in which the MPLS header conveys useful
   information: This is in the case of a VPN-specific LSP terminating at
   a PE router.  In this case, the value of the label tells the PE which
   LSP the packet is arriving on, which in turn is used to determine
   which VFI is used for the packet (i.e., which VPN-specific forwarding
   table needs to be used to forward the packet).

   However, consider the case where multiple VPN-specific LSPs are
   multiplexed inside one PE-to-PE LSP.  Also, let's suppose that in
   this case the egress PE has chosen all incoming labels (for all LSPs)
   to be unique in the context of that PE.  This implies that the label
   associated with the PE to PE LSP is not needed by the egress node.
   Rather, it can determine which VFI to use based on the VPN-specific
   LSP.  In this case, the egress PE can request that the penultimate
   LSR performs penultimate label popping for the PE to PE LSP.  This
   eliminates one header lookup in the egress LSR.

   Note that penultimate node label popping is only applicable for VPN
   standards which use multiple levels of LSPs.  Even in this case
   penultimate node label popping is only done when the egress node
   specifically requests it from the penultimate node.

A.3 Demultiplexing to Eliminate the Tunnel Egress VFI Lookup

   Consider a VPN standard which makes use of MPLS as the tunneling
   mechanism.  Any standard for encapsulating VPN traffic inside LSPs
   needs to specify what degree of granularity is available in terms of
   the manner in which user data traffic is assigned to LSPs.  In other
   words, for any given LSP, the ingress or egress PE device needs to
   know which LSPs need to be set up, and the ingress PE needs to know
   which set of VPN packets are allowed to be mapped to any particular
   LSP.

   Suppose that a VPN standard allows some flexibility in terms of the
   mapping of packets to LSPs, and suppose that the standard allows the
   egress node to determine the granularity.  In this case the egress
   node would need to have some way to indicate the granularity to the
   ingress node, so that the ingress node will know which packets can be
   mapped to each LSP.




Design Team               Expires January 2002                 [Page 65]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   In this case, the egress node might decide to have packets mapped to
   LSPs in a manner which simplifies the header lookup function at the
   egress node.  For example, the egress node could determine which set
   of packets it will forward to a particular neighbor CE device.  The
   egress node can then specify that the set of IP packets which are to
   use a particular LSP correspond to that specific set of packets.  For
   packets which arrive on the specified LSP, the egress node does not
   need to do a header lookup on the VPN's customer address space: It
   can just pop the MPLS header and forward the packet to the
   appropriate CE device.  If all LSPs are set up accordingly, then the
   egress node does not need to do any lookup for VPN traffic which
   arrives on LSPs from other PEs (in other words, the PE router will
   not need to do a second lookup in its role as an egress node).

   Note that PE routers will most likely also be an ingress routers for
   traffic going in the other direction.  The PE router will need to do
   an address lookup in the customer network's address space in its role
   as an ingress node.  However, in this direction the PE still needs to
   do only a single header lookup.

   When used with MPLS tunnels, this optional optimization reduces the
   need for header lookups, at the cost of possibly increasing the
   number of label values which need to be assigned (since one label
   would need to be assigned for each next-hop CE device, rather than
   just one label for every VFI).

   The same approach is also possible when other encapsulations are
   used, such as IP-in-IP [RFC2003], GRE [RFC2784] [RFC2890], or IPsec
   [RFC2401] [RFC2402].  This requires that distinct values are used for
   the multiplexing field in the tunneling protocol.  If IP-in-IP
   encapsulation is used, then separate IP addresses could assigned for
   tunnels which are to be forwarded to different next hop CE devices.
   This implies that this method may be used to reduce the number of
   header lookups, at the cost of increasing the use of IP addresses
   used as destination addresses for tunnels.  If GRE encapsulation is
   used, then the "key" field could be used for multiplexing, which
   implies that different values of this field could be used for packets
   destined to different next hop CE routers.  For IPsec the SPI field
   could be used in the same manner.


Acknowledgments

   This document is output of the framework document design team of the
   PPVPN WG.  However, sources of this document are based on various
   inputs from colleagues of authors.  We would like to thank Junichi
   Sumimoto, Kosei Suzuki, Hiroshi Kurakami, Takafumi Hamano, Naoto
   Makinae, and Kenichi Kitami of NTT and Rajesh Balay, Anoop Ghanwani,



Design Team               Expires January 2002                 [Page 66]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   Harpreet Chadha, Samir Jain, Lianghwa Jou, Vijay Srinivasan, and
   Abbie Matthews of CoSine Communications.

   We would also like to thank Yakov Rekhter of Juniper Networks, Scott
   Bradner of Harvard University, and Jeremy De Clercq of Alcatel for
   their valuable comments and suggestions.


Intellectual Property

   Intellectual property rights may have been claimed with regard to
   some of the techniques and mechanisms described in this framework
   document.  For more information consult the online list of claimed
   rights maintained by the IETF at http://www.ietf.org/ipr.html.


References

   [PPVPN-REQ] Carugi, M. et al., "Service Requirements for Provider
   Provisioned Virtual Private Networks," Internet-draft <draft-ietf-
   ppvpn-requirements-01.txt>, June 2001.

   [RFC2764] Gleeson, B. et al., "A Framework for IP Based Virtual
   Private Networks," RFC 2764, February 2000.

   [RFC2547] Rosen, E. and Rekhter, Y., "BGP/MPLS VPN," RFC 2547, March
   1999.

   [RFC2684] Grossman, D. and Heinanen, J., "Multiprotocol Encapsulation
   over ATM Adaptation Layer 5," RFC 2684, September 1999.

   [RFC2685] Fox B. and Gleeson, B., "Virtual Private Networks
   Identifier," RFC 2685, September 1999.

   [VPN-2547BIS] Rosen, E. et al., "BGP/MPLS VPNs," Internet-draft
   <draft-rosen-rfc2547bis-03.txt>, February 2001.

   [VPN-BGP-V6] Nguyen, T. et al., "BGP-MPLS VPN extension for IPv6 VPN
   over an IPv4 infrastructure," Internet-draft <draft-nguyen-bgp-
   ipv6-vpn-02.txt>, June 2001.

   [VPN-BGP-OSPF] Rosen, E. et al., "OSPF as the PE/CE Protocol in
   BGP/MPLS VPNs," Internet-draft <draft-rosen-vpns-ospf-bgp-
   mpls-02.txt>, June 2001.

   [VPN-BGP-MCAST] Rosen, E. et al., "Multicast in MPLS/BGP VPNs,"
   Internet-draft <draft-rosen-vpn-mcast-02.txt>, July 2001.




Design Team               Expires January 2002                 [Page 67]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   [VPN-BGP-IPSEC1] De Clercq, J. et al., "BGP/IPsec VPN," Internet-
   draft <draft-declercq-bgp-ipsec-vpn-01.txt>, February 2001.

   [VPN-BGP-IPSEC2] Rosen, E. et al., "Use of PE-PE IPsec in RFC2547
   VPNs," Internet-draft <draft-rosen-ppvpn-ipsec-2547-00.txt>, June
   2001.

   [VPN-BGP-GRE] Rekhter, Y. et al., "Use of PE-PE GRE or IP in RFC2547
   VPNs," Internet-draft <draft-rekhter-ppvpn-gre-ip-2547-00.txt>, June
   2001.

   [VPN-BGP-VR] Ould-Brahim, H. et al., "Using BGP as an Auto-Discovery
   Mechanism for Network-based VPNs," Internet-draft <draft-ouldbrahim-
   bgpvpn-auto-01.txt>, March 2001.

   [VPN-BGP-MIB] Nadeau, T. et al., "MPLS/BGP Virtual Private Network
   Management Information Base Using SMIv2," Internet-draft <draft-
   nadeau-mpls-vpn-mib-03.txt>, July 2001.

   [VPN-VR] Ould-Brahim, H. et al., "Network based IP VPN Architecture
   Using Virtual Routers," Internet-draft <draft-ouldbrahim-vpn-
   vr-03.txt>, March 2001.

   [VPN-VR-MIB] Stelzer, E. and Hancock, S., "Virtual Router Management
   Information Base Using SMIv2," Internet-draft <draft-elwin-ppvpn-vr-
   mib-00.txt>, June 2001.

   [VPN-IPSEC1] Gleeson B., "Uses of IPsec with Provider Provisioned
   VPNs," Internet-draft <draft-gleeson-ipsec-ppvpn-00.txt>, February
   2001.

   [VPN-IPSEC2] Lordello, C. et al., "VPN-ID-Enhanced IPSec-VPN DOI for
   ISAKMP," Internet-draft <draft-lordello-ipsec-vpn-doi-00.txt>, August
   2000.

   [VPN-L2-1] Kompella, K. et al., "MPLS-based Layer 2 VPNs" Internet-
   draft <draft-kompella-ppvpn-l2vpn-00.txt>, June 2001.

   [VPN-L2-2] Rosen, E., "An Architecture for L2VPNs," Internet-draft
   <draft-rosen-ppvpn-l2vpn-00.txt>, May 2001.

   [VPN-INTER] Kurakami, H. et al., "Provider-Provisioned VPN
   Interworking," Internet-Draft <draft-kurakami-ppvpn-
   interworking-00.txt>, February 2001.

   [VPN-2917BIS] Muthukrishnan, K. et al, "A Core MPLS IP VPN
   Architecture," Internet-draft <draft-muthukrishnan-
   rfc2917bis-00.txt>, November 2000.



Design Team               Expires January 2002                 [Page 68]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   [RFC3031] Rosen E. et al., "Multiprotocol Label Switching
   Architecture," RFC 3031, January 2001.

   [MPLS-FRAME] Callon, R. et al., "A Framework for Multiprotocol Label
   Switching," <draft-ietf-mpls-framework-05.txt>, September 1999.

   [RFC3035] Davie, B. et al., "MPLS using LDP and ATM VC Switching,"
   RFC 3035, January 2001.

   [MPLS-DIFF] Le Faucheur, F. et al., "MPLS Support of Differentiated
   Services," Internet-draft <draft-ietf-mpls-diff-ext-07.txt>, August
   2000.

   [MPLS-GMNCL] Kuwahara, T. et al., "Scalable Connectionless Tunneling
   Architecture and Protocols for VPNs," Internet-draft <draft-kuwahara-
   cl-tunneling-vpn-00.txt>, June 2001.

   [RFC2003] C. Perkins "IP Encapsulation within IP," RFC 2003, October
   1996.

   [RFC2784] Farinacci, D. et al., "Generic Routing Encapsulation
   (GRE)," RFC 2784, March 2000.

   [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE,"
   RFC 2890, September 2000.

   [RFC2401] Kent, S. and Atkinson, R., "Security Architecture for the
   Internet Protocol," RFC 2401, November 1998.

   [RFC2402] Kent, S. and Atkinson, R., "IP Authentication Header," RFC
   2402, November 1998.

   [RFC2406] Kent, S. and Atkinson, R., "IP Encapsulating Security
   Payload (ESP)," RFC 2406, November 1998.

   [RFC2409] Harkins, D. and Carrel, D., "The Internet Key Exchange
   (IKE)," RFC 2409, November 1998.

   [RFC2661] Townsley, W. et al., "Layer Two Tunneling Protocol 'L2TP',"
   RFC 2661, August 1999.

   [RFC2453] Malkin, G., "RIP Version 2," RFC 2453, November 1994.

   [RFC2328] Moy, J., "OSPF Version 2," RFC 2328, April 1998.

   [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
   Dual Environments," RFC 1195, December 1990.




Design Team               Expires January 2002                 [Page 69]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   [RFC1771] Rekhter, Y. and Li, T., "A Border Gateway Protocol 4
   (BGP-4)," RFC 1771, March 1995.

   [RFC1965] Traina, P., "Autonomous System Confederations for BGP," RFC
   1965, June 1996.

   [RFC1966] Bates, T., "BGP Route Reflection: An alternative to full
   mesh IBGP," RFC 1966, June 1996.

   [RFC1997] Chandra, R., Traina, P., and Li, T., "BGP Communities
   Attribute," RFC 1997, August 1996.

   [RFC2858] Bates, T., Chandra, R., Katz, D., and Rekhter, Y.,
   "Multiprotocol Extensions for BGP-4," RFC 2283, February 1998.

   [BGP-COM] Sangli, S., "BGP Extended Communities Attribute," Internet-
   draft <draft-ietf-idr-bgp-ext-communities-00.txt> July 2001.

   [RFC2205] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) --
   Version 1 Functional Specification," RFC 2205, September 1997.

   [RFC2208] Mankin, A. et al., "Resource ReSerVation Protocol (RSVP)
   Version 1 Applicability Statement Some Guidelines on Deployment," RFC
   2208, September 1997.

   [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
   Services," RFC 2210, September 1997.

   [RFC2211] Wroclawski, J., "Specification of the Controlled-Load
   Network Element Service," RFC 2211, September 1997.

   [RFC2212] Shenker, S., Partridge, C., and Guerin, R., "Specification
   of Guaranteed Quality of Service," RFC 2212, September 1997.

   [RFC2207] Berger, L. and O'Malley, T., "RSVP Extensions for IPSEC
   Data Flows," RFC 2207, September 1997.

   [RFC2746] Terzis, A. et al., "RSVP Operation Over IP Tunnels," RFC
   2746, January 2000.

   [RSVP-LSP] Awduche, D. et al., "Extensions to RSVP for LSP Tunnels,"
   Internet-draft <draft-ietf-mpls-rsvp-lsp-tunnel-07.txt>, August 2000.

   [RFC2474] Nichols, K. et al., "Definition of the Differentiated
   Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC 2474,
   December 1998.

   [RFC2475] Blake S. et al., "An architecture for Differentiated



Design Team               Expires January 2002                 [Page 70]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   Services," RFC 2475, December 1998.

   [RFC2597] Heinanen, J. et al., "Assured Forwarding PHB Group," RFC
   2597, June 1999.

   [RFC2598] Jacobsen, V. et al., "An Expedited Forwarding PHB," RFC
   2598, June 1999.

   [RFC2983] Black, D., "Differentiated Services and Tunnels," RFC 2983,
   October 2000.

   [RFC1777] Yeong, W. et al., "Lightweight Directory Access Protocol,"
   RFC 1777, March 1995.

   [RFC2251] Wahl, M. et al., "Lightweight Directory Access Protocol
   (v3)," RFC 2251, December 1997.

   [LDAP-PERSIST] Smith, M. (Ed.), "Persistent Search: A Simple LDAP
   Change Notification Mechanism," Internet-draft <draft-ietf-ldapext-
   psearch-03.txt>, November 2000.

   [RFC1918] Rekhter, Y. et al., "Address Allocation for Private
   Internets," RFC 1918, February 1996.


Authors' addresses

   Ross Callon
   Juniper Networks
   1194 N. Mathilda Ave
   Sunnyvale, CA  94089, USA
   Email: rcallon@juniper.net

   Muneyoshi Suzuki
   NTT Information Sharing Platform Labs.
   3-9-11, Midori-cho,
   Musashino-shi, Tokyo 180-8585, Japan
   Email: suzuki.muneyoshi@lab.ntt.co.jp

   Bryan Gleeson
   Email: bryangleeson@yahoo.com

   Andrew G. Malis
   Vivace Networks, Inc.
   2730 Orchard Parkway
   San Jose, CA 95134, USA
   Email: Andy.Malis@vivacenetworks.com




Design Team               Expires January 2002                 [Page 71]

INTERNET-DRAFT           A Framework for PPVPNs                July 2001


   Karthik Muthukrishnan
   Lucent Technologies
   1 Robbins Road
   Westford, MA 01886, USA
   Email: mkarthik@lucent.com

   Eric C. Rosen
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824
   Email: erosen@cisco.com

   Chandru Sargor
   Cosine Communications
   1200 Bridge Parkway
   Redwood City, CA 94065
   Email: Chandramouli.Sargor@cosinecom.com

   Jieyun Jessica Yu
   Email: jyy_99@yahoo.com































Design Team               Expires January 2002                 [Page 72]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/