[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

MPLS Working Group                                         Juha Heinanen
Internet Engineering Task Force                      Telia Finland, Inc.
INTERNET DRAFT                                 Bryan Gleeson, Arthur Lin
Expires February 1998                              Shasta Networks, Inc.


                MPLS Mappings of Generic VPN Mechanisms
                <draft-heinanen-generic-vpn-mpls-00.txt>



1. Status of this Memo

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

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

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).


2. Abstract

   This document describes a set of generic mechanisms which can be used
   to set up network based Virtual Private Networks (VPN) across IP
   networks. In particular,  it describes how these mechanisms can be
   mapped into a network running the Multi-Protocol Label Switching
   (MPLS) specification.  The mechanisms described, however, can apply
   to any type of IP network running various forms of IP tunneling
   mechanisms, and are not solely restricted to MPLS networks.  This
   Draft serves to introduce these generic mechanisms, which are part of
   the broader VPN framework which will be described more fully in
   forthcoming Drafts.

3. Introduction

   An earlier Draft [Heinanen] proposed a number of mechanisms for
   Virtual Private Network (VPN) support in networks running the Multi-
   Protocol Label Switching (MPLS) specification [Callon].



Heinanen, et al.                                                [Page 1]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


   Subsequently, it was noted that most of the mechanisms proposed in
   that Draft are subsets of generic VPN mechanisms, and can also apply
   to current IP networks.  Hence this Draft first discusses these
   generic mechanisms and shows how these may be applied in general IP
   networks.  In particular, these can be applied in IP networks not
   running any major new protocol, such as MPLS, which may facilitate
   roll- out of VPN services on current IP networks, prior to the
   possible future deployment of MPLS.  Subsequently, the Draft also
   discusses how these mechanisms can be applied to MPLS networks in
   particular.

   As with the earlier Draft, this Draft is intended to serve as a
   framework, highlighting areas for more detailed specification.
   Neither has enough detail to allow for interoperable implementations.
   Hence more work is required to finalize a specification for VPN
   support, both on MPLS networks and on current networks.  A future
   Internet Draft will propose a more general VPN framework and specific
   areas for future specification so as to allow more general
   interoperable VPN solutions.


4. VPN Definition and Scope

   A VPN can be succinctly defined as the emulation of a private wide
   area network (WAN) facility using IP facilities (including the public
   Internet, or private IP backbones).  There are a wide variety of VPN
   types, corresponding to the very wide variety of WAN facilities that
   are currently defined. Future Drafts will discuss the full range of
   possible VPN types, but the particular type of VPN specifically
   discussed in this Draft can be described as a 'virtual private routed
   network' (VPRN), in which a customer with multiple geographically
   dispersed sites wishes to connect each of these sites together into a
   private network. Such networks are routinely built today using, for
   instance, frame relay links and/or leased lines between the routers
   at each pair of sites, or, more likely, given the cost of such links,
   by star wiring each site to a single central site.

   A VPRN emulates such a network using dedicated IP links.  The nature
   of the connectivity of these sites is discussed further below, but
   for the moment it can be assumed that it is desired that each of
   these sites be logically meshed to each other site, since there is
   less cost assumed with full meshing in a virtual IP network, than in
   cases where physical resources (e.g. Frame Relay DLCI, or a leased
   line) must be allocated for each connected pair of sites.  This
   yields optimal routing, since it precludes the need for traffic
   between two sites to traverse through a third.

   VPNs of various sorts are today routinely implemented using a



Heinanen, et al.                                                [Page 2]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


   combination of host applications and customer premises equipment
   (CPE) routers.  The mechanisms discussed in both this Draft and its
   predecessor, however, apply specifically only to the class of
   'network based VPNs', where the operation of the VPN is outsourced to
   an Internet service provider (ISP), and is implemented on network as
   opposed to CPE equipment.  There is significant interest in such
   solutions both by customers seeking to reduce support costs and by
   ISPs seeking new revenue sources.  The network based focus allows the
   use of particular mechanisms which may lead to highly efficient and
   cost effective VPRN solutions.  However such mechanisms also leverage
   tools (e.g. piggybacking on routing protocols) which are accessible
   only to ISPs and which are unlikely to be made available to any
   customer, or even hosted on ISP owned and operated CPE, due to the
   problems of coordinating joint management of the CPE gear by both the
   ISP and the customer.

   Hence, it is assumed that each customer site CPE router connects to
   an ISP edge router through one or more dedicated point-to-point stub
   links (e.g. leased lines, ATM or Frame Relay connections); the VPRN
   mechanisms discussed below will operate on each of these ISP edge
   routers, in order to route traffic received across a stub link to the
   appropriate destination customer site across its stub link.  In
   particular, the edge router will hide all VPRN topology information
   from the CPE routers, hence significantly simplifying the operation
   of the CPE.

   Note that a single ISP edge router could terminate multiple stub
   links belonging to the same VPRN.  The means by which traffic is
   routed between such local interfaces is outside the scope of
   standardization, per se, though obviously these would leverage many
   of the same routing and forwarding mechanisms used for communication
   with remote VPN sites.

   In such a scenario, a VPN connecting each of these sites must
   generally meet a number of minimum requirements, which arise from the
   need to essentially emulate the facilities that customers expect from
   a leased line facility, and which, hence, they also generally expect
   from any emulation of such a facility.  While there are a number of
   such requirements, three are of particular concern to this Draft:

   A. Support for Disjoint Address Spaces:

   The addressing used within the VPRN may have no relation to the
   addressing of the ISP, or ISPs, across which the VPRN may operate.
   In particular, the former may also be non-unique, private IP
   addressing [Rekhter1].

   B. Support for Intra-VPN routing:



Heinanen, et al.                                                [Page 3]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


   Since a VPRN will generally interconnect multiple sites, the VPRN
   mechanism must implement some mechanism by which intra-VPN traffic
   can be efficiently routed to the correct destination site within the
   VPRN.

   C. Support for Data Security:

   In general, customers using VPNs require some form of data security,
   given the general perceptions of the lack of security of IP networks,
   and particularly that of the Internet.  Whether or not this
   perception is correct, it is one that must be addressed by any VPN
   implementation.  Most recent VPN implementations are converging on
   the use of IPSec facilities [Kent] for this purpose.

   Together, these requirements imply that VPRNs must be implemented
   through some form of IP tunneling mechanism, where the addressing
   used within the VPRN can be disjoint from that used to route the
   tunneled packets across the IP backbone.  Such tunnels, depending
   upon their form, can provide some level of intrinsic data security,
   or this can also be enhanced using other mechanisms (e.g. IPSec).

   Such tunnels together form an overlay network operating over and
   across the general Internet backbone, connecting each of the ISP edge
   routers supporting VPN stub links to each other.  Within each of the
   ISP edge routers, there must be VPN specific IP forwarding
   mechanisms, to forward packets received across each of the stub links
   ('ingress' traffic) to the appropriate destination edge router, based
   upon the address space of the customer's network, and to forward
   packets received from the core ('egress' traffic) to the appropriate
   stub link, for cases where an edge router supports multiple stub
   links belonging to the same VPN (as will be noted below, VPN tunnels
   can, as a local matter, either terminate on the edge router, or on
   each stub link; in the former case, a VPN specific forwarding table
   is needed for egress traffic, in the latter case, it is not).

   Note also that a single customer site may belong concurrently to
   multiple VPNs, of various sorts, and/or may wish to transmit traffic
   both onto one or more VPNs and to the default Internet. The
   mechanisms needed to do this are outside the scope of this Draft, and
   are not discussed further.

   For the purposes of this Draft, it is also assumed that all of the
   traffic being sent across the VPRN is IP traffic, since the devices
   implementing the VPRN need to be able to interpret the packet header
   information to determine the appropriate end-point within the VPRN.
   However, that procedures discussed here could be readily extended for
   Multiprotocol transport, either by forming separate VPRNs for each
   protocol, or by running Multiprotocol routing and forwarding



Heinanen, et al.                                                [Page 4]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


   procedures in each VPN router, and multiplexing multiple protocols
   across the VPN stub links.  IP encapsulation methods could also be
   used to transport different protocols across IP links.  These
   multiprotocol transport mechanisms are left for further study.

5. Generic VPN Mechanisms

   ISPs wishing to offer tunnel based VPRN services need to be able to
   do so with minimal configuration, since this yields the most cost
   effective solution.  The generic VPN mechanisms discussed here apply
   to the means by which this can be done. The following sections
   discuss these in detail.


5.1 VPN Membership Information Configuration and Dissemination

   In order to establish a VPRN, or to insert new customer sites into an
   established VPRN, the stub links on each edge router from those sites
   in the particular VPRN must first be configured with the identity of
   the particular VPRN to which the stub links belong.  Note that this
   first step, of stub link configuration, is unavoidable, since clearly
   the edge router cannot infer such bindings and hence must be
   configured with this information.  The means by which this is done
   are outside the scope of this Draft, but a management information
   base (MIB) allowing for bindings between local stub links and VPN
   identities may be one obvious solution.

   Thereafter, each edge router must learn either the identity of, or,
   at least, the router 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; this is
   discussed further below.

   In order to configure each stub link with the identity of the VPN to
   which it belongs, some form of VPN identifier is required; the scope
   of uniqueness of this identifier is a function of its usage, which is
   related to how VPRN membership is disseminated.  This problem, of
   VPRN member dissemination between participating edge routers, can be
   solved in a variety of ways:

   A. Directory Lookup:

   The members of a particular VPRN, that is, at a minimum, the identity
   of the edge routers supporting stub links in the VPRN, and possibly
   also the identity of each of the stub links, could be configured into
   a directory, which edge routers could query, using some defined



Heinanen, et al.                                                [Page 5]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


   mechanism (e.g. LDAP), upon configuration of their local stub
   interfaces and VPN identifier. The latter, in this case, need only be
   unique within the scope of the directory.

   This mechanism 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 would also need 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.

   B. Explicit Management Configuration:

   A VPRN Management Information Base (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 possibly
   also the identity of each of the stub links.  Similar mechanisms
   could also be used, as noted above, to configure the VPN bindings of
   the local stub links on the edge router.  The scope of the VPN
   identifier in this case is related to the scope of the management
   system.

   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.

   C. Piggybacking in Routing Protocols:

   VPRN membership information could be piggybacked into the routing
   protocols run by each edge router, 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 the 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



Heinanen, et al.                                                [Page 6]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


   contained information 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, and is discussed
   further below.

   The advantage of this last scheme is that it allows for very
   efficient information dissemination, particularly across multiple
   routing domains (e.g. across different autonomous systems/ISPs) 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. Significant administrative complexity may also be
   required to configure scoping mechanisms so as to both permit and
   constrain the dissemination of the piggybacked advertisements.

   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. The earlier Draft [Heinanen] discussed the last scheme
   only, and that is further spelled out below, but the other two
   schemes may also offer important practical advantages.  In
   particular, note that, in practice, there will almost always be some
   directory or management system which will maintain VPN membership
   information, since, as noted above, the binding of VPNs to stub links
   must be configured, hence, presumably, such information would be
   obtained from, and stored within, some database.  Hence the
   additional steps to facilitate the configuration of such information
   into edge routers, and/or, facilitate edge router access to such
   information, may not be excessively onerous.  These methods will be
   discussed in greater detail in forthcoming Drafts.


5.1.1 VPN Identifier

   A principal benefit of the router piggybacking model is that it
   allows for simple dissemination of VPN membership information across
   multiple ASs. This implies the need for a VPN identifier than can be



Heinanen, et al.                                                [Page 7]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


   unique across multiple ASs. To that end, [Heinanen] proposed a
   globally unique VPN identifier (note that such an identifier may be
   useful for VPN types other than only VPRNs) made up of the
   concatenation of an AS number, and a label assigned by the AS
   administrator which is locally unique within the particular AS. It is
   proposed that this be adopted as the VPN identifier, with the further
   stipulation that the VPN ID be coded as a four octet BGP Communities
   Attribute [Chandra], made up a two octet AS number and a 2 octet,
   unstructured integer VPN number, to allow for sufficient numbers of
   VPNs per AS.  The specific details of this proposed format are for
   future clarification.

   Note that where a VPN crosses multiple ASs, then there must be some
   administrative mechanisms to coordinate VPN ID assignment e.g.
   through the notion of a 'home AS' for a particular VPN, which is used
   in the VPN ID of that VPN. A VPN ID coded as proposed could also be
   easily piggybacked in BGP, and could also be easily specified within
   BGP policy filters in AS border routers for scoping and
   administrative purposes.

   For the remainder of the discussion, it is assumed that the VPN
   identifier will be as so described.


5.2  Tunneling Mechanisms

   Once VPRN membership information has been disseminated, the tunnels
   comprising the VPRN can be constructed.  While this can be done
   through manual configuration, this is 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 signaling protocol which
   would allow two nodes to construct a tunnel to each other knowing
   only each other's identity.  Note also that there are some tunneling
   mechanisms which allow for multiple disjoint calls or sessions within
   the same tunnel - in such a 'shared tunnel' case, the signaling
   protocol could also be used to assign a call within an existing
   tunnel between two edge routers for a new VPN between them.

   There are two specific cases of interest networks running MPLS, and
   current networks not running MPLS.  These are discussed separately.


5.2.1 MPLS Networks

   As noted in [Heinanen], 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



Heinanen, et al.                                                [Page 8]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


   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.  The exact
   relationship of the various MPLS labels and the particular VPN to
   which they are bound is a function of whether or not the CPE edge
   routers participate or do not participate in MPLS with the ISP edge
   routers. These cases are discussed in greater detail below.

   The principal attraction of MPLS as a tunneling mechanism is that it
   may require less processing within each edge router than alternative
   tunneling mechanisms.  This is also 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).  As discussed below, however, such implicit mechanisms
   address only some of the potential security concerns of customers.


5.2.2 Non-MPLS Networks

   For non-MPLS networks, VPNs in general require the use of an explicit
   IP tunneling mechanism.  There are numerous IP tunneling mechanisms,
   including IP/IP [Simpson], GRE tunnels [Hanks], L2TP [Valencia] and
   IPSec [Kent].  Each of these allow for opaque transport of IP
   packets, with routing disjoint from the address fields of the
   encapsulated packets.  Additional processing is required in edge
   routers for the use of any of these protocols, with some (e.g. IPSec)
   mandating significant processing capabilities.  On the other hand,
   such tunneling protocols can provide significantly more comprehensive
   data security capabilities than the implicit security of MPLS.

   It is the case, however, that none of the protocols listed above were
   originally designed to support VPNs of the type under consideration.
   As such, none provide all of the mechanisms likely to be needed for
   VPN applications.  In particular, only L2TP and IPSec can be
   considered to have any form of signaling protocol (the L2TP control
   protocol, and the Internet Key Exchange protocol [Harkins],
   respectively) which could potentially be used to automate the process
   of tunnel set up. Furthermore, none of these tunneling protocols have
   support today for multicast (other than source replication), whereas
   MPLS does have such support, though the application of MPLS
   mechanisms to multicast transport within VPNs is not yet fully
   defined, and requires further study.

   Given however, the current paucity of operational networks running
   MPLS, there is likely to be significant value in fully defining a VPN



Heinanen, et al.                                                [Page 9]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


   tunneling mechanism which could be deployed in current networks.  It
   may also be possible to readily extend other IP tunneling protocols
   to incorporate support for multicast.  Subsequent Drafts will address
   these issues.


5.3 Stub Link Reachability Information

   There must be mechanisms to allow ISP edge routers to determine the
   set of VPN addresses and address prefixes reachable at each stub link
   connecting to the edge router.  There are a number of means by which
   this can be done:

   A. Routing Protocol Instance:

   A routing protocol can be run between the CPE edge router and the ISP
   edge router to exchange reachability information.  Note that this
   routing exchange is asymmetrical since the CPE router views the ISP
   edge router as the default path into the VPN.  Any suitable routing
   protocol could be used to exchange routing information between the
   CPE and ISP edge routers.  It should be noted that the only function
   of this protocol is indeed to exchange reachability information, not
   to discover topology, since, by definition, there is only a single,
   point-to-point (logical) link between the CPE router and the ISP edge
   router, with the latter then discovering (and hiding) the VPN
   topology.

   Likely protocols for this purpose include RIPv2, OSPF [Moy] and BGP-4
   [Rekhter2].  Note that even if the same protocol is used between the
   CPE and ISP edge routers, and from the ISP edge routers into the
   core, these will be two quite distinct routing instantiations.  If
   the ISP edge router uses routing protocol piggybacking to disseminate
   VPN membership and reachability information across the core, then it
   may redistribute suitably labeled routes from the CPE routing
   instantiation to the core routing instantiation (but never the other
   way round).  There is no requirement that the same protocol, or even
   the same CPE reachability information gathering mechanism, be run
   between each CPE router and associated edge router in a particular
   VPRN, since this is purely local matter.

   Note that if a particular customer site concurrently belongs to
   multiple VPNs (or wishes to concurrently communicate with both a VPN
   and the Internet), then the ISP edge router must have some means of
   unambiguously mapping stub link address prefixes to particular VPNs.
   This could be done either by ensuring (and appropriately configuring
   the ISP edge router to know) that particular disjoint address
   prefixes are mapped into separate VPNs, or by tagging the routing
   advertisements from the CPE edge router with the appropriate VPN



Heinanen, et al.                                               [Page 10]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


   identifier.  In the case of MPLS, as discussed below, different MPLS
   labels would be used to differentiate the disjoint prefixes assigned
   to particular VPNs.  In any case, some administrative procedure would
   be required for this coordination.

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

   C. ISP Administered Addresses:

   The set of addresses used by each stub site could be administered and
   allocated by the ISP, which may be appropriate for very small sites
   with little network administration resources.  In such a case the ISP
   edge router could determine these addresses by proxying for the
   particular address administration mechanism (e.g. DHCP).  Note that
   in this case it would be the responsibility of the ISP to ensure that
   each site in the VPN received a disjoint address space.

   D. MPLS Label Distribution Protocol:

   In cases where the CPE edge router runs MPLS, the MPLS LDP could be
   extended to convey the set of prefixes at each stub site, together
   with the appropriate labeling information.  While LDP is not
   generally considered a routing protocol per se, it may be useful to
   extend it for this particular constrained scenario.  This is for
   further study.


5.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 stub link, so as to preclude the need to maintain and disseminate
   large numbers of host routes.

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




Heinanen, et al.                                               [Page 11]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


   A. Directory Lookup:

   Along with VPN membership information, a central directory could
   maintain a listing of the address prefixes associated with each end
   point.  Such information could be obtained by the server through
   protocol interactions with each edge router.  Note that the same
   directory synchronization issues discussed above would apply in this
   case.

   B. 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, and also raises the question of how the
   management system learns such information in the first place.

   C. Local Intra-VPRN Routing Instantiations:

   In this approach, each edge router runs an instantiation 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. The intra-VPN 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.

   Note that this intra-VPRN routing protocol need have no relationship
   with the routing protocols operated by the ISPs in the path.
   Specifically, the intra- VPRN routing protocol operates as an overlay
   over the IP backbone, and, given the very simple meshed topology of
   the VPRN, could be a very simple protocol, such as RIPv2 [Malkin], at
   least unless the VPRN spans a very large number of edge routers.
   Since the intra-VPN routing protocol runs as an overlay, it is also
   wholly transparent to any intermediate routers, and to any edge
   routers not within the VPRN.  This also implies that such routing
   information can also remain opaque to such routers, which may be a
   necessary security requirements in some cases.

   D. Link Reachability Protocol

   Each edge router could run a link reachability protocol - for
   instance, some variation of the MPLS 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. Such a protocol would need to be
   specified, and would require aspects of current routing protocols
   such as hello protocols, and re-transmit timers and/or positive
   acknowledgements.  However, such an approach may reduce the



Heinanen, et al.                                               [Page 12]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


   processing burden of running routing protocol instantiations 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.

   E. Piggybacking in Routing Protocols:

   As with VPN 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 would extract this information from
   received route advertisements in the same way as they would 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.

   The earlier Draft [Heinanen] discussed the last scheme only, and that
   is further spelled out below.  A number of vendors have already
   announced, however, their intention to support variants of the
   virtual router scheme, which is also less disruptive to currently
   deployed routing protocols.  As such, this scheme merits further
   investigation and will be addressed in future Drafts.


6. Routing Protocol Piggybacking

   As noted above, routing protocol piggybacking could be used to carry
   VPN membership information alone, or also VPN reachability
   information.  The means by which this is done, and the nature of the
   piggyback information, is a function both of the particular routing
   protocol, and of the underlying network mechanism.  The particular



Heinanen, et al.                                               [Page 13]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


   cases of OSPF and BGP-4 are discussed below.

6.1 OSPF

   OSPF is often used as an intra-AS routing protocol, and hence may be
   a required candidate for routing protocol piggybacking.  One means by
   which VPN membership and reachability information could be
   piggybacked is through the use of the proposed OSPF opaque LSA
   [Coltun].  The exact details of how such a piggybacking advertisement
   might be coded are for further study.  In particular, it may prove to
   be the case that opaque LSAs could be well suited for piggybacking
   VPN membership information, but not VPN reachability information,
   since opaque LSAs, at least as currently defined, are attributes of,
   not indexes into, reachability information. Using them in the latter
   manner, which would be required to piggyback VPN reachability
   information, may break some existing OSPF implementations. Opaque
   LSAs do, however, have a well defined scoping mechanism, that, at
   least within an AS, allows for control over the extent of
   dissemination of a VPN advertisement.

   Note also that as a link state protocol OSPF advertisements always
   allow for the identification of the source of an advertisement.
   However, each router in the OSPF network, and not only edge routers,
   will also need to examine received advertisements, and explicitly
   ignore piggybacked VPN advertisements, unless configured to be a VPN
   terminator (i.e. edge router).


6.2 BGP-4

   There are a number of potential mechanisms by which VPN information
   could be piggybacked into BGP-4, including the Multiprotocol
   Extensions attribute [Bates] or the BGP communities attribute.  In
   the case where VPN reachability information is piggybacked, each VPN
   address prefix could be encoded as Network Layer Reachability
   Information (NLRI) and bound to the VPN identifier as a community
   attribute, if the VPN ID has the format proposed previously. Note
   that in cases where it was desired only to advertise VPN membership
   information, then advertising each VPN prefix may be onerous and
   undesirable, but there is no specific mechanism in BGP-4, as yet, to
   advertise anything other than NLRI.

   In the case where this is done on an MPLS network, then the
   advertisement would carry each VPN prefix, together with the MPLS
   label(s) to be used to send packets to that stub link.  As noted
   above, these labels, as a purely local matter, could identify either
   the route to each stub link, or only to the edge router itself, which
   would then use its own forwarding mechanisms for egress packets.



Heinanen, et al.                                               [Page 14]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


   Since there is already defined a particular mechanism for carrying
   MPLS labels in BGP-4 using the Multiprotocol Extensions field
   [Rekhter3], this would suggest that this mechanism should be
   generalized for the purpose also of conveying VPN information; hence
   it is proposed that that Draft be amended for this purpose.

   The use of BGP-4 for VPN piggybacking is more complex in cases where
   this is done on non-MPLS networks.  In such a case, the piggybacked
   advertisements must allow for the explicit identification of the
   source of the advertisement.  This is important for tunnel set up in
   non-MPLS networks, where each edge router needs to know the identity
   (i.e. IP address) of each of the other edge routers, in order to
   initiate whatever signaling mechanism may be used for tunnel set-up.

   At present there is no means by which the original source of a BGP
   advertisement can be identified once that advertisement is
   redistributed (e.g. from an intra-AS protocol like OSPF into BGP at a
   border node, or from an edge router through a border router for
   distribution outside the original AS).  Since VPN support in non-MPLS
   networks is an important requirement, it is proposed that whatever
   BGP-4 mechanism is chosen for the purpose of VPN advertisements also
   be amended to allow for explicit tagging with the IP address of the
   original source of the advertisement.  One possible means by which
   this could be done may be to associate the VPN ID (coded as a
   Community Attribute) with the /32 prefix (i.e. IP address) of the
   edge router supporting the VPN.  This issue is for further study.

   Note that in the case where BGP advertisements are propagated across
   AS boundaries, then each border router must cache the full set of
   prefixes and associated label stacks of each advertised VPN.  In such
   a case, further work is also needed to control scoping of BGP
   piggybacked advertisements.  In particular, at AS boundaries, border
   routers would generally need to be manually configured with VPN route
   advertisement policies to determine whether such advertisements
   should be propagated, and, if so, to which peer ASs.  In general ASs
   will also likely automatically reject VPN advertisements received
   from peer ASs unless specifically configured to pass them.  Some
   administrative mechanism (e.g. manual procedures or some form of
   directory communication, for instance) would be needed for this
   purpose.

   Note also that such scoping policy configurations would be needed not
   only in each border router of each AS with one or more VPN
   termination points, but also in each AS in the transit path between
   them.  This last may pose problems if the trust system includes the
   terminating ASs, but excludes one or more of the transit ASs.  These
   problems expose a particular artifact of router piggybacking - while
   VPN membership and reachability information is relevant only to the



Heinanen, et al.                                               [Page 15]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


   particular edge routers concerned, router piggybacking necessarily
   requires also the active participation of all intermediate routers
   that need to process and propagate such advertisements.  This may
   impose significant burdens on the operation and administration of
   such intermediate routers, as well as compromising the integrity of
   the VPNs concerned.


7. MPLS Mappings

   The earlier Draft [Heinanen] proposed a number of mechanisms for
   facilitating VPN set up in MPLS networks.  As noted above, most of
   these mechanisms are subsets of more generic VPN mechanisms, and some
   of the alternate mechanisms described above can also be applied to
   MPLS networks.  There are specific issues with respect to mappings
   into MPLS networks due to the nature of the particular control and
   data planes of MPLS. Furthermore, the operation of these data and
   control planes is a function of whether or not the CPE router also
   runs MPLS.  These cases are considered separately.

7.1 CPE Router Runs MPLS

   In this case the CPE router and ISP edge router exchange, using one
   of the mechanisms discussed above, the set of address prefixes
   associated with that stub site and then, concurrently or
   subsequently, assign MPLS labels to each such prefix.  Note that, as
   discussed above, the edge router could decide, as a local matter, to
   assign the same label to each such stub link, or distinct labels to
   each, depending upon whether or not it wished to explicitly forward
   egress packets.

   If a CPE routers belongs concurrently to more than one VPN, then it
   must label the (disjoint) prefixes of each VPN differently, to allow
   for unambiguous routing at the edge router.  Thereafter, the ISP edge
   router uses whatever routing and label assignment mechanisms may be
   used within its network to disseminate the prefixes, tagged with the
   appropriate VPN ID, and the locally assigned MPLS label, to each
   other peer Label Switching Router (LSR).

   In the specific case where BGP-4 is used for piggybacking across the
   core network, this implies that each edge router and border router in
   the AS but not the intermediate LSRs - will receive the bindings of
   VPN IDs, VPN prefixes and associated labels, together with the label
   needed to forward traffic to the particular edge router from its BGP
   peers. If border routers were to propagate this information further
   across the core, they would then push into this label stack,
   information to identify the explicit tunnel route to the particular
   border router from its peer border routers.  At a terminating edge



Heinanen, et al.                                               [Page 16]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


   router, the edge router would maintain in its VPN specific Label
   Information Base (LIB), the mappings of particular VPN prefixes to
   the label stacks associated with each prefix.  Note that in this
   case, edge routers will know, and need know, only the route (i.e.
   MPLS label stack) to each VPN prefix, and will not know the identity
   of the edge router through which that prefix is reached.

   Each edge router may also advertise, using either LDP or a
   piggybacked routing protocol, a default label to be used by the CPE
   across its stub links to send data into the VPN, unless this binding
   was implicit (e.g. all traffic from a stub link only gets sent to one
   particular VPN).

   Note that all of these label stacks are disjoint from the labels used
   for connectivity between the edge and border routers, through the
   intermediate LSR within the AS MPLS network. This level of intra-AS
   connectivity is a lower level than the BGP peering level; hence,
   disjoint MPLS label allocation mechanisms (e.g. LDP following prefix
   distribution using an intra-AS routing protocol) would be used to
   determine connectivity to, and the appropriate label stacks for, edge
   and border router connectivity across the AS.

   Hence an edge or border router wishing to transmit to a particular
   VPN stub link would need to first determine the destination VPN
   prefix, and the VPN label stack associated with that prefix.
   Subsequently, it would then determine the label switched path (LSP)
   to the particular destination edge router, push the resultant label
   stack onto the VPN label and transmit the packet.  At the destination
   edge router, the intra-AS routing label stack would be popped, and
   the packet sent to the appropriate stub link using either the VPN
   label, if explicitly tagged, or using a local forwarding mechanism,
   if not.


7.2 CPE Router Does Not Run MPLS

   This case would work exactly as described above, except that the ISP
   edge router would proxy for the CPE router by assigning labels to
   each CPE prefix. Packets sent to the stub link would be routed as
   described above, except that at the destination edge router the label
   stack would be removed and an untagged packet sent to the CPE router.
   In this case, the edge router would also need some unambiguous means
   of determining the destination VPN, where a particular stub site
   supports multiple VPNs.  Typically this will require disjoint address
   spaces in each VPN.

   Note that in either case that all border routers will need to
   maintain label mappings for all prefixes associated with each VPN in



Heinanen, et al.                                               [Page 17]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


   the AS. This is a consequence of the fact that BGP can, at present,
   only advertise routes to particular NLRI prefixes and hence, cannot,
   as discussed above, advertise only VPN to edge router bindings. It is
   also, of course, obvious, that such information cannot in any sense
   be aggregated.


7.3  Use of RSVP in MPLS Networks

   There have been a number of proposals to use the Resource Reservation
   Protocol (RSVP) to allocate labels within MPLS networks, either for
   the purpose of setting up flow specific LSPs [Davie] or for
   administrating traffic engineered tunnels across multiple ASs, as in
   the PASTE proposal [Li].  In either case, VPN membership and, perhaps
   also VPN reachability information, could be carried using such RSVP
   based label allocation mechanisms, as with the use of the LDP,
   described above.  In particular, in the case of the PASTE proposal,
   RSVP is used to set up and administer traffic engineered tunnels that
   span potentially multiple service provider domains, and provide non-
   default path forwarding.  In such a case, router piggybacking may not
   be possible, and hence RSVP may be the only protocol available in
   which to piggyback VPN advertisements.  This subject is for further
   study.


8. Security Considerations

   As noted above, VPN operation on MPLS networks relies upon the
   implicit security of explicitly labeled LSPs.  Unless a particular
   edge router has been configured for membership into a particular VPN,
   then no CPE router connected to that edge router should be able to
   insert traffic into that VPN. Note, however, that this is only true
   if each edge router in the network, and not just those participating
   in the VPN, ensures that no CPE router can transmit packets with
   label information that may cause it to be inserted, at some merge
   point, into a LSP leading to the labeled VPN.  As such, the trust
   model for MPLS based VPNs must encompass all MPLS edge routers, and
   not only those participating in the particular VPN.

   The particular form of data security offered by MPLS based VPNs also
   does not address other potential security concerns e.g. data
   snooping, non- repudiation, etc.  Such concerns can only be met
   through more explicit security mechanisms e.g. IPSec.  As noted
   earlier, such mechanisms are required for any tunneling mechanism
   operating on non-MPLS networks where paths are not explicitly
   labeled.  Note, however, that such security mechanisms - e.g.
   bilateral IPSec peerings between two edge routers in a VPN - have the
   advantage that the trust model need only include the relevant edge



Heinanen, et al.                                               [Page 18]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


   routers, and not any of the intermediate routers (or administrative
   domains).

   Particular VPN configuration mechanisms have their own security
   issues.  In particular, piggybacking of VPN membership and routing
   information in routing protocols would potentially expose such
   information to all intermediate routing nodes.  This may be a
   particular issue where this mechanism is used to distribute VPN
   information across multiple ASs or ISPs.  Mechanisms to address this
   problem may be worthy of study e.g. the use of encryption and
   authentication mechanisms to protect such piggybacked information,
   with the use of key distribution mechanisms to restrict access only
   to trusted edge routers.


9. Intellectual Property Considerations

   Cisco Systems has claimed potential intellectual property rights to
   certain aspects of the mechanisms discussed in the earlier Draft, and
   referred to here.  Refer to [Heinanen] for the specific disclosure
   notice.  The nature, extent and impact of these claims are unknown to
   the present authors.


10.  Acknowledgements

   Thanks to Tony Li, of Juniper Networks, for his helpful review and
   feedback and to Anthony Alles, of Shasta Networks, for his assistance
   in the generation of this Draft.

11. References

   [Bates] Bates, T.  "Multiprotocol Extensions for BGP-4", RFC 2283.

   [Callon] Callon, R., et al  "Multiprotocol Label Switching
   Architecture", draft-ietf-mpls-arch-02.txt.

   [Chandra] Chandra, R. and Traina, P.  "BGP Communities Attribute",
   RFC 1998.

   [Coltun] Coltun, R.  "The OSPF Opaque LSA Option", RFC 2370.

   [Davie] Davie, B., et al - "Use of Label Switching with RSVP",
   draft-ietf-mpls-rsvp-00.txt

   [Hanks]  Hanks, S., et al  "Generic Routing Encapsulation over Ipv4
   Networks", RFC 1702.




Heinanen, et al.                                               [Page 19]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


   [Harkins]  Harkins, D. and Carrel, D.  "The Internet Key Exchange
   (IKE)", draft-ietf-ipsec-isakmp-oakley-08.txt.

   [Heinanen]  Heinanen, J. and Rosen, E.  "VPN Support with MPLS"
   draft-heinanen-mpls-vpn-01.txt.

   [Kent]  Kent, S. and Atkinson, R.  "Security Architecture for the
   Internet Protocol", draft-ietf-ipsec-arch-sec-06.txt.

   [Li]  Li, T. and Rekhter, Y. - "Provider Architecture for
   Differentiated Services and Traffic Engineering (PASTE)", draft-li-
   paste-00.txt.

   [Malkin] Malkin, G.  "RIP Version 2  Carrying Additional
   Information", RFC 1723.

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

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

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

   [Rekhter3] Rekhter, Y. and Rosen, E.  "Carrying Label Information in
   BGP-4", draft-ietf-mpls-bgp4-mpls-00.txt.

   [Simpson]  Simpson, W.  "IP in IP Tunneling", RFC 1853.

   [Valencia], Valencia, A., et al  "Layer Two Tunneling Protocol
   "L2TP"", draft-ietf-pppext-l2tp-11.txt.

   11. Author Information

        Juha Heinanen
        Telia Finland, Inc.
        Myyrmaentie 2
        01600 VANTAA
        Finland
        Tel: +358 303 944 808
        Email: jh@telia.fi

        Bryan Gleeson
        Shasta Networks
        249 Humboldt Court
        Sunnyvale CA 94089-1300
        USA
        Tel: +1 (408) 548 3711



Heinanen, et al.                                               [Page 20]


INTERNET DRAFT  MPLS Mappings of Generic VPN Mechanisms     August, 1998


        Email: bgleeson@shastanets.com

        Arthur Lin
        Shasta Networks
        249 Humboldt Court
        Sunnyvale CA 94089-1300
        USA
        Tel: +1 (408) 548 3788
        Email: alin@shastanets.com










































Heinanen, et al.                                               [Page 21]


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