draft-ietf-tsvwg-rsvp-dste-04.txt   draft-ietf-tsvwg-rsvp-dste-05.txt 
RSVP Aggregation over MPLS TE tunnels September 2006
Internet Draft Francois Le Faucheur Internet Draft Francois Le Faucheur
Editor Editor
Cisco Systems, Inc. Cisco Systems, Inc.
draft-ietf-tsvwg-rsvp-dste-04.txt draft-ietf-tsvwg-rsvp-dste-05.txt
Expires: March 2007 September 2006
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 5 skipping to change at page 2, line 5
RSVP end-to-end reservations over MPLS Traffic Engineering (TE) RSVP end-to-end reservations over MPLS Traffic Engineering (TE)
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.
RSVP Aggregation over MPLS TE tunnels September 2006
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 [KEYWORDS].
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
2. Contributing Authors...........................................6 2. Contributing Authors...........................................6
3. Definitions....................................................7 3. Definitions....................................................7
4. Operations of RSVP Aggregation over TE with pre-established 4. Operations of RSVP Aggregation over TE with pre-established
Tunnels...........................................................8 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............10
skipping to change at page 2, line 38 skipping to change at page 2, line 40
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 TE Tunnel.....................................15
4.10. Example Signaling Flow..................................16 4.10. Example Signaling Flow..................................16
5. IPv4 and IPv6 Applicability...................................17 5. IPv4 and IPv6 Applicability...................................17
6. E2E Reservations Applicability................................17 6. E2E Reservations Applicability................................17
7. Example Deployment Scenarios..................................17 7. Example Deployment Scenarios..................................17
7.1. Voice and Video Reservations Scenario....................17 7.1. Voice and Video Reservations Scenario....................17
7.2. PSTN/3G Voice Trunking Scenario..........................18 7.2. PSTN/3G Voice Trunking Scenario..........................18
8. Security Considerations.......................................19 8. Security Considerations.......................................19
9. IANA Considerations...........................................20 9. IANA Considerations...........................................20
10. Acknowledgments..............................................20 10. Acknowledgments..............................................21
11. Normative References.........................................20 11. Normative References.........................................21
12. Informative References.......................................21 12. Informative References.......................................22
13. Editor's Address:............................................22 13. Editor's Address:............................................23
Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator.......23 Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator.......24
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)................................25 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 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 4, line 4 skipping to change at page 4, line 4
Diffserv core even when the total number of such flows carried over Diffserv core even when the total number of such flows carried over
the Diffserv core is extremely large. the Diffserv core is extremely large.
[RSVP-AGG] describes in detail how to perform such aggregation of end [RSVP-AGG] describes in detail how to perform such aggregation of end
to end RSVP reservations over aggregate RSVP reservations in a to end RSVP reservations over aggregate RSVP reservations in a
Diffserv cloud. It establishes an architecture where multiple end-to- Diffserv cloud. It establishes an architecture where multiple end-to-
end RSVP reservations sharing the same ingress router (Aggregator) end RSVP reservations sharing the same ingress router (Aggregator)
and the same egress router (Deaggregator) at the edges of an and the same egress router (Deaggregator) at the edges of an
"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
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 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 Based be established using RSVP-TE signaling. MPLS TE uses Constraint Based
Routing to compute the path for a TE tunnel. Then, Admission Control Routing to compute the path for a TE tunnel. Then, Admission Control
skipping to change at page 5, line 4 skipping to change at page 5, line 4
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 only changes those where necessary to operate over TE tunnels. With
[RSVP-AGG], a lot of responsibilities (such as mapping end-to-end [RSVP-AGG], a lot of responsibilities (such as mapping end-to-end
reservations to Aggregate reservations and resizing the Aggregate reservations to Aggregate reservations and resizing the Aggregate
reservations) are assigned to the Deaggregator (which is the reservations) are assigned to the Deaggregator (which is the
equivalent of the Tunnel Tail-end) while with TE, the tunnels are equivalent of the Tunnel Tail-end) while with TE, the tunnels are
controlled by the Tunnel Head-end. Hence, the main change over the controlled by the Tunnel Head-end. Hence, the main change over the
RSVP Aggregations procedures defined in [RSVP-AGG] is to modify these RSVP Aggregations procedures defined in [RSVP-AGG] is to modify these
RSVP Aggregation over MPLS TE tunnels September 2006
procedures to reassign responsibilities from the Deaggregator to the procedures to reassign responsibilities from the Deaggregator to the
Aggregator (i.e. the tunnel Head-end). 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 of
end-to-end LSPs into an aggregate LSP in the core (by using the label end-to-end LSPs into an aggregate LSP in the core (by using the label
stack construct). Since end-to-end TE LSPs are themselves signaled stack construct). Since end-to-end TE LSPs are themselves signaled
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
skipping to change at page 6, line 4 skipping to change at page 6, line 4
appear to be addressed in RFC 2746. 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 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.
" "
RSVP Aggregation over MPLS TE tunnels September 2006
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
following: following:
- applications can benefit from dynamic, topology-aware resource- - applications can benefit from dynamic, topology-aware resource-
based admission control over any segment of the end to end path based admission control over any segment of the end to end path
including the core including the core
- as per regular RSVP behavior, RSVP does not impose any burden - as per regular RSVP behavior, RSVP does not impose any burden
on routers where such admission control is not needed (for on routers where such admission control is not needed (for
example if the links upstream and downstream of the MPLS TE example if the links upstream and downstream of the MPLS TE
core are vastly over-engineered compared to the core capacity, core are vastly over-engineered compared to the core capacity,
skipping to change at page 7, line 4 skipping to change at page 7, line 4
and content were contributed by the editor and the co-authors listed and content were contributed by the editor and the co-authors listed
below. (The contact information for the editor appears in the below. (The contact information for the editor appears in the
Editor's Address section.) Editor's Address section.)
Michael DiBiasio Michael DiBiasio
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: dibiasio@cisco.com Email: dibiasio@cisco.com
RSVP Aggregation over MPLS TE tunnels September 2006
Bruce Davie Bruce Davie
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: bdavie@cisco.com Email: bdavie@cisco.com
Christou Christou Christou Christou
Booz Allen Hamilton Booz Allen Hamilton
8283 Greensboro Drive 8283 Greensboro Drive
skipping to change at page 8, line 4 skipping to change at page 8, line 4
USA USA
Email: bgoode@att.com 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 router
at the ingress edge of the aggregation region (with at the ingress edge of the aggregation region (with
RSVP Aggregation over MPLS TE tunnels September 2006
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.
Deaggregator This is the process in (or associated with) the router Deaggregator This is the process in (or associated with) the router
at the egress edge of the aggregation region (with at the egress 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 Tail-end document, it is also the TE Tunnel Tail-end
skipping to change at page 9, line 5 skipping to change at page 9, line 5
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
4. 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.
RSVP Aggregation over MPLS TE tunnels September 2006
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.
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-to-
end TE LSPs to take into account the (aggregate) TE tunnels. In the end TE LSPs to take into account the (aggregate) TE tunnels. In the
skipping to change at page 9, line 48 skipping to change at page 9, line 50
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
I----I I----I |----| |----|
H--I R I\ I-----I I------I /I R I--H H--| R |\ |-----| |------| /| R |--H
H--I I\\I I I---I I I//I I--H H--| |\\| | |---| | |//| |--H
I----I \I He/ I I T I I Te/ I/ I----I |----| \| He/ | | T | | Te/ |/ |----|
I Agg I=======================I Deag I | Agg |=======================| Deag |
/I I I I I I\
H--------//I I I---I I I\\--------H RSVP Aggregation over MPLS TE tunnels September 2006
H--------/ I-----I I------I \--------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
skipping to change at page 11, line 5 skipping to change at page 11, line 5
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 towards the destination, one belonging
to DS-TE Class-Type 1 and one to Class-Type 0, if the policy is to to DS-TE Class-Type 1 and one to Class-Type 0, if the policy is to
map Intserv Guaranteed Services reservations to a Class-Type 1 tunnel map Intserv Guaranteed Services reservations to a Class-Type 1 tunnel
and Intserv Controlled Load reservations to a Class-Type 0 tunnel, and Intserv Controlled Load reservations to a Class-Type 0 tunnel,
and if the E2E RSVP Path message advertises both Guaranteed Service and if the E2E RSVP Path message advertises both Guaranteed Service
and Controlled Load. and 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 towards 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 and
may be based on configured information, on information available in may be based on configured information, on information available in
the MPLS TE topology database, on the current TE tunnel path, on the MPLS TE topology database, on the current TE tunnel path, on
information collected via RSVP-TE signaling, or combinations of those. information collected via RSVP-TE signaling, or combinations of those.
Updating the ADSPEC allow receivers that take into account the Updating the ADSPEC allow receivers that take into account the
information collected in the ADSPEC within the network (such as delay information collected in the ADSPEC within the network (such as delay
skipping to change at page 12, line 5 skipping to change at page 12, line 5
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 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.
skipping to change at page 13, line 4 skipping to change at page 13, line 4
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
RSVP Aggregation over MPLS TE tunnels September 2006
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.
4.6. Handling of E2E Resv Message by the Aggregator 4.6. Handling of E2E Resv Message by the Aggregator
skipping to change at page 13, line 50 skipping to change at page 13, line 53
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 this reservation.
That is, the reservation is not installed and a ResvError is sent That is, the reservation is not installed and a ResvError is sent
back towards the receiver. back towards the 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
skipping to change at page 15, line 4 skipping to change at page 15, line 4
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 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 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 17, 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 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.
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
skipping to change at page 18, line 4 skipping to change at page 18, line 4
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 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 September 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 | H |# ------- -------- #| H |
I I\#I I ----- I I#/I I | |\#| | ----- | |#/| |
-----I \I Agg I I T I I Deag I/ ------ -----| \| Agg | | T | | Deag |/ ------
I I==========================I I | |==========================| |
------ /I I::::::::::I I:::::::::::I I\ ------ ------ /| |::::::::::| |:::::::::::| |\ ------
I H I/#I I ----- I I#\I H I | H |/#| | ----- | |#\| H |
I I# ------- -------- #I I | |# ------- -------- #| |
------ ------ ------ ------
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
skipping to change at page 19, line 5 skipping to change at page 19, line 5
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 September 2006
------ ------ ------ ------
I GW I\ ------- -------- /I GW I | GW |\ ------- -------- /| GW |
I I\\I I ----- I I//I I | |\\| | ----- | |//| |
-----I \I Agg I I T I I Deag I/ ------ -----| \| Agg | | T | | Deag |/ ------
I I==========================I I | |==========================| |
------ /I I I I I I\ ------ ------ /| | | | | |\ ------
I GW I//I I ----- I I\\I GW I | GW |//| | ----- | |\\| GW |
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
8. Security Considerations 8. Security Considerations
The security issues inherent to the use of RSVP, RSVP Aggregation and In the environments concerned by this document, RSVP messages are
MPLS TE apply. Those can be addressed as discussed in [RSVP], [RSVP- used to control resource reservations for E2E flows outside the MPLS
AGG] and [RSVP-TE]. region as well as to control resource reservations for MPLS TE
Tunnels inside the MPLS region. To ensure the integrity of the
associated reservation and admission control mechanisms, the
mechanisms defined in [RSVP-CRYPTO1] and [RSVP-CRYPTO2] can be used.
Those protect RSVP messages integrity hop-by-hop and provide node
authentication, thereby protecting against corruption and spoofing of
RSVP messages. These hop-by-hop integrity mechanisms can naturally be
used to protect the RSVP messages used for E2E reservations outside
the MPLS region, to protect RSVP messages used for MPLS TE Tunnels
inside the MPLS region, or for both. These hop-by-hop RSVP integrity
mechanisms can also be used to protect RSVP messages used for E2E
reservations when those transit through the MPLS region. This is
because the Aggregator and Deaggregator behave as RSVP neighbors from
the viewpoint of the E2E flows (even if they are not necessarily IP
neighbors nor RSVP-TE neighbors). It that case, the Aggregator and
Deaggregator need to use a pre-shared secret.
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
MPLS label, instead of the 5-tuple of conventional RSVP reservation
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
aggregation of RSVP E2E reservations as per this specification) can
RSVP Aggregation over MPLS TE tunnels September 2006
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.
This document is based in part on [RSVP-AGG] which specifies
aggregation of RSVP reservations. Section 5 of [RSVP-AGG] raises the
point that because many E2E flows may share an aggregate reservation,
if the security of an aggregate reservation is compromised, there is
a multiplying effect in the sense that it can in turn compromise the
security of many E2E reservations whose quality of service depends on
the aggregate reservation. This concern applies also to RSVP
Aggregation over TE Tunnels as specified in the present document.
However, the integrity of MPLS TE Tunnels operation can be protected
using the mechanisms discussed in the previous paragraphs. Also,
while [RSVP-AGG] specifies RSVP Aggregation over dynamically
established aggregate reservations, the present document restricts
itself to RSVP Aggregation over pre-established TE Tunnels. This
further reduces the security risks.
In the case where the Aggregators dynamically resize the TE tunnels
based on the current level of reservation, there are risks that the
TE tunnels used for RSVP aggregation hog resources in the core which
could prevent other TE Tunnels from being established. There are also
potential risks that such resizing results in significant computation
and signaling as well as churn on tunnel paths. Such risks can be
mitigated by configuration options allowing control of TE tunnel
dynamic resizing (maximum TE tunnel size, maximum resizing
frequency, ...) and/or possibly by the use of TE preemption.
Section 5 of [RSVP-AGG] also discusses a security issue specific to
RSVP aggregation related to the necessary modification of the IP
Protocol number in RSVP E2E Path messages that traverses the
aggregation region. This security issue does not apply to the present
document since aggregation of RSVP reservation over TE Tunnels does
not use this approach of changing the protocol number in 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 applicable
to the present document. to the present document.
In addition, in the case where the Aggregators dynamically resize the
TE tunnels based on the current level of reservation, there are risks
that the TE tunnels used for RSVP aggregation hog resources in the
core which could prevent other TE Tunnels from being established.
There are also potential risks that such resizing results in
significant computation and signaling as well as churn on tunnel
paths. Such risks can be mitigated by configuration options allowing
control of TE tunnel dynamic resizing (maximum Te tunnel size,
maximum resizing frequency,...) and/or possibly by the use of TE
preemption.
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. IANA Considerations
RSVP Aggregation over MPLS TE tunnels September 2006
This document has no actions for IANA. This document has no actions for IANA.
10. Acknowledgments 10. 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 11. Normative References
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate [BCP 78], S. Bradner, IETF Rights in Contributions, RFC3978, BCP 78,
Requirement Levels, RFC2119, March 1997. March 2005.
[RFC3668] S. Bradner, Intellectual Property Rights in IETF Technology,
RFC 3668, February 2004.
[BCP-78], S. Bradner, IETF Rights in Contributions, RFC3978, March
2005.
[RSVP] Braden et al., Resource ReSerVation Protocol (RSVP) -- Version
1 Functional Specification, RFC 2205, September 1997.
[INT-SERV] Braden, R., Clark, D. and S. Shenker, Integrated Services
in the Internet Architecture: an Overview, RFC 1633, June 1994.
[GUARANTEED] Shenker et al., Specification of Guaranteed Quality of [BCP 79] S. Bradner, Intellectual Property Rights in IETF Technology,
Service, RFC2212 RFC 3668, BCP 79, February 2004.
[CONTROLLED] Wroclawski, Specification of the Controlled-Load Network [CONTROLLED] Wroclawski, Specification of the Controlled-Load Network
Element Service, RFC2211 Element Service, RFC2211
[DIFFSERV] Blake et al., An Architecture for Differentiated Services, [DIFFSERV] Blake et al., An Architecture for Differentiated Services,
RFC 2475 RFC 2475
[DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of
Diff-Serv-aware MPLS Traffic Engineering, RFC 4124, June 2005.
[GUARANTEED] Shenker et al., Specification of Guaranteed Quality of
Service, RFC2212
[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 [INT-SERV] Braden, R., Clark, D. and S. Shenker, Integrated Services
Reservations, RFC 3175, September 2001. in the Internet Architecture: an Overview, RFC 1633, June 1994.
[KEYWORDS] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, RFC2119, March 1997.
[LSP-HIER] Kompella et al, Label Switched Paths (LSP) Hierarchy with
Generalized Multi-Protocol Label Switching (GMPLS) Traffic
Engineering (TE), RFC 4206, October 2005
[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] Braden et al., Resource ReSerVation Protocol (RSVP) -- Version
RFC 3209, December 2001. 1 Functional Specification, RFC 2205, September 1997.
[DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of RSVP Aggregation over MPLS TE tunnels September 2006
Diff-Serv-aware MPLS Traffic Engineering, RFC 4124, June 2005.
[LSP-HIER] Kompella et al, Label Switched Paths (LSP) Hierarchy with [RSVP-AGG] Baker et al, Aggregation of RSVP for IPv4 and IPv6
Generalized Multi-Protocol Label Switching (GMPLS) Traffic Reservations, RFC 3175, September 2001.
Engineering (TE), RFC 4206, October 2005
[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 [SEC-ARCH] Kent and Seo, Security Architecture for the Internet
Protocol, RFC 4301, December 2005 Protocol, RFC 4301, December 2005
12. Informative References 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, [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 [L-RSVP] Manner et al., Localized RSVP, draft-manner-lrsvp-04.txt,
IPv6 Provider Edge Routers (6PE), work in progress work in progress.
[RSVP-IPSEC] Berger et al, RSVP Extensions for IPSEC Data Flows, RFC [RSVP-APPID] Bernet et al., Identity Representation for RSVP, RFC
2207 3182.
[RSVP-GEN-AGG] Le Faucheur et al, Generic Aggregate RSVP Reservations, [RSVP-GEN-AGG] Le Faucheur et al, Generic Aggregate RSVP Reservations,
draft-ietf-tsvwg-rsvp-ipsec, work in progress draft-ietf-tsvwg-rsvp-ipsec, work in progress
[RSVP-TUN] Terzis et al., RSVP Operation Over IP Tunnels, RFC 2746, [RSVP-IPSEC] Berger et al, RSVP Extensions for IPSEC Data Flows, RFC
January 2000 2207
[RSVP-PREEMP] Herzog, Signaled Preemption Priority Policy Element, [RSVP-PREEMP] Herzog, Signaled Preemption Priority Policy Element,
RFC 3181 RFC 3181
[L-RSVP] Manner et al., Localized RSVP, draft-manner-lrsvp-04.txt, RSVP Aggregation over MPLS TE tunnels September 2006
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-TUN] Terzis et al., RSVP Operation Over IP Tunnels, RFC 2746,
3182. January 2000
[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.
[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. Editor's Address: 13. 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
skipping to change at page 22, line 46 skipping to change at page 24, line 5
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.
Disclaimer of Validity Disclaimer of Validity
RSVP Aggregation over MPLS TE tunnels September 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.
Copyright Notice Copyright Notice
skipping to change at page 24, line 5 skipping to change at page 25, line 5
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:
I----I I--------------I I------I I--------------I I----I |----| |--------------| |------| |--------------| |----|
I I I Aggregator/ I I MPLS I I Aggregator/ I I I | | | Aggregator/ | | MPLS | | Aggregator/ | | |
IHostI I Deaggregator/I I cloudI I Deaggregator/I IHostI |Host| | Deaggregator/| | cloud| | Deaggregator/| |Host|
I I I RSVP Proxy I I I I RSVP Proxy I I I | | | RSVP Proxy | | | | RSVP Proxy | | |
I----I I--------------I I------I I--------------I I----I |----| |--------------| |------| |--------------| |----|
==========TE Tunnel==========> ==========TE Tunnel==========>
<========= TE Tunnel========== <========= TE Tunnel==========
Path Path Path Path
------------> (1)-\ /-(i) <---------- ------------> (1)-\ /-(i) <----------
Resv I I 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 TE Tunnel.
(1) and (i) happens independently of each other. (1) and (i) happens independently of each other.
skipping to change at page 25, line 5 skipping to change at page 26, line 5
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
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 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
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 which itself has been subject
skipping to change at page 26, line 5 skipping to change at page 27, line 5
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 de-aggregator/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 de-aggregator/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
skipping to change at page 27, line 4 skipping to change at page 28, line 4
_,' \-| ./ -'._ / | _,' \-| ./ -'._ / |
| 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 A1. Integration of SIP Resource Management, DSTE
RSVP Aggregation over MPLS TE tunnels September 2006
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
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
skipping to change at page 28, line 5 skipping to change at page 29, line 5
- GW1 sends a SIP UPDATE message to GW2. - GW1 sends a SIP UPDATE message to GW2.
- Upon receiving the UPDATE, GW2 sends the INVITE to the - Upon receiving the UPDATE, GW2 sends the INVITE to the
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.
RSVP Aggregation over MPLS TE tunnels September 2006
- 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 September 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 30, line 5 skipping to change at page 31, 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 September 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. 51 change blocks. 
91 lines changed or deleted 222 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/