tech-invite   World Map     

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

RFC 4110

 
 
 

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

Part 2 of 4, p. 14 to 39
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 14 
2.  Reference Models

   This section describes PPVPN reference models.  The purpose of
   discussing reference models is to clarify the common components and
   pieces that are needed to build and deploy a PPVPN.  Two types of
   VPNs, layer 3 PE-based VPN and layer 3 provider-provisioned CE-based
   VPN are covered in separated sections below.

2.1.  Reference Model for Layer 3 PE-based VPN

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

   Figure 2.1 shows the reference model for layer 3 PE-based VPNs and
   Figures 2.2 and 2.3 show relationship between entities in the
   reference model.

   As shown in Figure 2.1, the customer interface is defined as the
   interface which exists between CE and PE devices, and the network
   interface is defined as the interface which exists between a pair of
   PE devices.

   Figure 2.2 illustrates a single logical tunnel between each pair of
   VFIs supporting the same VPN.  Other options are possible.  For
   example, a single tunnel might occur between two PEs, with multiple
   per-VFI tunnels multiplexed over the PE to PE tunnel.  Similarly,
   there may be multiple tunnels between two VFIs, for example to
   optimize forwarding within the VFI.  Other possibilities will be
   discussed later in this framework document.

Top      Up      ToC       Page 15 
    +---------+  +------------------------------------+  +---------+
    |         |  |                                    |  |         |
    |         |  |                     +------+     +------+  : +------+
+------+ :    |  |                     |      |     |      |  : |  CE  |
|  CE  | :    |  |                     |  P   |     |  PE  |  : |device|
|device| :  +------+   VPN tunnel   :  |router|     |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 2.1: Reference model for layer 3 PE-based VPN.


               +----------+                  +----------+
+-----+        |PE device |                  |PE device |        +-----+
| 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 2.2: Relationship between entities in reference model (1).

Top      Up      ToC       Page 16 
               +----------+                  +----------+
+-----+        |PE device |                  |PE device |        +-----+
| 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 2.3: Relationship between entities in reference model (2).

2.1.1.  Entities in the Reference Model

   The entities in the reference model are described below.

   o Customer edge (CE) device

     In the context of layer 3 provider-provisioned PE-based VPNs, a CE
     device may be a router, LSR, or host that has no VPN-specific
     functionality.  It is attached via an access connection to a PE
     device.

   o P router

     A 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.

   o Provider edge (PE) device

     In the context of layer 3 provider-provisioned PE-based VPNs, a PE
     device implements one or more VFIs and maintains per-VPN state for
     the support of one or more VPNs.  It may be a router, LSR, or other
     device that includes VFIs and provider edge VPN functionality such
     as provisioning, management, and traffic classification and
     separation.  (Note that access connections are terminated by VFIs
     from the functional point of view).  A PE device is attached via an
     access connection to one or more CE devices.

Top      Up      ToC       Page 17 
   o Customer site

     A customer site is a set of users that have mutual IP reachability
     without use of a VPN backbone that goes beyond the site.

   o SP networks

     An SP network is an IP or MPLS 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.  Access connections can be,
     e.g., dedicated physical circuits, logical circuits (such as FR,
     ATM, and MAC), or IP tunnels (e.g., using IPsec, L2TP, or MPLS).

   o Access network

     An access network provides access connections between CE 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 VPN edge devices.  A VPN
     packet is carried on a tunnel by encapsulating it before
     transmitting it over the VPN backbone.

     Multiple VPN 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.,
     GRE, IP-in-IP, IPsec, or MPLS tunnel).  This is illustrated in
     Figure 2.3.  See section 4.3 for details.

   o VPN forwarding instance (VFI)

     A single PE device is likely to be connected to a number of CE
     devices.  The CE devices are unlikely to all be in the same VPN.
     The PE device must therefore maintain a separate forwarding
     instances for each VPN to which it is connected.  A VFI is a
     logical entity, residing in a PE, that contains the router
     information base and forwarding information base for a VPN.  The
     interaction between routing and VFIs is discussed in section 4.4.2.

Top      Up      ToC       Page 18 
   o Customer management function

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

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

   o Network management function

     The network management function supports the provisioning and
     monitoring of PE or CE device attributes and their relationships.

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

2.1.2.  Relationship Between CE and PE

   For robustness, a CE device may be connected to more than one PE
   device, resulting in a multi-homing arrangement.  Four distinct types
   of multi-homing arrangements, shown in Figure 2.4, may be supported.

Top      Up      ToC       Page 19 
                 +----------------                    +---------------
                 |                                    |
             +------+                             +------+
   +---------|  PE  |                   +---------|  PE  |
   |         |device|                   |         |device| SP network
   |         +------+                   |         +------+
+------+         |                   +------+         |
|  CE  |         |                   |  CE  |         +---------------
|device|         |   SP network      |device|         +---------------
+------+         |                   +------+         |
   |         +------+                   |         +------+
   |         |  PE  |                   |         |  PE  |
   +---------|device|                   +---------|device| SP network
             +------+                             +------+
                 |                                    |
                 +----------------                    +---------------
This type includes a CE device connected
to a PE device via two access connections.
                (a)                                  (b)

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

                (c)                                  (d)

        Figure 2.4: Four types of double-homing arrangements.

2.1.3.  Interworking Model

   It is quite natural to assume that multiple different layer 3 VPN
   approaches may be implemented, particularly if the VPN backbone
   includes more than one SP network.  For example, (1) each SP chooses
   one or more layer 3 PE-based VPN approaches out of multiple vendor's
   implementations, implying that different SPs may choose different

Top      Up      ToC       Page 20 
   approaches; and (2) an SP may deploy multiple networks of layer 3
   PE-based VPNs (e.g., an old network and a new network).  Thus it is
   important to allow interworking of layer 3 PE-based VPNs making use
   of multiple different layer 3 VPN approaches.

   There are three scenarios that enable layer 3 PE-based VPN
   interworking among different approaches.

   o Interworking function

     This scenario enables interworking using a PE that is located at
     one or more points which are logically located between VPNs based
     on different layer 3 VPN approaches.  For example, this PE may be
     located on the boundary between SP networks which make use of
     different layer 3 VPN approaches [VPN-DISC].  A PE at one of these
     points is called an interworking function (IWF), and an example
     configuration is shown in Figure 2.5.

               +------------------+  +------------------+
               |                  |  |                  |
          +------+  VPN tunnel  +------+  VPN tunnel  +------+
          |      |==============|      |==============|      |
          |      |              |      |              |      |
          |  PE  |              |  PE  |              |  PE  |
          |      |              |device|              |      |
          |device|              |(IWF) |              |device|
          |      |  VPN tunnel  |      |  VPN tunnel  |      |
          |      |==============|      |==============|      |
          +------+              +------+              +------+
               |                  |  |                  |
               +------------------+  +------------------+
               |<-VPN approach 1->|  |<-VPN approach 2->|

                   Figure 2.5: Interworking function.

   o Interworking interface

     This scenario enables interworking using tunnels between PEs
     supporting by different layer 3 VPN approaches.  As shown in Figure
     2.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.

Top      Up      ToC       Page 21 
       +------------------+                     +------------------+
       |                  |          :          |                  |
   +------+ VPN tunnel +------+Tunnel:      +------+ VPN tunnel +------+
   |      |============|      |======:======|      |============|      |
   |      |            |      |      :      |      |            |      |
   |  PE  |            |  PE  |      :      |  PE  |            |  PE  |
   |      |            |      |      :      |      |            |      |
   |device|            |device|      :      |device|            |device|
   |      | VPN tunnel |      |Tunnel:      |      | VPN tunnel |      |
   |      |============|      |======:======|      |============|      |
   +------+            +------+      :      +------+            +------+
       |                  |          :          |                  |
       +------------------+    Interworking     +------------------+
       |<-VPN approach 1->|     interface       |<-VPN approach 2->|

                     Figure 2.6: Interworking interface.

     o Customer-based interworking

     If some customer site has a CE attached to one kind of VPN, and a
     CE attached to another kind, communication between the two kinds of
     VPN occurs automatically.

2.2.  Reference Model for Layer 3 Provider-Provisioned CE-based VPN

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

   Figure 2.7 shows the reference model for layer 3 provider-provisioned
   CE-based VPN.  As shown in Figure 2.7, the customer interface is
   defined as the interface which exists between CE and PE devices.

   In this model, a CE device maintains one or more VPN tunnel
   endpoints, and a PE device has no VPN-specific functionality.  As a
   result, the interworking issues of section 2.1.3 do not arise.

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

                Figure 2.7: Reference model for layer 3
                   provider-provisioned CE-based VPN.

2.2.1.  Entities in the Reference Model

   The entities in the reference model are described below.

   o Customer edge (CE) device

     In the context of layer 3 provider-provisioned CE-based VPNs, a CE
     device provides layer 3 connectivity to the customer site.  It may
     be a router, LSR, or host that maintains one or more VPN tunnel
     endpoints.  A CE device is attached via an access connection to a
     PE device and usually located at the edge of a customer site or
     co-located on an SP premises.

   o P router (see section 2.1.1)

   o Provider edge (PE) device

     In the context of layer 3 provider-provisioned CE-based VPNs, a PE
     device may be a router, LSR, or other device that has no
     VPN-specific functionality.  It is attached via an access
     connection to one or more CE devices.

Top      Up      ToC       Page 23 
   o Customer Site (see section 2.1.1)

   o SP networks

     An SP network is a network administrated by a single service
     provider.  It is an IP or MPLS network.  In the context of layer 3
     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 2.1.1)

   o Access network (see section 2.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 layer 3 provider-provisioned CE-based
     VPNs, a VPN tunnel is an IP tunnel (e.g., using GRE, IP-in-IP,
     IPsec, or L2TP) or an MPLS tunnel between two CE devices over the
     SP's network.

   o Customer management function (see section 2.1.1)

   o Network management function

     The network management function supports the provisioning and
     monitoring of PE or CE device attributes and their relationships,
     covering PE and CE devices that define the VPN connectivity of the
     customer VPNs.

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

3.  Customer Interface

3.1.  VPN Establishment at the Customer Interface

3.1.1.  Layer 3 PE-based VPN

   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

Top      Up      ToC       Page 24 
   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 customer sites are
   added to or removed from the VPNs.

   In some layer 3 PE-based PPVPN schemes, VPN membership information
   (i.e., information about which PEs are attached to which VPNs) is
   explicitly distributed.  In others, the membership information is
   inferred from other information that is distributed.  Different
   schemes use the membership information in different ways, e.g., some
   to determine what set of tunnels to set up, some to constrain the
   distribution of VPN routing information.

   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.

3.1.1.1.  Static Binding

   Static binding occurs when a provisioning action binds a particular
   PE-CE access link to a particular VPN.  For example, a network
   administrator may set up a dedicated link layer connection, such as
   an ATM VCC or a FR DLCI, between a PE device and a CE device.  In
   this case the binding between a PE-CE access connection and a
   particular VPN to fixed at provisioning time, and remains the same
   until another provisioning action changes the binding.

3.1.1.2.  Dynamic Binding

   Dynamic binding occurs when some real-time protocol interaction
   causes a particular PE-CE access link to be temporarily bound to a
   particular VPN.  For example, a mobile user may dial up the provider
   network and carry out user authentication and VPN selection
   procedures.  Then 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
   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

Top      Up      ToC       Page 25 
   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.
   This suggests that there needs to be a way to distribute membership
   information rapidly and reliably when these user-initiated actions
   take place.

3.1.2.  Layer 3 Provider-Provisioned CE-based VPN

   In layer 3 provider-provisioned CE-based VPNs, the PE devices have no
   knowledge of the VPNs.  A PE device attached to a particular VPN has
   no knowledge of the addressing or routing information of that
   specific VPN.

   CE devices have IP or MPLS connectivity via a connection to a PE
   device, which just provides ordinary connectivity to the global IP
   address space or to an address space which is unique in a particular
   SPs network.  The IP connectivity may be via a static binding, or via
   some kind of dynamic binding.

   The establishment of the VPNs is done at each CE device, making use
   of the IP or MPLS connectivity to the others.  Therefore, it is
   necessary for a given CE device to know which other CE devices belong
   to the same VPN.  In this context, VPN membership refers to the
   association of VPNs and CE devices.

3.2.  Data Exchange at the Customer Interface

3.2.1.  Layer 3 PE-based VPN

   For layer 3 PE-based VPNs, the exchange is normal IP packets,
   transmitted in the same form which is available for interconnecting
   routers in general.  For example, IP packets may be exchanged over
   Ethernet, SONET, T1, T3, dial-up lines, and any other link layer
   available to the router.  It is important to note that those link
   layers are strictly local to the interface for the purpose of
   carrying IP packets, and are terminated at each end of the customer
   interface.  The IP packets may contain addresses which, while unique
   within the VPN, are not unique on the VPN backbone.  Optionally, the
   data exchange may use MPLS to carry the IP packets.

Top      Up      ToC       Page 26 
3.2.2.  Layer 3 Provider-Provisioned CE-based VPN

   The data exchanged at the customer interface are always normal IP
   packets that are routable on the VPN backbone, and whose addresses
   are unique on the VPN backbone.  Optionally, MPLS frames can be used,
   if the appropriate label-switched paths exist across the VPN
   backbone.  The PE device does not know whether these packets are VPN
   packets or not.  At the current time, MPLS is not commonly offered as
   a customer-visible service, so that CE-based VPNs most commonly make
   use of IP services.

3.3.  Customer Visible Routing

   Once VPN tunnels are set up between pairs of VPN edge devices, it is
   necessary to set up mechanisms which ensure that packets from the
   customer network get sent through the proper tunnels.  This routing
   function must be performed by the VPN edge device.

3.3.1.  Customer View of Routing for Layer 3 PE-based VPNs

   There is a PE-CE routing interaction which enables a PE to obtain
   those addresses, from the customer network, that are reachable via
   the CE.  The PE-CE routing interaction also enables a CE device to
   obtain those addresses, from the customer network, which are
   reachable via the PE; these will generally be addresses that are at
   other sites in the customer network.

   The PE-CE routing interaction can make use of static routing, an IGP
   (such as RIP, OSPF, IS-IS, etc.), or BGP.

   If the PE-CE interaction is done via an IGP, the PE will generally
   maintain at least several independent IGP instances; one for the
   backbone routing, and one for each VPN.  Thus the PE participates in
   the IGP of the customer VPNs, but the CE does not participate in the
   backbone's IGP.

   If the PE-CE interaction is done via BGP, the PE MAY support one
   instance of BGP for each VPN, as well as an additional instance of
   BGP for the public Internet routes.  Alternatively, the PE might
   support a single instance of BGP, using, e.g., different BGP Address
   Families to distinguish the public Internet routes from the VPN
   routes.

   Routing information which a PE learns from a CE in a particular VPN
   must be forwarded to the other PEs that are attached to the same VPN.
   Those other PEs must then forward the information in turn to the
   other CEs of that VPN.

Top      Up      ToC       Page 27 
   The PE-PE routing distribution can be done as part of the same
   routing instance to which the PE-CE interface belongs.
   Alternatively, it can be done via a different routing instance,
   possibly using a different routing algorithm.  In this case, the PE
   must redistribute VPN routes from one routing instance to another.

   Note that VPN routing information is never distributed to the P
   routers.  VPN routing information is known at the edge of the VPN
   backbone, but not in the core.

   If the VPN's IGP is different than the routing algorithm running on
   the CE-PE link, then the CE must support two routing instances, and
   must redistribute the VPN's routes from one instance to the other
   (e.g., [VPN-BGP-OSPF]).

   In the case of layer 3 PE-based VPNs a single PE device is likely to
   provide service for several different VPNs.  Since different VPNs may
   have address spaces which are not mutually unique, a PE device must
   have several forwarding tables, in general one for each VPN to which
   it is attached.  These will be referred to as VPN Forwarding
   Instances (VFIs).  Each VFI is a logical entity internal to the PE
   device.  VFIs are defined in section 2.1.1, and discussed in more
   detail in section 4.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.

3.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 PE device is considered to be in a site or not.  This issue
   is discussed below.

Top      Up      ToC       Page 28 
   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.  One could
   have, all routers within the customer network (including the PEs, or
   more precisely, including a VFI within each PE) appear within a
   single area.  Tunnels between the PEs could also appear as normal
   links.

   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
   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 or IS-IS 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.

3.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

Top      Up      ToC       Page 29 
   static routing or BGP may be used across the customer 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.  Note that
   private IP addresses or non-unique IP address (e.g., unregistered
   addresses) should not be used for extranet communication.

3.3.1.3.  CE and PE Devices for Layer 3 PE-based VPNs

   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 PE-based VPNs both CE and PE devices participate as normal
   routers within the area.

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

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

   For example, from the perspective of routing within the customer
   network, the CE devices may be the area border or AS boundary routers
   of the IGP area.  In this case, static routing, BGP, or whatever
   routing is used in the backbone, may be used across the customer
   interface.

3.3.2.  Customer View of Routing for Layer 3 Provider-Provisioned
        CE-based VPNs

   For layer 3 provider-provisioned CE-based VPNs, the PE devices are
   not aware of the set of addresses which are reachable at particular
   customer sites.  The CE and PE devices do not exchange the customer's
   routing information.

   Customer sites that belong to the same VPN may exchange routing
   information through the CE-CE VPN tunnels that appear, to the
   customers IGP, as router adjacencies.  Alternatively, instead of

Top      Up      ToC       Page 30 
   exchanging routing information through the VPN tunnels, the SP's
   management system may take care of the configuration of the static
   route information of one site towards the other sites in the VPN.

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

   As the CE device receives an IP or MPLS service from the SP, the CE
   and PE devices may exchange 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.

   However, in many scenarios, the use of static/default routes at the
   CE-PE interface might be all the global routing that is required.

3.3.3.  Options for Customer Visible Routing

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

   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.

Top      Up      ToC       Page 31 
   o OSPF (Open Shortest Path First) [RFC2328]

     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.

   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.

Top      Up      ToC       Page 32 
   o BGP-4 (Border Gateway Protocol version 4) [RFC1771]

     BGP-4 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
     [RFC3065].  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.

     BGP-4 has been extended to support IPv6, IPX, and others as well as
     IPv4 [RFC2858].  Multiprotocol BGP-4 carries routes from multiple
     "address families".

4.  Network Interface and SP Support of VPNs

4.1.  Functional Components of a VPN

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

   o A mechanism to acquire VPN membership/capability information

   o A mechanism to tunnel traffic between VPN sites

   o For layer 3 PE-based VPNs, a means to learn customer routes,
     distribute them between the PEs, and to advertise reachable
     destinations to customer sites.

Top      Up      ToC       Page 33 
   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.

   Logically, the establishment of a VPN can be thought of as composed
   of the following three stages.  In the first stage, the VPN edge
   devices learn of each other.  In the second stage, they establish
   tunnels to each other.  In the third stage, they exchange routing
   information with each other.  However, not all VPN solutions need be
   decomposed into these three stages.  For example, in some VPN
   solutions, tunnels are not established after learning membership
   information; rather, pre-existing tunnels are selected and used.
   Also, in some VPN solutions, the membership information and the
   routing information are combined.

   In the membership/capability discovery stage, membership and
   capability information needs to be acquired to determine whether two
   particular VPN edge devices support any VPNs in common.  This can be
   accomplished, for instance, by exchanging VPN identifiers of the
   configured VPNs at each VPN edge device.  The capabilities of the VPN
   edge devices need to be determined, in order to be able to agree on a
   common mechanism 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 SPs may implement a single VPN solution.
   Likewise, the routing information for VPNs can be distributed using
   the methods discussed in section 4.4.

   In the tunnel establishment stage, mechanisms may 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.  However, if IP tunneling, e.g., is used, there may not
   be any need to explicitly set up tunnels; if MPLS tunnels are used,
   they may be pre-established as part of normal MPLS functioning.

   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 from a
   central management system, using protocols such as, e.g., LDAP.
   Alternatively, it can be distributed manually.  However, as manual
   configuration does not scale and is error prone, its use is
   discouraged.  As a third alternative, VPN information can be

Top      Up      ToC       Page 34 
   distributed via protocols that ensure automatic and consistent
   distribution of information in a timely manner, much as routing
   protocols do for routing information.  This may suggest that the
   information be carried in routing protocols themselves, though only
   if this can be done without negatively impacting the essential
   routing functions.

   It can be seen that quite a lot of information needs to be exchanged
   in order to establish and maintain a VPN.  The scaling and stability
   consequences need to be analyzed for any VPN approach.

   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 3 provider-provisioned CE-based VPNs, the VPN service is
   offering tunnels between CE devices.  IP routing for the VPN is done
   by the customer network.  With these solutions, the SP is involved in
   the operation of the membership/capability discovery stage and the
   tunnel establishment stage.  The IP routing functional component may
   be entirely up to the customer network, or alternatively, the SP's
   management system may be responsible for the distribution of the
   reachability information of the VPN sites to the other sites of the
   same VPN.

4.2.  VPN Establishment and Maintenance

   For a layer 3 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 layer 3 PPVPNs, however
   there are some generic problems that any VPN solution must address,
   including:

   o For PE-based VPNs, when a new site is added to a PE, how do the
     other PEs find out about it?  When a PE first gets attached to a
     given VPN, how does it determine which other PEs are attached to
     the same VPN.  For CE-based VPNs, when a new site is added, how
     does its CE find out about all the other CEs at other sites of the
     same VPN?

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

Top      Up      ToC       Page 35 
   o An administrator may wish to provision different topologies for
     different VPNs (e.g., a full mesh or a hub & spoke topology).  How
     is this achieved?

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

4.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 uses the network management system to configure and provision
   the VPN edge devices.  This approach can also be used to distribute
   VPN discovery information, either using proprietary protocols or
   using standard management protocols and MIBs.  Another approach is
   where the VPN edge devices act as clients of a centralized directory
   or database server that contains VPN discovery information.  Another
   possibility is where VPN discovery information is piggybacked onto a
   routing protocol running between the VPN edge devices [VPN-DISC].

4.2.1.1.  Network Management for Membership Information

   SPs use network management extensively to configure and monitor the
   various devices that are spread throughout their networks.  This
   approach could be also used for distributing VPN related information.
   A network management system (either centralized or distributed) could
   be used by the SP to configure and provision VPNs on the VPN edge
   devices at various locations.  VPN configuration information could be
   entered into a network management application and distributed to the
   remote sites via the same means used to distribute other network
   management information.  This approach is most natural when all the
   devices that must be provisioned are within a single SP's network,

Top      Up      ToC       Page 36 
   since the SP has access to all VPN edge devices in its domain.
   Security and access control are important, and could be achieved for
   example using SNMPv3, SSH, or IPsec tunnels.

4.2.1.2.  Directory Servers

   An SP typically needs to maintain a database of VPN
   configuration/membership information, regardless of the mechanisms
   used to distribute it.  LDAPv3 [RFC3377] is a standard directory
   protocol which makes it possible to use a common mechanism for both
   storing such information and distributing it.

   To facilitate interoperability between different implementations, as
   well as between the management systems of different SPs, a standard
   schema for representing VPN membership and configuration information
   would have to be developed.

   LDAPv3 supports authentication of messages and associated access
   control, which can be used to limit access to VPN information to
   authorized entities.

4.2.1.3.  Augmented Routing for Membership Information

   Extensions to the use of existing BGP mechanisms, for distribution of
   VPN membership information, are proposed in [VPN-2547BIS].  In that
   scheme, BGP is used to distribute VPN routes, and each route carries
   a set of attributes which indicate the VPN (or VPNs) to which the
   route belongs.  This allows the VPN discovery information and routing
   information to be combined in a single protocol.  Information needed
   to establish per-VPN tunnels can also be carried as attributes of the
   routes.  This makes use of the BGP protocol's ability to effectively
   carry large amounts of routing information.

   It is also possible to use BGP to distribute just the
   membership/capability information, while using a different technique
   to distribute the routing.  BGP's update message would be used to
   indicate that a PE is attached to a particular VPN; BGP's withdraw
   message would be used to indicate that a PE has ceased to be attached
   to a particular VPN.  This makes use of the BGP protocol's ability to
   dynamically distribute real-time changes in a reliable and fairly
   rapid manner.  In addition, if a BGP route reflector is used, PEs
   never have to be provisioned with each other's IP addresses at all.
   Both cases make use of BGP's mechanisms, such as route filters, for
   constraining the distribution of information.

   Augmented routing may be done in combination with aggregated routing,
   as discussed in section 4.4.4.  Of course, when using BGP for
   distributing any kind of VPN-specific information, one must ensure

Top      Up      ToC       Page 37 
   that one is not disrupting the classical use of BGP for distributing
   public Internet routing information.  For further discussion of this,
   see the discussion of aggregated routing, section 4.4.4.

4.2.1.4.  VPN Discovery for Inter-SP VPNs

   When two sites of a VPN are connected to different SP networks, the
   SPs must support a common mechanism for exchanging
   membership/capability information.  This might make use of manual
   configuration or automated exchange of information between the SPs.
   Automated exchange may be facilitated if one or more mechanisms for
   VPN discovery are standardized and supported across the multiple SPs.
   Inter-SP trust relationships will need to be established, for example
   to determine which information and how much information about the
   VPNs may be exchanged between SPs.

   In some cases different service providers may deploy different
   approaches for VPN discovery.  Where this occurs, this implies that
   for multi-SP VPNs, some manual coordination and configuration may be
   necessary.

   The amount of information which needs to be shared between SPs may
   vary greatly depending upon the number of size of the multi-SP VPNs.
   The SPs will therefore need to determine and agree upon the expected
   amount of membership information to be exchanged, and the dynamic
   nature of this information.  Mechanisms may also be needed to
   authenticate the VPN membership information.

   VPN information should be distributed only to places where it needs
   to go, whether that is intra-provider or inter-provider.  In this
   way, the distribution of VPN information is unlike the distribution
   of inter-provider routing information, as the latter needs to be
   distributed throughout the Internet.  In addition, the joint support
   of a VPN by two SPs should not require any third SP to maintain state
   for that VPN.  Again, notice the difference with respect to
   inter-provider routing; in inter-provider routing: sending traffic
   from one SP to another may indeed require routing state in a third
   SP.

   As one possible example: Suppose that there are two SPs A and C,
   which want to support a common VPN.  Suppose that A and C are
   interconnected via SP B.  In this case B will need to know how to
   route traffic between A and C, and therefore will need to know
   something about A and C (such as enough routing information to
   forward IP traffic and/or connect MPLS LSPs between PEs or route
   reflectors in A and C).  However, for scaling purposes it is
   desirable that B not need to know VPN-specific information about the
   VPNs which are supported by A and C.

Top      Up      ToC       Page 38 
4.2.2.  Constraining Distribution of VPN Routing Information

   In layer 3 provider-provisioned CE-based VPNs, the VPN tunnels
   connect CE devices.  In this case, distribution of IP routing
   information occurs between CE devices on the customer sites.  No
   additional constraints on the distribution of VPN routing information
   are necessary.

   In layer 3 PE-based VPNs, however, the PE devices must be aware of
   VPN routing information (for the VPNs to which they are attached).
   For scalability reasons, one does not want a scheme in which all PEs
   contain all routes for all VPNs.  Rather, only the PEs that are
   attached to sites in a given VPN should contain the routing
   information for that VPN.  This means that the distribution of VPN
   routing information between PE devices must be constrained.

   As VPN membership may change dynamically, it is necessary to have a
   mechanism that allows VPN route information to be distributed to any
   PE where there is an attached user for that VPN, and allows for the
   removal of this information when it is no longer needed.

   In the Virtual Router scheme, per-VPN tunnels must be established
   before any routes for a VPN are distributed, and the routes are then
   distributed through those tunnels.  Thus by establishing the proper
   set of tunnels, one implicitly constrains and controls the
   distribution of per-VPN routing information.  In this scheme, the
   distribution of membership information consists of the set of VPNs
   that exists on each PE, as well as information about the desired
   topology.  This enables a PE to determine the set of remote PEs to
   which it must establish tunnels for a particular VPN.

   In the aggregated routing scheme (see section 4.4.4), the
   distribution of VPN routing information is 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 4.4.4.

4.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 VPN edge devices that have attached sites for that VPN.
   Naturally, whatever the topology, all VPN sites are reachable from
   each other; the topology simply constrains the way traffic is routed

Top      Up      ToC       Page 39 
   among the sites.  For example, in one topology traffic between site A
   and site B goes from one to the other directly over the VPN backbone;
   in another topology, traffic from site A to site B must traverse site
   C before reaching site B.

   The simplest topology is a full mesh, where a tunnel exists between
   every pair of VPN edge devices.  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 VPN edge devices.  Each tunnel consumes some resources
   at a VPN edge device, and depending on the type of tunnel, may or may
   not consume resources in intermediate routers or LSRs.  One reason
   for using a partial mesh topology is to reduce the number of tunnels
   a VPN edge device, 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 VPN edge
   device may be part of a full mesh topology for one VPN, and of a
   partial mesh topology for another VPN.

   An example of where a partial mesh topology could be suitable is for
   a VPN that supports a large number of telecommuters and 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 VPN edge devices and the corporate sites attached to hub VPN
   edge devices.  Traffic between telecommuters is still supported, but
   this traffic traverses a hub VPN edge device.

   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
   VPN edge device to be able to advertise per-VPN topology information
   to other VPN edge devices.  It may be simplest to advertise this at
   the same time as the membership information is advertised, using the
   same mechanisms.

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


Next RFC Part