RSVP Aggregation over MPLS TE tunnels September 2006 Internet DraftNetwork Working Group Francois LeFaucheur EditorFaucheur, Ed. Request for Comments: 4804 Cisco Systems, Inc.draft-ietf-tsvwg-rsvp-dste-05.txt Expires: MarchCategory: Standards Track February 2007September 2006Aggregation ofRSVPResource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels Status ofthisThis MemoBy submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents ofThis document specifies an Internet standards track protocol for the InternetEngineering Task Force (IETF), its areas,community, andits working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents validrequests discussion and suggestions fora maximumimprovements. Please refer to the current edition ofsix monthsthe "Internet Official Protocol Standards" (STD 1) for the standardization state andmay be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The liststatus ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The listthis protocol. Distribution ofInternet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract RFC 3175 specifies aggregation ofRSVPResource 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.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.RSVP Aggregation over MPLS TE tunnels September 2006 Copyright Notice Copyright (C) The Internet Society (2006). Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].Table of Contents 1.Introduction...................................................2Introduction ....................................................3 2.Contributing Authors...........................................6Specification of Requirements ...................................7 3.Definitions....................................................7Definitions .....................................................7 4. Operations of RSVP Aggregation over TE withpre-established Tunnels...........................................................8Pre-established Tunnels .........................................8 4.1. ReferenceModel...........................................9Model ............................................9 4.2. Receipt of E2E Pathmessage ByMessage by theAggregator............10Aggregator ..............9 4.3. Handling of E2E Pathmessage ByMessage by TransitLSRs.............11LSRs ..............11 4.4. Receipt of E2E Path Message byDeaggregator..............12the Deaggregator ...........11 4.5. Handling of E2E Resv Message byDeaggregator.............12the Deaggregator ..........12 4.6. Handling of E2E Resv Message by theAggregator...........13Aggregator ............12 4.7. Forwarding of E2EtrafficTraffic byAggregator..................14the Aggregator ...............14 4.8. Removal of E2Ereservations..............................14Reservations ...............................14 4.9. Removal of the TETunnel.....................................15Tunnel ..................................14 4.10. Example SignalingFlow..................................16Flow ...................................15 5. IPv4 and IPv6Applicability...................................17Applicability ....................................16 6. E2E ReservationsApplicability................................17Applicability .................................16 7. Example DeploymentScenarios..................................17Scenarios ...................................16 7.1. Voice and Video ReservationsScenario....................17Scenario .....................16 7.2. PSTN/3G Voice TrunkingScenario..........................18Scenario ...........................17 8. SecurityConsiderations.......................................19Considerations ........................................18 9.IANA Considerations...........................................20Acknowledgments ................................................19 10.Acknowledgments..............................................21 11.NormativeReferences.........................................21 12.References ..........................................20 11. InformativeReferences.......................................22 13. Editor's Address:............................................23References ........................................21 Appendix A - Optional Use of RSVP Proxy on RSVPAggregator.......24Aggregator ........23 Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels for VoIP Call Admission Control(CAC)................................26(CAC) ................25 1. IntroductionRSVP Aggregation over MPLS TE tunnels September 2006The 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 Protocolwhichthat can be used by applications to request resources from the network. The network responds byexplicitelyexplicitly 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-flowprocessingprocessing, 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 includingresource basedresource-based admission control,policypolicy- based admission control, assistance in trafficidentification /classificationidentification/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 ormay beRSVP aware. When it is RSVP aware, several mechanisms may be used to support dynamic provisioning andtopology awaretopology-aware admissioncontrolcontrol, including aggregate RSVP reservations,per flow RSVPper-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 awaretopology-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]describes inand [RSVP-GEN-AGG] describe in detail how to perform such aggregation ofend to endend-to-end RSVP reservations over aggregate RSVP reservations in a Diffserv cloud.It establishesThey establish an architecture where multipleend-to- endend-to-end RSVP reservations sharing the same ingress router (Aggregator) andthe sameegress router (Deaggregator) at the edges of an "aggregationregion",region" can be mapped onto a single aggregate reservation within the aggregation region. This considerably reducesRSVP Aggregation over MPLS TE tunnels September 2006the 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)Tunnelstunnels can be used to carry arbitrary aggregates of traffic for the purposes of traffic engineering. [RSVP-TE] specifies how such MPLS TETunnelstunnels can be established using RSVP-TE signaling. MPLS TE usesConstraint BasedConstraint-Based Routing to compute the path for a TE tunnel. Then, Admission Control is performed during the establishment of TETunnelstunnels to ensure they are granted their requested resources. [DSTE-REQ] presents the Service Providers requirements for support ofDiff-Serv-awareDiffserv-aware MPLS Traffic Engineering (DS-TE). With DS-TE, separate DS-TE tunnels can be used to carry different Diffserv classes oftraffictraffic, and different resource constraints can be enforced for these different classes. [DSTE-PROTO] specifies RSVP-TE signaling extensions as well as OSPF andISISIntermediate 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 andDS- TEDS-TE tunnels simply as "TE tunnels". TE tunnels have much in common with the aggregate RSVP reservations used in[RSVP-AGG]:[RSVP-AGG] and [RSVP-GEN-AGG]: -aA TE tunnel is subject to Admission Control and thus is effectively an aggregate bandwidthreservationreservation. - In the data plane, packet scheduling relies exclusively onDiff-ServDiffserv classification andPHBsPHBs. - 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 TEtunnels,tunnels; Aggregator and Deaggregator in the case of aggregate RSVPreservationsreservations. - Both TE tunnels and aggregate RSVP reservations are signaled using the RSVP protocol (with some extensions defined in[RSVP- TE][RSVP-TE] and [DSTE-PROTO] respectively for TE tunnels and DS-TE tunnels). 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],[RSVP-AGG] and [RSVP-GEN-AGG], and only changes those where necessary to operate over TE tunnels. With[RSVP-AGG],[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 theTunneltunnel Tail-end) while with TE, the tunnels are controlled by theTunneltunnel Head-end. Hence, the main change over the RSVP Aggregations procedures defined in [RSVP-AGG] and [RSVP-GEN-AGG] is to modify theseRSVP Aggregation over MPLS TE tunnels September 2006procedures to reassign responsibilities from the Deaggregator to the Aggregator(i.e.(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 TETunnels.tunnels. This document capitalizes on the similarities between nesting of TE LSPs over TE tunnels and RSVP aggregation over TEtunnelstunnels, 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 followingwaysways: -WhereasThis document describes operation over MPLS tunnels, whereas RFC 2746 describes operation with IPtunnels, this document describes operation over MPLStunnels. 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. - 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 commonheadHead-end andtail endTail-end routers, withhead-endthe 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"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 dataflows. " RSVP Aggregation over MPLS TE tunnels September 2006flows". Aggregation of end-to-end RSVP reservations over TE tunnels combines the benefits of [RSVP-AGG] and [RSVP-GEN-AGG] with the benefits ofMPLSMPLS, including the following: -applicationsApplications can benefit from dynamic,topology-aware resource- basedtopology-aware, resource-based admission control over any segment of theend to end pathend- to-end path, including thecorecore. -asAs per regular RSVP behavior, RSVP does not impose any burden on routers where such admission control is not needed (forexampleexample, 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 routerhops)hops). -theThe 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 tunnelsandsince the datapath classification and scheduling in the core relies purely on the Diffserv mechanism (or more precisely the MPLS Diffservmechanismsmechanisms, as specified in[DIFF-MPLS])[DIFF-MPLS]). -theThe 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.(e.g., affinity, optimization on different metrics) and when needed can take advantage of resources on other paths than the shortestpathpath. -theThe aggregate reservations (and thus the traffic from the correspondingend to endend-to-end reservations) can be protected against failure through the use of MPLS FastRerouteReroute. This document, like[RSVP-AGG],[RSVP-AGG] and [RSVP-GEN-AGG], covers aggregation of unicast sessions. Aggregation of multicast sessions is for further study. 2.Contributing Authors This document was the collective workSpecification ofseveral authors.Requirements Thetextkey words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", andcontent were contributed by"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 theeditorprocess 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 theco-authors listed below. (The contact information forTE tunnel Head-end. Deaggregator This is theeditor appearsprocess inthe Editor's Address section.) Michael DiBiasio Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA Email: dibiasio@cisco.com RSVP Aggregation over MPLS TE tunnels September 2006 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 USA Email: gash@att.com Bur Goode AT&T 32 Old Orchard Drive Weston, CT 06883 USA Email: bgoode@att.com 3. Definitions For readability, a number of definitions from [RSVP-AGG] as well as 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 RSVP Aggregation over MPLS TE tunnels September 2006 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)(or associated with) the router at the egress edge of the aggregation region (with respect to theend to endend-to-end RSVP reservation) and behaving in accordance with [RSVP-AGG]. In this document, it is also the TETunneltunnel Tail-end E2E End to end E2EreservationReservation 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 isto beaggregated over an MPLS TE tunnel between the Aggregator and Deaggregator. An E2E RSVP reservation may be a per-flow reservation. Alternatively, the E2E reservation may itself be an aggregate reservation of various types(e.g.(e.g., Aggregate IP reservation, Aggregate IPsec reservation). SeesectionSection 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,maintainingmaintaining, and tearing down a given TE tunnel. Tail-end This is the Label Switch Router responsible for terminating a given TEtunneltunnel. Transit LSR This is a Label SwitchrouterRouter that is on the path of a given TE tunnel and is neither the Head-end nor theTail-endTail-end. 4. Operations of RSVP Aggregation over TE withpre-establishedPre-established Tunnels [RSVP-AGG]supportsand [RSVP-GEN-AGG] support operations both in the case where aggregate RSVP reservations are pre-established andin the casewhere Aggregators and Deaggregators have to dynamically discover each other and dynamically establish the necessary aggregate RSVP reservations.RSVP Aggregation over MPLS TE tunnels September 2006Similarly, RSVP Aggregation over TE tunnels could operate both in the case where the TE tunnels are pre-established andin the casewhere 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 insectionSection 3 of [LSP-HIER] are not relevant here because those aim at allowing the constraint based routing ofend-to- endend- 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 TETunneltunnel may be advertised intoISISIS-IS or OSPF, to be used in normal SPF by nodes upstream of the Aggregator. This would affect SPF routing and thus routing ofend-to- endend-to-end RSVP reservations. The control of aggregation boundaries discussed insectionSection 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 arepre- established,pre-established, so that the aggregation boundary can be easily inferred. The signaling aspects discussed insectionSection 6.2 of [LSP-HIER] apply to the establishment/termination of the aggregate TE tunnels when this is triggered by GMPLS mechanisms(e.g.(e.g., as a result of an end-to-end TE LSP establishment request received at the aggregationboundary) .boundary). As this document assumes pre-established tunnels, those aspects are not relevant here. The signaling aspects discussed insectionSection 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 insectionSection 6.1 of[LSP- HIER],[LSP-HIER], but for the establishment of end-to-end RSVP reservations (instead ofend-to-endend- to-end TE LSPs) over the TE tunnels. This is covered further insectionSection 4 of the present document. Pre-establishment of the TE tunnels may be triggered by any mechanismsincludingincluding; forexampleexample, 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 |RSVP Aggregation over MPLS TE tunnels September 2006/| | | | | |\ 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 == = TETunneltunnel 4.2. Receipt of E2E Pathmessage ByMessage 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. 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][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 TETunnel set-uptunnel 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 tunneltowardstoward the destination and if the policy is to map any E2E RSVP reservation onto TETunnels.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 tunnelstowardstoward 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.RSVP Aggregation over MPLS TE tunnels September 2006Whether final or tentative, the Aggregator makes a mapping decision and selects a TE tunnel. Before forwarding the E2E Path messagetowardstoward 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, orcombinations of those.a combination thereof. Updating the ADSPECallowallows 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 thetail-endTail-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 TETunnel.tunnel. 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],[RSVP-AGG] and [RSVP-GEN-AGG], the IP Protocol numberneeddoes 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 Pathmessage ByMessage 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.RSVP Aggregation over MPLS TE tunnels September 20064.4. Receipt of E2E Path Message by the DeaggregatorOnUpon 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. 2. Find the "other end" of the above data interface,sayi.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 downstreamtowardstoward 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 upstreamhop-by- hophop- by-hop towards the sender.OnUpon 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 AggregatorRSVP Aggregation over MPLS TE tunnels September 2006and 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). 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 TETunneltunnel 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 there- sizingre-sizing of the aggregate reservation (in this case, the TEtunnel.)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 theTunneltunnel 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, theaggregatorAggregator SHOULD use "make-before-break" procedures as described in [RSVP-TE] to alter the TE tunnel bandwidth.RSVP Aggregation over MPLS TE tunnels September 2006If sufficient bandwidth is not available on the final TETunnel,tunnel, the Aggregator MUST follow the normal RSVP procedure for a reservation being placed with insufficient bandwidth to supportthis reservation.it. That is, the reservation is not installed and a ResvError is sent backtowardstoward 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 TETunnel.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 changeand described above.(described above). In the former case, admission control over the final TE tunnel (and forwarding of E2E Resv message upstreamtowardstoward the sender) would only occur when the Aggregatorreceivesreceived 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 finalTunneltunnel is carried out immediately byAggregator right awaythe Aggregator, and if successful the E2E Resv message is generated upstreamtowardstoward the sender.OnUpon receipt of an E2E ResvConf from the Aggregator, the Deaggregator MUST forward the E2E ResvConf downstreamtowardstoward 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 E2EtrafficTraffic 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 E2EreservationsReservations 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 theRSVP Aggregation over MPLS TE tunnels September 2006resources available on the corresponding TE tunnel accordingly. 4.9. Removal of the TE Tunnel Should a TETunneltunnel go away (presumably due to a configuration change, route change, or policy event), theaggregatorAggregator 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 ifnoa suitable tunnelexists.does not exist. In case the Path messages are forwarded onto anothertunneltunnel, which terminates on a different Deaggregator, or the reservation istorn-downtorn 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.RSVP Aggregation over MPLS TE tunnels September 20064.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 TETunnel(s)tunnel(s) (**) TETunnel(s)tunnel(s) are pre-established (1) Aggregator tentatively selects the TE tunnel and forwards E2E path to Deaggregator (2) Deaggregator forwards the E2E Pathtowardstoward the receiver (3) Deaggregator forwards the E2E Resv to the Aggregator (4) Aggregator selects final TE tunnel, checks that there is sufficient bandwidth on TEtunneltunnel, and forwards E2E Resv toRSVP Aggregation over MPLS TE tunnels September 2006PHOP. If final tunnel is different from tunnel tentatively selected, the Aggregator re-sends an E2EPath.Path with an updated IF_ID RSVP_HOP and possibly an updated ADSPEC. 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 TETunnelstunnels. (2) Aggregation of E2E IPv6 RSVP reservations over IPv6 TETunnelstunnels. (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 MPLScore,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)theThe E2E RSVP reservation is a per-flow reservation where the flow is characterized by the usual 5-tuple (2)theThe 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)theThe 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 highnumbersnumber of hosts. In the example illustrated below, hosts generateend-to-endE2E 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. These reservations are aggregated over MPLS DS-TE tunnels overRSVP Aggregation over MPLS TE tunnels September 2006the packet core. The mapping policy defined by the usermaybemay be that all the reservations for audio and voice streams are mapped ontoDS- TEDS-TE tunnels of Class-Type11, 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 (TETunneltunnel Head-end) Deagg = Deaggregator (TETunneltunnel Tail-end) T = Transit LSR / = E2E RSVP reservation for a Voice flow # = E2E RSVP reservation for a Video flow == = DS-TETunneltunnel from Class-Type 1 :: = DS-TETunneltunnel 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 inlarge scalelarge-scale telephony trunking environments. A Trunk VoIP Gateway may generate one aggregate RSVP reservation for all the calls in placetowardstoward 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 TETunnels.tunnels. The MPLS TE tunnels may be protected by MPLS Fast Reroute. This scenario is illustrated below:RSVP Aggregation over MPLS TE tunnels September 2006------ ------ | GW |\ ------- -------- /| GW | | |\\| | ----- | |//| | -----| \| Agg | | T | | Deag |/ ------ | |==========================| | ------ /| | | | | |\ ------ | GW |//| | ----- | |\\| GW | | |/ ------- -------- \| | ------ ------ GW = VoIP Gateway Agg = Aggregator (TETunneltunnel Head-end) Deagg = Deaggregator (TETunneltunnel Tail-end) T = Transit LSR / = Aggregate Gateway to Gateway E2E RSVP reservation == = TETunneltunnel 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 TETunnelstunnels 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.ThoseThe mechanisms protect the integrity of RSVP messagesintegrityhop-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 TETunnelstunnels inside the MPLS region, or for both. Thesehop-by-hophop- 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).ItIn that case, the Aggregator and Deaggregator need to use a pre-shared secret. As discussed insectionSection 6 of [RSVP-TE], filtering of traffic associated with an MPLS TETunneltunnel 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 TETunnelstunnels (which are used for aggregation of RSVP E2E reservations as per this specification) canRSVP Aggregation over MPLS TE tunnels September 2006be established. SeesectionSection 6 of [RSVP-TE] for a description of how filtering of RSVP messages associated with MPLS TETunnelstunnels can be deployed to that end. This document is based in part on[RSVP-AGG][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 TETunnelstunnels as specified in the present document. However, the integrity of MPLS TETunnelstunnels 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 TETunnels.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 thecorecore, which could prevent other TETunnelstunnels 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 TETunnelstunnels 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. 9.IANA Considerations RSVP Aggregation over MPLS TE tunnels September 2006 This document has no actions for IANA. 10.Acknowledgments This document builds on the [RSVP-AGG],[RSVP-TUN][RSVP-TUN], and [LSP-HIER] specifications.Also, weWe would like to thank Tom Phelan, John Drake, Arthi Ayyangar, Fred Baker, Subha Dhesikan, Kwok-Ho Chan, CarolIturraldeIturralde, and James Gibson for their input into this document.11.10. Normative References[BCP 78], S. Bradner, IETF Rights in Contributions, RFC3978, BCP 78, March 2005. [BCP 79] S. Bradner, Intellectual Property Rights in IETF Technology, RFC 3668, BCP 79, February 2004.[CONTROLLED] Wroclawski,SpecificationJ., "Specification of the Controlled-Load Network ElementService, RFC2211Service", RFC 2211, September 1997. [DIFFSERV]Blake et al., AnBlake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for DifferentiatedServices,Service", RFC24752475, December 1998. [DSTE-PROTO] LeFaucheur et al, Protocol extensionsFaucheur, F., "Protocol Extensions forsupportSupport ofDiff-Serv-awareDiffserv-aware MPLS TrafficEngineering,Engineering", RFC 4124, June 2005. [GUARANTEED]Shenker et al., SpecificationShenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality ofService, RFC2212Service", RFC 2212, September 1997. [INT-DIFF]ABernet, 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 DiffservNetworks,Networks", RFC 2998, November 2000. [INT-SERV] Braden, R., Clark,D.D., and S. Shenker,Integrated"Integrated Services in the Internet Architecture: anOverview,Overview", RFC 1633, June 1994. [KEYWORDS]S.Bradner,KeyS., "Key words for use in RFCs to Indicate RequirementLevels, RFC2119,Levels", BCP 14, RFC 2119, March 1997. [LSP-HIER]Kompella et al, LabelKompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering(TE),(TE)", RFC 4206, October20052005. [MPLS-TE]Awduche et al.,Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic EngineeringoverOver MPLS", RFC 2702, September 1999. [RSVP]Braden et al., ResourceBraden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 FunctionalSpecification,Specification", RFC 2205, September 1997.RSVP Aggregation over MPLS TE tunnels September 2006[RSVP-AGG]Baker et al, AggregationBaker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6Reservations,Reservations", RFC 3175, September 2001. [RSVP-CRYPTO1]Baker at al, RSVPBaker, F., Lindell, B., and M. Talwar, "RSVP CryptographicAuthentication,Authentication", RFC 2747, January 2000. [RSVP-CRYPTO2]BradenBraden, R. and L. Zhang,RSVP"RSVP Cryptographic Authentication--- Updated Message TypeValue,Value", RFC 3097, April 2001. [RSVP-TE]Awduche et al, RSVP-TE:Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSPTunnels,Tunnels", RFC 3209, December 2001. [SEC-ARCH]KentKent, S. and K. Seo,Security"Security Architecture for the InternetProtocol,Protocol", RFC 4301, December2005 12.2005. 11. Informative References [6PE] DeClercq et al, ConnectingClercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers(6PE), work in progress(6PE)", RFC 4798, February 2007. [AUTOMESH] Vasseur and Leroux,Routing"Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) meshmembership, draft-vasseur-ccamp-automesh-00.txt, workmembership", Work inprogress.Progress. [DIFF-MPLS] LeFaucheur et al, MPLSFaucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support ofDiff-Serv, RFC3270,Differentiated Services", RFC 3270, May 2002. [DSTE-REQ] LeFaucheur et al, RequirementsFaucheur, F. and W. Lai, "Requirements forsupportSupport ofDiff-Serv- awareDifferentiated Services-aware MPLS TrafficEngineering, RFC3564,Engineering", RFC 3564, July 2003. [L-RSVP]MannerManner, et al., LocalizedRSVP, draft-manner-lrsvp-04.txt, workRSVP for Controlling RSVP Proxies, Work inprogress.Progress. [RSVP-APPID]Bernet et al., IdentityYadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation forRSVP,RSVP", RFC3182.3182, October 2001. [RSVP-GEN-AGG] LeFaucheur et al, GenericFaucheur, R., Davie, B., Bose, P., Martin, L., Christou, C., Davenport, M., and A. Hamilton, "Generic AggregateRSVP Reservations, draft-ietf-tsvwg-rsvp-ipsec, workResource ReSerVation Protocol (RSVP) Reservations", Work inprogressProgress, January 2007. [RSVP-IPSEC]Berger et al, RSVPBerger, L. and T. O'Malley, "RSVP Extensions for IPSEC DataFlows,Flows", RFC22072207, September 1997. [RSVP-PREEMP] Herzog,SignaledS., "Signaled Preemption Priority PolicyElement,Element", RFC3181 RSVP Aggregation over MPLS TE tunnels September 2006 [RSVP-PROXY] Gai3181, October 2001. [RSVP-PROXY1] Gai, et al., RSVP Proxy,draft-ietf-rsvp-proxy-03.txt (expired), workWork inprogress. [RSVP-TUN] TerzisProgress. [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 IPTunnels,Tunnels", RFC 2746, January20002000. [SIP-RSVP] Camarillo,IntegrationG., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol(SIP),(SIP)", RFC3312 13. Editor's Address: Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side3312, October 2002. Appendix A -Batiment T3 400, Avenue de Roumanille 06410 Biot Sophia-Antipolis France Email: flefauch@cisco.com IPR Statements The IETF takes no position regarding the validity or scopeOptional Use ofany Intellectual Property RightsRSVP Proxy on RSVP Aggregator A number of approaches ([RSVP-PROXY1],[RSVP-PROXY2], [L-RSVP]) have been, orother rights that might be claimedare being, discussed in the IETF in order topertainallow a network node to behave as an RSVP proxy which: - originates theimplementation or useResv Message (in response to the Path message) on behalf of thetechnology described in this document ordestination node - originates theextent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effortPath message (in response toidentify any such rights. Informationsome trigger) onthe 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 usersbehalf ofthis specification can be obtained fromtheIETF 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 technologysource node. We observe that such approaches may optionally berequired to implement this standard. Please address the information toused in conjunction with theIETF at ietf-ipr@ietf.org. Disclaimeraggregation ofValidityRSVPAggregationreservations over MPLS TE tunnelsSeptember 2006 This document andas specified in this document. In particular, we consider the case where the RSVP Aggregator/Deaggregator also behaves as the RSVP proxy. The informationcontained 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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Notice Copyright (C) The Internet Society (2006). 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. Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator A number of approaches ([RSVP-PROXY], [L-RSVP]) have been, or are being, discussed in the IETF in order to allow a network node to 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 is this Appendix is purely informationalin this Appendix is purely informational and illustrative. As discussed in[RSVP-PROXY]:[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 TETunneltunnel (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 TETunnel (i.e.tunnel (i.e., between the host and the RSVP aggregator).RSVP Aggregation over MPLS TE tunnels September 2006Also, 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.(i.e., from RSVP aggregator/Deaggregator to host). 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 TETunnel.tunnel. (1) and (i)happenshappen independently of each other. (2)(ii) : Aggregator/Deaggregator/Proxy generates the Resv messagetowardstoward 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 messagetowardstoward 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-PROXY],[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.RSVP Aggregation over MPLS TE tunnels September 2006But 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 TETunnels,tunnels, in such a waywhichthat ensures (when used on both the Host-Aggregator and Deaggregator-Host sides, and when both end systems supportRSVP) that:RSVP): (i) admission control and resource reservation is performed on every segment of the end-to-end path(i.e.(i.e., between source host and Aggregator, over the TETunneltunnel between the Aggregator and Deaggregatorwhichthat itself has been subject to admission control by MPLS TE, between Deaggregator and destinationhost)host). (ii) this is achieved in bothdirectiondirections. (iii) RSVP signaling is localized between hosts and Aggregator/Deaggregator, which may result in significant reduction in reservation establishment delays (and in turn inpost dialpost-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 informationis thatin this Appendix is purely informational and illustrative. Consider the scenario depicted in FigureA1.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 thehead-endHead-end edge router, through core network P routers, to thetail-endTail-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 theaggregator/head-endAggregator/Head-end and PE2 serves as thede-aggregator/tail-end.Deaggregator/Tail-end. For reservations going from GW2 to GW2, PE2 serves as theaggregator/head-endAggregator/Head-end and PE1 serves as thede-aggregator/tail-end. RSVP Aggregation over MPLS TE tunnels September 2006Deaggregator/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 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 tunneltowardstoward the destination. Assuming there is enough bandwidth available on that tunnel, the PE adjusts itsbook-keepingbookkeeping of remaining available bandwidth on the tunnel and generates a Resv message backtowardstoward 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 FigureA1.B1. Integration of SIP ResourceManagement, DSTEManagement and RSVP Aggregation over MPLS TEtunnels September 2006 and RSVP AggregationTunnels [SIP-RSVP] discusses how network quality of service can be made a precondition for establishment of sessions initiated by the Session 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.Our example environment relies of [SIP-RSVP] to synchronize RSVP bandwidth reservations with SIP. For example,Through the collaboration between SIP resource management, RSVPbandwidth requests may be integrated into the call setup flowsignaling, RSVP Aggregation and DS-TE asfollows (See call setup flow diagram in Figure A2): - Caller C1 initiates a call by sending a SIP INVITE to VoIP gateway GW1, which passesdescribed above, we see that: a) theINVITE alongPE and GW collaborate to determine whether there is enough bandwidth on thecall control agent (CCA). The INVITE message may contain a list of codecs thattunnel between the callingphone can support. - VoIP gateway GW2, chooses a compatible codec from the listandresponds with a SIP message 183 Session Progress. - When GW1 receivescalled GWs to accommodate theSIP response message withconnection, b) theSDP, it determines how much bandwidthcorresponding accept/reject decision isrequired for the call. - GW1 sends an RSVP Path messagecommunicated toPE1, requesting bandwidth forthecall. - GW2 also sends an RSVP Path message to PE2. - Assuming thatGWs on a connection-by-connection basis, and c) the PE can optimize network resources by dynamically adjusting the bandwidth of each tunnel(from left to right) has sufficient bandwidth, PE1 respondsaccording toGW1 withthe load over that tunnel. For example, if aResv message - Again assumingtunnel is operating at near capacity, the network may dynamically adjust the tunnel(from right to left) has sufficient bandwidth, PE2 responds to GW2 withsize within aResv message - GW2 sendsset of parameters. We note that admission Control of voice calls over the core network capacity is achieved in aSIP 200 OK message to GW1.hierarchical manner whereby: -GW1 sends a SIP UPDATE messageDSTE tunnels are subject toGW2. - Upon receiving the UPDATE, GW2 sendsAdmission Control over theINVITE toresources of thedestination phone, which responds with SIP message 180 RINGING.MPLS TE core -When (and if) the called party answers, the destination phone responds with another SIP 200 OK which completes the connection and tellsVoice calls are subject to CAC over thecalling party that there is now reservedDSTE tunnel bandwidth This hierarchy is a key element inboth directions so that conversation can begin. RSVP Aggregationthe scalability of this CAC solution for voice calls over an MPLSTE tunnels September 2006 - RTP media streamsCore. 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 inboth directions pass throughplace 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 tunnelsas they traverseare subject to Admission Control over the resources of the MPLSnetwork.TE core - Aggregate RSVPAggregationreservations (for the calls from one GW to another GW) are subject to Admission Control overMPLS TE tunnels September 2006 IP-Phone/ IP-Phone/ TA-C1 GW1 PE1 CCA PE2 GW2 TA-C2 | INVITE|(SDP1) | INVITE | INVITE | | | |---------->|-------|---------->|------------|------->| | | 100|TRYING | | | | | |<----------|-------|-----------| | | | | 183|(SDP2) | | | | | |<----------|-------|-----------|------------|--------| | | | PATH | | | PATH | | | |------>| | |<-------| | | | RESV | | | RESV | | | |<------| | |------->| | | | | UPDATE|(SDP3) | | | | |-------|-----------|------------|------->| | | | | 200 OK|(SDP4) | | | | |<------|-----------|------------|--------| INVITE | | | | | | |---------->| |180 RINGING| | 180|RINGING | |180 RINGING| |<----------|<------|-----------|------------|--------|<----------| | 200 OK | 200|OK | 200|OK | 200 OK | |<----------|<------|-----------|<-----------|--------|<----------| | | | | | | | | | | DSTE|TUNNEL | | | | RTP|MEDIA |-----------|------------| | | |===========|=======|===========|============|========|==========>| | | |-----------|------------| | | | | | | | | | | | |-----------|------------| | | |<==========|=======|===========|============|========|===========| | | |-----------|------------| | |the DSTETUNNEL Figure A2. VoIP QoS CAC using SIP with Preconditions Throughtunnels (as per thecollaboration between SIP resource management, RSVP signaling, RSVP"RSVP Aggregationand DS-TE as described above, we see that: a)over TE Tunnels" procedures defined in this document) - Voice calls are subject to CAC by thePE andGWcollaborate to determine whether there is enough bandwidth onover thetunnel betweenaggregate reservation toward thecallingappropriate destination GW. This pushes even further the scalability limits of this voice CAC architecture. Contributing Authors This document was the collective work of several authors. The text andcalled GWs to accommodatecontent were contributed by theconnection, b)editor and thecorresponding accept/reject decisionco-authors listed below. Michael DiBiasio Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: dibiasio@cisco.com Bruce Davie Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: bdavie@cisco.com Christou Christou Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 USA EMail: christou_chris@bah.com Michael Davenport Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 USA EMail: davenport_michael@bah.com Jerry Ash AT&T 200 Laurel Avenue Middletown, NJ 07748 USA EMail: gash@att.com Bur Goode AT&T 32 Old Orchard Drive Weston, CT 06883 USA EMail: bgoode@att.com Editor's Address Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot Sophia-Antipolis France EMail: flefauch@cisco.com Full Copyright Statement Copyright (C) The IETF Trust (2007). This document iscommunicatedsubject to theGWs on a connection-by-connection basis,rights, licenses andc) the PE can optimize network resources by dynamically adjusting the bandwidth of each tunnel according torestrictions contained in BCP 78, and except as set forth therein, theload over that tunnel. For example, if a tunnel is operating near capacity,authors retain all their rights. This document and thenetwork may dynamically adjustinformation 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 thetunnel size within a setvalidity or scope ofparameters. RSVP Aggregation over MPLS TE tunnels September 2006 We noteany Intellectual Property Rights or other rights thatadmission Control of voice calls over the core network capacity is achieved in a hierarchical manner whereby: - DSTE tunnels are subjectmight be claimed to pertain toAdmission Control overtheresourcesimplementation or use of theMPLS TE core - Voice calls are subject to CAC over the DSTE tunnel bandwidth This hierarchy is a key elementtechnology described inthe scalability ofthisCAC solution for voice calls over an MPLS Core. It is also possible fordocument 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 theGWsprocedures with respect touse aggregate RSVP reservations themselves instead of per-call RSVP reservations. For example, instead of setting one reservation for each call GW1 hasrights inplace towards GW2, GW1 may establish one (or a small number of) aggregate reservations as definedRFC documents can be found in[RSVP-AGG] which is used for all (or a subsetBCP 78 and BCP 79. Copies ofall)IPR disclosures made to thecalls towards GW2. This effectively provides an additional levelIETF Secretariat and any assurances ofhierarchy whereby: - DSTE tunnels are subjectlicenses toAdmission Control overbe made available, or theresourcesresult of an attempt made to obtain a general license or permission for theMPLS TE core - Aggregate RSVP reservations (for the callsuse of such proprietary rights by implementers or users of this specification can be obtained fromone GWthe IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party toanother GW) are subjectbring toAdmission Control over the DSTE tunnels (as per the "RSVP Aggregation over TE Tunnels" procedures defined in this document) - Voice calls are subjectits attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required toCAC byimplement this standard. Please address theGW overinformation to theaggregate reservation towardsIETF at ietf-ipr@ietf.org. Acknowledgement Funding for theappropriate destination GW. This pushes even furtherRFC Editor function is currently provided by thescalability limits of this voice CAC architecture.Internet Society.