draft-ietf-tsvwg-rsvp-l3vpn-01.txt   draft-ietf-tsvwg-rsvp-l3vpn-02.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: May 3, 2009 Cisco Systems, Inc. Expires: November 29, 2009 Cisco Systems, Inc.
October 30, 2008 May 28, 2009
Support for RSVP in Layer 3 VPNs Support for RSVP in Layer 3 VPNs
draft-ietf-tsvwg-rsvp-l3vpn-01.txt draft-ietf-tsvwg-rsvp-l3vpn-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 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.
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."
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 May 3, 2009. This Internet-Draft will expire on November 29, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
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 CE and PE
routers. This document specifies procedures by which RSVP messages routers. This document specifies procedures by which RSVP messages
travelling from CE to CE across an L3VPN may be appropriately handled travelling from CE to CE across an L3VPN may be appropriately handled
by PE routers so that admission control can be performed on PE-CE by PE routers so that admission control can be performed on PE-CE
links. Optionally, admission control across the provider's backbone links. Optionally, admission control across the provider's backbone
may also be supported. 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].
Change history
[_Note to RFC Editor: This section to be removed before publication_]
Changes in this version (draft-ietf-tsvwg-rsvp-l3vpn-01) relative to
the last (draft-ietf-tsvwg-rsvp-l3vpn-00):
o Recommended the use of VPN-IPv4 HOP object in all cases
o Clarified usage and security considerations regarding VPN-IPv4
address used for signalling (removed discussion on potential usage
of an extended-community to control redistribution)
o Minor clarifications and typographical corrections
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Model of Operation . . . . . . . . . . . . . . . . . . . . 6 2.1. Model of Operation . . . . . . . . . . . . . . . . . . . . 6
3. Admission Control on PE-CE Links . . . . . . . . . . . . . . . 7 3. Admission Control on PE-CE Links . . . . . . . . . . . . . . . 7
3.1. New Objects of Type VPN-IPv4 . . . . . . . . . . . . . . . 8 3.1. New Objects of Type VPN-IPv4 . . . . . . . . . . . . . . . 8
3.2. Path Message Processing at Ingress PE . . . . . . . . . . 9 3.2. Path Message Processing at Ingress PE . . . . . . . . . . 9
3.3. Path Message Processing at Egress PE . . . . . . . . . . . 10 3.3. Path Message Processing at Egress PE . . . . . . . . . . . 10
skipping to change at page 3, line 36 skipping to change at page 3, line 36
7. Other RSVP procedures . . . . . . . . . . . . . . . . . . . . 16 7. Other RSVP procedures . . . . . . . . . . . . . . . . . . . . 16
7.1. Refresh overhead reduction . . . . . . . . . . . . . . . . 16 7.1. Refresh overhead reduction . . . . . . . . . . . . . . . . 16
7.2. Cryptographic Authentication . . . . . . . . . . . . . . . 16 7.2. Cryptographic Authentication . . . . . . . . . . . . . . . 16
7.3. RSVP Aggregation . . . . . . . . . . . . . . . . . . . . . 17 7.3. RSVP Aggregation . . . . . . . . . . . . . . . . . . . . . 17
7.4. Support for CE-CE RSVP-TE . . . . . . . . . . . . . . . . 17 7.4. Support for CE-CE RSVP-TE . . . . . . . . . . . . . . . . 17
8. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 18 8. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 18
8.1. VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . . . . . . 18 8.1. VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . . . . . . 18
8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects . . . . . . 19 8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects . . . . . . 19
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 . . . . . 22 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 . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
Appendix A. Alternatives Considered . . . . . . . . . . . . . . 31 Appendix A. Alternatives Considered . . . . . . . . . . . . . . 32
Appendix A.1. GMPLS UNI approach . . . . . . . . . . . . . . . . . 31 Appendix A.1. GMPLS UNI approach . . . . . . . . . . . . . . . . . 32
Appendix A.2. VRF label approach . . . . . . . . . . . . . . . . . 32 Appendix A.2. VRF label approach . . . . . . . . . . . . . . . . . 33
Appendix A.3. VRF label plus VRF address approach . . . . . . . . 32 Appendix A.3. VRF label plus VRF address approach . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
12.1. Normative References . . . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . . 33
12.2. Informative References . . . . . . . . . . . . . . . . . . 33 12.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 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
admission control in their own networks. Since the links between admission control (and associated resource reservation) in their own
Provider Edge (PE) and Customer Edge (CE) routers in a layer 3 VPN networks. Since the links between Provider Edge (PE) and Customer
may often be resource constrained, it may be desirable to be able to Edge (CE) routers in a layer 3 VPN may often be resource constrained,
perform admission control over those links. In order to perform it may be desirable to be able to perform admission control over
admission control using RSVP in such an environment, it is necessary those links. In order to perform admission control using RSVP in
that RSVP control messages, such as Path messages and Resv messages, such an environment, it is necessary that RSVP control messages, such
are appropriately handled by the PE routers. This presents a number as Path messages and Resv messages, are appropriately handled by the
of challenges in the context of BGP/MPLS VPNs: PE routers. This presents a number of challenges in the context of
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 in the IP header. However, packets traversing router alert option in the IP header. However, packets traversing
the backbone of a BGP/MPLS VPN are MPLS encapsulated and thus the the backbone of a BGP/MPLS VPN are MPLS encapsulated and thus the
router alert option is not normally visible to the egress PE. router alert option is not normally visible to the egress PE.
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. with non-unique destination addresses.
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.
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 NSIS [RFC4080]. other protocols used for admission control such as the combination of
the NSIS Signaling Layer Protocol (NSLP) for QoS Signaling
([I-D.ietf-nsis-qos-nslp]) and General Internet Signaling Transport
(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.
Core (P) routers in a BGP/MPLS VPN do not have forwarding entries for Core (P) routers in a BGP/MPLS VPN do not have forwarding entries for
customer routes, and thus cannot natively process RSVP messages for customer routes, and thus cannot natively process RSVP messages for
customer flows. Also the core is a shared resource that carries customer flows. Also the core is a shared resource that carries
traffic for many customers, so issues of resource allocation among traffic for many customers, so issues of resource allocation among
customers and trust (or lack thereof) must also be addressed. This customers and trust (or lack thereof) must also be addressed. This
draft also specifies procedures for supporting such a scenario. draft also specifies procedures for supporting such a scenario.
skipping to change at page 8, line 22 skipping to change at page 8, line 22
new types of SESSION, SENDER_TEMPLATE and FILTERSPEC objects, which new types of SESSION, SENDER_TEMPLATE and FILTERSPEC objects, which
contain globally unique VPN-IPv4 format addresses. The ingress and contain globally unique VPN-IPv4 format addresses. The ingress and
egress PE nodes translate between the regular IPv4 addresses for egress PE nodes translate between the regular IPv4 addresses for
messages to and from the CE, and VPN-IPv4 addresses for messages to messages to and from the CE, and VPN-IPv4 addresses for messages to
and from PE routers. The rules for this translation are described in and from PE routers. The rules for this translation are described in
later sections. later sections.
The RSVP_HOP object in a RSVP message currently specifies an IP The RSVP_HOP object in a RSVP message currently specifies an IP
address to be used by the neighboring RSVP hop to reply to the address to be used by the neighboring RSVP hop to reply to the
message sender. However, MPLS VPN PE routers (especially those message sender. However, MPLS VPN PE routers (especially those
separated by Option-B ASBRs) are not required to have direct IP separated by Option-B Autonomous System Border Routers -ASBRs) are
reachability to each other. To solve this issue, we propose the use not required to have direct IP reachability to each other. To solve
of label switching to forward RSVP messages between nodes within a this issue, we propose the use of label switching to forward RSVP
MPLS VPN. This is achieved by defining a new VPN-IPv4 RSVP_HOP messages between nodes within a MPLS VPN. This is achieved by
object. Use of the VPN-IPv4 RSVP_HOP object enables RSVP control defining a new VPN-IPv4 RSVP_HOP object. Use of the VPN-IPv4
plane reachability between any two adjacent RSVP hops in a MPLS VPN RSVP_HOP object enables RSVP control plane reachability between any
(e.g. a PE in AS 1 and a PE in AS2), regardless of whether they have two adjacent RSVP hops in a MPLS VPN (e.g. a PE in AS 1 and a PE in
IP reachability to each other. AS2), regardless of whether they have IP reachability to each other.
The VPN-IPv4 RSVP_HOP object carries the IPv4 address of the message The VPN-IPv4 RSVP_HOP object carries the IPv4 address of the message
sender and a logical interface handle as before, but in addition sender and a logical interface handle as before, but in addition
carries a VPN-IPv4 address which also represents the sender of the carries a VPN-IPv4 address which also represents the sender of the
message. The message sender MUST also advertise this VPN-IPv4 HOP message. The message sender MUST also advertise this VPN-IPv4 HOP
address into BGP, associated with a locally allocated label, and this address into BGP, associated with a locally allocated label, and this
advertisement MUST be propagated by BGP throughout the VPN and to advertisement MUST be propagated by BGP throughout the VPN and to
adjacent ASes if required to provide reachability to this PE. Frames adjacent ASes if required to provide reachability to this PE. Frames
received by the PE marked with this label MUST be given to the local received by the PE marked with this label MUST be given to the local
control plane for processing. When a neighboring RSVP hop wishes to control plane for processing. When a neighboring RSVP hop wishes to
skipping to change at page 13, line 46 skipping to change at page 13, line 46
[RFC4364] defines three modes of inter-AS operation for MPLS/BGP [RFC4364] defines three modes of inter-AS operation for MPLS/BGP
VPNs, referred to as options A, B and C. In the following sections we VPNs, referred to as options A, B and C. In the following sections we
describe how the scheme described above can operate in each inter-AS describe how the scheme described above can operate in each inter-AS
environment. environment.
5.1. Inter-AS Option A 5.1. Inter-AS Option A
Operation of RSVP in Inter-AS Option A is quite straightforward. Operation of RSVP in Inter-AS Option A is quite straightforward.
Each ASBR operates like a PE, and the ASBR-ASBR links can be viewed Each ASBR operates like a PE, and the ASBR-ASBR links can be viewed
as PE-CE links in terms of admission control. If the procedures as PE-CE links in terms of admission control. If the procedures
defined in Section 3 are enabled on both ASBRs, then CAC may be defined in Section 3 are enabled on both ASBRs, then admission
performed on the inter-ASBR links. In addition, the operator of each control may be performed on the inter-ASBR links. In addition, the
AS can independently decide whether or not to perform CAC across his operator of each AS can independently decide whether or not to
backbone. The new objects described in this document MUST NOT be perform admission control across his backbone. The new objects
sent in any RSVP message between two Option-A ASBRs. described in this document MUST NOT be sent in any RSVP message
between two Option-A ASBRs.
5.2. Inter-AS Option B 5.2. Inter-AS Option B
To support inter-AS Option B, we require some additional processing To support inter-AS Option B, we require some additional processing
of RSVP messages on the ASBRs. Recall that, when packets are of RSVP messages on the ASBRs. Recall that, when packets are
forwarded from one AS to another in option B, the VPN label is forwarded from one AS to another in option B, the VPN label is
swapped by each ASBR as a packet goes from one AS to another. The swapped by each ASBR as a packet goes from one AS to another. The
BGP next hop seen by the ingress PE will be the ASBR, and there need BGP next hop seen by the ingress PE will be the ASBR, and there need
not be IP visibility between the ingress and egress PEs. Hence when not be IP visibility between the ingress and egress PEs. Hence when
the ingress PE sends the Path message to the BGP next hop of the VPN- the ingress PE sends the Path message to the BGP next hop of the VPN-
skipping to change at page 15, line 7 skipping to change at page 15, line 9
send RSVP messages directly between them. This is only possible if send RSVP messages directly between them. This is only possible if
they are MPLS-encapsulated. The use of the VPN-IPv4 HOP object they are MPLS-encapsulated. The use of the VPN-IPv4 HOP object
described in Section 3.1 is REQUIRED in this case. described in Section 3.1 is REQUIRED in this case.
When an ASBR that is not installing local RSVP state receives a Path When an ASBR that is not installing local RSVP state receives a Path
message, it looks up the next-hop of the matching BGP route as message, it looks up the next-hop of the matching BGP route as
described in Section 3.2, and sends the Path message to the next-hop, described in Section 3.2, and sends the Path message to the next-hop,
without modifying any RSVP objects (including the RSVP_HOP). This without modifying any RSVP objects (including the RSVP_HOP). This
process is repeated at subsequent ASBRs until the Path message process is repeated at subsequent ASBRs until the Path message
arrives at a router that is installing local RSVP state (either the arrives at a router that is installing local RSVP state (either the
ultimate egress PE, or an ASBR configured to perform CAC). This ultimate egress PE, or an ASBR configured to perform admission
router receives the Path and processes it as described in Section 3.3 control). This router receives the Path and processes it as
if it is a PE, or Section 5.2.1 if it is an ASBR performing CAC. described in Section 3.3 if it is a PE, or Section 5.2.1 if it is an
When this router sends the Resv upstream, it looks up the routing ASBR performing admission control. When this router sends the Resv
table for a next-hop+label for the VPN-IPv4 address in the PHOP, upstream, it looks up the routing table for a next-hop+label for the
encapsulates the Resv with that label and sends it upstream. This VPN-IPv4 address in the PHOP, encapsulates the Resv with that label
message will be received for control processing directly on the and sends it upstream. This message will be received for control
upstream RSVP hop (that last updated the RSVP_HOP field in the Path processing directly on the upstream RSVP hop (that last updated the
message), without any involvement of intermediate ASBRs. RSVP_HOP field in the Path message), without any involvement of
intermediate ASBRs.
The ASBR is not expected to process any other RSVP messages apart The ASBR is not expected to process any other RSVP messages apart
from the Path message as described above. The ASBR also does not from the Path message as described above. The ASBR also does not
need to store any RSVP state. Note that any ASBR along the path that need to store any RSVP state. Note that any ASBR along the path that
wishes to do admission control or insert itself into the RSVP wishes to do admission control or insert itself into the RSVP
signalling flow, may do so by writing its own RSVP_HOP object with signalling flow, may do so by writing its own RSVP_HOP object with
IPv4 and VPN-IPv4 address pointing to itself. IPv4 and VPN-IPv4 address pointing to itself.
If an Option-B ASBR receives a RSVP Path message with an IPv4 If an Option-B ASBR receives a RSVP Path message with an IPv4
RSVP_HOP, does not wish to perform admission control but is willing RSVP_HOP, does not wish to perform admission control but is willing
to install local state for this flow, the ASBR MUST process and to install local state for this flow, the ASBR MUST process and
forward RSVP signalling messages for this flow as described in forward RSVP signalling messages for this flow as described in
Section 5.2.1 (with the exception that it does not perform admission Section 5.2.1 (with the exception that it does not perform admission
control). If an Option-B ASBR receives a RSVP Path message with an control). If an Option-B ASBR receives a RSVP Path message with an
IPv4 RSVP_HOP, but does not wish to install local state or perform IPv4 RSVP_HOP, but does not wish to install local state or perform
admission control for this flow, the ASBR MUST NOT forward the Path admission control for this flow, the ASBR MUST NOT forward the Path
message. In addition, the ASBR SHOULD send a PathError message of message. In addition, the ASBR SHOULD send a PathError message of
Error Code [_TBD_], Error Value [_TBD_], (see Section 9) signifying Error Code "RSVP over MPLS Problem"_, _Error Value "RSVP_HOP not
to the upstream RSVP hop that the supplied RSVP_HOP object is reachable across VPN" (see Section 9) signifying to the upstream RSVP
insufficient to provide reachability across this VPN. This failure hop that the supplied RSVP_HOP object is insufficient to provide
condition is not expected to be recoverable. reachability across this VPN. This failure condition is not expected
to be recoverable.
5.3. Inter-AS Option C 5.3. Inter-AS Option C
Operation of RSVP in Inter-AS Option C is also quite straightforward, Operation of RSVP in Inter-AS Option C is also quite straightforward,
because there exists an LSP directly from ingress PE to egress PE. because there exists an LSP directly from ingress PE to egress PE.
In this case, there is no significant difference in operation from In this case, there is no significant difference in operation from
the single AS case described in Section 3. Furthermore, if it is the single AS case described in Section 3. Furthermore, if it is
desired to provide admission control from PE to PE, it can be done by desired to provide admission control from PE to PE, it can be done by
building an inter-AS TE tunnel and then using the procedures building an inter-AS TE tunnel and then using the procedures
described in Section 4. described in Section 4.
skipping to change at page 18, line 17 skipping to change at page 18, line 17
the requirements of [I-D.kumaki-l3vpn-e2e-rsvp-te-reqts]. To the the requirements of [I-D.kumaki-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 SESSION Object is described in Section 3.2 The usage of the VPN-IPv4 (or VPN-IPv6) SESSION Object is described
and Section 3.3. The VPN-IPv4 SESSION object should appear in all in Section 3.2 to Section 3.6. The VPN-IPv4 (or VPN-IPv6) SESSION
RSVP messages that ordinarily contain a SESSION object and are sent object appears in RSVP messages that ordinarily contain a SESSION
between ingress PE and egress PE in either direction. The object object and are sent between ingress PE and egress PE in either
MUST NOT be included in any RSVP messages that are sent outside of direction. The object MUST NOT be included in any RSVP messages that
the provider's backbone (except in the inter-AS option B and C cases, are sent outside of the provider's backbone (except in the inter-AS
as described above, when it may appear on inter-AS links). The VPN- option B and C cases, as described above, when it may appear on
IPv4 address in this object is built by combining the IPv4 address inter-AS links).
from the incoming SESSION with the RD in the BGP advertisement from
the egress PE for this prefix and customer.
The VPN-IPv6 SESSION object is analogous to the VPN-IPv4 SESSION The VPN-IPv6 SESSION object is analogous to the VPN-IPv4 SESSION
object, using VPN-IPv6 addresses[RFC4659]. object, using an VPN-IPv6 address ([RFC4659]) instead of an VPN-IPv4
address ([RFC4364]).
The formats of the objects are as follows: The formats of the objects are as follows:
o VPN-IPv4 SESSION object: Class = 1, C-Type = TBA o VPN-IPv4 SESSION object: Class = 1, C-Type = TBA
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| VPN-IPv4 DestAddress (12 bytes) | | VPN-IPv4 DestAddress (12 bytes) |
+ + + +
skipping to change at page 19, line 19 skipping to change at page 19, line 19
| | | |
+ VPN-IPv6 DestAddress (24 bytes) + + VPN-IPv6 DestAddress (24 bytes) +
/ / / /
. . . .
/ / / /
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort | | Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
The protocol ID, flags, and DstPort are identical to the IPv4 and The VPN-IPv4 DestAddress (respectively VPN-IPv6 DestAddress) field
IPv6 SESSION objects. contains an address of the VPN-IPv4 (respectively VPN-IPv6) address
family encoded as specified in [RFC4364] (respectively [RFC4659]).
The content of this field is discussed in Section 3.2 and
Section 3.3.
The protocol ID, flags, and DstPort are identical to the same fields
in the IPv4 and IPv6 SESSION objects ([RFC2205]).
8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects 8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects
The usage of the VPN-IPv4 SENDER_TEMPLATE Object is described in The usage of the VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE Object is
Section 3.2 and Section 3.3. The VPN-IPv4 SENDER_TEMPLATE object described in Section 3.2 and Section 3.3. The VPN-IPv4 (or VPN-IPv6)
should appear in all RSVP messages that ordinarily contain a SENDER_TEMPLATE object appears in RSVP messages that ordinarily
SENDER_TEMPLATE object and are sent between ingress PE and egress PE contain a SENDER_TEMPLATE object and are sent between ingress PE and
in either direction (such as Path, PathError, and PathTear). The egress PE in either direction (such as Path, PathError, and
object MUST NOT be included in any RSVP messages that are sent PathTear). The object MUST NOT be included in any RSVP messages that
outside of the provider's backbone (except in the inter-AS option B are sent outside of the provider's backbone (except in the inter-AS
and C cases, as described above, when it may appear on inter-AS option B and C cases, as described above, when it may appear on
links). The VPN-IPv4 address in this object is built by combining inter-AS links). The format of the object is as follows:
the IPv4 address from the incoming SENDER_TEMPLATE with the RD in the
BGP advertisement from the ingress PE for this prefix and customer.
The format of the object is as follows:
o VPN-IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = TBA o VPN-IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = TBA
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| VPN-IPv4 SrcAddress (12 bytes) | | VPN-IPv4 SrcAddress (12 bytes) |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 20, line 32 skipping to change at page 20, line 32
| | | |
+ VPN-IPv6 SrcAddress (24 bytes) + + VPN-IPv6 SrcAddress (24 bytes) +
/ / / /
. . . .
/ / / /
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Reserved | SrcPort | | Reserved | SrcPort |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
The SrcPort is identical to the IPv4 and IPv6 SENDER_TEMPLATE The VPN-IPv4 SrcAddress (respectively VPN-IPv6 SrcAddress) field
objects. The Reserved field must be set to zero on transmit and contains an address of the VPN-IPv4 (respectively VPN-IPv6) address
ignored on receipt. family encoded as specified in [RFC4364] (respectively [RFC4659]).
The content of this field is discussed in Section 3.2 and
Section 3.3.
The SrcPort is identical to the SrcPort field in the IPv4 and IPv6
SENDER_TEMPLATE objects ([RFC2205]).
The Reserved field must be set to zero on transmit and ignored on
receipt.
8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects 8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects
The usage of the VPN-IPv4 FILTER_SPEC Object is described in The usage of the VPN-IPv4 (or VPN-IPv6) FILTER_SPEC Object is
Section 3.4 and Section 3.5. The VPN-IPv4 FILTER_SPEC object should described in Section 3.4 and Section 3.5. The VPN-IPv4 (or VPN-IPv6)
appear in all RSVP messages that ordinarily contain a FILTER_SPEC FILTER_SPEC object appears in RSVP messages that ordinarily contain a
object and are sent between ingress PE and egress PE in either FILTER_SPEC object and are sent between ingress PE and egress PE in
direction (such as Resv, ResvError, and ResvTear). The object MUST either direction (such as Resv, ResvError, and ResvTear). The object
NOT be included in any RSVP messages that are sent outside of the MUST NOT be included in any RSVP messages that are sent outside of
provider's backbone (except in the inter-AS option B and C cases, as the provider's backbone (except in the inter-AS option B and C cases,
described above, when it may appear on inter-AS links). The VPN-IPv4 as described above, when it may appear on inter-AS links).
address in this object is built by combining the IPv4 address from
the incoming FILTER_SPEC with the RD in the BGP advertisement from
the ingress PE for this prefix and customer.
o VPN-IPv4 FILTER_SPEC object: Class = 10, C-Type = TBA o VPN-IPv4 FILTER_SPEC object: Class = 10, C-Type = TBA
Definition same as VPN-IPv4 SENDER_TEMPLATE object. Definition same as VPN-IPv4 SENDER_TEMPLATE object.
o VPN-IPv6 FILTER_SPEC object: Class = 10, C-Type = TBA o VPN-IPv6 FILTER_SPEC object: Class = 10, C-Type = TBA
Definition same as VPN-IPv6 SENDER_TEMPLATE object. Definition same as VPN-IPv6 SENDER_TEMPLATE object.
The protocol ID, flags, and DstPort are identical to the IPv4 and The content of the VPN-IPv4 SrcAddress (or VPN-IPv6 SrcAddress) field
IPv6 SESSION objects. is discussed in Section 3.4 and Section 3.5.
The SrcPort is identical to the SrcPort field in the IPv4 and IPv6
SENDER_TEMPLATE objects ([RFC2205]).
The Reserved field must be set to zero on transmit and ignored on
receipt.
8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects 8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects
Usage of the VPN-IPv4 RSVP_HOP Object is described in Section 5.2.2. Usage of the VPN-IPv4 (or VPN-IPv6) RSVP_HOP Object is described in
The VPN-IPv4 RSVP_HOP object is used to establish signalling Section 3.1 and Section 5.2.2. The VPN-IPv4 (VPN-IPv6) RSVP_HOP
reachability between RSVP neighbors separated by one or more Option-B object is used to establish signalling reachability between RSVP
ASBRs. This object may appear in all RSVP messages that carry a neighbors separated by one or more Option-B ASBRs. This object may
RSVP_HOP object, and that travel between the Ingress and Egress PEs. appear in RSVP messages that carry a RSVP_HOP object, and that travel
It MUST NOT be included in any RSVP messages that are sent outside of between the Ingress and Egress PEs. It MUST NOT be included in any
the provider's backbone (except in the inter-AS option B and C cases, RSVP messages that are sent outside of the provider's backbone
as described above, when it may appear on inter-AS links). The (except in the inter-AS option B and C cases, as described above,
format of the object is as follows: when it may appear on inter-AS links). The format of the object is
as follows:
o VPN-IPv4 RSVP_HOP object: Class = 3, C-Type = TBA o VPN-IPv4 RSVP_HOP object: Class = 3, C-Type = TBA
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| IPv4 Next/Previous Hop Address (4 bytes) | | IPv4 Next/Previous Hop Address (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| VPN-IPv4 Next/Previous Hop Address (12 bytes) | | VPN-IPv4 Next/Previous Hop Address (12 bytes) |
+ + +
+
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Logical Interface Handle | | Logical Interface Handle |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o VPN-IPv6 RSVP_HOP object: Class = 3, C-Type = TBA o VPN-IPv6 RSVP_HOP object: Class = 3, C-Type = TBA
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ IPv6 Next/Previous Hop Address (16 bytes) + + IPv6 Next/Previous Hop Address (16 bytes) +
| | | |
+ + + +
| | | |
skipping to change at page 22, line 27 skipping to change at page 22, line 42
| | | |
+ VPN-IPv6 Next/Previous Hop Address (24 bytes) + + VPN-IPv6 Next/Previous Hop Address (24 bytes) +
/ / / /
. . . .
/ / / /
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Logical Interface Handle | | Logical Interface Handle |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
The IPv4 Next/Previous Hop Address, IPv6 Next/Previous Hop Address
and the Logical Interface Handle fields are identical to those of the
RSVP_HOP object ([RFC2205]).
The VPN-IPv4 Next/Previous Hop Address (respectively VPN-IPv6 Next/
Previous Hop Address) field contains an address of the VPN-IPv4
(respectively VPN-IPv6) address family encoded as specified in
[RFC4364] (respectively [RFC4659]). The content of this field is
discussed in Section 3.1.
8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects 8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects
The usage of Aggregated VPN-IPv4 SESSION object is described in The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SESSION object is
Section 7.3. The AGGREGATE-VPN-IPv4 SESSION object should appear in described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively
all RSVP messages that ordinarily contain a AGGREGATE-IPv4 SESSION AGGREGATE-IPv6-VPN) SESSION object appears in RSVP messages that
object as defined in [RFC3175] and are sent between ingress PE and ordinarily contain a AGGREGATE-IPv4 (respectively AGGREGATE-IPv6)
egress PE in either direction. The GENERIC-AGGREGATE-VPN-IPv4 SESSION object as defined in [RFC3175] and are sent between ingress
SESSION object should appear in all RSVP messages that ordinarily PE and egress PE in either direction. The GENERIC-AGGREGATE-VPN-IPv4
contain a GENERIC-AGGREGATE-IPv4 SESSION object as defined in (respectively AGGREGATE-VPN-IPv6) SESSION object should appear in all
RSVP messages that ordinarily contain a GENERIC-AGGREGATE-IPv4
(respectively GENERIC-AGGREGATE-IPv6) SESSION object as defined in
[RFC4860] and are sent between ingress PE and egress PE in either [RFC4860] and are sent between ingress PE and egress PE in either
direction. These objects MUST NOT be included in any RSVP messages direction. These objects MUST NOT be included in any RSVP messages
that are sent outside of the provider's backbone (except in the that are sent outside of the provider's backbone (except in the
inter-AS option B and C cases, as described above, when it may appear inter-AS option B and C cases, as described above, when it may appear
on inter-AS links). The processing rules for these objects are on inter-AS links). The processing rules for these objects are
otherwise identical to those of the VPN-IPv4 SESSION object defined otherwise identical to those of the VPN-IPv4 (respectively VPN-IPv6)
in Section 8.1. The VPN-IPv4 address in this object is built by SESSION object defined in Section 8.1. The format of the object is
combining the IPv4 address from the incoming SESSION with the RD in as follows:
the BGP advertisement from the egress PE for this prefix and
customer. The format of the object is as follows:
o AGGREGATE-VPN-IPv4 SESSION object: Class = 1, C-Type = TBA o AGGREGATE-VPN-IPv4 SESSION object: Class = 1, C-Type = TBA
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| VPN-IPv4 DestAddress (12 bytes) | | VPN-IPv4 DestAddress (12 bytes) |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 23, line 32 skipping to change at page 24, line 19
| | | |
+ VPN-IPv6 DestAddress (24 bytes) + + VPN-IPv6 DestAddress (24 bytes) +
/ / / /
. . . .
/ / / /
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Reserved | Flags | Reserved | DSCP | | Reserved | Flags | Reserved | DSCP |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
The flags and DSCP are identical to the AGGREGATE-IPv4 and AGGREGATE- The VPN-IPv4 DestAddress (respectively VPN-IPv6 DestAddress) field
IPv6 SESSION objects. contains an address of the VPN-IPv4 (respectively VPN-IPv6) address
family encoded as specified in [RFC4364] (respectively [RFC4659]).
The content of this field is discussed in Section 3.2 and
Section 3.3.
The flags and DSCP are identical to the same fields of the AGGREGATE-
IPv4 and AGGREGATE-IPv6 SESSION objects ([RFC3175],).
o GENERIC-AGGREGATE-VPN-IPv4 SESSION object: o GENERIC-AGGREGATE-VPN-IPv4 SESSION object:
Class = 1, C-Type = TBA Class = 1, C-Type = TBA
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| VPN-IPv4 DestAddress (12 bytes) | | VPN-IPv4 DestAddress (12 bytes) |
+ + + +
| | | |
skipping to change at page 24, line 42 skipping to change at page 25, line 24
/ / / /
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID | | Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Reserved | vDstPort | | Reserved | vDstPort |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Extended vDstPort | | Extended vDstPort |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
The VPN-IPv4 DestAddress (respectively VPN-IPv6 DestAddress) field
contains an address of the VPN-IPv4 (respectively VPN-IPv6) address
family encoded as specified in [RFC4364] (respectively [RFC4659]).
The content of this field is discussed in Section 3.2 and
Section 3.3.
The flags, PHB-ID, vDstPort and Extended vDstPort are identical to The flags, PHB-ID, vDstPort and Extended vDstPort are identical to
the GENERIC-AGGREGATE-IPv4 and GENERIC-AGGREGATE-IPv6 SESSION the same fields of the GENERIC-AGGREGATE-IPv4 and GENERIC-AGGREGATE-
objects. IPv6 SESSION objects ([RFC4860]).
8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 SENDER_TEMPLATE objects 8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 SENDER_TEMPLATE objects
The usage of Aggregated VPN-IPv4 SENDER_TEMPLATE object is described The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object
in Section 7.3. The AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object should is described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively
appear in all RSVP messages that ordinarily contain a AGGREGATE-IPv4 AGGREGATE-VPN-IPv6) SENDER_TEMPLATE object appears in RSVP messages
SENDER_TEMPLATE object as defined in [RFC3175] and [RFC4860], and are that ordinarily contain a AGGREGATE-IPv4 (respectively AGGREGATE-
sent between ingress PE and egress PE in either direction. These IPv6) SENDER_TEMPLATE object as defined in [RFC3175] and [RFC4860],
objects MUST NOT be included in any RSVP messages that are sent and are sent between ingress PE and egress PE in either direction.
These objects MUST NOT be included in any RSVP messages that are sent
outside of the provider's backbone (except in the inter-AS option B outside of the provider's backbone (except in the inter-AS option B
and C cases, as described above, when it may appear on inter-AS and C cases, as described above, when it may appear on inter-AS
links). The processing rules for these objects are otherwise links). The processing rules for these objects are otherwise
identical to those of the VPN-IPv4 SENDER_TEMPLATE object defined in identical to those of the VPN-IPv4 (respectively VPN-IPv6)
Section 8.2. The VPN-IPv4 address in this object is built by SENDER_TEMPLATE object defined in Section 8.2. The format of the
combining the IPv4 address from the incoming SENDER_TEMPLATE with the object is as follows:
RD in the BGP advertisement from the ingress PE for this prefix and
customer. The format of the object is as follows:
o AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object: o AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object:
Class = 11, C-Type = TBA Class = 11, C-Type = TBA
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| VPN-IPv4 AggregatorAddress (12 bytes) | | VPN-IPv4 AggregatorAddress (12 bytes) |
+ + + +
| | | |
skipping to change at page 25, line 42 skipping to change at page 26, line 30
| | | |
+ + + +
| | | |
+ VPN-IPv6 AggregatorAddress (24 bytes) + + VPN-IPv6 AggregatorAddress (24 bytes) +
/ / / /
. . . .
/ / / /
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
The flags and DSCP are identical to the AGGREGATE-IPv4 and AGGREGATE- The VPN-IPv4 AggregatorAddress (respectively VPN-IPv6
IPv6 SESSION objects. AggregatorAddress) field contains an address of the VPN-IPv4
(respectively VPN-IPv6) address family encoded as specified in
[RFC4364] (respectively [RFC4659]). The content and processing rules
for these objects are similar to those of the VPN-IPv4
SENDER_TEMPLATE object defined in Section 8.2.
The flags and DSCP are identical to the same fields of the AGGREGATE-
IPv4 and AGGREGATE-IPv6 SESSION objects.
8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC objects 8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC objects
The usage of Aggregated VPN-IPv4 FILTER_SPEC object is described in The usage of Aggregated VPN-IPv4 FILTER_SPEC object is described in
Section 7.3. The AGGREGATE-VPN-IPv4 FILTER_SPEC object should appear Section 7.3. The AGGREGATE-VPN-IPv4 FILTER_SPEC object appears in
in all RSVP messages that ordinarily contain a AGGREGATE-IPv4 RSVP messages that ordinarily contain a AGGREGATE-IPv4 FILTER_SPEC
FILTER_SPEC object as defined in [RFC3175] and [RFC4860], and are object as defined in [RFC3175] and [RFC4860], and are sent between
sent between ingress PE and egress PE in either direction. These ingress PE and egress PE in either direction. These objects MUST NOT
objects MUST NOT be included in any RSVP messages that are sent be included in any RSVP messages that are sent outside of the
outside of the provider's backbone (except in the inter-AS option B provider's backbone (except in the inter-AS option B and C cases, as
and C cases, as described above, when it may appear on inter-AS described above, when it may appear on inter-AS links). The
links). The processing rules for these objects are otherwise processing rules for these objects are otherwise identical to those
identical to those of the VPN-IPv4 FILTER_SPEC object defined in of the VPN-IPv4 FILTER_SPEC object defined in Section 8.3. The
Section 8.3. The VPN-IPv4 address in this object is built by format of the object is as follows:
combining the IPv4 address from the incoming FILTER_SPEC with the RD
in the BGP advertisement from the ingress PE for this prefix and
customer. The format of the object is as follows:
o AGGREGATE-VPN-IPv4 FILTER_SPEC object: o AGGREGATE-VPN-IPv4 FILTER_SPEC object:
Class = 10, C-Type = TBA Class = 10, C-Type = TBA
Definition same as AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object. Definition same as AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object.
o AGGREGATE-VPN-IPv6 FILTER_SPEC object: o AGGREGATE-VPN-IPv6 FILTER_SPEC object:
Class = 10, C-Type = TBA Class = 10, C-Type = TBA
Definition same as AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object. Definition same as AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object.
skipping to change at page 29, line 20 skipping to change at page 30, line 20
1 = RSVP_HOP not reachable across VPN [RFCXXXX] 1 = RSVP_HOP not reachable across VPN [RFCXXXX]
[Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC
number of this specification. Suggested values: aa=34] number of this specification. Suggested values: aa=34]
10. Security Considerations 10. Security Considerations
[RFC4364] addresses the security considerations of BGP/MPLS VPNs in [RFC4364] addresses the security considerations of BGP/MPLS VPNs in
general. General RSVP security considerations are discussed in general. General RSVP security considerations are discussed in
[RFC2205]. To ensure the integrity of RSVP, the RSVP Authentication [RFC2205]. To ensure the integrity of RSVP, the RSVP Authentication
mechanisms defined in [RFC2747] and [RFC3097] may be used. Those mechanisms defined in [RFC2747] and [RFC3097] SHOULD be supported.
protect RSVP message integrity hop-by-hop and provide node Those protect RSVP message integrity hop-by-hop and provide node
authentication as well as replay protection, thereby protecting authentication as well as replay protection, thereby protecting
against corruption and spoofing of RSVP messages. against corruption and spoofing of RSVP messages.
[I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses applicability of [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses applicability of
various keying approaches for RSVP Authentication. First, we note various keying approaches for RSVP Authentication. First, we note
that the discussion about applicability of group keying to an intra- that the discussion about applicability of group keying to an intra-
provider environment where RSVP hops are not IP hops is relevant to provider environment where RSVP hops are not IP hops is relevant to
securing of RSVP among PEs of a given Service Provider deploying the securing of RSVP among PEs of a given Service Provider deploying the
solution specified in the present document. We note that the RSVP solution specified in the present document. We note that the RSVP
signaling in MPLS VPN is likely to spread over multiple signaling in MPLS VPN is likely to spread over multiple
administrative domains (e.g. the service provider operating the VPN administrative domains (e.g. the service provider operating the VPN
skipping to change at page 30, line 12 skipping to change at page 31, line 12
A customer who makes resource reservations on the CE-PE links for his A customer who makes resource reservations on the CE-PE links for his
sites is only competing for link resources with himself, as in sites is only competing for link resources with himself, as in
standard RSVP, at least in the common case where each CE-PE link is standard RSVP, at least in the common case where each CE-PE link is
dedicated to a single customer. Thus, from the perspective of the dedicated to a single customer. Thus, from the perspective of the
CE-PE links, this draft does not introduce any new security issues. CE-PE links, this draft does not introduce any new security issues.
However, because a PE typically serves multiple customers, there is However, because a PE typically serves multiple customers, there is
also the possibility that a customer might attempt to use excessive also the possibility that a customer might attempt to use excessive
computational resources on a PE (CPU cycles, memory etc.) by sending computational resources on a PE (CPU cycles, memory etc.) by sending
large numbers of RSVP messages to a PE. In the extreme this could large numbers of RSVP messages to a PE. In the extreme this could
represent a form of denial-of-service attack. In order to prevent represent a form of denial-of-service attack. In order to prevent
such an attack, a PE should have mechanisms to limit the fraction of such an attack, a PE SHOULD support mechanisms to limit the fraction
its processing resources that can be consumed by any one CE or by the of its processing resources that can be consumed by any one CE or by
set of CEs of a given customer. For example, a PE might implement a the set of CEs of a given customer. For example, a PE might
form of rate limiting on RSVP messages that it receives from each CE. implement a form of rate limiting on RSVP messages that it receives
We observe that these security risks and measures related to PE from each CE. We observe that these security risks and measures
resource usage are very similar for any control plane protocol related to PE resource usage are very similar for any control plane
operating between CE and PE (e.g. RSVP, routing, multicast) protocol operating between CE and PE (e.g. RSVP, routing, multicast)
The second concern arises only when the service provider chooses to The second concern arises only when the service provider chooses to
offer resource reservation across the backbone, as described in offer resource reservation across the backbone, as described in
Section 4. In this case, the concern may be that a single customer Section 4. In this case, the concern may be that a single customer
might attempt to reserve a large fraction of backbone capacity, might attempt to reserve a large fraction of backbone capacity,
perhaps with a co-ordinated effort from several different CEs, thus perhaps with a co-ordinated effort from several different CEs, thus
denying service to other customers using the same backbone. denying service to other customers using the same backbone.
[RFC4804] provides some guidance on the security issues when RSVP [RFC4804] provides some guidance on the security issues when RSVP
reservations are aggregated onto MPLS tunnels, which are applicable reservations are aggregated onto MPLS tunnels, which are applicable
to the situation described here. We note that a provider may use to the situation described here. We note that a provider MAY use
local policy to limit the amount of resources that can be reserved by local policy to limit the amount of resources that can be reserved by
a given customer from a particular PE, and that a policy server could a given customer from a particular PE, and that a policy server could
be used to control the resource usage of a given customer across be used to control the resource usage of a given customer across
multiple PEs if desired. multiple PEs if desired. It is RECOMMENDED that an implementation of
this specification support local policy on the PE to control the
amount of resources that can be reserved by a given customer/CE.
Use of the VPN-IPv4 HOP object requires exporting a PE VPN-IPv4 route Use of the VPN-IPv4 HOP object requires exporting a PE VPN-IPv4 route
to another AS, and potentially could allow unchecked access to remote to another AS, and potentially could allow unchecked access to remote
PEs if those routes were indiscriminately redistributed. However, as PEs if those routes were indiscriminately redistributed. However, as
described in Section 3.1, no route which is not within a customer's described in Section 3.1, no route which is not within a customer's
VPN should ever be advertised to (or reachable from) that customer. VPN should ever be advertised to (or reachable from) that customer.
If a PE uses a local address already within a customer VRF (like If a PE uses a local address already within a customer VRF (like
PE-CE link address), it MUST NOT send this address in any RSVP PE-CE link address), it MUST NOT send this address in any RSVP
messages in a different customer VRF. A "control plane" VPN can be messages in a different customer VRF. A "control plane" VPN MAY be
created across PEs and ASBRs and addresses in this VPN can be used to created across PEs and ASBRs and addresses in this VPN can be used to
signal RSVP sessions for any customers, but these routes MUST NOT be signal RSVP sessions for any customers, but these routes MUST NOT be
advertised to, or made reachable from, any customer. Alternatively, advertised to, or made reachable from, any customer. An
ASBRs may implement the signalling procedures described in implementation of the present document MAY support such operation
Section 5.2.1, even if admission control is not required on the using a "control plane" VPN. Alternatively, ASBRs MAY implement the
inter-AS link, as these procedures do not require any direct P/PE signalling procedures described in Section 5.2.1, even if admission
route advertisement out of the AS. control is not required on the inter-AS link, as these procedures do
not require any direct P/PE route advertisement out of the AS.
Finally, certain operations described herein (Section 3) require an Finally, certain operations described herein (Section 3) require an
ASBR or PE to receive and locally process a signalling packet ASBR or PE to receive and locally process a signalling packet
addressed to the BGP next-hop address advertised by that router. addressed to the BGP next-hop address advertised by that router.
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, it would be possible to extend 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
11. Acknowledgments 11. Acknowledgments
Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter, Eric Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter, Eric
Rosen and Dan Tappan for their many contributions to solving the Rosen, Dan Tappan and Lou Berger for their many contributions to
problems described in this draft. Thanks to Ferit Yegenoglu for his solving the problems described in this draft. Thanks to Ferit
useful comments. Yegenoglu for his useful 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 33, line 19 skipping to change at page 34, line 19
[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-nsis-ntlp]
Schulzrinne, H. and M. Stiemerling, "GIST: General
Internet Signalling Transport", draft-ietf-nsis-ntlp-19
(work in progress), March 2009.
[I-D.ietf-nsis-qos-nslp]
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16
(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-01 (work in draft-ietf-tsvwg-rsvp-security-groupkeying-04 (work in
progress), July 2008. progress), March 2009.
[I-D.kumaki-l3vpn-e2e-rsvp-te-reqts] [I-D.kumaki-l3vpn-e2e-rsvp-te-reqts]
Kumaki, K., "Requirements for supporting Customer RSVP and Kumaki, K., "Requirements for supporting Customer RSVP and
RSVP-TE Over a BGP/MPLS IP-VPN", RSVP-TE Over a BGP/MPLS IP-VPN",
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-06 (work in draft-kumaki-l3vpn-e2e-rsvp-te-reqts-06 (work in
progress), February 2008. 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.
skipping to change at page 34, line 9 skipping to change at page 35, line 20
Extensions", RFC 2961, April 2001. Extensions", RFC 2961, April 2001.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097, Authentication -- Updated Message Type Value", RFC 3097,
April 2001. April 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[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.
skipping to change at page 34, line 36 skipping to change at page 36, line 4
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
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Mass. Ave. 1414 Mass. Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: ashokn@cisco.com Email: ashokn@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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
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.
 End of changes. 49 change blocks. 
195 lines changed or deleted 243 lines changed or added

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