rfc2379.txt

RFC 的详细文档！

Network Working Group                                          L. Berger
Request for Comments: 2379                                  FORE Systems
BCP: 24                                                      August 1998
Category: Best Current Practice


                RSVP over ATM Implementation Guidelines

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   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.

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].





Berger                   Best Current Practice                  [Page 1]

RFC 2379        RSVP over ATM Implementation Guidelines      August 1998


   This document uses the same terms and assumption stated in [2].
   Additionally, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
   "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
   "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 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.
















Berger                   Best Current Practice                  [Page 2]

RFC 2379        RSVP over ATM Implementation Guidelines      August 1998


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

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

                  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 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.









Berger                   Best Current Practice                  [Page 3]

RFC 2379        RSVP over ATM Implementation Guidelines      August 1998


                       ______
                      /      \
           +-------- / 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
                     Path

      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
   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



Berger                   Best Current Practice                  [Page 4]