Network Working Group E. Rosen
`Request for Comments: 2547 Y. Rekhter
`Category: Informational Cisco Systems, Inc.
` March 1999
`
` BGP/MPLS VPNs
`
`Status of this Memo
`
` This memo provides information for the Internet community. It does
` not specify an Internet standard of any kind. Distribution of this
` memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (1999). All Rights Reserved.
`
`Abstract
`
` This document describes a method by which a Service Provider with an
` IP backbone may provide VPNs (Virtual Private Networks) for its
` customers. MPLS (Multiprotocol Label Switching) is used for
` forwarding packets over the backbone, and BGP (Border Gateway
` Protocol) is used for distributing routes over the backbone. The
` primary goal of this method is to support the outsourcing of IP
` backbone services for enterprise networks. It does so in a manner
` which is simple for the enterprise, while still scalable and flexible
` for the Service Provider, and while allowing the Service Provider to
` add value. These techniques can also be used to provide a VPN which
` itself provides IP service to customers.
`
`Table of Contents
`
` 1 Introduction ....................................... 2
` 1.1 Virtual Private Networks ........................... 2
` 1.2 Edge Devices ....................................... 3
` 1.3 VPNs with Overlapping Address Spaces ............... 4
` 1.4 VPNs with Different Routes to the Same System ...... 4
` 1.5 Multiple Forwarding Tables in PEs .................. 5
` 1.6 SP Backbone Routers ................................ 5
` 1.7 Security ........................................... 5
` 2 Sites and CEs ...................................... 6
` 3 Per-Site Forwarding Tables in the PEs .............. 6
` 3.1 Virtual Sites ...................................... 8
` 4 VPN Route Distribution via BGP ..................... 8
` 4.1 The VPN-IPv4 Address Family ........................ 9
` 4.2 Controlling Route Distribution ..................... 10
`
`Rosen & Rekhter Informational [Page 1]
`
`Petitioner Apple Inc. - Ex. 1037, p. 1
`
`

`

`
`RFC 2547 BGP/MPLS VPNs March 1999
`
` 4.2.1 The Target VPN Attribute ........................... 10
` 4.2.2 Route Distribution Among PEs by BGP ................ 12
` 4.2.3 The VPN of Origin Attribute ........................ 13
` 4.2.4 Building VPNs using Target and Origin Attributes ... 14
` 5 Forwarding Across the Backbone ..................... 15
` 6 How PEs Learn Routes from CEs ...................... 16
` 7 How CEs learn Routes from PEs ...................... 19
` 8 What if the CE Supports MPLS? ...................... 19
` 8.1 Virtual Sites ...................................... 19
` 8.2 Representing an ISP VPN as a Stub VPN .............. 20
` 9 Security ........................................... 20
` 9.1 Point-to-Point Security Tunnels between CE Routers . 21
` 9.2 Multi-Party Security Associations .................. 21
` 10 Quality of Service ................................. 22
` 11 Scalability ........................................ 22
` 12 Intellectual Property Considerations ............... 23
` 13 Security Considerations ............................ 23
` 14 Acknowledgments .................................... 23
` 15 Authors’ Addresses ................................. 24
` 16 References ......................................... 24
` 17 Full Copyright Statement............................. 25
`
`1. Introduction
`
`1.1. Virtual Private Networks
`
` Consider a set of "sites" which are attached to a common network
` which we may call the "backbone". Let’s apply some policy to create a
` number of subsets of that set, and let’s impose the following rule:
` two sites may have IP interconnectivity over that backbone only if at
` least one of these subsets contains them both.
`
` The subsets we have created are "Virtual Private Networks" (VPNs).
` Two sites have IP connectivity over the common backbone only if there
` is some VPN which contains them both. Two sites which have no VPN in
` common have no connectivity over that backbone.
`
` If all the sites in a VPN are owned by the same enterprise, the VPN
` is a corporate "intranet". If the various sites in a VPN are owned
` by different enterprises, the VPN is an "extranet". A site can be in
` more than one VPN; e.g., in an intranet and several extranets. We
` regard both intranets and extranets as VPNs. In general, when we use
` the term VPN we will not be distinguishing between intranets and
` extranets.
`
` We wish to consider the case in which the backbone is owned and
` operated by one or more Service Providers (SPs). The owners of the
` sites are the "customers" of the SPs. The policies that determine
`
`Rosen & Rekhter Informational [Page 2]
`
`Petitioner Apple Inc. - Ex. 1037, p. 2
`
`

`

`
`RFC 2547 BGP/MPLS VPNs March 1999
`
` whether a particular collection of sites is a VPN are the policies of
` the customers. Some customers will want the implementation of these
` policies to be entirely the responsibility of the SP. Other
` customers may want to implement these policies themselves, or to
` share with the SP the responsibility for implementing these policies.
` In this document, we are primarily discussing mechanisms that may be
` used to implement these policies. The mechanisms we describe are
` general enough to allow these policies to be implemented either by
` the SP alone, or by a VPN customer together with the SP. Most of the
` discussion is focused on the former case, however.
`
` The mechanisms discussed in this document allow the implementation of
` a wide range of policies. For example, within a given VPN, we can
` allow every site to have a direct route to every other site ("full
` mesh"), or we can restrict certain pairs of sites from having direct
` routes to each other ("partial mesh").
`
` In this document, we are particularly interested in the case where
` the common backbone offers an IP service. We are primarily concerned
` with the case in which an enterprise is outsourcing its backbone to a
` service provider, or perhaps to a set of service providers, with
` which it maintains contractual relationships. We are not focused on
` providing VPNs over the public Internet.
`
` In the rest of this introduction, we specify some properties which
` VPNs should have. The remainder of this document outlines a VPN
` model which has all these properties. The VPN Model of this document
` appears to be an instance of the framework described in [4].
`
`1.2. Edge Devices
`
` We suppose that at each site, there are one or more Customer Edge
` (CE) devices, each of which is attached via some sort of data link
` (e.g., PPP, ATM, ethernet, Frame Relay, GRE tunnel, etc.) to one or
` more Provider Edge (PE) routers.
`
` If a particular site has a single host, that host may be the CE
` device. If a particular site has a single subnet, that the CE device
` may be a switch. In general, the CE device can be expected to be a
` router, which we call the CE router.
`
` We will say that a PE router is attached to a particular VPN if it is
` attached to a CE device which is in that VPN. Similarly, we will say
` that a PE router is attached to a particular site if it is attached
` to a CE device which is in that site.
`
` When the CE device is a router, it is a routing peer of the PE(s) to
` which it is attached, but is not a routing peer of CE routers at
`
`Rosen & Rekhter Informational [Page 3]
`
`Petitioner Apple Inc. - Ex. 1037, p. 3
`
`

`

`
`RFC 2547 BGP/MPLS VPNs March 1999
`
` other sites. Routers at different sites do not directly exchange
` routing information with each other; in fact, they do not even need
` to know of each other at all (except in the case where this is
` necessary for security purposes, see section 9). As a consequence,
` very large VPNs (i.e., VPNs with a very large number of sites) are
` easily supported, while the routing strategy for each individual site
` is greatly simplified.
`
` It is important to maintain clear administrative boundaries between
` the SP and its customers (cf. [4]). The PE and P routers should be
` administered solely by the SP, and the SP’s customers should not have
` any management access to it. The CE devices should be administered
` solely by the customer (unless the customer has contracted the
` management services out to the SP).
`
`1.3. VPNs with Overlapping Address Spaces
`
` We assume that any two non-intersecting VPNs (i.e., VPNs with no
` sites in common) may have overlapping address spaces; the same
` address may be reused, for different systems, in different VPNs. As
` long as a given endsystem has an address which is unique within the
` scope of the VPNs that it belongs to, the endsystem itself does not
` need to know anything about VPNs.
`
` In this model, the VPN owners do not have a backbone to administer,
` not even a "virtual backbone". Nor do the SPs have to administer a
` separate backbone or "virtual backbone" for each VPN. Site-to-site
` routing in the backbone is optimal (within the constraints of the
` policies used to form the VPNs), and is not constrained in any way by
` an artificial "virtual topology" of tunnels.
`
`1.4. VPNs with Different Routes to the Same System
`
` Although a site may be in multiple VPNs, it is not necessarily the
` case that the route to a given system at that site should be the same
` in all the VPNs. Suppose, for example, we have an intranet
` consisting of sites A, B, and C, and an extranet consisting of A, B,
` C, and the "foreign" site D. Suppose that at site A there is a
` server, and we want clients from B, C, or D to be able to use that
` server. Suppose also that at site B there is a firewall. We want
` all the traffic from site D to the server to pass through the
` firewall, so that traffic from the extranet can be access controlled.
` However, we don’t want traffic from C to pass through the firewall on
` the way to the server, since this is intranet traffic.
`
` This means that it needs to be possible to set up two routes to the
` server. One route, used by sites B and C, takes the traffic directly
` to site A. The second route, used by site D, takes the traffic
`
`Rosen & Rekhter Informational [Page 4]
`
`Petitioner Apple Inc. - Ex. 1037, p. 4
`
`

`

`
`RFC 2547 BGP/MPLS VPNs March 1999
`
` instead to the firewall at site B. If the firewall allows the
` traffic to pass, it then appears to be traffic coming from site B,
` and follows the route to site A.
`
`1.5. Multiple Forwarding Tables in PEs
`
` Each PE router needs to maintain a number of separate forwarding
` tables. Every site to which the PE is attached must be mapped to one
` of those forwarding tables. When a packet is received from a
` particular site, the forwarding table associated with that site is
` consulted in order to determine how to route the packet. The
` forwarding table associated with a particular site S is populated
` only with routes that lead to other sites which have at least one VPN
` in common with S. This prevents communication between sites which
` have no VPN in common, and it allows two VPNs with no site in common
` to use address spaces that overlap with each other.
`
`1.6. SP Backbone Routers
`
` The SP’s backbone consists of the PE routers, as well as other
` routers (P routers) which do not attach to CE devices.
`
` If every router in an SP’s backbone had to maintain routing
` information for all the VPNs supported by the SP, this model would
` have severe scalability problems; the number of sites that could be
` supported would be limited by the amount of routing information that
` could be held in a single router. It is important to require
` therefore that the routing information about a particular VPN be
` present ONLY in those PE routers which attach to that VPN. In
` particular, the P routers should not need to have ANY per-VPN routing
` information whatsoever.
`
` VPNs may span multiple service providers. We assume though that when
` the path between PE routers crosses a boundary between SP networks,
` it does so via a private peering arrangement, at which there exists
` mutual trust between the two providers. In particular, each provider
` must trust the other to pass it only correct routing information, and
` to pass it labeled (in the sense of MPLS [9]) packets only if those
` packets have been labeled by trusted sources. We also assume that it
` is possible for label switched paths to cross the boundary between
` service providers.
`
`1.7. Security
`
` A VPN model should, even without the use of cryptographic security
` measures, provide a level of security equivalent to that obtainable
` when a level 2 backbone (e.g., Frame Relay) is used. That is, in the
` absence of misconfiguration or deliberate interconnection of
`
`Rosen & Rekhter Informational [Page 5]
`
`Petitioner Apple Inc. - Ex. 1037, p. 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]
`
`Petitioner Apple Inc. - Ex. 1037, p. 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]
`
`Petitioner Apple Inc. - Ex. 1037, p. 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]
`
`Petitioner Apple Inc. - Ex. 1037, p. 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]
`
`Petitioner Apple Inc. - Ex. 1037, p. 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]
`
`Petitioner Apple Inc. - Ex. 1037, p. 10
`
`

`

`
`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]
`
`Petitioner Apple Inc. - Ex. 1037, p. 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 no