Internet Draft                                                 L. Berger
Expires: October 1998                                       FORE Systems
File: draft-ietf-issll-atm-imp-guide-04.txt

                RSVP over ATM Implementation Guidelines

                             April 3, 1998

Status of 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 view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on (Africa),
   (Northern Europe), (Southern Europe),
   (Pacific Rim), (US East Coast), or
   (US West Coast).


   This memo presents specific implementation guidelines for running
   RSVP over ATM switched virtual circuits (SVCs).  The general problem
   is discussed in [6].  Implementation requirements are discussed in
   [2].  Integrated Services to ATM service mappings are covered in [3].
   The full set of documents present the background and information
   needed to implement Integrated Services and RSVP over ATM.

Berger                   Expires: October 1998                  [Page 1]

Internet Draft          RSVP over ATM Guidelines              April 1998

1. Introduction

   This memo discusses running IP over ATM in an environment where SVCs
   are used to support QoS flows and RSVP is used as the internet level
   QoS signaling protocol.  It applies when using CLIP/ION, LANE2.0 and
   MPOA methods for supporting IP over ATM.  The general issues related
   to running RSVP[4] over ATM have been covered in several papers
   including [6] and other earlier work.  This document is intended as a
   companion to [6,2] and as a guide to implementers.  The reader should
   be familiar with both documents.

   This document provides a recommended set of functionality for
   implementations using ATM UNI3.x and 4.0, while allowing for more
   sophisticated approaches.  We expect some vendors to additionally
   provide some of the more sophisticated approaches described in [6],
   and some networks to only make use of such approaches.  The
   recommended set of functionality is defined to ensure predictability
   and interoperability between different implementations.  Requirements
   for RSVP over ATM implementations are provided in [2].

   This document uses the same terms and assumption stated in [2].
   Additionally, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [5].

2. Implementation Recommendations

   This section provides implementation guidelines for implementation of
   RSVP over ATM.  Several recommendations are common for all, RSVP
   sessions, both unicast and multicast.  There are also recommendations
   that are unique to unicast and multicast session types.

   2.1 RSVP Message VC Usage

      The general issues related to which VC should be used for RSVP
      messages is covered in [6]. It discussed several implementation
      options including: mixed control and data, single control VC per
      session,  single control VC multiplexed among sessions, and
      multiple VCs multiplexed among sessions.  QoS for control VCs was
      also discussed.  The general discussion is not repeated here and
      [6] should be reviewed for detailed information.

      RSVP over ATM implementations SHOULD send RSVP control (messages)
      over the best effort data path, see figure 1.  It is permissible
      to allow a user to override this behavior.  The stated approach
      minimizes VC requirements since the best effort data path will
      need to exist in order for RSVP sessions to be established and in

Berger                   Expires: October 1998                  [Page 2]

Internet Draft          RSVP over ATM Guidelines              April 1998

      order for RSVP reservations to be initiated.  The specific best
      effort paths that will be used by RSVP are: for unicast, the same
      VC used to reach the unicast destination; and for multicast, the
      same VC that is used for best effort traffic destined to the IP
      multicast group.  Note that for multicast there may be another
      best effort VC that is used to carry session data traffic, i.e.,
      for data that is both in the multicast group and matching a
      sessions protocol and port.

                             Data Flow ==========>

                                    QoS VCs
                     +-----+    -------------->   +----+
                     |     |  -------------->     |    |
                     | Src |                      | R1 |
                     |     |   Best Effort VC(s)  |    |
                     +-----+  <-----------------> +----+
                              RSVP Control

                   Figure 1: RSVP Control Message VC Usage

      The disadvantage of this approach is that best effort VCs may not
      provide the reliability that RSVP needs.  However the best effort
      path is expected to satisfy RSVP reliability requirements in most
      networks. Especially since RSVP allows for a certain amount of
      packet loss without any loss of state synchronization.

   2.2 Aggregation

      As discussed in [6], data associated with multiple RSVP sessions
      can be sent using the same shared VCs. Implementation of such
      "aggregation" models is still a matter for research.  Therefore,
      RSVP over ATM implementations SHOULD use independent VCs for each
      RSVP reservation.

   2.3 Short-Cuts

      Short-cuts allow ATM attached routers and hosts to directly
      establish point-to-point VCs across LIS boundaries, i.e., the VC
      end-points are on different IP subnets. Short-cut support for
      unicast traffic has been defined in [7] and [1].  The ability for
      short-cuts and RSVP to interoperate has been raised as a general

Berger                   Expires: October 1998                  [Page 3]

Internet Draft          RSVP over ATM Guidelines              April 1998

      question.  The area of concern is the ability to handle asymmetric
      short-cuts.  Specifically how RSVP can handle the case where a
      downstream short-cut may not have a matching upstream short-cut.
      In this case, which is shown in figure 2, PATH and RESV messages
      following different paths.

                          /      \
               +-------- / Router \ <-------+
               |         \        /         |   <....... RESVs Follow
               |          \______/          |            Hop-by-hop Path
               |                            |
               |                            |
               V           QoS VCs          |
            +-----+    ==============>   +----+
            |     |  ==============>     |    |
            | Src |                      | R1 |
            |     |   Best Effort VC(s)  |    |
            +-----+  <=================> +----+

                         ::                        Data Paths:
                         ::                        ----> Hop-by-hop (routed)
                   PATHs and Data                  ====> Short-cut
                  Follow Short-cut

       Figure 2: Asymmetric RSVP Message Forwarding With ATM Short-Cuts

      Examination of RSVP shows that the protocol already includes
      mechanisms that allows support of the asymmetric paths.  The
      mechanism is the same one used to support RESV messages arriving
      at the wrong router and the wrong interface. RSVP messages are
      only processed when they arrive at the proper interface. When
      messages arrive on the wrong interface, they are forwarded by
      RSVP.  The proper interface is indicated in the NHOP object of the
      message. So, existing RSVP mechanisms will support the asymmetric
      paths that can occur when using short-cuts.

      The short-cut model of VC establishment still poses several issues
      when running with RSVP. The major issues are dealing with
      established best effort short-cuts, when to establish short-cuts,
      and QoS only short-cuts. These issues will need to be addressed by
      RSVP implementations.

      The key issue to be addressed by RSVP over ATM implementations is

Berger                   Expires: October 1998                  [Page 4]

Internet Draft          RSVP over ATM Guidelines              April 1998

      when to establish a short-cut for a QoS data flow.  RSVP over ATM
      implementations SHOULD simply follow best effort traffic. When a
      short-cut has been established for best effort traffic to a
      destination or next-hop, that same end-point SHOULD be used when
      setting up RSVP triggered VCs for QoS traffic to the same
      destination or next-hop. This will happen naturally when PATH
      messages are forwarded over the best effort short-cut.  Note that
      in this approach, when best effort short-cuts are never
      established, RSVP triggered QoS short-cuts will also never be

   2.4 Data VC Management for Heterogeneous Sessions

      Heterogeneous sessions can only occur with multicast RSVP
      sessions.  The issues relating to data VC management of
      heterogeneous sessions are covered in detail in [6] and are not
      repeated in this document.  In summary, heterogeneity occurs when
      receivers request different levels of QoS within a single session
      and also when some receivers do not request any QoS.  Both types
      of heterogeneity are shown in figure 3.

                           +------> | R1 |
                           |        +----+
                           |        +----+
              +-----+ -----+   +--> | R2 |
              |     | ---------+    +----+        Receiver Request Types:
              | Src |                             ---->  QoS 1 and QoS 2
              |     | .........+    +----+        ....>  Best-Effort
              +-----+ .....+   +..> | R3 |
                           :        +----+
                       /\  :
                       ||  :        +----+
                       ||  +......> | R4 |
                       ||           +----+
                  IP Mulicast

                    Figure 3: Types of Multicast Receivers

      [6] provides four models for dealing with heterogeneity: full
      heterogeneity,  limited heterogeneity, homogeneous, and modified
      homogeneous models.  The key issue to be addressed by an
      implementation is providing requested QoS downstream. One of, or
      some combination of, the discussed models [6] may be used to

Berger                   Expires: October 1998                  [Page 5]

Internet Draft          RSVP over ATM Guidelines              April 1998

      provide the requested QoS.  Unfortunately, none of the described
      models is the right answer for all cases.  For some networks, e.g.
      public WANs, it is likely that the limited heterogeneous model or
      a hybrid limited-full heterogeneous model will be desired.  In
      other networks, e.g. LANs, it is likely that a the modified
      homogeneous model will be desired.

      Since there is not one model that satisfies all cases,
      implementations SHOULD implement one of either the limited
      heterogeneity model or the modified homogeneous model.
      Implementations SHOULD support both approaches and provide the
      ability to select which method is actually used, but are not
      required to do so.

3. Security

   The same considerations stated in [4] and [8] apply to this document.
   There are no additional security issues raised in this document.

4. Acknowledgments

   This work is based on earlier drafts and comments from the ISSLL
   working group.  The author would like to acknowledge their
   contribution, most notably Steve Berson who coauthored one of the

5. Author's Address

      Lou Berger
      FORE Systems
      1595 Spring Hill Road
      5th Floor
      Vienna, VA 22182

      Phone: +1 703-245-4527


[1] The ATM Forum, "MPOA Baseline Version 1", May 1997.

[2] Berger, L., "RSVP over ATM Implementation Requirements, Internet
    Draft, January 1998.

[3] Borden, M., and Garrett, M., "Interoperation of Controlled-Load and
    Guaranteed-Service with ATM," Internet Draft, November 1997.

[4] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S.,

Berger                   Expires: October 1998                  [Page 6]

Internet Draft          RSVP over ATM Guidelines              April 1998

    "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
    Specification," RFC 2205, September 1997.

[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
    Levels," RFC 2119, March 1997.

[6] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M., and
    Krawczyk, J, "A Framework for Integrated Services and RSVP over
    ATM," Internet Draft, February 1998.

[7] Luciani, J., Katz, D., Piscitello, D., Cole, B., "NBMA Next Hop
    Resolution Protocol (NHRP)," Internet Draft, December 1997.

[8] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E., and
    Malis, A., "ATM Signalling Support for IP over ATM," RFC 1755.

Berger                   Expires: October 1998                  [Page 7]