rfc2547.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

RFC 2547                     BGP/MPLS VPNs                    March 1999


   leaves the backbone are not relevant.  As a result, one may have
   multiple routes to the same system, where the particular route chosen
   for a particular packet is based on the site from which the packet
   enters the backbone.

   Note that it is the two-level labeling that makes it possible to keep
   all the VPN routes out of the P routers, and this in turn is crucial
   to ensuring the scalability of the model.  The backbone does not even
   need to have routes to the CEs, only to the PEs.

6. How PEs Learn Routes from CEs

   The PE routers which attach to a particular VPN need to know, for
   each of that VPN's sites, which addresses in that VPN are at each
   site.

   In the case where the CE device is a host or a switch, this set of
   addresses will generally be configured into the PE router attaching
   to that device.  In the case where the CE device is a router, there
   are a number of possible ways that a PE router can obtain this set of
   addresses.

   The PE translates these addresses into VPN-IPv4 addresses, using a
   configured RD.  The PE then treats these VPN-IPv4 routes as input to
   BGP.  In no case will routes from a site ever be leaked into the
   backbone's IGP.

   Exactly which PE/CE route distribution techniques are possible
   depends on whether a particular CE is in a "transit VPN" or not.  A
   "transit VPN" is one which contains a router that receives routes
   from a "third party" (i.e., from a router which is not in the VPN,
   but is not a PE router), and that redistributes those routes to a PE
   router.  A VPN which is not a transit VPN is a "stub VPN".  The vast
   majority of VPNs, including just about all corporate enterprise
   networks, would be expected to be "stubs" in this sense.

   The possible PE/CE distribution techniques are:

      1. Static routing (i.e., configuration) may be used. (This is
         likely to be useful only in stub VPNs.)

      2. PE and CE routers may be RIP peers, and the CE may use RIP to
         tell the PE router the set of address prefixes which are
         reachable at the CE router's site.  When RIP is configured in
         the CE, care must be taken to ensure that address prefixes from
         other sites (i.e., address prefixes learned by the CE router
         from the PE router) are never advertised to the PE.  More
         precisely: if a PE router, say PE1, receives a VPN-IPv4 route



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


         R1, and as a result distributes an IPv4 route R2 to a CE, then
         R2 must not be distributed back from that CE's site to a PE
         router, say PE2, (where PE1 and PE2 may be the same router or
         different routers), unless PE2 maps R2 to a VPN-IPv4 route
         which is different than (i.e., contains a different RD than)
         R1.

      3. The PE and CE routers may be OSPF peers.  In this case, the
         site should be a single OSPF area, the CE should be an ABR in
         that area, and the PE should be an ABR which is not in that
         area.  Also, the PE should report no router links other than
         those to the CEs which are at the same site. (This technique
         should be used only in stub VPNs.)

      4. The PE and CE routers may be BGP peers, and the CE router may
         use BGP (in particular, EBGP to tell the PE router the set of
         address prefixes which are at the CE router's site. (This
         technique can be used in stub VPNs or transit VPNs.)

         From a purely technical perspective, this is by far the best
         technique:

              a) Unlike the IGP alternatives, this does not require the
                 PE to run multiple routing algorithm instances in order
                 to talk to multiple CEs

              b) BGP is explicitly designed for just this function:
                 passing routing information between systems run by
                 different administrations

              c) If the site contains "BGP backdoors", i.e., routers
                 with BGP connections to routers other than PE routers,
                 this procedure will work correctly in all
                 circumstances.  The other procedures may or may not
                 work, depending on the precise circumstances.

              d) Use of BGP makes it easy for the CE to pass attributes
                 of the routes to the PE.  For example, the CE may
                 suggest a particular Target for each route, from among
                 the Target attributes that the PE is authorized to
                 attach to the route.

          On the other hand, using BGP is likely to be something new for
          the CE administrators, except in the case where the customer
          itself is already an Internet Service Provider (ISP).






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


          If a site is not in a transit VPN, note that it need not have
          a unique Autonomous System Number (ASN).  Every CE whose site
          which is not in a transit VPN can use the same ASN.  This can
          be chosen from the private ASN space, and it will be stripped
          out by the PE.  Routing loops are prevented by use of the Site
          of Origin Attribute (see below).

          If a set of sites constitute a transit VPN, it is convenient
          to represent them as a BGP Confederation, so that the internal
          structure of the VPN is hidden from any router which is not
          within the VPN.  In this case, each site in the VPN would need
          two BGP connections to the backbone, one which is internal to
          the confederation and one which is external to it.  The usual
          intra-confederation procedures would have to be slightly
          modified in order to take account for the fact that the
          backbone and the sites may have different policies.  The
          backbone is a member of the confederation on one of the
          connections, but is not a member on the other.  These
          techniques may be useful if the customer for the VPN service
          is an ISP.  This technique allows a customer that is an ISP to
          obtain VPN backbone service from one of its ISP peers.

          (However, if a VPN customer is itself an ISP, and its CE
          routers support MPLS, a much simpler technique can be used,
          wherein the ISP is regarded as a stub VPN.  See section 8.)

   When we do not need to distinguish among the different ways in which
   a PE can be informed of the address prefixes which exist at a given
   site, we will simply say that the PE has "learned" the routes from
   that site.

   Before a PE can redistribute a VPN-IPv4 route learned from a site, it
   must assign certain attributes to the route. There are three such
   attributes:

      - Site of Origin

        This attribute uniquely identifies the site from which the PE
        router learned the route.  All routes learned from a particular
        site must be assigned the same Site of Origin attribute, even if
        a site is multiply connected to a single PE, or is connected to
        multiple PEs.  Distinct Site of Origin attributes must be used
        for distinct sites.  This attribute could be encoded as an
        extended BGP communities attribute (section 4.2.1).

      - VPN of Origin

        See section 4.2.1.



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


      - Target VPN

        See section 4.2.1.

7. How CEs learn Routes from PEs

   In this section, we assume that the CE device is a router.

   In general, a PE may distribute to a CE any route which the PE has
   placed in the forwarding table which it uses to route packets from
   that CE.  There is one exception: if a route's Site of Origin
   attribute identifies a particular site, that route must never be
   redistributed to any CE at that site.

   In most cases, however, it will be sufficient for the PE to simply
   distribute the default route to the CE.  (In some cases, it may even
   be sufficient for the CE to be configured with a default route
   pointing to the PE.)  This will generally work at any site which does
   not itself need to distribute the default route to other sites.
   (E.g., if one site in a corporate VPN has the corporation's access to
   the Internet, that site might need to have default distributed to the
   other site, but one could not distribute default to that site
   itself.)

   Whatever procedure is used to distribute routes from CE to PE will
   also be used to distribute routes from PE to CE.

8. What if the CE Supports MPLS?

   In the case where the CE supports MPLS, AND is willing to import the
   complete set of routes from its VPNs, the PE can distribute to it a
   label for each such route.  When the PE receives a packet from the CE
   with such a label, it (a) replaces that label with the corresponding
   label that it learned via BGP, and (b) pushes on a label
   corresponding to the BGP next hop for the corresponding route.

8.1. Virtual Sites

   If the CE/PE route distribution is done via BGP, the CE can use MPLS
   to support multiple virtual sites.  The CE may itself contain a
   separate forwarding table for each virtual site, which it populates
   as indicated by the VPN of Origin and Target VPN attributes of the
   routes it receives from the PE.  If the CE receives the full set of
   routes from the PE, the PE will not need to do any address lookup at
   all on packets received from the CE.  Alternatively, the PE may in
   some cases be able to distribute to the CE a single (labeled) default
   route for each VPN.  Then when the PE receives a labeled packet from




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


   the CE, it would know which forwarding table to look in; the label
   placed on the packet by the CE would identify only the virtual site
   from which the packet is coming.

8.2. Representing an ISP VPN as a Stub VPN

   If a particular VPN is actually an ISP, but its CE routers support
   MPLS, then the VPN can actually be treated as a stub VPN.  The CE and
   PE routers need only exchange routes which are internal to the VPN.
   The PE router would distribute to the CE router a label for each of
   these routes.  Routers at different sites in the VPN can then become
   BGP peers.  When the CE router looks up a packet's destination
   address, the routing lookup always resolves to an internal address,
   usually the address of the packet's BGP next hop.  The CE labels the
   packet appropriately and sends the packet to the PE.

9. Security

   Under the following conditions:

      a) labeled packets are not accepted by backbone routers from
         untrusted or unreliable sources, unless it is known that such
         packets will leave the backbone before the IP header or any
         labels lower in the stack will be inspected, and

      b) labeled VPN-IPv4 routes are not accepted from untrusted or
         unreliable sources,

   the security provided by this architecture is virtually identical to
   that provided to VPNs by Frame Relay or ATM backbones.

   It is worth noting that the use of MPLS makes it much simpler to
   provide this level of security than would be possible if one
   attempted to use some form of IP-within-IP tunneling in place of
   MPLS.  It is a simple matter to refuse to accept a labeled packet
   unless the first of the above conditions applies to it.  It is rather
   more difficult to configure the a router to refuse to accept an IP
   packet if that packet is an IP-within-IP tunnelled packet which is
   going to a "wrong" place.

   The use of MPLS also allows a VPN to span multiple SPs without
   depending in any way on the inter-domain distribution of IPv4 routing
   information.

   It is also possible for a VPN user to provide himself with enhanced
   security by making use of Tunnel Mode IPSEC [5].  This is discussed
   in the remainder of this section.




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