draft-ietf-tsvwg-rsvp-dste-05.txt   rfc4804.txt 
RSVP Aggregation over MPLS TE tunnels September 2006 Network Working Group F. Le Faucheur, Ed.
Request for Comments: 4804 Cisco Systems, Inc.
Internet Draft Francois Le Faucheur Category: Standards Track February 2007
Editor
Cisco Systems, Inc.
draft-ietf-tsvwg-rsvp-dste-05.txt
Expires: March 2007 September 2006
Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels
Status of this Memo
By submitting this Internet-Draft, each author represents that any Aggregation of Resource ReSerVation Protocol (RSVP)
applicable patent or other IPR claims of which he or she is aware Reservations over MPLS TE/DS-TE Tunnels
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 Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The IETF Trust (2007).
http://www.ietf.org/shadow.html.
Abstract Abstract
RFC 3175 specifies aggregation of RSVP end-to-end reservations over RFC 3175 specifies aggregation of Resource ReSerVation Protocol
aggregate RSVP reservations. This document specifies aggregation of (RSVP) end-to-end reservations over aggregate RSVP reservations.
RSVP end-to-end reservations over MPLS Traffic Engineering (TE) This document specifies aggregation of RSVP end-to-end reservations
tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE) over MPLS Traffic Engineering (TE) tunnels or MPLS Diffserv-aware
Tunnels. This approach is based on RFC 3175 and simply modifies the MPLS Traffic Engineering (DS-TE) tunnels. This approach is based on
corresponding procedures for operations over MPLS TE tunnels instead RFC 3175 and simply modifies the corresponding procedures for
of aggregate RSVP reservations. This approach can be used to achieve operations over MPLS TE tunnels instead of aggregate RSVP
admission control of a very large number of flows in a scalable reservations. This approach can be used to achieve admission control
manner since the devices in the core of the network are unaware of of a very large number of flows in a scalable manner since the
the end-to-end RSVP reservations and are only aware of the MPLS TE devices in the core of the network are unaware of the end-to-end RSVP
tunnels. reservations and are only aware of the MPLS TE tunnels.
RSVP Aggregation over MPLS TE tunnels September 2006
Copyright Notice
Copyright (C) The Internet Society (2006).
Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS].
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction ....................................................3
2. Contributing Authors...........................................6 2. Specification of Requirements ...................................7
3. Definitions....................................................7 3. Definitions .....................................................7
4. Operations of RSVP Aggregation over TE with pre-established 4. Operations of RSVP Aggregation over TE with
Tunnels...........................................................8 Pre-established Tunnels .........................................8
4.1. Reference Model...........................................9 4.1. Reference Model ............................................9
4.2. Receipt of E2E Path message By the Aggregator............10 4.2. Receipt of E2E Path Message by the Aggregator ..............9
4.3. Handling of E2E Path message By Transit LSRs.............11 4.3. Handling of E2E Path Message by Transit LSRs ..............11
4.4. Receipt of E2E Path Message by Deaggregator..............12 4.4. Receipt of E2E Path Message by the Deaggregator ...........11
4.5. Handling of E2E Resv Message by Deaggregator.............12 4.5. Handling of E2E Resv Message by the Deaggregator ..........12
4.6. Handling of E2E Resv Message by the Aggregator...........13 4.6. Handling of E2E Resv Message by the Aggregator ............12
4.7. Forwarding of E2E traffic by Aggregator..................14 4.7. Forwarding of E2E Traffic by the Aggregator ...............14
4.8. Removal of E2E reservations..............................14 4.8. Removal of E2E Reservations ...............................14
4.9. Removal of TE Tunnel.....................................15 4.9. Removal of the TE Tunnel ..................................14
4.10. Example Signaling Flow..................................16 4.10. Example Signaling Flow ...................................15
5. IPv4 and IPv6 Applicability...................................17 5. IPv4 and IPv6 Applicability ....................................16
6. E2E Reservations Applicability................................17 6. E2E Reservations Applicability .................................16
7. Example Deployment Scenarios..................................17 7. Example Deployment Scenarios ...................................16
7.1. Voice and Video Reservations Scenario....................17 7.1. Voice and Video Reservations Scenario .....................16
7.2. PSTN/3G Voice Trunking Scenario..........................18 7.2. PSTN/3G Voice Trunking Scenario ...........................17
8. Security Considerations.......................................19 8. Security Considerations ........................................18
9. IANA Considerations...........................................20 9. Acknowledgments ................................................20
10. Acknowledgments..............................................21 10. Normative References ..........................................20
11. Normative References.........................................21 11. Informative References ........................................21
12. Informative References.......................................22 Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator ........23
13. Editor's Address:............................................23 Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels
Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator.......24 for VoIP Call Admission Control (CAC) ................25
Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels for
VoIP Call Admission Control (CAC)................................26
1. Introduction 1. Introduction
RSVP Aggregation over MPLS TE tunnels September 2006
The Integrated Services (Intserv) [INT-SERV] architecture provides a The Integrated Services (Intserv) [INT-SERV] architecture provides a
means for the delivery of end-to-end Quality of Service (QoS) to means for the delivery of end-to-end Quality of Service (QoS) to
applications over heterogeneous networks. applications over heterogeneous networks.
[RSVP] defines the Resource reSerVation Protocol which can be used by [RSVP] defines the Resource reSerVation Protocol that can be used by
applications to request resources from the network. The network applications to request resources from the network. The network
responds by explicitely admitting or rejecting these RSVP requests. responds by explicitly admitting or rejecting these RSVP requests.
Certain applications that have quantifiable resource requirements Certain applications that have quantifiable resource requirements
express these requirements using Intserv parameters as defined in the express these requirements using Intserv parameters as defined in the
appropriate Intserv service specifications ([GUARANTEED], appropriate Intserv service specifications ([GUARANTEED],
[CONTROLLED]). [CONTROLLED]).
The Differentiated Services (DiffServ) architecture ([DIFFSERV]) was The Differentiated Services (DiffServ) architecture ([DIFFSERV]) was
then developed to support differentiated treatment of packets in very then developed to support the differentiated treatment of packets in
large scale environments. In contrast to the per-flow orientation of very large scale environments. In contrast to the per-flow
Intserv and RSVP, Diffserv networks classify packets into one of a orientation of Intserv and RSVP, Diffserv networks classify packets
small number of aggregated flows or "classes", based on the Diffserv into one of a small number of aggregated flows or "classes", based on
codepoint (DSCP) in the packet IP header. At each Diffserv router, the Diffserv codepoint (DSCP) in the packet IP header. At each
packets are subjected to a "per-hop behavior" (PHB), which is invoked Diffserv router, packets are subjected to a "per-hop behavior" (PHB),
by the DSCP. The primary benefit of Diffserv is its scalability. which is invoked by the DSCP. The primary benefit of Diffserv is its
Diffserv eliminates the need for per-flow state and per-flow scalability. Diffserv eliminates the need for per-flow state and
processing and therefore scales well to large networks. per-flow processing, and therefore scales well to large networks.
However, DiffServ does not include any mechanism for communication However, DiffServ does not include any mechanism for communication
between applications and the network. Thus, as detailed in [INT-DIFF], between applications and the network. Thus, as detailed in
significant benefits can be achieved by using Intserv over Diffserv [INT-DIFF], significant benefits can be achieved by using Intserv
including resource based admission control, policy based admission over Diffserv including resource-based admission control, policy-
control, assistance in traffic identification /classification and based admission control, assistance in traffic
traffic conditioning. As discussed in [INT-DIFF], Intserv can operate identification/classification, and traffic conditioning. As
over Diffserv in multiple ways. For example, the Diffserv region may discussed in [INT-DIFF], Intserv can operate over Diffserv in
be statically provisioned or may be RSVP aware. When it is RSVP aware, multiple ways. For example, the Diffserv region may be statically
several mechanisms may be used to support dynamic provisioning and provisioned or RSVP aware. When it is RSVP aware, several mechanisms
topology aware admission control including aggregate RSVP may be used to support dynamic provisioning and topology-aware
reservations, per flow RSVP or a bandwidth broker. The advantage of admission control, including aggregate RSVP reservations, per-flow
using aggregate RSVP reservations is that it offers dynamic, RSVP, or a bandwidth broker. The advantage of using aggregate RSVP
topology-aware admission control over the Diffserv region without reservations is that it offers dynamic, topology-aware admission
per-flow reservations and the associated level of RSVP signaling in control over the Diffserv region without per-flow reservations and
the Diffserv core. In turn, this allows dynamic, topology aware the associated level of RSVP signaling in the Diffserv core. In
admission control of flows requiring QoS reservations over the turn, this allows dynamic, topology-aware admission control of flows
Diffserv core even when the total number of such flows carried over requiring QoS reservations over the Diffserv core even when the total
the Diffserv core is extremely large. number of such flows carried over the Diffserv core is extremely
large.
[RSVP-AGG] describes in detail how to perform such aggregation of end [RSVP-AGG] and [RSVP-GEN-AGG] describe in detail how to perform such
to end RSVP reservations over aggregate RSVP reservations in a aggregation of end-to-end RSVP reservations over aggregate RSVP
Diffserv cloud. It establishes an architecture where multiple end-to- reservations in a Diffserv cloud. They establish an architecture
end RSVP reservations sharing the same ingress router (Aggregator) where multiple end-to-end RSVP reservations sharing the same ingress
and the same egress router (Deaggregator) at the edges of an router (Aggregator) and egress router (Deaggregator) at the edges of
"aggregation region", can be mapped onto a single aggregate an "aggregation region" can be mapped onto a single aggregate
reservation within the aggregation region. This considerably reduces reservation within the aggregation region. This considerably reduces
RSVP Aggregation over MPLS TE tunnels September 2006
the amount of reservation state that needs to be maintained by the amount of reservation state that needs to be maintained by
routers within the aggregation region. Furthermore, traffic belonging routers within the aggregation region. Furthermore, traffic
to aggregate reservations is classified in the data path purely using belonging to aggregate reservations is classified in the data path
Diffserv marking. purely using Diffserv marking.
[MPLS-TE] describes how MPLS Traffic Engineering (TE) Tunnels can be [MPLS-TE] describes how MPLS Traffic Engineering (TE) tunnels can be
used to carry arbitrary aggregates of traffic for the purposes of used to carry arbitrary aggregates of traffic for the purposes of
traffic engineering. [RSVP-TE] specifies how such MPLS TE Tunnels can traffic engineering. [RSVP-TE] specifies how such MPLS TE tunnels
be established using RSVP-TE signaling. MPLS TE uses Constraint Based can be established using RSVP-TE signaling. MPLS TE uses
Routing to compute the path for a TE tunnel. Then, Admission Control Constraint-Based Routing to compute the path for a TE tunnel. Then,
is performed during the establishment of TE Tunnels to ensure they Admission Control is performed during the establishment of TE tunnels
are granted their requested resources. to ensure they are granted their requested resources.
[DSTE-REQ] presents the Service Providers requirements for support of [DSTE-REQ] presents the Service Providers requirements for support of
Diff-Serv-aware MPLS Traffic Engineering (DS-TE). With DS-TE, Diffserv-aware MPLS Traffic Engineering (DS-TE). With DS-TE,
separate DS-TE tunnels can be used to carry different Diffserv separate DS-TE tunnels can be used to carry different Diffserv
classes of traffic and different resource constraints can be enforced classes of traffic, and different resource constraints can be
for these different classes. [DSTE-PROTO] specifies RSVP-TE signaling enforced for these different classes. [DSTE-PROTO] specifies RSVP-TE
extensions as well as OSPF and ISIS extensions for support of DS-TE. signaling extensions as well as OSPF and Intermediate System to
Intermediate System (IS-IS) extensions for support of DS-TE.
In the rest of this document we will refer to both TE tunnels and DS- In the rest of this document we will refer to both TE tunnels and
TE tunnels simply as "TE tunnels". DS-TE tunnels simply as "TE tunnels".
TE tunnels have much in common with the aggregate RSVP reservations TE tunnels have much in common with the aggregate RSVP reservations
used in [RSVP-AGG]: used in [RSVP-AGG] and [RSVP-GEN-AGG]:
- a TE tunnel is subject to Admission Control and thus is
effectively an aggregate bandwidth reservation - A TE tunnel is subject to Admission Control and thus is
effectively an aggregate bandwidth reservation.
- In the data plane, packet scheduling relies exclusively on - In the data plane, packet scheduling relies exclusively on
Diff-Serv classification and PHBs Diffserv classification and PHBs.
- Both TE tunnels and aggregate RSVP reservations are controlled - Both TE tunnels and aggregate RSVP reservations are controlled
by "intelligent" devices on the edge of the "aggregation core" by "intelligent" devices on the edge of the "aggregation core"
(Head-end and Tail-end in the case of TE tunnels, Aggregator (Head-end and Tail-end in the case of TE tunnels; Aggregator and
and Deaggregator in the case of aggregate RSVP reservations Deaggregator in the case of aggregate RSVP reservations.
- Both TE tunnels and aggregate RSVP reservations are signaled - Both TE tunnels and aggregate RSVP reservations are signaled
using the RSVP protocol (with some extensions defined in [RSVP- using the RSVP protocol (with some extensions defined in
TE] and [DSTE-PROTO] respectively for TE tunnels and DS-TE [RSVP-TE] and [DSTE-PROTO] respectively for TE tunnels and DS-TE
tunnels). tunnels).
This document provides a detailed specification for performing This document provides a detailed specification for performing
aggregation of end-to-end RSVP reservations over MPLS TE tunnels aggregation of end-to-end RSVP reservations over MPLS TE tunnels
(which act as aggregate reservations in the core). This document (which act as aggregate reservations in the core). This document
builds on the RSVP Aggregation procedures defined in [RSVP-AGG], and builds on the RSVP Aggregation procedures defined in [RSVP-AGG] and
only changes those where necessary to operate over TE tunnels. With [RSVP-GEN-AGG], and only changes those where necessary to operate
[RSVP-AGG], a lot of responsibilities (such as mapping end-to-end over TE tunnels. With [RSVP-AGG] and [RSVP-GEN-AGG], a lot of
reservations to Aggregate reservations and resizing the Aggregate responsibilities (such as mapping end-to-end reservations to
reservations) are assigned to the Deaggregator (which is the Aggregate reservations and resizing the Aggregate reservations) are
equivalent of the Tunnel Tail-end) while with TE, the tunnels are assigned to the Deaggregator (which is the equivalent of the tunnel
controlled by the Tunnel Head-end. Hence, the main change over the Tail-end) while with TE, the tunnels are controlled by the tunnel
RSVP Aggregations procedures defined in [RSVP-AGG] is to modify these Head-end. Hence, the main change over the RSVP Aggregations
procedures defined in [RSVP-AGG] and [RSVP-GEN-AGG] is to modify
RSVP Aggregation over MPLS TE tunnels September 2006 these procedures to reassign responsibilities from the Deaggregator
to the Aggregator (i.e., the tunnel Head-end).
procedures to reassign responsibilities from the Deaggregator to the
Aggregator (i.e. the tunnel Head-end).
[LSP-HIER] defines how to aggregate MPLS TE Label Switched Paths [LSP-HIER] defines how to aggregate MPLS TE Label Switched Paths
(LSPs) by creating a hierarchy of such LSPs. This involves nesting of (LSPs) by creating a hierarchy of such LSPs. This involves nesting
end-to-end LSPs into an aggregate LSP in the core (by using the label of end-to-end LSPs into an aggregate LSP in the core (by using the
stack construct). Since end-to-end TE LSPs are themselves signaled label stack construct). Since end-to-end TE LSPs are themselves
with RSVP-TE and reserve resources at every hop, this can be looked signaled with RSVP-TE and reserve resources at every hop, this can be
at as a form of aggregation of RSVP(-TE) reservations over MPLS TE looked at as a form of aggregation of RSVP(-TE) reservations over
Tunnels. This document capitalizes on the similarities between MPLS TE tunnels. This document capitalizes on the similarities
nesting of TE LSPs over TE tunnels and RSVP aggregation over TE between nesting of TE LSPs over TE tunnels and RSVP aggregation over
tunnels and reuses the procedures of [LSP-HIER] wherever possible. TE tunnels, and reuses the procedures of [LSP-HIER] wherever
possible.
This document also builds on the "RSVP over Tunnels" concepts of RFC This document also builds on the "RSVP over Tunnels" concepts of RFC
2746 [RSVP-TUN]. It differs from that specification in the following 2746 [RSVP-TUN]. It differs from that specification in the following
ways ways:
- Whereas RFC 2746 describes operation with IP tunnels, this
document describes operation over MPLS tunnels. One consequence - This document describes operation over MPLS tunnels, whereas RFC
of this difference is the need to deal with penultimate hop 2746 describes operation with IP tunnels. One consequence of
popping (PHP). this difference is the need to deal with penultimate hop popping
(PHP).
- MPLS-TE tunnels inherently reserve resources, whereas the - MPLS-TE tunnels inherently reserve resources, whereas the
tunnels in RFC 2746 do not have resource reservations by tunnels in RFC 2746 do not have resource reservations by
default. This leads to some simplifications in the current default. This leads to some simplifications in the current
document. document.
- This document builds on the fact that there is exactly one - This document builds on the fact that there is exactly one
aggregate reservation per MPLS-TE tunnel, whereas RFC 2746 aggregate reservation per MPLS-TE tunnel, whereas RFC 2746
permits a model where one reservation is established on the permits a model where one reservation is established on the
tunnel path for each end-to-end flow. tunnel path for each end-to-end flow.
- We have assumed in the current document that a given MPLS-TE - We have assumed in the current document that a given MPLS-TE
tunnel will carry reserved traffic and nothing but reserved tunnel will carry reserved traffic and nothing but reserved
traffic, which negates the requirement of RFC 2746 to traffic, which negates the requirement of RFC 2746 to
distinguish reserved and non-reserved traffic traversing the distinguish reserved and non-reserved traffic traversing the
same tunnel by using distinct encapsulations. same tunnel by using distinct encapsulations.
- There may be several MPLS-TE tunnels that share common head and
tail end routers, with head-end policy determining which tunnel - There may be several MPLS-TE tunnels that share common Head-end
is appropriate for a particular flow. This scenario does not and Tail-end routers, with the Head-end policy determining which
appear to be addressed in RFC 2746. tunnel is appropriate for a particular flow. This scenario does
not appear to be addressed in RFC 2746.
At the same time, this document does have many similarities with RFC At the same time, this document does have many similarities with RFC
2746. MPLS-TE tunnels are "type 2 tunnels" in the nomenclature of RFC 2746. MPLS-TE tunnels are "type 2 tunnels" in the nomenclature of
2746: RFC 2746:
"
The (logical) link may be able to promise that some overall
level of resources is available to carry traffic, but not to
allocate resources specifically to individual data flows.
"
RSVP Aggregation over MPLS TE tunnels September 2006 "The (logical) link may be able to promise that some overall level
of resources is available to carry traffic, but not to allocate
resources specifically to individual data flows".
Aggregation of end-to-end RSVP reservations over TE tunnels combines Aggregation of end-to-end RSVP reservations over TE tunnels combines
the benefits of [RSVP-AGG] with the benefits of MPLS including the the benefits of [RSVP-AGG] and [RSVP-GEN-AGG] with the benefits of
following: MPLS, including the following:
- applications can benefit from dynamic, topology-aware resource-
based admission control over any segment of the end to end path
including the core
- as per regular RSVP behavior, RSVP does not impose any burden
on routers where such admission control is not needed (for
example if the links upstream and downstream of the MPLS TE
core are vastly over-engineered compared to the core capacity,
admission control is not required on these over-engineered
links and RSVP need not be processed on the corresponding
router hops)
- the core scalability is not affected (relative to the
traditional MPLS TE deployment model) since the core remains
unaware of end-to-end RSVP reservations and only has to
maintain aggregate TE tunnels and since the datapath
classification and scheduling in the core relies purely on
Diffserv mechanism (or more precisely MPLS Diffserv mechanisms
as specified in [DIFF-MPLS])
- the aggregate reservation (and thus the traffic from the
corresponding end to end reservations) can be network
engineered via the use of Constraint based routing (e.g.
affinity, optimization on different metrics) and when needed
can take advantage of resources on other paths than the
shortest path
- the aggregate reservations (and thus the traffic from the
corresponding end to end reservations) can be protected against
failure through the use of MPLS Fast Reroute
This document, like [RSVP-AGG], covers aggregation of unicast
sessions. Aggregation of multicast sessions is for further study.
2. Contributing Authors
This document was the collective work of several authors. The text - Applications can benefit from dynamic, topology-aware,
and content were contributed by the editor and the co-authors listed resource-based admission control over any segment of the end-
below. (The contact information for the editor appears in the to-end path, including the core.
Editor's Address section.)
Michael DiBiasio - As per regular RSVP behavior, RSVP does not impose any burden on
Cisco Systems, Inc. routers where such admission control is not needed (for example,
300 Beaver Brook Road if the links upstream and downstream of the MPLS TE core are
Boxborough, MA 01719 vastly over-engineered compared to the core capacity, admission
USA control is not required on these over-engineered links and RSVP
Email: dibiasio@cisco.com need not be processed on the corresponding router hops).
RSVP Aggregation over MPLS TE tunnels September 2006 - The core scalability is not affected (relative to the
traditional MPLS TE deployment model) since the core remains
unaware of end-to-end RSVP reservations and only has to maintain
aggregate TE tunnels since the datapath classification and
scheduling in the core relies purely on the Diffserv mechanism
(or more precisely the MPLS Diffserv mechanisms, as specified in
[DIFF-MPLS]).
Bruce Davie - The aggregate reservation (and thus the traffic from the
Cisco Systems, Inc. corresponding end to end reservations) can be network engineered
300 Beaver Brook Road via the use of Constraint based routing (e.g., affinity,
Boxborough, MA 01719 optimization on different metrics) and when needed can take
USA advantage of resources on other paths than the shortest path.
Email: bdavie@cisco.com
Christou Christou - The aggregate reservations (and thus the traffic from the
Booz Allen Hamilton corresponding end-to-end reservations) can be protected against
8283 Greensboro Drive failure through the use of MPLS Fast Reroute.
McLean, VA 22102
USA
Email: christou_chris@bah.com
Michael Davenport This document, like [RSVP-AGG] and [RSVP-GEN-AGG], covers aggregation
Booz Allen Hamilton of unicast sessions. Aggregation of multicast sessions is for
8283 Greensboro Drive further study.
McLean, VA 22102
USA
Email: davenport_michael@bah.com
Jerry Ash 2. Specification of Requirements
AT&T
200 Laurel Avenue
Middletown, NJ 07748, USA
USA
Email: gash@att.com
Bur Goode The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
AT&T "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
32 Old Orchard Drive document are to be interpreted as described in [KEYWORDS].
Weston, CT 06883
USA
Email: bgoode@att.com
3. Definitions 3. Definitions
For readability, a number of definitions from [RSVP-AGG] as well as For readability, a number of definitions from [RSVP-AGG] as well as
definitions for commonly used MPLS TE terms are provided here: definitions for commonly used MPLS TE terms are provided here:
Aggregator This is the process in (or associated with) the router Aggregator This is the process in (or associated with) the
at the ingress edge of the aggregation region (with router at the ingress edge of the aggregation region
(with respect to the end-to-end RSVP reservation)
RSVP Aggregation over MPLS TE tunnels September 2006 and behaving in accordance with [RSVP-AGG]. In this
document, it is also the TE tunnel Head-end.
respect to the end to end RSVP reservation) and
behaving in accordance with [RSVP-AGG]. In this
document, it is also the TE Tunnel Head-end.
Deaggregator This is the process in (or associated with) the router Deaggregator This is the process in (or associated with) the
at the egress edge of the aggregation region (with router at the egress edge of the aggregation region
respect to the end to end RSVP reservation) and (with respect to the end-to-end RSVP reservation)
behaving in accordance with [RSVP-AGG]. In this and behaving in accordance with [RSVP-AGG]. In this
document, it is also the TE Tunnel Tail-end document, it is also the TE tunnel Tail-end
E2E End to end E2E End to end
E2E reservation This is an RSVP reservation such that: E2E Reservation This is an RSVP reservation such that:
(i) corresponding Path messages are initiated (i) corresponding Path messages are initiated
upstream of the Aggregator and terminated upstream of the Aggregator and terminated
downstream of the Deaggregator, and downstream of the Deaggregator, and
(ii) corresponding Resv messages are initiated (ii) corresponding Resv messages are initiated
downstream of the Deaggregator and downstream of the Deaggregator and terminated
terminated upstream of the Aggregator, and upstream of the Aggregator, and
(iii) this RSVP reservation is to be aggregated
over an MPLS TE tunnel between the
Aggregator and Deaggregator.
An E2E RSVP reservation may be a per-flow
reservation. Alternatively, the E2E reservation
may itself be an aggregate reservation of various
types (e.g. Aggregate IP reservation, Aggregate
IPsec reservation). See section 5 and 6 for more
details on the types of E2E RSVP reservations. As
per regular RSVP operations, E2E RSVP reservations
are unidirectional.
Head-end (iii) this RSVP reservation is aggregated over an
This is the Label Switch Router responsible for MPLS TE tunnel between the Aggregator and
establishing, maintaining and tearing down a given TE Deaggregator.
tunnel.
Tail-end An E2E RSVP reservation may be a per-flow
This is the Label Switch Router responsible for reservation. Alternatively, the E2E reservation may
terminating a given TE tunnel itself be an aggregate reservation of various types
(e.g., Aggregate IP reservation, Aggregate IPsec
reservation). See Section 5 and 6 for more details
on the types of E2E RSVP reservations. As per
regular RSVP operations, E2E RSVP reservations are
unidirectional.
Transit LSR This is a Label Switch router that is on the path of a Head-end This is the Label Switch Router responsible for
given TE tunnel and is neither the Head-end nor the establishing, maintaining, and tearing down a given
Tail-end TE tunnel.
4. Operations of RSVP Aggregation over TE with pre-established Tunnels Tail-end This is the Label Switch Router responsible for
terminating a given TE tunnel.
[RSVP-AGG] supports operations both in the case where aggregate RSVP Transit LSR This is a Label Switch Router that is on the path of
reservations are pre-established and in the case where Aggregators a given TE tunnel and is neither the Head-end nor
and Deaggregators have to dynamically discover each other and the Tail-end.
dynamically establish the necessary aggregate RSVP reservations.
RSVP Aggregation over MPLS TE tunnels September 2006 4. Operations of RSVP Aggregation over TE with Pre-established Tunnels
[RSVP-AGG] and [RSVP-GEN-AGG] support operations both in the case
where aggregate RSVP reservations are pre-established and where
Aggregators and Deaggregators have to dynamically discover each other
and dynamically establish the necessary aggregate RSVP reservations.
Similarly, RSVP Aggregation over TE tunnels could operate both in the Similarly, RSVP Aggregation over TE tunnels could operate both in the
case where the TE tunnels are pre-established and in the case where case where the TE tunnels are pre-established and where the tunnels
the tunnels need to be dynamically established. need to be dynamically established.
In this document we provide a detailed description of the procedures In this document we provide a detailed description of the procedures
in the case where TE tunnels are already established. These in the case where TE tunnels are already established. These
procedures are based on those defined in [LSP-HIER]. The routing procedures are based on those defined in [LSP-HIER]. The routing
aspects discussed in section 3 of [LSP-HIER] are not relevant here aspects discussed in Section 3 of [LSP-HIER] are not relevant here
because those aim at allowing the constraint based routing of end-to- because those aim at allowing the constraint based routing of end-
end TE LSPs to take into account the (aggregate) TE tunnels. In the to-end TE LSPs to take into account the (aggregate) TE tunnels. In
present document, the end-to-end RSVP reservations to be aggregated the present document, the end-to-end RSVP reservations to be
over the TE tunnels rely on regular SPF routing. However, as already aggregated over the TE tunnels rely on regular SPF routing. However,
mentioned in [LSP-HIER], we note that a TE Tunnel may be advertised as already mentioned in [LSP-HIER], we note that a TE tunnel may be
into ISIS or OSPF, to be used in normal SPF by nodes upstream of the advertised into IS-IS or OSPF, to be used in normal SPF by nodes
Aggregator. This would affect SPF routing and thus routing of end-to- upstream of the Aggregator. This would affect SPF routing and thus
end RSVP reservations. The control of aggregation boundaries routing of end-to-end RSVP reservations. The control of aggregation
discussed in section 6 of [LSP-HIER] is also not relevant here. This boundaries discussed in Section 6 of [LSP-HIER] is also not relevant
uses information exchanged in GMPLS protocols to dynamically discover here. This uses information exchanged in GMPLS protocols to
the aggregation boundary. In this document, TE tunnels are pre- dynamically discover the aggregation boundary. In this document, TE
established, so that the aggregation boundary can be easily inferred. tunnels are pre-established, so that the aggregation boundary can be
The signaling aspects discussed in section 6.2 of [LSP-HIER] apply to easily inferred. The signaling aspects discussed in Section 6.2 of
the establishment/termination of the aggregate TE tunnels when this [LSP-HIER] apply to the establishment/termination of the aggregate TE
is triggered by GMPLS mechanisms (e.g. as a result of an end-to-end tunnels when this is triggered by GMPLS mechanisms (e.g., as a result
TE LSP establishment request received at the aggregation boundary) . of an end-to-end TE LSP establishment request received at the
As this document assumes pre-established tunnels, those aspects are aggregation boundary). As this document assumes pre-established
not relevant here. The signaling aspects discussed in section 6.1 of tunnels, those aspects are not relevant here. The signaling aspects
[LSP-HIER] relate to the establishment/maintenance of the end-to-end discussed in Section 6.1 of [LSP-HIER] relate to the
TE LSPs over the aggregate TE tunnel. This document describes how to establishment/maintenance of the end-to-end TE LSPs over the
use the same procedures as those specified in section 6.1 of [LSP- aggregate TE tunnel. This document describes how to use the same
HIER], but for the establishment of end-to-end RSVP reservations procedures as those specified in Section 6.1 of [LSP-HIER], but for
(instead of end-to-end TE LSPs) over the TE tunnels. This is covered the establishment of end-to-end RSVP reservations (instead of end-
further in section 4 of the present document. to-end TE LSPs) over the TE tunnels. This is covered further in
Section 4 of the present document.
Pre-establishment of the TE tunnels may be triggered by any Pre-establishment of the TE tunnels may be triggered by any
mechanisms including for example manual configuration or automatic mechanisms including; for example, manual configuration or automatic
establishment of a TE tunnel mesh through dynamic discovery of TE establishment of a TE tunnel mesh through dynamic discovery of TE
Mesh membership as allowed in [AUTOMESH]. Mesh membership as allowed in [AUTOMESH].
Procedures in the case of dynamically established TE tunnels are for Procedures in the case of dynamically established TE tunnels are for
further studies. further studies.
4.1. Reference Model 4.1. Reference Model
|----| |----| |----| |----|
H--| R |\ |-----| |------| /| R |--H H--| R |\ |-----| |------| /| R |--H
H--| |\\| | |---| | |//| |--H H--| |\\| | |---| | |//| |--H
|----| \| He/ | | T | | Te/ |/ |----| |----| \| He/ | | T | | Te/ |/ |----|
| Agg |=======================| Deag | | Agg |=======================| Deag |
RSVP Aggregation over MPLS TE tunnels September 2006
/| | | | | |\ /| | | | | |\
H--------//| | |---| | |\\--------H H--------//| | |---| | |\\--------H
H--------/ |-----| |------| \--------H H--------/ |-----| |------| \--------H
H = Host requesting end-to-end RSVP reservations H = Host requesting end-to-end RSVP reservations
R = RSVP router R = RSVP router
He/Agg = TE tunnel Head-end/Aggregator He/Agg = TE tunnel Head-end/Aggregator
Te/Deag = TE tunnel Tail-end/Deaggregator Te/Deag = TE tunnel Tail-end/Deaggregator
T = Transit LSR T = Transit LSR
-- = E2E RSVP reservation -- = E2E RSVP reservation
== = TE Tunnel == = TE tunnel
4.2. Receipt of E2E Path message By the Aggregator 4.2. Receipt of E2E Path Message by the Aggregator
The first event is the arrival of the E2E Path message at the The first event is the arrival of the E2E Path message at the
Aggregator. The Aggregator MUST follow traditional RSVP procedures Aggregator. The Aggregator MUST follow traditional RSVP procedures
for processing of this E2E path message augmented with the extensions for the processing of this E2E path message augmented with the
documented in this section. extensions documented in this section.
The Aggregator MUST first attempt to map the E2E reservation onto a The Aggregator MUST first attempt to map the E2E reservation onto a
TE tunnel. This decision is made in accordance with routing TE tunnel. This decision is made in accordance with routing
information as well as any local policy information that may be information as well as any local policy information that may be
available at the Aggregator. Examples of such policies appear in the available at the Aggregator. Examples of such policies appear in the
following paragraphs. Just for illustration purposes, among many following paragraphs. Just for illustration purposes, among many
other criteria, such mapping policies might take into account the other criteria, such mapping policies might take into account the
Intserv service type, the Application Identity [RSVP-APPID] and/or Intserv service type, the Application Identity [RSVP-APPID], and/or
the signaled preemption [RSVP-PREEMP] of the E2E reservation (for the signaled preemption [RSVP-PREEMP] of the E2E reservation (for
example, the aggregator may take into account the E2E reservations example, the aggregator may take into account the E2E reservations
RSVP preemption priority and the MPLS TE Tunnel set-up and/or hold RSVP preemption priority and the MPLS TE tunnel setup and/or hold
priorities when mapping the E2E reservation onto an MPLS TE tunnel). priorities when mapping the E2E reservation onto an MPLS TE tunnel).
There are situations where the Aggregator is able to make a final There are situations where the Aggregator is able to make a final
mapping decision. That would be the case, for example, if there is a mapping decision. That would be the case, for example, if there is a
single TE tunnel towards the destination and if the policy is to map single TE tunnel toward the destination and if the policy is to map
any E2E RSVP reservation onto TE Tunnels. any E2E RSVP reservation onto TE tunnels.
There are situations where the Aggregator is not able to make a final There are situations where the Aggregator is not able to make a final
determination. That would be the case, for example, if routing determination. That would be the case, for example, if routing
identifies two DS-TE tunnels towards the destination, one belonging identifies two DS-TE tunnels toward the destination, one belonging to
to DS-TE Class-Type 1 and one to Class-Type 0, if the policy is to DS-TE Class-Type 1 and one to Class-Type 0, if the policy is to map
map Intserv Guaranteed Services reservations to a Class-Type 1 tunnel Intserv Guaranteed Services reservations to a Class-Type 1 tunnel and
and Intserv Controlled Load reservations to a Class-Type 0 tunnel, Intserv Controlled Load reservations to a Class-Type 0 tunnel, and if
and if the E2E RSVP Path message advertises both Guaranteed Service the E2E RSVP Path message advertises both Guaranteed Service and
and Controlled Load. Controlled Load.
RSVP Aggregation over MPLS TE tunnels September 2006
Whether final or tentative, the Aggregator makes a mapping decision Whether final or tentative, the Aggregator makes a mapping decision
and selects a TE tunnel. Before forwarding the E2E Path message and selects a TE tunnel. Before forwarding the E2E Path message
towards the receiver, the Aggregator SHOULD update the ADSPEC inside toward the receiver, the Aggregator SHOULD update the ADSPEC inside
the E2E Path message to reflect the impact of the MPLS TE cloud onto the E2E Path message to reflect the impact of the MPLS TE cloud onto
the QoS achievable by the E2E flow. This update is a local matter and the QoS achievable by the E2E flow. This update is a local matter
may be based on configured information, on information available in and may be based on configured information, on the information
the MPLS TE topology database, on the current TE tunnel path, on available in the MPLS TE topology database, on the current TE tunnel
information collected via RSVP-TE signaling, or combinations of those. path, on information collected via RSVP-TE signaling, or a
Updating the ADSPEC allow receivers that take into account the combination thereof. Updating the ADSPEC allows receivers that take
information collected in the ADSPEC within the network (such as delay into account the information collected in the ADSPEC within the
and bandwidth estimates) to make more informed reservation decisions. network (such as delay and bandwidth estimates) to make more informed
reservation decisions.
The Aggregator MUST then forward the E2E Path message to the The Aggregator MUST then forward the E2E Path message to the
Deaggregator (which is the tail-end of the selected TE tunnel). In Deaggregator (which is the Tail-end of the selected TE tunnel). In
accordance with [LSP-HIER], the Aggregator MUST send the E2E Path accordance with [LSP-HIER], the Aggregator MUST send the E2E Path
message with an IF_ID RSVP_HOP object instead of an RSVP_HOP object. message with an IF_ID RSVP_HOP object instead of an RSVP_HOP object.
The data interface identification MUST identify the TE Tunnel. The data interface identification MUST identify the TE tunnel.
To send the E2E Path message, the Aggregator MUST address it directly To send the E2E Path message, the Aggregator MUST address it directly
to the Deaggregator by setting the destination address in the IP to the Deaggregator by setting the destination address in the IP
Header of the E2E Path message to the Deaggregator address. The Header of the E2E Path message to the Deaggregator address. The
Router Alert is not set in the E2E Path message. Router Alert is not set in the E2E Path message.
Optionally, the Aggregator MAY also encapsulate the E2E Path message Optionally, the Aggregator MAY also encapsulate the E2E Path message
in an IP tunnel or in the TE tunnel itself. in an IP tunnel or in the TE tunnel itself.
Regardless of the encapsulation method, the Router Alert is not set. Regardless of the encapsulation method, the Router Alert is not set.
Thus, the E2E Path message will not be visible to routers along the Thus, the E2E Path message will not be visible to routers along the
path from the Aggregator to the Deaggregator. Therefore, in contrast path from the Aggregator to the Deaggregator. Therefore, in contrast
to the procedures of [RSVP-AGG], the IP Protocol number need not be to the procedures of [RSVP-AGG] and [RSVP-GEN-AGG], the IP Protocol
modified to "RSVP-E2E-IGNORE"; it MUST be left as is (indicating number does not need to be modified to "RSVP-E2E-IGNORE"; it MUST be
"RSVP") by the Aggregator. left as is (indicating "RSVP") by the Aggregator.
In some environments, the Aggregator and Deaggregator MAY also act as In some environments, the Aggregator and Deaggregator MAY also act as
IPsec Security Gateways in order to provide IPsec protection to E2E IPsec Security Gateways in order to provide IPsec protection to E2E
traffic when it transits between the Aggregator and the Deaggregator. traffic when it transits between the Aggregator and the Deaggregator.
In that case, to transmit the E2E Path message to the Deaggregator, In that case, to transmit the E2E Path message to the Deaggregator,
the Aggregator MUST send the E2E Path message into the relevant IPsec the Aggregator MUST send the E2E Path message into the relevant IPsec
tunnel terminating on the Deaggregator. tunnel terminating on the Deaggregator.
E2E PathTear and ResvConf messages MUST be forwarded by the E2E PathTear and ResvConf messages MUST be forwarded by the
Aggregator to the Deaggregator exactly like Path messages. Aggregator to the Deaggregator exactly like Path messages.
4.3. Handling of E2E Path message By Transit LSRs 4.3. Handling of E2E Path Message by Transit LSRs
Since the E2E Path message is addressed directly to the Deaggregator Since the E2E Path message is addressed directly to the Deaggregator
and does not have Router Alert set, it is hidden from all transit and does not have Router Alert set, it is hidden from all transit
LSRs. LSRs.
RSVP Aggregation over MPLS TE tunnels September 2006 4.4. Receipt of E2E Path Message by the Deaggregator
4.4. Receipt of E2E Path Message by Deaggregator
On receipt of the E2E Path message addressed to it, the Deaggregator Upon receipt of the E2E Path message addressed to it, the
will notice that the IP Protocol number is set to "RSVP" and will Deaggregator will notice that the IP Protocol number is set to "RSVP"
thus perform RSVP processing of the E2E Path message. and will thus perform RSVP processing of the E2E Path message.
As with [LSP-HIER], the IP TTL vs. RSVP TTL check MUST NOT be made. As with [LSP-HIER], the IP TTL vs. RSVP TTL check MUST NOT be made.
The Deaggregator is informed that this check is not to be made The Deaggregator is informed that this check is not to be made
because of the presence of the IF_ID RSVP HOP object. because of the presence of the IF_ID RSVP HOP object.
The Deaggregator MAY support the option to perform the following The Deaggregator MAY support the option to perform the following
checks (defined in [LSP-HIER]) by the receiver Y of the IF_ID checks (defined in [LSP-HIER]) by the receiver Y of the IF_ID
RSVP_HOP object: RSVP_HOP object:
1. Make sure that the data interface identified in the IF_ID 1. Make sure that the data interface identified in the IF_ID
RSVP_HOP object actually terminates on Y. RSVP_HOP object actually terminates on Y.
2. Find the "other end" of the above data interface, say X.
Make sure that the PHOP in the IF_ID RSVP_HOP object is a 2. Find the "other end" of the above data interface, i.e., X. Make
control channel address that belongs to the same node as X. sure that the PHOP in the IF_ID RSVP_HOP object is a control
channel address that belongs to the same node as X.
The information necessary to perform these checks may not always be The information necessary to perform these checks may not always be
available to the Deaggregator. Hence, the Deaggregator MUST support available to the Deaggregator. Hence, the Deaggregator MUST support
operations in such environments where the checks cannot be made. operations in such environments where the checks cannot be made.
The Deaggregator MUST forward the E2E Path downstream towards the The Deaggregator MUST forward the E2E Path downstream toward the
receiver. In doing so, the Deaggregator sets the destination address receiver. In doing so, the Deaggregator sets the destination address
in the IP header of the E2E Path message to the IP address found in in the IP header of the E2E Path message to the IP address found in
the destination address field of the Session object. The Deaggregator the destination address field of the Session object. The
also sets the Router Alert. Deaggregator also sets the Router Alert.
An E2E PathErr sent by the Deaggregator in response to the E2E Path An E2E PathErr sent by the Deaggregator in response to the E2E Path
message (which contains an IF_ID RSVP_HOP object) SHOULD contain an message (which contains an IF_ID RSVP_HOP object) SHOULD contain an
IF_ID RSVP_HOP object. IF_ID RSVP_HOP object.
4.5. Handling of E2E Resv Message by Deaggregator 4.5. Handling of E2E Resv Message by the Deaggregator
As per regular RSVP operations, after receipt of the E2E Path, the As per regular RSVP operations, after receipt of the E2E Path, the
receiver generates an E2E Resv message which travels upstream hop-by- receiver generates an E2E Resv message which travels upstream hop-
hop towards the sender. by-hop towards the sender.
On receipt of the E2E Resv, the Deaggregator MUST follow traditional
RSVP procedures on receipt of the E2E Resv message. This includes
performing admission control for the segment downstream of the
Deaggregator and forwarding the E2E Resv message to the PHOP signaled
earlier in the E2E Path message and which identifies the Aggregator.
Since the E2E Resv message is directly addressed to the Aggregator
RSVP Aggregation over MPLS TE tunnels September 2006
and does not carry the Router Alert option (as per traditional RSVP Upon receipt of the E2E Resv, the Deaggregator MUST follow
Resv procedures), the E2E Resv message is hidden from the routers traditional RSVP procedures on receipt of the E2E Resv message. This
between the Deaggregator and the Aggregator which, therefore, handle includes performing admission control for the segment downstream of
the E2E Resv message as a regular IP packet. the Deaggregator and forwarding the E2E Resv message to the PHOP
signaled earlier in the E2E Path message and which identifies the
Aggregator. Since the E2E Resv message is directly addressed to the
Aggregator and does not carry the Router Alert option (as per
traditional RSVP Resv procedures), the E2E Resv message is hidden
from the routers between the Deaggregator and the Aggregator which,
therefore, handle the E2E Resv message as a regular IP packet.
If the Aggregator and Deaggregator are also acting as IPsec Security If the Aggregator and Deaggregator are also acting as IPsec Security
Gateways, the Deaggregator MUST send the E2E Resv message into the Gateways, the Deaggregator MUST send the E2E Resv message into the
relevant IPsec tunnel terminating on the Aggregator. relevant IPsec tunnel terminating on the Aggregator.
4.6. Handling of E2E Resv Message by the Aggregator 4.6. Handling of E2E Resv Message by the Aggregator
The Aggregator is responsible for ensuring that there is sufficient The Aggregator is responsible for ensuring that there is sufficient
bandwidth available and reserved over the appropriate TE tunnel to bandwidth available and reserved over the appropriate TE tunnel to
the Deaggregator for the E2E reservation. the Deaggregator for the E2E reservation.
On receipt of the E2E Resv message, the Aggregator MUST first perform On receipt of the E2E Resv message, the Aggregator MUST first perform
the final mapping onto the final TE tunnel (if the previous mapping the final mapping onto the final TE tunnel (if the previous mapping
was only a tentative one). was only a tentative one).
If the tunnel did not change during the final mapping, the Aggregator If the tunnel did not change during the final mapping, the Aggregator
continues processing of the E2E Resv as described in the four continues the processing of the E2E Resv as described in the four
following paragraphs. following paragraphs.
The aggregator calculates the size of the resource request using The aggregator calculates the size of the resource request using
traditional RSVP procedures. That is, it follows the procedures in traditional RSVP procedures. That is, it follows the procedures in
[RSVP] to determine the resource requirements from the Sender Tspec [RSVP] to determine the resource requirements from the Sender Tspec
and the Flowspec contained in the Resv. Then it compares the resource and the Flowspec contained in the Resv. Then it compares the
request with the available resources of the selected TE tunnel. resource request with the available resources of the selected TE
tunnel.
If sufficient bandwidth is available on the final TE tunnel, the If sufficient bandwidth is available on the final TE tunnel, the
Aggregator MUST update its internal understanding of how much of the Aggregator MUST update its internal understanding of how much of the
TE Tunnel is in use and MUST forward the E2E Resv messages to the TE tunnel is in use and MUST forward the E2E Resv messages to the
corresponding PHOP. corresponding PHOP.
As noted in [RSVP-AGG], a range of policies MAY be applied to the re- As noted in [RSVP-AGG], a range of policies MAY be applied to the
sizing of the aggregate reservation (in this case, the TE tunnel.) re-sizing of the aggregate reservation (in this case, the TE tunnel).
For example, the policy may be that the reserved bandwidth of the For example, the policy may be that the reserved bandwidth of the
tunnel can only be changed by configuration. More dynamic policies tunnel can only be changed by configuration. More dynamic policies
are also possible, whereby the aggregator may attempt to increase the are also possible, whereby the aggregator may attempt to increase the
reserved bandwidth of the tunnel in response to the amount of reserved bandwidth of the tunnel in response to the amount of
allocated bandwidth that has been used by E2E reservations. allocated bandwidth that has been used by E2E reservations.
Furthermore, to avoid the delay associated with the increase of the Furthermore, to avoid the delay associated with the increase of the
Tunnel size, the Aggregator may attempt to anticipate the increases tunnel size, the Aggregator may attempt to anticipate the increases
in demand and adjust the TE tunnel size ahead of actual needs by E2E in demand and adjust the TE tunnel size ahead of actual needs by E2E
reservations. In order to reduce disruptions, the aggregator SHOULD reservations. In order to reduce disruptions, the Aggregator SHOULD
use "make-before-break" procedures as described in [RSVP-TE] to alter use "make-before-break" procedures as described in [RSVP-TE] to alter
the TE tunnel bandwidth. the TE tunnel bandwidth.
RSVP Aggregation over MPLS TE tunnels September 2006 If sufficient bandwidth is not available on the final TE tunnel, the
If sufficient bandwidth is not available on the final TE Tunnel, the
Aggregator MUST follow the normal RSVP procedure for a reservation Aggregator MUST follow the normal RSVP procedure for a reservation
being placed with insufficient bandwidth to support this reservation. being placed with insufficient bandwidth to support it. That is, the
That is, the reservation is not installed and a ResvError is sent reservation is not installed and a ResvError is sent back toward the
back towards the receiver. receiver.
If the tunnel did change during the final mapping, the Aggregator If the tunnel did change during the final mapping, the Aggregator
MUST first resend to the Deaggregator an E2E Path message with the MUST first resend to the Deaggregator an E2E Path message with the
IF_ID RSVP_HOP data interface identification identifying the final TE IF_ID RSVP_HOP data interface identification identifying the final TE
Tunnel. If needed, the ADSPEC information in this E2E Path message tunnel. If needed, the ADSPEC information in this E2E Path message
SHOULD be updated. Then the Aggregator MUST SHOULD be updated. Then the Aggregator MUST
- either drop the E2E Resv message - either drop the E2E Resv message
- or proceed with the processing of the E2E Resv in the same - or proceed with the processing of the E2E Resv in the same
manner as in the case where the tunnel did not change and manner as in the case where the tunnel did not change (described
described above. above).
In the former case, admission control over the final TE tunnel (and In the former case, admission control over the final TE tunnel (and
forwarding of E2E Resv message upstream towards the sender) would forwarding of E2E Resv message upstream toward the sender) would only
only occur when the Aggregator receives the subsequent E2E Resv occur when the Aggregator received the subsequent E2E Resv message
message (that will be sent by the Deaggregator in response to the (that will be sent by the Deaggregator in response to the resent E2E
resent E2E Path). In the latter case, admission control over the Path). In the latter case, admission control over the final tunnel
final Tunnel is carried out by Aggregator right away and if is carried out immediately by the Aggregator, and if successful the
successful the E2E Resv message is generated upstream towards the E2E Resv message is generated upstream toward the sender.
sender.
On receipt of an E2E ResvConf from the Aggregator, the Deaggregator Upon receipt of an E2E ResvConf from the Aggregator, the Deaggregator
MUST forward the E2E ResvConf downstream towards the receiver. In MUST forward the E2E ResvConf downstream toward the receiver. In
doing so, the Deaggregator sets the destination address in the IP doing so, the Deaggregator sets the destination address in the IP
header of the E2E ResvConf message to the IP address found in the header of the E2E ResvConf message to the IP address found in the
RESV_CONFIRM object of the corresponding Resv. The Deaggregator also RESV_CONFIRM object of the corresponding Resv. The Deaggregator also
sets the Router Alert. sets the Router Alert.
4.7. Forwarding of E2E traffic by Aggregator 4.7. Forwarding of E2E Traffic by the Aggregator
When the Aggregator receives a data packet belonging to an E2E When the Aggregator receives a data packet belonging to an E2E
reservations currently mapped over a given TE tunnel, the Aggregator reservations currently mapped over a given TE tunnel, the Aggregator
MUST encapsulate the packet into that TE tunnel. MUST encapsulate the packet into that TE tunnel.
If the Aggregator and Deaggregator are also acting as IPsec Security If the Aggregator and Deaggregator are also acting as IPsec Security
Gateways, the Aggregator MUST also encapsulate the data packet into Gateways, the Aggregator MUST also encapsulate the data packet into
the relevant IPsec tunnel terminating on the Deaggregator before the relevant IPsec tunnel terminating on the Deaggregator before
transmission into the MPLS TE tunnel. transmission into the MPLS TE tunnel.
4.8. Removal of E2E reservations 4.8. Removal of E2E Reservations
E2E reservations are removed in the usual way via PathTear, ResvTear, E2E reservations are removed in the usual way via PathTear, ResvTear,
timeout, or as the result of an error condition. When a reservation timeout, or as the result of an error condition. When a reservation
is removed, the Aggregator MUST update its local view of the is removed, the Aggregator MUST update its local view of the
RSVP Aggregation over MPLS TE tunnels September 2006
resources available on the corresponding TE tunnel accordingly. resources available on the corresponding TE tunnel accordingly.
4.9. Removal of TE Tunnel 4.9. Removal of the TE Tunnel
Should a TE Tunnel go away (presumably due to a configuration change, Should a TE tunnel go away (presumably due to a configuration change,
route change, or policy event), the aggregator behaves much like a route change, or policy event), the Aggregator behaves much like a
conventional RSVP router in the face of a link failure. That is, it conventional RSVP router in the face of a link failure. That is, it
may try to forward the Path messages onto another tunnel, if routing may try to forward the Path messages onto another tunnel, if routing
and policy permit, or it may send Path_Error messages to the sender and policy permit, or it may send Path_Error messages to the sender
if no suitable tunnel exists. In case the Path messages are forwarded if a suitable tunnel does not exist. In case the Path messages are
onto another tunnel which terminates on a different Deaggregator, or forwarded onto another tunnel, which terminates on a different
the reservation is torn-down via Path Error messages, the reservation Deaggregator, or the reservation is torn down via Path Error
state established on the router acting as the Deaggregator before the messages, the reservation state established on the router acting as
TE tunnel went away, will time out since it will no longer be the Deaggregator before the TE tunnel went away, will time out since
refreshed. it will no longer be refreshed.
RSVP Aggregation over MPLS TE tunnels September 2006
4.10. Example Signaling Flow 4.10. Example Signaling Flow
Aggregator Deaggregator Aggregator Deaggregator
(*) (*)
RSVP-TE Path RSVP-TE Path
=========================> =========================>
RSVP-TE Resv RSVP-TE Resv
skipping to change at page 16, line 37 skipping to change at page 15, line 35
E2E Resv E2E Resv
<----------- <-----------
(3) (3)
E2E Resv E2E Resv
<----------------------------- <-----------------------------
(4) (4)
E2E Resv E2E Resv
<------------- <-------------
(*) Aggregator is triggered to pre-establish the TE Tunnel(s) (*) Aggregator is triggered to pre-establish the TE tunnel(s)
(**) TE Tunnel(s) are pre-established (**) TE tunnel(s) are pre-established
(1) Aggregator tentatively selects the TE tunnel and forwards (1) Aggregator tentatively selects the TE tunnel and forwards
E2E path to Deaggregator E2E path to Deaggregator
(2) Deaggregator forwards the E2E Path towards receiver (2) Deaggregator forwards the E2E Path toward the receiver
(3) Deaggregator forwards the E2E Resv to the Aggregator (3) Deaggregator forwards the E2E Resv to the Aggregator
(4) Aggregator selects final TE tunnel, checks that there is (4) Aggregator selects final TE tunnel, checks that there is
sufficient bandwidth on TE tunnel and forwards E2E Resv to sufficient bandwidth on TE tunnel, and forwards E2E Resv to
RSVP Aggregation over MPLS TE tunnels September 2006
PHOP. If final tunnel is different from tunnel tentatively PHOP. If final tunnel is different from tunnel tentatively
selected, the Aggregator re-sends an E2E Path. selected, the Aggregator re-sends an E2E Path with an updated
IF_ID RSVP_HOP and possibly an updated ADSPEC.
5. IPv4 and IPv6 Applicability 5. IPv4 and IPv6 Applicability
The procedures defined in this document are applicable to all the The procedures defined in this document are applicable to all the
following cases: following cases:
(1) Aggregation of E2E IPv4 RSVP reservations over IPv4 TE (1) Aggregation of E2E IPv4 RSVP reservations over IPv4 TE
Tunnels tunnels.
(2) Aggregation of E2E IPv6 RSVP reservations over IPv6 TE (2) Aggregation of E2E IPv6 RSVP reservations over IPv6 TE
Tunnels tunnels.
(3) Aggregation of E2E IPv6 RSVP reservations over IPv4 TE (3) Aggregation of E2E IPv6 RSVP reservations over IPv4 TE
tunnels, provided a mechanism such as [6PE] is used by the tunnels, provided a mechanism such as [6PE] is used by the
Aggregator and Deaggregator for routing of IPv6 traffic over Aggregator and Deaggregator for routing of IPv6 traffic over
an IPv4 MPLS core, an IPv4 MPLS core.
(4) Aggregation of E2E IPv4 RSVP reservations over IPv6 TE (4) Aggregation of E2E IPv4 RSVP reservations over IPv6 TE
tunnels, provided a mechanism is used by the Aggregator and tunnels, provided a mechanism is used by the Aggregator and
Deaggregator for routing IPv4 traffic over IPv6 MPLS. Deaggregator for routing IPv4 traffic over IPv6 MPLS.
6. E2E Reservations Applicability 6. E2E Reservations Applicability
The procedures defined in this document are applicable to many types The procedures defined in this document are applicable to many types
of E2E RSVP reservations including the following cases: of E2E RSVP reservations including the following cases:
(1) the E2E RSVP reservation is a per-flow reservation where the
(1) The E2E RSVP reservation is a per-flow reservation where the
flow is characterized by the usual 5-tuple flow is characterized by the usual 5-tuple
(2) the E2E reservation is an aggregate reservation for multiple
(2) The E2E reservation is an aggregate reservation for multiple
flows as described in [RSVP-AGG] or [RSVP-GEN-AGG] where the flows as described in [RSVP-AGG] or [RSVP-GEN-AGG] where the
set of flows is characterized by the <source address, set of flows is characterized by the <source address,
destination address, DSCP> destination address, DSCP>
(3) the E2E reservation is a reservation for an IPsec protected
(3) The E2E reservation is a reservation for an IPsec protected
flow. For example, where the flow is characterized by the flow. For example, where the flow is characterized by the
<source address, destination address, SPI> as described in <source address, destination address, SPI> as described in
[RSVP-IPSEC]. [RSVP-IPSEC].
7. Example Deployment Scenarios 7. Example Deployment Scenarios
7.1. Voice and Video Reservations Scenario 7.1. Voice and Video Reservations Scenario
An example application of the procedures specified in this document An example application of the procedures specified in this document
is admission control of voice and video in environments with very is admission control of voice and video in environments with a very
high numbers of hosts. In the example illustrated below, hosts high number of hosts. In the example illustrated below, hosts
generate end-to-end per-flow reservations for each of their video generate E2E per-flow reservations for each of their video streams
streams associated with a video-conference, each of their audio associated with a video-conference, each of their audio streams
streams associated with a video-conference and each of their voice associated with a video-conference and each of their voice calls.
calls. These reservations are aggregated over MPLS DS-TE tunnels over
RSVP Aggregation over MPLS TE tunnels September 2006
the packet core. The mapping policy defined by the user maybe that These reservations are aggregated over MPLS DS-TE tunnels over the
all the reservations for audio and voice streams are mapped onto DS- packet core. The mapping policy defined by the user may be that all
TE tunnels of Class-Type 1 while reservations for video streams are the reservations for audio and voice streams are mapped onto DS-TE
tunnels of Class-Type 1, while reservations for video streams are
mapped onto DS-TE tunnels of Class-Type 0. mapped onto DS-TE tunnels of Class-Type 0.
------ ------ ------ ------
| H |# ------- -------- #| H | | H |# ------- -------- #| H |
| |\#| | ----- | |#/| | | |\#| | ----- | |#/| |
-----| \| Agg | | T | | Deag |/ ------ -----| \| Agg | | T | | Deag |/ ------
| |==========================| | | |==========================| |
------ /| |::::::::::| |:::::::::::| |\ ------ ------ /| |::::::::::::::::::::::::::| |\ ------
| H |/#| | ----- | |#\| H | | H |/#| | ----- | |#\| H |
| |# ------- -------- #| | | |# ------- -------- #| |
------ ------ ------ ------
H = Host H = Host
Agg = Aggregator (TE Tunnel Head-end) Agg = Aggregator (TE tunnel Head-end)
Deagg = Deaggregator (TE Tunnel Tail-end) Deagg = Deaggregator (TE tunnel Tail-end)
T = Transit LSR T = Transit LSR
/ = E2E RSVP reservation for a Voice flow / = E2E RSVP reservation for a Voice flow
# = E2E RSVP reservation for a Video flow # = E2E RSVP reservation for a Video flow
== = DS-TE Tunnel from Class-Type 1 == = DS-TE tunnel from Class-Type 1
:: = DS-TE Tunnel from Class-Type 0 :: = DS-TE tunnel from Class-Type 0
7.2. PSTN/3G Voice Trunking Scenario 7.2. PSTN/3G Voice Trunking Scenario
An example application of the procedures specified in this document An example application of the procedures specified in this document
is voice call admission control in large scale telephony trunking is voice call admission control in large-scale telephony trunking
environments. A Trunk VoIP Gateway may generate one aggregate RSVP environments. A Trunk VoIP Gateway may generate one aggregate RSVP
reservation for all the calls in place towards another given remote reservation for all the calls in place toward another given remote
Trunk VoIP Gateway (with resizing of this aggregate reservation in a Trunk VoIP Gateway (with resizing of this aggregate reservation in a
step function depending on current number of calls). In turn, these step function depending on the current number of calls). In turn,
reservations may be aggregated over MPLS TE tunnels over the packet these reservations may be aggregated over MPLS TE tunnels over the
core so that tunnel Head-ends act as Aggregators and perform packet core so that tunnel Head-ends act as Aggregators and perform
admission control of Trunk Gateway reservations into MPLS TE Tunnels. admission control of Trunk Gateway reservations into MPLS TE tunnels.
The MPLS TE tunnels may be protected by MPLS Fast Reroute. The MPLS TE tunnels may be protected by MPLS Fast Reroute. This
This scenario is illustrated below: scenario is illustrated below:
RSVP Aggregation over MPLS TE tunnels September 2006
------ ------ ------ ------
| GW |\ ------- -------- /| GW | | GW |\ ------- -------- /| GW |
| |\\| | ----- | |//| | | |\\| | ----- | |//| |
-----| \| Agg | | T | | Deag |/ ------ -----| \| Agg | | T | | Deag |/ ------
| |==========================| | | |==========================| |
------ /| | | | | |\ ------ ------ /| | | | | |\ ------
| GW |//| | ----- | |\\| GW | | GW |//| | ----- | |\\| GW |
| |/ ------- -------- \| | | |/ ------- -------- \| |
------ ------ ------ ------
GW = VoIP Gateway GW = VoIP Gateway
Agg = Aggregator (TE Tunnel Head-end) Agg = Aggregator (TE tunnel Head-end)
Deagg = Deaggregator (TE Tunnel Tail-end) Deagg = Deaggregator (TE tunnel Tail-end)
T = Transit LSR T = Transit LSR
/ = Aggregate Gateway to Gateway E2E RSVP reservation / = Aggregate Gateway to Gateway E2E RSVP reservation
== = TE Tunnel == = TE tunnel
8. Security Considerations 8. Security Considerations
In the environments concerned by this document, RSVP messages are In the environments concerned by this document, RSVP messages are
used to control resource reservations for E2E flows outside the MPLS used to control resource reservations for E2E flows outside the MPLS
region as well as to control resource reservations for MPLS TE region as well as to control resource reservations for MPLS TE
Tunnels inside the MPLS region. To ensure the integrity of the tunnels inside the MPLS region. To ensure the integrity of the
associated reservation and admission control mechanisms, the associated reservation and admission control mechanisms, the
mechanisms defined in [RSVP-CRYPTO1] and [RSVP-CRYPTO2] can be used. mechanisms defined in [RSVP-CRYPTO1] and [RSVP-CRYPTO2] can be used.
Those protect RSVP messages integrity hop-by-hop and provide node The mechanisms protect the integrity of RSVP messages hop-by-hop and
authentication, thereby protecting against corruption and spoofing of provide node authentication, thereby protecting against corruption
RSVP messages. These hop-by-hop integrity mechanisms can naturally be and spoofing of RSVP messages. These hop-by-hop integrity mechanisms
used to protect the RSVP messages used for E2E reservations outside can naturally be used to protect the RSVP messages used for E2E
the MPLS region, to protect RSVP messages used for MPLS TE Tunnels reservations outside the MPLS region, to protect RSVP messages used
inside the MPLS region, or for both. These hop-by-hop RSVP integrity for MPLS TE tunnels inside the MPLS region, or for both. These hop-
mechanisms can also be used to protect RSVP messages used for E2E by-hop RSVP integrity mechanisms can also be used to protect RSVP
reservations when those transit through the MPLS region. This is messages used for E2E reservations when those transit through the
because the Aggregator and Deaggregator behave as RSVP neighbors from MPLS region. This is because the Aggregator and Deaggregator behave
the viewpoint of the E2E flows (even if they are not necessarily IP as RSVP neighbors from the viewpoint of the E2E flows (even if they
neighbors nor RSVP-TE neighbors). It that case, the Aggregator and are not necessarily IP neighbors nor RSVP-TE neighbors). In that
Deaggregator need to use a pre-shared secret. case, the Aggregator and Deaggregator need to use a pre-shared
secret.
As discussed in section 6 of [RSVP-TE], filtering of traffic As discussed in Section 6 of [RSVP-TE], filtering of traffic
associated with an MPLS TE Tunnel can only be done on the basis of an associated with an MPLS TE tunnel can only be done on the basis of an
MPLS label, instead of the 5-tuple of conventional RSVP reservation MPLS label, instead of the 5-tuple of conventional RSVP reservation
as per [RSVP]. Thus, as explained in [RSVP-TE], an administrator may as per [RSVP]. Thus, as explained in [RSVP-TE], an administrator may
wish to limit the domain over which TE Tunnels (which are used for wish to limit the domain over which TE tunnels (which are used for
aggregation of RSVP E2E reservations as per this specification) can aggregation of RSVP E2E reservations as per this specification) can
be established. See Section 6 of [RSVP-TE] for a description of how
RSVP Aggregation over MPLS TE tunnels September 2006 filtering of RSVP messages associated with MPLS TE tunnels can be
be established. See section 6 of [RSVP-TE] for a description of how
filtering of RSVP messages associated with MPLS TE Tunnels can be
deployed to that end. deployed to that end.
This document is based in part on [RSVP-AGG] which specifies This document is based in part on [RSVP-AGG], which specifies
aggregation of RSVP reservations. Section 5 of [RSVP-AGG] raises the aggregation of RSVP reservations. Section 5 of [RSVP-AGG] raises the
point that because many E2E flows may share an aggregate reservation, point that because many E2E flows may share an aggregate reservation,
if the security of an aggregate reservation is compromised, there is if the security of an aggregate reservation is compromised, there is
a multiplying effect in the sense that it can in turn compromise the a multiplying effect in the sense that it can in turn compromise the
security of many E2E reservations whose quality of service depends on security of many E2E reservations whose quality of service depends on
the aggregate reservation. This concern applies also to RSVP the aggregate reservation. This concern applies also to RSVP
Aggregation over TE Tunnels as specified in the present document. Aggregation over TE tunnels as specified in the present document.
However, the integrity of MPLS TE Tunnels operation can be protected However, the integrity of MPLS TE tunnels operation can be protected
using the mechanisms discussed in the previous paragraphs. Also, using the mechanisms discussed in the previous paragraphs. Also,
while [RSVP-AGG] specifies RSVP Aggregation over dynamically while [RSVP-AGG] specifies RSVP Aggregation over dynamically
established aggregate reservations, the present document restricts established aggregate reservations, the present document restricts
itself to RSVP Aggregation over pre-established TE Tunnels. This itself to RSVP Aggregation over pre-established TE tunnels. This
further reduces the security risks. further reduces the security risks.
In the case where the Aggregators dynamically resize the TE tunnels In the case where the Aggregators dynamically resize the TE tunnels
based on the current level of reservation, there are risks that the based on the current level of reservation, there are risks that the
TE tunnels used for RSVP aggregation hog resources in the core which TE tunnels used for RSVP aggregation hog resources in the core, which
could prevent other TE Tunnels from being established. There are also could prevent other TE tunnels from being established. There are
potential risks that such resizing results in significant computation also potential risks that such resizing results in significant
and signaling as well as churn on tunnel paths. Such risks can be computation and signaling as well as churn on tunnel paths. Such
mitigated by configuration options allowing control of TE tunnel risks can be mitigated by configuration options allowing control of
dynamic resizing (maximum TE tunnel size, maximum resizing TE tunnel dynamic resizing (maximum TE tunnel size, maximum resizing
frequency, ...) and/or possibly by the use of TE preemption. frequency, etc.), and/or possibly by the use of TE preemption.
Section 5 of [RSVP-AGG] also discusses a security issue specific to Section 5 of [RSVP-AGG] also discusses a security issue specific to
RSVP aggregation related to the necessary modification of the IP RSVP aggregation related to the necessary modification of the IP
Protocol number in RSVP E2E Path messages that traverses the Protocol number in RSVP E2E Path messages that traverses the
aggregation region. This security issue does not apply to the present aggregation region. This security issue does not apply to the
document since aggregation of RSVP reservation over TE Tunnels does present document since aggregation of RSVP reservation over TE
not use this approach of changing the protocol number in RSVP tunnels does not use this approach of changing the protocol number in
messages. RSVP messages.
Section 7 of [LSP-HIER] discusses security considerations stemming Section 7 of [LSP-HIER] discusses security considerations stemming
from the fact that the implicit assumption of a binding between data from the fact that the implicit assumption of a binding between data
interface and the interface over which a control message is sent is interface and the interface over which a control message is sent is
no longer valid. These security considerations are equally applicable no longer valid. These security considerations are equally
to the present document. applicable to the present document.
If the Aggregator and Deaggregator are also acting as IPsec Security If the Aggregator and Deaggregator are also acting as IPsec Security
Gateways, the Security Considerations of [SEC-ARCH] apply. Gateways, the Security Considerations of [SEC-ARCH] apply.
9. IANA Considerations 9. Acknowledgments
RSVP Aggregation over MPLS TE tunnels September 2006
This document has no actions for IANA.
10. Acknowledgments
This document builds on the [RSVP-AGG], [RSVP-TUN] and [LSP-HIER]
specifications. Also, we would like to thank Tom Phelan, John Drake,
Arthi Ayyangar, Fred Baker, Subha Dhesikan, Kwok-Ho Chan, Carol
Iturralde and James Gibson for their input into this document.
11. Normative References
[BCP 78], S. Bradner, IETF Rights in Contributions, RFC3978, BCP 78, This document builds on the [RSVP-AGG], [RSVP-TUN], and [LSP-HIER]
March 2005. specifications. We would like to thank Tom Phelan, John Drake, Arthi
Ayyangar, Fred Baker, Subha Dhesikan, Kwok-Ho Chan, Carol Iturralde,
and James Gibson for their input into this document.
[BCP 79] S. Bradner, Intellectual Property Rights in IETF Technology, 10. Normative References
RFC 3668, BCP 79, February 2004.
[CONTROLLED] Wroclawski, Specification of the Controlled-Load Network [CONTROLLED] Wroclawski, J., "Specification of the Controlled-Load
Element Service, RFC2211 Network Element Service", RFC 2211, September 1997.
[DIFFSERV] Blake et al., An Architecture for Differentiated Services, [DIFFSERV] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
RFC 2475 Z., and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of [DSTE-PROTO] Le Faucheur, F., "Protocol Extensions for Support of
Diff-Serv-aware MPLS Traffic Engineering, RFC 4124, June 2005. Diffserv-aware MPLS Traffic Engineering", RFC 4124,
June 2005.
[GUARANTEED] Shenker et al., Specification of Guaranteed Quality of [GUARANTEED] Shenker, S., Partridge, C., and R. Guerin,
Service, RFC2212 "Specification of Guaranteed Quality of Service", RFC
2212, September 1997.
[INT-DIFF] A Framework for Integrated Services Operation over [INT-DIFF] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang,
Diffserv Networks, RFC 2998, November 2000. L., Speer, M., Braden, R., Davie, B., Wroclawski, J.,
and E. Felstaine, "A Framework for Integrated Services
Operation over Diffserv Networks", RFC 2998, November
2000.
[INT-SERV] Braden, R., Clark, D. and S. Shenker, Integrated Services [INT-SERV] Braden, R., Clark, D., and S. Shenker, "Integrated
in the Internet Architecture: an Overview, RFC 1633, June 1994. Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[KEYWORDS] S. Bradner, Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels, RFC2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[LSP-HIER] Kompella et al, Label Switched Paths (LSP) Hierarchy with [LSP-HIER] Kompella, K. and Y. Rekhter, "Label Switched Paths
Generalized Multi-Protocol Label Switching (GMPLS) Traffic (LSP) Hierarchy with Generalized Multi-Protocol Label
Engineering (TE), RFC 4206, October 2005 Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
October 2005.
[MPLS-TE] Awduche et al., "Requirements for Traffic Engineering over [MPLS-TE] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and
J. McManus, "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999. MPLS", RFC 2702, September 1999.
[RSVP] Braden et al., Resource ReSerVation Protocol (RSVP) -- Version [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
1 Functional Specification, RFC 2205, September 1997. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
RSVP Aggregation over MPLS TE tunnels September 2006 September 1997.
[RSVP-AGG] Baker et al, Aggregation of RSVP for IPv4 and IPv6
Reservations, RFC 3175, September 2001.
[RSVP-CRYPTO1] Baker at al, RSVP Cryptographic Authentication, RFC
2747, January 2000.
[RSVP-CRYPTO2] Braden and Zhang, RSVP Cryptographic Authentication -
Updated Message Type Value, RFC 3097, April 2001.
[RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels,
RFC 3209, December 2001.
[SEC-ARCH] Kent and Seo, Security Architecture for the Internet
Protocol, RFC 4301, December 2005
12. Informative References
[6PE] De Clercq et al, Connecting IPv6 Islands over IPv4 MPLS using
IPv6 Provider Edge Routers (6PE), work in progress
[AUTOMESH] Vasseur and Leroux, Routing extensions for discovery of
Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering
(TE) mesh membership, draft-vasseur-ccamp-automesh-00.txt, work in
progress.
[DIFF-MPLS] Le Faucheur et al, MPLS Support of Diff-Serv, RFC3270,
May 2002.
[DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv-
aware MPLS Traffic Engineering, RFC3564, July 2003.
[L-RSVP] Manner et al., Localized RSVP, draft-manner-lrsvp-04.txt,
work in progress.
[RSVP-APPID] Bernet et al., Identity Representation for RSVP, RFC [RSVP-AGG] Baker, F., Iturralde, C., Le Faucheur, F., and B.
3182. Davie, "Aggregation of RSVP for IPv4 and IPv6
Reservations", RFC 3175, September 2001.
[RSVP-GEN-AGG] Le Faucheur et al, Generic Aggregate RSVP Reservations, [RSVP-CRYPTO1] Baker, F., Lindell, B., and M. Talwar, "RSVP
draft-ietf-tsvwg-rsvp-ipsec, work in progress Cryptographic Authentication", RFC 2747, January 2000.
[RSVP-IPSEC] Berger et al, RSVP Extensions for IPSEC Data Flows, RFC [RSVP-CRYPTO2] Braden, R. and L. Zhang, "RSVP Cryptographic
2207 Authentication -- Updated Message Type Value", RFC
3097, April 2001.
[RSVP-PREEMP] Herzog, Signaled Preemption Priority Policy Element, [RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
RFC 3181 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
RSVP Aggregation over MPLS TE tunnels September 2006 [SEC-ARCH] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RSVP-PROXY] Gai et al., RSVP Proxy, draft-ietf-rsvp-proxy-03.txt 11. Informative References
(expired), work in progress.
[RSVP-TUN] Terzis et al., RSVP Operation Over IP Tunnels, RFC 2746, [6PE] De Clercq, J., Ooms, D., Prevost, S., and F. Le
January 2000 Faucheur, "Connecting IPv6 Islands over IPv4 MPLS
using IPv6 Provider Edge Routers (6PE)", RFC 4798,
February 2007.
[SIP-RSVP] Camarillo, Integration of Resource Management and Session [AUTOMESH] Vasseur and Leroux, "Routing extensions for discovery
Initiation Protocol (SIP), RFC 3312 of Multiprotocol (MPLS) Label Switch Router (LSR)
Traffic Engineering (TE) mesh membership", Work in
Progress.
13. Editor's Address: [DIFF-MPLS] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P., and J.
Heinanen, "Multi-Protocol Label Switching (MPLS)
Support of Differentiated Services", RFC 3270, May
2002.
Francois Le Faucheur [DSTE-REQ] Le Faucheur, F. and W. Lai, "Requirements for Support
Cisco Systems, Inc. of Differentiated Services-aware MPLS Traffic
Village d'Entreprise Green Side - Batiment T3 Engineering", RFC 3564, July 2003.
400, Avenue de Roumanille
06410 Biot Sophia-Antipolis
France
Email: flefauch@cisco.com
IPR Statements [L-RSVP] Manner, et al., Localized RSVP for Controlling RSVP
Proxies, Work in Progress.
The IETF takes no position regarding the validity or scope of any [RSVP-APPID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore,
Intellectual Property Rights or other rights that might be claimed to T., Herzog, S., and R. Hess, "Identity Representation
pertain to the implementation or use of the technology described in for RSVP", RFC 3182, October 2001.
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 [RSVP-GEN-AGG] Le Faucheur, R., Davie, B., Bose, P., Martin, L.,
assurances of licenses to be made available, or the result of an Christou, C., Davenport, M., and A. Hamilton, "Generic
attempt made to obtain a general license or permission for the use of Aggregate Resource ReSerVation Protocol (RSVP)
such proprietary rights by implementers or users of this Reservations", Work in Progress, January 2007.
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 [RSVP-IPSEC] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
copyrights, patents or patent applications, or other proprietary Data Flows", RFC 2207, September 1997.
rights that may cover technology that may be required to implement
this standard.
Please address the information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy
Element", RFC 3181, October 2001.
RSVP Aggregation over MPLS TE tunnels September 2006 [RSVP-PROXY1] Gai, et al., RSVP Proxy, Work in Progress.
This document and the information contained herein are provided on an [RSVP-PROXY2] Le Faucheur, et al., RSVP Proxy Approaches, Work in
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS Progress.
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Notice [RSVP-TUN] Terzis, A., Krawczyk, J., Wroclawski, J., and L.
Zhang, "RSVP Operation Over IP Tunnels", RFC 2746,
January 2000.
Copyright (C) The Internet Society (2006). This document is subject [SIP-RSVP] Camarillo, G., Marshall, W., and J. Rosenberg,
to the rights, licenses and restrictions contained in BCP 78, and "Integration of Resource Management and Session
except as set forth therein, the authors retain all their rights. Initiation Protocol (SIP)", RFC 3312, October 2002.
Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator
A number of approaches ([RSVP-PROXY], [L-RSVP]) have been, or are A number of approaches ([RSVP-PROXY1],[RSVP-PROXY2], [L-RSVP]) have
being, discussed in the IETF in order to allow a network node to been, or are being, discussed in the IETF in order to allow a network
behave as an RSVP proxy which: node to behave as an RSVP proxy which:
- originates the Resv Message (in response to the Path message) on - originates the Resv Message (in response to the Path message) on
behalf of the destination node behalf of the destination node
- originates the Path message (in response to some trigger) on - originates the Path message (in response to some trigger) on
behalf of the source node. behalf of the source node.
We observe that such approaches may optionally be used in conjunction We observe that such approaches may optionally be used in conjunction
with the aggregation of RSVP reservations over MPLS TE tunnels as with the aggregation of RSVP reservations over MPLS TE tunnels as
specified in this document. In particular, we consider the case where specified in this document. In particular, we consider the case
the RSVP Aggregator/Deaggregator also behaves as the RSVP proxy. where the RSVP Aggregator/Deaggregator also behaves as the RSVP
proxy.
The information is this Appendix is purely informational and The information in this Appendix is purely informational and
illustrative. illustrative.
As discussed in [RSVP-PROXY]: As discussed in [RSVP-PROXY1]:
"The proxy functionality does not imply merely generating a single "The proxy functionality does not imply merely generating a single
Resv message. Proxying the Resv involves installing state in the node Resv message. Proxying the Resv involves installing state in the
doing the proxy i.e. the proxying node should act as if it had node doing the proxy i.e. the proxying node should act as if it had
received a Resv from the true endpoint. This involves reserving received a Resv from the true endpoint. This involves reserving
resources (if required), sending periodic refreshes of the Resv resources (if required), sending periodic refreshes of the Resv
message and tearing down the reservation if the Path is torn down." message and tearing down the reservation if the Path is torn down."
Hence, when behaving as the RSVP Proxy, the RSVP Aggregator may Hence, when behaving as the RSVP Proxy, the RSVP Aggregator may
effectively perform resource reservation over the MPLS TE Tunnel (and effectively perform resource reservation over the MPLS TE tunnel (and
hence over the whole segment between the RSVP Aggregator and the RSVP hence over the whole segment between the RSVP Aggregator and the RSVP
Deaggregator) even if the RSVP signaling only takes place upstream of Deaggregator) even if the RSVP signaling only takes place upstream of
the MPLS TE Tunnel (i.e. between the host and the RSVP aggregator). the MPLS TE tunnel (i.e., between the host and the RSVP aggregator).
RSVP Aggregation over MPLS TE tunnels September 2006
Also, the RSVP Proxy can generate the Path message on behalf of the Also, the RSVP Proxy can generate the Path message on behalf of the
remote source host in order to achieve reservation in the return remote source host in order to achieve reservation in the return
direction (i.e. from RSVP aggregator/Deaggregator to host). direction (i.e., from RSVP aggregator/Deaggregator to host).
The resulting Signaling Flow is illustrated below, covering The resulting Signaling Flow is illustrated below, covering
reservations for both directions: reservations for both directions:
|----| |--------------| |------| |--------------| |----| |----| |--------------| |------| |--------------| |----|
| | | Aggregator/ | | MPLS | | Aggregator/ | | | | | | Aggregator/ | | MPLS | | Aggregator/ | | |
|Host| | Deaggregator/| | cloud| | Deaggregator/| |Host| |Host| | Deaggregator/| | cloud| | Deaggregator/| |Host|
| | | RSVP Proxy | | | | RSVP Proxy | | | | | | RSVP Proxy | | | | RSVP Proxy | | |
|----| |--------------| |------| |--------------| |----| |----| |--------------| |------| |--------------| |----|
skipping to change at page 25, line 33 skipping to change at page 24, line 27
Path Path Path Path
------------> (1)-\ /-(i) <---------- ------------> (1)-\ /-(i) <----------
Resv | | Resv Resv | | Resv
<------------ (2)-/ \-(ii) ------------> <------------ (2)-/ \-(ii) ------------>
Path Path Path Path
<------------ (3) (iii) ------------> <------------ (3) (iii) ------------>
Resv Resv Resv Resv
------------> <------------ ------------> <------------
(1)(i) : Aggregator/Deaggregator/Proxy receives Path message, (1)(i) : Aggregator/Deaggregator/Proxy receives Path message,
selects the TE tunnel, performs admission control over the TE Tunnel. selects the TE tunnel, performs admission control over the
(1) and (i) happens independently of each other. TE tunnel. (1) and (i) happen independently of each other.
(2)(ii) : Aggregator/Deaggregator/Proxy generates the Resv message (2)(ii) : Aggregator/Deaggregator/Proxy generates the Resv message
towards Host. (2) is triggered by (1) and (ii) is triggered by (i). toward Host. (2) is triggered by (1) and (ii) is triggered
Before generating this Resv message, the Aggregator/Proxy performs by (i). Before generating this Resv message, the
admission control of the corresponding reservation over the TE tunnel Aggregator/Proxy performs admission control of the
that will eventually carry the corresponding traffic. corresponding reservation over the TE tunnel that will
eventually carry the corresponding traffic.
(3)(iii) : Aggregator/Deaggregator/Proxy generates the Path message (3)(iii) : Aggregator/Deaggregator/Proxy generates the Path message
towards Host for reservation in return direction. The actual trigger toward Host for reservation in return direction. The
for this depends on the actual RSVP proxy solution. As an example, actual trigger for this depends on the actual RSVP proxy
(3) and (iii) may simply be triggered respectively by (1) and (i). solution. As an example, (3) and (iii) may simply be
triggered respectively by (1) and (i).
Note that the details of the signaling flow may vary slightly Note that the details of the signaling flow may vary slightly
depending on the actual approach used for RSVP Proxy. For example, if depending on the actual approach used for RSVP Proxy. For example,
the [L-RSVP] approach was used instead of [RSVP-PROXY], an additional if the [L-RSVP] approach was used instead of [RSVP-PROXY1], an
PathRequest message would be needed from host to additional PathRequest message would be needed from host to
Aggregator/Deaggregator/Proxy in order to trigger the generation of Aggregator/Deaggregator/Proxy in order to trigger the generation of
the Path message for return direction. the Path message for return direction.
RSVP Aggregation over MPLS TE tunnels September 2006
But regardless of the details of the call flow and of the actual RSVP But regardless of the details of the call flow and of the actual RSVP
Proxy approach, RSVP proxy may optionally be deployed in combination Proxy approach, RSVP proxy may optionally be deployed in combination
with RSVP Aggregation over MPLS TE Tunnels, in such a way which with RSVP Aggregation over MPLS TE tunnels, in such a way that
ensures (when used on both the Host-Aggregator and Deaggregator-Host ensures (when used on both the Host-Aggregator and Deaggregator-Host
sides, and when both end systems support RSVP) that: sides, and when both end systems support RSVP):
(i) admission control and resource reservation is performed on (i) admission control and resource reservation is performed on
every segment of the end-to-end path (i.e. between source every segment of the end-to-end path (i.e., between source
host and Aggregator, over the TE Tunnel between the host and Aggregator, over the TE tunnel between the
Aggregator and Deaggregator which itself has been subject Aggregator and Deaggregator that itself has been subject to
to admission control by MPLS TE, between Deaggregator and admission control by MPLS TE, between Deaggregator and
destination host) destination host).
(ii) this is achieved in both direction (ii) this is achieved in both directions.
(iii) RSVP signaling is localized between hosts and (iii) RSVP signaling is localized between hosts and
Aggregator/Deaggregator, which may result in significant Aggregator/Deaggregator, which may result in significant
reduction in reservation establishment delays (and in turn reduction in reservation establishment delays (and in turn
in post dial delay in the case where these reservations in post-dial delay in the case where these reservations are
are pre-conditions for voice call establishment), pre-conditions for voice call establishment), particularly
particularly in the case where the MPLS TE tunnels span in the case where the MPLS TE tunnels span long distances
long distances with high propagation delays. with high propagation delays.
Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels for Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels for
VoIP Call Admission Control (CAC) VoIP Call Admission Control (CAC)
This Appendix presents an example scenario where the mechanisms This Appendix presents an example scenario where the mechanisms
described in this document are used, in combination with other described in this document are used, in combination with other
mechanisms specified by the IETF, to achieve Call Admission Control mechanisms specified by the IETF, to achieve Call Admission Control
(CAC) of Voice over IP (VoIP) traffic over the packet core. (CAC) of Voice over IP (VoIP) traffic over the packet core.
The information is that Appendix is purely informational and The information in this Appendix is purely informational and
illustrative. illustrative.
Consider the scenario depicted in Figure A1. VoIP Gateways GW1 and Consider the scenario depicted in Figure B1. VoIP Gateways GW1 and
GW2 are both signaling and media gateways. They are connected to an GW2 are both signaling and media gateways. They are connected to an
MPLS network via edge routers PE1 and PE2, respectively. In each MPLS network via edge routers PE1 and PE2, respectively. In each
direction, a DSTE tunnel passes from the head-end edge router, direction, a DSTE tunnel passes from the Head-end edge router,
through core network P routers, to the tail-end edge router. GW1 and through core network P routers, to the Tail-end edge router. GW1 and
GW2 are RSVP-enabled. The RSVP reservations established by GW1 and GW2 are RSVP-enabled. The RSVP reservations established by GW1 and
GW2 are aggregated by PE1 and PE2 over the DS-TE tunnels. For GW2 are aggregated by PE1 and PE2 over the DS-TE tunnels. For
reservations going from GW1 to GW2, PE1 serves as the reservations going from GW1 to GW2, PE1 serves as the
aggregator/head-end and PE2 serves as the de-aggregator/tail-end. For Aggregator/Head-end and PE2 serves as the Deaggregator/Tail-end. For
reservations going from GW2 to GW2, PE2 serves as the reservations going from GW2 to GW2, PE2 serves as the
aggregator/head-end and PE1 serves as the de-aggregator/tail-end. Aggregator/Head-end and PE1 serves as the Deaggregator/Tail-end.
RSVP Aggregation over MPLS TE tunnels September 2006
To determine whether there is sufficient bandwidth in the MPLS core To determine whether there is sufficient bandwidth in the MPLS core
to complete a connection, the originating and destination GWs each to complete a connection, the originating and destination GWs each
send for each connection a Resource Reservation Protocol (RSVP) send for each connection a Resource Reservation Protocol (RSVP)
bandwidth request to the network PE router to which it is connected. bandwidth request to the network PE router to which it is connected.
As part of its Aggregator role, the PE router effectively performs As part of its Aggregator role, the PE router effectively performs
admission control of the bandwidth request generated by the GW onto admission control of the bandwidth request generated by the GW onto
the resources of the corresponding DS-TE tunnel. the resources of the corresponding DS-TE tunnel.
In this example, in addition to behaving as Aggregator/Deaggregator, In this example, in addition to behaving as Aggregator/Deaggregator,
PE1 and PE2 behave as RSVP proxy. So when a PE receives a Path PE1 and PE2 behave as RSVP proxy. So when a PE receives a Path
message from a GW, it does not propagate the Path message any further. message from a GW, it does not propagate the Path message any
Rather, the PE performs admission control of the bandwidth signaled further. Rather, the PE performs admission control of the bandwidth
in the Path message over the DSTE tunnel towards the destination. signaled in the Path message over the DSTE tunnel toward the
Assuming there is enough bandwidth available on that tunnel, the PE destination. Assuming there is enough bandwidth available on that
adjusts its book-keeping of remaining available bandwidth on the tunnel, the PE adjusts its bookkeeping of remaining available
tunnel and generates a Resv message back towards the GW to confirm bandwidth on the tunnel and generates a Resv message back toward the
resources have been reserved over the DSTE tunnel. GW to confirm resources have been reserved over the DSTE tunnel.
,-. ,-. ,-. ,-.
_.---' `---' `-+ _.---' `---' `-+
,-'' +------------+ : ,-'' +------------+ :
( | | `. ( | | `.
\ ,' CCA `. : \ ,' CCA `. :
\ ,' | | `. ; \ ,' | | `. ;
;' +------------+ `._ ;' +------------+ `._
,'+ ; `. ,'+ ; `.
,' -+ Application Layer' `. ,' -+ Application Layer' `.
skipping to change at page 27, line 55 skipping to change at page 26, line 47
_|..__ +------+ { DSTE Tunnels ; +------+ __----|--. _|..__ +------+ { DSTE Tunnels ; +------+ __----|--.
_,' \-| ./ -'._ / | _,' \-| ./ -'._ / |
| Access \ / +----+ \, |_ Access | | Access \ / +----+ \, |_ Access |
| Network | \_ | P | | / Network | | Network | \_ | P | | / Network |
| / `| +----+ / | ' | / `| +----+ / | '
`--. ,.__,| | IP/MPLS Network / '---'- ----' `--. ,.__,| | IP/MPLS Network / '---'- ----'
'`' '' ' .._,,'`.__ _/ '---' | '`' '' ' .._,,'`.__ _/ '---' |
| '`''' | | '`''' |
C1 C2 C1 C2
Figure A1. Integration of SIP Resource Management, DSTE Figure B1. Integration of SIP Resource Management and
RSVP Aggregation over MPLS TE Tunnels
RSVP Aggregation over MPLS TE tunnels September 2006
and RSVP Aggregation
[SIP-RSVP] discusses how network quality of service can be made a [SIP-RSVP] discusses how network quality of service can be made a
precondition for establishment of sessions initiated by the Session precondition for establishment of sessions initiated by the Session
Initiation Protocol (SIP). These preconditions require that the Initiation Protocol (SIP). These preconditions require that the
participant reserve network resources before continuing with the participant reserve network resources before continuing with the
session. The reservation of network resources are performed through a session. The reservation of network resources are performed through
signaling protocol such as RSVP. a signaling protocol such as RSVP.
Our example environment relies of [SIP-RSVP] to synchronize RSVP
bandwidth reservations with SIP. For example, the RSVP bandwidth
requests may be integrated into the call setup flow as follows (See
call setup flow diagram in Figure A2):
- Caller C1 initiates a call by sending a SIP INVITE to VoIP
gateway GW1, which passes the INVITE along to the call control
agent (CCA). The INVITE message may contain a list of codecs
that the calling phone can support.
- VoIP gateway GW2, chooses a compatible codec from the list and
responds with a SIP message 183 Session Progress.
- When GW1 receives the SIP response message with the SDP, it
determines how much bandwidth is required for the call.
- GW1 sends an RSVP Path message to PE1, requesting bandwidth for
the call.
- GW2 also sends an RSVP Path message to PE2.
- Assuming that the tunnel (from left to right) has sufficient
bandwidth, PE1 responds to GW1 with a Resv message
- Again assuming the tunnel (from right to left) has sufficient
bandwidth, PE2 responds to GW2 with a Resv message
- GW2 sends a SIP 200 OK message to GW1.
- GW1 sends a SIP UPDATE message to GW2.
- Upon receiving the UPDATE, GW2 sends the INVITE to the
destination phone, which responds with SIP message 180 RINGING.
- When (and if) the called party answers, the destination phone
responds with another SIP 200 OK which completes the connection
and tells the calling party that there is now reserved
bandwidth in both directions so that conversation can begin.
RSVP Aggregation over MPLS TE tunnels September 2006
- RTP media streams in both directions pass through the DSTE
tunnels as they traverse the MPLS network.
RSVP Aggregation over MPLS TE tunnels September 2006
IP-Phone/ IP-Phone/
TA-C1 GW1 PE1 CCA PE2 GW2 TA-C2
| INVITE|(SDP1) | INVITE | INVITE | | |
|---------->|-------|---------->|------------|------->| |
| 100|TRYING | | | | |
|<----------|-------|-----------| | | |
| 183|(SDP2) | | | | |
|<----------|-------|-----------|------------|--------| |
| | PATH | | | PATH | |
| |------>| | |<-------| |
| | RESV | | | RESV | |
| |<------| | |------->| |
| | | UPDATE|(SDP3) | | |
| |-------|-----------|------------|------->| |
| | | 200 OK|(SDP4) | | |
| |<------|-----------|------------|--------| INVITE |
| | | | | |---------->|
|180 RINGING| | 180|RINGING | |180 RINGING|
|<----------|<------|-----------|------------|--------|<----------|
| 200 OK | 200|OK | 200|OK | 200 OK |
|<----------|<------|-----------|<-----------|--------|<----------|
| | | | | | |
| | | DSTE|TUNNEL | | |
| RTP|MEDIA |-----------|------------| | |
|===========|=======|===========|============|========|==========>|
| | |-----------|------------| | |
| | | | | | |
| | |-----------|------------| | |
|<==========|=======|===========|============|========|===========|
| | |-----------|------------| | |
DSTE TUNNEL
Figure A2. VoIP QoS CAC using SIP with Preconditions
Through the collaboration between SIP resource management, RSVP Through the collaboration between SIP resource management, RSVP
signaling, RSVP Aggregation and DS-TE as described above, we see signaling, RSVP Aggregation and DS-TE as described above, we see
that: that:
a) the PE and GW collaborate to determine whether there is enough a) the PE and GW collaborate to determine whether there is enough
bandwidth on the tunnel between the calling and called GWs to bandwidth on the tunnel between the calling and called GWs to
accommodate the connection, accommodate the connection,
b) the corresponding accept/reject decision is communicated to the b) the corresponding accept/reject decision is communicated to the
GWs on a connection-by-connection basis, and GWs on a connection-by-connection basis, and
c) the PE can optimize network resources by dynamically adjusting
the bandwidth of each tunnel according to the load over that tunnel.
For example, if a tunnel is operating near capacity, the network may
dynamically adjust the tunnel size within a set of parameters.
RSVP Aggregation over MPLS TE tunnels September 2006 c) the PE can optimize network resources by dynamically adjusting
the bandwidth of each tunnel according to the load over that
tunnel. For example, if a tunnel is operating at near
capacity, the network may dynamically adjust the tunnel size
within a set of parameters.
We note that admission Control of voice calls over the core network We note that admission Control of voice calls over the core network
capacity is achieved in a hierarchical manner whereby: capacity is achieved in a hierarchical manner whereby:
- DSTE tunnels are subject to Admission Control over the
resources of the MPLS TE core - DSTE tunnels are subject to Admission Control over the resources
of the MPLS TE core
- Voice calls are subject to CAC over the DSTE tunnel bandwidth - Voice calls are subject to CAC over the DSTE tunnel bandwidth
This hierarchy is a key element in the scalability of this CAC This hierarchy is a key element in the scalability of this CAC
solution for voice calls over an MPLS Core. solution for voice calls over an MPLS Core.
It is also possible for the GWs to use aggregate RSVP reservations It is also possible for the GWs to use aggregate RSVP reservations
themselves instead of per-call RSVP reservations. For example, themselves instead of per-call RSVP reservations. For example,
instead of setting one reservation for each call GW1 has in place instead of setting one reservation for each call GW1 has in place
towards GW2, GW1 may establish one (or a small number of) aggregate toward GW2, GW1 may establish one (or a small number of) aggregate
reservations as defined in [RSVP-AGG] which is used for all (or a reservations as defined in [RSVP-AGG] or [RSVP-GEN-AGG], which is
subset of all) the calls towards GW2. This effectively provides an used for all (or a subset of all) the calls toward GW2. This
additional level of hierarchy whereby: effectively provides an additional level of hierarchy whereby:
-
DSTE tunnels are subject to Admission Control over the - DSTE tunnels are subject to Admission Control over the resources
resources of the MPLS TE core of the MPLS TE core
- Aggregate RSVP reservations (for the calls from one GW to - Aggregate RSVP reservations (for the calls from one GW to
another GW) are subject to Admission Control over the DSTE another GW) are subject to Admission Control over the DSTE
tunnels (as per the "RSVP Aggregation over TE Tunnels" tunnels (as per the "RSVP Aggregation over TE Tunnels"
procedures defined in this document) procedures defined in this document)
- Voice calls are subject to CAC by the GW over the aggregate - Voice calls are subject to CAC by the GW over the aggregate
reservation towards the appropriate destination GW. reservation toward the appropriate destination GW.
This pushes even further the scalability limits of this voice CAC This pushes even further the scalability limits of this voice CAC
architecture. architecture.
Contributing Authors
This document was the collective work of several authors. The text
and content were contributed by the editor and the co-authors listed
below.
Michael DiBiasio
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
EMail: dibiasio@cisco.com
Bruce Davie
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
EMail: bdavie@cisco.com
Christou Christou
Booz Allen Hamilton
8283 Greensboro Drive
McLean, VA 22102
USA
EMail: christou_chris@bah.com
Michael Davenport
Booz Allen Hamilton
8283 Greensboro Drive
McLean, VA 22102
USA
EMail: davenport_michael@bah.com
Jerry Ash
AT&T
200 Laurel Avenue
Middletown, NJ 07748
USA
EMail: gash@att.com
Bur Goode
AT&T
32 Old Orchard Drive
Weston, CT 06883
USA
EMail: bgoode@att.com
Editor's Address
Francois Le Faucheur
Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
06410 Biot Sophia-Antipolis
France
EMail: flefauch@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 198 change blocks. 
794 lines changed or deleted 594 lines changed or added

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