doc: Add RFC documents

1 files changed, 1739 insertions, 0 deletions

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