draft-ietf-tsvwg-rsvp-dste-02.txt   draft-ietf-tsvwg-rsvp-dste-03.txt 
RSVP Aggregation over MPLS TE tunnels February 2006
Internet Draft Francois Le Faucheur Internet Draft Francois Le Faucheur
Michael DiBiasio Editor
Bruce Davie
Cisco Systems, Inc. Cisco Systems, Inc.
Michael Davenport draft-ietf-tsvwg-rsvp-dste-03.txt
Chris Christou
Booz Allen Hamilton
Jerry Ash
Bur Goode
AT&T
draft-ietf-tsvwg-rsvp-dste-02.txt
Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 2, line 4 skipping to change at page 1, line 36
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
RFC 3175 specifies aggregation of RSVP end-to-end reservations over RFC 3175 specifies aggregation of RSVP end-to-end reservations over
aggregate RSVP reservations. This document specifies aggregation of aggregate RSVP reservations. This document specifies aggregation of
RSVP end-to-end reservations over MPLS Traffic Engineering (TE) RSVP end-to-end reservations over MPLS Traffic Engineering (TE)
RSVP Aggregation over MPLS TE tunnels February 2006
tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE) tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE)
Tunnels. This approach is based on RFC 3175 and simply modifies the Tunnels. This approach is based on RFC 3175 and simply modifies the
corresponding procedures for operations over MPLS TE tunnels instead corresponding procedures for operations over MPLS TE tunnels instead
of aggregate RSVP reservations. This approach can be used to achieve of aggregate RSVP reservations. This approach can be used to achieve
admission control of a very large number of flows in a scalable admission control of a very large number of flows in a scalable
manner since the devices in the core of the network are unaware of manner since the devices in the core of the network are unaware of
the end-to-end RSVP reservations and are only aware of the MPLS TE the end-to-end RSVP reservations and are only aware of the MPLS TE
tunnels. tunnels.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Specification of Requirements Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1. Introduction Table of Contents
1. Introduction...................................................2
2. Contributing Authors...........................................6
3. Definitions....................................................7
4. Operations of RSVP Aggregation over TE with pre-established
Tunnels...........................................................8
4.1. Reference Model...........................................9
4.2. Receipt of E2E Path message By the Aggregator............10
4.3. Handling of E2E Path message By Transit LSRs.............11
4.4. Receipt of E2E Path Message by Deaggregator..............11
4.5. Handling of E2E Resv Message by Deaggregator.............12
4.6. Handling of E2E Resv Message by the Aggregator...........13
4.7. Forwarding of E2E traffic by Aggregator..................14
4.8. Removal of E2E reservations..............................14
4.9. Removal of TE Tunnel.....................................15
4.10. Example Signaling Flow..................................16
5. IPv4 and IPv6 Applicability...................................17
6. E2E Reservations Applicability................................17
7. Example Deployment Scenarios..................................17
7.1. Voice and Video Reservations Scenario....................17
7.2. PSTN/3G Voice Trunking Scenario..........................18
8. Optional Use of RSVP Proxy on RSVP Aggregator.................19
9. Security Considerations.......................................21
10. IANA Considerations..........................................22
11. Acknowledgments..............................................22
12. Normative References.........................................22
13. Informative References.......................................23
14. Editor's Address:............................................24
Appendix A - Example Usage of RSVP Aggregation over DSTE Tunnels for
VoIP Call Admission Control (CAC)................................25
1. Introduction
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 which 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 explicitely 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],
skipping to change at page 3, line 4 skipping to change at page 3, line 31
codepoint (DSCP) in the packet IP header. At each Diffserv router, codepoint (DSCP) in the packet IP header. At each Diffserv router,
packets are subjected to a "per-hop behavior" (PHB), which is invoked packets are subjected to a "per-hop behavior" (PHB), which is invoked
by the DSCP. The primary benefit of Diffserv is its scalability. by the DSCP. The primary benefit of Diffserv is its scalability.
Diffserv eliminates the need for per-flow state and per-flow Diffserv eliminates the need for per-flow state and per-flow
processing and therefore scales well to large networks. 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 [INT-DIFF],
significant benefits can be achieved by using Intserv over Diffserv significant benefits can be achieved by using Intserv over Diffserv
including resource based admission control, policy based admission including resource based admission control, policy based admission
RSVP Aggregation over MPLS TE tunnels February 2006
control, assistance in traffic identification /classification and control, assistance in traffic identification /classification and
traffic conditioning. As discussed in [INT-DIFF], Intserv can operate traffic conditioning. As discussed in [INT-DIFF], Intserv can operate
over Diffserv in multiple ways. For example, the Diffserv region may over Diffserv in multiple ways. For example, the Diffserv region may
be statically provisioned or may be RSVP aware. When it is RSVP aware, be statically provisioned or may be RSVP aware. When it is RSVP aware,
several mechanisms may be used to support dynamic provisioning and several mechanisms may be used to support dynamic provisioning and
topology aware admission control including aggregate RSVP topology aware admission control including aggregate RSVP
reservations, per flow RSVP or a bandwidth broker. The advantage of reservations, per flow RSVP or a bandwidth broker. The advantage of
using aggregate RSVP reservations is that it offers dynamic, using aggregate RSVP reservations is that it offers dynamic,
topology-aware admission control over the Diffserv region without topology-aware admission control over the Diffserv region without
per-flow reservations and the associated level of RSVP signaling in per-flow reservations and the associated level of RSVP signaling in
skipping to change at page 3, line 37 skipping to change at page 4, line 12
"aggregation region", can be mapped onto a single aggregate "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
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 belonging
to aggregate reservations is classified in the data path purely using to aggregate reservations is classified in the data path purely using
Diffserv marking. 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 can
be established using RSVP-TE signaling. . MPLS TE uses Constraint be established using RSVP-TE signaling. MPLS TE uses Constraint Based
Based Routing to compute the path for a TE tunnel. Then, Admission Routing to compute the path for a TE tunnel. Then, Admission Control
Control is performed during the establishment of TE Tunnels to ensure is performed during the establishment of TE Tunnels to ensure they
they are granted their requested resources. 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, Diff-Serv-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 enforced
for these different classes. [DSTE-PROTO] specifies RSVP-TE signaling for these different classes. [DSTE-PROTO] specifies RSVP-TE signaling
extensions as well as OSPF and ISIS extensions for support of DS-TE. extensions as well as OSPF and ISIS 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 DS-
TE tunnels simply as "TE tunnels". 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]:
- a TE tunnel is subject to Admission Control and thus is - a TE tunnel is subject to Admission Control and thus is
effectively an aggregate bandwidth reservation effectively an aggregate bandwidth reservation
RSVP Aggregation over MPLS TE tunnels February 2006
- In the data plane, packet scheduling relies exclusively on - In the data plane, packet scheduling relies exclusively on
Diff-Serv classification and PHBs Diff-Serv 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 Deaggregator in the case of aggregate RSVP reservations and 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 [RSVP-
TE] and [DSTE-PROTO] respectively for TE tunnels and DS-TE TE] and [DSTE-PROTO] respectively for TE tunnels and DS-TE
tunnels). tunnels).
skipping to change at page 4, line 46 skipping to change at page 5, line 21
with RSVP-TE and reserve resources at every hop, this can be looked with RSVP-TE and reserve resources at every hop, this can be looked
at as a form of aggregation of RSVP(-TE) reservations over MPLS TE at as a form of aggregation of RSVP(-TE) reservations over MPLS TE
Tunnels. This document capitalizes on the similarities between Tunnels. This document capitalizes on the similarities between
nesting of TE LSPs over TE tunnels and RSVP aggregation over TE nesting of TE LSPs over TE tunnels and RSVP aggregation over TE
tunnels and reuses the procedures of [LSP-HIER] wherever possible. 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 - Whereas RFC 2746 describes operation with IP tunnels, this
draft describes operation over MPLS tunnels. One consequence of document describes operation over MPLS tunnels. One consequence
this difference is the need to deal with penultimate hop of this difference is the need to deal with penultimate hop
popping (PHP). 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
draft. document.
- There is exactly one reservation per MPLS-TE tunnel, whereas - There is exactly one reservation per MPLS-TE tunnel, whereas
RFC 2746 permits many reservations per tunnel. RFC 2746 permits many reservations per tunnel.
- We have assumed in the current document that a given MPLS-TE
RSVP Aggregation over MPLS TE tunnels February 2006
- We have assumed in the current draft 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 - There may be several MPLS-TE tunnels that share common head and
tail end routers, with head-end policy determining which tunnel tail end routers, with head-end policy determining which tunnel
is appropriate for a particular flow. This scenario does not is appropriate for a particular flow. This scenario does not
appear to be addressed in RFC 2746. appear to be addressed in RFC 2746.
At the same time, this draft 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 RFC
2746: 2746:
" "
The (logical) link may be able to promise that some overall The (logical) link may be able to promise that some overall
level of resources is available to carry traffic, but not to level of resources is available to carry traffic, but not to
allocate resources specifically to individual data flows. 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] with the benefits of MPLS including the
skipping to change at page 6, line 5 skipping to change at page 6, line 32
- the aggregate reservation (and thus the traffic from the - the aggregate reservation (and thus the traffic from the
corresponding end to end reservations) can be network corresponding end to end reservations) can be network
engineered via the use of Constraint based routing (e.g. engineered via the use of Constraint based routing (e.g.
affinity, optimization on different metrics) and when needed affinity, optimization on different metrics) and when needed
can take advantage of resources on other paths than the can take advantage of resources on other paths than the
shortest path shortest path
- the aggregate reservations (and thus the traffic from the - the aggregate reservations (and thus the traffic from the
corresponding end to end reservations) can be protected against corresponding end to end reservations) can be protected against
failure through the use of MPLS Fast Reroute failure through the use of MPLS Fast Reroute
RSVP Aggregation over MPLS TE tunnels February 2006
This document, like [RSVP-AGG], covers aggregation of unicast This document, like [RSVP-AGG], covers aggregation of unicast
sessions. Aggregation of multicast sessions is for further study. sessions. Aggregation of multicast sessions is for further study.
1.1. Changes from previous versions 2. Contributing Authors
The changes from version draft-ietf-tsvwg-rsvp-dste-01 to version This document was the collective work of several authors. The text
draft-ietf-tsvwg-rsvp-dste-02 are: and content were contributed by the editor and the co-authors listed
- clarification in text describing handling of E2E Path below. (The contact information for the editor appears in the
- added text on handling of E2E PathTear and ResvConf. Editor's Address section.)
The changes from version draft-ietf-tsvwg-rsvp-dste-00 to version Michael DiBiasio
draft-ietf-tsvwg-rsvp-dste-01 of this draft address comments from the Cisco Systems, Inc.
"RSVP Review team" and from the Working Group Last Call. The 300 Beaver Brook Road
significant changes are: Boxborough, MA 01719
- added text in multiple sub-sections of section 3 to describe USA
operations when the Aggregator and Deaggregator also behave as Email: dibiasio@cisco.com
IPsec security gateways.
- added text in section 3 to further clarify relationship with
[LSP-HIER]
- added text in section 8 to refer to some security
considerations of [LSP-HIER] which are applicable to this
document
- edits in section 3.2 about forwarding of E2E path
- edits in section 3.4 about processing of E2E Path
- edits in section 3.6 to describe operations in case of TE
tunnel mapping change
- added section 3.7 to clarify forwarding of E2E traffic by
Aggregator
- cleaned up usage of MUST/SHOULD/MAY
- clarifications and editorials.
The significant changes from version draft-lefaucheur-rsvp-dste-02 Bruce Davie
to version draft-ietf-tsvwg-rsvp-dste-00 of this draft were: Cisco Systems, Inc.
- added a SHOULD for use of Make-Before-Break when resizing TE
tunnel
- added clarification text about E2E Resv hiding from Transit
LSRs
- added reference to [RSVP-GEN-AGG] in section 5.
- added definition of E2E reservation in section 2.
- removed the case where E2E reservation is a TE tunnel (already
covered in [LSP-HIER])
The significant changes from version draft-lefaucheur-rsvp-dste-01 to 300 Beaver Brook Road
version draft-lefaucheur-rsvp-dste-02 of this draft were: Boxborough, MA 01719
- Alignment with RSVP operations of draft-ietf-mpls-lsp-hierarchy USA
- Addition of an appendix providing an example usage scenario for Email: bdavie@cisco.com
information purposes
RSVP Aggregation over MPLS TE tunnels February 2006 Christou Christou
Booz Allen Hamilton
8283 Greensboro Drive
McLean, VA 22102
USA
Email: christou_chris@bah.com
The significant changes from version draft-lefaucheur-rsvp-dste-00 to Michael Davenport
version draft-lefaucheur-rsvp-dste-01 of this draft were: Booz Allen Hamilton
- added discussion of the relationship to RFC 2746 [RSVP-TUN] 8283 Greensboro Drive
- added discussion of mapping policy at aggregator McLean, VA 22102
- added discussion of "RSVP proxy" behavior in conjunction with USA
the aggregation scheme described here Email: davenport_michael@bah.com
- added discussion on TTL processing on Deaggregator
2. Definitions Jerry Ash
AT&T
200 Laurel Avenue
Middletown, NJ 07748, USA
USA
Email: gash@att.com
Bur Goode
AT&T
32 Old Orchard Drive
Weston, CT 06883
USA
Email: bgoode@att.com
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 router
at the ingress edge of the aggregation region (with at the ingress edge of the aggregation region (with
respect to the end to end RSVP reservation) and respect to the end to end RSVP reservation) and
behaving in accordance with [RSVP-AGG]. In this behaving in accordance with [RSVP-AGG]. In this
document, it is also the TE Tunnel Head-end. document, it is also the TE Tunnel Head-end.
skipping to change at page 7, line 48 skipping to change at page 8, line 27
(ii) corresponding Resv messages are initiated (ii) corresponding Resv messages are initiated
downstream of the Deaggregator and downstream of the Deaggregator and
terminated upstream of the Aggregator, and terminated upstream of the Aggregator, and
(iii) this RSVP reservation is to be aggregated (iii) this RSVP reservation is to be aggregated
over an MPLS TE tunnel between the over an MPLS TE tunnel between the
Aggregator and Deaggregator. Aggregator and Deaggregator.
An E2E RSVP reservation may be a per-flow An E2E RSVP reservation may be a per-flow
reservation. Alternatively, the E2E reservation reservation. Alternatively, the E2E reservation
may itself be an aggregate reservation of various may itself be an aggregate reservation of various
types (e.g. Aggregate IP reservation, Aggregate types (e.g. Aggregate IP reservation, Aggregate
IPsec reservation). See section 4 and 5 for more IPsec reservation). See section 5 and 6 for more
details on the types of E2E RSVP reservations. As details on the types of E2E RSVP reservations. As
per regular RSVP operations, E2E RSVP reservations per regular RSVP operations, E2E RSVP reservations
are unidirectional. are unidirectional.
RSVP Aggregation over MPLS TE tunnels February 2006
Head-end Head-end
This is the Label Switch Router responsible for This is the Label Switch Router responsible for
establishing, maintaining and tearing down a given TE establishing, maintaining and tearing down a given TE
tunnel. tunnel.
Tail-end Tail-end
This is the Label Switch Router responsible for This is the Label Switch Router responsible for
terminating a given TE tunnel terminating a given TE tunnel
Transit LSR This is a Label Switch router that is on the path of a Transit LSR This is a Label Switch router that is on the path of a
given TE tunnel and is neither the Head-end nor the given TE tunnel and is neither the Head-end nor the
Tail-end Tail-end
3. Operations of RSVP Aggregation over TE with pre-established Tunnels 4. Operations of RSVP Aggregation over TE with pre-established Tunnels
[RSVP-AGG] supports operations both in the case where aggregate RSVP [RSVP-AGG] supports operations both in the case where aggregate RSVP
reservations are pre-established and in the case where Aggregators reservations are pre-established and in the case where Aggregators
and Deaggregators have to dynamically discover each other and and Deaggregators have to dynamically discover each other and
dynamically establish the necessary aggregate RSVP reservations. 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 in the case where
the tunnels need to be dynamically established. the tunnels need to be dynamically established.
skipping to change at page 9, line 4 skipping to change at page 9, line 35
The signaling aspects discussed in section 6.2 of [LSP-HIER] apply to The signaling aspects discussed in section 6.2 of [LSP-HIER] apply to
the establishment/termination of the aggregate TE tunnels when this the establishment/termination of the aggregate TE tunnels when this
is triggered by GMPLS mechanisms (e.g. as a result of an end-to-end is triggered by GMPLS mechanisms (e.g. as a result of an end-to-end
TE LSP establishment request received at the aggregation boundary) . TE LSP establishment request received at the aggregation boundary) .
As this document assumes pre-established tunnels, those aspects are As this document assumes pre-established tunnels, those aspects are
not relevant here. The signaling aspects discussed in section 6.1 of not relevant here. The signaling aspects discussed in section 6.1 of
[LSP-HIER] relate to the establishment/maintenance of the end-to-end [LSP-HIER] relate to the establishment/maintenance of the end-to-end
TE LSPs over the aggregate TE tunnel. This document describes how to TE LSPs over the aggregate TE tunnel. This document describes how to
use the same procedures as those specified in section 6.1 of [LSP- use the same procedures as those specified in section 6.1 of [LSP-
HIER], but for the establishment of end-to-end RSVP reservations HIER], but for the establishment of end-to-end RSVP reservations
RSVP Aggregation over MPLS TE tunnels February 2006
(instead of end-to-end TE LSPs) over the TE tunnels. This is covered (instead of end-to-end TE LSPs) over the TE tunnels. This is covered
further in section 3 of the present document. 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.
3.1. Reference Model 4.1. Reference Model
I----I I----I I----I I----I
H--I R I\ I-----I I------I /I R I--H H--I R I\ I-----I I------I /I R I--H
H--I I\\I I I---I I I//I I--H H--I I\\I I I---I I I//I I--H
I----I \I He/ I I T I I Te/ I/ I----I I----I \I He/ I I T I I Te/ I/ I----I
I Agg I=======================I Deag I I Agg I=======================I Deag I
/I I I I I I\ /I I I I I I\
H--------//I I I---I I I\\--------H H--------//I I I---I I I\\--------H
H--------/ I-----I I------I \--------H H--------/ I-----I I------I \--------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
3.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 processing of this E2E path message augmented with the extensions
documented in this section. 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 Aggregation over MPLS TE tunnels February 2006
RSVP preemption priority and the MPLS TE Tunnel set-up and/or hold RSVP preemption priority and the MPLS TE Tunnel set-up 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 towards 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
skipping to change at page 11, line 4 skipping to change at page 11, line 34
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], the IP Protocol number need not be
modified to "RSVP-E2E-IGNORE"; it MUST be left as is (indicating modified to "RSVP-E2E-IGNORE"; it MUST be left as is (indicating
"RSVP") by the Aggregator. "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
RSVP Aggregation over MPLS TE tunnels February 2006
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.
3.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.
3.4. Receipt of E2E Path Message by Deaggregator 4.4. Receipt of E2E Path Message by Deaggregator
On receipt of the E2E Path message addressed to it, the Deaggregator On receipt of the E2E Path message addressed to it, the Deaggregator
will notice that the IP Protocol number is set to "RSVP" and will will notice that the IP Protocol number is set to "RSVP" and will
thus perform RSVP processing of the E2E Path message. 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. 2. Find the "other end" of the above data interface, say X.
skipping to change at page 12, line 5 skipping to change at page 12, line 36
The Deaggregator MUST forward the E2E Path downstream towards the The Deaggregator MUST forward the E2E Path downstream towards 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 Deaggregator
also sets the Router Alert. 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.
RSVP Aggregation over MPLS TE tunnels February 2006 4.5. Handling of E2E Resv Message by Deaggregator
3.5. Handling of E2E Resv Message by 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-by-
hop towards the sender. hop towards the sender.
On receipt of the E2E Resv, the Deaggregator MUST follow traditional On receipt of the E2E Resv, the Deaggregator MUST follow traditional
RSVP procedures on receipt of the E2E Resv message. This includes RSVP procedures on receipt of the E2E Resv message. This includes
performing admission control for the segment downstream of the performing admission control for the segment downstream of the
Deaggregator and forwarding the E2E Resv message to the PHOP signaled Deaggregator and forwarding the E2E Resv message to the PHOP signaled
earlier in the E2E Path message and which identifies the Aggregator. earlier in the E2E Path message and which identifies the Aggregator.
Since the E2E Resv message is directly addressed to 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 and does not carry the Router Alert option (as per traditional RSVP
Resv procedures), the E2E Resv message is hidden from the routers Resv procedures), the E2E Resv message is hidden from the routers
between the Deaggregator and the Aggregator which, therefore, handle between the Deaggregator and the Aggregator which, therefore, handle
the E2E Resv message as a regular IP packet. 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.
3.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 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
[RFC2205] to determine the resource requirements from the Sender [RSVP] to determine the resource requirements from the Sender Tspec
Tspec and the Flowspec contained in the Resv. Then it compares the and the Flowspec contained in the Resv. Then it compares the resource
resource request with the available resources of the selected TE request with the available resources of the selected TE tunnel.
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.
RSVP Aggregation over MPLS TE tunnels February 2006
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 re-
sizing of the aggregate reservation (in this case, the TE tunnel.) 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
skipping to change at page 13, line 52 skipping to change at page 14, line 33
successful the E2E Resv message is generated upstream towards the successful the E2E Resv message is generated upstream towards the
sender. sender.
On receipt of an E2E ResvConf from the Aggregator, the Deaggregator On 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 towards 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.
3.7. Forwarding of E2E traffic by Aggregator 4.7. Forwarding of E2E traffic by Aggregator
RSVP Aggregation over MPLS TE tunnels February 2006
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.
3.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
resources available on the corresponding TE tunnel accordingly. resources available on the corresponding TE tunnel accordingly.
3.9. Removal of TE Tunnel 4.9. Removal of 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 no suitable tunnel exists. In case the Path messages are forwarded
onto another tunnel which terminates on a different Deaggregator, or onto another tunnel which terminates on a different Deaggregator, or
the reservation is torn-down via Path Error messages, the reservation the reservation is torn-down via Path Error messages, the reservation
state established on the router acting as the Deaggregator before the state established on the router acting as the Deaggregator before the
TE tunnel went away, will time out since it will no longer be TE tunnel went away, will time out since it will no longer be
refreshed. refreshed.
RSVP Aggregation over MPLS TE tunnels February 2006 4.10. Example Signaling Flow
3.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 4 skipping to change at page 17, line 4
(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 towards 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 February 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.
4. 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.
5. 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].
6. Example Deployment Scenarios 7. Example Deployment Scenarios
6.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 very
high numbers of hosts. In the example illustrated below, hosts high numbers of hosts. In the example illustrated below, hosts
generate end-to-end per-flow reservations for each of their video generate end-to-end per-flow reservations for each of their video
streams associated with a video-conference, each of their audio streams associated with a video-conference, each of their audio
streams associated with a video-conference and each of their voice streams associated with a video-conference and each of their voice
calls. These reservations are aggregated over MPLS DS-TE tunnels over calls. These reservations are aggregated over MPLS DS-TE tunnels over
RSVP Aggregation over MPLS TE tunnels February 2006
the packet core. The mapping policy defined by the user maybe that the packet core. The mapping policy defined by the user maybe that
all the reservations for audio and voice streams are mapped onto DS- all the reservations for audio and voice streams are mapped onto DS-
TE tunnels of Class-Type 1 while reservations for video streams are 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.
------ ------ ------ ------
I H I# ------- -------- #I H I I H I# ------- -------- #I H I
I I\#I I ----- I I#/I I I I\#I I ----- I I#/I I
-----I \I Agg I I T I I Deag I/ ------ -----I \I Agg I I T I I Deag I/ ------
I I==========================I I I I==========================I I
skipping to change at page 17, line 32 skipping to change at page 18, line 29
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
6.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 towards 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 current number of calls). In turn, these
reservations may be aggregated over MPLS TE tunnels over the packet reservations may be aggregated over MPLS TE tunnels over the packet
core so that tunnel Head-ends act as Aggregators and perform 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 scenario is illustrated below: This scenario is illustrated below:
RSVP Aggregation over MPLS TE tunnels February 2006
------ ------ ------ ------
I GW I\ ------- -------- /I GW I I GW I\ ------- -------- /I GW I
I I\\I I ----- I I//I I I I\\I I ----- I I//I I
-----I \I Agg I I T I I Deag I/ ------ -----I \I Agg I I T I I Deag I/ ------
I I==========================I I I I==========================I I
------ /I I I I I I\ ------ ------ /I I I I I I\ ------
I GW I//I I ----- I I\\I GW I I GW I//I I ----- I I\\I GW I
I I/ ------- -------- \I I I I/ ------- -------- \I I
------ ------ ------ ------
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
7. Optional Use of RSVP Proxy on RSVP Aggregator 8. 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-PROXY], [L-RSVP]) have been, or are
being, discussed in the IETF in order to allow a network node to being, discussed in the IETF in order to allow a network node to
behave as an RSVP proxy which: 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
skipping to change at page 19, line 4 skipping to change at page 20, line 4
"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 node
doing the proxy i.e. the proxying node should act as if it had 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
RSVP Aggregation over MPLS TE tunnels February 2006
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).
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:
skipping to change at page 20, line 4 skipping to change at page 21, line 4
(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 towards Host for reservation in return direction. The actual trigger
for this depends on the actual RSVP proxy solution. As an example, for this depends on the actual RSVP proxy solution. As an example,
(3) and (iii) may simply be triggered respectively by (1) and (i). (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, if
the [L-RSVP] approach was used instead of [RSVP-PROXY], an additional the [L-RSVP] approach was used instead of [RSVP-PROXY], an additional
PathRequest message would be needed from host to PathRequest message would be needed from host to
RSVP Aggregation over MPLS TE tunnels February 2006
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.
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 which
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) that:
(i) admission control and resource reservation is performed on (i) admission control and resource reservation is performed on
skipping to change at page 20, line 33 skipping to change at page 21, line 30
(ii) this is achieved in both direction (ii) this is achieved in both direction
(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 pre-conditions for voice call establishment), are pre-conditions for voice call establishment),
particularly in the case where the MPLS TE tunnels span particularly in the case where the MPLS TE tunnels span
long distances with high propagation delays. long distances with high propagation delays.
8. Security Considerations 9. Security Considerations
The security issues inherent to the use of RSVP, RSVP Aggregation and The security issues inherent to the use of RSVP, RSVP Aggregation and
MPLS TE apply. Those can be addressed as discussed in [RSVP], [RSVP- MPLS TE apply. Those can be addressed as discussed in [RSVP], [RSVP-
AGG] and [RSVP-TE]. AGG] and [RSVP-TE].
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 applicable
to the present document. to the present document.
skipping to change at page 21, line 5 skipping to change at page 22, line 5
TE tunnels based on the current level of reservation, there are risks TE tunnels based on the current level of reservation, there are risks
that the TE tunnels used for RSVP aggregation hog resources in the that the TE tunnels used for RSVP aggregation hog resources in the
core which could prevent other TE Tunnels from being established. core which could prevent other TE Tunnels from being established.
There are also potential risks that such resizing results in There are also potential risks that such resizing results in
significant computation and signaling as well as churn on tunnel significant computation and signaling as well as churn on tunnel
paths. Such risks can be mitigated by configuration options allowing paths. Such risks can be mitigated by configuration options allowing
control of TE tunnel dynamic resizing (maximum Te tunnel size, control of TE tunnel dynamic resizing (maximum Te tunnel size,
maximum resizing frequency,...) and/or possibly by the use of TE maximum resizing frequency,...) and/or possibly by the use of TE
preemption. preemption.
RSVP Aggregation over MPLS TE tunnels February 2006
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 10. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
10. Acknowledgments 11. Acknowledgments
This document builds on the [RSVP-AGG], [RSVP-TUN] and [LSP-HIER] This document builds on the [RSVP-AGG], [RSVP-TUN] and [LSP-HIER]
specifications. Also, we would like to thank Tom Phelan, John Drake, specifications. Also, we would like to thank Tom Phelan, John Drake,
Arthi Ayyangar, Fred Baker, Subha Dhesikan, Kwok-Ho Chan, Carol Arthi Ayyangar, Fred Baker, Subha Dhesikan, Kwok-Ho Chan, Carol
Iturralde and James Gibson for their input into this document. Iturralde and James Gibson for their input into this document.
11. Normative References 12. Normative References
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate [RFC2119] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, RFC2119, March 1997. Requirement Levels, RFC2119, March 1997.
[RFC3668] S. Bradner, Intellectual Property Rights in IETF Technology, [RFC3668] S. Bradner, Intellectual Property Rights in IETF Technology,
RFC 3668, February 2004. RFC 3668, February 2004.
[BCP-78], S. Bradner, IETF Rights in Contributions, RFC3978, March [BCP-78], S. Bradner, IETF Rights in Contributions, RFC3978, March
2005. 2005.
skipping to change at page 22, line 5 skipping to change at page 23, line 5
[DIFFSERV] Blake et al., An Architecture for Differentiated Services, [DIFFSERV] Blake et al., An Architecture for Differentiated Services,
RFC 2475 RFC 2475
[INT-DIFF] A Framework for Integrated Services Operation over [INT-DIFF] A Framework for Integrated Services Operation over
Diffserv Networks, RFC 2998, November 2000. Diffserv Networks, RFC 2998, November 2000.
[RSVP-AGG] Baker et al, Aggregation of RSVP for IPv4 and IPv6 [RSVP-AGG] Baker et al, Aggregation of RSVP for IPv4 and IPv6
Reservations, RFC 3175, September 2001. Reservations, RFC 3175, September 2001.
RSVP Aggregation over MPLS TE tunnels February 2006
[MPLS-TE] Awduche et al., "Requirements for Traffic Engineering over [MPLS-TE] Awduche et al., "Requirements for Traffic Engineering over
MPLS", RFC 2702, September 1999. MPLS", RFC 2702, September 1999.
[RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels, [RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels,
RFC 3209, December 2001. RFC 3209, December 2001.
[DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of [DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of
Diff-Serv-aware MPLS Traffic Engineering, RFC 4124, June 2005. Diff-Serv-aware MPLS Traffic Engineering, RFC 4124, June 2005.
[LSP-HIER] Kompella et al, Label Switched Paths (LSP) Hierarchy with [LSP-HIER] Kompella et al, Label Switched Paths (LSP) Hierarchy with
Generalized Multi-Protocol Label Switching (GMPLS) Traffic Generalized Multi-Protocol Label Switching (GMPLS) Traffic
Engineering (TE), RFC 4206, October 2005 Engineering (TE), RFC 4206, October 2005
[SEC-ARCH] Kent and Seo, Security Architecture for the Internet [SEC-ARCH] Kent and Seo, Security Architecture for the Internet
Protocol, RFC 4301, December 2005 Protocol, RFC 4301, December 2005
12. Informative References 13. Informative References
[DIFF-MPLS] Le Faucheur et al, MPLS Support of Diff-Serv, RFC3270, [DIFF-MPLS] Le Faucheur et al, MPLS Support of Diff-Serv, RFC3270,
May 2002. May 2002.
[DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv-
aware MPLS Traffic Engineering, RFC3564, July 2003. aware MPLS Traffic Engineering, RFC3564, July 2003.
[6PE] De Clercq et al, Connecting IPv6 Islands over IPv4 MPLS using [6PE] De Clercq et al, Connecting IPv6 Islands over IPv4 MPLS using
IPv6 Provider Edge Routers (6PE), work in progress IPv6 Provider Edge Routers (6PE), work in progress
skipping to change at page 23, line 5 skipping to change at page 24, line 5
[L-RSVP] Manner et al., Localized RSVP, draft-manner-lrsvp-04.txt, [L-RSVP] Manner et al., Localized RSVP, draft-manner-lrsvp-04.txt,
work in progress. work in progress.
[RSVP-PROXY] Gai et al., RSVP Proxy, draft-ietf-rsvp-proxy-03.txt [RSVP-PROXY] Gai et al., RSVP Proxy, draft-ietf-rsvp-proxy-03.txt
(expired), work in progress. (expired), work in progress.
[RSVP-APPID] Bernet et al., Identity Representation for RSVP, RFC [RSVP-APPID] Bernet et al., Identity Representation for RSVP, RFC
3182. 3182.
RSVP Aggregation over MPLS TE tunnels February 2006
[AUTOMESH] Vasseur and Leroux, Routing extensions for discovery of [AUTOMESH] Vasseur and Leroux, Routing extensions for discovery of
Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering
(TE) mesh membership, draft-vasseur-ccamp-automesh-00.txt, work in (TE) mesh membership, draft-vasseur-ccamp-automesh-00.txt, work in
progress. progress.
[SIP-RSVP] Camarillo, Integration of Resource Management and Session [SIP-RSVP] Camarillo, Integration of Resource Management and Session
Initiation Protocol (SIP), RFC 3312 Initiation Protocol (SIP), RFC 3312
13. Authors Address: 14. Editor's Address:
Francois Le Faucheur Francois Le Faucheur
Cisco Systems, Inc. Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3 Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille 400, Avenue de Roumanille
06410 Biot Sophia-Antipolis 06410 Biot Sophia-Antipolis
France France
Email: flefauch@cisco.com Email: flefauch@cisco.com
Michael DiBiasio IPR Statements
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
RSVP Aggregation over MPLS TE tunnels February 2006
USA
Email: davenport_michael@bah.com
Jerry Ash
AT&T
200 Laurel Avenue
Middletown, NJ 07748, USA
USA
Email: gash@att.com
Bur Goode
AT&T
32 Old Orchard Drive
Weston, CT 06883
USA
Email: bgoode@att.com
14. IPR Statements
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 24, line 48 skipping to change at page 24, line 47
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. this standard.
Please address the information to the IETF at ietf-ipr@ietf.org. Please address the information to the IETF at ietf-ipr@ietf.org.
15. Disclaimer of Validity Disclaimer of Validity
RSVP Aggregation over MPLS TE tunnels February 2006
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
16. Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Appendix A - Example Usage of RSVP Aggregation over DSTE Tunnels for Appendix A - 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.
skipping to change at page 26, line 5 skipping to change at page 26, line 7
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.
The bandwidth request takes into account VoIP header compression, The bandwidth request takes into account VoIP header compression,
where applicable. As part of its Aggregator role, the PE router where applicable. As part of its Aggregator role, the PE router
effectively performs admission control of the bandwidth request effectively performs admission control of the bandwidth request
generated by the GW onto the resources of the corresponding DS-TE generated by the GW onto the resources of the corresponding DS-TE
tunnel. tunnel.
RSVP Aggregation over MPLS TE tunnels February 2006
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 further.
Rather, the PE performs admission control of the bandwidth signaled Rather, the PE performs admission control of the bandwidth signaled
in the Path message over the DSTE tunnel towards the destination. in the Path message over the DSTE tunnel towards the destination.
Assuming there is enough bandwidth available on that tunnel, the PE Assuming there is enough bandwidth available on that tunnel, the PE
adjusts its book-keeping of remaining available bandwidth on the adjusts its book-keeping of remaining available bandwidth on the
tunnel and generates a Resv message back towards the GW to confirm tunnel and generates a Resv message back towards the GW to confirm
resources have been reserved over the DSTE tunnel. resources have been reserved over the DSTE tunnel.
skipping to change at page 27, line 4 skipping to change at page 27, line 6
| '`''' | | '`''' |
C1 C2 C1 C2
Figure A1. Integration of SIP Resource Management, DSTE Figure A1. Integration of SIP Resource Management, DSTE
and RSVP Aggregation 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
RSVP Aggregation over MPLS TE tunnels February 2006
session. The reservation of network resources are performed through a session. The reservation of network resources are performed through a
signaling protocol such as RSVP. signaling protocol such as RSVP.
Our example environment relies of [SIP-RSVP] to synchronize RSVP Our example environment relies of [SIP-RSVP] to synchronize RSVP
bandwidth reservations with SIP. For example, the RSVP bandwidth bandwidth reservations with SIP. For example, the RSVP bandwidth
requests may be integrated into the call setup flow as follows (See requests may be integrated into the call setup flow as follows (See
call setup flow diagram in Figure A2): call setup flow diagram in Figure A2):
- Caller C1 initiates a call by sending a SIP INVITE to VoIP - Caller C1 initiates a call by sending a SIP INVITE to VoIP
gateway GW1, which passes the INVITE along to the call control gateway GW1, which passes the INVITE along to the call control
skipping to change at page 28, line 5 skipping to change at page 28, line 5
destination phone, which responds with SIP message 180 RINGING. destination phone, which responds with SIP message 180 RINGING.
- When (and if) the called party answers, the destination phone - When (and if) the called party answers, the destination phone
responds with another SIP 200 OK which completes the connection responds with another SIP 200 OK which completes the connection
and tells the calling party that there is now reserved and tells the calling party that there is now reserved
bandwidth in both directions so that conversation can begin. bandwidth in both directions so that conversation can begin.
- RTP media streams in both directions pass through the DSTE - RTP media streams in both directions pass through the DSTE
tunnels as they traverse the MPLS network. tunnels as they traverse the MPLS network.
RSVP Aggregation over MPLS TE tunnels February 2006
IP-Phone/ IP-Phone/ IP-Phone/ IP-Phone/
TA-C1 GW1 PE1 CCA PE2 GW2 TA-C2 TA-C1 GW1 PE1 CCA PE2 GW2 TA-C2
| INVITE|(SDP1) | INVITE | INVITE | | | | INVITE|(SDP1) | INVITE | INVITE | | |
|---------->|-------|---------->|------------|------->| | |---------->|-------|---------->|------------|------->| |
| 100|TRYING | | | | | | 100|TRYING | | | | |
|<----------|-------|-----------| | | | |<----------|-------|-----------| | | |
| 183|(SDP2) | | | | | | 183|(SDP2) | | | | |
|<----------|-------|-----------|------------|--------| | |<----------|-------|-----------|------------|--------| |
| | PATH | | | PATH | | | | PATH | | | PATH | |
| |------>| | |<-------| | | |------>| | |<-------| |
skipping to change at page 29, line 5 skipping to change at page 29, line 5
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 c) the PE can optimize network resources by dynamically adjusting
the bandwidth of each tunnel according to the load over that tunnel. the bandwidth of each tunnel according to the load over that tunnel.
For example, if a tunnel is operating near capacity, the network may For example, if a tunnel is operating near capacity, the network may
dynamically adjust the tunnel size within a set of parameters. dynamically adjust the tunnel size within a set of parameters.
RSVP Aggregation over MPLS TE tunnels February 2006
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 - DSTE tunnels are subject to Admission Control over the
resources of the MPLS TE core 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,
 End of changes. 70 change blocks. 
217 lines changed or deleted 120 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/