Tech-invite   World Map
3GPPspecs     Glossaries     IETF     RFCs     Groups     SIP     ABNFs

RFC 2764


A Framework for IP Based Virtual Private Networks

Part 2 of 3, p. 18 to 40
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 18 
4.0  VPN Types:  Virtual Leased Lines

   The simplest form of a VPN is a 'Virtual Leased Line' (VLL) service.
   In this case a point-to-point link is provided to a customer,
   connecting two CPE devices, as illustrated below.  The link layer
   type used to connect the CPE devices to the ISP nodes can be any link
   layer type, for example an ATM VCC or a Frame Relay circuit.  The CPE
   devices can be either routers bridges or hosts.

Top      Up      ToC       Page 19 
   The two ISP nodes are both connected to an IP network, and an IP
   tunnel is set up between them.  Each ISP node is configured to bind
   the stub link and the IP tunnel together at layer 2 (e.g., an ATM VCC
   and the IP tunnel).  Frames are relayed between the two links.  For
   example the ATM Adaptation Layer 5 (AAL5) payload is taken and
   encapsulated in an IPSec tunnel, and vice versa.  The contents of the
   AAL5 payload are opaque to the ISP node, and are not examined there.

               +--------+      -----------       +--------+
   +---+       | ISP    |     ( IP        )      | ISP    |      +---+
   |CPE|-------| edge   |-----( backbone  ) -----| edge   |------|CPE|
   +---+ ATM   | node   |     (           )      | node   |  ATM +---+
         VCC   +--------+      -----------       +--------+  VCC

                      <--------- IP Tunnel -------->                subnet =    
          Addressing used by customer (transparent to provider)

                          Figure 4.1: VLL Example

   To a customer it looks the same as if a single ATM VCC or Frame Relay
   circuit were used to interconnect the CPE devices, and the customer
   could be unaware that part of the circuit was in fact implemented
   over an IP backbone.  This may be useful, for example, if a provider
   wishes to provide a LAN interconnect service using ATM as the network
   interface, but does not have an ATM network that directly
   interconnects all possible customer sites.

   It is not necessary that the two links used to connect the CPE
   devices to the ISP nodes be of the same media type, but in this case
   the ISP nodes cannot treat the traffic in an opaque manner, as
   described above.  Instead the ISP nodes must perform the functions of
   an interworking device between the two media types (e.g., ATM and
   Frame Relay), and perform functions such as LLC/SNAP to NLPID
   conversion, mapping between ARP protocol variants and performing any
   media specific processing that may be expected by the CPE devices
   (e.g., ATM OAM cell handling or Frame Relay XID exchanges).

   The IP tunneling protocol used must support multiprotocol operation
   and may need to support sequencing, if that characteristic is
   important to the customer traffic.  If the tunnels are established
   using a signalling protocol, they may be set up in a data driven
   manner, when a frame is received from a customer link and no tunnel
   exists, or the tunnels may be established at provisioning time and
   kept up permanently.

Top      Up      ToC       Page 20 
   Note that the use of the term 'VLL' in this document is different to
   that used in the definition of the Diffserv Expedited Forwarding Per
   Hop Behaviour (EF-PHB) [30].  In that document a VLL is used to mean
   a low latency, low jitter, assured bandwidth path, which can be
   provided using the described PHB. Thus the focus there is primarily
   on link characteristics that are temporal in nature. In this document
   the term VLL does not imply the use of any specific QoS mechanism,
   Diffserv or otherwise.  Instead the focus is primarily on link
   characteristics that are more topological in nature, (e.g., such as
   constructing a link which includes an IP tunnel as one segment of the
   link). For a truly complete emulation of a link layer both the
   temporal and topological aspects need to be taken into account.

5.0  VPN Types:  Virtual Private Routed Networks

5.1  VPRN Characteristics

   A Virtual Private Routed Network (VPRN) is defined to be the
   emulation of a multi-site wide area routed network using IP
   facilities.  This section looks at how a network-based VPRN service
   can be provided.  CPE-based VPRNs are also possible, but are not
   specifically discussed here.  With network-based VPRNs many of the
   issues that need to be addressed are concerned with configuration and
   operational issues, which must take into account the split in
   administrative responsibility between the service provider and the
   service user.

   The distinguishing characteristic of a VPRN, in comparison to other
   types of VPNs, is that packet forwarding is carried out at the
   network layer.  A VPRN consists of a mesh of IP tunnels between ISP
   routers, together with the routing capabilities needed to forward
   traffic received at each VPRN node to the appropriate destination
   site.  Attached to the ISP routers are CPE routers connected via one
   or more links, termed 'stub' links.  There is a VPRN specific
   forwarding table at each ISP router to which members of the VPRN are
   connected.  Traffic is forwarded between ISP routers, and between ISP
   routers and customer sites, using these forwarding tables, which
   contain network layer reachability information (in contrast to a
   Virtual Private LAN Segment type of VPN (VPLS) where the forwarding
   tables contain MAC layer reachability information - see section 7.0).

   An example VPRN is illustrated in the following diagram, which shows
   3 ISP edge routers connected via a full mesh of IP tunnels, used to
   interconnect 4 CPE routers.  One of the CPE routers is multihomed to
   the ISP network.  In the multihomed case, all stub links may be
   active, or, as shown, there may be one primary and one or more backup
   links to be used in case of failure of the primary.  The term '
   backdoor' link is used to refer to a link between two customer sites

Top      Up      ToC       Page 21 
   that does not traverse the ISP network. +--------+                       +--------+
   +---+       | ISP    |     IP tunnel         | ISP    |       +---+
   |CPE|-------| edge   |<--------------------->| edge   |-------|CPE|
   +---+ stub  | router |       | router |  stub +---+
         link  +--------+                       +--------+  link   :
                |   ^  |                         |   ^             :
                |   |  |     ---------------     |   |             :
                |   |  +----(               )----+   |             :
                |   |       ( IP BACKBONE   )        |             :
                |   |       (               )        |             :
                |   |        ---------------         |             :
                |   |               |                |             :
                |   |IP tunnel  +--------+  IP tunnel|             :
                |   |           | ISP    |           |             :
                |   +---------->| edge   |<----------+             :
                | | router |            :
          backup|               +--------+                 backdoor:
           link |                |      |                    link  :
                |      stub link |      |  stub link               :
                |                |      |                          :
                |             +---+    +---+                       :
                +-------------|CPE|    |CPE|.......................:
         +---+    +---+

                         Figure 5.1: VPRN Example

   The principal benefit of a VPRN is that the complexity and the
   configuration of the CPE routers is minimized.  To a CPE router, the
   ISP edge router appears as a neighbor router in the customer's
   network, to which it sends all traffic, using a default route.  The
   tunnel mesh that is set up to transfer traffic extends between the
   ISP edge routers, not the CPE routers.  In effect the burden of
   tunnel establishment and maintenance and routing configuration is
   outsourced to the ISP.  In addition other services needed for the
   operation of a VPN such as the provision of a firewall and QoS
   processing can be handled by a small number of ISP edge routers,
   rather than a large number of potentially heterogeneous CPE devices.
   The introduction and management of new services can also be more
   easily handled, as this can be achieved without the need to upgrade
   any CPE equipment.  This latter benefit is particularly important
   when there may be large numbers of residential subscribers using VPN
   services to access private corporate networks.  In this respect the
   model is somewhat akin to that used for telephony services, whereby
   new services (e.g., call waiting) can be introduced with no change in
   subscriber equipment.

Top      Up      ToC       Page 22 
   The VPRN type of VPN is in contrast to one where the tunnel mesh
   extends to the CPE routers, and where the ISP network provides layer
   2 connectivity alone.  The latter case can be implemented either as a
   set of VLLs between CPE routers (see section 4.0), in which case the
   ISP network provides a set of layer 2 point-to-point links, or as a
   VPLS (see section 7.0), in which case the ISP network is used to
   emulate a multiaccess LAN segment.  With these scenarios a customer
   may have more flexibility (e.g., any IGP or any protocol can be run
   across all customer sites) but this usually comes at the expense of a
   more complex configuration for the customer.  Thus, depending on
   customer requirements, a VPRN or a VPLS may be the more appropriate

   Because a VPRN carries out forwarding at the network layer, a single
   VPRN only directly supports a single network layer protocol.  For
   multiprotocol support, a separate VPRN for each network layer
   protocol could be used, or one protocol could be tunneled over
   another (e.g., non-IP protocols tunneled over an IP VPRN) or
   alternatively the ISP network could be used to provide layer 2
   connectivity only, such as with a VPLS as mentioned above.

   The issues to be addressed for VPRNs include initial configuration,
   determination by an ISP edge router of the set of links that are in
   each VPRN, the set of other routers that have members in the VPRN,
   and the set of IP address prefixes reachable via each stub link,
   determination by a CPE router of the set of IP address prefixes to be
   forwarded to an ISP edge router, the mechanism used to disseminate
   stub reachability information to the correct set of ISP routers, and
   the establishment and use of the tunnels used to carry the data
   traffic.  Note also that, although discussed first for VPRNs, many of
   these issues also apply to the VPLS scenario described later, with
   the network layer addresses being replaced by link layer addresses.

   Note that VPRN operation is decoupled from the mechanisms used by the
   customer sites to access the Internet.  A typical scenario would be
   for the ISP edge router to be used to provide both VPRN and Internet
   connectivity to a customer site.  In this case the CPE router just
   has a default route pointing to the ISP edge router, with the latter
   being responsible for steering private traffic to the VPRN and other
   traffic to the Internet, and providing firewall functionality between
   the two domains.  Alternatively a customer site could have Internet
   connectivity via an ISP router not involved in the VPRN, or even via
   a different ISP.  In this case the CPE device is responsible for
   splitting the traffic into the two domains and providing firewall

Top      Up      ToC       Page 23 
5.1.1  Topology

   The topology of a VPRN may consist of a full mesh of tunnels between
   each VPRN node, or may be an arbitrary topology, such as a set of
   remote offices connected to the nearest regional site, with these
   regional sites connected together via a full or partial mesh.  With
   VPRNs using IP tunnels there is much less cost assumed with full
   meshing than in cases where physical resources (e.g., a leased line)
   must be allocated for each connected pair of sites, or where the
   tunneling method requires resources to be allocated in the devices
   used to interconnect the edge routers (e.g., Frame Relay DLCIs).  A
   full mesh topology yields optimal routing, since it precludes the
   need for traffic between two sites to traverse a third.  Another
   attraction of a full mesh is that there is no need to configure
   topology information for the VPRN.  Instead, given the member routers
   of a VPRN, the topology is implicit.  If the number of ISP edge
   routers in a VPRN is very large, however, a full mesh topology may
   not be appropriate, due to the scaling issues involved, for example,
   the growth in the number of tunnels needed between sites, (which for
   n sites is n(n-1)/2), or the number of routing peers per router.
   Network policy may also lead to non full mesh topologies, for example
   an administrator may wish to set up the topology so that traffic
   between two remote sites passes through a central site, rather than
   go directly between the remote sites.  It is also necessary to deal
   with the scenario where there is only partial connectivity across the
   IP backbone under certain error conditions (e.g. A can reach B, and B
   can reach C, but A cannot reach C directly), which can occur if
   policy routing is being used.

   For a network-based VPRN, it is assumed that each customer site CPE
   router connects to an ISP edge router through one or more point-to-
   point stub links (e.g. leased lines, ATM or Frame Relay connections).
   The ISP routers are responsible for learning and disseminating
   reachability information amongst themselves.  The CPE routers must
   learn the set of destinations reachable via each stub link, though
   this may be as simple as a default route.

   The stub links may either be dedicated links, set up via
   provisioning, or may be dynamic links set up on demand, for example
   using PPP, voluntary tunneling (see section 6.3), or ATM signalling.
   With dynamic links it is necessary to authenticate the subscriber,
   and determine the authorized resources that the subscriber can access
   (e.g. which VPRNs the subscriber may join).  Other than the way the
   subscriber is initially bound to the VPRN, (and this process may
   involve extra considerations such as dynamic IP address assignment),
   the subsequent VPRN mechanisms and services can be used for both
   types of subscribers in the same way.

Top      Up      ToC       Page 24 
5.1.2  Addressing

   The addressing used within a VPRN may have no relation to the
   addressing used on the IP backbone over which the VPRN is
   instantiated.  In particular non-unique private IP addressing may be
   used [4].  Multiple VPRNs may be instantiated over the same set of
   physical devices, and they may use the same or overlapping address

5.1.3  Forwarding

   For a VPRN the tunnel mesh forms an overlay network operating over an
   IP backbone.  Within each of the ISP edge routers there must be VPN
   specific forwarding state to forward packets received from stub links
   ('ingress traffic') to the appropriate next hop router, and to
   forward packets received from the core ('egress traffic') to the
   appropriate stub link.  For cases where an ISP edge router supports
   multiple stub links belonging to the same VPRN, the tunnels can, as a
   local matter, either terminate on the edge router, or on a stub link.
   In the former case a VPN specific forwarding table is needed for
   egress traffic, in the latter case it is not.  A VPN specific
   forwarding table is generally needed in the ingress direction, in
   order to direct traffic received on a stub link onto the correct IP
   tunnel towards the core.

   Also since a VPRN operates at the internetwork layer, the IP packets
   sent over a tunnel will have their Time to Live (TTL) field
   decremented in the normal manner, preventing packets circulating
   indefinitely in the event of a routing loop within the VPRN.

5.1.4  Multiple concurrent VPRN connectivity

   Note also that a single customer site may belong concurrently to
   multiple VPRNs and may want to transmit traffic both onto one or more
   VPRNs and to the default Internet, over the same stub link.  There
   are a number of possible approaches to this problem, but these are
   outside the scope of this document.

5.2  VPRN Related Work

   VPRN requirements and mechanisms have been discussed previously in a
   number of different documents.  One of the first was [10], which
   showed how the same VPN functionality can be implemented over both
   MPLS and non-MPLS networks.  Some others are briefly discussed below.

   There are two main variants as regards the mechanisms used to provide
   VPRN membership and reachability functionality, - overlay and
   piggybacking.  These are discussed in greater detail in sections

Top      Up      ToC       Page 25 
   5.3.2, 5.3.3 and 5.3.4 below.  An example of the overlay model is
   described in [14], which discusses the provision of VPRN
   functionality by means of a separate per-VPN routing protocol
   instance and route and forwarding table instantiation, otherwise
   known as virtual routing.  Each VPN routing instance is isolated from
   any other VPN routing instance, and from the routing used across the
   backbone.  As a result any routing protocol (e.g. OSPF, RIP2, IS-IS)
   can be run with any VPRN, independently of the routing protocols used
   in other VPRNs, or in the backbone itself.  The VPN model described
   in [12] is also an overlay VPRN model using virtual routing.  That
   document is specifically geared towards the provision of VPRN
   functionality over MPLS backbones, and it describes how VPRN
   membership dissemination can be automated over an MPLS backbone, by
   performing VPN neighbor discovery over the base MPLS tunnel mesh.
   [31] extends the virtual routing model to include VPN areas, and VPN
   border routers which route between VPN areas.  VPN areas may be
   defined for administrative or technical reasons, such as different
   underlying network infrastructures (e.g. ATM, MPLS, IP).

   In contrast [15] describes the provision of VPN functionality using a
   piggybacking approach for membership and reachability dissemination,
   with this information being piggybacked in Border Gateway Protocol 4
   (BGP) [32] packets.  VPNs are constructed using BGP policies, which
   are used to control which sites can communicate with each other. [13]
   also uses BGP for piggybacking membership information, and piggybacks
   reachability information on the protocol used to establish MPLS LSPs
   (CR-LDP or extended RSVP).  Unlike the other proposals, however, this
   proposal requires the participation on the CPE router to implement
   the VPN functionality.

5.3  VPRN Generic Requirements

   There are a number of common requirements which any network-based
   VPRN solution must address, and there are a number of different
   mechanisms that can be used to meet these requirements.  These
   generic issues are

   1) The use of a globally unique VPN identifier in order to be able to
      refer to a particular VPN.

   2) VPRN membership determination.  An edge router must learn of the
      local stub links that are in each VPRN, and must learn of the set
      of other routers that have members in that VPRN.

   3) Stub link reachability information.  An edge router must learn the
      set of addresses and address prefixes reachable via each stub

Top      Up      ToC       Page 26 
   4) Intra-VPRN reachability information.  Once an edge router has
      determined the set of address prefixes associated with each of its
      stub links, then this information must be disseminated to each
      other edge router in the VPRN.

   5) Tunneling mechanism.  An edge router must construct the necessary
      tunnels to other routers that have members in the VPRN, and must
      perform the encapsulation and decapsulation necessary to send and
      receive packets over the tunnels.

5.3.1  VPN Identifier

   The IETF [16] and the ATM Forum [17] have standardized on a single
   format for a globally unique identifier used to identify a VPN - a
   VPN-ID.  Only the format of the VPN-ID has been defined, not its
   semantics or usage.  The aim is to allow its use for a wide variety
   of purposes, and to allow the same identifier to used with different
   technologies and mechanisms.  For example a VPN-ID can be included in
   a MIB to identify a VPN for management purposes.  A VPN-ID can be
   used in a control plane protocol, for example to bind a tunnel to a
   VPN at tunnel establishment time.  All packets that traverse the
   tunnel are then implicitly associated with the identified VPN.  A
   VPN-ID can be used in a data plane encapsulation, to allow for an
   explicit per-packet identification of the VPN associated with the
   packet.  If a VPN is implemented using different technologies (e.g.,
   IP and ATM) in a network, the same identifier can be used to identify
   the VPN across the different technologies.  Also if a VPN spans
   multiple administrative domains the same identifier can be used

   Most of the VPN schemes developed (e.g. [11], [12], [13], [14])
   require the use of a VPN-ID that is carried in control and/or data
   packets, which is used to associate the packet with a particular VPN.
   Although the use of a VPN-ID in this manner is very common, it is not
   universal. [15] describes a scheme where there is no protocol field
   used to identify a VPN in this manner.  In this scheme the VPNs as
   understood by a user, are administrative constructs, built using BGP
   policies.  There are a number of attributes associated with VPN
   routes, such as a route distinguisher, and origin and target "VPN",
   that are used by the underlying protocol mechanisms for
   disambiguation and scoping, and these are also used by the BGP policy
   mechanism in the construction of VPNs, but there is nothing
   corresponding with the VPN-ID as used in the other documents.

   Note also that [33] defines a multiprotocol encapsulation for use
   over ATM AAL5 that uses the standard VPN-ID format.

Top      Up      ToC       Page 27 
5.3.2  VPN Membership Information Configuration and Dissemination

   In order to establish a VPRN, or to insert new customer sites into an
   established VPRN, an ISP edge router must determine which stub links
   are associated with which VPRN.  For static links (e.g. an ATM VCC)
   this information must be configured into the edge router, since the
   edge router cannot infer such bindings by itself.  An SNMP MIB
   allowing for bindings between local stub links and VPN identities is
   one solution.

   For subscribers that attach to the network dynamically (e.g. using
   PPP or voluntary tunneling) it is possible to make the association
   between stub link and VPRN as part of the end user authentication
   processing that must occur with such dynamic links.  For example the
   VPRN to which a user is to be bound may be derived from the domain
   name the used as part of PPP authentication.  If the user is
   successfully authenticated (e.g. using a Radius server), then the
   newly created dynamic link can be bound to the correct VPRN.  Note
   that static configuration information is still needed, for example to
   maintain the list of authorized subscribers for each VPRN, but the
   location of this static information could be an external
   authentication server rather than on an ISP edge router.  Whether the
   link was statically or dynamically created, a VPN-ID can be
   associated with that link to signify to which VPRN it is bound.

   After learning which stub links are bound to which VPRN, each edge
   router must learn either the identity of, or, at least, the route to,
   each other edge router supporting other stub links in that particular
   VPRN.  Implicit in the latter is the notion that there exists some
   mechanism by which the configured edge routers can then use this edge
   router and/or stub link identity information to subsequently set up
   the appropriate tunnels between them.  The problem of VPRN member
   dissemination between participating edge routers, can be solved in a
   variety of ways, discussed below.  Directory Lookup

   The members of a particular VPRN, that is, the identity of the edge
   routers supporting stub links in the VPRN, and the set of static stub
   links bound to the VPRN per edge router, could be configured into a
   directory, which edge routers could query, using some defined
   mechanism (e.g. Lightweight Directory Access Protocol (LDAP) [34]),
   upon startup.

   Using a directory allows either a full mesh topology or an arbitrary
   topology to be configured.  For a full mesh, the full list of member
   routers in a VPRN is distributed everywhere.  For an arbitrary
   topology, different routers may receive different member lists.

Top      Up      ToC       Page 28 
   Using a directory allows for authorization checking prior to
   disseminating VPRN membership information, which may be desirable
   where VPRNs span multiple administrative domains.  In such a case,
   directory to directory protocol mechanisms could also be used to
   propagate authorized VPRN membership information between the
   directory systems of the multiple administrative domains.

   There also needs to be some form of database synchronization
   mechanism (e.g. triggered or regular polling of the directory by edge
   routers, or active pushing of update information to the edge routers
   by the directory) in order for all edge routers to learn the identity
   of newly configured sites inserted into an active VPRN, and also to
   learn of sites removed from a VPRN.  Explicit Management Configuration

   A VPRN MIB could be defined which would allow a central management
   system to configure each edge router with the identities of each
   other participating edge router and the identity of each of the
   static stub links bound to the VPRN.  Like the use of a directory,
   this mechanism allows both full mesh and arbitrary topologies to be
   configured.  Another mechanism using a centralized management system
   is to use a policy server and use the Common Open Policy Service
   (COPS) protocol [35] to distribute VPRN membership and policy
   information, such as the tunnel attributes to use when establishing a
   tunnel, as described in [36].

   Note that this mechanism allows the management station to impose
   strict authorization control; on the other hand, it may be more
   difficult to configure edge routers outside the scope of the
   management system.  The management configuration model can also be
   considered a subset of the directory method, in that the management
   directories could use MIBs to push VPRN membership information to the
   participating edge routers, either subsequent to, or as part of, the
   local stub link configuration process.  Piggybacking in Routing Protocols

   VPRN membership information could be piggybacked into the routing
   protocols run by each edge router across the IP backbone, since this
   is an efficient means of automatically propagating information
   throughout the network to other participating edge routers.
   Specifically, each route advertisement by each edge router could
   include, at a minimum, the set of VPN identifiers associated with
   each edge router, and adequate information to allow other edge
   routers to determine the identity of, and/or, the route to, the
   particular edge router.  Other edge routers would examine received
   route advertisements to determine if any contained information was

Top      Up      ToC       Page 29 
   relevant to a supported (i.e., configured) VPRN; this determination
   could be done by looking for a VPN identifier matching a locally
   configured VPN.  The nature of the piggybacked information, and
   related issues, such as scoping, and the means by which the nodes
   advertising particular VPN memberships will be identified, will
   generally be a function both of the routing protocol and of the
   nature of the underlying transport.

   Using this method all the routers in the network will have the same
   view of the VPRN membership information, and so a full mesh topology
   is easily supported.  Supporting an arbitrary topology is more
   difficult, however, since some form of pruning would seem to be

   The advantage of the piggybacking scheme is that it allows for
   efficient information dissemination, but it does require that all
   nodes in the path, and not just the participating edge routers, be
   able to accept such modified route advertisements.  A disadvantage is
   that significant administrative complexity may be required to
   configure scoping mechanisms so as to both permit and constrain the
   dissemination of the piggybacked advertisements, and in itself this
   may be quite a configuration burden, particularly if the VPRN spans
   multiple routing domains (e.g. different autonomous systems / ISPs).

   Furthermore, unless some security mechanism is used for routing
   updates so as to permit only all relevant edge routers to read the
   piggybacked advertisements, this scheme generally implies a trust
   model where all routers in the path must perforce be authorized to
   know this information.  Depending upon the nature of the routing
   protocol, piggybacking may also require intermediate routers,
   particularly autonomous system (AS) border routers, to cache such
   advertisements and potentially also re-distribute them between
   multiple routing protocols.

   Each of the schemes described above have merit in particular
   situations.  Note that, in practice, there will almost always be some
   centralized directory or management system which will maintain VPRN
   membership information, such as the set of edge routers that are
   allowed to support a certain VPRN, the bindings of static stub links
   to VPRNs, or authentication and authorization information for users
   that access the network via dynamics links.  This information needs
   to be configured and stored in some form of database, so that the
   additional steps needed to facilitate the configuration of such
   information into edge routers, and/or, facilitate edge router access
   to such information, may not be excessively onerous.

Top      Up      ToC       Page 30 
5.3.3  Stub Link Reachability Information

   There are two aspects to stub site reachability - the means by which
   VPRN edge routers determine the set of VPRN addresses and address
   prefixes reachable at each stub site, and the means by which the CPE
   routers learn the destinations reachable via each stub link.  A
   number of common scenarios are outlined below.  In each case the
   information needed by the ISP edge router is the same - the set of
   VPRN addresses reachable at the customer site, but the information
   needed by the CPE router differs.  Stub Link Connectivity Scenarios  Dual VPRN and Internet Connectivity

   The CPE router is connected via one link to an ISP edge router, which
   provides both VPRN and Internet connectivity.

   This is the simplest case for the CPE router, as it just needs a
   default route pointing to the ISP edge router.  VPRN Connectivity Only

   The CPE router is connected via one link to an ISP edge router, which
   provides VPRN, but not Internet, connectivity.

   The CPE router must know the set of non-local VPRN destinations
   reachable via that link.  This may be a single prefix, or may be a
   number of disjoint prefixes.  The CPE router may be either statically
   configured with this information, or may learn it dynamically by
   running an instance of an Interior Gateway Protocol (IGP).  For
   simplicity it is assumed that the IGP used for this purpose is RIP,
   though it could be any IGP.  The ISP edge router will inject into
   this instance of RIP the VRPN routes which it learns by means of one
   of the intra-VPRN reachability mechanisms described in section 5.3.4.
   Note that the instance of RIP run to the CPE, and any instance of a
   routing protocol used to learn intra-VPRN reachability (even if also
   RIP) are separate, with the ISP edge router redistributing the routes
   from one instance to another.

Top      Up      ToC       Page 31  Multihomed Connectivity

   The CPE router is multihomed to the ISP network, which provides VPRN

   In this case all the ISP edge routers could advertise the same VPRN
   routes to the CPE router, which then sees all VPRN prefixes equally
   reachable via all links.  More specific route redistribution is also
   possible, whereby each ISP edge router advertises a different set of
   prefixes to the CPE router.  Backdoor Links

   The CPE router is connected to the ISP network, which provides VPRN
   connectivity, but also has a backdoor link to another customer site

   In this case the ISP edge router will advertise VPRN routes as in
   case 2 to the CPE device.  However now the same destination is
   reachable via both the ISP edge router and via the backdoor link.  If
   the CPE routers connected to the backdoor link are running the
   customer's IGP, then the backdoor link may always be the favored link
   as it will appear an an 'internal' path, whereas the destination as
   injected via the ISP edge router will appear as an 'external' path
   (to the customer's IGP).  To avoid this problem, assuming that the
   customer wants the traffic to traverse the ISP network, then a
   separate instance of  RIP should be run between the CPE routers at
   both ends of the backdoor link, in the same manner as an instance of
   RIP is run on a stub or backup link between a CPE router and an ISP
   edge router.  This will then also make the backdoor link appear as an
   external path, and by adjusting the link costs appropriately, the ISP
   path can always be favored, unless it goes down, when the backdoor
   link is then used.

   The description of the above scenarios covers what reachability
   information is needed by the ISP edge routers and the CPE routers,
   and discusses some of the mechanisms used to convey this information.
   The sections below look at these mechanisms in more detail.  Routing Protocol Instance

   A routing protocol can be run between the CPE edge router and the ISP
   edge router to exchange reachability information.  This allows an ISP
   edge router to learn the VPRN prefixes reachable at a customer site,
   and also allows a CPE router to learn the destinations reachable via
   the provider network.

Top      Up      ToC       Page 32 
   The extent of the routing domain for this protocol instance is
   generally just the ISP edge router and the CPE router although if the
   customer site is also running the same protocol as its IGP, then the
   domain may extend into customer site.  If the customer site is
   running a different routing protocol then the CPE router
   redistributes the routes between the instance running to the ISP edge
   router, and the instance running into the customer site.

   Given the typically restricted scope of this routing instance, a
   simple protocol will generally suffice.  RIP is likely to be the most
   common protocol used, though any routing protocol, such as OSPF, or
   BGP run in internal mode (IBGP), could also be used.

   Note that the instance of the stub link routing protocol is different
   from any instance of a routing protocol used for intra-VPRN
   reachability.  For example, if the ISP edge router uses routing
   protocol piggybacking to disseminate VPRN membership and reachability
   information across the core, then it may redistribute suitably
   labeled routes from the CPE routing instance to the core routing
   instance.  The routing protocols used for each instance are
   decoupled, and any suitable protocol can be used in each case.  There
   is no requirement that the same protocol, or even the same stub link
   reachability information gathering mechanism, be run between each CPE
   router and associated ISP edge router in a particular VPRN, since
   this is a purely local matter.

   This decoupling allows ISPs to deploy a common (across all VPRNs)
   intra-VPRN reachability mechanism, and a common stub link
   reachability mechanism, with these mechanisms isolated both from each
   other, and from the particular IGP used in a customer network.  In
   the first case, due to the IGP-IGP boundary implemented on the ISP
   edge router, the ISP can insulate the intra-VPRN reachability
   mechanism from misbehaving stub link protocol instances.  In the
   second case the ISP is not required to be aware of the particular IGP
   running in a customer site.  Other scenarios are possible, where the
   ISP edge routers are running a routing protocol in the same instance
   as the customer's IGP, but are unlikely to be practical, since it
   defeats the purpose of a VPRN simplifying CPE router configuration.
   In cases where a customer wishes to run an IGP across multiple sites,
   a VPLS solution is more suitable.

   Note that if a particular customer site concurrently belongs to
   multiple VPRNs (or wishes to concurrently communicate with both a
   VPRN and the Internet), then the ISP edge router must have some means
   of unambiguously mapping stub link address prefixes to particular
   VPRNs.  A simple way is to have multiple stub links, one per VPRN.
   It is also possible to run multiple VPRNs over one stub link.  This
   could be done either by ensuring (and appropriately configuring the

Top      Up      ToC       Page 33 
   ISP edge router to know) that particular disjoint address prefixes
   are mapped into separate VPRNs, or by tagging the routing
   advertisements from the CPE router with the appropriate VPN
   identifier.  For example if MPLS was being used to convey stub link
   reachability information, different MPLS labels would be used to
   differentiate the disjoint prefixes assigned to particular VPRNs.  In
   any case, some administrative procedure would be required for this
   coordination.  Configuration

   The reachability information across each stub link could be manually
   configured, which may be appropriate if the set of addresses or
   prefixes is small and static.  ISP Administered Addresses

   The set of addresses used by each stub site could be administered and
   allocated via the VPRN edge router, which may be appropriate for
   small customer sites, typically containing either a single host, or a
   single subnet.  Address allocation can be carried out using protocols
   such as PPP or DHCP [37], with, for example, the edge router acting
   as a Radius client and retrieving the customer's IP address to use
   from a Radius server, or acting as a DHCP relay and examining the
   DHCP reply message as it is relayed to the customer site.  In this
   manner the edge router can build up a table of stub link reachability
   information.  Although these address assignment mechanisms are
   typically used to assign an address to a single host, some vendors
   have added extensions whereby an address prefix can be assigned,
   with, in some cases, the CPE device acting as a "mini-DHCP" server
   and assigning addresses for the hosts in the customer site.

   Note that with these schemes it is the responsibility of the address
   allocation server to ensure that each site in the VPN received a
   disjoint address space.  Note also that an ISP would typically only
   use this mechanism for small stub sites, which are unlikely to have
   backdoor links.  MPLS Label Distribution Protocol

   In cases where the CPE router runs MPLS, LDP can be used to convey
   the set of prefixes at a stub site to a VPRN edge router.  Using the
   downstream unsolicited mode of label distribution the CPE router can
   distribute a label for each route in the stub site.  Note however
   that the processing carried out by the edge router in this case is
   more than just the normal LDP processing, since it is learning new
   routes via LDP, rather than the usual case of learning labels for
   existing routes that it has learned via standard routing mechanisms.

Top      Up      ToC       Page 34 
5.3.4  Intra-VPN Reachability Information

   Once an edge router has determined the set of prefixes associated
   with each of its stub links, then this information must be
   disseminated to each other edge router in the VPRN.  Note also that
   there is an implicit requirement that the set of reachable addresses
   within the VPRN be locally unique that is, each VPRN stub link (not
   performing load sharing) maintain an address space disjoint from any
   other, so as to permit unambiguous routing.  In practical terms, it
   is also generally desirable, though not required, that this address
   space be well partitioned i.e., specific, disjoint address prefixes
   per edge router, so as to preclude the need to maintain and
   disseminate large numbers of host routes.

   The problem of intra-VPN reachability information dissemination can
   be solved in a number of ways, some of which include the following:  Directory Lookup

   Along with VPRN membership information, a central directory could
   maintain a listing of the address prefixes associated with each
   customer site.  Such information could be obtained by the server
   through protocol interactions with each edge router.  Note that the
   same directory synchronization issues discussed above in section
   5.3.2 also apply in this case.  Explicit Configuration

   The address spaces associated with each edge router could be
   explicitly configured into each other router.  This is clearly a
   non-scalable solution, particularly when arbitrary topologies are
   used, and also raises the question of how the management system
   learns such information in the first place.  Local Intra-VPRN Routing Instantiations

   In this approach, each edge router runs an instance of a routing
   protocol (a 'virtual router') per VPRN, running across the VPRN
   tunnels to each peer edge router, to disseminate intra-VPRN
   reachability information.  Both full-mesh and arbitrary VPRN
   topologies can be easily supported, since the routing protocol itself
   can run over any topology.  The intra-VPRN routing advertisements
   could be distinguished from normal tunnel data packets either by
   being addressed directly to the peer edge router, or by a tunnel
   specific mechanism.

Top      Up      ToC       Page 35 
   Note that this intra-VPRN routing protocol need have no relationship
   either with the IGP of any customer site or with the routing
   protocols operated by the ISPs in the IP backbone.  Depending on the
   size and scale of the VPRNs to be supported either a simple protocol
   like RIP or a more sophisticated protocol like OSPF could be used.
   Because the intra-VPRN routing protocol operates as an overlay over
   the IP backbone it is wholly transparent to any intermediate routers,
   and to any edge routers not within the VPRN.  This also implies that
   such routing information can remain opaque to such routers, which may
   be a necessary security requirements in some cases.  Also note that
   if the routing protocol runs directly over the same tunnels as the
   data traffic, then it will inherit the same level of security as that
   afforded the data traffic, for example strong encryption and

   If the tunnels over which an intra-VPRN routing protocol runs are
   dedicated to a specific VPN (e.g. a different multiplexing field is
   used for each VPN) then no changes are needed to the routing protocol
   itself.  On the other hand if shared tunnels are used, then it is
   necessary to extend the routing protocol to allow a VPN-ID field to
   be included in routing update packets, to allow sets of prefixes to
   be associated with a particular VPN.  Link Reachability Protocol

   By link reachability protocol is meant a protocol that allows two
   nodes, connected via a point-to-point link, to exchange reachability
   information.  Given a full mesh topology, each edge router could run
   a link reachability protocol, for instance some variation of MPLS
   CR-LDP, across the tunnel to each peer edge router in the VPRN,
   carrying the VPN-ID and the reachability information of each VPRN
   running across the tunnel between the two edge routers.  If VPRN
   membership information has already been distributed to an edge
   router, then the neighbor discovery aspects of a traditional routing
   protocol are not needed, as the set of neighbors is already known.
   TCP connections can be used to interconnect the neighbors, to provide
   reliability.  This approach may reduce the processing burden of
   running routing protocol instances per VPRN, and may be of particular
   benefit where a shared tunnel mechanism is used to connect a set of
   edge routers supporting multiple VPRNs.

   Another approach to developing a link reachability protocol would be
   to base it on IBGP.  The problem that needs to be solved by a link
   reachability protocol is very similar to that solved by IBGP -
   conveying address prefixes reliably between edge routers.

Top      Up      ToC       Page 36 
   Using a link reachability protocol it is straightforward to support a
   full mesh topology - each edge router conveys its own local
   reachability information to all other routers, but does not
   redistribute information received from any other router.  However
   once an arbitrary topology needs to be supported, the link
   reachability protocol needs to develop into a full routing protocol,
   due to the need to implement mechanisms to avoid loops, and there
   would seem little benefit in reinventing another routing protocol to
   deal with this.  Some reasons why partially connected meshes may be
   needed even in a tunneled environment are discussed in section 5.1.1.  Piggybacking in IP Backbone Routing Protocols

   As with VPRN membership, the set of address prefixes associated with
   each stub interface could also be piggybacked into the routing
   advertisements from each edge router and propagated through the
   network.  Other edge routers extract this information from received
   route advertisements in the same way as they obtain the VPRN
   membership information (which, in this case, is implicit in the
   identification of the source of each route advertisement).  Note that
   this scheme may require, depending upon the nature of the routing
   protocols involved, that intermediate routers, e.g. border routers,
   cache intra-VPRN routing information in order to propagate it
   further.  This also has implications for the trust model, and for the
   level of security possible for intra-VPRN routing information.

   Note that in any of the cases discussed above, an edge router has the
   option of disseminating its stub link prefixes in a manner so as to
   permit tunneling from remote edge routers directly to the egress stub
   links.  Alternatively, it could disseminate the information so as to
   associate all such prefixes with the edge router, rather than with
   specific stub links.  In this case, the edge router would need to
   implement a VPN specific forwarding mechanism for egress traffic, to
   determine the correct egress stub link.  The advantage of this is
   that it may significantly reduce the number of distinct tunnels or
   tunnel label information which need to be constructed and maintained.
   Note that this choice is purely a local manner and is not visible to
   remote edge routers.

5.3.5  Tunneling Mechanisms

   Once VPRN membership information has been disseminated, the tunnels
   comprising the VPRN core can be constructed.

   One approach to setting up the tunnel mesh is to use point-to-point
   IP tunnels, and the requirements and issues for such tunnels have
   been discussed in section 3.0.  For example while tunnel
   establishment can be done through manual configuration, this is

Top      Up      ToC       Page 37 
   clearly not likely to be a scalable solution, given the O(n^2)
   problem of meshed links.  As such, tunnel set up should use some form
   of signalling protocol to allow two nodes to construct a tunnel to
   each other knowing only each other's identity.

   Another approach is to use the multipoint to point 'tunnels' provided
   by MPLS.  As noted in [38], MPLS can be considered to be a form of IP
   tunneling, since the labels of MPLS packets allow for routing
   decisions to be decoupled from the addressing information of the
   packets themselves.  MPLS label distribution mechanisms can be used
   to associate specific sets of MPLS labels with particular VPRN
   address prefixes supported on particular egress points (i.e., stub
   links of edge routers) and hence allow other edge routers to
   explicitly label and route traffic to particular VPRN stub links.

   One attraction of MPLS as a tunneling mechanism is that it may
   require less processing within each edge router than alternative
   tunneling mechanisms.  This is a function of the fact that data
   security within a MPLS network is implicit in the explicit label
   binding, much as with a connection oriented network, such as Frame
   Relay.  This may hence lessen customer concerns about data security
   and hence require less processor intensive security mechanisms (e.g.,
   IPSec).  However there are other potential security concerns with
   MPLS.  There is no direct support for security features such as
   authentication, confidentiality, and non-repudiation and the trust
   model for MPLS means that intermediate routers, (which may belong to
   different administrative domains), through which membership and
   prefix reachability information is conveyed, must be trusted, not
   just the edge routers themselves.

5.4  Multihomed Stub Routers

   The discussion thus far has implicitly assumed that stub routers are
   connected to one and only one VPRN edge router.  In general, this
   restriction should be capable of being relaxed without any change to
   VPRN operation, given general market interest in multihoming for
   reliability and other reasons.  In particular, in cases where the
   stub router supports multiple redundant links, with only one
   operational at any given time, with the links connected either to the
   same VPRN edge router, or to two or more different VPRN edge routers,
   then the stub link reachability mechanisms will both discover the
   loss of an active link, and the activation of a backup link.  In the
   former situation, the previously connected VPRN edge router will
   cease advertising reachability to the stub node, while the VPRN edge
   router with the now active link will begin advertising reachability,
   hence restoring connectivity.

Top      Up      ToC       Page 38 
   An alternative scenario is where the stub node supports multiple
   active links, using some form of load sharing algorithm.  In such a
   case, multiple VPRN edge routers may have active paths to the stub
   node, and may so advertise across the VPRN.  This scenario should not
   cause any problem with reachability across the VPRN providing that
   the intra-VPRN reachability mechanism can accommodate multiple paths
   to the same prefix, and has the appropriate mechanisms to preclude
   looping - for instance, distance vector metrics associated with each
   advertised prefix.

5.5  Multicast Support

   Multicast and broadcast traffic can be supported across VPRNs either
   by edge replication or by native multicast support in the backbone.
   These two cases are discussed below.

5.5.1  Edge Replication

   This is where each VPRN edge router replicates multicast traffic for
   transmission across each link in the VPRN.  Note that this is the
   same operation that would be performed by CPE routers terminating
   actual physical links or dedicated connections.  As with CPE routers,
   multicast routing protocols could also be run on each VPRN edge
   router to determine the distribution tree for multicast traffic and
   hence reduce unnecessary flood traffic.  This could be done by
   running instances of standard multicast routing protocols, e.g.
   Protocol Independent Multicast (PIM) [39] or Distance Vector
   Multicast Routing Protocol (DVMRP) [40], on and between each VPRN
   edge router, through the VPRN tunnels, in the same way that unicast
   routing protocols might be run at each VPRN edge router to determine
   intra-VPN unicast reachability, as discussed in section 5.3.4.
   Alternatively, if a link reachability protocol was run across the
   VPRN tunnels for intra-VPRN reachability, then this could also be
   augmented to allow VPRN edge routers to indicate both the particular
   multicast groups requested for reception at each edge node, and also
   the multicast sources at each edge site.

   In either case, there would need to be some mechanism to allow for
   the VPRN edge routers to determine which particular multicast groups
   were requested at each site and which sources were present at each
   site.  How this could be done would, in general, be a function of the
   capabilities of the CPE stub routers at each site.  If these run
   multicast routing protocols, then they can interact directly with the
   equivalent protocols at each VPRN edge router.  If the CPE device
   does not run a multicast routing protocol, then in the absence of
   Internet Group Management Protocol (IGMP) proxying [41] the customer
   site would be limited to a single subnet connected to the VPRN edge
   router via a bridging device, as the scope of an IGMP message is

Top      Up      ToC       Page 39 
   limited to a single subnet.  However using IGMP-proxying the CPE
   router can engage in multicast forwarding without running a multicast
   routing protocol, in constrained topologies.  On its interfaces into
   the customer site the CPE router performs the router functions of
   IGMP, and on its interface to the VPRN edge router it performs the
   host functions of IGMP.

5.5.2  Native Multicast Support

   This is where VPRN edge routers map intra-VPRN multicast traffic onto
   a native IP multicast distribution mechanism across the backbone.
   Note that intra-VPRN multicast has the same requirements for
   isolation from general backbone traffic as intra-VPRN unicast
   traffic.  Currently the only IP tunneling mechanism that has native
   support for multicast is MPLS.  On the other hand, while MPLS
   supports native transport of IP multicast packets, additional
   mechanisms would be needed to leverage these mechanisms for the
   support of intra-VPRN multicast.

   For instance, each VPRN router could prefix multicast group addresses
   within each VPRN with the VPN-ID of that VPRN and then redistribute
   these, essentially treating this VPN-ID/intra-VPRN multicast address
   tuple as a normal multicast address, within the backbone multicast
   routing protocols, as with the case of unicast reachability, as
   discussed previously.  The MPLS multicast label distribution
   mechanisms could then be used to set up the appropriate multicast
   LSPs to interconnect those sites within each VPRN supporting
   particular multicast group addresses.  Note, however, that this would
   require each of the intermediate LSRs to not only be aware of each
   intra-VPRN multicast group, but also to have the capability of
   interpreting these modified advertisements.  Alternatively,
   mechanisms could be defined to map intra-VPRN multicast groups into
   backbone multicast groups.

   Other IP tunneling mechanisms do not have native multicast support.
   It may prove feasible to extend such tunneling mechanisms by
   allocating IP multicast group addresses to the VPRN as a whole and
   hence distributing intra-VPRN multicast traffic encapsulated within
   backbone multicast packets.  Edge VPRN routers could filter out
   unwanted multicast groups.  Alternatively, mechanisms could also be
   defined to allow for allocation of backbone multicast group addresses
   for particular intra-VPRN multicast groups, and to then utilize
   these, through backbone multicast protocols, as discussed above, to
   limit forwarding of intra-VPRN multicast traffic only to those nodes
   within the group.

Top      Up      ToC       Page 40 
   A particular issue with the use of native multicast support is the
   provision of security for such multicast traffic.  Unlike the case of
   edge replication, which inherits the security characteristics of the
   underlying tunnel, native multicast mechanisms will need to use some
   form of secure multicast mechanism.  The development of architectures
   and solutions for secure multicast is an active research area, for
   example see [42] and [43].  The Secure Multicast Group (SMuG) of the
   IRTF has been set up to develop prototype solutions, which would then
   be passed to the IETF IPSec working group for standardization.

   However considerably more development is needed before scalable
   secure native multicast mechanisms can be generally deployed.

5.6  Recommendations

   The various proposals that have been developed to support some form
   of VPRN functionality can be broadly classified into two groups -
   those that utilize the router piggybacking approach for distributing
   VPN membership and/or reachability information ([13],[15]) and those
   that use the virtual routing approach ([12],[14]).  In some cases the
   mechanisms described rely on the characteristics of a particular
   infrastructure (e.g. MPLS) rather than just IP.

   Within the context of the virtual routing approach it may be useful
   to develop a membership distribution protocol based on a directory or
   MIB.  When combined with the protocol extensions for IP tunneling
   protocols outlined in section 3.2, this would then provide the basis
   for a complete set of protocols and mechanisms that support
   interoperable VPRNs that span multiple administrations over an IP
   backbone.  Note that the other major pieces of functionality needed -
   the learning and distribution of customer reachability information,
   can be performed by instances of standard routing protocols, without
   the need for any protocol extensions.

   Also for the constrained case of a full mesh topology, the usefulness
   of developing a link reachability protocol could be examined, however
   the limitations and scalability issues associated with this topology
   may not make it worthwhile to develop something specific for this
   case, as standard routing will just work.

   Extending routing protocols to allow a VPN-ID to carried in routing
   update packets could also be examined, but is not necessary if VPN
   specific tunnels are used.

Next RFC Part