[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/