draft-ietf-tsvwg-rsvp-l3vpn-06.txt   draft-ietf-tsvwg-rsvp-l3vpn-07.txt 
Network Working Group B. Davie Network Working Group B. Davie
Internet-Draft F. le Faucheur Internet-Draft F. le Faucheur
Intended status: Standards Track A. Narayanan Intended status: Standards Track A. Narayanan
Expires: October 27, 2010 Cisco Systems, Inc. Expires: December 18, 2010 Cisco Systems, Inc.
April 25, 2010 June 16, 2010
Support for RSVP in Layer 3 VPNs Support for RSVP in Layer 3 VPNs
draft-ietf-tsvwg-rsvp-l3vpn-06.txt draft-ietf-tsvwg-rsvp-l3vpn-07.txt
Abstract Abstract
RFC 4364 and RFC 4659 define an approach to building provider- RFC 4364 and RFC 4659 define an approach to building provider-
provisioned Layer 3 VPNs for IPv4 and IPv6. It may be desirable to provisioned Layer 3 VPNs for IPv4 and IPv6. It may be desirable to
use RSVP to perform admission control on the links between Customer use RSVP to perform admission control on the links between Customer
Edge (CE) routers and Provider Edge (PE) routers. This document Edge (CE) routers and Provider Edge (PE) routers. This document
specifies procedures by which RSVP messages travelling from CE to CE specifies procedures by which RSVP messages travelling from CE to CE
across an L3VPN may be appropriately handled by PE routers so that across an L3VPN may be appropriately handled by PE routers so that
admission control can be performed on PE-CE links. Optionally, admission control can be performed on PE-CE links. Optionally,
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 27, 2010. This Internet-Draft will expire on December 18, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 46 skipping to change at page 3, line 46
8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . 24 8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . 24
8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6
SENDER_TEMPLATE objects . . . . . . . . . . . . . . . . . 26 SENDER_TEMPLATE objects . . . . . . . . . . . . . . . . . 26
8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC 8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC
objects . . . . . . . . . . . . . . . . . . . . . . . . . 27 objects . . . . . . . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Alternatives Considered . . . . . . . . . . . . . . 34 Appendix A. Alternatives Considered . . . . . . . . . . . . . . 34
Appendix A.1. GMPLS UNI approach . . . . . . . . . . . . . . . . . 34 Appendix A.1. GMPLS UNI approach . . . . . . . . . . . . . . . . . 34
Appendix A.2. VRF label approach . . . . . . . . . . . . . . . . . 34 Appendix A.2. Label switching approach . . . . . . . . . . . . . . 34
Appendix A.3. VRF label plus VRF address approach . . . . . . . . 35 Appendix A.3. VRF label approach . . . . . . . . . . . . . . . . . 35
Appendix A.4. VRF label plus VRF address approach . . . . . . . . 35
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.1. Normative References . . . . . . . . . . . . . . . . . . . 35 12.1. Normative References . . . . . . . . . . . . . . . . . . . 35
12.2. Informative References . . . . . . . . . . . . . . . . . . 36 12.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
[RFC4364] and [RFC4659] define a Layer 3 VPN service known as BGP/ [RFC4364] and [RFC4659] define a Layer 3 VPN service known as BGP/
MPLS VPNs for IPv4 and for IPv6 respectively. [RFC2205] defines the MPLS VPNs for IPv4 and for IPv6 respectively. [RFC2205] defines the
Resource Reservation Protocol (RSVP) which may be used to perform Resource Reservation Protocol (RSVP) which may be used to perform
admission control as part of the Integrated Services (Int-Serv) admission control as part of the Integrated Services (Int-Serv)
architecture [RFC1633][RFC2210]. architecture [RFC1633][RFC2210].
Customers of a layer 3 VPN service may run RSVP for the purposes of Customers of a layer 3 VPN service may run RSVP for the purposes of
skipping to change at page 4, line 28 skipping to change at page 4, line 28
those links. In order to perform admission control using RSVP in those links. In order to perform admission control using RSVP in
such an environment, it is necessary that RSVP control messages, such such an environment, it is necessary that RSVP control messages, such
as Path messages and Resv messages, are appropriately handled by the as Path messages and Resv messages, are appropriately handled by the
PE routers. This presents a number of challenges in the context of PE routers. This presents a number of challenges in the context of
BGP/MPLS VPNs: BGP/MPLS VPNs:
o RSVP Path message processing depends on routers recognizing the o RSVP Path message processing depends on routers recognizing the
router alert option ([RFC2113], [RFC2711]) in the IP header. router alert option ([RFC2113], [RFC2711]) in the IP header.
However, packets traversing the backbone of a BGP/MPLS VPN are However, packets traversing the backbone of a BGP/MPLS VPN are
MPLS encapsulated and thus the router alert option may not be MPLS encapsulated and thus the router alert option may not be
normally visible to the egress PE, due to implementation or policy visible to the egress PE due to implementation or policy
considerations. considerations (e.g. if the egress PE processes the message as
"pop and go" without examining the IP header).
o BGP/MPLS VPNs support non-unique addressing of customer networks. o BGP/MPLS VPNs support non-unique addressing of customer networks.
Thus a PE at the ingress or egress of the provider backbone may be Thus a PE at the ingress or egress of the provider backbone may be
called upon to process Path messages from different customer VPNs called upon to process Path messages from different customer VPNs
with non-unique destination addresses within the RSVP message. with non-unique destination addresses within the RSVP message.
Current mechanisms for identifying customer context from data Current mechanisms for identifying customer context from data
packets are incompatible with RSVP message processing rules. packets are incompatible with RSVP message processing rules.
o A PE at the ingress of the provider's backbone may receive Resv o A PE at the ingress of the provider's backbone may receive Resv
messages corresponding to different customer VPNs from other PEs, messages corresponding to different customer VPNs from other PEs,
and needs to be able to associate those Resv messages with the and needs to be able to associate those Resv messages with the
appropriate customer VPNs. appropriate customer VPNs.
Further discussion of these issues is presented in Section 2.
This document describes a set of procedures to overcome these This document describes a set of procedures to overcome these
challenges and thus to enable admission control using RSVP over the challenges and thus to enable admission control using RSVP over the
PE-CE links. We note that similar techniques may be applicable to PE-CE links. We note that similar techniques may be applicable to
other protocols used for admission control such as the combination of other protocols used for admission control such as the combination of
the NSIS Signaling Layer Protocol (NSLP) for QoS Signaling the NSIS Signaling Layer Protocol (NSLP) for QoS Signaling
([I-D.ietf-nsis-qos-nslp]) and General Internet Signaling Transport ([I-D.ietf-nsis-qos-nslp]) and General Internet Signaling Transport
(GIST) protocol ([I-D.ietf-nsis-ntlp]). (GIST) protocol ([I-D.ietf-nsis-ntlp]).
Additionally, it may be desirable to perform admission control over Additionally, it may be desirable to perform admission control over
the provider's backbone on behalf of one or more L3VPN customers. the provider's backbone on behalf of one or more L3VPN customers.
skipping to change at page 6, line 5 skipping to change at page 6, line 7
of admission control across the provider's backbone. of admission control across the provider's backbone.
RSVP Path messages are normally addressed to the destination of a RSVP Path messages are normally addressed to the destination of a
session, and contain the Router Alert Option (RAO) within the IP session, and contain the Router Alert Option (RAO) within the IP
header. Routers along the path to the destination that are header. Routers along the path to the destination that are
configured to process RSVP messages need to detect the presence of configured to process RSVP messages need to detect the presence of
the RAO to allow them to intercept Path messages. However, the the RAO to allow them to intercept Path messages. However, the
egress PEs of a network supporting BGP/MPLS VPNs receive packets egress PEs of a network supporting BGP/MPLS VPNs receive packets
destined for customer sites as MPLS-encapsulated packets, and destined for customer sites as MPLS-encapsulated packets, and
possibly forwards those based only on examination of the MPLS label. possibly forwards those based only on examination of the MPLS label.
Hence, a Path message would be forwarded without examination of the In order to process RSVP Path messages, the egress VPN PE would have
IP options and would therefore not receive appropriate processing at to pop the VPN label and examine the IP header underneath, before
the PE. Another potential issue is doing CAC at an ASBR. Even an forwarding the packet (based on the VPN label disposition rules),
which is not a requirement for data packet processing today. Hence,
a Path message would be forwarded without examination of the IP
options and would therefore not receive appropriate processing at the
PE. Another potential issue is doing CAC at an ASBR. Even an
implementation that examines the IP header when removing the VPN implementation that examines the IP header when removing the VPN
label (e.g. PE-CE link) would not be able to do CAC at an Option-B label (e.g. PE-CE link) would not be able to do CAC at an Option-B
ASBR; that requires examining the (interior) IP header while doing a ASBR; that requires examining the (interior) IP header while doing a
label swap, which is a much less desirable feature. In general, label swap, which is much less desirable behaviour.
there are significant issues with requiring support for IP Router-
Alert outside of a controller, "walled-garden" network, as described In general, there are significant issues with requiring support for
in [I-D.ietf-intarea-router-alert-considerations]. The issues with IP Router-Alert outside of a controlled, "walled-garden" network, as
requiring interior MPLS routers to process IP Router-Alert marked described in [I-D.ietf-intarea-router-alert-considerations]. The
packets are also described in [I-D.ietf-mpls-ip-options]. For these case of a MPLS L3VPN falls under the "Overlay Model" described
reasons, it is highly desirable to remove the dependency on router therein. Fundamental to this model is that providers would seek to
alert option across administrative domains (such as from a customer eliminate the requirement to process IP-RAO marked packets from
network to an egress PE, or such as across ASBRs in inter- provider customers, on any routers except the PEs facing those customers.
MPLS VPN scenarios). The approach for RSVP packet handling described Issues with requiring interior MPLS routers to process IP Router-
in this document has the advantage of being independent of any data- Alert marked packets are also described in
plane requirements such as IP Router-Alert support within the VPN. [I-D.ietf-mpls-ip-options]. The approach for RSVP packet handling
described in this document has the advantage of being independent of
any data-plane requirements such as IP Router-Alert support within
the VPN, or examining any IP options for MPLS-encapsulated packets.
The only requirement for processing IP Router-Alert packets is for The only requirement for processing IP Router-Alert packets is for
RSVP packets received from the CE, which do not carry any MPLS RSVP packets received from the CE, which do not carry any MPLS
encapsulation. encapsulation.
For the PE-CE link subproblem, the most basic challenge is that RSVP For the PE-CE link subproblem, the most basic challenge is that RSVP
control messages contain IP addresses that are drawn from the control messages contain IP addresses that are drawn from the
customer's address space, and PEs need to deal with traffic from many customer's address space, and PEs need to deal with traffic from many
customers who may have non-unique (or overlapping) address spaces. customers who may have non-unique (or overlapping) address spaces.
Thus, it is essential that a PE be able in all cases to identify the Thus, it is essential that a PE be able in all cases to identify the
correct VPN context in which to process an RSVP control message. The correct VPN context in which to process an RSVP control message. The
current mechanism for identifying the customer context is the VPN current mechanism for identifying the customer context is the VPN
Label, which is carried in a MPLS header outside of the RSVP message. Label, which is carried in a MPLS header outside of the RSVP message.
This is divergent from the general RSVP model of session This is divergent from the general RSVP model of session
identification ([RFC2205], [RFC2209]), which relies solely on RSVP identification ([RFC2205], [RFC2209]), which relies solely on RSVP
objects to identify sessions. Further, it is incompatible with objects to identify sessions. Further, it is incompatible with
protocols like COPS/RSVP ([RFC2748],[RFC2748]), which replace the IP protocols like COPS/RSVP ([RFC2748], [RFC2749]), which replace the IP
encapsulation of the RSVP message and send only RSVP objects to a encapsulation of the RSVP message and send only RSVP objects to a
COPS server. We believe it is important to retain the model of COPS server. We believe it is important to retain the model of
completely identifying an RSVP session from the contents of RSVP completely identifying an RSVP session from the contents of RSVP
objects. Much of this document deals with this issue. objects. Much of this document deals with this issue.
For the case of making reservations across the provider backbone, we For the case of making reservations across the provider backbone, we
observe that BGP/MPLS VPNs do not create any per-customer forwarding observe that BGP/MPLS VPNs do not create any per-customer forwarding
state in the P (provider core) routers. Thus, in order to make state in the P (provider core) routers. Thus, in order to make
reservations on behalf of customer-specified flows, it is clearly reservations on behalf of customer-specified flows, it is clearly
necessary to make some sort of aggregated reservation from PE-PE and necessary to make some sort of aggregated reservation from PE-PE and
skipping to change at page 34, line 8 skipping to change at page 34, line 8
11. Acknowledgments 11. Acknowledgments
Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter, Eric Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter, Eric
Rosen, Dan Tappan and Lou Berger for their many contributions to Rosen, Dan Tappan and Lou Berger for their many contributions to
solving the problems described in this document. Thanks to Ferit solving the problems described in this document. Thanks to Ferit
Yegenoglu for his useful comments. We also thank Stefan Santesson Yegenoglu for his useful comments. We also thank Stefan Santesson
Vijay Gurbani and Alexey Melnikov for their review comments. We Vijay Gurbani and Alexey Melnikov for their review comments. We
thank Richard Woundy for his very thorough review and comments thank Richard Woundy for his very thorough review and comments
including those that resulted in additional text discussing scenarios including those that resulted in additional text discussing scenarios
of admission control reject in the MPLVS VPN cloud. of admission control reject in the MPLS VPN cloud. Also, we thank
Adrian Farrel for his detailed review and contributions.
Appendix A. Alternatives Considered Appendix A. Alternatives Considered
At this stage a number of alternatives to the approach described At this stage a number of alternatives to the approach described
above have been considered. We document some of the approaches above have been considered. We document some of the approaches
considered here to assist future discussion. None of these has been considered here to assist future discussion. None of these has been
shown to improve upon the approach described above, and the first two shown to improve upon the approach described above, and the first two
seem to have significant drawbacks relative to the approach described seem to have significant drawbacks relative to the approach described
above. above.
skipping to change at page 34, line 35 skipping to change at page 34, line 36
allowing a CE device to request the establishment of an LSP across allowing a CE device to request the establishment of an LSP across
the network on the other side of the UNI. Hence the procedures in the network on the other side of the UNI. Hence the procedures in
[RFC4208] would lead to the establishment of an LSP across the VPN [RFC4208] would lead to the establishment of an LSP across the VPN
provider's network for every RSVP request received, which is not provider's network for every RSVP request received, which is not
desired in this case. desired in this case.
To the extent possible, the approach described in this document is To the extent possible, the approach described in this document is
consistent with [RFC4208], while filling in more of the details and consistent with [RFC4208], while filling in more of the details and
avoiding the problem noted above. avoiding the problem noted above.
Appendix A.2. VRF label approach Appendix A.2. Label switching approach
Implementations that always look at IP headers inside the MPLS label
on the egress PE can intercept Path messages and determine the
correct VRF and RSVP state by using a combination of the
encapsulating VPN label and the IP header. In our view, this is an
undesirable approach for two reasons. Firstly, it imposes a new MPLS
forwarding requirement for all data packets on the egress PE.
Secondly, it requires using the encapsulating MPLS label to identify
RSVP state, which runs counter to existing RSVP principle and
practice where all information used to identify RSVP state is
included within RSVP objects. RSVP extensions such as COPS/RSVP
[RFC2749] which re-encapsulate RSVP messages are incompatible with
this change.
Appendix A.3. VRF label approach
Another approach to solving the problems described here involves the Another approach to solving the problems described here involves the
use of label switching to ensure that Path, Resv, and other RSVP use of label switching to ensure that Path, Resv, and other RSVP
messages are directed to the appropriate VRF. One challenge with messages are directed to the appropriate VRF on the next RSVP hop
such an approach is that [RFC4364] does not require labels to be (e.g. egress PE). One challenge with such an approach is that
allocated for VRFs, only for customer prefixes, and that there is no [RFC4364] does not require labels to be allocated for VRFs, only for
simple, existing method for advertising the fact that a label is customer prefixes, and that there is no simple, existing method for
bound to a VRF. If, for example, an ingress PE sent a Path message advertising the fact that a label is bound to a VRF. If, for
labelled with a VPN label that was advertised by the egress PE for example, an ingress PE sent a Path message labelled with a VPN label
the prefix that matches the destination address in the Path, there is that was advertised by the egress PE for the prefix that matches the
a risk that the egress PE would simply label-switch the Path directly destination address in the Path, there is a risk that the egress PE
on to the CE without performing RSVP processing. would simply label-switch the Path directly on to the CE without
performing RSVP processing.
A second challenge with this approach is that an IP address needs to A second challenge with this approach is that an IP address needs to
be associated with a VRF and used as the PHOP address for the Path be associated with a VRF and used as the PHOP address for the Path
message sent from ingress PE to egress PE. That address needs to be message sent from ingress PE to egress PE. That address needs to be
reachable from the egress PE, and to exist in the VRF at the ingress reachable from the egress PE, and to exist in the VRF at the ingress
PE. Such an address is not always available in today's deployments, PE. Such an address is not always available in today's deployments,
so this represents at least a change to existing deployment so this represents at least a change to existing deployment
practices. practices.
Appendix A.3. VRF label plus VRF address approach Appendix A.4. VRF label plus VRF address approach
It is possible to create an approach based on that described in the It is possible to create an approach based on that described in the
previous section which addresses the main challenges of that previous section which addresses the main challenges of that
approach. The basic approach has two parts: (a) define a new BGP approach. The basic approach has two parts: (a) define a new BGP
Extended Community to tag a route (and its associated MPLS label) as Extended Community to tag a route (and its associated MPLS label) as
pointing to a VRF; (b) allocate a "dummy" address to each VRF, pointing to a VRF; (b) allocate a "dummy" address to each VRF,
specifically to be used for routing RSVP messages. The dummy address specifically to be used for routing RSVP messages. The dummy address
(which could be anything, e.g. a loopback of the associated PE) would (which could be anything, e.g. a loopback of the associated PE) would
be used as a PHOP for Path messages and would serve as the be used as a PHOP for Path messages and would serve as the
destination for Resv messages but would not be imported into VRFs of destination for Resv messages but would not be imported into VRFs of
skipping to change at page 36, line 25 skipping to change at page 36, line 42
[I-D.ietf-l3vpn-e2e-rsvp-te-reqts] [I-D.ietf-l3vpn-e2e-rsvp-te-reqts]
Kumaki, K., Kamite, Y., and R. Zhang, "Requirements for Kumaki, K., Kamite, Y., and R. Zhang, "Requirements for
supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP- supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-
VPN", draft-ietf-l3vpn-e2e-rsvp-te-reqts-05 (work in VPN", draft-ietf-l3vpn-e2e-rsvp-te-reqts-05 (work in
progress), December 2009. progress), December 2009.
[I-D.ietf-mpls-ip-options] [I-D.ietf-mpls-ip-options]
Jaeger, W., Mullooly, J., Scholl, T., and D. Smith, Jaeger, W., Mullooly, J., Scholl, T., and D. Smith,
"Requirements for Label Edge Router Forwarding of IPv4 "Requirements for Label Edge Router Forwarding of IPv4
Option Packets", draft-ietf-mpls-ip-options-03 (work in Option Packets", draft-ietf-mpls-ip-options-04 (work in
progress), January 2010. progress), May 2010.
[I-D.ietf-nsis-ntlp] [I-D.ietf-nsis-ntlp]
Schulzrinne, H. and M. Stiemerling, "GIST: General Schulzrinne, H. and M. Stiemerling, "GIST: General
Internet Signalling Transport", draft-ietf-nsis-ntlp-20 Internet Signalling Transport", draft-ietf-nsis-ntlp-20
(work in progress), June 2009. (work in progress), June 2009.
[I-D.ietf-nsis-qos-nslp] [I-D.ietf-nsis-qos-nslp]
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18
(work in progress), January 2010. (work in progress), January 2010.
 End of changes. 15 change blocks. 
39 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/