--- 1/draft-ietf-tsvwg-rsvp-dste-01.txt 2006-04-24 22:12:19.000000000 +0200 +++ 2/draft-ietf-tsvwg-rsvp-dste-02.txt 2006-04-24 22:12:19.000000000 +0200 @@ -6,22 +6,22 @@ Bruce Davie Cisco Systems, Inc. Michael Davenport Chris Christou Booz Allen Hamilton Jerry Ash Bur Goode AT&T - draft-ietf-tsvwg-rsvp-dste-01.txt - Expires: August 2006 February 2006 + draft-ietf-tsvwg-rsvp-dste-02.txt + Expires: October 2006 April 2006 Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels Status of this Memo By submitting this Internet-Draft, each author represents that any 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. @@ -250,20 +250,25 @@ corresponding end to end reservations) can be protected against failure through the use of MPLS Fast Reroute RSVP Aggregation over MPLS TE tunnels February 2006 This document, like [RSVP-AGG], covers aggregation of unicast sessions. Aggregation of multicast sessions is for further study. 1.1. Changes from previous versions + The changes from version draft-ietf-tsvwg-rsvp-dste-01 to version + draft-ietf-tsvwg-rsvp-dste-02 are: + - clarification in text describing handling of E2E Path + - added text on handling of E2E PathTear and ResvConf. + The changes from version draft-ietf-tsvwg-rsvp-dste-00 to version draft-ietf-tsvwg-rsvp-dste-01 of this draft address comments from the "RSVP Review team" and from the Working Group Last Call. The significant changes are: - added text in multiple sub-sections of section 3 to describe operations when the Aggregator and Deaggregator also behave as IPsec security gateways. - added text in section 3 to further clarify relationship with [LSP-HIER] - added text in section 8 to refer to some security @@ -288,29 +293,28 @@ - added definition of E2E reservation in section 2. - removed the case where E2E reservation is a TE tunnel (already covered in [LSP-HIER]) The significant changes from version draft-lefaucheur-rsvp-dste-01 to version draft-lefaucheur-rsvp-dste-02 of this draft were: - Alignment with RSVP operations of draft-ietf-mpls-lsp-hierarchy - Addition of an appendix providing an example usage scenario for information purposes + RSVP Aggregation over MPLS TE tunnels February 2006 + The significant changes from version draft-lefaucheur-rsvp-dste-00 to version draft-lefaucheur-rsvp-dste-01 of this draft were: - added discussion of the relationship to RFC 2746 [RSVP-TUN] - added discussion of mapping policy at aggregator - added discussion of "RSVP proxy" behavior in conjunction with the aggregation scheme described here - - RSVP Aggregation over MPLS TE tunnels February 2006 - - added discussion on TTL processing on Deaggregator 2. 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 @@ -337,31 +341,31 @@ Aggregator and Deaggregator. An E2E RSVP reservation may be a per-flow reservation. Alternatively, the E2E reservation may itself be an aggregate reservation of various types (e.g. Aggregate IP reservation, Aggregate IPsec reservation). See section 4 and 5 for more details on the types of E2E RSVP reservations. As per regular RSVP operations, E2E RSVP reservations are unidirectional. + RSVP Aggregation over MPLS TE tunnels February 2006 + 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 - RSVP Aggregation over MPLS TE tunnels February 2006 - 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 3. Operations of RSVP Aggregation over TE with pre-established Tunnels [RSVP-AGG] supports operations both in the case where aggregate RSVP reservations are pre-established and in the case where Aggregators and Deaggregators have to dynamically discover each other and dynamically establish the necessary aggregate RSVP reservations. @@ -389,30 +393,31 @@ The signaling aspects discussed in section 6.2 of [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 + + RSVP Aggregation over MPLS TE tunnels February 2006 + (instead of end-to-end TE LSPs) over the TE tunnels. This is covered further in section 3 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]. - RSVP Aggregation over MPLS TE tunnels February 2006 - Procedures in the case of dynamically established TE tunnels are for further studies. 3.1. Reference Model I----I I----I H--I R I\ I-----I I------I /I R I--H H--I I\\I I I---I I I//I I--H I----I \I He/ I I T I I Te/ I/ I----I I Agg I=======================I Deag I @@ -438,30 +443,31 @@ 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 Aggregation over MPLS TE tunnels February 2006 + RSVP preemption priority and the MPLS TE Tunnel set-up 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 towards the destination and if the policy is to map any E2E RSVP reservation onto TE Tunnels. - RSVP Aggregation over MPLS TE tunnels February 2006 - 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 towards 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 @@ -472,46 +478,47 @@ may be based on configured information, on information available in the MPLS TE topology database, on the current TE tunnel path, on information collected via RSVP-TE signaling, or combinations of those. 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. - The preferred method for the Aggregator to send the E2E Path message - is to 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. + 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. - An alternate method for the Aggregator to send the E2E Path is to - encapsulate the E2E Path message in an IP tunnel or in the TE tunnel - itself and unicast the E2E Path message to the Deaggregator, without - the Router Alert option. + Optionally, the Aggregator MAY also encapsulate the E2E Path message + in an IP tunnel or in the TE tunnel itself. - With both methods, 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], the IP Protocol number need not be modified - to "RSVP-E2E-IGNORE"; it MUST be left as is (indicating "RSVP") by - the Aggregator. + 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], the IP Protocol number need not 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 + + RSVP Aggregation over MPLS TE tunnels February 2006 + 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. - RSVP Aggregation over MPLS TE tunnels February 2006 + E2E PathTear and ResvConf messages MUST be forwarded by the + Aggregator to the Deaggregator exactly like Path messages. 3.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. 3.4. Receipt of E2E Path Message by Deaggregator On receipt of the E2E Path message addressed to it, the Deaggregator @@ -539,28 +546,28 @@ The Deaggregator MUST forward the E2E Path downstream towards 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. + RSVP Aggregation over MPLS TE tunnels February 2006 + 3.5. Handling of E2E Resv Message by 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. - RSVP Aggregation over MPLS TE tunnels February 2006 - On receipt of the E2E Resv, the Deaggregator MUST follow traditional RSVP procedures on receipt of the E2E Resv message. This includes performing admission control for the segment downstream of the Deaggregator and forwarding the E2E Resv message to the PHOP signaled earlier in the E2E Path message and which identifies the Aggregator. Since the E2E Resv message is directly addressed to the Aggregator 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. @@ -588,29 +595,28 @@ [RFC2205] 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. + RSVP Aggregation over MPLS TE tunnels February 2006 + 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 - - RSVP Aggregation over MPLS TE tunnels February 2006 - 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 @@ -629,35 +635,42 @@ described above. In the former case, admission control over the final TE tunnel (and forwarding of E2E Resv message upstream towards the sender) would only occur when the Aggregator receives 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 by Aggregator right away and if successful the E2E Resv message is generated upstream towards the sender. + On receipt of an E2E ResvConf from the Aggregator, the Deaggregator + MUST forward the E2E ResvConf downstream towards 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. + 3.7. Forwarding of E2E traffic by Aggregator + RSVP Aggregation over MPLS TE tunnels February 2006 + When the Aggregator receives a data packet belonging to an E2E 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. 3.8. Removal of E2E reservations - RSVP Aggregation over MPLS TE tunnels February 2006 - 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. 3.9. Removal of 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 @@ -744,22 +757,21 @@ 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 (3) the E2E reservation is a reservation for an IPsec protected flow. For example, where the flow is characterized by the as described in - [RSVP-IPSEC] -IPsec + [RSVP-IPSEC]. 6. Example Deployment Scenarios 6.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 very high numbers of hosts. In the example illustrated below, hosts generate end-to-end per-flow reservations for each of their video streams associated with a video-conference, each of their audio @@ -1010,60 +1022,59 @@ MPLS", RFC 2702, September 1999. [RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC 3209, December 2001. [DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of Diff-Serv-aware MPLS Traffic Engineering, RFC 4124, June 2005. [LSP-HIER] Kompella et al, Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic - Engineering (TE), RFC 4206 - , October 2005 + Engineering (TE), RFC 4206, October 2005 [SEC-ARCH] Kent and Seo, Security Architecture for the Internet Protocol, RFC 4301, December 2005 12. Informative References [DIFF-MPLS] Le Faucheur et al, MPLS Support of Diff-Serv, RFC3270, May 2002. [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- aware MPLS Traffic Engineering, RFC3564, July 2003. [6PE] De Clercq et al, Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE), work in progress [RSVP-IPSEC] Berger et al, RSVP Extensions for IPSEC Data Flows, RFC 2207 [RSVP-GEN-AGG] Le Faucheur et al, Generic Aggregate RSVP Reservations, - draft-lefaucheur-rsvp-ipsec, work in progress + draft-ietf-tsvwg-rsvp-ipsec, work in progress [RSVP-TUN] Terzis et al., RSVP Operation Over IP Tunnels, RFC 2746, January 2000 [RSVP-PREEMP] Herzog, Signaled Preemption Priority Policy Element, RFC 3181 [L-RSVP] Manner et al., Localized RSVP, draft-manner-lrsvp-04.txt, work in progress. [RSVP-PROXY] Gai et al., RSVP Proxy, draft-ietf-rsvp-proxy-03.txt (expired), work in progress. - RSVP Aggregation over MPLS TE tunnels February 2006 - [RSVP-APPID] Bernet et al., Identity Representation for RSVP, RFC 3182. + RSVP Aggregation over MPLS TE tunnels February 2006 + [AUTOMESH] Vasseur and Leroux, Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership, draft-vasseur-ccamp-automesh-00.txt, work in progress. [SIP-RSVP] Camarillo, Integration of Resource Management and Session Initiation Protocol (SIP), RFC 3312 13. Authors Address: @@ -1091,25 +1102,25 @@ Christou Christou Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 USA Email: christou_chris@bah.com Michael Davenport Booz Allen Hamilton + 8283 Greensboro Drive + McLean, VA 22102 RSVP Aggregation over MPLS TE tunnels February 2006 - 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 @@ -1137,24 +1148,24 @@ 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. - RSVP Aggregation over MPLS TE tunnels February 2006 - 15. Disclaimer of Validity + RSVP Aggregation over MPLS TE tunnels February 2006 + 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 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. 16. Copyright Notice @@ -1185,26 +1196,25 @@ reservations going from GW2 to GW2, PE2 serves as the aggregator/head-end and PE1 serves as the de-aggregator/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. The bandwidth request takes into account VoIP header compression, where applicable. As part of its Aggregator role, the PE router effectively performs admission control of the bandwidth request - - RSVP Aggregation over MPLS TE tunnels February 2006 - generated by the GW onto the resources of the corresponding DS-TE tunnel. + RSVP Aggregation over MPLS TE tunnels February 2006 + 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 towards the destination. Assuming there is enough bandwidth available on that tunnel, the PE adjusts its book-keeping of remaining available bandwidth on the tunnel and generates a Resv message back towards the GW to confirm resources have been reserved over the DSTE tunnel. @@ -1236,25 +1246,25 @@ `--. ,.__,| | IP/MPLS Network / '---'- ----' '`' '' ' .._,,'`.__ _/ '---' | | '`''' | C1 C2 Figure A1. Integration of SIP Resource Management, DSTE and RSVP Aggregation [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 RSVP Aggregation over MPLS TE tunnels February 2006 - 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, the RSVP bandwidth requests may be integrated into the call setup flow as follows (See call setup flow diagram in Figure A2): - Caller C1 initiates a call by sending a SIP INVITE to VoIP gateway GW1, which passes the INVITE along to the call control