draft-ietf-tsvwg-rsvp-l3vpn-05.txt   draft-ietf-tsvwg-rsvp-l3vpn-06.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 27, 2010 Cisco Systems, Inc. Expires: October 27, 2010 Cisco Systems, Inc.
November 23, 2009 April 25, 2010
Support for RSVP in Layer 3 VPNs Support for RSVP in Layer 3 VPNs
draft-ietf-tsvwg-rsvp-l3vpn-05.txt draft-ietf-tsvwg-rsvp-l3vpn-06.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 32 skipping to change at page 1, line 32
supported. 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].
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 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on October 27, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 27, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
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 . . . . . . . . . . . . . . . . . . . . 7 2.1. Model of Operation . . . . . . . . . . . . . . . . . . . . 7
3. Admission Control on PE-CE Links . . . . . . . . . . . . . . . 8 3. Admission Control on PE-CE Links . . . . . . . . . . . . . . . 9
3.1. New Objects of Type VPN-IPv4 . . . . . . . . . . . . . . . 8 3.1. New Objects of Type VPN-IPv4 . . . . . . . . . . . . . . . 9
3.2. Path Message Processing at Ingress PE . . . . . . . . . . 10 3.2. Path Message Processing at Ingress PE . . . . . . . . . . 11
3.3. Path Message Processing at Egress PE . . . . . . . . . . . 11 3.3. Path Message Processing at Egress PE . . . . . . . . . . . 12
3.4. Resv Processing at Egress PE . . . . . . . . . . . . . . . 12 3.4. Resv Processing at Egress PE . . . . . . . . . . . . . . . 12
3.5. Resv Processing at Ingress PE . . . . . . . . . . . . . . 12 3.5. Resv Processing at Ingress PE . . . . . . . . . . . . . . 13
3.6. Other RSVP Messages . . . . . . . . . . . . . . . . . . . 12 3.6. Other RSVP Messages . . . . . . . . . . . . . . . . . . . 13
4. Admission Control in Provider's Backbone . . . . . . . . . . . 13 4. Admission Control in Provider's Backbone . . . . . . . . . . . 14
5. Inter-AS operation . . . . . . . . . . . . . . . . . . . . . . 14 5. Inter-AS operation . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Inter-AS Option A . . . . . . . . . . . . . . . . . . . . 14 5.1. Inter-AS Option A . . . . . . . . . . . . . . . . . . . . 15
5.2. Inter-AS Option B . . . . . . . . . . . . . . . . . . . . 14 5.2. Inter-AS Option B . . . . . . . . . . . . . . . . . . . . 15
5.2.1. Admission control on ASBR . . . . . . . . . . . . . . 15 5.2.1. Admission control on ASBR . . . . . . . . . . . . . . 15
5.2.2. No admission control on ASBR . . . . . . . . . . . . . 15 5.2.2. No admission control on ASBR . . . . . . . . . . . . . 16
5.3. Inter-AS Option C . . . . . . . . . . . . . . . . . . . . 16 5.3. Inter-AS Option C . . . . . . . . . . . . . . . . . . . . 17
6. Operation with RSVP disabled . . . . . . . . . . . . . . . . . 16 6. Operation with RSVP disabled . . . . . . . . . . . . . . . . . 17
7. Other RSVP procedures . . . . . . . . . . . . . . . . . . . . 17 7. Other RSVP procedures . . . . . . . . . . . . . . . . . . . . 17
7.1. Refresh overhead reduction . . . . . . . . . . . . . . . . 17 7.1. Refresh overhead reduction . . . . . . . . . . . . . . . . 18
7.2. Cryptographic Authentication . . . . . . . . . . . . . . . 17 7.2. Cryptographic Authentication . . . . . . . . . . . . . . . 18
7.3. RSVP Aggregation . . . . . . . . . . . . . . . . . . . . . 18 7.3. RSVP Aggregation . . . . . . . . . . . . . . . . . . . . . 18
7.4. Support for CE-CE RSVP-TE . . . . . . . . . . . . . . . . 18 7.4. Support for CE-CE RSVP-TE . . . . . . . . . . . . . . . . 19
8. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 19 8. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 19
8.1. VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . . . . . . 19 8.1. VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . . . . . . 19
8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects . . . . . . 20 8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects . . . . . . 21
8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects . . . . . . . . 21 8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects . . . . . . . . 22
8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects . . . . . . . . . . 22 8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects . . . . . . . . . . 22
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
skipping to change at page 4, line 27 skipping to change at page 4, line 27
it may be desirable to be able to perform admission control over it may be desirable to be able to perform admission control over
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 is not normally MPLS encapsulated and thus the router alert option may not be
visible to the egress PE. normally visible to the egress PE, due to implementation or policy
considerations.
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 within the RSVP message.
Current mechanisms for identifying customer context from data
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.
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
skipping to change at page 5, line 41 skipping to change at page 5, line 45
different VPNs. different VPNs.
2. Problem Statement 2. Problem Statement
The problem space of this document is the support of admission The problem space of this document is the support of admission
control between customer sites when the customer subscribes to a BGP/ control between customer sites when the customer subscribes to a BGP/
MPLS VPN. We subdivide the problem into (a) the problem of admission MPLS VPN. We subdivide the problem into (a) the problem of admission
control on the PE-CE links (in both directions), and (b) the problem control on the PE-CE links (in both directions), and (b) the problem
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
session, and contain the Router Alert Option (RAO) within the IP
header. Routers along the path to the destination that are
configured to process RSVP messages need to detect the presence of
the RAO to allow them to intercept Path messages. However, the
egress PEs of a network supporting BGP/MPLS VPNs receive packets
destined for customer sites as MPLS-encapsulated packets, and
possibly forwards those based only on examination of the MPLS label.
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
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
label swap, which is a much less desirable feature. In general,
there are significant issues with requiring support for IP Router-
Alert outside of a controller, "walled-garden" network, as described
in [I-D.ietf-intarea-router-alert-considerations]. The issues with
requiring interior MPLS routers to process IP Router-Alert marked
packets are also described in [I-D.ietf-mpls-ip-options]. For these
reasons, it is highly desirable to remove the dependency on router
alert option across administrative domains (such as from a customer
network to an egress PE, or such as across ASBRs in inter- provider
MPLS VPN scenarios). 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.
The only requirement for processing IP Router-Alert packets is for
RSVP packets received from the CE, which do not carry any MPLS
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. correct VPN context in which to process an RSVP control message. The
Much of this document deals with this issue. current mechanism for identifying the customer context is the VPN
Label, which is carried in a MPLS header outside of the RSVP message.
This is divergent from the general RSVP model of session
identification ([RFC2205], [RFC2209]), which relies solely on RSVP
objects to identify sessions. Further, it is incompatible with
protocols like COPS/RSVP ([RFC2748],[RFC2748]), which replace the IP
encapsulation of the RSVP message and send only RSVP objects to a
COPS server. We believe it is important to retain the model of
completely identifying an RSVP session from the contents of RSVP
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
then map individual, customer-specific reservations onto an aggregate then map individual, customer-specific reservations onto an aggregate
reservation. That is similar to the problem tackled in [RFC3175] and reservation. That is similar to the problem tackled in [RFC3175] and
[RFC4804], with the additional complications of handling customer- [RFC4804], with the additional complications of handling customer-
specific addressing associated with BGP/MPLS VPNs. specific addressing associated with BGP/MPLS VPNs.
Finally, we note that RSVP Path messages are normally addressed to
the destination of a session, and contain the router alert option.
Routers along the path to the destination that are configured to
process RSVP messages need to detect the presence of the router alert
option to allow them to intercept Path messages. However, the egress
PEs of a network supporting BGP/MPLS VPNs receive packets destined
for customer sites as MPLS-encapsulated packets, and possibly
forwards those based only on examination of the MPLS label. Hence, a
Path message would be forwarded without examination of the IP options
and would therefore not receive appropriate processing at the PE.
This problem of recognizing and processing Path messages is also
discussed below.
Consider the case where an MPLS VPN customer uses RSVP signaling Consider the case where an MPLS VPN customer uses RSVP signaling
across his sites for resource reservation and admission control. across his sites for resource reservation and admission control.
Let's further assume that, initially, RSVP is not processed through Let's further assume that, initially, RSVP is not processed through
the MPLS VPN cloud (i.e RSVP messages from the sender to the receiver the MPLS VPN cloud (i.e RSVP messages from the sender to the receiver
travel transparently from CE to CE). In that case, RSVP allows travel transparently from CE to CE). In that case, RSVP allows
establishment of resource reservations and admission control on a establishment of resource reservations and admission control on a
subset of the flow path (from sender to ingress CE; and from the RSVP subset of the flow path (from sender to ingress CE; and from the RSVP
router downstream of the egress CE to the receiver). If admission router downstream of the egress CE to the receiver). If admission
control is then activated on any of the CE-PE link, provider's control is then activated on any of the CE-PE link, provider's
backbone or PE-CE link (as allowed by the present document), the backbone or PE-CE link (as allowed by the present document), the
skipping to change at page 9, line 14 skipping to change at page 9, line 47
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 Autonomous System Border Routers -ASBRs) are separated by Option-B Autonomous System Border Routers -ASBRs) are
not required to have direct IP reachability to each other. To solve not required to have direct IP reachability to each other. To solve
this issue, we propose the use of label switching to forward RSVP this issue, we propose the use of label switching to forward RSVP
messages between nodes within a MPLS VPN. This is achieved by messages between nodes within a MPLS VPN. This is achieved by
defining a new VPN-IPv4 RSVP_HOP object. Use of the VPN-IPv4 defining a new VPN-IPv4 RSVP_HOP object. Use of the VPN-IPv4
RSVP_HOP object enables RSVP control plane reachability between any RSVP_HOP object enables any two adjacent RSVP hops in a MPLS VPN
two adjacent RSVP hops in a MPLS VPN (e.g. a PE in AS 1 and a PE in (e.g. a PE in AS 1 and a PE in AS2) to correctly identify each other
AS2), regardless of whether they have IP reachability to each other. and send RSVP messages directly 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 (LIH) as before, but in sender and a Logical Interface Handle (LIH) as before, but in
addition carries a VPN-IPv4 address which also represents the sender addition carries a VPN-IPv4 address which also represents the sender
of the message. The message sender MUST also advertise this VPN-IPv4 of the message. The message sender MUST also advertise this VPN-IPv4
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 11, line 25 skipping to change at page 12, line 10
VPN. A new Path message is constructed with a destination address VPN. A new Path message is constructed with a destination address
equal to the address of the egress PE identified above. This new equal to the address of the egress PE identified above. This new
Path message will contain all the objects from the original Path Path message will contain all the objects from the original Path
message, replacing the original SESSION and SENDER_TEMPLATE objects message, replacing the original SESSION and SENDER_TEMPLATE objects
with the new VPN-IPv4 type objects. The Path message is sent without with the new VPN-IPv4 type objects. The Path message is sent without
router alert option and contains a RSVP_HOP object constructed as router alert option and contains a RSVP_HOP object constructed as
specified in Section 3.1. specified in Section 3.1.
3.3. Path Message Processing at Egress PE 3.3. Path Message Processing at Egress PE
When a Path message arrives at the egress PE, it is addressed to the When a Path message arrives at the egress PE, (step 4 of Section 2.1)
PE itself, and is handed to RSVP for processing. The router extracts it is addressed to the PE itself, and is handed to RSVP for
the RD and IPv4 address from the VPN-IPv4 SESSION object, and processing. The router extracts the RD and IPv4 address from the
determines the local VRF context by finding a matching VPN-IPv4 VPN-IPv4 SESSION object, and determines the local VRF context by
prefix with the specified RD that has been advertised by this router finding a matching VPN-IPv4 prefix with the specified RD that has
into BGP. The entire incoming RSVP message, including the VRF been advertised by this router into BGP. The entire incoming RSVP
information, is stored as part of the Path state. message, including the VRF information, is stored as part of the Path
state.
Now the RSVP module can construct a Path message which differs from Now the RSVP module can construct a Path message which differs from
the Path it received in the following ways: the Path it received in the following ways:
a. Its destination address is the IP address extracted from the a. Its destination address is the IP address extracted from the
SESSION Object; SESSION Object;
b. The SESSION and SENDER_TEMPLATE objects are converted back to b. The SESSION and SENDER_TEMPLATE objects are converted back to
IPv4-type by discarding the attached RD IPv4-type by discarding the attached RD
skipping to change at page 12, line 9 skipping to change at page 12, line 40
as per normal RSVP processing. as per normal RSVP processing.
The router then sends the Path message on towards its destination The router then sends the Path message on towards its destination
over the interface identified above. This Path message carries the over the interface identified above. This Path message carries the
router alert option as required by [RFC2205]. router alert option as required by [RFC2205].
3.4. Resv Processing at Egress PE 3.4. Resv Processing at Egress PE
When a receiver at the customer site originates a Resv message for When a receiver at the customer site originates a Resv message for
the session, normal RSVP procedures apply until the Resv, making its the session, normal RSVP procedures apply until the Resv, making its
way back towards the sender, arrives at the "egress" PE (it is way back towards the sender, arrives at the "egress" PE (step 8 of
"egress" with respect to the direction of data flow, i.e. PE2 in Section 2.1). Note that this is the "egress" PE with respect to the
figure 1). On arriving at PE2, the SESSION and FILTER_SPEC objects direction of data flow, i.e. PE2 in figure 1. On arriving at PE2,
in the Resv, and the VRF in which the Resv was received, are used to the SESSION and FILTER_SPEC objects in the Resv, and the VRF in which
find the matching Path state stored previously. At this stage, the Resv was received, are used to find the matching Path state
admission control can be performed on the PE-CE link. stored previously. At this stage, admission control can be performed
on the PE-CE link.
Assuming admission control is successful, the PE constructs a Resv Assuming admission control is successful, the PE constructs a Resv
message to send to the RSVP HOP stored in the Path state, i.e., the message to send to the RSVP HOP stored in the Path state, i.e., the
ingress PE (PE1 in Figure 1). The IPv4 SESSION object is replaced ingress PE (PE1 in Figure 1). The IPv4 SESSION object is replaced
with the same VPN-IPv4 SESSION object received in the Path. The IPv4 with the same VPN-IPv4 SESSION object received in the Path. The IPv4
FILTER_SPEC object is replaced with a VPN-IPv4 FILTER_SPEC object, FILTER_SPEC object is replaced with a VPN-IPv4 FILTER_SPEC object,
which copies the VPN-IPv4 address from the SENDER_TEMPLATE received which copies the VPN-IPv4 address from the SENDER_TEMPLATE received
in the matching Path message. The RSVP_HOP in the Resv message MUST in the matching Path message. The RSVP_HOP in the Resv message MUST
be constructed as specified in Section 3.1. The Resv message MUST be be constructed as specified in Section 3.1. The Resv message MUST be
addressed to the IP address contained within the RSVP_HOP object in addressed to the IP address contained within the RSVP_HOP object in
skipping to change at page 12, line 37 skipping to change at page 13, line 21
with that VPN-IPv4 address in BGP, as described in Section 3.1. If with that VPN-IPv4 address in BGP, as described in Section 3.1. If
the Path message contained an IPv4 RSVP_HOP object, the Resv is the Path message contained an IPv4 RSVP_HOP object, the Resv is
simply IP-encapsulated and addressed directly to the IP address in simply IP-encapsulated and addressed directly to the IP address in
the RSVP_HOP object. the RSVP_HOP object.
If admission control is not successful on the egress PE, a ResvError If admission control is not successful on the egress PE, a ResvError
message is sent towards the receiver as per normal RSVP processing. message is sent towards the receiver as per normal RSVP processing.
3.5. Resv Processing at Ingress PE 3.5. Resv Processing at Ingress PE
Upon receiving a Resv message at the ingress PE (with respect to data Upon receiving a Resv message at the ingress PE (step 8 of
flow, i.e. PE1 in Figure 1), the PE determines the local VRF context Section 2.1) with respect to data flow (i.e. PE1 in Figure 1), the
and associated Path state for this Resv by decoding the received PE determines the local VRF context and associated Path state for
SESSION and FILTER_SPEC objects. It is now possible to generate a this Resv by decoding the received SESSION and FILTER_SPEC objects.
Resv message to send to the appropriate CE. The Resv message sent to It is now possible to generate a Resv message to send to the
the ingress CE will contain IPv4 SESSION and FILTER_SPEC objects, appropriate CE. The Resv message sent to the ingress CE will contain
derived from the appropriate Path state. Since we assume in this IPv4 SESSION and FILTER_SPEC objects, derived from the appropriate
section that admission control over the Provider's backbone is not Path state. Since we assume in this section that admission control
needed, the ingress PE does not perform any admission control for over the Provider's backbone is not needed, the ingress PE does not
this reservation. perform any admission control for this reservation.
3.6. Other RSVP Messages 3.6. Other RSVP Messages
Processing of PathError, PathTear, ResvError, ResvTear and ResvConf Processing of PathError, PathTear, ResvError, ResvTear and ResvConf
messages is generally straightforward and follows the rules of messages is generally straightforward and follows the rules of
[RFC2205]. These additional rules MUST be observed for messages [RFC2205]. These additional rules MUST be observed for messages
transmitted within the VPN (i.e. Between the PEs): transmitted within the VPN (i.e. Between the PEs):
o The SESSION, SENDER_TEMPLATE and FILTER_SPEC objects MUST be o The SESSION, SENDER_TEMPLATE and FILTER_SPEC objects MUST be
converted from IPv4 to VPN-IPv4 form and back in the same manner converted from IPv4 to VPN-IPv4 form and back in the same manner
skipping to change at page 36, line 11 skipping to change at page 36, line 11
[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-intarea-router-alert-considerations]
Faucheur, F., "IP Router Alert Considerations and Usage",
draft-ietf-intarea-router-alert-considerations-00 (work in
progress), March 2010.
[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-04 (work in VPN", draft-ietf-l3vpn-e2e-rsvp-te-reqts-05 (work in
progress), August 2009. progress), December 2009.
[I-D.ietf-mpls-ip-options]
Jaeger, W., Mullooly, J., Scholl, T., and D. Smith,
"Requirements for Label Edge Router Forwarding of IPv4
Option Packets", draft-ietf-mpls-ip-options-03 (work in
progress), January 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-17 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18
(work in progress), October 2009. (work in progress), January 2010.
[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-05 (work in draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in
progress), June 2009. progress), June 2009.
[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 36, line 47 skipping to change at page 37, line 9
[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
Services", RFC 2210, September 1997. Services", RFC 2210, September 1997.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000.
[RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R.,
and A. Sastry, "The COPS (Common Open Policy Service)
Protocol", RFC 2748, January 2000.
[RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R.,
and A. Sastry, "COPS usage for RSVP", RFC 2749,
January 2000.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction and S. Molendini, "RSVP Refresh Overhead Reduction
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
 End of changes. 26 change blocks. 
82 lines changed or deleted 126 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/