< draft-ietf-l3vpn-rfc2547bis   rfc4364.txt 
Network Working Group Eric C. Rosen Network Working Group E. Rosen
Internet Draft Cisco Systems, Inc. Request for Comments: 4364 Cisco Systems, Inc.
Expiration Date: April 2005 Obsoletes: 2547 Y. Rekhter
Yakov Rekhter Category: Standards Track Juniper Networks, Inc.
Juniper Networks, Inc. February 2006
October 2004
BGP/MPLS IP VPNs
draft-ietf-l3vpn-rfc2547bis-03.txt
Status of this Memo
By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been disclosed,
or will be disclosed, and any of which we become aware will be
disclosed, in accordance with RFC 3668.
This document is an Internet-Draft and is subject to all provisions BGP/MPLS IP Virtual Private Networks (VPNs)
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
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 This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2006).
http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes a method by which a Service Provider may use This document describes a method by which a Service Provider may use
an IP backbone to provide IP VPNs (Virtual Private Networks) for its an IP backbone to provide IP Virtual Private Networks (VPNs) for its
customers. This method uses a "peer model", in which the customers' customers. This method uses a "peer model", in which the customers'
edge routers ("CE routers") send their routes to the Service edge routers (CE routers) send their routes to the Service Provider's
Provider's edge routers ("PE routers"); there is no "overlay" visible edge routers (PE routers); there is no "overlay" visible to the
to the customer's routing algorithm, and CE routers at different customer's routing algorithm, and CE routers at different sites do
sites do not peer with each other. Data packets are tunneled through not peer with each other. Data packets are tunneled through the
the backbone, so that the core routers do not need to know the VPN backbone, so that the core routers do not need to know the VPN
routes. routes.
This document obsoletes RFC 2547. This document obsoletes RFC 2547.
Table of Contents Table of Contents
1 Introduction ....................................... 4 1. Introduction ....................................................3
1.1 Virtual Private Networks ........................... 5 1.1. Virtual Private Networks ...................................4
1.2 Customer Edge and Provider Edge .................... 6 1.2. Customer Edge and Provider Edge ............................5
1.3 VPNs with Overlapping Address Spaces ............... 8 1.3. VPNs with Overlapping Address Spaces .......................6
1.4 VPNs with Different Routes to the Same System ...... 8 1.4. VPNs with Different Routes to the Same System ..............7
1.5 SP Backbone Routers ................................ 8 1.5. SP Backbone Routers ........................................7
1.6 Security ........................................... 9 1.6. Security ...................................................8
2 Sites and CEs ...................................... 9 2. Sites and CEs ...................................................8
3 VRFs: Multiple Forwarding Tables in PEs ............ 10 3. VRFs: Multiple Forwarding Tables in PEs .........................9
3.1 VRFs and Attachment Circuits ....................... 10 3.1. VRFs and Attachment Circuits ...............................9
3.2 Associating IP Packets with VRFs ................... 12 3.2. Associating IP Packets with VRFs ..........................10
3.3 Populating the VRFs ................................ 13 3.3. Populating the VRFs .......................................11
4 VPN Route Distribution via BGP ..................... 14 4. VPN Route Distribution via BGP .................................12
4.1 The VPN-IPv4 Address Family ........................ 14 4.1. The VPN-IPv4 Address Family ...............................13
4.2 Encoding of Route Distinguishers ................... 15 4.2. Encoding of Route Distinguishers ..........................14
4.3 Controlling Route Distribution ..................... 16 4.3. Controlling Route Distribution ............................15
4.3.1 The Route Target Attribute ......................... 17 4.3.1. The Route Target Attribute .........................15
4.3.2 Route Distribution Among PEs by BGP ................ 19 4.3.2. Route Distribution Among PEs by BGP ................17
4.3.3 Use of Route Reflectors ............................ 21 4.3.3. Use of Route Reflectors ............................20
4.3.4 How VPN-IPv4 NLRI is Carried in BGP ................ 24 4.3.4. How VPN-IPv4 NLRI Is Carried in BGP ................22
4.3.5 Building VPNs using Route Targets .................. 24 4.3.5. Building VPNs Using Route Targets ..................23
4.3.6 Route Distribution Among VRFs in a Single PE ....... 25 4.3.6. Route Distribution Among VRFs in a Single PE .......23
5 Forwarding ......................................... 25 5. Forwarding .....................................................23
6 Maintaining Proper Isolation of VPNs ............... 28 6. Maintaining Proper Isolation of VPNs ...........................26
7 How PEs Learn Routes from CEs ...................... 29 7. How PEs Learn Routes from CEs ..................................27
8 How CEs learn Routes from PEs ...................... 32 8. How CEs Learn Routes from PEs ..................................30
9 Carriers' Carriers ................................. 32 9. Carriers' Carriers .............................................30
10 Multi-AS Backbones ................................. 34 10. Multi-AS Backbones ............................................32
11 Accessing the Internet from a VPN .................. 36 11. Accessing the Internet from a VPN .............................34
12 Management VPNs .................................... 38 12. Management VPNs ...............................................36
13 Security Considerations ............................ 39 13. Security Considerations .......................................37
13.1 Data Plane ......................................... 39 13.1. Data Plane ...............................................37
13.2 Control Plane ...................................... 41 13.2. Control Plane ............................................39
13.3 Security of P and PE devices ....................... 41 13.3. Security of P and PE Devices .............................39
14 Quality of Service ................................. 41 14. Quality of Service ............................................39
15 Scalability ........................................ 42 15. Scalability ...................................................40
16 IANA Considerations ................................ 42 16. IANA Considerations ...........................................40
17 Acknowledgments .................................... 43 17. Acknowledgements ..............................................41
18 Authors' Addresses ................................. 43 18. Contributors ..................................................41
19 Contributors ....................................... 44 19. Normative References ..........................................44
20 Normative References ............................... 46 20. Informative References ........................................45
21 Informational References ........................... 47
22 Intellectual Property Statement .................... 48
23 Full Copyright Statement ........................... 49
1. Introduction 1. Introduction
This document describes a method by which a Service Provider may use This document describes a method by which a Service Provider may use
an IP backbone to provide IP VPNs (Virtual Private Networks) for its an IP backbone to provide IP Virtual Private Networks (VPNs) for its
customers. This method uses a "peer model", in which the customers' customers. This method uses a "peer model", in which the customers'
edge routers ("CE routers") send their routes to the Service edge routers (CE routers) send their routes to the Service Provider's
Provider's edge routers ("PE routers"). BGP ("Border Gateway edge routers (PE routers). Border Gateway Protocol (BGP)
Protocol", [BGP,BGP-MP]) is then used by the Service Provider to [BGP, BGP-MP] is then used by the Service Provider to exchange the
exchange the routes of a particular VPN among the PE routers that are routes of a particular VPN among the PE routers that are attached to
attached to that VPN. This is done in a way which ensures that that VPN. This is done in a way that ensures that routes from
routes from different VPNs remain distinct and separate, even if two different VPNs remain distinct and separate, even if two VPNs have an
VPNs have an overlapping address space. The PE routers distribute, overlapping address space. The PE routers distribute, to the CE
to the CE routers in a particular VPN, the routes from other the CE routers in a particular VPN, the routes from other the CE routers in
routers in that VPN. The CE routers do not peer with each other, that VPN. The CE routers do not peer with each other, hence there is
hence there is no "overlay" visible to the VPN's routing algorithm. no "overlay" visible to the VPN's routing algorithm. The term "IP"
The term "IP" in "IP VPN" is used to indicate that the PE receives IP in "IP VPN" is used to indicate that the PE receives IP datagrams
datagrams from the CE, examines their IP headers, and routes them from the CE, examines their IP headers, and routes them accordingly.
accordingly.
Each route within a VPN is assigned an MPLS ("Multiprotocol Label Each route within a VPN is assigned a Multiprotocol Label Switching
Switching", [MPLS-ARCH, MPLS-BGP, MPLS-ENCAPS]) label; when BGP (MPLS) [MPLS-ARCH, MPLS-BGP, MPLS-ENCAPS] label; when BGP distributes
distributes a VPN route, it also distributes an MPLS label for that a VPN route, it also distributes an MPLS label for that route.
route. Before a customer data packet travels across the Service Before a customer data packet travels across the Service Provider's
Provider's backbone, it is encapsulated with the MPLS label that backbone, it is encapsulated with the MPLS label that corresponds, in
corresponds, in the customer's VPN, to the route that is the best the customer's VPN, to the route that is the best match to the
match to the packet's destination address. This MPLS packet is packet's destination address. This MPLS packet is further
further encapsulated (e.g., with another MPLS label, or with an IP or encapsulated (e.g., with another MPLS label or with an IP or Generic
GRE ("Generic Routing Encapsulation" tunnel header [MPLS-in-IP-GRE]) Routing Encapsulation (GRE) tunnel header [MPLS-in-IP-GRE]) so that
so that it gets tunneled across the backbone to the proper PE router. it gets tunneled across the backbone to the proper PE router. Thus,
Thus the backbone core routers do not need to know the VPN routes. the backbone core routers do not need to know the VPN routes.
The primary goal of this method is to support the case in which a The primary goal of this method is to support the case in which a
client obtains IP backbone services from a Service Provider or client obtains IP backbone services from a Service Provider or
Service Providers with which it maintains contractual relationships. Service Providers with which it maintains contractual relationships.
The client may be an enterprise, a group of enterprises which need an The client may be an enterprise, a group of enterprises that need an
extranet, an Internet Service Provider, an application service extranet, an Internet Service Provider, an application service
provider, another VPN Service Provider which uses this same method to provider, another VPN Service Provider that uses this same method to
offer VPNs to clients of its own, etc. The method makes it very offer VPNs to clients of its own, etc. The method makes it very
simple for the client to use the backbone services. It is also very simple for the client to use the backbone services. It is also very
scalable and flexible for the Service Provider, and allows the scalable and flexible for the Service Provider, and allows the
Service Provider to add value. Service Provider to add value.
1.1. Virtual Private Networks 1.1. Virtual Private Networks
Consider a set of "sites" that are attached to a common network that Consider a set of "sites" that are attached to a common network that
we call "the backbone". Now apply some policy to create a number of we call "the backbone". Now apply some policy to create a number of
subsets of that set, and impose the following rule: two sites may subsets of that set, and impose the following rule: two sites may
have IP interconnectivity over that backbone only if at least one of have IP interconnectivity over that backbone only if at least one of
these subsets contains them both. these subsets contains them both.
These subsets are "Virtual Private Networks" (VPNs). Two sites have These subsets are Virtual Private Networks (VPNs). Two sites have IP
IP connectivity over the common backbone only if there is some VPN connectivity over the common backbone only if there is some VPN that
which contains them both. Two sites which have no VPN in common have contains them both. Two sites that have no VPN in common have no
no connectivity over that backbone. connectivity over that backbone.
If all the sites in a VPN are owned by the same enterprise, the VPN If all the sites in a VPN are owned by the same enterprise, the VPN
may be thought of as a corporate "intranet". If the various sites in may be thought of as a corporate "intranet". If the various sites in
a VPN are owned by different enterprises, the VPN may be thought of a VPN are owned by different enterprises, the VPN may be thought of
as an "extranet". A site can be in more than one VPN; e.g., in an as an "extranet". A site can be in more than one VPN; e.g., in an
intranet and in several extranets. In general, when we use the term intranet and in several extranets. In general, when we use the term
VPN we will not be distinguishing between intranets and extranets. "VPN" we will not be distinguishing between intranets and extranets.
We refer to the owners of the sites as the "customers". We refer to We refer to the owners of the sites as the "customers". We refer to
the owners/operators of the backbone as the "Service Providers" the owners/operators of the backbone as the "Service Providers"
(SPs). The customers obtain "VPN service" from the SPs. (SPs). The customers obtain "VPN service" from the SPs.
A customer may be a single enterprise, a set of enterprises, an A customer may be a single enterprise, a set of enterprises, an
Internet Service Provider, an Application Service Provider, another Internet Service Provider, an Application Service Provider, another
SP which offers the same kind of VPN service to its own customers, SP that offers the same kind of VPN service to its own customers,
etc. etc.
The policies that determine whether a particular collection of sites The policies that determine whether a particular collection of sites
is a VPN are the policies of the customers. Some customers will want is a VPN are the policies of the customers. Some customers will want
the implementation of these policies to be entirely the the implementation of these policies to be entirely the
responsibility of the SP. Other customers may want to share with the responsibility of the SP. Other customers may want to share with the
SP the responsibility for implementing these policies. This document SP the responsibility for implementing these policies. This document
specifies mechanisms that can be used to implement these policies. specifies mechanisms that can be used to implement these policies.
The mechanisms we describe are general enough to allow 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 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 together with the SP. Most of the discussion is focused on the
former case, however. former case, however.
The mechanisms discussed in this document allow the implementation of The mechanisms discussed in this document allow the implementation of
a wide range of policies. For example, within a given VPN, one can a wide range of policies. For example, within a given VPN, one can
allow every site to have a direct route to every other site ("full allow every site to have a direct route to every other site ("full
mesh"). Alternatively, one can force traffic between certain pairs mesh"). Alternatively, one can force traffic between certain pairs
of sites to be routed via a third site. This can be useful, e.g., if of sites to be routed via a third site. This can be useful, e.g., if
it is desired that traffic between a pair of sites be passed through it is desired that traffic between a pair of sites be passed through
a firewall, and the firewall is located at the third site. a firewall, and the firewall is located at the third site.
In this document, we restrict our discussion to the case in which the In this document, we restrict our discussion to the case in which the
customer is explicitly purchasing VPN service from an SP, or from a customer is explicitly purchasing VPN service from an SP, or from a
set of SPs that have agreed to cooperate to provide the VPN service. set of SPs that have agreed to cooperate to provide the VPN service.
That is, the customer is not merely purchasing internet access from That is, the customer is not merely purchasing internet access from
an SP, and the VPN traffic does not pass through a random collection an SP, and the VPN traffic does not pass through a random collection
of interconnected SP networks. of interconnected SP networks.
We also restrict our discussion to the case in which the backbone We also restrict our discussion to the case in which the backbone
provides an IP service to the customer, rather than, e.g, a layer 2 provides an IP service to the customer, rather than, e.g., a layer 2
service such as Frame Relay, ATM (Asynchronous Transfer Mode), service such as Frame Relay, Asynchronous Transfer Mode (ATM),
ethernet, HDLC ("High Level Data Link Control"), or PPP (Point-to- ethernet, High Level Data Link Control (HDLC), or Point-to-Point
Point Protocol). The customer may attach to the backbone via one of Protocol (PPP). The customer may attach to the backbone via one of
these (or other) layer 2 services, but the layer 2 service is these (or other) layer 2 services, but the layer 2 service is
terminated at the "edge" of the backbone, where the customer's IP terminated at the "edge" of the backbone, where the customer's IP
datagrams are removed from any layer 2 encapsulation. datagrams are removed from any layer 2 encapsulation.
In the rest of this introduction, we specify some properties which In the rest of this introduction, we specify some properties that
VPNs should have. The remainder of this document specifies a set of VPNs should have. The remainder of this document specifies a set of
mechanisms that can be deployed to provide a VPN model which has all mechanisms that can be deployed to provide a VPN model that has all
these properties. This section also introduces some of the technical these properties. This section also introduces some of the technical
terminology used in the remainder of the document. terminology used in the remainder of the document.
1.2. Customer Edge and Provider Edge 1.2. Customer Edge and Provider Edge
Routers can be attached to each other, or to end systems, in a Routers can be attached to each other, or to end systems, in a
variety of different ways: PPP connections, ATM VCs ("Virtual variety of different ways: PPP connections, ATM Virtual Circuits
Circuits"), Frame Relay VCs, ethernet interfaces, VLANs ("Virtual (VCs), Frame Relay VCs, ethernet interfaces, Virtual Local Area
Local Area Networks") on ethernet interfaces, GRE tunnels, L2TP Networks (VLANs) on ethernet interfaces, GRE tunnels, Layer 2
("Layer 2 Tunneling Protocol") tunnels, IPsec tunnels, etc. We will Tunneling Protocol (L2TP) tunnels, IPsec tunnels, etc. We will use
use the term "attachment circuit" to refer generally to some such the term "attachment circuit" to refer generally to some such means
means of attaching to a router. An attachment circuit may be the of attaching to a router. An attachment circuit may be the sort of
sort of connection that is usually thought of as a "data link", or it connection that is usually thought of as a "data link", or it may be
may be a tunnel of some sort; what matters is that it be possible for a tunnel of some sort; what matters is that it be possible for two
two devices to be network layer peers over the attachment circuit. devices to be network layer peers over the attachment circuit.
Each VPN site must contain one or more Customer Edge (CE) devices. Each VPN site must contain one or more Customer Edge (CE) devices.
Each CE device is attached, via some sort of attachment circuit, to Each CE device is attached, via some sort of attachment circuit, to
one or more Provider Edge (PE) routers. one or more Provider Edge (PE) routers.
Routers in the SP's network which do not attach to CE devices are Routers in the SP's network that do not attach to CE devices are
known as "P routers". known as "P routers".
CE devices can be hosts or routers. In a typical case, a site CE devices can be hosts or routers. In a typical case, a site
contains one or more routers, some of which are attached to PE contains one or more routers, some of which are attached to PE
routers. The site routers which attach to the PE routers would then routers. The site routers that attach to the PE routers would then
be the CE devices, or "CE routers". However, there is nothing to be the CE devices, or "CE routers". However, there is nothing to
prevent a non-routing host from attaching directly to a PE router, in prevent a non-routing host from attaching directly to a PE router, in
which case the host would be a CE device. which case the host would be a CE device.
Sometimes, what is physically attached to a PE router is a layer 2 Sometimes, what is physically attached to a PE router is a layer 2
switch. In this case, we do NOT say that the layer 2 switch is a CE switch. In this case, we do NOT say that the layer 2 switch is a CE
devices. Rather, the CE devices are the hosts and routers that device. Rather, the CE devices are the hosts and routers that
communicate with the PE router through the layer 2 switch; the layer communicate with the PE router through the layer 2 switch; the layer
2 infrastructure is transparent. If the layer 2 infrastructure 2 infrastructure is transparent. If the layer 2 infrastructure
provides a multipoint service, then multiple CE devices can be provides a multipoint service, then multiple CE devices can be
attached to the PE router over the same attachment circuit. attached to the PE router over the same attachment circuit.
CE devices are logically part of a customer's VPN. PE and P routers CE devices are logically part of a customer's VPN. PE and P routers
are logically part of the SP's network. are logically part of the SP's network.
The attachment circuit over which a packet travels when going from CE The attachment circuit over which a packet travels when going from CE
to PE is known as that packet's "ingress attachment circuit", and the to PE is known as that packet's "ingress attachment circuit", and the
PE as the packet's "ingress PE". The attachment circuit over which a PE as the packet's "ingress PE". The attachment circuit over which a
packet travels when going from PE to CE is known as that packet's packet travels when going from PE to CE is known as that packet's
"egress attachment circuit", and the PE as the packet's "egress PE". "egress attachment circuit", and the PE as the packet's "egress PE".
We will say that a PE router is attached to a particular VPN if it is We will say that a PE router is attached to a particular VPN if it is
attached to a CE device which is in a site of that VPN. Similarly, attached to a CE device that is in a site of that VPN. Similarly, we
we will say that a PE router is attached to a particular site if it will say that a PE router is attached to a particular site if it is
is attached to a CE device which is in that site. attached to a CE device that is in that site.
When the CE device is a router, it is a routing peer of the PE(s) to When the CE device is a router, it is a routing peer of the PE(s) to
which it is attached, but it is NOT a routing peer of CE routers at which it is attached, but it is NOT a routing peer of CE routers at
other sites. Routers at different sites do not directly exchange other sites. Routers at different sites do not directly exchange
routing information with each other; in fact, they do not even need routing information with each other; in fact, they do not even need
to know of each other at all. As a consequence, the customer has no to know of each other at all. As a consequence, the customer has no
backbone or "virtual backbone" to manage, and does not have to deal backbone or "virtual backbone" to manage, and does not have to deal
with any inter-site routing issues. In other words, in the scheme with any inter-site routing issues. In other words, in the scheme
described in this document, a VPN is NOT an "overlay" on top of the described in this document, a VPN is NOT an "overlay" on top of the
SP's network. SP's network.
skipping to change at page 8, line 14 skipping to change at page 7, line 5
1.3. VPNs with Overlapping Address Spaces 1.3. VPNs with Overlapping Address Spaces
If two VPNs have no sites in common, then they may have overlapping If two VPNs have no sites in common, then they may have overlapping
address spaces. That is, a given address might be used in VPN V1 as address spaces. That is, a given address might be used in VPN V1 as
the address of system S1, but in VPN V2 as the address of a the address of system S1, but in VPN V2 as the address of a
completely different system S2. This is a common situation when the completely different system S2. This is a common situation when the
VPNs each use an RFC1918 private address space. Of course, within VPNs each use an RFC1918 private address space. Of course, within
each VPN, each address must be unambiguous. each VPN, each address must be unambiguous.
Even two VPNs which do have sites in common may have overlapping Even two VPNs that do have sites in common may have overlapping
address spaces, as long as there is no need for any communication address spaces, as long as there is no need for any communication
between systems with such addresses and systems in the common sites. between systems with such addresses and systems in the common sites.
1.4. VPNs with Different Routes to the Same System 1.4. VPNs with Different Routes to the Same System
Although a site may be in multiple VPNs, it is not necessarily the 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 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 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, 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 C, and the "foreign" site D. Suppose that at site A there is a
skipping to change at page 8, line 41 skipping to change at page 7, line 32
It is possible to set up two routes to the server. One route, used It is 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 by sites B and C, takes the traffic directly to site A. The second
route, used by site D, takes the traffic instead to the firewall at route, used by site D, takes the traffic instead to the firewall at
site B. If the firewall allows the traffic to pass, it then appears 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. to be traffic coming from site B, and follows the route to site A.
1.5. SP Backbone Routers 1.5. SP Backbone Routers
The SP's backbone consists of the PE routers, as well as other The SP's backbone consists of the PE routers, as well as other
routers ("P routers") which do not attach to CE devices. routers ("P routers") that do not attach to CE devices.
If every router in an SP's backbone had to maintain routing If every router in an SP's backbone had to maintain routing
information for all the VPNs supported by the SP, there would be information for all the VPNs supported by the SP, there would be
severe scalability problems; the number of sites that could be severe scalability problems; the number of sites that could be
supported would be limited by the amount of routing information that supported would be limited by the amount of routing information that
could be held in a single router. It is important therefore that the could be held in a single router. It is important therefore that the
routing information about a particular VPN only needs to be present routing information about a particular VPN only needs to be present
in the PE routers which attach to that VPN. In particular, the P in the PE routers that attach to that VPN. In particular, the P
routers do not need to have ANY per-VPN routing information routers do not need to have ANY per-VPN routing information
whatsoever. (This condition may need to be relaxed somewhat when whatsoever. (This condition may need to be relaxed somewhat when
multicast routing is considered. This is not considered further in multicast routing is considered. This is not considered further in
this paper, but is examined in [VPN-MCAST].) this paper, but is examined in [VPN-MCAST].)
So just as the VPN owners do not have a backbone or "virtual So just as the VPN owners do not have a backbone or "virtual
backbone" to administer, the SPs themselves do not have a separate backbone" to administer, the SPs themselves do not have a separate
backbone or "virtual backbone" to administer for each VPN. Site-to- backbone or "virtual backbone" to administer for each VPN. Site-to-
site routing in the backbone is optimal (within the constraints of site routing in the backbone is optimal (within the constraints of
the policies used to form the VPNs), and is not constrained in any the policies used to form the VPNs) and is not constrained in any way
way by an artificial "virtual topology" of tunnels. by an artificial "virtual topology" of tunnels.
Section 10 discusses some of the special issues that arise when the Section 10 discusses some of the special issues that arise when the
backbone spans several service providers. backbone spans several Service Providers.
1.6. Security 1.6. Security
VPNs of the sort being discussed here, even without making use of VPNs of the sort being discussed here, even without making use of
cryptographic security measures, are intended to provide a level of cryptographic security measures, are intended to provide a level of
security equivalent to that obtainable when a layer 2 backbone (e.g., security equivalent to that obtainable when a layer 2 backbone (e.g.,
Frame Relay) is used. That is, in the absence of misconfiguration or Frame Relay) is used. That is, in the absence of misconfiguration or
deliberate interconnection of different VPNs, it is not possible for deliberate interconnection of different VPNs, it is not possible for
systems in one VPN to gain access to systems in another VPN. Of systems in one VPN to gain access to systems in another VPN. Of
course the methods described herein do not by themselves encrypt the course, the methods described herein do not by themselves encrypt the
data for privacy, nor do they provide a way to determine whether data data for privacy, nor do they provide a way to determine whether data
has been tampered with en route. If this is desired, cryptographic has been tampered with en route. If this is desired, cryptographic
measures must be applied in addition. (See, e.g., [MPLS/BGP-IPsec]. measures must be applied in addition. (See, e.g., [MPLS/BGP-IPsec].)
Security is discussed in more detail in section 13. Security is discussed in more detail in Section 13.
2. Sites and CEs 2. Sites and CEs
From the perspective of a particular backbone network, a set of IP From the perspective of a particular backbone network, a set of IP
systems may be regarded as a "site" if those systems have mutual IP systems may be regarded as a "site" if those systems have mutual IP
interconnectivity that doesn't require use of the backbone. In interconnectivity that doesn't require use of the backbone. In
general, a site will consist of a set of systems which are in general, a site will consist of a set of systems that are in
geographic proximity. However, this is not universally true. If two geographic proximity. However, this is not universally true. If two
geographic locations are connected via a leased line, over which OSPF geographic locations are connected via a leased line, over which Open
("Open Shortest Path First" protocol, [OSPFv2]) is running, and if Shortest Path First (OSPF) protocol [OSPFv2] is running, and if that
that line is the preferred way of communicating between the two line is the preferred way of communicating between the two locations,
locations, then the two locations can be regarded as a single site, then the two locations can be regarded as a single site, even if each
even if each location has its own CE router. (This notion of "site" location has its own CE router. (This notion of "site" is
is topological, rather than geographical. If the leased line goes topological, rather than geographical. If the leased line goes down,
down, or otherwise ceases to be the preferred route, but the two or otherwise ceases to be the preferred route, but the two geographic
geographic locations can continue to communicate by using the VPN locations can continue to communicate by using the VPN backbone, then
backbone, then one site has become two.) one site has become two.)
A CE device is always regarded as being in a single site (though as A CE device is always regarded as being in a single site (though as
we shall see in section 3.2), a site may consist of multiple "virtual we shall see in Section 3.2, a site may consist of multiple "virtual
sites"). A site, however, may belong to multiple VPNs. sites"). A site, however, may belong to multiple VPNs.
A PE router may attach to CE devices from any number of different A PE router may attach to CE devices from any number of different
sites, whether those CE devices are in the same or in different VPNs. 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 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 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 router, the PE router and the CE router will appear as router
adjacencies to each other. adjacencies to each other.
While we speak mostly of "sites" as being the basic unit of While we speak mostly of "sites" as being the basic unit of
skipping to change at page 10, line 33 skipping to change at page 9, line 20
extranet attachment circuit. extranet attachment circuit.
3. VRFs: Multiple Forwarding Tables in PEs 3. VRFs: Multiple Forwarding Tables in PEs
Each PE router maintains a number of separate forwarding tables. One Each PE router maintains a number of separate forwarding tables. One
of the forwarding tables is the "default forwarding table". The of the forwarding tables is the "default forwarding table". The
others are "VPN Routing and Forwarding tables", or "VRFs". others are "VPN Routing and Forwarding tables", or "VRFs".
3.1. VRFs and Attachment Circuits 3.1. VRFs and Attachment Circuits
Every PE-CE attachment circuits is associated, by configuration, with Every PE/CE attachment circuit is associated, by configuration, with
one or more VRFs. An attachment circuit which is associated with a one or more VRFs. An attachment circuit that is associated with a
VRF is known as a "VRF attachment circuit". VRF is known as a "VRF attachment circuit".
In the simplest case and most typical case, a PE-CE attachment In the simplest case and most typical case, a PE/CE attachment
circuit is associated with exactly one VRF. When an IP packet is circuit is associated with exactly one VRF. When an IP packet is
received over a particular attachment circuit, its destination IP received over a particular attachment circuit, its destination IP
address is looked up in the associated VRF. The result of that address is looked up in the associated VRF. The result of that
lookup determines how to route the packet. The VRF used by a lookup determines how to route the packet. The VRF used by a
packet's ingress PE for routing a particular packet is known as the packet's ingress PE for routing a particular packet is known as the
packet's "ingress VRF". (There is also the notion of a packet's packet's "ingress VRF". (There is also the notion of a packet's
"egress VRF", located at the packet's egress PE; this is discussed in "egress VRF", located at the packet's egress PE; this is discussed in
section 5.) Section 5.)
If an IP packet arrives over an attachment circuit which is not If an IP packet arrives over an attachment circuit that is not
associated with any VRF, the packet's destination address is looked associated with any VRF, the packet's destination address is looked
up in the default forwarding table, and the packet is routed up in the default forwarding table, and the packet is routed
accordingly. Packets forwarded according to the default forwarding accordingly. Packets forwarded according to the default forwarding
table include packets from neighboring P or PE routers, as well as table include packets from neighboring P or PE routers, as well as
packets from customer-facing attachment circuits that have not been packets from customer-facing attachment circuits that have not been
associated with VRFs. associated with VRFs.
Intuitively, one can think of the default forwarding table as Intuitively, one can think of the default forwarding table as
containing "public routes", and of the VRFs as containing "private containing "public routes", and of the VRFs as containing "private
routes". One can similarly think of VRF attachment circuits as being routes". One can similarly think of VRF attachment circuits as being
"private", and of non-VRF attachment circuits as being "public". "private", and of non-VRF attachment circuits as being "public".
If a particular VRF attachment circuit connects site S to a PE If a particular VRF attachment circuit connects site S to a PE
router, then connectivity from S (via that attachment circuit) can be router, then connectivity from S (via that attachment circuit) can be
restricted by controlling the set of routes which get entered in the restricted by controlling the set of routes that gets entered in the
corresponding VRF. The set of routes in that VRF should be limited corresponding VRF. The set of routes in that VRF should be limited
to the set of routes leading to sites which have at least one VPN in to the set of routes leading to sites that have at least one VPN in
common with S. Then a packet sent from S over a VRF attachment common with S. Then a packet sent from S over a VRF attachment
circuit can only be routed by the PE to another site S' if S' is in circuit can only be routed by the PE to another site S' if S' is in
one of the same VPNs as S. That is, communication (via PE routers) one of the same VPNs as S. That is, communication (via PE routers)
is prevented between any pair of VPN sites which have no VPN in is prevented between any pair of VPN sites that have no VPN in
common. Communication between VPN sites and non-VPN sites is common. Communication between VPN sites and non-VPN sites is
prevented by keeping the routes to the VPN sites out of the default prevented by keeping the routes to the VPN sites out of the default
forwarding table. forwarding table.
If there are multiple attachment circuits leading from S to one or If there are multiple attachment circuits leading from S to one or
more PE routers, then there might be multiple VRFs that could be used more PE routers, then there might be multiple VRFs that could be used
to route traffic from S. To properly restrict S's connectivity, the to route traffic from S. To properly restrict S's connectivity, the
same set of routes would have to exist in all the VRFs. same set of routes would have to exist in all the VRFs.
Alternatively, one could impose different connectivity restrictions Alternatively, one could impose different connectivity restrictions
over different attachment circuit from S. In that case, some of the over different attachment circuit from S. In that case, some of the
VRFs associated with attachment circuits from S would contain VRFs associated with attachment circuits from S would contain
different sets of routes than some of the others. different sets of routes than some of the others.
We allow the case in which a single attachment circuit is associated We allow the case in which a single attachment circuit is associated
with a set of VRFs, rather than with a single VRF. This can be with a set of VRFs, rather than with a single VRF. This can be
useful if it is desired to divide a single VPN into several "sub- useful if it is desired to divide a single VPN into several
VPNs", each with different connectivity restrictions, where some "sub-VPNs", each with different connectivity restrictions, where some
characteristic of the customer packets is used to select from among characteristic of the customer packets is used to select from among
the sub-VPNs. For simplicity though, we will usually speak of an the sub-VPNs. For simplicity though, we will usually speak of an
attachment circuit as being associated with a single VRF. attachment circuit as being associated with a single VRF.
3.2. Associating IP Packets with VRFs 3.2. Associating IP Packets with VRFs
When a PE router receives a packet from a CE device, it must When a PE router receives a packet from a CE device, it must
determine the attachment circuit over which the packet arrived, as determine the attachment circuit over which the packet arrived, as
this determines in turn the VRF (or set of VRFs) that can be used for this determines in turn the VRF (or set of VRFs) that can be used for
forwarding that packet. In general, to determine the attachment forwarding that packet. In general, to determine the attachment
circuit over which a packet arrived, a PE router takes note of the circuit over which a packet arrived, a PE router takes note of the
physical interface over which the packet arrived, and possibly also physical interface over which the packet arrived, and possibly also
takes note of some aspect of the packet's layer 2 header. For takes note of some aspect of the packet's layer 2 header. For
example, if a packet's ingress attachment circuit is a frame relay example, if a packet's ingress attachment circuit is a Frame Relay
VC, the identity of the attachment circuit can be determined from the VC, the identity of the attachment circuit can be determined from the
physical frame relay interface over which the packet arrived, physical Frame Relay interface over which the packet arrived,
together with the DLCI ("Data Link Connection Identifier") field in together with the Data Link Connection Identifier (DLCI) field in the
the packet's frame relay header. packet's Frame Relay header.
Although the PE's conclusion that a particular packet arrived on a Although the PE's conclusion that a particular packet arrived on a
particular Attachment Circuit may be partially determined by the particular attachment circuit may be partially determined by the
packet's layer 2 header, it must be impossible for a customer, by packet's layer 2 header, it must be impossible for a customer, by
writing the header fields, to fool the SP into thinking that a packet writing the header fields, to fool the SP into thinking that a packet
which was received over one attachment circuit really arrived over a that was received over one attachment circuit really arrived over a
different one. In the example above, although the attachment circuit different one. In the example above, although the attachment circuit
is determined partially by inspection of the DLCI field in the frame is determined partially by inspection of the DLCI field in the Frame
relay header, this field cannot be set freely by the customer. Relay header, this field cannot be set freely by the customer.
Rather, it must be set to a value specified by the SP, or else the Rather, it must be set to a value specified by the SP, or else the
packet cannot arrive at the PE router. packet cannot arrive at the PE router.
In some cases, a particular site may be divided by the customer into In some cases, a particular site may be divided by the customer into
several "virtual sites". The SP may designate a particular set of several "virtual sites". The SP may designate a particular set of
VRFs to be used for routing packets from that site, and may allow the VRFs to be used for routing packets from that site and may allow the
customer to set some characteristic of the packet which is then used customer to set some characteristic of the packet, which is then used
for choosing a particular VRF from the set. for choosing a particular VRF from the set.
For example, each virtual site might be realized as a VLAN. The SP For example, each virtual site might be realized as a VLAN. The SP
and the customer could agree that on packets arriving from a and the customer could agree that on packets arriving from a
particular CE, certain VLAN values would be used to identify certain particular CE, certain VLAN values would be used to identify certain
VRFs. Of course, packets from that CE would be discarded by the PE VRFs. Of course, packets from that CE would be discarded by the PE
if they carry VLAN tag values that are not in the agreed upon set. if they carry VLAN tag values that are not in the agreed-upon set.
Another way to accomplish this is to use IP source addresses. In this Another way to accomplish this is to use IP source addresses. In
case PE uses the IP source address in a packet received from the CE, this case, the PE uses the IP source address in a packet received
along with the interface over which the packet is received, to assign from the CE, along with the interface over which the packet is
the packet to a particular VRF. Again, the customer would only be received, to assign the packet to a particular VRF. Again, the
able to select from among the particular set of VRFs which that customer would only be able to select from among the particular set
customer is allowed to use. of VRFs that that customer is allowed to use.
If it is desired to have a particular host be in multiple virtual If it is desired to have a particular host be in multiple virtual
sites, then that host must determine, for each packet, which 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 site the packet is associated with. It can do this, e.g., by sending
packets from different virtual sites on different VLANs, or out packets from different virtual sites on different VLANs, or out
different network interfaces. different network interfaces.
3.3. Populating the VRFs 3.3. Populating the VRFs
With what set of routes are the VRFs populated? With what set of routes are the VRFs populated?
As an example, let PE1, PE2, and PE3 be three PE routers, and let 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, 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 CE1, the routes that are reachable at CE1's site. If PE2 and PE3 are
are attached respectively to CE2 and CE3, and there is some VPN V 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 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 and PE3 the routes that it has learned from CE1. PE2 and PE3 use
these routes to populate the VRFs which they associate respectively these routes to populate the VRFs that they associate, respectively,
with the sites of CE2 and CE3. Routes from sites which are not in with the sites of CE2 and CE3. Routes from sites that are not in VPN
VPN V do not appear in these VRFs, which means that packets from CE2 V do not appear in these VRFs, which means that packets from CE2 or
or CE3 cannot be sent to sites which are not in VPN V. CE3 cannot be sent to sites that are not in VPN V.
When we speak of a PE "learning" routes from a CE, we are not When we speak of a PE "learning" routes from a CE, we are not
presupposing any particular learning technique. The PE may learn presupposing any particular learning technique. The PE may learn
routes by means of a dynamic routing algorithm, but it may also routes by means of a dynamic routing algorithm, but it may also
"learn" routes by having those routes configured (i.e., static "learn" routes by having those routes configured (i.e., static
routing). (In this case, to say that the PE "learned" the routes routing). (In this case, to say that the PE "learned" the routes
from the CE is perhaps to exercise a bit of poetic license.) from the CE is perhaps to exercise a bit of poetic license.)
PEs also need to learn, from other PEs, the routes that belong to a
PEs also need to learn, from other PEs, the routes which belong to a
given VPN. The procedures to be used for populating the VRFs with given VPN. The procedures to be used for populating the VRFs with
the proper sets of routes are specified in section 4. the proper sets of routes are specified in Section 4.
If there are multiple attachment circuits leading from a particular If there are multiple attachment circuits leading from a particular
PE router to a particular site, they might all be mapped to the same PE router to a particular site, they might all be mapped to the same
forwarding table. But if policy dictates, they could be mapped to forwarding table. But if policy dictates, they could be mapped to
different forwarding tables. For instance, the policy might be that different forwarding tables. For instance, the policy might be that
a particular attachment circuit from a site is used only for intranet a particular attachment circuit from a site is used only for intranet
traffic, while another attachment circuit from that site is used only traffic, while another attachment circuit from that site is used only
for extranet traffic. (Perhaps, e.g., the CE attached to the for extranet traffic. (Perhaps, e.g., the CE attached to the
extranet attachment circuit is a firewall, while the CE attached to extranet attachment circuit is a firewall, while the CE attached to
the intranet attachment circuit is not.) In this case, the two the intranet attachment circuit is not.) In this case, the two
attachment circuits would be associated with different VRFs. attachment circuits would be associated with different VRFs.
Note that if two attachment circuits are associated with the same Note that if two attachment circuits are associated with the same
VRF, then packets which the PE receives over one of them will be able VRF, then packets that the PE receives over one of them will be able
to reach exactly the same set of destinations as packets which the PE to reach exactly the same set of destinations as packets that the PE
receives over the other. So two attachment circuits cannot be receives over the other. So two attachment circuits cannot be
associated with the same VRF unless each CE is in the exact same set associated with the same VRF unless each CE is in the exact same set
of VPNs as is the other. of VPNs as is the other.
If an attachment circuit leads to a site which is in multiple VPNs, If an attachment circuit leads to a site which is in multiple VPNs,
the attachment circuit may still associated with a single VRF, in the attachment circuit may still associated with a single VRF, in
which case the VRF will contain routes from the full set of VPNs of which case the VRF will contain routes from the full set of VPNs of
which the site is a member. which the site is a member.
4. VPN Route Distribution via BGP 4. VPN Route Distribution via BGP
PE routers use BGP to distribute VPN routes to each other (more PE routers use BGP to distribute VPN routes to each other (more
accurately, to cause VPN routes to be distributed to each other). accurately, to cause VPN routes to be distributed to each other).
We allow each VPN to have its own address space, which means that a We allow each VPN to have its own address space, which means that a
given address may denote different systems in different VPNs. If two given address may denote different systems in different VPNs. If two
routes, to the same IP address prefix, are actually routes to routes to the same IP address prefix are actually routes to different
different systems, it is important to ensure that BGP not treat them systems, it is important to ensure that BGP not treat them as
as comparable. Otherwise BGP might choose to install only one of comparable. Otherwise, BGP might choose to install only one of them,
them, making the other system unreachable. Further, we must ensure making the other system unreachable. Further, we must ensure that
that POLICY is used to determine which packets get sent on which POLICY is used to determine which packets get sent on which routes;
routes; given that several such routes are installed by BGP, only one given that several such routes are installed by BGP, only one such
such must appear in any particular VRF. must appear in any particular VRF.
We meet these goals by the use of a new address family, as specified We meet these goals by the use of a new address family, as specified
below. below.
4.1. The VPN-IPv4 Address Family 4.1. The VPN-IPv4 Address Family
The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes
from multiple "address families". We introduce the notion of the from multiple "address families". We introduce the notion of the
"VPN-IPv4 address family". A VPN-IPv4 address is a 12-byte quantity, "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 beginning with an 8-byte Route Distinguisher (RD) and ending with a
4-byte IPv4 address. If several VPNs use the same IPv4 address 4-byte IPv4 address. If several VPNs use the same IPv4 address
prefix, the PEs translate these into unique VPN-IPv4 address prefix, the PEs translate these into unique VPN-IPv4 address
prefixes. This ensures that if the same address is used in several prefixes. This ensures that if the same address is used in several
different VPNs, it is possible for BGP to carry several completely different VPNs, it is possible for BGP to carry several completely
different routes to that address, one for each VPN. different routes to that address, one for each VPN.
Since VPN-IPv4 addresses and IPv4 addresses are different address Since VPN-IPv4 addresses and IPv4 addresses are different address
families, BGP never treats them as comparable addresses. families, BGP never treats them as comparable addresses.
An RD is simply a number, and it does not contain any inherent An RD is simply a number, and it does not contain any inherent
information; it does not identify the origin of the route or the set information; it does not identify the origin of the route or the set
of VPNs to which the route is to be distributed. The purpose of the 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 RD is solely to allow one to create distinct routes to a common IPv4
address prefix. Other means are used to determine where to address prefix. Other means are used to determine where to
redistribute the route (see section 4.3). redistribute the route (see Section 4.3).
The RD can also be used to create multiple different routes to the The RD can also be used to create multiple different routes to the
very same system. We have already discussed a situation in which the very same system. We have already discussed a situation in which the
route to a particular server should be different for intranet traffic route to a particular server should be different for intranet traffic
than for extranet traffic. This can be achieved by creating two than for extranet traffic. This can be achieved by creating two
different VPN-IPv4 routes that have the same IPv4 part, but different different VPN-IPv4 routes that have the same IPv4 part, but different
RDs. This allows BGP to install multiple different routes to the RDs. This allows BGP to install multiple different routes to the
same system, and allows policy to be used (see section 4.3.5) to same system, and allows policy to be used (see Section 4.3.5) to
decide which packets use which route. decide which packets use which route.
The RDs are structured so that every service provider can administer The RDs are structured so that every Service Provider can administer
its own "numbering space" (i.e., can make its own assignments of its own "numbering space" (i.e., can make its own assignments of
RDs), without conflicting with the RD assignments made by any other RDs), without conflicting with the RD assignments made by any other
service provider. An RD consists of three fields: a two-byte type Service Provider. An RD consists of three fields: a 2-byte type
field, an administrator field, and an assigned number field. The field, an administrator field, and an assigned number field. The
value of the type field determines the lengths of the other two value of the type field determines the lengths of the other two
fields, as well as the semantics of the administrator field. The fields, as well as the semantics of the administrator field. The
administrator field identifies an assigned number authority, and the administrator field identifies an assigned number authority, and the
assigned number field contains a number which has been assigned, by assigned number field contains a number that has been assigned, by
the identified authority, for a particular purpose. For example, one the identified authority, for a particular purpose. For example, one
could have an RD whose administrator field contains an Autonomous could have an RD whose administrator field contains an Autonomous
System number (ASN), and whose (4-byte) number field contains a System number (ASN), and whose (4-byte) number field contains a
number assigned by the SP to whom that ASN belongs (having been number assigned by the SP to whom that ASN belongs (having been
assigned to that SP by the appropriate authority). assigned to that SP by the appropriate authority).
RDs are given this structure in order to ensure that an SP which RDs are given this structure in order to ensure that an SP that
provides VPN backbone service can always create a unique RD when it provides VPN backbone service can always create a unique RD when it
needs to do so. However, the structure is not meaningful to BGP; when needs to do so. However, the structure is not meaningful to BGP;
BGP compares two such address prefixes, it ignores the structure when BGP compares two such address prefixes, it ignores the structure
entirely. entirely.
A PE needs to be configured such that routes which lead to particular A PE needs to be configured such that routes that lead to a
CE become associated with a particular RD. The configuration may particular CE become associated with a particular RD. The
cause all routes leading to the same CE to be associated with the configuration may cause all routes leading to the same CE to be
same RD, or it may be cause different routes to be associated with associated with the same RD, or it may cause different routes to be
different RDs, even if they lead to the same CE. associated with different RDs, even if they lead to the same CE.
4.2. Encoding of Route Distinguishers 4.2. Encoding of Route Distinguishers
As stated, a VPN-IPv4 address consists of an 8-byte Route As stated, a VPN-IPv4 address consists of an 8-byte Route
Distinguisher followed by a 4-byte IPv4 address. The RDs are encoded Distinguisher followed by a 4-byte IPv4 address. The RDs are encoded
as follows: as follows:
- Type Field: 2 bytes - Type Field: 2 bytes
- Value Field: 6 bytes - Value Field: 6 bytes
The interpretation of the Value field depends on the value of the The interpretation of the Value field depends on the value of the
Type field. At the present time, three values of the type field are type field. At the present time, three values of the type field are
defined: 0, 1, and 2. defined: 0, 1, and 2.
- Type 0: The Value field consists of two subfields: - Type 0: The Value field consists of two subfields:
* Administrator subfield: 2 bytes * Administrator subfield: 2 bytes
* Assigned Number subfield: 4 bytes * Assigned Number subfield: 4 bytes
The Administrator subfield must contain an Autonomous System The Administrator subfield must contain an Autonomous System
number. If this ASN is from the public ASN space, it must have number. If this ASN is from the public ASN space, it must have
been assigned by the appropriate authority (use of ASN values been assigned by the appropriate authority (use of ASN values
from the private ASN space is strongly discouraged). The from the private ASN space is strongly discouraged). The
Assigned Number subfield contains a number from a numbering space Assigned Number subfield contains a number from a numbering space
which is administered by the enterprise to which the ASN has been that is administered by the enterprise to which the ASN has been
assigned by an appropriate authority. assigned by an appropriate authority.
- Type 1: The Value field consists of two subfields: - Type 1: The Value field consists of two subfields:
* Administrator subfield: 4 bytes * Administrator subfield: 4 bytes
* Assigned Number subfield: 2 bytes * Assigned Number subfield: 2 bytes
The Administrator subfield must contain an IP address. If this IP The Administrator subfield must contain an IP address. If this
address is from the public IP address space, it must have been IP address is from the public IP address space, it must have been
assigned by an appropriate authority (use of addresses from the assigned by an appropriate authority (use of addresses from the
private IP address space is strongly discouraged). The Assigned private IP address space is strongly discouraged). The Assigned
Number sub-field contains a number from a numbering space which Number subfield contains a number from a numbering space which is
is administered by the enterprise to which the IP address has administered by the enterprise to which the IP address has been
been assigned. assigned.
- Type 2: The Value field consists of two subfields: - Type 2: The Value field consists of two subfields:
* Administrator subfield: 4 bytes * Administrator subfield: 4 bytes
* Assigned Number subfield: 2 bytes * Assigned Number subfield: 2 bytes
The Administrator subfield must contain a 4-byte Autonomous The Administrator subfield must contain a 4-byte Autonomous
System number [BGP-AS4]. If this ASN is from the public ASN System number [BGP-AS4]. If this ASN is from the public ASN
space, it must have been assigned by the appropriate authority space, it must have been assigned by the appropriate authority
(use of ASN values from the private ASN space is strongly (use of ASN values from the private ASN space is strongly
skipping to change at page 17, line 9 skipping to change at page 15, line 31
VPN-IPv4 routes is controlled. VPN-IPv4 routes is controlled.
If a PE router is attached to a particular VPN (by being attached to If a PE router is attached to a particular VPN (by being attached to
a particular CE in that VPN), it learns some of that VPN's IP routes a particular CE in that VPN), it learns some of that VPN's IP routes
from the attached CE router. Routes learned from a CE routing peer from the attached CE router. Routes learned from a CE routing peer
over a particular attachment circuit may be installed in the VRF over a particular attachment circuit may be installed in the VRF
associated with that attachment circuit. Exactly which routes are associated with that attachment circuit. Exactly which routes are
installed in this manner is determined by the way in which the PE installed in this manner is determined by the way in which the PE
learns routes from the CE. In particular, when the PE and CE are learns routes from the CE. In particular, when the PE and CE are
routing protocol peers, this is determined by the decision process of routing protocol peers, this is determined by the decision process of
the routing protocol; this is discussed in section 7. the routing protocol; this is discussed in Section 7.
These routes are then converted to VPN-IP4 routes, and "exported" to These routes are then converted to VPN-IP4 routes, and "exported" to
BGP. If there is more than one route to a particular VPN-IP4 address BGP. If there is more than one route to a particular VPN-IP4 address
prefix, BGP chooses the "best" one, using the BGP decision process. prefix, BGP chooses the "best" one, using the BGP decision process.
That route is then distributed by BGP to the set of other PEs that That route is then distributed by BGP to the set of other PEs that
need to know about it. At these other PEs, BGP will again choose the need to know about it. At these other PEs, BGP will again choose the
best route for a particular VPN-IP4 address prefix. Then the chosen best route for a particular VPN-IP4 address prefix. Then the chosen
VPN-IP4 routes are converted back into IP routes, and "imported" into VPN-IP4 routes are converted back into IP routes, and "imported" into
one or more VRFs. Whether they are actually installed in the VRFs one or more VRFs. Whether they are actually installed in the VRFs
depends on the decision process of the routing method used between depends on the decision process of the routing method used between
the PE and those CEs that are associated with the VRF in question. the PE and those CEs that are associated with the VRF in question.
Finally, any route installed in a VRF may be distributed to the Finally, any route installed in a VRF may be distributed to the
associated CE routers. associated CE routers.
4.3.1. The Route Target Attribute 4.3.1. The Route Target Attribute
Every VRF is associated with one or more "Route Target" (RT) Every VRF is associated with one or more Route Target (RT)
attributes. attributes.
When a VPN-IPv4 route is created (from an IPv4 route which the PE has When a VPN-IPv4 route is created (from an IPv4 route that the PE has
learned from a CE) by a PE router, it is associated with one or more learned from a CE) by a PE router, it is associated with one or more
"Route Target" attributes. These are carried in BGP as attributes of Route Target attributes. These are carried in BGP as attributes of
the route. the route.
Any route associated with Route Target T must be distributed to every Any route associated with Route Target T must be distributed to every
PE router that has a VRF associated with Route Target T. When such a PE router that has a VRF associated with Route Target T. When such a
route is received by a PE router, it is eligible to be installed in route is received by a PE router, it is eligible to be installed in
those of the PE's VRFs which are associated with Route Target T. those of the PE's VRFs that are associated with Route Target T.
(Whether it actually gets installed depends upon the outcome of the (Whether it actually gets installed depends upon the outcome of the
BGP decision process, and upon the outcome of the decision process of BGP decision process, and upon the outcome of the decision process of
the IGP (i.e., the intra-domain routing protocol) running on the PE- the IGP (i.e., the intra-domain routing protocol) running on the
CE interface.) PE/CE interface.)
A Route Target attribute can be thought of as identifying a set of A Route Target attribute can be thought of as identifying a set of
sites. (Though it would be more precise to think of it as sites. (Though it would be more precise to think of it as
identifying a set of VRFs.) Associating a particular Route Target identifying a set of VRFs.) Associating a particular Route Target
attribute with a route allows that route to be placed in the VRFs attribute with a route allows that route to be placed in the VRFs
that are used for routing traffic which is received from the that are used for routing traffic that is received from the
corresponding sites. corresponding sites.
There is a set of Route Targets that a PE router attaches to a route There is a set of Route Targets that a PE router attaches to a route
received from site S; these may be called the "Export Targets". And received from site S; these may be called the "Export Targets". And
there is a set of Route Targets that a PE router uses to determine there is a set of Route Targets that a PE router uses to determine
whether a route received from another PE router could be placed in whether a route received from another PE router could be placed in
the VRF associated with site S; these may be called the "Import the VRF associated with site S; these may be called the "Import
Targets". The two sets are distinct, and need not be the same. Note Targets". The two sets are distinct, and need not be the same. Note
that a particular VPN-IPv4 route is only eligible for installation in that a particular VPN-IPv4 route is only eligible for installation in
a particular VRF if there is some Route Target which is both one of a particular VRF if there is some Route Target that is both one of
the route's Route Targets and one of the VRF's Import Targets. the route's Route Targets and one of the VRF's Import Targets.
The function performed by the Route Target attribute is similar to The function performed by the Route Target attribute is similar to
that performed by the BGP Communities Attribute. However, the format that performed by the BGP Communities attribute. However, the format
of the latter is inadequate for present purposes, since it allows of the latter is inadequate for present purposes, since it allows
only a two-byte numbering space. It is desirable to structure the only a 2-byte numbering space. It is desirable to structure the
format, similar to what we have described for RDs (see section 4.2), format, similar to what we have described for RDs (see Section 4.2),
so that a type field defines the length of an administrator field, so that a type field defines the length of an administrator field,
and the remainder of the attribute is a number from the specified and the remainder of the attribute is a number from the specified
administrator's numbering space. This can be done using BGP Extended administrator's numbering space. This can be done using BGP Extended
Communities. The Route Targets discussed herein are encoded as BGP Communities. The Route Targets discussed herein are encoded as BGP
Extended Community Route Targets [BGP-EXTCOMM]. They are structured Extended Community Route Targets [BGP-EXTCOMM]. They are structured
similarly to the RDs. similarly to the RDs.
When a BGP speaker has received more than one route to the same VPN- When a BGP speaker has received more than one route to the same VPN-
IPv4 prefix, the BGP rules for route preference are used to choose IPv4 prefix, the BGP rules for route preference are used to choose
which VPN-IPv4 route is installed by BGP. which VPN-IPv4 route is installed by BGP.
skipping to change at page 18, line 43 skipping to change at page 17, line 15
(i.e., using more RDs), but the scaling properties would be less (i.e., using more RDs), but the scaling properties would be less
favorable. favorable.
How does a PE determine which Route Target attributes to associate How does a PE determine which Route Target attributes to associate
with a given route? There are a number of different possible ways. 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 The PE might be configured to associate all routes that lead to a
specified site with a specified Route Target. Or the PE might be specified site with a specified Route Target. Or the PE might be
configured to associate certain routes leading to a specified site configured to associate certain routes leading to a specified site
with one Route Target, and certain with another. with one Route Target, and certain with another.
If the PE and the CE are themselves BGP peers (see section 7), then If the PE and the CE are themselves BGP peers (see Section 7), then
the SP may allow the customer, within limits, to specify how its the SP may allow the customer, within limits, to specify how its
routes are to be distributed. The SP and the customer would need to routes are to be distributed. The SP and the customer would need to
agree in advance on the set of RTs which are allowed to be attached agree in advance on the set of RTs that are allowed to be attached to
to the customer's VPN routes. The CE could then attach one or more the customer's VPN routes. The CE could then attach one or more of
of those RTs to each IP route which it distributes to the PE. This those RTs to each IP route that it distributes to the PE. This gives
gives the customer the freedom to specify in real time, within agreed the customer the freedom to specify in real time, within agreed-upon
upon limits, its route distribution policies. If the CE is allowed limits, its route distribution policies. If the CE is allowed to
to attach RTs to its routes, the PE MUST filter out all routes which attach RTs to its routes, the PE MUST filter out all routes that
contain RTs that the customer is not allowed to use. If the CE is contain RTs that the customer is not allowed to use. If the CE is
not allowed to attach RTs to its routes, but does so anyway, the PE not allowed to attach RTs to its routes, but does so anyway, the PE
MUST remove the RT before converting the customer's route to a VPN- MUST remove the RT before converting the customer's route to a VPN-
IPv4 route. IPv4 route.
4.3.2. Route Distribution Among PEs by BGP 4.3.2. Route Distribution Among PEs by BGP
If two sites of a VPN attach to PEs which are in the same Autonomous If two sites of a VPN attach to PEs that are in the same Autonomous
System, the PEs can distribute VPN-IPv4 routes to each other by means System, the PEs can distribute VPN-IPv4 routes to each other by means
of an IBGP connection between them. (The term "IBGP" refers to the of an IBGP connection between them. (The term "IBGP" refers to the
set of protocols and procedures used when there is a BGP connection set of protocols and procedures used when there is a BGP connection
between two BGP speakers in the same Autonomous System. This is between two BGP speakers in the same Autonomous System. This is
distinguished from "EBGP", the set of procedures used between two BGP distinguished from "EBGP", the set of procedures used between two BGP
speakers in different Autonomous Systems.) Alternatively, each can speakers in different Autonomous Systems.) Alternatively, each can
have an IBGP connection to a route reflector [BGP-RR]. have an IBGP connection to a route reflector [BGP-RR].
When a PE router distributes a VPN-IPv4 route via BGP, it uses its When a PE router distributes a VPN-IPv4 route via BGP, it uses its
own address as the "BGP next hop". This address is encoded as a own address as the "BGP next hop". This address is encoded as a
VPN-IPv4 address with an RD of 0. ([BGP-MP] requires that the next VPN-IPv4 address with an RD of 0. ([BGP-MP] requires that the next
hop address be in the same address family as the NLRI ("Network Layer hop address be in the same address family as the Network Layer
Reachability Information".)) It also assigns and distributes an MPLS Reachability Information (NLRI).) It also assigns and distributes an
label. (Essentially, PE routers distribute not VPN-IPv4 routes, but MPLS label. (Essentially, PE routers distribute not VPN-IPv4 routes,
Labeled VPN-IPv4 routes. Cf. [MPLS-BGP]). When the PE processes a but Labeled VPN-IPv4 routes. Cf. [MPLS-BGP].) When the PE processes
received packet that has this label at the top of the stack, the PE a received packet that has this label at the top of the stack, the PE
will pop the stack, and process the packet appropriately. will pop the stack, and process the packet appropriately.
The PE may distribute the exact set of routes that appears in the The PE may distribute the exact set of routes that appears in the
VRF, or it may perform summarization and distribute aggregates of VRF, or it may perform summarization and distribute aggregates of
those routes, or it may do some of one and some of the other. those routes, or it may do some of one and some of the other.
Suppose that a PE has assigned label L to route R, and has Suppose that a PE has assigned label L to route R, and has
distributed this label mapping via BGP. If R is an aggregate of a distributed this label mapping via BGP. If R is an aggregate of a
set of routes in the VRF, the PE will know that packets from the set of routes in the VRF, the PE will know that packets from the
backbone which arrive with this label must have their destination backbone that arrive with this label must have their destination
addresses looked up in a VRF. When the PE looks up the label in its addresses looked up in a VRF. When the PE looks up the label in its
Label Information Base, it learns which VRF must be used. On the Label Information Base, it learns which VRF must be used. On the
other hand, if R is not an aggregate, then when the PE looks up the other hand, if R is not an aggregate, then when the PE looks up the
label, it learns the egress attachment circuit, as well as the label, it learns the egress attachment circuit, as well as the
encapsulation header for the packet. In this case, no lookup in the encapsulation header for the packet. In this case, no lookup in the
VRF is done. VRF is done.
We would expect that the most common case would be the case where the We would expect that the most common case would be the case where the
route is NOT an aggregate. The case where it is an aggregate can be route is NOT an aggregate. The case where it is an aggregate can be
very useful though if the VRF contains a large number of host routes very useful though if the VRF contains a large number of host routes
(e.g., as in dial-in), or if the VRF has an associated LAN (Local (e.g., as in dial-in), or if the VRF has an associated Local Area
Area Network) interface (where there is a different outgoing layer 2 Network (LAN) interface (where there is a different outgoing layer 2
header for each system on the LAN, but a route is not distributed for header for each system on the LAN, but a route is not distributed for
each such system). each such system).
Whether each route has a distinct label or not is an implementation Whether or not each route has a distinct label is an implementation
matter. There are a number of possible algorithms one could use to matter. There are a number of possible algorithms one could use to
determine whether two routes get assigned the same label: determine whether two routes get assigned the same label:
- One may choose to have a single label for an entire VRF, so that - One may choose to have a single label for an entire VRF, so that
a single label is shared by all the routes from that VRF. Then a single label is shared by all the routes from that VRF. Then
when the egress PE receives a packet with that label, it must when the egress PE receives a packet with that label, it must
look up the packet's IP destination address in that VRF (the look up the packet's IP destination address in that VRF (the
packet's "egress VRF"), in order to determine the packet's egress packet's "egress VRF"), in order to determine the packet's egress
attachment circuit and the corresponding data link encapsulation. attachment circuit and the corresponding data link encapsulation.
- One may choose to have a single label for each attachment - One may choose to have a single label for each attachment
circuit, so that a single label is shared by all the routes with circuit, so that a single label is shared by all the routes with
the same "outgoing attachment circuit". This enables one to the same "outgoing attachment circuit". This enables one to
avoid doing a lookup in the egress VRF, though some sort of avoid doing a lookup in the egress VRF, though some sort of
lookup may need to be done in order to determine the data link lookup may need to be done in order to determine the data link
encapsulation, e.g, an ARP ("Address Resolution Protocol") encapsulation, e.g., an Address Resolution Protocol (ARP) lookup.
lookup.
- One may choose to have a distinct label for each route. Then if - One may choose to have a distinct label for each route. Then if
a route is potentially reachable over more than one attachment a route is potentially reachable over more than one attachment
circuit, the PE/CE routing can switch the preferred path for a circuit, the PE/CE routing can switch the preferred path for a
route from one attachment circuit to another, without there being route from one attachment circuit to another, without there being
any need to distribute new a label for that route. any need to distribute new a label for that route.
There may be other possible algorithms as well. The choice of There may be other possible algorithms as well. The choice of
algorithm is entirely at the discretion of the egress PE, and is algorithm is entirely at the discretion of the egress PE, and is
otherwise transparent. otherwise transparent.
In using BGP-distributed MPLS labels in this manner, we presuppose In using BGP-distributed MPLS labels in this manner, we presuppose
that an MPLS packet carrying such a label can be tunneled from the that an MPLS packet carrying such a label can be tunneled from the
router that installs the corresponding BGP-distributed route to the router that installs the corresponding BGP-distributed route to the
router which is the BGP next hop of that route. This requires either router that is the BGP next hop of that route. This requires either
that a label switched path exist between those two routers, or else that a label switched path exist between those two routers or else
that some other tunneling technology (e.g., [MPLS-in-IP-GRE]) can be that some other tunneling technology (e.g., [MPLS-in-IP-GRE]) can be
used between them. used between them.
This tunnel may follow a "best effort" route, or it may follow a This tunnel may follow a "best effort" route, or it may follow a
traffic engineered route. Between a given pair of routers there may traffic-engineered route. Between a given pair of routers, there may
be one such tunnel, or there may be several, perhaps with different be one such tunnel, or there may be several, perhaps with different
QoS characteristics. All that matters for the VPN architecture is Quality of Service (QoS) characteristics. All that matters for the
that some such tunnel exists. To ensure interoperability among VPN architecture is that some such tunnel exists. To ensure
systems which implement this VPN architecture using MPLS label interoperability among systems that implement this VPN architecture
switched paths as the tunneling technology, all such systems MUST using MPLS label switched paths as the tunneling technology, all such
support LDP ("Label Distribution Protocol", [MPLS-LDP]). In systems MUST support Label Distribution Protocol (LDP) [MPLS-LDP].
particular, Downstream Unsolicited mode MUST be supported on In particular, Downstream Unsolicited mode MUST be supported on
interfaces which are neither LC-ATM ("Label Controlled ATM") [MPLS- interfaces that are neither Label Controlled ATM (LC-ATM) [MPLS-ATM]
ATM] nor LC-FR ("Label Controlled Frame Relay") [MPLS-FR] interfaces, nor Label Controlled Frame Relay (LC-FR) [MPLS-FR] interfaces, and
and Downstream on Demand mode MUST be supported on LC-ATM interfaces Downstream on Demand mode MUST be supported on LC-ATM interfaces and
and LC-FR interfaces. LC-FR interfaces.
If the tunnel follows a best effort route, then the PE finds the If the tunnel follows a best-effort route, then the PE finds the
route to the remote endpoint by looking up its IP address in the route to the remote endpoint by looking up its IP address in the
default forwarding table. default forwarding table.
A PE router, UNLESS it is a Route Reflector (see section 4.3.3) or an A PE router, UNLESS it is a route reflector (see Section 4.3.3) or an
Autonomous System border router for an inter-provider VPN (see Autonomous System Border Router (ASBR) for an inter-provider VPN (see
section 10) should not install a VPN-IPv4 route unless it has at Section 10), should not install a VPN-IPv4 route unless it has at
least one VRF with an Import Target identical to one of the route's least one VRF with an Import Target identical to one of the route's
Route Target attributes. Inbound filtering should be used to cause Route Target attributes. Inbound filtering should be used to cause
such routes to be discarded. If a new Import Target is later added such routes to be discarded. If a new Import Target is later added
to one of the PE's VRFs (a "VPN Join" operation), it must then to one of the PE's VRFs (a "VPN Join" operation), it must then
acquire the routes it may previously have discarded. This can be acquire the routes it may previously have discarded. This can be
done using the refresh mechanism described in [BGP-RFSH]. The done using the refresh mechanism described in [BGP-RFSH]. The
outbound route filtering mechanism of [BGP-ORF] can also be used to outbound route filtering mechanism of [BGP-ORF] can also be used to
advantage to make the filtering more dynamic. advantage to make the filtering more dynamic.
Similarly, if a particular Import Target is no longer present in any Similarly, if a particular Import Target is no longer present in any
of a PE's VRFs (as a result of one or more "VPN Prune" operations), of a PE's VRFs (as a result of one or more "VPN Prune" operations),
the PE may discard all routes which, as a result, no longer have any the PE may discard all routes that, as a result, no longer have any
of the PE's VRF's Import Targets as one of their Route Target of the PE's VRF's Import Targets as one of their Route Target
Attributes. attributes.
A router which is not attached to any VPN, and which is not a Route A router that is not attached to any VPN and that is not a Route
Reflector (i.e., a P router), never installs any VPN-IPv4 routes at Reflector (i.e., a P router) never installs any VPN-IPv4 routes at
all. all.
Note that VPN Join and Prune operations are non-disruptive, and do Note that VPN Join and Prune operations are non-disruptive and do not
not require any BGP connections to be brought down, as long as the require any BGP connections to be brought down, as long as the
refresh mechanism of [BGP-RFSH] is used. refresh mechanism of [BGP-RFSH] is used.
As a result of these distribution rules, no one PE ever needs to As a result of these distribution rules, no one PE ever needs to
maintain all routes for all VPNs; this is an important scalability maintain all routes for all VPNs; this is an important scalability
consideration. consideration.
4.3.3. Use of Route Reflectors 4.3.3. Use of Route Reflectors
Rather than having a complete IBGP mesh among the PEs, it is Rather than having a complete IBGP mesh among the PEs, it is
advantageous to make use of BGP Route Reflectors [BGP-RR] to improve advantageous to make use of BGP Route Reflectors [BGP-RR] to improve
scalability. All the usual techniques for using route reflectors to scalability. All the usual techniques for using route reflectors to
improve scalability, e.g., route reflector hierarchies, are improve scalability (e.g., route reflector hierarchies) are
available. available.
Route reflectors are the only systems which need to have routing Route reflectors are the only systems that need to have routing
information for VPNs to which they are not directly attached. information for VPNs to which they are not directly attached.
However, there is no need to have any one route reflector know all However, there is no need to have any one route reflector know all
the VPN-IPv4 routes for all the VPNs supported by the backbone. the VPN-IPv4 routes for all the VPNs supported by the backbone.
We outline below two different ways to partition the set of VPN-IPv4 We outline below two different ways to partition the set of VPN-IPv4
routes among a set of route reflectors. routes among a set of route reflectors.
1. Each route reflector is preconfigured with a list of Route 1. Each route reflector is preconfigured with a list of Route
Targets. For redundancy, more than one route reflector may be Targets. For redundancy, more than one route reflector may be
preconfigured with the same list. A route reflector uses the preconfigured with the same list. A route reflector uses the
preconfigured list of Route Targets to construct its inbound preconfigured list of Route Targets to construct its inbound
route filtering. The route reflector may use the techniques of route filtering. The route reflector may use the techniques of
[BGP-ORF] to install on each of its peers (regardless of [BGP-ORF] to install on each of its peers (regardless of
whether the peer is another route reflector, or a PE) the set whether the peer is another route reflector or a PE) the set of
of "Outbound Route Filters" (ORFs) that contain the list of its Outbound Route Filters (ORFs) that contains the list of its
preconfigured Route Targets. Note that route reflectors should preconfigured Route Targets. Note that route reflectors should
accept ORFs from other route reflectors, which means that route accept ORFs from other route reflectors, which means that route
reflectors should advertise the ORF capability to other route reflectors should advertise the ORF capability to other route
reflectors. reflectors.
A service provider may modify the list of preconfigured Route A service provider may modify the list of preconfigured Route
Targets on a route reflector. When this is done, the route Targets on a route reflector. When this is done, the route
reflector modifies the ORFs it installs on all of its IBGP reflector modifies the ORFs it installs on all of its IBGP
peers. To reduce the frequency of configuration changes on peers. To reduce the frequency of configuration changes on
route reflectors, each route reflector may be preconfigured route reflectors, each route reflector may be preconfigured
with a block of Route Targets. This way, when a new Route with a block of Route Targets. This way, when a new Route
Target is needed for a new VPN, there is already one or more Target is needed for a new VPN, there is already one or more
route reflectors that are (pre)configured with this Route route reflectors that are (pre)configured with this Route
Target. Target.
Unless a given PE is a client of all route reflectors, when a Unless a given PE is a client of all route reflectors, when a
new VPN is added to the PE ("VPN Join"), it will need to become new VPN is added to the PE ("VPN Join"), it will need to become
a client of the route reflector(s) that maintain routes for a client of the route reflector(s) that maintain routes for
that VPN. Likewise, deleting an existing VPN from the PE ("VPN that VPN. Likewise, deleting an existing VPN from the PE ("VPN
Prune") may result in a situation where the PE no longer need Prune") may result in a situation where the PE no longer needs
to be a client of some route reflector(s). In either case, the to be a client of some route reflector(s). In either case, the
Join or Prune operation is non-disruptive (as long as [BGP- Join or Prune operation is non-disruptive (as long as
RFSH] is used, and never requires a BGP connection to be [BGP-RFSH] is used, and never requires a BGP connection to be
brought down, only to be brought right back up. brought down, only to be brought right back up.
(By "adding a new VPN to a PE", we really mean adding a new (By "adding a new VPN to a PE", we really mean adding a new
import Route Target to one of its VRFs, or adding a new VRF import Route Target to one of its VRFs, or adding a new VRF
with an import Route Target not had by any of the PE's other with an import Route Target not had by any of the PE's other
VRFs.) VRFs.)
2. Another method is to have each PE be a client of some subset of 2. Another method is to have each PE be a client of some subset of
the route reflectors. A route reflector is not preconfigured the route reflectors. A route reflector is not preconfigured
with the list of Route Targets, and does not perform inbound with the list of Route Targets, and does not perform inbound
route filtering of routes received from its clients (PEs); route filtering of routes received from its clients (PEs);
rather it accepts all the routes received from all of its rather, it accepts all the routes received from all of its
clients (PEs). The route reflector keeps track of the set of clients (PEs). The route reflector keeps track of the set of
the Route Targets carried by all the routes it receives. When the Route Targets carried by all the routes it receives. When
the route reflector receives from its client a route with a the route reflector receives from its client a route with a
Route Target that is not in this set, this Route Target is Route Target that is not in this set, this Route Target is
immediately added to the set. On the other hand, when the route immediately added to the set. On the other hand, when the
reflector no longer has any routes with a particular Route route reflector no longer has any routes with a particular
Target that is in the set, the route reflector should delay (by Route Target that is in the set, the route reflector should
a few hours) the deletion of this Route Target from the set. delay (by a few hours) the deletion of this Route Target from
the set.
The route reflector uses this set to form the inbound route The route reflector uses this set to form the inbound route
filters that it applies to routes received from other route filters that it applies to routes received from other route
reflectors. The route reflector may also use ORFs to install reflectors. The route reflector may also use ORFs to install
the appropriate outbound route filtering on other route the appropriate outbound route filtering on other route
reflectors. Just like with the first approach, a route reflectors. Just like with the first approach, a route
reflector should accept ORFs from other route reflectors. To reflector should accept ORFs from other route reflectors. To
accomplish this, a route reflector advertises ORF capability to accomplish this, a route reflector advertises ORF capability to
other route reflectors. other route reflectors.
When the route reflector changes the set, it should immediately When the route reflector changes the set, it should immediately
change its inbound route filtering. In addition, if the route change its inbound route filtering. In addition, if the route
reflector uses ORFs, then the ORFs have to be immediately reflector uses ORFs, then the ORFs have to be immediately
changed to reflect the changes in the set. If the route changed to reflect the changes in the set. If the route
reflector doesn't use ORFs, and a new Route Target is added to reflector doesn't use ORFs, and a new Route Target is added to
the set, the route reflector, after changing its inbound route the set, the route reflector, after changing its inbound route
filtering, must issue BGP Refresh to other route reflectors. filtering, must issue BGP Refresh to other route reflectors.
The delay of "a few hours" mentioned above allows a route The delay of "a few hours" mentioned above allows a route
reflector to hold onto routes with a given RT, even after it reflector to hold onto routes with a given RT, even after it
loses the last of its clients which are interested in such loses the last of its clients that are interested in such
routes. This protects against the need to reacquire all such routes. This protects against the need to reacquire all such
routes if the clients' "disappearance" is only temporary. routes if the clients' "disappearance" is only temporary.
With this procedure, VPN Join and Prune operations are also With this procedure, VPN Join and Prune operations are also
non-disruptive. non-disruptive.
Note that this technique will not work properly if some client Note that this technique will not work properly if some client
PE has a VRF with an import Route Target that is not one of its PE has a VRF with an import Route Target that is not one of its
export Route Targets. export Route Targets.
In these procedures, a PE router which attaches to a particular VPN In these procedures, a PE router which attaches to a particular VPN
"auto-discovers" the other PEs which attach to the same VPN. When a "auto-discovers" the other PEs that attach to the same VPN. When a
new PE router is added, or when an existing PE router attaches to a new PE router is added, or when an existing PE router attaches to a
new VPN, no reconfiguration of other PE routers is needed. new VPN, no reconfiguration of other PE routers is needed.
Just as there is no one PE router that needs to know all the VPN-IPv4 Just as there is no one PE router that needs to know all the VPN-IPv4
routes that are supported over the backbone, these distribution rules routes supported over the backbone, these distribution rules ensure
ensure that there is no one RR ("Route Reflector") which needs to that there is no one Route Reflector (RR) that needs to know all the
know all the VPN-IPv4 routes that are supported over the backbone. VPN-IPv4 routes supported over the backbone. As a result, the total
As a result, the total number of such routes that can be supported number of such routes that can be supported over the backbone is not
over the backbone is not bounded by the capacity of any single bounded by the capacity of any single device, and therefore can
device, and therefore can increase virtually without bound. increase virtually without bound.
4.3.4. How VPN-IPv4 NLRI is Carried in BGP 4.3.4. How VPN-IPv4 NLRI Is Carried in BGP
The BGP Multiprotocol Extensions [BGP-MP] are used to encode the The BGP Multiprotocol Extensions [BGP-MP] are used to encode the
NLRI. If the AFI (Address Family Identifier) field is set to 1, and NLRI. If the Address Family Identifier (AFI) field is set to 1, and
the SAFI (Subsequent Address Family Identifier) field is set to 128, the Subsequent Address Family Identifier (SAFI) field is set to 128,
the NLRI is an MPLS-labeled VPN-IPv4 address. AFI 1 is used since the NLRI is an MPLS-labeled VPN-IPv4 address. AFI 1 is used since
the network layer protocol associated with the NLRI is still IP. the network layer protocol associated with the NLRI is still IP.
Note that this VPN architecture does not require the capability to Note that this VPN architecture does not require the capability to
distribute unlabeled VPN-IPv4 addresses. distribute unlabeled VPN-IPv4 addresses.
In order for two BGP speakers to exchange labeled VPN-IPv4 NLRI, they In order for two BGP speakers to exchange labeled VPN-IPv4 NLRI, they
must use BGP Capabilities Advertisement to ensure that they both are must use BGP Capabilities Advertisement to ensure that they both are
capable of properly processing such NLRI. This is done as specified capable of properly processing such NLRI. This is done as specified
in [BGP-MP], by using capability code 1 (multiprotocol BGP), with an in [BGP-MP], by using capability code 1 (multiprotocol BGP), with an
AFI of 1 and an SAFI of 128. AFI of 1 and an SAFI of 128.
The labeled VPN-IPv4 NLRI itself is encoded as specified in [MPLS- The labeled VPN-IPv4 NLRI itself is encoded as specified in
BGP], where the prefix consists of an 8-byte RD followed by an IPv4 [MPLS-BGP], where the prefix consists of an 8-byte RD followed by an
prefix. IPv4 prefix.
4.3.5. Building VPNs using Route Targets 4.3.5. Building VPNs Using Route Targets
By setting up the Import Targets and Export Targets properly, one can By setting up the Import Targets and Export Targets properly, one can
construct different kinds of VPNs. construct different kinds of VPNs.
Suppose it is desired to create a a fully meshed closed user group, Suppose it is desired to create a fully meshed closed user group,
i.e., a set of sites where each can send traffic directly to the i.e., a set of sites where each can send traffic directly to the
other, but traffic cannot be sent to or received from other sites. other, but traffic cannot be sent to or received from other sites.
Then each site is associated with a VRF, a single Route Target Then each site is associated with a VRF, a single Route Target
attribute is chosen, that Route Target is assigned to each VRF as attribute is chosen, that Route Target is assigned to each VRF as
both the Import Target and the Export Target, and that Route Target both the Import Target and the Export Target, and that Route Target
is not assigned to any other VRFs as either the Import Target or the is not assigned to any other VRFs as either the Import Target or the
Export Target. Export Target.
Alternatively, suppose one desired, for whatever reason, to create a 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 "hub and spoke" kind of VPN. This could be done by the use of two
skipping to change at page 25, line 4 skipping to change at page 23, line 23
Then each site is associated with a VRF, a single Route Target Then each site is associated with a VRF, a single Route Target
attribute is chosen, that Route Target is assigned to each VRF as attribute is chosen, that Route Target is assigned to each VRF as
both the Import Target and the Export Target, and that Route Target both the Import Target and the Export Target, and that Route Target
is not assigned to any other VRFs as either the Import Target or the is not assigned to any other VRFs as either the Import Target or the
Export Target. Export Target.
Alternatively, suppose one desired, for whatever reason, to create a 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 "hub and spoke" kind of VPN. This could be done by the use of two
Route Target values, one meaning "Hub" and one meaning "Spoke". At Route Target values, one meaning "Hub" and one meaning "Spoke". At
the VRFs attached to the hub sites, "Hub" is the Export Target and the VRFs attached to the hub sites, "Hub" is the Export Target and
"Spoke" is the Import Target. At the VRFs attached to the spoke "Spoke" is the Import Target. At the VRFs attached to the spoke
site, "Hub" is the Import Target and "Spoke" is the Export Target. site, "Hub" is the Import Target and "Spoke" is the Export Target.
Thus the methods for controlling the distribution of routing Thus, the methods for controlling the distribution of routing
information among various sets of sites are very flexible, which in information among various sets of sites are very flexible, which in
turn provides great flexibility in constructing VPNs. turn provides great flexibility in constructing VPNs.
4.3.6. Route Distribution Among VRFs in a Single PE 4.3.6. Route Distribution Among VRFs in a Single PE
It is possible to distribute routes from one VRF to another, even if It is possible to distribute routes from one VRF to another, even if
both VRFs are in the same PE, even though in this case one cannot say both VRFs are in the same PE, even though in this case one cannot say
that the route has been distributed by BGP. Nevertheless, the that the route has been distributed by BGP. Nevertheless, the
decision to distribute a particular route from one VRF to another decision to distribute a particular route from one VRF to another
within a single PE is the same decision that would be made if the within a single PE is the same decision that would be made if the
VRFs were on different PEs. That is, it depends on the route target VRFs were on different PEs. That is, it depends on the Route Target
attribute which is assigned to the route (or would be assigned if the attribute that is assigned to the route (or would be assigned if the
route were distributed by BGP), and the import target of the second route were distributed by BGP), and the import target of the second
VRF. VRF.
5. Forwarding 5. Forwarding
If the intermediate routers in the backbone do not have any If the intermediate routers in the backbone do not have any
information about the routes to the VPNs, how are packets forwarded information about the routes to the VPNs, how are packets forwarded
from one VPN site to another? from one VPN site to another?
When a PE receives an IP packet from a CE device, it chooses a When a PE receives an IP packet from a CE device, it chooses a
skipping to change at page 25, line 42 skipping to change at page 24, line 15
Assume that a match is found. As a result we learn the packet's Assume that a match is found. As a result we learn the packet's
"next hop". "next hop".
If the packet's next hop is reached directly over a VRF attachment If the packet's next hop is reached directly over a VRF attachment
circuit from this PE (i.e., the packet's egress attachment circuit is circuit from this PE (i.e., the packet's egress attachment circuit is
on the same PE as its ingress attachment circuit), then the packet is on the same PE as its ingress attachment circuit), then the packet is
sent on the egress attachment circuit, and no MPLS labels are pushed sent on the egress attachment circuit, and no MPLS labels are pushed
onto the packet's label stack. onto the packet's label stack.
If the ingress and egress attachment circuits are on the same PE, but If the ingress and egress attachment circuits are on the same PE, but
are associated with different VRFs, and if the route which best are associated with different VRFs, and if the route that best
matches the destination address in the ingress attachment circuit's matches the destination address in the ingress attachment circuit's
VRF is an aggregate of several routes in the egress attachment VRF is an aggregate of several routes in the egress attachment
circuit's VRF, it may be necessary to look up the packet's circuit's VRF, it may be necessary to look up the packet's
destination address in the egress VRF as well. destination address in the egress VRF as well.
If the packet's next hop is NOT reached through a VRF attachment If the packet's next hop is NOT reached through a VRF attachment
circuit, then the packet must travel at least one hop through the circuit, then the packet must travel at least one hop through the
backbone. The packet thus has a "BGP Next Hop", and the BGP Next Hop backbone. The packet thus has a "BGP Next Hop", and the BGP Next Hop
will have assigned an MPLS label for the route that best matches the will have assigned an MPLS label for the route that best matches the
packet's destination address. Call this label the "VPN route label". packet's destination address. Call this label the "VPN route label".
The IP packet is turned into an MPLS packet with the VPN route label The IP packet is turned into an MPLS packet with the VPN route label
as the sole label on the label stack. as the sole label on the label stack.
The packet must then be tunneled to the BGP Next Hop. The packet must then be tunneled to the BGP Next Hop.
If the backbone supports MPLS, this is done as follows: If the backbone supports MPLS, this is done as follows:
- The PE routers (and any Autonomous System border routers) which - The PE routers (and any Autonomous System border routers) that
redistribute VPN-IPv4 addresses need to insert /32 address redistribute VPN-IPv4 addresses need to insert /32 address
prefixes for themselves into the IGP routing tables of the prefixes for themselves into the IGP routing tables of the
backbone. This enables MPLS, at each node in the backbone backbone. This enables MPLS, at each node in the backbone
network, to assign a label corresponding to the route to each PE network, to assign a label corresponding to the route to each PE
router. To ensure interoperability among different router. To ensure interoperability among different
implementations, it is required to support LDP for setting up the implementations, it is required to support LDP for setting up the
label switched paths across the backbone. However, other methods label switched paths across the backbone. However, other methods
of setting up these label switched paths are also possible. of setting up these label switched paths are also possible.
(Some of these other methods may not require the presence of the (Some of these other methods may not require the presence of the
/32 address prefixes in the IGP.) /32 address prefixes in the IGP.)
skipping to change at page 26, line 40 skipping to change at page 25, line 12
label gets pushed on the MPLS label stack, and the packet is label gets pushed on the MPLS label stack, and the packet is
forwarded to the tunnel's next hop. forwarded to the tunnel's next hop.
- Otherwise, - Otherwise,
* The packet will have an "IGP Next Hop", which is the next hop * The packet will have an "IGP Next Hop", which is the next hop
along the IGP route to the BGP Next Hop. along the IGP route to the BGP Next Hop.
* If the BGP Next Hop and the IGP Next Hop are the same, and if * If the BGP Next Hop and the IGP Next Hop are the same, and if
penultimate hop popping is used, the packet is then sent to penultimate hop popping is used, the packet is then sent to
the IGP next hop, carrying only the VPN route label. the IGP Next Hop, carrying only the VPN route label.
* Otherwise, the IGP Next Hop will have assigned a label for * Otherwise, the IGP Next Hop will have assigned a label for
the route which best matches the address of the BGP Next Hop. the route that best matches the address of the BGP Next Hop.
Call this the "tunnel label". The tunnel label gets pushed Call this the "tunnel label". The tunnel label gets pushed
on as the packet's top label. The packet is then forwarded on as the packet's top label. The packet is then forwarded
to the IGP next hop. to the IGP Next Hop.
- MPLS will then carry the packet across the backbone to the BGP - MPLS will then carry the packet across the backbone to the BGP
Next Hop, where the VPN label will be examined. Next Hop, where the VPN label will be examined.
If the backbone does not support MPLS, the MPLS packet carrying only If the backbone does not support MPLS, the MPLS packet carrying only
the VPN route label may be tunneled to the BGP Next Hop using the the VPN route label may be tunneled to the BGP Next Hop using the
techniques of [MPLS-in-IP-or-GRE]. When the packet emerges from the techniques of [MPLS-in-IP-GRE]. When the packet emerges from the
tunnel, it will be at the BGP Next Hop, where the VPN route label tunnel, it will be at the BGP Next Hop, where the VPN route label
will be examined. will be examined.
At the BGP Next Hop, the treatment of the packet depends on the VPN At the BGP Next Hop, the treatment of the packet depends on the VPN
route label (see section 4.3.2). In many cases, the PE will be able route label (see Section 4.3.2). In many cases, the PE will be able
to determine, from this label, the attachment circuit over which the to determine, from this label, the attachment circuit over which the
packet should be transmitted (to a CE device), as well as the proper packet should be transmitted (to a CE device), as well as the proper
data link layer header for that interface. In other cases, the PE data link layer header for that interface. In other cases, the PE
may only be able to determine that the packet's destination address may only be able to determine that the packet's destination address
needs to be looked up in a particular VRF before being forwarded to a needs to be looked up in a particular VRF before being forwarded to a
CE device. There are also intermediate cases in which the VPN route CE device. There are also intermediate cases in which the VPN route
label may determine the packet's egress attachment circuit, but a label may determine the packet's egress attachment circuit, but a
lookup (e.g., ARP) still needs to be done in order to determine the lookup (e.g., ARP) still needs to be done in order to determine the
packet's data link header on that attachment circuit. packet's data link header on that attachment circuit.
skipping to change at page 27, line 42 skipping to change at page 26, line 14
scheme. The backbone does not even need to have routes to the CEs, scheme. The backbone does not even need to have routes to the CEs,
only to the PEs. only to the PEs.
With respect to the tunnels, it is worth noting that this With respect to the tunnels, it is worth noting that this
specification: specification:
- DOES NOT require that the tunnels be point-to-point; multipoint- - DOES NOT require that the tunnels be point-to-point; multipoint-
to-point can be used; to-point can be used;
- DOES NOT require that there be any explicit setup of the tunnels, - DOES NOT require that there be any explicit setup of the tunnels,
either via signaling or via manual configuration. either via signaling or via manual configuration;
- DOES NOT require that there be any tunnel-specific signaling; - DOES NOT require that there be any tunnel-specific signaling;
- DOES NOT require that there be any tunnel-specific state in the P - DOES NOT require that there be any tunnel-specific state in the P
or PE routers, beyond what is necessary to maintain the routing or PE routers, beyond what is necessary to maintain the routing
information and (if used) the MPLS label information. information and (if used) the MPLS label information.
Of course, this specification is compatible with the use of point- Of course, this specification is compatible with the use of point-
to-point tunnels that must be explicitly configured and/or signaled, to-point tunnels that must be explicitly configured and/or signaled,
and in some situations there may be reasons for using such tunnels. and in some situations there may be reasons for using such tunnels.
The considerations which are relevant to choosing a particular The considerations that are relevant to choosing a particular
tunneling technology are outside the scope of this specification. tunneling technology are outside the scope of this specification.
6. Maintaining Proper Isolation of VPNs 6. Maintaining Proper Isolation of VPNs
To maintain proper isolation of one VPN from another, it is important To maintain proper isolation of one VPN from another, it is important
that no router in the backbone accept a tunneled packet from outside that no router in the backbone accept a tunneled packet from outside
the backbone, unless it is sure that both endpoints of that tunnel the backbone, unless it is sure that both endpoints of that tunnel
are outside the backbone. are outside the backbone.
If MPLS is being used as the tunneling technology, this means that a If MPLS is being used as the tunneling technology, this means that a
skipping to change at page 29, line 7 skipping to change at page 27, line 17
backbone devices refuse to accept labeled packets from non-backbone backbone devices refuse to accept labeled packets from non-backbone
devices. devices.
If MPLS is not being used as the tunneling technology, then filtering If MPLS is not being used as the tunneling technology, then filtering
must be done to ensure that an MPLS-in-IP or MPLS-in-GRE packet can must be done to ensure that an MPLS-in-IP or MPLS-in-GRE packet can
be accepted into the backbone only if the packet's IP destination be accepted into the backbone only if the packet's IP destination
address will cause it to be sent outside the backbone. address will cause it to be sent outside the backbone.
7. How PEs Learn Routes from CEs 7. How PEs Learn Routes from CEs
The PE routers which attach to a particular VPN need to know, for The PE routers that attach to a particular VPN need to know, for each
each attachment circuit leading to that VPN, which of the VPN's attachment circuit leading to that VPN, which of the VPN's addresses
addresses should be reached over that attachment circuit. should be reached over that attachment circuit.
The PE translates these addresses into VPN-IPv4 addresses, using a The PE translates these addresses into VPN-IPv4 addresses, using a
configured RD. The PE then treats these VPN-IPv4 routes as input to configured RD. The PE then treats these VPN-IPv4 routes as input to
BGP. Routes from a VPN site are NOT leaked into the backbone's IGP. BGP. Routes from a VPN site are NOT leaked into the backbone's IGP.
Exactly which PE/CE route distribution techniques are possible Exactly which PE/CE route distribution techniques are possible
depends on whether a particular CE is in a "transit VPN" or not. A depends on whether or not a particular CE is in a "transit VPN". A
"transit VPN" is one which contains a router that receives routes "transit VPN" is one that contains a router that receives routes from
from a "third party" (i.e., from a router which is not in the VPN, a "third party" (i.e., from a router that is not in the VPN, but is
but is not a PE router), and that redistributes those routes to a PE not a PE router) and that redistributes those routes to a PE router.
router. A VPN which is not a transit VPN is a "stub VPN". The vast A VPN that is not a transit VPN is a "stub VPN". The vast majority
majority of VPNs, including just about all corporate enterprise of VPNs, including just about all corporate enterprise networks,
networks, would be expected to be "stubs" in this sense. would be expected to be "stubs" in this sense.
The possible PE/CE distribution techniques are: The possible PE/CE distribution techniques are:
1. Static routing (i.e., configuration) may be used. (This is 1. Static routing (i.e., configuration) may be used. (This is
likely to be useful only in stub VPNs.) likely to be useful only in stub VPNs.)
2. PE and CE routers may be RIP ("Routing Information Protocol", 2. PE and CE routers may be Routing Information Protocol (RIP)
[RIP]) peers, and the CE may use RIP to tell the PE router the [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 set of address prefixes that are reachable at the CE router's
site. When RIP is configured in the CE, care must be taken to site. When RIP is configured in the CE, care must be taken to
ensure that address prefixes from other sites (i.e., address ensure that address prefixes from other sites (i.e., address
prefixes learned by the CE router from the PE router) are never prefixes learned by the CE router from the PE router) are never
advertised to the PE. More precisely: if a PE router, say advertised to the PE. More precisely: if a PE router, say,
PE1, receives a VPN-IPv4 route R1, and as a result distributes PE1, receives a VPN-IPv4 route R1, and as a result distributes
an IPv4 route R2 to a CE, then R2 must not be distributed back 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 from that CE's site to a PE router, say, PE2, (where PE1 and
may be the same router or different routers), unless PE2 maps PE2 may be the same router or different routers), unless PE2
R2 to a VPN-IPv4 route which is different than (i.e., contains maps R2 to a VPN-IPv4 route that is different than (i.e.,
a different RD than) R1. contains a different RD than) R1.
3. The PE and CE routers may be OSPF peers. A PE router which is 3. The PE and CE routers may be OSPF peers. A PE router that is
an OSPF peer of a CE router appears, to the CE router, to be an an OSPF peer of a CE router appears, to the CE router, to be an
area 0 router. If a PE router is an OSPF peer of CE routers area 0 router. If a PE router is an OSPF peer of CE routers
which are in distinct VPNs, the PE must of course be running that are in distinct VPNs, the PE must of course be running
multiple instances of OSPF. multiple instances of OSPF.
IPv4 routes which the PE learns from the CE via OSPF are IPv4 routes that the PE learns from the CE via OSPF are
redistributed into BGP as VPN-IPv4 routes. Extended community redistributed into BGP as VPN-IPv4 routes. Extended Community
attributes are used to carry, along with the route, all the attributes are used to carry, along with the route, all the
information needed to enable the route to be distributed to information needed to enable the route to be distributed to
other CE routers in the VPN in the proper type of OSPF LSA. other CE routers in the VPN in the proper type of OSPF Link
OSPF route tagging is used to ensure that routes received from State Advertisement (LSA). OSPF route tagging is used to
the MPLS/BGP backbone are not sent back into the backbone. ensure that routes received from the MPLS/BGP backbone are not
sent back into the backbone.
Specification of the complete set of procedures for the use of Specification of the complete set of procedures for the use of
OSPF between PE and CE can be found in [VPN-OSPF] and [OSPF- OSPF between PE and CE can be found in [VPN-OSPF] and
2547-DNBIT]. [OSPF-2547-DNBIT].
4. The PE and CE routers may be BGP peers, and the CE router may 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 use BGP (in particular, EBGP to tell the PE router the set of
address prefixes which are at the CE router's site. (This address prefixes that are at the CE router's site. (This
technique can be used in stub VPNs or transit VPNs.) technique can be used in stub VPNs or transit VPNs.)
This technique has a number of advantages over the others: This technique has a number of advantages over the others:
a) Unlike the IGP alternatives, this does not require the PE a) Unlike the IGP alternatives, this does not require the PE
to run multiple routing algorithm instances in order to to run multiple routing algorithm instances in order to
talk to multiple CEs talk to multiple CEs.
b) BGP is explicitly designed for just this function: b) BGP is explicitly designed for just this function:
passing routing information between systems run by passing routing information between systems run by
different administrations different administrations.
c) If the site contains "BGP backdoors", i.e., routers with c) If the site contains "BGP backdoors", i.e., routers with
BGP connections to routers other than PE routers, this BGP connections to routers other than PE routers, this
procedure will work correctly in all circumstances. The procedure will work correctly in all circumstances. The
other procedures may or may not work, depending on the other procedures may or may not work, depending on the
precise circumstances. precise circumstances.
d) Use of BGP makes it easy for the CE to pass attributes of d) Use of BGP makes it easy for the CE to pass attributes of
the routes to the PE. A complete specification of the the routes to the PE. A complete specification of the
set of attributes and their use is outside the scope of set of attributes and their use is outside the scope of
skipping to change at page 31, line 17 skipping to change at page 29, line 30
coordination with the SP. coordination with the SP.
On the other hand, using BGP may be something new for the CE On the other hand, using BGP may be something new for the CE
administrators. administrators.
If a site is not in a transit VPN, note that it need not have a 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 is unique Autonomous System Number (ASN). Every CE whose site is
not in a transit VPN can use the same ASN. This can be chosen 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 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 PE. Routing loops are prevented by use of the Site of Origin
Attribute (see below). attribute (see below).
What if a set of sites constitute a transit VPN? This will What if a set of sites constitutes a transit VPN? This will
generally be the case only if the VPN is itself an Internet generally be the case only if the VPN is itself an Internet
Service Provider's (ISP's) network, where the ISP is itself Service Provider's (ISP's) network, where the ISP is itself
buying backbone services from another SP. The latter SP may be buying backbone services from another SP. The latter SP may be
called a "Carrier's Carrier". In this case, the best way to called a "carrier's carrier". In this case, the best way to
provide the VPN is to have the CE routers support MPLS, and to provide the VPN is to have the CE routers support MPLS, and to
use the technique described in section 9. use the technique described in Section 9.
When we do not need to distinguish among the different ways in which 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 a PE can be informed of the address prefixes that exist at a given
site, we will simply say that the PE has "learned" the routes from site, we will simply say that the PE has "learned" the routes from
that site. This includes the case where the PE has been manually that site. This includes the case where the PE has been manually
configured with the routes. configured with the routes.
Before a PE can redistribute a VPN-IPv4 route learned from a site, it Before a PE can redistribute a VPN-IPv4 route learned from a site, it
must assign a Route Target attribute (see section 4.3.1) to the must assign a Route Target attribute (see Section 4.3.1) to the
route, and it may assign a Site of Origin attribute to the route. route, and it may assign a Site of Origin attribute to the route.
The Site of Origin attribute, if used, is encoded as a Route Origin The Site of Origin attribute, if used, is encoded as a Route Origin
Extended Community [BGP-EXTCOMM]. The purpose of this attribute is Extended Community [BGP-EXTCOMM]. The purpose of this attribute is
to uniquely identify the set of routes learned from a particular to uniquely identify the set of routes learned from a particular
site. This attribute is needed in some cases to ensure that a route site. This attribute is needed in some cases to ensure that a route
learned from a particular site via a particular PE/CE connection is learned from a particular site via a particular PE/CE connection is
not distributed back to the site through a different PE/CE not distributed back to the site through a different PE/CE
connection. It is particularly useful if BGP is being used as the connection. It is particularly useful if BGP is being used as the
PE/CE protocol, but different sites have not been assigned distinct PE/CE protocol, but different sites have not been assigned distinct
ASNs. ASNs.
8. How CEs learn Routes from PEs 8. How CEs Learn Routes from PEs
In this section, we assume that the CE device is a router. In this section, we assume that the CE device is a router.
If the PE places a particular route in the VRF it uses to route If the PE places a particular route in the VRF it uses to route
packets received from a particular CE, then in general, the PE may packets received from a particular CE, then in general, the PE may
distribute that route to the CE. Of course the PE may distribute distribute that route to the CE. Of course, the PE may distribute
that route to the CE only if this is permitted by the rules of the that route to the CE only if this is permitted by the rules of the
PE/CE protocol. (For example, if a particular PE/CE protocol has PE/CE protocol. (For example, if a particular PE/CE protocol has
"split horizon", certain routes in the VRF cannot be redistributed "split horizon", certain routes in the VRF cannot be redistributed
back to the CE.) We add one more restriction on the distribution of back to the CE.) We add one more restriction on the distribution of
routes from PE to CE: if a route's Site of Origin attribute routes from PE to CE: if a route's Site of Origin attribute
identifies a particular site, that route must never be redistributed identifies a particular site, that route must never be redistributed
to any CE at that site. to any CE at that site.
In most cases, however, it will be sufficient for the PE to simply 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 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 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 pointing to the PE.) This will generally work at any site that does
not itself need to distribute the default route to other sites. 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 (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 the Internet, that site might need to have default distributed to the
other site, but one could not distribute default to that site other site, but one could not distribute default to that site
itself.) itself.)
Whatever procedure is used to distribute routes from CE to PE will Whatever procedure is used to distribute routes from CE to PE will
also be used to distribute routes from PE to CE. also be used to distribute routes from PE to CE.
9. Carriers' Carriers 9. Carriers' Carriers
Sometimes a VPN may actually be the network of an ISP, with its own Sometimes a VPN may actually be the network of an ISP, with its own
peering and routing policies. Sometimes a VPN may be the network of peering and routing policies. Sometimes a VPN may be the network of
an SP which is offering VPN services in turn to its own customers. an SP that is offering VPN services in turn to its own customers.
VPNs like these can also obtain backbone service from another SP, the VPNs like these can also obtain backbone service from another SP, the
"carrier's carrier", using essentially the same methods described in "carrier's carrier", using essentially the same methods described in
this document. However, it is necessary in these cases that the CE this document. However, it is necessary in these cases that the CE
routers support MPLS. In particular: routers support MPLS. In particular:
- The CE routers should distribute to the PE routers ONLY those - The CE routers should distribute to the PE routers ONLY those
routes which are internal to the VPN. This allows the VPN to be routes that are internal to the VPN. This allows the VPN to be
handled as a stub VPN. handled as a stub VPN.
- The CE routers should support MPLS, in that they should be able - The CE routers should support MPLS, in that they should be able
to receive labels from the PE routers, and send labeled packets to receive labels from the PE routers, and send labeled packets
to the PE routers. They do not need to distribute labels of to the PE routers. They do not need to distribute labels of
their own though. their own, though.
- The PE routers should distribute, to the CE routers, labels for - The PE routers should distribute, to the CE routers, labels for
the routes they distribute to the CE routers. the routes they distribute to the CE routers.
The PE must not distribute the same label to two different CEs The PE must not distribute the same label to two different CEs
unless one of the following conditions holds: unless one of the following conditions holds:
* The two CEs are associated with exactly the same set of VRFs; * The two CEs are associated with exactly the same set of VRFs;
* The PE maintains a different Incoming Label Map ([MPLS-ARCH]) * The PE maintains a different Incoming Label Map ([MPLS-ARCH])
for each CE. for each CE.
Further, when the PE receives a labeled packet from a CE, it must Further, when the PE receives a labeled packet from a CE, it must
verify that the top label is one that was distributed to that CE. verify that the top label is one that was distributed to that CE.
- Routers at the different sites should establish BGP connections - Routers at the different sites should establish BGP connections
among themselves for the purpose of exchanging external routes among themselves for the purpose of exchanging external routes
(i.e., routes which lead outside of the VPN). (i.e., routes that lead outside of the VPN).
- All the external routes must be known to the CE routers. - All the external routes must be known to the CE routers.
Then when a CE router looks up a packet's destination address, the Then when a CE router looks up a packet's destination address, the
routing lookup will resolve to an internal address, usually the routing lookup will resolve to an internal address, usually the
address of the packet's BGP next hop. The CE labels the packet address of the packet's BGP next hop. The CE labels the packet
appropriately and sends the packet to the PE. The PE, rather than appropriately and sends the packet to the PE. The PE, rather than
looking up the packet's IP destination address in a VRF, uses the looking up the packet's IP destination address in a VRF, uses the
packet's top MPLS label to select the "BGP next hop". As a result, packet's top MPLS label to select the BGP next hop. As a result, if
if the BGP next hop is more than one hop away, the top label will be the BGP next hop is more than one hop away, the top label will be
replaced by two labels, a tunnel label and a VPN route label. If the replaced by two labels, a tunnel label and a VPN route label. If the
BGP next hop is one hop away, the top label may be replaced by just BGP next hop is one hop away, the top label may be replaced by just
the VPN route label. If the ingress PE is also the egress PE, the the VPN route label. If the ingress PE is also the egress PE, the
top label will just be popped. When the packet is sent from its top label will just be popped. When the packet is sent from its
egress PE to a CE, the packet will have one fewer MPLS labels than it egress PE to a CE, the packet will have one fewer MPLS labels than it
had when it was first received by its ingress PE. had when it was first received by its ingress PE.
In the above procedure, the CE routers are the only routers in the In the above procedure, the CE routers are the only routers in the
VPN which need to support MPLS. If, on the other hand, all the VPN that need to support MPLS. If, on the other hand, all the
routers at a particular VPN site support MPLS, then it is no longer routers at a particular VPN site support MPLS, then it is no longer
required that the CE routers know all the external routes. All that required that the CE routers know all the external routes. All that
is required is that the external routes be known to whatever routers is required is that the external routes be known to whatever routers
are responsible for putting the label stack on a hitherto unlabeled are responsible for putting the label stack on a hitherto unlabeled
packet, and that there be label switched path that leads from those packet and that there be label switched path that leads from those
routers to their BGP peers at other sites. In this case, for each routers to their BGP peers at other sites. In this case, for each
internal route that a CE router distributes to a PE router, it must internal route that a CE router distributes to a PE router, it must
also distribute a label. also distribute a label.
10. Multi-AS Backbones 10. Multi-AS Backbones
What if two sites of a VPN are connected to different Autonomous What if two sites of a VPN are connected to different Autonomous
Systems (e.g., because the sites are connected to different SPs)? Systems (e.g., because the sites are connected to different SPs)?
The PE routers attached to that VPN will then not be able to maintain The PE routers attached to that VPN will then not be able to maintain
IBGP connections with each other, or with a common route reflector. IBGP connections with each other, or with a common route reflector.
skipping to change at page 34, line 41 skipping to change at page 32, line 43
b) EBGP redistribution of labeled VPN-IPv4 routes from AS to b) EBGP redistribution of labeled VPN-IPv4 routes from AS to
neighboring AS. neighboring AS.
In this procedure, the PE routers use IBGP to redistribute In this procedure, the PE routers use IBGP to redistribute
labeled VPN-IPv4 routes either to an Autonomous System Border labeled VPN-IPv4 routes either to an Autonomous System Border
Router (ASBR), or to a route reflector of which an ASBR is a Router (ASBR), or to a route reflector of which an ASBR is a
client. The ASBR then uses EBGP to redistribute those labeled client. The ASBR then uses EBGP to redistribute those labeled
VPN-IPv4 routes to an ASBR in another AS, which in turn VPN-IPv4 routes to an ASBR in another AS, which in turn
distributes them to the PE routers in that AS, or perhaps to distributes them to the PE routers in that AS, or perhaps to
another ASBR which in turn distributes them ... another ASBR which in turn distributes them, and so on.
When using this procedure, VPN-IPv4 routes should only be When using this procedure, VPN-IPv4 routes should only be
accepted on EBGP connections at private peering points, as part accepted on EBGP connections at private peering points, as part
of a trusted arrangement between SPs. VPN-IPv4 routes should of a trusted arrangement between SPs. VPN-IPv4 routes should
neither be distributed to nor accepted from the public neither be distributed to nor accepted from the public
Internet, or from any BGP peers which are not trusted. An ASBR Internet, or from any BGP peers that are not trusted. An ASBR
should never accept a labeled packet from an EBGP peer unless should never accept a labeled packet from an EBGP peer unless
it has actually distributed the top label to that peer. it has actually distributed the top label to that peer.
If there are many VPNs having sites attached to different If there are many VPNs having sites attached to different
Autonomous Systems, there does not need to be a single ASBR Autonomous Systems, there does not need to be a single ASBR
between those two ASes which holds all the routes for all the between those two ASes that holds all the routes for all the
VPNs; there can be multiple ASBRs, each of which holds only the VPNs; there can be multiple ASBRs, each of which holds only the
routes for a particular subset of the VPNs. routes for a particular subset of the VPNs.
This procedure requires that there be a label switched path This procedure requires that there be a label switched path
leading from a packet's ingress PE to its egress PE. Hence the leading from a packet's ingress PE to its egress PE. Hence the
appropriate trust relationships must exist between and among appropriate trust relationships must exist between and among
the set of ASes along the path. Also, there must be agreement the set of ASes along the path. Also, there must be agreement
among the set of SPs as to which border routers need to receive among the set of SPs as to which border routers need to receive
routes with which Route Targets. routes with which Route Targets.
c) Multihop EBGP redistribution of labeled VPN-IPv4 routes between c) Multi-hop EBGP redistribution of labeled VPN-IPv4 routes
source and destination ASes, with EBGP redistribution of between source and destination ASes, with EBGP redistribution
labeled IPv4 routes from AS to neighboring AS. of labeled IPv4 routes from AS to neighboring AS.
In this procedure, VPN-IPv4 routes are neither maintained nor In this procedure, VPN-IPv4 routes are neither maintained nor
distributed by the ASBRs. An ASBR must maintain labeled IPv4 distributed by the ASBRs. An ASBR must maintain labeled IPv4
/32 routes to the PE routers within its AS. It uses EBGP to /32 routes to the PE routers within its AS. It uses EBGP to
distribute these routes to other ASes. ASBRs in any transit distribute these routes to other ASes. ASBRs in any transit
ASes will also have to use EBGP to pass along the labeled /32 ASes will also have to use EBGP to pass along the labeled /32
routes. This results in the creation of a label switched path routes. This results in the creation of a label switched path
from the ingress PE router to the egress PE router. Now PE from the ingress PE router to the egress PE router. Now PE
routers in different ASes can establish multi-hop EBGP routers in different ASes can establish multi-hop EBGP
connections to each other, and can exchange VPN-IPv4 routes connections to each other, and can exchange VPN-IPv4 routes
over those connections. over those connections.
If the /32 routes for the PE routers are made known to the P If the /32 routes for the PE routers are made known to the P
routers of each AS, everything works normally. If the /32 routers of each AS, everything works normally. If the /32
routes for the PE routers are NOT made known to the P routers routes for the PE routers are NOT made known to the P routers
(other than the ASBRs), then this procedure requires a packet's (other than the ASBRs), then this procedure requires a packet's
ingress PE to put a three label stack on it. The bottom label ingress PE to put a three-label stack on it. The bottom label
is assigned by the egress PE, corresponding to the packet's is assigned by the egress PE, corresponding to the packet's
destination address in a particular VRF. The middle label is destination address in a particular VRF. The middle label is
assigned by the ASBR, corresponding to the /32 route to the assigned by the ASBR, corresponding to the /32 route to the
egress PE. The top label is assigned by the ingress PE's IGP egress PE. The top label is assigned by the ingress PE's IGP
Next Hop, corresponding to the /32 route to the ASBR. Next Hop, corresponding to the /32 route to the ASBR.
To improve scalability, one can have the multi-hop EBGP To improve scalability, one can have the multi-hop EBGP
connections exist only between a route reflector in one AS and connections exist only between a route reflector in one AS and
a route reflector in another. (However, when the route a route reflector in another. (However, when the route
reflectors distribute routes over this connection, they do not reflectors distribute routes over this connection, they do not
modify the BGP next hop attribute of the routes.) The actual modify the BGP next hop attribute of the routes.) The actual
PE routers would then only have IBGP connections to the route PE routers would then only have IBGP connections to the route
reflectors in their own AS. reflectors in their own AS.
This procedure is very similar to the "Carrier's Carrier" This procedure is very similar to the "carrier's carrier"
procedures described in section 9. Like the previous procedure, procedures described in Section 9. Like the previous
it requires that there be a label switched path leading from a procedure, it requires that there be a label switched path
packet's ingress PE to its egress PE. leading from a packet's ingress PE to its egress PE.
11. Accessing the Internet from a VPN 11. Accessing the Internet from a VPN
Many VPN sites will need to be able to access the public Internet, as Many VPN sites will need to be able to access the public Internet, as
well as to access other VPN sites. The following describes some of well as to access other VPN sites. The following describes some of
the alternative ways of doing this. the alternative ways of doing this.
1. In some VPNs, one or more of the sites will obtain Internet 1. In some VPNs, one or more of the sites will obtain Internet
Access by means of an "Internet gateway" (perhaps a firewall) access by means of an "Internet gateway" (perhaps a firewall)
attached to a non-VRF interface to an ISP. The ISP may or may attached to a non-VRF interface to an ISP. The ISP may or may
not be the same organization as the SP which is providing the not be the same organization as the SP that is providing the
VPN service. Traffic to/from the Internet gateway would then VPN service. Traffic to/from the Internet gateway would then
be routed according to the PE router's default forwarding be routed according to the PE router's default forwarding
table. table.
In this case, the sites which have Internet Access may be In this case, the sites that have Internet access may be
distributing a default route to their PEs, which in turn distributing a default route to their PEs, which in turn
redistribute it to other PEs and hence into other sites of the redistribute it to other PEs and hence into other sites of the
VPN. This provides Internet Access for all of the VPN's sites. VPN. This provides Internet access for all of the VPN's sites.
In order to properly handle traffic from the Internet, the ISP In order to properly handle traffic from the Internet, the ISP
must distribute, to the Internet, routes leading to addresses must distribute, to the Internet, routes leading to addresses
that are within the VPN. This is completely independent of any that are within the VPN. This is completely independent of any
of the route distribution procedures described in this of the route distribution procedures described in this
document. The internal structure of the VPN will in general document. The internal structure of the VPN will in general
not be visible from the Internet; such routes would simply lead not be visible from the Internet; such routes would simply lead
to the non-VRF interface that attaches to the VPN's Internet to the non-VRF interface that attaches to the VPN's Internet
gateway. gateway.
In this model, there is no exchange of routes between a PE In this model, there is no exchange of routes between a PE
router's default forwarding table and any of its VRFs. VPN router's default forwarding table and any of its VRFs. VPN
route distribution procedures and Internet route distribution route distribution procedures and Internet route distribution
procedures are completely independent. procedures are completely independent.
Note that although some sites of the VPN use a VRF interface to Note that although some sites of the VPN use a VRF interface to
communicate with the Internet, ultimately all packets to/from communicate with the Internet, ultimately all packets to/from
the Internet traverse a non-VRF interface before the Internet traverse a non-VRF interface before
leaving/entering the VPN, so we refer to this as "non-VRF leaving/entering the VPN, so we refer to this as "non-VRF
Internet Access". Internet access".
Note that the PE router to which the non-VRF interface attaches Note that the PE router to which the non-VRF interface attaches
does not necessarily need to maintain all the Internet routes does not necessarily need to maintain all the Internet routes
in its default forwarding table. The default forwarding table in its default forwarding table. The default forwarding table
could have as few as one route, "default", which leads to could have as few as one route, "default", which leads to
another router (probably an adjacent one) which has the another router (probably an adjacent one) that has the Internet
Internet routes. A variation of this scheme is to tunnel routes. A variation of this scheme is to tunnel packets
packets received over the non-VRF interface from the PE router received over the non-VRF interface from the PE router to
to another router, where this other router maintains the full another router, where this other router maintains the full set
set of Internet routes. of Internet routes.
2. Some VPNs may obtain Internet access via a VRF interface ("VRF 2. Some VPNs may obtain Internet access via a VRF interface ("VRF
Internet Access"). If a packet is received by a PE over a VRF Internet access"). If a packet is received by a PE over a VRF
interface, and if the packet's destination address does not interface, and if the packet's destination address does not
match any route in the VRF, then it may be matched against the match any route in the VRF, then it may be matched against the
PE's default forwarding table. If a match is made there, the PE's default forwarding table. If a match is made there, the
packet can be forwarded natively through the backbone to the packet can be forwarded natively through the backbone to the
Internet, instead of being forwarded by MPLS. Internet, instead of being forwarded by MPLS.
In order for traffic to flow natively in the opposite direction In order for traffic to flow natively in the opposite direction
(from Internet to VRF interface), some of the routes from the (from Internet to VRF interface), some of the routes from the
VRF must be exported to the Internet forwarding table. VRF must be exported to the Internet forwarding table.
Needless to say, any such routes must correspond to globally Needless to say, any such routes must correspond to globally
unique addresses. unique addresses.
In this scheme, the default forwarding table might have the In this scheme, the default forwarding table might have the
full set of Internet routes, or it might have a little as a full set of Internet routes, or it might have as little as a
single default route leading to another router which does have single default route leading to another router that does have
the full set of Internet routes in its default forwarding the full set of Internet routes in its default forwarding
table. table.
3. Suppose the PE has the capability to store "non-VPN routes" in 3. Suppose the PE has the capability to store "non-VPN routes" in
a VRF. If a packet's destination address matches a "non-VPN a VRF. If a packet's destination address matches a "non-VPN
route", then the packet is transmitted natively, rather than route", then the packet is transmitted natively, rather than
being transmitted via MPLS. If the VRF contains a non-VPN being transmitted via MPLS. If the VRF contains a non-VPN
default route, all packets for the public Internet will match default route, all packets for the public Internet will match
it, and be forwarded natively to the default route's next hop. it, and be forwarded natively to the default route's next hop.
At that next hop, the packets' destination addresses will be At that next hop, the packets' destination addresses will be
skipping to change at page 37, line 49 skipping to change at page 36, line 4
routers is distributing a default route. routers is distributing a default route.
4. It is also possible to obtain Internet access via a VRF 4. It is also possible to obtain Internet access via a VRF
interface by having the VRF contain the Internet routes. interface by having the VRF contain the Internet routes.
Compared with model 2, this eliminates the second lookup, but Compared with model 2, this eliminates the second lookup, but
it has the disadvantage of requiring the Internet routes to be it has the disadvantage of requiring the Internet routes to be
replicated in each such VRF. replicated in each such VRF.
If this technique is used, the SP may want to make its If this technique is used, the SP may want to make its
interface to the Internet be a VRF interface, and to use the interface to the Internet be a VRF interface, and to use the
techniques of section 4 to distribute Internet routes, as VPN- techniques of Section 4 to distribute Internet routes, as VPN-
IPv4 routes, to other VRFs. IPv4 routes, to other VRFs.
It should be clearly understood that by default, there is no exchange It should be clearly understood that by default, there is no exchange
of routes between a VRF and the default forwarding table. This is of routes between a VRF and the default forwarding table. This is
done ONLY upon agreement between a customer and a SP, and only if it done ONLY upon agreement between a customer and an SP, and only if it
suits the customer's policies. suits the customer's policies.
12. Management VPNs 12. Management VPNs
This specification does not require that the sub-interface connecting This specification does not require that the sub-interface connecting
a PE router and a CE router be a "numbered" interface. If it is a a PE router and a CE router be a "numbered" interface. If it is a
numbered interface, this specification allows the addresses assigned numbered interface, this specification allows the addresses assigned
to the interface to come from either the address space of the VPN or to the interface to come from either the address space of the VPN or
the address space of the SP. the address space of the SP.
If a CE router is being managed by the Service Provider, then the If a CE router is being managed by the Service Provider, then the
Service Provider will likely have a network management system which Service Provider will likely have a network management system that
needs to be able to communicate with the CE router. In this case, needs to be able to communicate with the CE router. In this case,
the addresses assigned to the sub-interface connecting the CE and PE the addresses assigned to the sub-interface connecting the CE and PE
routers should come from the SP's address space, and should be unique routers should come from the SP's address space, and should be unique
within that space. The network management system should itself within that space. The network management system should itself
connect to a PE router (more precisely, be at a site which connects connect to a PE router (more precisely, be at a site that connects to
to a PE router) via a VRF interface. The address of the network a PE router) via a VRF interface. The address of the network
management system will be exported to all VRFs which are associated management system will be exported to all VRFs that are associated
with interfaces to CE routers that are managed by the SP. The with interfaces to CE routers that are managed by the SP. The
addresses of the CE routers will be exported to the VRF associated addresses of the CE routers will be exported to the VRF associated
with the Network Management system, but not to any other VRFs. with the network management system, but not to any other VRFs.
This allows communication between CE and Network Management system, This allows communication between the CE and network management
but does not allow any undesired communication to or among the CE system, but does not allow any undesired communication to or among
routers. the CE routers.
One way to ensure that the proper route import/exports are done is to One way to ensure that the proper route import/exports are done is to
use two Route Targets, call them T1 and T2. If a particular VRF use two Route Targets; call them T1 and T2. If a particular VRF
interface attaches to a CE router that is managed by the SP, then interface attaches to a CE router that is managed by the SP, then
that VRF is configured to: that VRF is configured to:
- import routes that have T1 attached to them, and - import routes that have T1 attached to them, and
- attach T2 to addresses assigned to each end of its VRF - attach T2 to addresses assigned to each end of its VRF
interfaces. interfaces.
If a particular VRF interface attaches to the SP's Network Management If a particular VRF interface attaches to the SP's network management
system, then that VRF is configured to attach T1 to the address of system, then that VRF is configured to attach T1 to the address of
that system, and to import routes that have T2 attached to them. that system, and to import routes that have T2 attached to them.
13. Security Considerations 13. Security Considerations
13.1. Data Plane 13.1. Data Plane
By security in the "data plane", we mean protection against the By security in the "data plane", we mean protection against the
following possibilities: following possibilities:
skipping to change at page 39, line 40 skipping to change at page 37, line 40
the data plane security provided by this architecture is virtually the data plane security provided by this architecture is virtually
identical to that provided to VPNs by Frame Relay or ATM backbones. identical to that provided to VPNs by Frame Relay or ATM backbones.
If the devices under the control of the SP are properly configured, If the devices under the control of the SP are properly configured,
data will not enter or leave a VPN unless authorized to do so. data will not enter or leave a VPN unless authorized to do so.
Condition 1 above can be stated more precisely. One should discard a Condition 1 above can be stated more precisely. One should discard a
labeled packet received from a particular neighbor unless one of the labeled packet received from a particular neighbor unless one of the
following two conditions holds: following two conditions holds:
- the packet's top label has a label value which the receiving - the packet's top label has a label value that the receiving
system has distributed to that neighbor, or system has distributed to that neighbor, or
- the packet's top label has a label value which the receiving - the packet's top label has a label value that the receiving
system has distributed to a system beyond that neighbor (i.e., system has distributed to a system beyond that neighbor (i.e.,
when it is known that the path from the system to which the label when it is known that the path from the system to which the label
was distributed to the receiving system may be via that was distributed to the receiving system may be via that
neighbor). neighbor).
Condition 2 above is of most interest in the case of inter-provider Condition 2 above is of most interest in the case of inter-provider
VPNs (see section 10). For inter-provider VPNs constructed according VPNs (see Section 10). For inter-provider VPNs constructed according
to scheme b) of section 10, condition 2 is easily checked. (The to scheme b) of Section 10, condition 2 is easily checked. (The
issue of security when scheme c) of section 10 is used is for further issue of security when scheme (c) of Section 10 is used is for
study.) further study.)
It is worth noting that the use of MPLS makes it much simpler to It is worth noting that the use of MPLS makes it much simpler to
provide data plane security than might be possible if one attempted provide data plane security than might be possible if one attempted
to use some form of IP tunneling in place of the MPLS outer label. to use some form of IP tunneling in place of the MPLS outer label.
It is a simple matter to have one's border routers refuse to accept a It is a simple matter to have one's border routers refuse to accept a
labeled packet unless the first of the above conditions applies to labeled packet unless the first of the above conditions applies to
it. It is rather more difficult to configure a router to refuse to it. It is rather more difficult to configure a router to refuse to
accept an IP packet if that packet is an IP tunneled packet whose accept an IP packet if that packet is an IP tunneled packet whose
destination address is that of a PE router; certainly this is not destination address is that of a PE router; certainly, this is not
impossible to do, but it has both management and performance impossible to do, but it has both management and performance
implications. implications.
MPLS-in-IP and MPLS-in-GRE tunneling are specified in [MPLS-in-IP- MPLS-in-IP and MPLS-in-GRE tunneling are specified in
GRE]. If it is desired to use such tunnels to carry VPN packets, [MPLS-in-IP-GRE]. If it is desired to use such tunnels to carry VPN
then the security considerations described in section 8 of that packets, then the security considerations described in Section 8 of
document must be fully understood. Any implementation of BGP/MPLS IP that document must be fully understood. Any implementation of
VPNs which allows VPN packets to be tunneled as described in that BGP/MPLS IP VPNs that allows VPN packets to be tunneled as described
document MUST contain an implementation of IPsec which can be used as in that document MUST contain an implementation of IPsec that can be
therein described. If the tunnel is not secured by IPsec, then the used as therein described. If the tunnel is not secured by IPsec,
technique of IP address filtering at the border routers, described in then the technique of IP address filtering at the border routers,
section 8.2 of that document, is the only means of ensuring that a described in Section 8.2 of that document, is the only means of
packet which exits the tunnel at a particular egress PE was actually ensuring that a packet that exits the tunnel at a particular egress
placed in the tunnel by the proper tunnel head node (i.e., that the PE was actually placed in the tunnel by the proper tunnel head node
packet does not have a spoofed source address). Since border routers (i.e., that the packet does not have a spoofed source address).
frequently filter only source addresses, packet filtering may not be Since border routers frequently filter only source addresses, packet
effective unless the egress PE can check the IP source address of any filtering may not be effective unless the egress PE can check the IP
tunneled packet it receives, and compare it to a list of IP addresses source address of any tunneled packet it receives, and compare it to
which are valid tunnel head addresses. Any implementation which a list of IP addresses that are valid tunnel head addresses. Any
allows MPLS-in-IP and/or MPLS-in-GRE tunneling to be used without implementation that allows MPLS-in-IP and/or MPLS-in-GRE tunneling to
IPsec MUST allow the egress PE to validate in this manner the IP be used without IPsec MUST allow the egress PE to validate in this
source address of any tunneled packet that it receives. manner the IP source address of any tunneled packet that it receives.
In the case where a number of CE routers attach to a PE router via a In the case where a number of CE routers attach to a PE router via a
LAN interface, to ensure proper security, one of the following LAN interface, to ensure proper security, one of the following
conditions must hold: conditions must hold:
1. All the CE routers on the LAN belong to the same VPN, or 1. All the CE routers on the LAN belong to the same VPN, or
2. A trusted and secured LAN switch divides the LAN into multiple 2. A trusted and secured LAN switch divides the LAN into multiple
VLANs, with each VLAN containing only systems of a single VPN; VLANs, with each VLAN containing only systems of a single VPN;
in this case the switch will attach the appropriate VLAN tag to in this case, the switch will attach the appropriate VLAN tag
any packet before forwarding it to the PE router. to any packet before forwarding it to the PE router.
Cryptographic privacy is not provided by this architecture, nor by Cryptographic privacy is not provided by this architecture, nor by
Frame Relay or ATM VPNs. These architectures are all compatible with Frame Relay or ATM VPNs. These architectures are all compatible with
the use of cryptography on a CE-CE basis, if that is desired. the use of cryptography on a CE-CE basis, if that is desired.
The use of cryptography on a PE-PE basis is for further study. The use of cryptography on a PE-PE basis is for further study.
13.2. Control Plane 13.2. Control Plane
The data plane security of the previous section depends on the The data plane security of the previous section depends on the
security of the control plane. To ensure security, neither BGP nor security of the control plane. To ensure security, neither BGP nor
LDP connections should be made with untrusted peers. The TCP/IP MD5 LDP connections should be made with untrusted peers. The TCP/IP MD5
authentication option [TCP-MD5] should be used with both these authentication option [TCP-MD5] should be used with both these
protocols. The routing protocol within the SP's network should also protocols. The routing protocol within the SP's network should also
be secured in a similar manner. be secured in a similar manner.
13.3. Security of P and PE devices 13.3. Security of P and PE Devices
If the physical security of these devices is compromised, data plane If the physical security of these devices is compromised, data plane
security may also be compromised. security may also be compromised.
The usual steps should be take to ensure that IP traffic from the The usual steps should be taken to ensure that IP traffic from the
public Internet cannot be used to modify the configuration of these public Internet cannot be used to modify the configuration of these
devices, or to mount Denial of Service attacks on them. devices, or to mount Denial of Service attacks on them.
14. Quality of Service 14. Quality of Service
Although not the focus of this paper, Quality of Service is a key Although not the focus of this paper, Quality of Service is a key
component of any VPN service. In MPLS/BGP VPNs, existing L3 QoS component of any VPN service. In MPLS/BGP VPNs, existing L3 QoS
capabilities can be applied to labeled packets through the use of the capabilities can be applied to labeled packets through the use of the
"experimental" bits in the shim header [MPLS-ENCAPS], or, where ATM "experimental" bits in the shim header [MPLS-ENCAPS], or, where ATM
is used as the backbone, through the use of ATM QoS capabilities. is used as the backbone, through the use of ATM QoS capabilities.
skipping to change at page 42, line 12 skipping to change at page 40, line 12
either intserv (Integrated Services) or diffserv (Differentiated either intserv (Integrated Services) or diffserv (Differentiated
Services) capabilities to a particular VPN, as appropriate. Services) capabilities to a particular VPN, as appropriate.
15. Scalability 15. Scalability
We have discussed scalability issues throughout this paper. In this We have discussed scalability issues throughout this paper. In this
section, we briefly summarize the main characteristics of our model section, we briefly summarize the main characteristics of our model
with respect to scalability. with respect to scalability.
The Service Provider backbone network consists of (a) PE routers, (b) The Service Provider backbone network consists of (a) PE routers, (b)
BGP Route Reflectors, (c) P routers (which are neither PE routers nor BGP Route Reflectors, (c) P routers (that are neither PE routers nor
Route Reflectors), and, in the case of multi-provider VPNs, (d) Route Reflectors), and, in the case of multi-provider VPNs, (d)
ASBRs. ASBRs.
P routers do not maintain any VPN routes. In order to properly P routers do not maintain any VPN routes. In order to properly
forward VPN traffic, the P routers need only maintain routes to the forward VPN traffic, the P routers need only maintain routes to the
PE routers and the ASBRs. The use of two levels of labeling is what PE routers and the ASBRs. The use of two levels of labeling is what
makes it possible to keep the VPN routes out of the P routers. makes it possible to keep the VPN routes out of the P routers.
A PE router maintains VPN routes, but only for those VPNs to which it A PE router maintains VPN routes, but only for those VPNs to which it
is directly attached. is directly attached.
Route reflectors can be partitioned among VPNs so that each partition Route reflectors can be partitioned among VPNs so that each partition
carries routes for only a subset of the VPNs supported by the Service carries routes for only a subset of the VPNs supported by the Service
Provider. Thus no single route reflector is required to maintain Provider. Thus, no single route reflector is required to maintain
routes for all VPNs. routes for all VPNs.
For inter-provider VPNs, if the ASBRs maintain and distribute VPN- For inter-provider VPNs, if the ASBRs maintain and distribute VPN-
IPv4 routes, then the ASBRs can be partitioned among VPNs in a IPv4 routes, then the ASBRs can be partitioned among VPNs in a
similar manner, with the result that no single ASBR is required to similar manner, with the result that no single ASBR is required to
maintain routes for all the inter-provider VPNs. If multi-hop EBGP maintain routes for all the inter-provider VPNs. If multi-hop EBGP
is used, then the ASBRs need not maintain and distribute VPN-IPv4 is used, then the ASBRs need not maintain and distribute VPN-IPv4
routes at all. routes at all.
As a result, no single component within the Service Provider network As a result, no single component within the Service Provider network
has to maintain all the routes for all the VPNs. So the total has to maintain all the routes for all the VPNs. So the total
capacity of the network to support increasing numbers of VPNs is not capacity of the network to support increasing numbers of VPNs is not
limited by the capacity of any individual component. limited by the capacity of any individual component.
16. IANA Considerations 16. IANA Considerations
IANA ("Internet Assigned Numbers Authority") needs to create a new The Internet Assigned Numbers Authority (IANA) has created a new
registry for the "Route Distinguisher Type Field" (see section 4.2). registry for the "Route Distinguisher Type Field" (see Section 4.2).
This is a two-byte field. Types 0, 1, and 2 are defined by this This is a two-byte field. Types 0, 1, and 2 are defined by this
document. Additional Route Distinguisher Type field values with a document. Additional Route Distinguisher Type Field values with a
high-order bit of 0 may be allocated by IANA on a "First Come, First high-order bit of 0 may be allocated by IANA on a "First Come, First
Served" basis [IANA]. Values with a high-order bit of 1 may be Served" basis [IANA]. Values with a high-order bit of 1 may be
allocated by IANA based on "IETF consensus" [IANA]. allocated by IANA based on "IETF consensus" [IANA].
This document specifies (see section 4.3.4) the use of the BGP AFI This document specifies (see Section 4.3.4) the use of the BGP
(Address Family Identifier) value 1, along with the BGP SAFI Address Family Identifier (AFI) value 1, along with the BGP
(Subsequent Address Family Identifier) value 128, to represent the Subsequent Address Family Identifier (SAFI) value 128, to represent
address family "VPN-IPv4 Labeled Addresses", which is defined in this the address family "VPN-IPv4 Labeled Addresses", which is defined in
document. this document.
The use of AFI value 1 for IP is as currently specified in the IANA The use of AFI value 1 for IP is as currently specified in the IANA
registry "Address Family Identifier", so IANA need take no action registry "Address Family Identifier", so IANA need take no action
with respect to it. with respect to it.
At the time of this writing, the SAFI value 128 is specified as The SAFI value 128 was originally specified as "Private Use" in the
"Private Use" in the IANA "Subsequent Address Family Identifier" IANA "Subsequent Address Family Identifier" registry. IANA has
registry. As this value is used in a large number of deployments, changed the SAFI value 128 from "private use" to "MPLS-labeled VPN
and it is not feasible to change it. Therefore IANA should change address".
the SAFI value 128 from "private use" to "MPLS-labeled VPN address".
17. Acknowledgments 17. Acknowledgements
The full list of contributors can be found in section 20. The full list of contributors can be found in Section 18.
Significant contributions to this work have also been made by Ravi Significant contributions to this work have also been made by Ravi
Chandra, Dan Tappan and Bob Thomas. Chandra, Dan Tappan, and Bob Thomas.
We also wish to thank Shantam Biswas for his review and We also wish to thank Shantam Biswas for his review and
contributions. contributions.
18. Authors' Addresses 18. Contributors
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
E-mail: erosen@cisco.com
Yakov Rekhter
Juniper Networks
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
E-mail: yakov@juniper.net
19. Contributors
Tony Bogovic Tony Bogovic
Telcordia Technologies Telcordia Technologies
445 South Street, Room 1A264B 445 South Street, Room 1A264B
Morristown, NJ 07960 Morristown, NJ 07960
E-mail: tjb@research.telcordia.com
EMail: tjb@research.telcordia.com
Stephen John Brannon Stephen John Brannon
Swisscom AG Swisscom AG
Postfach 1570 Postfach 1570
CH-8301 CH-8301
Glattzentrum (Zuerich), Switzerland Glattzentrum (Zuerich), Switzerland
E-mail: stephen.brannon@swisscom.com
EMail: stephen.brannon@swisscom.com
Marco Carugi Marco Carugi
Nortel Networks S.A. Nortel Networks S.A.
Parc d'activit‰s de Magny-Les Jeunes Bois CHATEAUFORT Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT
78928 YVELINES Cedex 9 - FRANCE 78928 YVELINES Cedex 9 - FRANCE
Email : marco.carugi@nortelnetworks.com
EMail: marco.carugi@nortelnetworks.com
Christopher J. Chase Christopher J. Chase
AT&T AT&T
200 Laurel Ave 200 Laurel Ave
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
E-mail: chase@att.com
EMail: chase@att.com
Ting Wo Chung Ting Wo Chung
Bell Nexxia Bell Nexxia
181 Bay Street 181 Bay Street
Suite 350 Suite 350
Toronto, Ontario Toronto, Ontario
M5J2T3 M5J2T3
E-mail: ting_wo.chung@bellnexxia.com
EMail: ting_wo.chung@bellnexxia.com
Eric Dean Eric Dean
Jeremy De Clercq Jeremy De Clercq
Alcatel Network Strategy Group Alcatel Network Strategy Group
Francis Wellesplein 1 Francis Wellesplein 1
2018 Antwerp, Belgium 2018 Antwerp, Belgium
E-mail: jeremy.de_clercq@alcatel.be
EMail: jeremy.de_clercq@alcatel.be
Luyuan Fang Luyuan Fang
AT&T AT&T
IP Backbone Architecture IP Backbone Architecture
200 Laurel Ave. 200 Laurel Ave.
Middletown, NJ 07748 Middletown, NJ 07748
E-mail: luyuanfang@att.com
EMail: luyuanfang@att.com
Paul Hitchen Paul Hitchen
BT BT
BT Adastral Park BT Adastral Park
Martlesham Heath, Martlesham Heath,
Ipswich IP5 3RE Ipswich IP5 3RE
UK UK
E-mail: paul.hitchen@bt.com
EMail: paul.hitchen@bt.com
Manoj Leelanivas Manoj Leelanivas
Juniper Networks, Inc. Juniper Networks, Inc.
385 Ravendale Drive 385 Ravendale Drive
Mountain View, CA 94043 USA Mountain View, CA 94043 USA
E-mail: manoj@juniper.net
EMail: manoj@juniper.net
Dave Marshall Dave Marshall
Worldcom Worldcom
901 International Parkway 901 International Parkway
Richardson, Texas 75081 Richardson, Texas 75081
E-mail: dave.marshall@wcom.com
EMail: dave.marshall@wcom.com
Luca Martini Luca Martini
Level 3 Communications, LLC. Cisco Systems, Inc.
1025 Eldorado Blvd. 9155 East Nichols Avenue, Suite 400
Broomfield, CO, 80021 Englewood, CO, 80112
E-mail: luca@level3.net
EMail: lmartini@cisco.com
Monique Jeanne Morrow Monique Jeanne Morrow
Cisco Systems, Inc. Cisco Systems, Inc.
Glatt-com, 2nd floor Glatt-com, 2nd floor
CH-8301 CH-8301
Glattzentrum, Switzerland Glattzentrum, Switzerland
E-mail: mmorrow@cisco.com
EMail: mmorrow@cisco.com
Ravichander Vaidyanathan Ravichander Vaidyanathan
Telcordia Technologies Telcordia Technologies
445 South Street, Room 1C258B 445 South Street, Room 1C258B
Morristown, NJ 07960 Morristown, NJ 07960
E-mail: vravi@research.telcordia.com
EMail: vravi@research.telcordia.com
Adrian Smith Adrian Smith
BT BT
BT Adastral Park BT Adastral Park
Martlesham Heath, Martlesham Heath,
Ipswich IP5 3RE Ipswich IP5 3RE
UK UK
E-mail: adrian.ca.smith@bt.com
EMail: adrian.ca.smith@bt.com
Vijay Srinivasan Vijay Srinivasan
1200 Bridge Parkway 1200 Bridge Parkway
Redwood City, CA 94065 Redwood City, CA 94065
E-mail: vsriniva@cosinecom.com
EMail: vsriniva@cosinecom.com
Alain Vedrenne Alain Vedrenne
Equant Equant
Heraklion, 1041 route des Dolines, BP347 Heraklion, 1041 route des Dolines, BP347
06906 Sophia Antipolis, Cedex, france 06906 Sophia Antipolis, Cedex, France
Email: Alain.Vedrenne@equant.com
20. Normative References EMail: Alain.Vedrenne@equant.com
[BGP] "Border Gateway Protocol 4 (BGP-4)", Rekhter and Li, RFC 1771, 19. Normative References
March 1995
[BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions [BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
for BGP4", RFC 2858, June 2000 (BGP-4)", RFC 4271, January 2006.
[BGP-EXTCOMM] Sangli, Tappan, and Rekhter, "BGP Extended Communities [BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
Attribute", draft-ietf-idr-bgp-ext-communities-07.txt, March 2004 "Multiprotocol Extensions for BGP-4", RFC 2858,
June 2000.
[MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label [BGP-EXTCOMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP
Switching Architecture", RFC 3031, January 2001 Extended Communities Attribute", RFC 4360, February
2006.
[MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4", [MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon,
RFC 3107, May 2001 "Multiprotocol Label Switching Architecture", RFC
3031, January 2001.
[MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and [MPLS-BGP] Rekhter, Y. and E. Rosen, "Carrying Label
Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001 Information in BGP-4", RFC 3107, May 2001.
21. Informational References [MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label
Stack Encoding", RFC 3032, January 2001.
[BGP-AS4] Vohra and Chen, "BGP Support for Four-Octet AS Number 20. Informative References
Space", draft-ietf-idr-as4bytes-08.txt, March 2004
[BGP-ORF] Chen, Rekhter, "Cooperative Route Filtering Capability for [BGP-AS4] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
BGP-4", draft-ietf-idr-route-filter-10.txt, March 2004 AS Number Space", Work in Progress, March 2004.
[BGP-RFSH] Chen, "Route Refresh Capability for BGP-4", RFC 2918, [BGP-ORF] Chen, E. and Y. Rekhter, "Cooperative Route
March 2000 Filtering Capability for BGP-4", Work in Progress,
March 2004.
[BGP-RR] Bates, Chandra, and Chen, "BGP Route Reflection: An [BGP-RFSH] Chen, E., "Route Refresh Capability for BGP-4", RFC
alternative to full mesh IBGP", RFC 2796, April 2000 2918, September 2000.
[IANA] Narten, Alvestrand, "Guidelines for Writing an IANA [BGP-RR] Bates, T., Chandra, R., and E. Chen, "BGP Route
Considerations Section in RFCs", RFC 2434, October 1998 Reflection - An Alternative to Full Mesh IBGP", RFC
2796, April 2000.
[IPSEC] Kent and Atkinson, "Security Architecture for the Internet [IANA] Narten, T. and H. Alvestrand, "Guidelines for
Protocol", RFC 2401, November 1998 Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998.
[MPLS-ATM] Davie, Doolan, Lawrence, McCloghrie, Rosen, Swallow, and [MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
Rekhter, "MPLS using LDP and ATM VC Switching", RFC 3035, January Swallow, G., Rekhter, Y., and P. Doolan, "MPLS
2001 using LDP and ATM VC Switching", RFC 3035, January
2001.
[MPLS/BGP-IPsec] Rosen, De Clercq, Paridaen, T'Joens, and Sargor, [MPLS/BGP-IPsec] Rosen, E., De Clercq, J., Paridaens, O., T'Joens,
"Use of PE-PE IPsec in RFC2547 VPNs", draft-ietf-l3vpn-ipsec-2547- Y., and C. Sargor, "Architecture for the Use of
02.txt, March 2004 PE-PE IPsec Tunnels in BGP/MPLS IP VPNs", Work in
Progress, March 2004.
[MPLS-FR] Conta, Doolan, Malis, "Use of Label Switching on Frame [MPLS-FR] Conta, A., Doolan, P., and A. Malis, "Use of Label
Relay Networks Specification" RFC 3034, January 2001 Switching on Frame Relay Networks Specification",
RFC 3034, January 2001.
[MPLS-in-IP-GRE] Worster, Rekhter, and Rosen, "Encapsulating MPLS in [MPLS-in-IP-GRE] Worster, T., Rekhter, Y., and E. Rosen,
IP or GRE", draft-ietf-mpls-in-ip-or-gre-08.txt, June 2004 "Encapsulating MPLS in IP or Generic Routing
Encapsulation (GRE)", RFC 4023, March 2005.
[MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP [MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette,
Specification", RFC 3036, January 2001 A., and B. Thomas, "LDP Specification", RFC 3036,
January 2001.
[MPLS-RSVP] Awduche, Berger, Gan, Li, Srinavasan, Swallow, "RSVP-TE: [MPLS-RSVP] Awduche, D., Berger, L., Gan, D., Li, T.,
Extensions to RSVP for LSP Tunnels", RFC 3209, February 2001 Srinivasan, V., and G. Swallow, "RSVP-TE:
Extensions to RSVP for LSP Tunnels", RFC 3209,
December 2001.
[OSPFv2] Moy, "OSPF Version 2", RFC 2328, April 1998 [OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[PASTE] Li and Rekhter, "A Provider Architecture for Differentiated [PASTE] Li, T. and Y. Rekhter, "A Provider Architecture for
Services and Traffic Engineering (PASTE)", RFC 2430, October 1998 Differentiated Services and Traffic Engineering
(PASTE)", RFC 2430, October 1998.
[RIP] Malkin, "RIP Version 2", RFC 2453, November 1998 [RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
November 1998.
[OSPF-2547-DNBIT] Rosen, Psenak, and Pillay-Esnault, "Using an LSA [OSPF-2547-DNBIT] Rosen, E., Psenak, P., and P. Pillay-Esnault,
Options Bit to Prevent Looping in BGP/MPLS IP VPNs", draft-ietf- "Using an LSA Options Bit to Prevent Looping in
ospf-2547-dnbit-04.txt, March 2004 BGP/MPLS IP VPNs", Work in Progress, March 2004.
[TCP-MD5] Heffernan, "Protection of BGP Sessions via the TCP MD5 [TCP-MD5] Heffernan, A., "Protection of BGP Sessions via the
Signature Option", RFC 2385, August 1998 TCP MD5 Signature Option", RFC 2385, August 1998.
[VPN-MCAST] Rosen, Cai, Wijsnands, "Multicast in MPLS/BGP VPNs", [VPN-MCAST] Rosen, E., Cai, Y., and J. Wijsnands, "Multicast in
draft-rosen-vpn-mcast-07.txt, May 2004 MPLS/BGP VPNs", Work in Progress, May 2004.
[VPN-OSPF] Rosen, Psenak and Pillay-Esnault, "OSPF as the PE/CE [VPN-OSPF] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF
Protocol in BGP/MPLS VPNs", draft-ietf-l3vpn-ospf-2547-01.txt, as the PE/CE Protocol in BGP/MPLS VPNs", Work in
February 2004 Progress, February 2004.
22. Intellectual Property Statement Authors' Addresses
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
EMail: erosen@cisco.com
Yakov Rekhter
Juniper Networks
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
EMail: yakov@juniper.net
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
23. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Acknowledgement
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an Funding for the RFC Editor function is provided by the IETF
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS Administrative Support Activity (IASA).
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 245 change blocks. 
547 lines changed or deleted 569 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35