rfc2547.txt

RFC 的详细文档！


RFC 2547                     BGP/MPLS VPNs                    March 1999


   In essence, a Target VPN attribute identifies a set of sites.
   Associating a particular Target VPN attribute with a route allows
   that route to be placed in the per-site forwarding tables that are
   used for routing traffic which is received from the corresponding
   sites.

   There is a set of Target VPNs that a PE router attaches to a route
   received from site S. And there is a set of Target VPNs that a PE
   router uses to determine whether a route received from another PE
   router could be placed in the forwarding table associated with site
   S. The two sets are distinct, and need not be the same.

   The function performed by the Target VPN attribute is similar to that
   performed by the BGP Communities Attribute.  However, the format of
   the latter is inadequate, since it allows only a two-byte numbering
   space.  It would be fairly straightforward to extend the BGP
   Communities Attribute to provide a larger numbering space.  It should
   also be possible to structure the format, similar to what we have
   described for RDs (see section 4.1), so that a type field defines the
   length of an administrator field, and the remainder of the attribute
   is a number from the specified administrator's numbering space.

   When a BGP speaker has received two routes to the same VPN-IPv4
   prefix, it chooses one, according to the BGP rules for route
   preference.

   Note that a route can only have one RD, but it can have multiple
   Target VPNs.  In BGP, scalability is improved if one has a single
   route with multiple attributes, as opposed to multiple routes.  One
   could eliminate the Target VPN attribute by creating more routes
   (i.e., using more RDs), but the scaling properties would be less
   favorable.

   How does a PE determine which Target VPN attributes to associate with
   a given route?  There are a number of different possible ways.  The
   PE might be configured to associate all routes that lead to a
   particular site with a particular Target VPN.  Or the PE might be
   configured to associate certain routes leading to a particular site
   with one Target VPN, and certain with another.  Or the CE router,
   when it distributes these routes to the PE (see section 6), might
   specify one or more Target VPNs for each route.  The latter method
   shifts the control of the mechanisms used to implement the VPN
   policies from the SP to the customer.  If this method is used, it may
   still be desirable to have the PE eliminate any Target VPNs that,
   according to its own configuration, are not allowed, and/or to add in
   some Target VPNs that according to its own configuration are
   mandatory.




Rosen & Rekhter              Informational                     [Page 11]

RFC 2547                     BGP/MPLS VPNs                    March 1999


   It might be more accurate, if less suggestive, to call this attribute
   the "Route Target" attribute instead of the "VPN Target" attribute.
   It really identifies only a set of sites which will be able to use
   the route, without prejudice to whether those sites constitute what
   might intuitively be called a VPN.

4.2.2. Route Distribution Among PEs by BGP

   If two sites of a VPN attach to PEs which are in the same Autonomous
   System, the PEs can distribute VPN-IPv4 routes to each other by means
   of an IBGP connection between them.  Alternatively, each can have an
   IBGP connection to a route reflector.

   If two sites of VPN are in different Autonomous Systems (e.g.,
   because they are connected to different SPs), then a PE router will
   need to use IBGP to redistribute VPN-IPv4 routes either to an
   Autonomous System Border Router (ASBR), or to a route reflector of
   which an ASBR is a client.  The ASBR will then need to use EBGP to
   redistribute those routes to an ASBR in another AS.  This allows one
   to connect different VPN sites to different Service Providers.
   However, VPN-IPv4 routes should only be accepted on EBGP connections
   at private peering points, as part of a trusted arrangement between
   SPs.  VPN-IPv4 routes should neither be distributed to nor accepted
   from the public Internet.

   If there are many VPNs having sites attached to different Autonomous
   Systems, there does not need to be a single ASBR between those two
   ASes which holds all the routes for all the VPNs; there can be
   multiple ASBRs, each of which holds only the routes for a particular
   subset of the VPNs.

   When a PE router distributes a VPN-IPv4 route via BGP, it uses its
   own address as the "BGP next hop".  It also assigns and distributes
   an MPLS label.  (Essentially, PE routers distribute not VPN-IPv4
   routes, but Labeled VPN-IPv4 routes. Cf. [8]) When the PE processes a
   received packet that has this label at the top of the stack, the PE
   will pop the stack, and send the packet directly to the site from to
   which the route leads.  This will usually mean that it just sends the
   packet to the CE router from which it learned the route.  The label
   may also determine the data link encapsulation.

   In most cases, the label assigned by a PE will cause the packet to be
   sent directly to a CE, and the PE which receives the labeled packet
   will not look up the packet's destination address in any forwarding
   table.  However, it is also possible for the PE to assign a label
   which implicitly identifies a particular forwarding table.  In this
   case, the PE receiving a packet that label would look up the packet's
   destination address in one of its forwarding tables.  While this can



Rosen & Rekhter              Informational                     [Page 12]

RFC 2547                     BGP/MPLS VPNs                    March 1999


   be very useful in certain circumstances, we do not consider it
   further in this paper.

   Note that the MPLS label that is distributed in this way is only
   usable if there is a label switched path between the router that
   installs a route and the BGP next hop of that route.  We do not make
   any assumption about the procedure used to set up that label switched
   path.  It may be set up on a pre-established basis, or it may be set
   up when a route which would need it is installed.  It may be a "best
   effort" route, or it may be a traffic engineered route.  Between a
   particular PE router and its BGP next hop for a particular route
   there may be one LSP, or there may be several, perhaps with different
   QoS characteristics.  All that matters for the VPN architecture is
   that some label switched path between the router and its BGP next hop
   exists.

   All the usual techniques for using route reflectors [2] to improve
   scalability, e.g., route reflector hierarchies, are available.  If
   route reflectors are used, there is no need to have any one route
   reflector know all the VPN-IPv4 routes for all the VPNs supported by
   the backbone.  One can have separate route reflectors, which do not
   communicate with each other, each of which supports a subset of the
   total set of VPNs.

   If a given PE router is not attached to any of the Target VPNs of a
   particular route, it should not receive that route; the other PE or
   route reflector which is distributing routes to it should apply
   outbound filtering to avoid sending it unnecessary routes.  Of
   course, if a PE router receives a route via BGP, and that PE is not
   attached to any of the route's target VPNs, the PE should apply
   inbound filtering to the route, neither installing nor redistributing
   it.

   A router which is not attached to any VPN, i.e., a P router, never
   installs any VPN-IPv4 routes at all.

   These distribution rules ensure that there is no one box which needs
   to know all the VPN-IPv4 routes that are supported over the backbone.
   As a result, the total number of such routes that can be supported
   over the backbone is not bound by the capacity of any single device,
   and therefore can increase virtually without bound.

4.2.3. The VPN of Origin Attribute

   A VPN-IPv4 route may be optionally associated with a VPN of Origin
   attribute.  This attribute uniquely identifies a set of sites, and
   identifies the corresponding route as having come from one of the
   sites in that set.  Typical uses of this attribute might be to



Rosen & Rekhter              Informational                     [Page 13]

RFC 2547                     BGP/MPLS VPNs                    March 1999


   identify the enterprise which owns the site where the route leads, or
   to identify the site's intranet.  However, other uses are also
   possible.  This attribute could be encoded as an extended BGP
   communities attribute.

   In situations in which it is necessary to identify the source of a
   route, it is this attribute, not the RD, which must be used.  This
   attribute may be used when "constructing" VPNs, as described below.

   It might be more accurate, if less suggestive, to call this attribute
   the "Route Origin" attribute instead of the "VPN of Origin"
   attribute.  It really identifies the route only has having come from
   one of a particular set of sites, without prejudice as to whether
   that particular set of sites really constitutes a VPN.

4.2.4. Building VPNs using Target and Origin Attributes

   By setting up the Target VPN and VPN of Origin attributes properly,
   one can construct different kinds of VPNs.

   Suppose it is desired to create a Closed User Group (CUG) which
   contains a particular set of sites. This can be done by creating a
   particular Target VPN attribute value to represent the CUG. This
   value then needs to be associated with the per-site forwarding tables
   for each site in the CUG, and it needs to be associated with every
   route learned from a site in the CUG.  Any route which has this
   Target VPN attribute will need to be redistributed so that it reaches
   every PE router attached to one of the sites in the CUG.

   Alternatively, suppose one desired, for whatever reason, to create a
   "hub and spoke" kind of VPN.  This could be done by the use of two
   Target Attribute values, one meaning "Hub" and one meaning "Spoke".
   Then routes from the spokes could be distributed to the hub, without
   causing routes from the hub to be distributed to the spokes.

   Suppose one has a number of sites which are in an intranet and an
   extranet, as well as a number of sites which are in the intranet
   only.  Then there may be both intranet and extranet routes which have
   a Target VPN identifying the entire set of sites.  The sites which
   are to have intranet routes only can filter out all routes with the
   "wrong" VPN of Origin.

   These two attributes allow great flexibility in allowing one to
   control the distribution of routing information among various sets of
   sites, which in turn provides great flexibility in constructing VPNs.






Rosen & Rekhter              Informational                     [Page 14]

RFC 2547                     BGP/MPLS VPNs                    March 1999


5. Forwarding Across the Backbone

   If the intermediate routes in the backbone do not have any
   information about the routes to the VPNs, how are packets forwarded
   from one VPN site to another?

   This is done by means of MPLS with a two-level label stack.

   PE routers (and ASBRs which redistribute VPN-IPv4 addresses) need to
   insert /32 address prefixes for themselves into the IGP routing
   tables of the backbone.  This enables MPLS, at each node in the
   backbone network, to assign a label corresponding to the route to
   each PE router.  (Certain procedures for setting up label switched
   paths in the backbone may not require the presence of the /32 address
   prefixes.)

   When a PE receives a packet from a CE device, it chooses a particular
   per-site forwarding table in which to look up the packet's
   destination address.  Assume that a match is found.

   If the packet is destined for a CE device attached to this same PE,
   the packet is sent directly to that CE device.

   If the packet is not destined for a CE device attached to this same
   PE, the packet's "BGP Next Hop" is found, as well as the label which
   that BGP next hop assigned for the packet's destination address. This
   label is pushed onto the packet's label stack, and becomes the bottom
   label.  Then the PE looks up the IGP route to the BGP Next Hop, and
   thus determines the IGP next hop, as well as the label assigned to
   the address of the BGP next hop by the IGP next hop.  This label gets
   pushed on as the packet's top label, and the packet is then forwarded
   to the IGP next hop.  (If the BGP next hop is the same as the IGP
   next hop, the second label may not need to be pushed on, however.)

   At this point, MPLS will carry the packet across the backbone and
   into the appropriate CE device.  That is, all forwarding decisions by
   P routers and PE routers are now made by means of MPLS, and the
   packet's IP header is not looked at again until the packet reaches
   the CE device.  The final PE router will pop the last label from the
   MPLS label stack before sending the packet to the CE device, thus the
   CE device will just see an ordinary IP packet.  (Though see section 8
   for some discussion of the case where the CE desires to received
   labeled packets.)

   When a packet enters the backbone from a particular site via a
   particular PE router, the packet's route is determined by the
   contents of the forwarding table which that PE router associated with
   that site.  The forwarding tables of the PE router where the packet



Rosen & Rekhter              Informational                     [Page 15]