Internet Draft Internet Draft Tag Switching with RSVP December 1996 Fred Baker Yakov Rekhter December 1996 Tag Switching with RSVP draft-baker-tags-rsvp-00.txt 1. 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. Internet Drafts 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." Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. 2. Abstract In this document we present a specification for binding RSVP flows to tags, and to distributing tag binding information for these tags by using RSVP messages. 3. Motivation The purpose of this document is to propose a standard method for hosts and routers that support tag switching and RSVP to use the RSVP Protocol [RSVP] to associate RSVP flows with tags. Specifically this document presents an addendum to Subsection 3.2 "Sending RSVP Messages" of the RSVP Specification. It also defines a new RSVP Object, RSVP_TAG, to carry the tag identifier. While there are several alternatives to mapping RSVP sessions to tags, this document specifies a "one tag per session" model, in which each RSVP session creates a new tag. This model has the following advantages: Baker & Rekhter [Page 1] Internet Draft Tag Switching with RSVP December 1996 (1) If tags are mapped into data link constructs, the model exploits the traffic control and scheduling capabilities of the data link, with their hardware or firmware mechanisms. (2) It reduces the network level processing load by removing the need for multiplexing of RSVP sessions onto a connection. This is not to preclude the aggregation of flows onto a smaller set of tags. Indeed, aggregation is a useful improvement. However, to be honest, we are not sure how to do that yet. The it would be correct and valid to do if the behavior of the network is indistinguishable from the first case. For this to be true, negotiated QoS features would continue to be observed, policing of some flows does not affect the policing of other flows, and the set of destinations to which each flow is delivered remain the same. This model works well when the receiving end-point of the connection or intermediate network elements are made aware of the association between the RSVP session and the tags. For example, in the case of an intermediate network element the tag constitutes a mechanism for pre-sorting packets to their network level session. This can assist the network device in performing appropriate forwarding and scheduling actions at very high speeds, by leveraging data link level capabilities. Similarly, an end-station can exploit the tag in de- multiplexing arriving packets to their appropriate application. This early de-multiplexing reduces latency and processing overheads within the end-station, thereby improving the performance of multimedia applications. Moreover, when the consuming application endpoint is a device within the end-station (such as a graphics display adapter), the tag can direct packets to the device. Since RSVP flows establish and maintain their associated tags, we think it is logical to ask RSVP to convey tag information between the endpoints. Moreover, RSVP messages contain all the elements necessary to identify the data flows that are tagged. Baker & Rekhter [Page 2] Internet Draft Tag Switching with RSVP December 1996 4. Specification As mentioned above, in a tag switching environment it is desirable to associate each RSVP flow with a tag. An RSVP flow [RSVP] is a simplex flow from a sending application to a set of receiving applications identified by an IP address, and a session may contain several flows. An RSVP reservation may be flow specific (fixed filter) or shared across flows (shared explicit and wildcard). The association of flows to tags may be one-to-one or many-to-one and would be influenced by several factors. These factors include the type of reservation, the routing protocols used (unicast, multicast with shared trees, or multicast with source-specific trees), local forwarding capabilities, etc. For example, it is logical to create a one-to-one mapping for flow specific reservations since this would enable the separate treatment of individual flows. The association between RSVP flows and tags involves the allocation of a tag to a flow, initiated either by the upstream or downstream node. There are benefits with both choices of initiator, and the approach described in this document can be used to support either scheme. We view the best use of upstream allocation as the means that the upstream router can indicate which tag value it is using to identify the flow. In cases where this is important (multicast flows), we expect that tag allocation occurs outside the context of RSVP, and the tag is carried for the convenience of the system receiving the PATH message. Downstream allocation is the preferred approach for unicast flows, which have no obvious external mechanism for tag negotiation, and for which downstream tag selection simplifies the algorithm. In the case of upstream allocation, RSVP PATH messages carry the information needed to associate RSVP flows with tags. In the case of a per-flow downstream allocation, RESV messages would instead carry the tags of the flows to which they apply. In both cases, as the tag identifies data from a specific sender to a set of receivers, the tag immediately follows the FILTER_SPECIFICATIONs in the RESV or the SENDER_TEMPLATE in the PATH message. In the case of a wildacrd filter (which has an implied SENDER_TEMPLATE and FILTER_SPECIFICATION), RSVP_TAG immediately follows the FLOW_SPECIFICATION. The RSVP_TAG object class, encoded in accordance with RSVP Object descriptions, has the following encoding: Baker & Rekhter [Page 3] Internet Draft Tag Switching with RSVP December 1996 RSVP_TAG class = xx, C_Type = Tag-Information +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In the upstream allocation mode, both the upstream and downstream nodes store the RSVP_TAG in the Path State Tables. (1) When the downstream node sends a RESV message, it acknowledges the association by including a the tag value specified by the upstream node in the RSVP_TAG object. At that point, the upstream node may start forwarding data using the tag. (2) If no RSVP_TAG value is present in the RESV message, the downstream node is not prepared to forward based on the tag value. (3) If an RSVP_TAG value is present, but the tag value differs, the downstream node is indicating either that it has not received a new tag value or that the tag value requested is unacceptable. (4) If the upstream node receives two successive RESVs with variant tag values from the same downstream node, it must assume the latter case and change the value it is advertising. A logical choice of value would be one of the values offered by downstream nodes, but the upstream node may select other values. The downstream allocation mode is useful for unicast sessions in which the QoS characteristics of a flow differ from the best effort characteristics of the standard tagged routes. The node that expects to receive the traffic assigns the tag values. The RESV's RSVP_TAG object indicates the tag value that the receiver wants used with the flow. If it is absent, the implication is that no tag value is assigned; if one was previously assigned it is now not in use. The sender may acknowledge in the PATH message, but the acknowledgment has no real value. Baker & Rekhter [Page 4] Internet Draft Tag Switching with RSVP December 1996 5. Example The figure below shows a simple example network in which two IP hosts H1 and H2 communicate through a sequence of tag switched routers (TSR1, TSR2). +------+ +------+ +------+ | +------+ | H1 |-----| TSR1 |-----| TSR2 |--|--| H2 | +------+ +------+ +------+ | +------+ 5.1. Upstream allocation H1 sends an RSVP PATH message to TSR1 using the mechanisms outlined in this document. The PATH message carries the tag allocated by H1 in the RSVP_TAG Object as shown above. When TSR1 receives the PATH message from H1, it performs its normal RSVP processing and also creates a Path State Table entry that includes the tag value carried in the RSVP_TAG object. TSR1 then forwards the PATH message to TSR2 and specifies in the RSVP_TAG object the tag value to be used between TSR1 and TSR2 for the flow. TSR1 also stores this value in the Path State Table entry. As with TSR1, when TSR2 receives the PATH message, it creates a Path State Table entry that includes the tag value carried in the RSVP_TAG object. TSR2 then forwards the PATH message to H2 and specified in the RSVP_TAG object the tag value to be used between TSR2 and H2 for the flow. H2 determines that it would like to setup a Reservation for this particular session, that is, it sends a RESV message with an RSVP_TAG object that carries TSR2's tag value. When TSR2 receives this message, along with normal RSVP processing, it retrieves from the corresponding Path State Table entry the values of the tags it sent to H2 and received from R1, respectively. These tags will then be used to identify packets arriving from TSR1, and forward them to H2. TSR2 then sends the RESV message to R1, this time with TSR1's tag value in the RSVP_TAG object. When TSR1 receives the RESV message, it also retrieves tag information from the corresponding Path State Table entry. It uses this to allocate resources and ensure that packets arriving with the specified tag value from H1 are directly forwarded with the corresponding tag value on the link to TSR2. TSR1 similarly forwards the RESV message to H1; upon receiving the message H1 proceeds to start sending the session's data with the tag it allocated on the link to TSR1. Baker & Rekhter [Page 5] Internet Draft Tag Switching with RSVP December 1996 5.2. Downstream allocation - unicast flow Following RSVP procedures, H1 sends an RSVP PATH to H2. The PATH message traverses through TSR1 and TSR2. H2 determines that it would like to setup a Reservation for this particular session, so H2 allocates a tag, and sends a RESV message to TSR2. The RESV message carries the value of the allocated tag in the RSVP_TAG object. When TSR2 receives this message, along with normal RSVP processing, it stores the value of the tag (carried in the RSVP_TAG object) as part of the Path State Table entry corresponding to the RESV message. TSR2 then allocates a tag, and sends a RESV message to TSR1. The message carries the value of the tag allocated by TSR2 in the RSVP_TAG object. When TSR1 receives this message, along with normal RSVP processing, it stores the value of the tag. TSR1 similarly allocates a tag, and places the tag into the RSVP_TAG object of the RESV message that TSR1 sends to H1. Upon receiving the message H1 proceeds to start sending the session's data with the tag received in the RESV message. 6. Security Considerations Security issues are not discussed in this document. We presume that the security procedures defined for RSVP will handle any security issues that arise with coupling tag switching with RSVP. 7. Acknowledgments We would like to acknowledge Roch Guerin, Dilip Kandlur, and Doug Williams for their help. Baker & Rekhter [Page 6] Internet Draft Tag Switching with RSVP December 1996 8. References [WGK] Virtual Circuit Identification Support for an RSVP-based Service, draft-williams-issll-vcuse-00.txt, Internet Draft, September 1996. 9. Author Information Fred Baker 519 Lado Drive Santa Barbara, California 93111 fred@cisco.com (408)526-4257 Yakov Rekhter 170 West Tasman San Jose, California yakov@cisco.com (408)527-0918 Baker & Rekhter [Page 7]