Internet DRAFT - draft-bonica-mplsvpn
draft-bonica-mplsvpn
L3VPN K. Kompella
Internet-Draft R. Bonica
Expires: December 4, 2006 K. Yamashita
Juniper Networks
K. Kumaki
KDDI Corporation
June 2, 2006
Delivering MPLS Services Over L3VPN
draft-bonica-mplsvpn-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 4, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes procedures that can be used to deliver MPLS
services over Layer 3 Virtual Private Networks (L3VPN). Using these
procedures, a VPN customer can signal MPLS Label Switched Paths (LSP)
from Customer Edge (CE) router to CE router. Although a Service
Provider (SP) network carries the Customer LSP (C-LSP) from one CE
Kompella, et al. Expires December 4, 2006 [Page 1]
Internet-Draft MPLS over L3VPN June 2006
router to another, the C-LSP does not interact with the SP network's
routing or signaling infrastructure.
Table of Contents
1. Conventions Used In This Document . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Concept of Operation . . . . . . . . . . . . . . . . . . . . . 4
3.1. CE Routers Establish A Labeled Path Between One Another . 5
3.2. Customer Sites Exchange Internal Routes With One
Another . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Signaling The C-LSP . . . . . . . . . . . . . . . . . . . 7
3.4. Traffic Engineering Considerations . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Kompella, et al. Expires December 4, 2006 [Page 2]
Internet-Draft MPLS over L3VPN June 2006
1. Conventions Used In This Document
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC2119 [1].
2. Introduction
This document describes procedures that can be used to deliver MPLS
[2] services over Layer 3 Virtual Private Networks. Reference [3]
describes service requirements.
Customer LSP's
(C-LSP)
------------------------------------------------------------)
(----------------------------------------------
Service Provider LSP
(SP-LSP)
---------------------------)
(---------------------------
........... ...........
. -- ---. --- --- --- --- .--- -- .
.|C0| |CE1|-----|PE1|----|P1 |-----|P2 |----|PE2|----|CE2| |C3|.
. -- ---. --- --- --- --- . --- -- .
.......... ...........
^ ^
| |
vrf instance vrf instance
--Customer-- ------Service Provider-------- --Customer--
VPN Site A L3VPN VPN Site B
Figure 1: Reference Model
Figure 1 provides a reference model. In the figure, an SP maintains
an L3VPN using BGP/MPLS technology [4]. The SP network contains two
edge routers (PE1 and PE2) and two core routers (P1 and P2). All
four SP routers participate in an IGP and a pair of unidirectional
MPLS LSPs provide connectivity between PE1 and PE2. Because these
LSPs are contained entirely by the SP network, we call them SP-LSPs.
PE1 and PE2 also exchange customer routes with one another through a
multiprotocol iBGP [5] session.
Kompella, et al. Expires December 4, 2006 [Page 3]
Internet-Draft MPLS over L3VPN June 2006
A VPN customer maintains one site at either end of the SP network.
From VPN Site A, the customer attaches CE1 to PE1. From VPN Site B,
the customer attaches CE2 to PE2. C0 resides VPN Site A and C3
resides in VPN Site B.
This document describes procedures that allow the customer to
establish RSVP-TE [6] signaled LSPs between VPN sites. Because these
LSPs originate on one customer router and terminate on another, we
call them Customer LSPs (C-LSP).
A C-LSP can connect any router in one VPN site to any router in
another VPN site. For example, a C-LSP might connect CE1 to CE2 or
C0 to C3.
The solution described herein is constrained by the service
provider's business policy. The following constraints are applied:
o The SP provides Layer 3 services only. It does not provide L2
services.
o The SP provides VPN services only. The SP must carry all
customer routes in a Virtual Routing and Forwarding (VRF) instance
that is dedicated to the customer's VPN. The SP must not carry
any customer routes in its general routing instance.
o Customer routers must not participate in the Service Provider's
IGP.
o Customer routers must not exchange RSVP or LDP [10] messages
with SP routers.
3. Concept of Operation
The procedure described herein permits the customer to establish and
maintain C-LSPs. Each C-LSP contains one or more hops, which for the
purposes of this document, will be called C-hops. Each C-hop MUST
originate on one customer router and terminate on another customer
router. An C-hop MUST neither originate nor terminate on an SP
router.
So, returning to Figure 1, a C-LSP that connects C0 to C3 might
include the following C-hops:
o C0-CE1
Kompella, et al. Expires December 4, 2006 [Page 4]
Internet-Draft MPLS over L3VPN June 2006
o CE1-CE2
o CE2-C3
Therefore, all MPLS state associated with an C-LSP is maintained on
customer routers. This facilitates service scaling and precludes
various kinds of DoS attacks against the SP.
The salient characteristic of this solution is that one hop,
connecting CE1 to CE2, spans the entire SP network. Note, however,
that routers CE1 and CE2 are not adjacent to one another at Layer 3.
So, the customer and SP must co-operate in order to provided a
labeled path between CE1 and CE2.
From a forwarding perspective, all C-LSPs that connect VPN Site A to
VPN Site B are multiplexed over the labeled path that connects CE1 to
CE2. From a signaling perspective, RSVP treats this labeled path as
a single hop. All RSVP messages sent from VPN Site A to VPN Site B
will traverse that labeled path. SP routers forward those RSVP
messages without examining or processing them. However, the customer
routers (CE1 and CE2) will process these messages and establish C-LSP
state as required.
The solution described herein is presented in four parts. These are:
o procedures required to establish a labeled path between CE
routers
o procedures required to distribute customer internal routes
between VPN sites
o procedures required to signal the C-LSP
o traffic engineering considerations
Each part is described in a dedicated subsection below.
3.1. CE Routers Establish A Labeled Path Between One Another
In order to establish a labeled path between CE routers, the SP
configures its network as it would if it were to provide an L3VPN
carrier-of-carriers service. (See Section 9 of reference [4] for
details.)
First, the SP configures its network for a basic BGP/MPLS IP VPN
service. This configuration includes the following steps:
Kompella, et al. Expires December 4, 2006 [Page 5]
Internet-Draft MPLS over L3VPN June 2006
o Enable an IGP on all SP routers.
o Establish a full mesh of MPLS LSPs among all PE routers (i.e.,
SP-LSPs).
o Configure the SP network so that PE routers can exchange
customer routes with one another using multiprotocol iBGP. This
can be achieved using either a full mesh of multiprotocol iBGP
neighboring sessions or a route reflector [11] configuration.
Next, the SP configures multiprotocol eBGP sessions between its PE
routers and the customer's CE routers. The SP configures the
following export policy on each of these multiprotocol eBGP
neighboring sessions:
o Set next-hop to self (i.e., the PE router's loopback address)
o Advertise all routes learned from BGP and belonging to the
appropriate VRF
The SP also configures these multiprotocol eBGP sessions with a
default import policy. The default import policy causes the PE
routers to relay, but otherwise not process, two new BGP extended
communities [7]. One of these extended communities, called the
C-next-hop, represents the loopback address of the advertising CE
router. The other extended community, called the Link Bandwidth
Community, represents the reservable bandwidth that on the link that
connects the PE router to the advertising CE router. Because these
extended communities are transitive, the PE router relays them as the
were received. The following sections describe how these new
extended communities are used.
3.2. Customer Sites Exchange Internal Routes With One Another
The customer begins this process by enabling an IGP on all interfaces
that are internal to the VPN site. The customer also floods router
loopback interfaces into the IGP. However, the customer does not
enable the IGP on the PE/CE interface. Therefore, each VPN site
maintains a unique IGP domain.
Next, the VPN customer configures its side of the multiprotocol eBGP
sessions described in Section 3.1. The customer configures the
following export policy on each of these multiprotocol eBGP
neighboring sessions:
Kompella, et al. Expires December 4, 2006 [Page 6]
Internet-Draft MPLS over L3VPN June 2006
o set label to EXPLICIT NULL
o set next-hop to self (i.e., the CE router's loopback address)
o append a new BGP extended community called the C-next-hop. The
C-next-hop, like the next-hop attribute, is set to the router's
loopback address.
o optionally, append a new BGP extended community called the the
Link Bandwidth Community. The Link Bandwidth Community represents
the reservable bandwidth that on the link that connects the PE
router to the advertising CE router (See Section 3.4 for details.)
o advertise all directly connected and IGP-learned routes
The customer also configures the following import policy on each of
these multiprotocol eBGP neighboring sessions:
o accept or reject each prefix as per local security policy
o if the prefix is accepted and it includes the new BGP C-next-hop
extended community, overwrite the BGP next-hop with the C-next-hop
Finally, the customer configures the CE router so that injects all
eBGP-learned routes into the IGP. When the CE router floods these
routes into the IGP, it employs IGP traffic engineering extensions
[8] [9] so that traffic engineering parameters will be available in
Traffic Engineering Databases throughout the VPN site. Traffic
engineering information is obtained from the BGP advertisement and
local configuration. See Section 3.4 for details.
Having completed this procedure, and returning to Figure 1, let us
review routing from C0 to C3. C0 has an IGP route to C3 through CE1.
CE1 has an BGP route to C3 with a BGP next-hop of CE2. CE1's best
path to CE2 is through the labeled path that connects it to CE2. CE2
has an iGP route to C3.
3.3. Signaling The C-LSP
The customer configures an C-LSP using RSVP-TE. For the purpose of
example, let us return to Figure 1 and assume that the customer
configures an C-LSP from C0 to C3. Assume also that no bandwidth is
reserved for this LSP. (We will revisit traffic engineering
considerations in Section 3.4).
C0 determines that it has a route to C3 (through CE1) and that that
route traverses an MPLS enabled interface. So, CO formats an RSVP
PATH message and sends it to CE1. The RSVP PATH message contains an
Kompella, et al. Expires December 4, 2006 [Page 7]
Internet-Draft MPLS over L3VPN June 2006
incomplete Explicit Route Object (ERO) that includes only CE1.
Because the RSVP PATH message arrives at CE1 unlabeled, CE1 detects
that the packet includes an IP Router Alert Option and processes the
message. So, CE1 updates the RSVP PATH message (adding CE2 to the
ERO) and forwards it through the labeled path to CE2.
The labeled path to CE2 passes through PE1, P1, P2 and PE2. However,
because the RSVP message arrives at these routers with a non-zero
MPLS label, these routers do not detect its IP Router Alert Option
and do not process the message. However, PE2 swaps the MPLS label
and forwards the RSVP message to CE2 with an EXPLICIT NULL label.
CE2 detects that the packet includes an IP Router Alert Option and
processes the message. Finally, CE2 updates the message and forwards
it to C3.
C3 returns an RSVP-TE RESV message via the same path, creating MPLS
state along the way.
3.4. Traffic Engineering Considerations
Customers can configure traffic engineering parameters in association
with a C-LSP. Specifically, customers can specify a bandwidth
reservation and a pre-emption priority for each C-LSP. If the
customer associates a bandwidth reservation with a C-LSP, customer
routers will calculate the best path through which the required
bandwidth is available. The following paragraphs describe traffic
engineering procedures.
When a CE router advertises a prefix to the PE router, the CE router
can specify a Link Bandwidth Community. The Link Bandwidth Community
represents the reservable bandwidth on the CE-PE link. PE routers
are configured so that they do not process the Link Bandwidth
Community. However, because the community is transitive, PE routers
relay the Link Bandwidth Community to the CE router at the distant
end of the SP network
The CE router at the distant end of the SP network compares the
bandwidth specified by the Link Bandwidth Community with the
bandwidth that is available on the link that connects it to the PE
router. It then injects the route to the distant CE into its IGP,
specifying the lesser of the two bandwidths as the bandwidth labeled
path that connects the two CE routers to one another. The IGP floods
this information throughout its domain, so that the lesser bandwidth
appears in Traffic Engineering databases throughout the VPN site.
Finally, the customer configures a C-LSP. Customer routers invoke
standard traffic engineering procedures to calculate the best path
Kompella, et al. Expires December 4, 2006 [Page 8]
Internet-Draft MPLS over L3VPN June 2006
and pre-empt other LSPs if necessary. If the new LSP results in a
bandwidth reservation across labeled path that connects CE routers to
one another, the CE router repeats its advertisement with an updated
Link Bandwidth Community.
It is anticipated that in the future, customers will want to
associate many other traffic engineering parameters with the labeled
path between CE routers. New BGP communities will be defined to
advertise those attributes and RSVP will also consider them in the
process of path calculation.
The Link Bandwidth Community is of an extended type.
The value of the high-order octet of the Type Field is 0x00. The
value of the low-order octet of the Type field for this community is
0x04.
The value of the Global Administrator sub-field in the Value Field
MUST represent the Autonomous System of the router that attaches the
Link Bandwidth Community.
The bandwidth of the link is expressed as 4 octets in IEEE floating
point format, units being bytes per second. It is carried in the
Local Administrator sub-field of the Value Field.
4. Security Considerations
In order to maintain their security postures, the SP and the customer
must constrain their interactions with one another. On the
forwarding plane, both parties should accept labeled traffic through
the PE/CE interface only if they have advertised that label. On the
control plane, the PE and CE router should exchange BGP traffic only.
They MUST NOT exchange RSVP signaling or participate in a common IGP.
5. IANA Considerations
IANA will assign two new BGP Extended Communities. These are the
Link Bandwidth community and the C-Next-hop Community.
6. Acknowledgments
Thanks to Yakov Rekhter for his comments regarding this draft.
7. References
Kompella, et al. Expires December 4, 2006 [Page 9]
Internet-Draft MPLS over L3VPN June 2006
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[3] Kumaki, K., "Requirements for delivering MPLS Services Over
L3VPN", draft-kumaki-l3vpn-e2e-rsvp-te-reqts-00 (work in
progress), February 2006.
[4] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks
(VPNs)", RFC 4364, February 2006.
[5] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4",
RFC 3107, May 2001.
[6] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G.
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001.
[7] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[8] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE)
Extensions to OSPF Version 2", RFC 3630, September 2003.
[9] Smit, H. and T. Li, "Intermediate System to Intermediate System
(IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784,
June 2004.
7.2. Informative References
[10] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B.
Thomas, "LDP Specification", RFC 3036, January 2001.
[11] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An
Alternative to Full Mesh IBGP", RFC 2796, April 2000.
Kompella, et al. Expires December 4, 2006 [Page 10]
Internet-Draft MPLS over L3VPN June 2006
Authors' Addresses
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
USA
Email: kireeti@juniper.net
Ronald P. Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, VA 20171
USA
Email: rpb@juniper.net
Koh Yamashita
Juniper Networks
3-7-1 Nishi Shinjuku
Shinjuku-Ku Tokyo, 163-1053
Japan
Email: kohy@juniper.net
Kenji Kumaki
KDDI Corporation
Garden Air Tower, Iidabashi
Chiyoda-ku Tokyo, 102-8460
Japan
Email: ke-kumaki@kddi.com
Kompella, et al. Expires December 4, 2006 [Page 11]
Internet-Draft MPLS over L3VPN June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
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
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kompella, et al. Expires December 4, 2006 [Page 12]
