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

Versions: 00

Internet-Draft                                          Arun Viswanathan
Expires: September 1997                                 Vijay Srinivasan
                                                               IBM Corp.

                                                              March 1997





                          Soft State Switching
           A Proposal to Extend RSVP for Switching RSVP Flows

                  <draft-viswanathan-aris-rsvp-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 inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "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 ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


Abstract

   This memo describes a mechanism for establishing a switched path with
   guaranteed Quality of Service for RSVP [1] flows in an integrated
   switch-router environment.  It proposes an extension to the RSVP
   protocol that allows establishment of a sequence of virtual
   connections along the hop-by-hop routed path by enabling adjacent
   nodes to exchange Layer-2 labels.  The labels correspond to
   information that identifies the virtual connections; for example, the
   VPI/VCI value in the case of an ATM-based Layer-2 infrastructure.



Viswanathan, et al.     Expires: September 1997                 [Page 1]


Internet-Draft            Soft State Switching                March 1997


1. Introduction

   An Integrated Switch-Router (ISR) is a switching node that has an IP
   Control Point (IP-CP) and implements a IP switching technology [2-4].
   The ISRs form adjacencies through a well-known virtual circuit (VC),
   also called the default VC, that terminates at the adjacent ISR's
   IP-CP.  This hop-by-hop VC connectivity gives a cloud of ISRs the
   same nature as any ubiquitous IP internet.  The objective is to
   switch RSVP flows in such an environment.

   This document proposes an extension to RSVP that introduces new
   objects to the existing RSVP messages.  Using these objects, each
   downstream ISR provides its neighboring upstream ISR with the Layer-2
   (L2) label on which it wishes to receive a RSVP flow.  In an ATM-
   based ISR environment, this label would correspond to a VPI/VCI value
   for the ATM virtual circuit on which the ISR wishes to receive
   traffic from the RSVP flow.  Then, using an approach similar to those
   outlined in [2], [3], and [4], the L2 labels are spliced hop-by-hop
   to form an end-to-end VC.  The data from the RSVP flow then uses this
   this end-to-end VC, and the RSVP signalling messages are forwarded
   through the default VC.  By moving RSVP flows from the default VCs to
   a dedicated end-to-end VC, it is possible to leverage the QoS
   capabilities of the underlying L2 technology to provide the type of
   service desired for the RSVP flow.

   In this memo the term virtual circuit (VC) is used loosely to imply a
   switched data path under any switching technology that has the
   ability to isolate flows from each other, e.g. ATM, Frame Relay etc.
   The memo proposes a "one VC per sender" approach.  Merging of RSVP
   flows into a single VC will be considered in a later revision of the
   draft.

   It is assumed here that the ISRs on the edge of an ISR cloud can
   either auto-learn or are configured to indicate that they are edge
   ISRs (on a per interface basis).


2. Soft State Switching

   In soft state switching, the goal is to switch traffic from an RSVP
   flow at L2 instead of having to forward them hop-by-hop as in
   conventional IP routers.  By doing so, it is possible to leverage the
   high-performance switching and Quality of Service capabilities of the
   L2 technology.  This is achieved when all neighboring ISRs along the
   routed path could exchange L2 labels for establishing the switched
   path for RSVP flows.  Then, the L2 labels may be "spliced" hop-by-hop
   to setup an end-to-end (ingress-to-egress) VC along the preferred
   routed path.  By splicing, we refer to the process by which an



Viswanathan, et al.     Expires: September 1997                 [Page 2]


Internet-Draft            Soft State Switching                March 1997


   incoming VC is associated with an outgoing VC at L2, without traffic
   from the incoming VC being processed at the network layer.  For
   example, this can be achieved in ATM switches by establishing this
   association in the ATM switching tables.  Once the splicing is
   complete, the default VC carrying best effort traffic between
   adjacent routers provides the IP forwarding path.  The RSVP
   signalling messages are forwarded on the default VC.

   The L2 labels are assumed to have only unidirectional significance.
   In other words, there exists a separate L2 label space for each
   direction of flow on a link.  Moreover, the downstream ISR is chosen
   to be the L2 label space owner (allocator) on a link.  The single
   owner approach keeps the L2 label usage simple and manageable.  If a
   L2 label space had more than one owner, it would require that owners
   synchronize their use of the L2 labels or the space would have to be
   partitioned amongst the owners.  For flexibility, the proposed
   extension to RSVP also supports the concept of "upstream on demand"
   allocation described in [3].  In this method, the upstream ISR
   allocates labels when demanded by the downstream ISR.  This enables
   co-existence with other protocols that consume L2 labels.


3. Motivation

   In this section, we discuss why the RSVP protocol is ideal for
   establishing a switched path for RSVP flows.

   One motivating factor for using RSVP is that mapping the network
   layer QoS request to a L2 virtual connection is simple.  The RESV
   message carries the QoS requested by the receiver(s) of the RSVP
   flow.  For example, this could correspond to one of the Integrated
   Service classes described in [6-8].  This QoS information is needed
   when L2 labels are set up and spliced; i.e., when the resource
   reservations are made.  Otherwise, the VC establishment protocol
   would have to carry its own QoS entity and/or map the VC setup to
   RSVP tables at each ISR hop.

   Another motivating reason for extending RSVP is multicast support.
   RSVP is designed to scale well for multicast sessions requiring
   resource reservation.  RSVP also allows receivers to join existing
   sessions with different QoS requirements.  An independent VC
   establishment protocol should be able to handle such session "joins"
   equally well.

   With the RSVP protocol the receivers can make sender selection
   through the provision of different filter styles.  In this, multiple
   sender flows (as chosen by the receivers) in a RSVP session can be
   associated with a single reservation.  In other words, sender flows



Viswanathan, et al.     Expires: September 1997                 [Page 3]


Internet-Draft            Soft State Switching                March 1997


   in a RSVP session can be merged into a single downstream reservation.
   A new VC establishment protocol would have to support a similar
   mechanism for seamless interoperability with the RSVP protocol.

   Finally, any mechanism for set up the VCs would, in any case, require
   extensive interfacing with RSVP protocol and/or its state tables.

   Due to these reasons, it is best if RSVP can be extended without
   changing its existing mechanics, to provide support for setting up
   the switched path for RSVP flows.  This need not be viewed as
   "piggy-backing" another protocol on RSVP, but rather, a natural
   extension to RSVP to provide QoS in an integrated switch-router
   environment.


4. L2 Label Exchange Mechanism

   The proposed extension to RSVP calls for adding a new object to carry
   the L2 label information in the RESV message.  The egress ISR, say
   ISR A, (i.e. the "last" node in the ISR environment, or the ISR
   through which the RSVP flow exits the ISR environment) places this
   object in the RESV message and sends it to the PHOP ISR for the flow
   (as stored in the Path state for this flow) -- call this ISR B.  The
   RESV message is sent to ISR B via the default routed path.  ISR B
   will use the L2 label in the RESV message to setup a VC to ISR A (in
   this case, the egress ISR) on the outgoing interface.  The QoS for
   this VC corresponds to a mapping of the Integrated Service class
   specified in the RESV message to an appropriate set of QoS values for
   the L2 technology.

   ISR B then chooses a new L2 label on the incoming interface through
   which the RSVP flow enters the ISR, and sends this label to its own
   PHOP, ISR C, using the new object in the RESV message.  When a VC is
   set up from ISR C to ISR B using this label, the L2 label on the
   incoming interface of ISR B is then mapped to the L2 label of the
   outgoing interface in ISR B's label swap table for L2 switching.
   This completes the splicing process at ISR B.

   Repeating this process at each PHOP ISR, the RESV eventually reaches
   the ingress ISR (the ISR through which the RSVP flow enters the ISR
   environment).  The ingress ISR will make necessary entries to forward
   packets for this flow through the VC identified by the L2 label in
   RESV message.  All ingress ISRs will delete the L2 object before
   forwarding the RESV message to their PHOPs.  The L2 labels used for
   an RSVP session are released whenever the RSVP session is torn down
   or is timed-out.

   Using this process, an end-to-end switched path is established for an



Viswanathan, et al.     Expires: September 1997                 [Page 4]


Internet-Draft            Soft State Switching                March 1997


   RSVP flow through an ISR network.  The data packets from the RSVP
   flow are forwarded via this switched path, while RSVP control
   messages continue to use the default VCs between ISRs.

   The procedure described in this section does not describe how flow
   merging is performed in such an environment.  Flow merging is a key
   feature of RSVP, and the ability to perform merging in an ISR
   environment is dependent on the capabilities of the ISRs.  This topic
   is addressed in detail in the following section.


5. Merging

   There are several switching technologies available today (ATM, Frame
   Relay etc.) and perhaps more in the future.  Moreover, the
   capabilities of a switch of a certain technology vary from vendor to
   vendor.  Three basic characteristics are identified that determine
   how the underlying L2 technology can be used in conjunction with this
   proposal to address merging of flows under appropriate environment.
   They are:

        o    Attribute A: Can correctly merge several upstream VCs into
             a single downstream VC.  Frame switches are typically able
             to do this in a straightforward manner.  However, for ATM
             switches without appropriate functionality built in, cells
             from different AAL SDUs may become interleaved on the
             outgoing VC, thus corrupting the higher layer information.

        o    Attribute B: Can treat a set of VCs as a single entity for
             QoS purposes.  A switch with this property is able to treat
             all traffic from a set of VCs in a like manner for purposes
             of scheduling, fair queueing etc.  For example, an ATM
             switch that performs per-class queueing would assign all
             the VCs from a given set to a particular class.  Then,
             cells from all the VCs in the sets would receive the QoS
             corresponding to that class.

        o    Attribute C: Can demultiplex senders flows in a single VC
             into a separate VC for a sender.  For example, using label
             stack for L2 tunneling ([3], [4]).


   The current version of the document does not address the logical
   merging of sender flows in a RSVP session.  The above attributes may
   be used to determine how RSVP flows are merged into a single VC.






Viswanathan, et al.     Expires: September 1997                 [Page 5]


Internet-Draft            Soft State Switching                March 1997


6. Multicast Support

   In order to support multicast sessions, at split points within the
   ISR network, where data from upstream ISRs splits into multiple
   downstream flows, the ISR can perform the required duplication (at L2
   level) of flows through the hardware multicast capability (for
   example, point-to-multipoint VC) of the switch, if available.
   Otherwise, the flow has to be processed at the network layer and
   multicast in the normal manner.  Note that the network layer
   forwarding is interoperable with all switch types.


7. Unreserved Receivers

   When none of the receivers have reserved, the multicast session may
   flow through the default VC as best-effort traffic.  But as soon as a
   receiver makes a reservation, the data flow may stop to receivers
   that haven't made any reservation yet.  The receivers without
   reservation only get PATH messages but no data (even through best-
   effort).  This problem can be addressed in several different ways
   determined by the switch architecture.

   This problem does not exist for switches that support Attribute A.
   They can add the default forwarding VC as a branch in the point-to-
   multipoint VC.  If the switch architecture allow adding the local
   IP-CP to the point-to-multipoint VC, then the IP-CP can multicast the
   packets only to those interface from which there is no reservation
   but are listed in the multicast table.  This would be the most
   preferable approach for all switches.

   Another way to alleviate this problem is to use the PATH message to
   do the VC establishment from the node downstream on which there are
   interfaces through which no reservation has been received [9].  This
   reservation uses a UBR-like QoS.  This is done when there is at least
   one reservation in place for the RSVP session.  This may not work in
   environments where upstream label allocation is not permitted.


8. TTL Decrement

   When IP packets flow through a switched path, the TTL value in the IP
   header cannot be decremented.  The decrementing of TTL value is used
   to delete packets in a routing loop to avoid/reduce congestion.  For
   this purpose, the proposed PATH L2 Object carries a hop-count that
   counts the number of consecutive ISR hops.  The ISRs increment the
   hop-count only if there is a switched path for that sender flow
   through that ISR.  All ISRs maintain the hop count in the Path State.
   Only the egress ISR on which the VC terminates would use the count to



Viswanathan, et al.     Expires: September 1997                 [Page 6]


Internet-Draft            Soft State Switching                March 1997


   decrement the TTL on packets for that sender flow.  The ISRs of a
   switching technology that have a TTL equivalent in the L2 header may
   not use the PATH L2 Object.


9. Upstream on Demand Label Allocation

   The memo describes the RSVP extension when the downstream ISR is the
   label space owner.  But a upstream label allocator can be supported.
   In this, the RESV message uses a NULL L2 Object to indicate a request
   for label allocation.  The upstream ISR responds with a L2 label for
   the RSVP session in the PATH messages to the downstream neighbor.
   This flexibility allows co-existence with other IP switching
   protocols.  This can also be useful in other environments such as
   [5].


10. Adjacency

   The ISR neighbors need some mechanism to establish adjacencies.  This
   is required because the neighbors need to exchange the label range
   for correct label allocation.  They also need to elect the label
   allocator.  The current version of this memo does not propose any
   extension to RSVP protocol for this mechanism.  It is assumed that
   adjacency would be established by another protocol (as proposed in
   [2], [3] or [4]) and such information would be made available to the
   RSVP module.  In absence of such mechanism the ISRs would have to be
   configured with the required information to operate as described in
   this memo.


11. Object Formats

   This section describes the object formats for the proposed extension.
   The L2 object for different scenarios are defined below:

        o    L2 HOP COUNT object: Class = x, C-Type = 1

             +-------------+-------------+-------------+-------------+
             |  Hop Count  |                Reserved                 |
             +-------------+-------------+-------------+-------------+

        Hop Count
             Counts the length (in ISR hops) of the switched path.

        o    NULL L2 Object: Class = y, C-Type = 1

        o    ATM RESV L2 object: Class = y, C-Type = 2



Viswanathan, et al.     Expires: September 1997                 [Page 7]


Internet-Draft            Soft State Switching                March 1997


             +-------------+-------------+-------------+-------------+
             |               IPv4 SrcAddress (4 bytes)               |
             +-------------+-------------+-------------+-------------+
             |    //////   |    //////   |          SrcPort          |
             +-------+-----+-------------+-------------+-------------+
             |       |       VPI         |            VCI            |
             +-------+-------------------+-------------+-------------+
             //                                                     //
             +-------------+-------------+-------------+-------------+
             |               IPv4 SrcAddress (4 bytes)               |
             +-------------+-------------+-------------+-------------+
             |    //////   |    //////   |          SrcPort          |
             +-------+-----+-------------+-------------+-------------+
             |       |       VPI         |            VCI            |
             +-------+-------------------+-------------+-------------+

        IPv4 SrcAddress
             IPv4 address of the sender.

        VPI - 12 bits
             Virtual Path Identifier.  If lesser than 12 bits then its
             right justified in this field.

        VCI - 16 bits
             Virtual Circuit Identifier.  If lesser than 16 bits then
             its right justified in this field.

        o    ATM PATH L2 object: Class = y, C-Type = 3

             +-------+-------------------+-------------+-------------+
             | Flags |       VPI         |            VCI            |
             +-------+-------------------+-------------+-------------+

        Flags - 4 bits
             0x01 - Implies that the PATH message is in response to an
             upstream on demand label allocation and may not be
             propogated any further.

        VPI - 12 bits
             Virtual Path Identifier.  If lesser than 12 bits then its
             right justified in this field.

        VCI - 16 bits
             Virtual Circuit Identifier.  If lesser than 16 bits then
             its right justified in this field.

   The IPv6 extension and error codes will be defined in a later
   revision of the draft.



Viswanathan, et al.     Expires: September 1997                 [Page 8]


Internet-Draft            Soft State Switching                March 1997


   The reader may have noticed that the new RESV L2 object has
   duplicated information already present in the FILTER_SPEC object.
   Another approach could be to extend the FILTER_SPEC object definition
   to carry the link layer labels or insert the label object following
   the FILTER_SPEC object.


12. Security Considerations

   Security considerations are not discussed in this document.


13. Acknowledgements

   The authors wishes to acknowledge Nancy Feldman for her input.


14. References

   [1]  R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, Resource
        ReSerVation Protocol (RSVP) -- Version 1 Functional
        Specification.  Internet Draft, draft-ietf-rsvp-spec-14,
        November 1996.

   [2]  P. Newman, W. L. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw,
        T. Lyon, G. Minshall, Ipsilon Flow Management Protocol
        Specification for IPv4, Version 1.0. Internet RFC 1953, May
        1996.

   [3]  Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow, D.
        Farinacci, Tag Switching Architecture - Overview. Internet
        Draft, draft-rekhter-tagswitch-arch-00.txt, January 1997.

   [4]  A. Viswanathan, N. Feldman, R. Boivie, R. Woundy, ARIS:
        Aggregated Route-Based IP Switching. Internet Draft, draft-
        viswanathan-aris-overview-00.txt, November 1996.

   [5]  D. Farinacci, Partitioning Tag Space among Multicast Routers on
        a Common Subnet. Internet Draft, draft-farinacci-multicast-tag-
        part-00.txt, December 1996.

   [6]  S. Shenker, C. Partridge, R. Guerin, Specification of Guaranteed
        Quality of Service. Internet Draft, draft-ietf-intserv-
        guaranteed-svc-06.txt, August 1996.

   [7]  J. Wroclawski, Specification of the Controlled-Load Network
        Element Service. Internet Draft, draft-ietf-intserv-ctrl-load-
        svc-03.txt, August 1996.



Viswanathan, et al.     Expires: September 1997                 [Page 9]


Internet-Draft            Soft State Switching                March 1997


   [8]  F. Baker, R. Guerin, D. Kandlur, Specification of Committed Rate
        Quality of Service. Internet Draft, draft-ietf-intserv-commit-
        rate-svc-00.txt, June 1996.


Author's Address

        Vijay Srinivasan
        IBM Corporation
        PO Box 12195
        Research Triangle Park, NC 27709

        Phone: +1 (919) 254-2730
        Email: vijay@raleigh.ibm.com


        Arun Viswanathan
        IBM Corporation
        17 Skyline Drive
        Hawthorne, NY 10532

        Phone: +1 (914) 784-3273
        Email: arunv@vnet.ibm.com




























Viswanathan, et al.     Expires: September 1997                [Page 10]


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