rfc2380.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 788 行 · 第 1/3 页

Network Working Group                                          L. Berger
Request for Comments: 2380                                  FORE Systems
Category: Standards Track                                    August 1998


               RSVP over ATM Implementation Requirements

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This memo presents specific implementation requirements for running
   RSVP over ATM switched virtual circuits (SVCs).  It presents
   requirements that ensure interoperability between multiple
   implementations and conformance to the RSVP and Integrated Services
   specifications.  A separate document [5] provides specific guidelines
   for running over today's ATM networks.  The general problem is
   discussed in [9].   Integrated Services to ATM service mappings are
   covered in [6].  The full set of documents present the background and
   information needed to implement Integrated Services and RSVP over
   ATM.

Table of Contents

   1. Introduction .................................................  2
      1.1 Terms ....................................................  2
      1.2 Assumptions ..............................................  3
   2. General RSVP Session Support .................................  4
      2.1 RSVP Message VC Usage ....................................  4
      2.2 VC Initiation ............................................  4
      2.3 VC Teardown ..............................................  5
      2.4 Dynamic QoS ..............................................  6
      2.5 Encapsulation ............................................  6
   3. Multicast RSVP Session Support ...............................  7
      3.1 Data VC Management for Heterogeneous Sessions ............  7
      3.2 Multicast End-Point Identification .......................  8
      3.3 Multicast Data Distribution ..............................  9
      3.4 Receiver Transitions ..................................... 11



Berger                      Standards Track                     [Page 1]

RFC 2380       RSVP over ATM Implementation Requirements     August 1998


   4. Security Considerations ...................................... 11
   5. Acknowledgments .............................................. 11
   6. Author's Address ............................................. 12
   REFERENCES ...................................................... 13
   FULL COPYRIGHT STATEMENT ........................................ 14

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 [4] methods for supporting IP over ATM.  The general issues
   related to running RSVP [8] over ATM have been covered in several
   papers including [9] and other earlier work.  This document is
   intended as a companion to [9,5].  The reader should be familiar with
   both documents.

   This document defines the specific requirements for implementations
   using ATM UNI3.x and 4.0.  These requirements must be adhered to by
   all RSVP over ATM implementations to ensure interoperability.
   Further recommendations to guide implementers of RSVP over ATM are
   provided in [5].

   The rest of this section will define terms and assumptions. Section 2
   will cover implementation guidelines common to all RSVP session.
   Section 3 will cover implementation guidelines specific to multicast
   sessions.

1.1 Terms

   The terms "reservation" and "flow" are used in many contexts, often
   with different meaning.  These terms are used in this document with
   the following meaning:

   o    Reservation is used in this document to refer to an RSVP
        initiated request for resources.  RSVP initiates requests for
        resources based on RESV message processing.  RESV messages that
        simply refresh state do not trigger resource requests.  Resource
        requests may be made based on RSVP sessions and RSVP reservation
        styles. RSVP styles dictate whether the reserved resources are
        used by one sender or shared by multiple senders.  See [8] for
        details of each. Each new request is referred to in this
        document as an RSVP reservation, or simply reservation.








Berger                      Standards Track                     [Page 2]

RFC 2380       RSVP over ATM Implementation Requirements     August 1998


   o    Flow is used to refer to the data traffic associated with a
        particular reservation.  The specific meaning of flow is RSVP
        style dependent.  For shared style reservations, there is one
        flow per session.  For distinct style reservations, there is one
        flow per sender (per session).

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

1.2 Assumptions

   The following assumptions are made:

   o    RSVP

        We assume RSVP as the internet signaling protocol which is
        described in [8].  The reader is assumed to be familiar with
        [8].

   o    IPv4 and IPv6

        RSVP support has been defined for both IPv4 and IPv6.  The
        guidelines in this document are intended to be used to support
        RSVP with either IPv4 or IPv6.  This document does not require
        one version over the other.

   o    Best effort service model

        The current Internet only supports best effort service.  We
        assume that as additional components of the Integrated Services
        model are defined, best effort service must continue to be
        supported.

   o    ATM UNI 3.x and 4.0

        We assume ATM service as defined by UNI 3.x and 4.0.  ATM
        provides both point-to-point and point-to-multipoint Virtual
        Circuits (VCs) with a specified Quality of Service (QoS).  ATM
        provides both Permanent Virtual Circuits (PVCs) and Switched
        Virtual Circuits (SVCs).  In the Permanent Virtual Circuit (PVC)
        environment, PVCs are typically used as point-to-point link
        replacements.  So the support issues are similar to point-to-
        point links.  This memo assumes that SVCs are used to support
        RSVP over ATM.






Berger                      Standards Track                     [Page 3]

RFC 2380       RSVP over ATM Implementation Requirements     August 1998


2. General RSVP Session Support

   This section provides implementation requirements that are common for
   all (both unicast and multicast) RSVP sessions.  The section covers
   VC usage, QoS VC initiation, VC teardown, handling requested changes
   in QoS, and encapsulation.

2.1 RSVP Message VC Usage

   There are several RSVP Message VC Usage options available to
   implementers.  Implementers must select which VC to use for RSVP
   messages and how to aggregate RSVP sessions over QoS VCs.  These
   options have been covered in [9] and some specific implementation
   guidelines are stated in [5].  In order to ensure interoperability
   between implementations that follow different options, RSVP over ATM
   implementations MUST NOT send RSVP (control) messages on the same QoS
   VC as RSVP associated data packets.  RSVP over ATM implementations
   MAY send RSVP messages on either the best effort data path or on a
   separate control VC.

   Since RSVP (control) messages and RSVP associated data packets are
   not sent on the same VCs, it is possible for a VC supporting one type
   of traffic to fail while the other remains in place.  When the VC
   associated with data packets fails and cannot be reestablished, RSVP
   SHOULD treat this as an allocation failure.  When the VC used to
   forward RSVP control messages is abnormally released and cannot be
   reestablished, the RSVP associated QoS VCs MUST also be released.
   The release of the associated data VCs is required to maintain the
   synchronization between forwarding and reservation states for the
   associated data flows.

2.2 VC Initiation

   There is an apparent mismatch between RSVP and ATM. Specifically,
   RSVP control is receiver oriented and ATM control is sender oriented.
   This initially may seem like a major issue but really is not.  While
   RSVP reservation (RESV) requests are generated at the receiver,
   actual allocation of resources takes place at the subnet sender.

   For data flows, this means that subnet senders MUST establish all QoS
   VCs and the RSVP enabled subnet receiver MUST be able to accept
   incoming QoS VCs.  These restrictions are consistent with RSVP
   version 1 processing rules and allow senders to use different flow to
   VC mappings and even different QoS renegotiation techniques without
   interoperability problems.  All RSVP over ATM approaches that have
   VCs initiated and controlled by the subnet senders will interoperate.
   Figure 1 shows this model of data flow VC initiation.




Berger                      Standards Track                     [Page 4]

RFC 2380       RSVP over ATM Implementation Requirements     August 1998


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

                      +-----+
                      |     |      -------------->  +----+
                      | Src |    -------------->    | R1 |
                      |    *|  -------------->      +----+
                      +-----+       QoS VCs
                           /\
                           ||
                       VC  ||
                       Initiator

                     Figure 1: Data Flow VC Initiation

   RSVP over ATM implementations MAY send data in the backwards
   direction on an RSVP initiated QoS point-to-point VC.  When sending
   in the backwards data path, the sender MUST ensure that the data
   conforms to the backwards direction traffic parameters.  Since the
   traffic parameters are set by the VC initiator, it is quite likely
   that no resources will be requested for traffic originating at the
   called party.  It should be noted that the backwards data path is not
   available with point-to-multipoint VCs.

2.3 VC Teardown

   VCs supporting IP over ATM data are typically torndown based on
   inactivity timers.  This mechanism is used since IP is connectionless
   and there is therefore no way to know when a VC is no longer needed.
   Since RSVP provides explicit mechanisms (messages and timeouts) to
   determine when an associated data VC is no longer needed, the
   traditional VC timeout mechanisms are not needed. Additionally, under
   normal operations RSVP implementations expect to be able to allocate
   resources and have those resources remain allocated until released at