draft-ietf-tsvwg-rsvp-l3vpn-02.txt   draft-ietf-tsvwg-rsvp-l3vpn-03.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: November 29, 2009 Cisco Systems, Inc. Expires: April 29, 2010 Cisco Systems, Inc.
May 28, 2009 October 26, 2009
Support for RSVP in Layer 3 VPNs Support for RSVP in Layer 3 VPNs
draft-ietf-tsvwg-rsvp-l3vpn-02.txt draft-ietf-tsvwg-rsvp-l3vpn-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 29, 2009. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
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 CE and PE use RSVP to perform admission control on the links between Customer
routers. This document specifies procedures by which RSVP messages Edge (CE) routers and Provider Edge (PE) routers. This document
travelling from CE to CE across an L3VPN may be appropriately handled specifies procedures by which RSVP messages travelling from CE to CE
by PE routers so that admission control can be performed on PE-CE across an L3VPN may be appropriately handled by PE routers so that
links. Optionally, admission control across the provider's backbone admission control can be performed on PE-CE links. Optionally,
may also be supported. admission control across the provider's backbone may also be
supported.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
skipping to change at page 3, line 44 skipping to change at page 3, line 44
8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects . . . . . . . . 20 8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects . . . . . . . . 20
8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects . . . . . . . . . . 21 8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects . . . . . . . . . . 21
8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . 23 8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . 23
8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6
SENDER_TEMPLATE objects . . . . . . . . . . . . . . . . . 25 SENDER_TEMPLATE objects . . . . . . . . . . . . . . . . . 25
8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC 8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC
objects . . . . . . . . . . . . . . . . . . . . . . . . . 26 objects . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
Appendix A. Alternatives Considered . . . . . . . . . . . . . . 32 Appendix A. Alternatives Considered . . . . . . . . . . . . . . 33
Appendix A.1. GMPLS UNI approach . . . . . . . . . . . . . . . . . 32 Appendix A.1. GMPLS UNI approach . . . . . . . . . . . . . . . . . 33
Appendix A.2. VRF label approach . . . . . . . . . . . . . . . . . 33 Appendix A.2. VRF label approach . . . . . . . . . . . . . . . . . 33
Appendix A.3. VRF label plus VRF address approach . . . . . . . . 33 Appendix A.3. VRF label plus VRF address approach . . . . . . . . 34
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 12.1. Normative References . . . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . . 34 12.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
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 17, line 50 skipping to change at page 17, line 50
flags. The appropriate VPN and transport labels are applied to flags. The appropriate VPN and transport labels are applied to
the frame and it is forwarded towards the remote CE. Note that the frame and it is forwarded towards the remote CE. Note that
this message will not be received or processed by any other P or this message will not be received or processed by any other P or
PE node. PE node.
o Any SESSION-OF-INTEREST objects (defined in [RFC4860]) are to be o Any SESSION-OF-INTEREST objects (defined in [RFC4860]) are to be
conveyed unmodified across the MPLS VPN. conveyed unmodified across the MPLS VPN.
7.4. Support for CE-CE RSVP-TE 7.4. Support for CE-CE RSVP-TE
[I-D.kumaki-l3vpn-e2e-rsvp-te-reqts] describes a set of requirements [I-D.ietf-l3vpn-e2e-rsvp-te-reqts] describes a set of requirements
for the establishment for CE-CE MPLS LSPs across networks offering an for the establishment for CE-CE MPLS LSPs across networks offering an
L3VPN service. The requirements specified in that draft are similar L3VPN service. The requirements specified in that draft are similar
to those addressed by this document, in that both address the issue to those addressed by this document, in that both address the issue
of handling RSVP requests from customers in a VPN context. It is of handling RSVP requests from customers in a VPN context. It is
possible that the solution described here could be adapted to meet possible that the solution described here could be adapted to meet
the requirements of [I-D.kumaki-l3vpn-e2e-rsvp-te-reqts]. To the the requirements of [I-D.ietf-l3vpn-e2e-rsvp-te-reqts]. To the
extent that this draft uses signalling extensions described in extent that this draft uses signalling extensions described in
[RFC3473] which have already been used for GMPLS/TE, we expect that [RFC3473] which have already been used for GMPLS/TE, we expect that
CE-CE RSVP/TE will be incremental work built on these extensions. CE-CE RSVP/TE will be incremental work built on these extensions.
These extensions will be considered in a separate document. These extensions will be considered in a separate document.
8. Object Definitions 8. Object Definitions
8.1. VPN-IPv4 and VPN-IPv6 SESSION objects 8.1. VPN-IPv4 and VPN-IPv6 SESSION objects
The usage of the VPN-IPv4 (or VPN-IPv6) SESSION Object is described The usage of the VPN-IPv4 (or VPN-IPv6) SESSION Object is described
skipping to change at page 32, line 18 skipping to change at page 32, line 18
This requirement does not strictly apply to MPLS/BGP VPNs [RFC4364]. This requirement does not strictly apply to MPLS/BGP VPNs [RFC4364].
This could be viewed as opening ASBRs and PEs to being directly This could be viewed as opening ASBRs and PEs to being directly
addressable by customer devices where they were not open before, and addressable by customer devices where they were not open before, and
could be considered a security issue. If a provider wishes to could be considered a security issue. If a provider wishes to
mitigate this situation, the implementation MAY support the "control mitigate this situation, the implementation MAY support the "control
protocol VPN" approach described above. That is, whenever a protocol VPN" approach described above. That is, whenever a
signalling message is to be sent to a PE or ASBR, the address of the signalling message is to be sent to a PE or ASBR, the address of the
router in question would be looked up in the "control protocol VPN", router in question would be looked up in the "control protocol VPN",
and the message would then be sent on the LSP that is found as a and the message would then be sent on the LSP that is found as a
result of that lookup. This would ensure that the router address is result of that lookup. This would ensure that the router address is
not reachable by customer devices not reachable by customer devices.
[RFC4364] mentions use of IPsec both on a CE-CE basis and PE-PE
basis: "Cryptographic privacy is not provided by this architecture,
nor by 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 PE-PE basis is for further
study."
The procedures specified in the present document for admission
control on the PE-CE links (Section 3) are compatible with the use of
IPsec on a PE-PE basis. The optional procedures specified in the
present document for admission control in the Service Provider's
backbone (Section 4) are not compatible with the use of IPsec on a
PE-PE basis, since those procedures depend on the use of PE-PE MPLS
TE Tunnels to perform aggregate reservations through the Service
Provider's backbone.
[RFC4923] describes a model for RSVP operation through IPsec
Gateways. In a nutshell, a form of hierarchical RSVP reservation is
used where an RSVP reservation is made for the IPsec tunnel and then
individual RSVP reservations are admitted/aggregated over the tunnel
reservation. This model applies to the case where IPsec is used on a
CE-CE basis. In that situation, the procedures defined in the
present document would simply apply "as is" to the reservation
established for the IPsec tunnel(s).
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 draft. Thanks to Ferit solving the problems described in this draft. Thanks to Ferit
Yegenoglu for his useful comments. Yegenoglu for his useful comments. We also thank Stefan Santesson
and Vijay Gurbani for their review comments.
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 19 skipping to change at page 34, line 46
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for "BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, September 2006. IPv6 VPN", RFC 4659, September 2006.
[RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation
Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels",
RFC 4804, February 2007. RFC 4804, February 2007.
12.2. Informative References 12.2. Informative References
[I-D.ietf-l3vpn-e2e-rsvp-te-reqts]
Kumaki, K., Kamite, Y., and R. Zhang, "Requirements for
supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-
VPN", draft-ietf-l3vpn-e2e-rsvp-te-reqts-04 (work in
progress), August 2009.
[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-19 Internet Signalling Transport", draft-ietf-nsis-ntlp-20
(work in progress), March 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-16 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16
(work in progress), February 2008. (work in progress), February 2008.
[I-D.ietf-tsvwg-rsvp-security-groupkeying] [I-D.ietf-tsvwg-rsvp-security-groupkeying]
Behringer, M. and F. Faucheur, "Applicability of Keying Behringer, M. and F. Faucheur, "Applicability of Keying
Methods for RSVP Security", Methods for RSVP Security",
draft-ietf-tsvwg-rsvp-security-groupkeying-04 (work in draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in
progress), March 2009. progress), June 2009.
[I-D.kumaki-l3vpn-e2e-rsvp-te-reqts]
Kumaki, K., "Requirements for supporting Customer RSVP and
RSVP-TE Over a BGP/MPLS IP-VPN",
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-06 (work in
progress), February 2008.
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview", Services in the Internet Architecture: an Overview",
RFC 1633, June 1994. RFC 1633, June 1994.
[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol [RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol
(RSVP) -- Version 1 Message Processing Rules", RFC 2209, (RSVP) -- Version 1 Message Processing Rules", RFC 2209,
September 1997. September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
skipping to change at page 35, line 34 skipping to change at page 36, line 12
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User- "Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol- Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, October 2005. Model", RFC 4208, October 2005.
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M.
Davenport, "Generic Aggregate Resource ReSerVation Davenport, "Generic Aggregate Resource ReSerVation
Protocol (RSVP) Reservations", RFC 4860, May 2007. Protocol (RSVP) Reservations", RFC 4860, May 2007.
[RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS) Signaling
in a Nested Virtual Private Network", RFC 4923,
August 2007.
Authors' Addresses Authors' Addresses
Bruce Davie Bruce Davie
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Mass. Ave. 1414 Mass. Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: bsd@cisco.com Email: bsd@cisco.com
Francois le Faucheur Francois le Faucheur
Cisco Systems, Inc. Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3 Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille 400, Avenue de Roumanille
Biot Sophia-Antipolis 06410 Biot Sophia-Antipolis 06410
France France
Email: flefauch@cisco.com Email: flefauch@cisco.com
Ashok Narayanan Ashok Narayanan
 End of changes. 16 change blocks. 
30 lines changed or deleted 62 lines changed or added

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