HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 00:11:38 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 17 Mar 1998 16:31:00 GMT ETag: "2e9a74-9f3d-350ea544" Accept-Ranges: bytes Content-Length: 40765 Connection: close Content-Type: text/plain Internet Engineering Task Force R.Guerin/D.Kandlur/L.Li/V.Srinivasan INTERNET DRAFT IBM L.Berger Fore 30 July 1997 Support of Shortcuts for RSVP Flows Over ATM draft-guerin-issll-rsvp-shortcut-00.txt Status of This Memo This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the internet-drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract Support for RSVP flows across an ATM network has been defined in [BB97, GB97, Ber97a]. Although the use of shortcuts was mentioned in [BB97, Sec. 3.7], and [Ber97a, Sec. 3.6] the current specifications do not address this case in sufficient details so as to allow interoperable implementations. The purpose of this document is to identify issues in using ATM shortcuts for RSVP flows. For purposes of illustrations, the NHRP protocol [LKPC97] will be assumed as the mechanism used to discover shortcuts, and a possible interface between RSVP and NHRP will be outlined. However, it should be noted that other shortcut mechanisms are possible, e.g., PAR [J96], and the general conclusions of this document should also hold in such cases. Since the issue of shortcut discovery is significantly more complex in the multicast case, for which in most instances has not been defined, e.g., NHRP, this document is limited to the case of unicast flows. Guerin, et al. Expires 4 February 1998 [Page i] Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997 Contents Status of This Memo i Abstract i 1. Overview and Issue 1 1.1. General Design Principles . . . . . . . . . . . . . . . . 3 2. RSVP Shortcut Interactions 5 2.1. RSVP Control Message Handling . . . . . . . . . . . . . . 5 2.2. Data VC Operations . . . . . . . . . . . . . . . . . . . 7 2.3. Error Handling Scenarios . . . . . . . . . . . . . . . . 8 3. Sample RSVP-NHRP Interface 9 4. Interaction with MPOA 11 5. Example of RSVP Shortcut 12 Guerin, et al. Expires 4 February 1998 [Page ii] Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997 1. Overview and Issue In order to understand the implications of establishing and using shortcuts for RSVP flows across ATM networks, it is helpful to first review how shortcuts are established and used. For purposes of illustration, we focus on the case of the NHRP protocol (Next-Hop Routing Protocol) [LKPC97]. However, most of the conclusions would also hold when using other shortcut establishment mechanisms, e.g., PAR [J96]. NHRP is a next hop discovery protocol, that allows progressive discovery of the layer 2 addresses of layer 3 next hops for a given network (IP) destination address. In other words, NHRP allows a network layer protocol such as IP to propagate a query to determine whether, for a given destination (or sets of destinations), some of the network layer routing hops can be bypassed by establishing a shortcut across the layer 2 (ATM) topology. This is illustrated in Figure 1, where ATM switches are represented with triangles, while rectangles are used for IP routers. _ _ _ _ |_|R2 |_|R3 |_|R4 |_|R5 \ \ \ / \ \ \ / _ _s1 \_s3 \_s5 \ _/ _s8 _ R1|_|---/_\-------/_\---------/_\---------/_\----/_\-----|_|R6 \ | | / s7 / \ --- --- / / \ \ / / / \ _s2 \ _ / s6_ / / /_\--------/_\---------/_\------/ s4 Routed path: R1-(s1-s3)-R2-(s3-s5)-R3-(s5-s7)-R4-(s7)-R5-(s7-s8)-R6 Shortcut: R1-(s1-s2-s4-s6-s8)-R6 Figure 1: Routed Path vs Shortcut. Irrespective of whether they are obtained through NHRP or some other means, the potential benefits of shortcuts are to off-load network layer processing of the packets from the routing hops being bypassed, and also to possibly achieve better delay and/or throughput performance for the data flow between the source and the destination. In the case of RSVP flows, another benefit is the opportunity to Guerin, et al. Expires 4 February 1998 [Page 1] Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997 better leverage the layer 2 topology to support QoS requirements, i.e., improve the likelihood that the necessary resources (bandwidth and buffer) are available. There are two main aspects to the use of ATM shortcuts for RSVP. The first concerns the internal (within the router or the RSVP-ATM gateway) interactions between RSVP and the shortcut establishment mechanism, e.g., NHRP. The second, and possibly more important, aspect deals with the external flows associated with the establishment of shortcuts, and in particular their coexistence with existing uses of shortcut mechanisms, i.e., for non-RSVP flows. In many implementations, the decision to establish a shortcut for some best effort traffic flow is traffic dependent. For example, a shortcut request is triggered only when the traffic volume to the destination exceeds a certain threshold, and thus warrants the overhead (signaling and support of an additional VC) of setting up the shortcut. In addition, how long the shortcut remains in effect is also typically traffic dependent, so that a shortcut will be taken down if the amount of traffic falls below a given threshold, or after some time-out period. This means that the "routes" associated with shortcuts, in addition to violating network protocol rules by crossing subnet boundaries, are also temporary in nature. As a result, routes associated with shortcuts will normally NOT show-up in the "standard" IP routing table, and will only be reflected in the forwarding information base of the router. The limited visibility, to IP routing, of shortcuts has some implications for RSVP. Specifically, when RSVP queries IP routing to obtain the NHOP to which to send a packet, the route that is returned is the default (hop-by-hop) path and not the shortcut path. As a result, RSVP control packets will flow on the default hop-by-hop path, while the data packets of the associated flow will be forwarded on the existing shortcut, if any, together with the rest of the default traffic to that destination. However, if and when a reservation is made and the classifier in the IP forwarding fastpath is updated at the ingress router, the RSVP data packets will start being forwarded on the routed path which is where the reservation was made. In some instances, this may have the unfortunate effect that the user may see lower performance (higher delay) once the reservation is in place. This is clearly not desirable, and further motivates the need for allowing RSVP flows to also use shortcuts. As alluded to earlier, this requires the definition of an interface between RSVP and the shortcut mechanism, that will support the necessary interactions. In particular, RSVP, or the RSVP-ATM gateway, must be able to query the shortcut mechanism, and to request the establishment of a new shortcut VC. In addition, the management Guerin, et al. Expires 4 February 1998 [Page 2] Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997 of shortcuts for both RSVP and best-effort traffic to the same destination needs to be coordinated, and this requires additional interactions between RSVP and the shortcut mechanism. Before proceeding with more detailed discussions on each of these aspects, we briefly review some of the general design issues and choices in using shortcuts for RSVP flows. 1.1. General Design Principles The main design principle followed in this document to support shortcuts for RSVP flows is: Separate but consistent shortcuts for RSVP data and control messages. There are several implications of this principle. 1. Receipt of an RSVP PATH message will trigger the establishment of a best-effort shortcut unless one is already in place for the same destination. Note that in the case where a shortcut is already in place, it may be necessary to verify that this existing shortcut is adequate, i.e., whether or not a more appropriate shortcut might be available for the destination address of the RSVP flow. This implies that for every new flow, RSVP should always check for the most appropriate shortcut to the flow's destination. In the case of NHRP, in order to ensure that the most appropriate shortcut possible is indeed returned, e.g., that the query is propagated as far as possible, some extensions to the current NHRP operation are desirable. Specifically, it would be useful to introduce and use QoS fields in NHRP queries (1) to carry the traffic information (TSpec) present in the RSVP PATH message. This information could then be used at each (NHRP) node as a "hint" to keep forwarding the query, so as to yield the "longest" possible shortcut consistent with the QoS requirements. For example, a bandwidth threshold may be used to decide which flows to forward over the hop-by-hop path and which to send over a separate shortcut. ---------------------------- 1. Note that such fields were present in earlier versions of the NHRP draft, but were dropped because their use was not fully specified at the time. Guerin, et al. Expires 4 February 1998 [Page 3] Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997 It should be noted that the availability of a best-effort shortcut VC means that the data packets associated with the RSVP flow will also be able, if permitted (more on this in Section 2), to use the short and, therefore, bypass intermediate router hops as well. 2. In order to allow the eventual establishment of a QoS shortcut VC on which to forward the data packets of an RSVP flow, the PATH messages must be forwarded over a shortcut VC with the same endpoint. 3. Best-effort shortcuts should not be taken down as long as any (associated) RSVP flow remains active, i.e., have a valid path state. This is required to ensure consistency between the forwarding of RSVP control and data packets. It means that the best-effort shortcut VC must stay in place as long as it is needed to forward RSVP control messages. In particular, the best-effort shortcut VC should not be taken down because of low traffic volume as is often the case in current implementations of shortcut mechanisms, e.g., NHRP. Note that a best-effort shortcut can be used to forward RSVP control messages associated with multiple RSVP flows, i.e., when the associated shortcut end-point is the same for all the flows. As a result, the shortcut must remain in place at least until all the flows have been removed. 4. Upon receipt of a RESV message, a new QoS shortcut VC is setup with the same end-points as the existing best-effort shortcut, but with the appropriate QoS characteristics based on the content of the RESV message. 5. A QoS shortcut VC should remain active as long as the associated RSVP reservation does. Implicit here is the fact that "management" of a QoS shortcut is closely coupled to the state of the associated RSVP flow. However, responsibility for actually managing the QoS shortcut VCs can lie either with RSVP or with the shortcut mechanism itself. For example, in the case of NHRP which is already responsible for managing best-effort shortcuts, one may want to extend this to also include management of QoS VCs. On the other hand, in order to easily support multiple shortcut mechanisms, it might be desirable to keep management of QoS shortcuts under the responsibility of RSVP, or rather of the "ATM gateway" responsible for establishing VCs on behalf of RSVP. Note that in this case, it is still necessary to maintain coordination between the best-effort and QoS shortcut VCs as outlined above. Guerin, et al. Expires 4 February 1998 [Page 4] Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997 In the next two sections, we elaborate on the interactions between RSVP and the shortcut mechanism, in terms of both external and internal exchanges. In Section 2, we specify more precisely the implications of RSVP shortcuts in terms of the associated message flows between entities on each end of the shortcut. In Section 3, we illustrate, for the case of NHRP, a possible interface between RSVP and the shortcut mechanism. 2. RSVP Shortcut Interactions This section covers the interactions between hosts and/or routers that take place in order to enable the use of shortcuts for RSVP flows. In particular, it describes how and which VCs are used by RSVP control messages, e.g., PATH and RESV messages, how and when shortcut VCs are established to support RSVP flows, and finally how certain VC setup error scenarios are handled. 2.1. RSVP Control Message Handling In order to properly coordinate the forwarding of RSVP data packets on a shortcut VC with the associated RSVP control messages, it is useful to distinguish between downstream and upstream RSVP control messages. According to the RSVP specification [BZB+97], downstream messages, e.g., PATH messages, flow from the sender to the receiver(s), while upstream messages, e.g., RESV messages, flow hop-by-hop (from next hop to previous hop) back towards the sender(s). As mentioned earlier, in this draft we limit ourselves to unicast flows (single ingress and egress points for the ATM network). Ensuring consistent RSVP reservation states and forwarding of RSVP data packets on a shortcut VC, requires proper coordination between the shortcut end-points and the forwarding of RSVP control messages. In particular, as mentioned in Section 1.1, it is key that downstream messages, i.e., PATH messages, have previous and next hops that match the end-points of the shortcut. For example, in Figure 1, when the shortcut R1-R6 is used for an RSVP data flow, the associated RSVP control messages sent by R1 must be sent directly to R6 without using the intermediate routed path R2-R3-R4-R5. If messages passed in the downstream direction are sent hop-by-hop and the data is sent via a shortcut, the receiver may not be able to properly handle the data and extra resources may be allocated in the intermediate routers R2, R3, R4, and R5. This restriction does not apply to messages sent in the upstream direction, i.e., RESV messages, that can be sent on either the shortcut or the hop-by-hop paths (see [Ber97a] for details). Guerin, et al. Expires 4 February 1998 [Page 5] Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997 Given the importance of ensuring that downstream control messages are delivered directly to the same endpoint as that of the shortcut, we now review the different cases that must be considered and the appropriate actions for each of them. There are three different scenarios that a sender (ATM ingress point) can face: 1. A shortcut to the (session) destination does not exist for best-effort traffic, and establishment of such a best-effort shortcut to this destination is administratively permitted. 2. A shortcut already exits for best-effort traffic to the (session) destination. 3. A shortcut to the (session) destination does not exits for best-effort traffic, and establishment of such a best-effort shortcut to this destination is administratively prohibited. Note that we assume that administrative control of shortcuts is part of the shortcut support mechanisms, such as NHRP, and is outside the scope of this document. Furthermore, it is assumed that RSVP can be notified when a best-effort shortcut is administratively prohibited. The first case occurs when no shortcut exists and the sender is administratively permitted to create a shortcut VC for use by best-effort data traffic to the same destination address as the RSVP control message. In this case, there are two possible approaches that the sender can follow. A first approach is to setup the "best-effort" VC at the time the first control message (PATH) arrives, and wait until the best-effort shortcut is established before forwarding the message downstream. The second approach is to immediately forward the control message (PATH) via the hop-by-hop path, and to proceed in parallel with the establishment of the best-effort shortcut. Once the "best-effort" shortcut is established, forwarding of control messages can then be switched over to the shortcut. Downstream RSVP processes will detect the path change and update their internal state appropriately. This latter approach has the disadvantage that additional resources may be allocated along the hop-by-hop path prior to the shortcut being established. In either case, the newly established shortcut VC must be maintained for as long as there remains RSVP control traffic to be forwarded downstream, i.e., the VC should not be timed out or taken down for lack of activity as long as the RSVP PATH state remains in effect. The second case occurs when a shortcut already exists for use by best-effort data traffic to the same destination address as an RSVP control message, i.e., the entry in the forwarding information base of the router, that corresponds to the destination address of the Guerin, et al. Expires 4 February 1998 [Page 6] Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997 RSVP message, indicates that it is a shortcut. In this case, the first step that needs to be performed is to "revalidate" the existing shortcut. As stated earlier, this revalidation is necessary as in some instances the shortcut mechanism may select different end-points for a shortcut depending on the nature of the traffic that is to use the shortcut. Revalidation of the shortcut also depends on the type of shortcut mechanism used. In case the shortcut is not validated, the sender finds itself in a similar situation as that of the previous case. Assuming the shortcut has been validated, the sender can then simply forward downstream RSVP control messages on the existing shortcut VC. However, as before, the sender must also make sure that the existing best-effort shortcut is not released while still being needed to forward RSVP control messages. The third and last case occurs when no shortcut exists, and the sender is administratively prohibited from creating a best-effort shortcut VC to the same destination address as the RSVP control messages. However, QoS shortcut VCs are allowed and could be used by RSVP flows. For example, this could be the case when crossing administrative domain boundaries. In order to enable the use of QoS shortcuts by RSVP flows in such instances, it is necessary to create a special VC to the shortcut endpoint for use solely by RSVP control messages that are to be sent downstream. As in the first case, the sender can forward the first PATH message downstream either before or after the VC has been successfully established. Similarly, the control shortcut VC must again be maintained for as long as there are RSVP control messages to be passed downstream. 2.2. Data VC Operations Shortcut data VCs are setup and maintained in essentially the same fashion as described in [Ber97a, Ber97b]. The only but significant difference is that the ATM called party used in VC setup matches the shortcut endpoint. As in the case of hop-by-hop operation, the setup of a QoS data VC is triggered by the receipt of the first RESV message. The fact that a shortcut will be used can be detected by realizing that the next hop, as per the IP source address in the RESV message, is on a different subnet, and by the fact that a "control shortcut VC" already exists to this next hop. When the RESV message is received by RSVP, a QoS VC to the shortcut endpoint is then initiated. In establishing the QoS shortcut VC, the RSVP process should follow the same recommendations as stated in [Ber97a], specifically using independent VCs for each RSVP reservation. The RSVP process should also follow the same recommendations and requirements as stated Guerin, et al. Expires 4 February 1998 [Page 7] Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997 in [Ber97b]. This includes the ability to handle changes in QoS requests and negotiate appropriate encapsulation. 2.3. Error Handling Scenarios There are a number of error scenarios that need to be handled by RSVP when using shortcuts. The first error scenario is when the shortcut VC used to forward RSVP control messages is abnormally released and cannot be reestablished. In this case there is no other choice but to send RSVP control messages hop-by-hop. When this occurs and no RSVP associated QoS VCs exists, no other special actions is required. However, when this occurs AND there are RSVP associated QoS VCs (there could be more than one), then those VCs MUST be released. The release of the associated data VCs is required to maintain the synchronization between forwarding and reservation states for the associated data flows. A second error scenario occurs when the setup of the QoS data VC associated with an RSVP flow fails. In this case, a shortcut with the required QoS is not available, but a best-effort VC has been successfully established to forward the RSVP control messages. Since the desired QoS cannot be satisfied using a shortcut, the sender SHOULD stop sending the RSVP control messages over the best-effort shortcut and start sending them on the hop-by-hop path. This will eventually allow the reservation to be attempted on the hop-by-hop path. The best-effort shortcut VC used for control messages may be released or maintained based on its other uses. For example, it may still be used to forward RSVP control messages associated with other flows which did successfully setup a QoS shortcut to the same endpoint. Note that the sender may want to regularly retry establishing a shortcut based path, especially if the reservation is also unsuccessful on the hop-by-hop path. The last error scenario to consider is that of a VC setup failure when processing a change in an RSVP reservation. This case is handled exactly the same way as is described in [Ber97b, Section 2.4]. The old QoS VC MUST continue to be used. When the new reservation is greater than the old reservation, the reservation request MUST be answered with an error. When the new reservation is less than the old reservation, the request MUST be treated as if the modification was successful. Implementations SHOULD retry replacing the too large VC after some appropriate elapsed time. In the next section, we provide an example of a possible interface between RSVP and the shortcut mechanisms, when NHRP is assumed for Guerin, et al. Expires 4 February 1998 [Page 8] Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997 the latter. This interface is only intended as a possible guideline and not meant to imply specific implementations requirements. 3. Sample RSVP-NHRP Interface An interface between RSVP and NHRP should allow determination of appropriate shortcut endpoints for different RSVP flows, support coordination between best-effort and QoS VCs used for the same flow, and accommodate handling of error scenarios. In the context of the interface outlined in this section, we assume that RSVP (the RSVP-ATM gateway) is responsible for the establishment of QoS shortcut VCs. As a result, interactions between NHRP and RSVP are limited to dealing with best-effort VCs. - RSVP_shortcut_resolve(flow_ID, IP_address, TSpec, return_code, BE_VC_handle, endpoint_ATM_address) This is a query from RSVP to NHRP to request the most appropriate shortcut possible towards reaching IP_address. Note that if a shortcut already exists to the destination, NHRP may need to revalidate it based on the new TSpec specified in the call. * flow_ID: identifies the flow for future reference. * IP_address: unicast IP address of the destination specified in the PATH message. * TSpec the traffic specification for the RSVP flow. This information may be carried in the QoS field of the NHRP request. * return_code: because resolution of the query and establishment of a new VC, if necessary, will take time, the return_code can take three different values: success/pending/failed. * BE_VC_handle: this value is only meaningful when return_code = success, and identifies to RSVP the best-effort VC associated with the flow. Implicit here is the fact that both RSVP and NHRP are now aware that the states of the VC associated with BE_VC_handle and of the RSVP flow identified by flow_id need to be coordinated. Note that a best effort VC could be associated with multiple flows, and NHRP could return the same or different handles for each flow. * endpoint_ATM_address: ATM address of the endpoint to which the best-effort VC was established. RSVP will use this Guerin, et al. Expires 4 February 1998 [Page 9] Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997 address to subsequently request the setup of a QoS VC upon receipt of an associated RESV message. - NHRP_shortcut_resolve(flow_ID, return_code, BE_VC_handle, endpoint_ATM_address) This is an asynchronous response to an earlier query by RSVP, i.e., one for which return_code = pending. * flow_ID: used by RSVP to correlate the response with the original query. * return_code: is either success or failed. * BE_VC_handle: in case return_code = success, identifies to RSVP the best-effort VC associated with the flow. Again, implicit here is the fact that both RSVP and NHRP are now aware that the states of the VC associated with BE_VC_handle and of the RSVP flow identified by flow_id need to be coordinated. Note that a best effort VC could be associated with multiple flows, and NHRP could return the same or different handles for each flow. * endpoint_ATM_address: ATM address of the endpoint to which the best-effort VC was established. RSVP will use this address to subsequently request the setup of a QoS VC upon receipt of an associated RESV message. - RSVP_shortcut_refresh (flow_id, BE_VC_handle, return_code) Used by RSVP to notify NHRP that an existing best-effort shortcut VC, previously established for a given RSVP flow, should be maintained independent of the volume of traffic it carries. Note that this function need not be supported through such an interface, and could be provided through local status bits that NHRP could query. * flow_id: initially assigned by RSVP to identify the flow. * BE_VC_handle: handle provided by NHRP after establishing the best-effort VC. * return_code: can be success or an error code (tbd) in case RSVP is trying to refresh a non-existing VC. - RSVP_shortcut_take_down (flow_id, BE_VC_handle) Guerin, et al. Expires 4 February 1998 [Page 10] Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997 Used by RSVP to notify NHRP that an existing best-effort shortcut VC, associated with a given flow, can be taken down. This need not trigger the actual take down of the VC in cases where the same best-effort VC is used to carry control messages of multiple RSVP flows, or if NHRP decides to keep the VC up to continue carrying best-effort data traffic. However, in the latter case, NHRP is responsible for removing any association between RSVP flows and the best-effort VC. * flow_id: initially assigned by RSVP to identify the flow. * BE_VC_handle: handle provided by NHRP after establishing the best-effort VC. - NHRP_BE_VC_failure(BE_VC_handle, error_code) Used by NHRP to notify RSVP of the failure of an existing best-effort VC. RSVP is responsible for taking down all associated QoS VCs. * BE_VC_handle: handle originally used by NHRP to identify the best-effort VC. * return_code: indicates the type of failure if known. 4. Interaction with MPOA In the ATM Forum's Multiprotocol Over ATM (MPOA) model, shortcuts are established between MPOA Clients (MPCs) on edge devices, or between an MPC and an NHRP Client (NHC). When an internetwork layer packet (e.g., IP packet) arrives over a shortcut VC to an MPOA edge device, the MPC looks up the internetwork layer destination address in the packet in a local cache to obtain DLL information to place on the packet. The DLL information is prepended to the packet and the frame is transferred to a LAN Emulation client for further handling. When using the scheme described in this draft for establishing shortcuts with QoS, it is possible that multiple shortcuts may be established to the same MPC with traffic from different RSVP flows to the same IP destination. Furthermore, it may be desirable to place different DLL headers for packets arriving over different VCs (e.g., with different values of priority in the token ring header, or in the IEEE 802.1p header), depending on the QoS required for the flow. The MPOA specification already allows for this possibility. The egress MPC simply needs to assign a different "tag" for each RSVP flow that it is terminating. This tag is carried in the packets arriving over the shortcuts to the edge device, and may be used to index in to Guerin, et al. Expires 4 February 1998 [Page 11] Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997 different entries in the local cache. Thus, the scheme described in this draft is compatible with MPOA as well. It is for further study whether full PATH state needs to be stored on the edge devices or not. The MPOA Server (MPS) may be able to store the PATH state, thus allowing for building of simpler edge devices. 5. Example of RSVP Shortcut In this last section, we briefly outline a possible set of events involved in the establishment of a shortcut for an RSVP flow. Referring to Figure 1, we assume a sending host H1 connected through a series of networks and routers to router R1 (ingress router to the ATM network), and a destination host H2 connected to router R6 (egress router from the ATM network) through again possibly a series of routers and networks. - Host H1 starts sending PATH messages. - First PATH message arrives at R1 which extracts the IP address of H2 and the TSpec of the flow and queries its local NHRP using RSVP_shortcut_resolve(). - NHRP generates an NHRP query for the IP address of host H2 and specifies using the NHRP QoS field, that the query should be resolved in the most specific and feasible manner, i.e., the ATM address of router R6 should be returned. NHRP responds to the RSVP query with a return_code = pending. - NHRP receives a response to its query. It could either correspond to an existing VC to R6 or require the establishment of a new VC. If the latter, NHRP proceeds with setting-up a new best-effort VC. - NHRP informs, using NHRP_shortcut_resolve(), that the best effort VC to R6 has been established (or not established) by returning the appropriate return_code. In what follows, we assume the best effort VC has been successfully established, so that NHRP also returns the ATM address of R6 to RSVP and the handle corresponding to the VC. - RSVP starts forwarding PATH messages on the newly establish shortcut VC to R6. Here we assume that R1 held back forwarding of PATH messages until after the establishment of the best-effort shortcut VC. Note that data packets for H2 will also be forwarded on the shortcut VC. Guerin, et al. Expires 4 February 1998 [Page 12] Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997 - PATH message arrives at R6 with its PHOP set to R1. R6 creates the appropriate path state and proceeds to forward the PATH message towards H2. - H2 receives the PATH message. It decides to make a reservation and starts sending RESV messages. - First RESV message arrives at R6 which (assuming the local reservation is successful), which forwards it to R1 since it has the IP address of R1 in its PHOP field. - RESV message is received by RSVP at R1, which then requests the establishment of a QoS VC to R6 using the ATM address returned by NHRP in NHRP_shortcut_resolve(). The request specifies a service class and traffic parameters based on the information contained in the RESV message. - Once notified of the success of the setup of the VC, RSVP proceeds to update the classifier at R1 to ensure that RSVP data packets are forwarded on the new VC. R1 also forwards the RESV message towards H1. - As long as the associated RESV state remains alive, RSVP at R1 keeps the QoS VC to R6 up and also makes sure that the associated best-effort VC remains up. - When the reservation is eventually taken down, say, by H2 issuing a RESV_TEAR, RSVP at R1 takes down the QoS VC to R6 and removes the associated classifier entry. Data packets start then being forwarded on the best effort shortcut VC to R6. - As long as the PATH state remains alive, RSVP at R1 keeps refreshing the associated best-effort shortcut VC to R6 using RSVP_shortcut_refresh(). - When the PATH state is removed, e.g., by receiving a PATH_TEAR initiated by H1, RSVP at R1 notifies NHRP using RSVP_shortcut_take_down() with the flow_id and VC_handle corresponding to the best effort shortcut VC associated with the flow. NHRP can then decide to either take the VC down or to keep it up. Acknowledgment The authors gratefully acknowledge inputs from Steve Nadas, Anoop Ghanwani, Steven Blake, Girish Bhat, and Ed Bowen. Guerin, et al. Expires 4 February 1998 [Page 13] Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997 References [BB97] S. Berson and L. Berger. IP Integrated Services with RSVP over ATM (draft-ietf-issll-atm-support-03.txt). INTERNET-DRAFT, Internet Engineering Task Force, ISSLL Working Group, March 1997. [Ber97a] L. Berger. RSVP over ATM Implementation Guidelines (draft-ietf-issll-atm-imp-guide-01.ps,txt). INTERNET-DRAFT, Internet Engineering Task Force, ISSLL Working Group, July 1997. [Ber97b] L. Berger. RSVP over ATM Implementation Requirements (draft-ietf-issll-atm-imp-req-00.ps,txt). INTERNET-DRAFT, Internet Engineering Task Force, ISSLL Working Group, July 1997. [GB97] M. Garrett and M. Borden. Interoperation of Controlled Load and Guaranteed Service with ATM (draft-ietf-issll-atm-mapping-02.txt). INTERNET-DRAFT, Internet Engineering Task Force, ISSLL Working Group, March 1997. [J96] J. Jeffords (ed.). PNNI Augmented Routing (PAR) v1.0 Specification. ATM Forum BTD-PNNI-PAR-01.00, December 1996. [LKPC97] J. V. Luciani, D. Katz, D. Piscitello, and B. Cole. NBMA Next Hop Resolution Protocol NHRP (draft-ietf-rolc-nhrp-11.txt). INTERNET-DRAFT, Internet Engineering Task Force, ROLC Working Group, March 1997. [BZB+97] R. Braden (Ed.), L. Zhang, S. Berson, S. Herzog, and S. Jamin. Resource reSerVation Protocol (RSVP) version 1, functional specification (draft-ietf-rsvp-spec-16.ps). INTERNET-DRAFT, Internet Engineering Task Force - RSVP WG, June 1997. Guerin, et al. Expires 4 February 1998 [Page 14] Internet Draft ATM Shortcuts for RSVP Flows 30 July 1997 Authors' Address Roch Guerin Dilip Kandlur IBM T.J. Watson Research Center IBM T.J. Watson Research Center P.O. Box 704 P.O. Box 704 Yorktown Heights, NY 10598 Yorktown Heights, NY 10598 EMAIL: guerin@watson.ibm.com EMAIL: kandlur@watson.ibm.com VOICE +1 914 784-7038 VOICE +1 914 784-7722 FAX +1 914 784-6205 FAX +1 914 784-6205 Liang Li Vijay Srinivasan IBM Corporation IBM Corporation P. O. Box 12195 P. O. Box 12195 Research Triangle Park, NC 27709 Research Triangle Park, NC 27709 EMAIL: lli@raleigh.ibm.com EMAIL: vijay@raleigh.ibm.com VOICE: +1 919 254-5627 VOICE: +1 919 254-2730 FAX: +1 919 254-5483 FAX: +1 919 254-5410 Lou Berger FORE Systems 6905 Rockledge Drive Suite 800 Bethesda, MD 20817 EMAIL: lberger@fore.com VOICE: +1 301 571 2534 Guerin, et al. Expires 4 February 1998 [Page 15]