rfc2547.txt

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

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


   different VPNs, it should not be possible for systems in one VPN to
   gain access to systems in another VPN.

   It should also be possible to deploy standard security procedures.

2. Sites and CEs

   From the perspective of a particular backbone network, a set of IP
   systems constitutes a site if those systems have mutual IP
   interconnectivity, and communication between them occurs without use
   of the backbone. In general, a site will consist of a set of systems
   which are in geographic proximity.  However, this is not universally
   true; two geographic locations connected via a leased line, over
   which OSPF is running, will constitute a single site, because
   communication between the two locations does not involve the use of
   the backbone.

   A CE device is always regarded as being in a single site (though as
   we shall see, a site may consist of multiple "virtual sites"). A
   site, however, may belong to multiple VPNs.

   A PE router may attach to CE devices in any number of different
   sites, whether those CE devices are in the same or in different VPNs.
   A CE device may, for robustness, attach to multiple PE routers, of
   the same or of different service providers.  If the CE device is a
   router, the PE router and the CE router will appear as router
   adjacencies to each other.

   While the basic unit of interconnection is the site, the architecture
   described herein allows a finer degree of granularity in the control
   of interconnectivity. For example, certain systems at a site may be
   members of an intranet as well as members of one or more extranets,
   while other systems at the same site may be restricted to being
   members of the intranet only.

3. Per-Site Forwarding Tables in the PEs

   Each PE router maintains one or more "per-site forwarding tables".
   Every site to which the PE router is attached is associated with one
   of these tables.  A particular packet's IP destination address is
   looked up in a particular per-site forwarding table only if that
   packet has arrived directly from a site which is associated with that
   table.

   How are the per-site forwarding tables populated?






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


   As an example, let PE1, PE2, and PE3 be three PE routers, and let
   CE1, CE2, and CE3 be three CE routers. Suppose that PE1 learns, from
   CE1, the routes which are reachable at CE1's site.  If PE2 and PE3
   are attached respectively to CE2 and CE3, and there is some VPN V
   containing CE1, CE2, and CE3, then PE1 uses BGP to distribute to PE2
   and PE3 the routes which it has learned from CE1.  PE2 and PE3 use
   these routes to populate the forwarding tables which they associate
   respectively with the sites of CE2 and CE3.  Routes from sites which
   are not in VPN V do not appear in these forwarding tables, which
   means that packets from CE2 or CE3 cannot be sent to sites which are
   not in VPN V.

   If a site is in multiple VPNs, the forwarding table associated with
   that site can contain routes from the full set of VPNs of which the
   site is a member.

   A PE generally maintains only one forwarding table per site, even if
   it is multiply connected to that site.  Also, different sites can
   share the same forwarding table if they are meant to use exactly the
   same set of routes.

   Suppose a packet is received by a PE router from a particular
   directly attached site, but the packet's destination address does not
   match any entry in the forwarding table associated with that site.
   If the SP is not providing Internet access for that site, then the
   packet is discarded as undeliverable.  If the SP is providing
   Internet access for that site, then the PE's Internet forwarding
   table will be consulted.  This means that in general, only one
   forwarding table per PE need ever contain routes from the Internet,
   even if Internet access is provided.

   To maintain proper isolation of one VPN from another, it is important
   that no router in the backbone accept a labeled packet from any
   adjacent non-backbone device unless (a) the label at the top of the
   label stack was actually distributed by the backbone router to the
   non-backbone device, and (b) the backbone router can determine that
   use of that label will cause the packet to leave the backbone before
   any labels lower in the stack will be inspected, and before the IP
   header will be inspected.  These restrictions are necessary in order
   to prevent packets from entering a VPN where they do not belong.

   The per-site forwarding tables in a PE are ONLY used for packets
   which arrive from a site which is directly attached to the PE.  They
   are not used for routing packets which arrive from other routers that
   belong to the SP backbone.  As a result, there may be multiple
   different routes to the same system, where the route followed by a
   given packet is determined by the site from which the packet enters
   the backbone.  E.g., one may have one route to a given system for



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


   packets from the extranet (where the route leads to a firewall), and
   a different route to the same system for packets from the intranet
   (including packets that have already passed through the firewall).

3.1. Virtual Sites

   In some cases, a particular site may be divided by the customer into
   several virtual sites, perhaps by the use of VLANs.  Each virtual
   site may be a member of a different set of VPNs. The PE then needs to
   contain a separate forwarding table for each virtual site.  For
   example, if a CE supports VLANs, and wants each VLAN mapped to a
   separate VPN, the packets sent between CE and PE could be contained
   in the site's VLAN encapsulation, and this could be used by the PE,
   along with the interface over which the packet is received, to assign
   the packet to a particular virtual site.

   Alternatively, one could divide the interface into multiple "sub-
   interfaces" (particularly if the interface is Frame Relay or ATM),
   and assign the packet to a VPN based on the sub-interface over which
   it arrives.  Or one could simply use a different interface for each
   virtual site.  In any case, only one CE router is ever needed per
   site, even if there are multiple virtual sites.  Of course, a
   different CE router could be used for each virtual site, if that is
   desired.

   Note that in all these cases, the mechanisms, as well as the policy,
   for controlling which traffic is in which VPN are in the hand of the
   customer.

   If it is desired to have a particular host be in multiple virtual
   sites, then that host must determine, for each packet, which virtual
   site the packet is associated with.  It can do this, e.g., by sending
   packets from different virtual sites on different VLANs, our out
   different network interfaces.

   These schemes do NOT require the CE to support MPLS.  Section 8
   contains a brief discussion of how the CE might support multiple
   virtual sites if it does support MPLS.

4. VPN Route Distribution via BGP

   PE routers use BGP to distribute VPN routes to each other (more
   accurately, to cause VPN routes to be distributed to each other).

   A BGP speaker can only install and distribute one route to a given
   address prefix.  Yet we allow each VPN to have its own address space,
   which means that the same address can be used in any number of VPNs,
   where in each VPN the address denotes a different system.  It follows



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


   that we need to allow BGP to install and distribute multiple routes
   to a single IP address prefix.  Further, we must ensure that POLICY
   is used to determine which sites can be use which routes; given that
   several such routes are installed by BGP, only one such must appear
   in any particular per-site forwarding table.

   We meet these goals by the use of a new address family, as specified
   below.

4.1. The VPN-IPv4 Address Family

   The BGP Multiprotocol Extensions [3] allow BGP to carry routes from
   multiple "address families".  We introduce the notion of the "VPN-
   IPv4 address family".  A VPN-IPv4 address is a 12-byte quantity,
   beginning with an 8-byte "Route Distinguisher (RD)" and ending with a
   4-byte IPv4 address.  If two VPNs use the same IPv4 address prefix,
   the PEs translate these into unique VPN-IPv4 address prefixes.  This
   ensures that if the same address is used in two different VPNs, it is
   possible to install two completely different routes to that address,
   one for each VPN.

   The RD does not by itself impose any semantics; it contains no
   information about the origin of the route or about the set of VPNs to
   which the route is to be distributed.  The purpose of the RD is
   solely to allow one to create distinct routes to a common IPv4
   address prefix.  Other means are used to determine where to
   redistribute the route (see section 4.2).

   The RD can also be used to create multiple different routes to the
   very same system.  In section 3, we gave an example where the route
   to a particular server had to be different for intranet traffic than
   for extranet traffic.  This can be achieved by creating two different
   VPN-IPv4 routes that have the same IPv4 part, but different RDs.
   This allows BGP to install multiple different routes to the same
   system, and allows policy to be used (see section 4.2.3) to decide
   which packets use which route.

   The RDs are structured so that every service provider can administer
   its own "numbering space" (i.e., can make its own assignments of
   RDs), without conflicting with the RD assignments made by any other
   service provider.  An RD consists of a two-byte type field, an
   administrator field, and an assigned number field.  The value of the
   type field determines the lengths of the other two fields, as well as
   the semantics of the administrator field.  The administrator field
   identifies an assigned number authority, and the assigned number
   field contains a number which has been assigned, by the identified
   authority, for a particular purpose.  For example, one could have an
   RD whose administrator field contains an Autonomous System number



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


   (ASN), and whose (4-byte) number field contains a number assigned by
   the SP to whom IANA has assigned that ASN.  RDs are given this
   structure in order to ensure that an SP which provides VPN backbone
   service can always create a unique RD when it needs to do so.
   However, the structuring provides no semantics. When BGP compares two
   such address prefixes, it ignores the structure entirely.

   If the Administrator subfield and the Assigned Number subfield of a
   VPN-IPv4 address are both set to all zeroes, the VPN-IPv4 address is
   considered to have exactly the same meaning as the corresponding
   globally unique IPv4 address. In particular, this VPN-IPv4 address
   and the corresponding globally unique IPv4 address will be considered
   comparable by BGP. In all other cases, a VPN-IPv4 address and its
   corresponding globally unique IPv4 address will be considered
   noncomparable by BGP.

   A given per-site forwarding table will only have one VPN-IPv4 route
   for any given IPv4 address prefix.  When a packet's destination
   address is matched against a VPN-IPv4 route, only the IPv4 part is
   actually matched.

   A PE needs to be configured to associate routes which lead to
   particular CE with a particular RD.  The PE may be configured to
   associate all routes leading to the same CE with the same RD, or it
   may be configured to associate different routes with different RDs,
   even if they lead to the same CE.

4.2. Controlling Route Distribution

   In this section, we discuss the way in which the distribution of the
   VPN-IPv4 routes is controlled.

4.2.1. The Target VPN Attribute

   Every per-site forwarding table is associated with one or more
   "Target VPN" attributes.

   When a VPN-IPv4 route is created by a PE router, it is associated
   with one or more "Target VPN" attributes.  These are carried in BGP
   as attributes of the route.

   Any route associated with Target VPN T must be distributed to every
   PE router that has a forwarding table associated with Target VPN T.
   When such a route is received by a PE router, it is eligible to be
   installed in each of the PE's per-site forwarding tables that is
   associated with Target VPN T. (Whether it actually gets installed
   depends on the outcome of the BGP decision process.)




Rosen & Rekhter              Informational                     [Page 10]