rfc2382.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                 E. Crawley, Editor
Request for Comments: 2382                                Argon Networks
Category: Informational                                        L. Berger
                                                            Fore Systems
                                                               S. Berson
                                                                    ISI
                                                                F. Baker
                                                           Cisco Systems
                                                               M. Borden
                                                            Bay Networks
                                                             J. Krawczyk
                                               ArrowPoint Communications
                                                             August 1998


         A Framework for Integrated Services and RSVP over ATM

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   This document outlines the issues and framework related to providing
   IP Integrated Services with RSVP over ATM. It provides an overall
   approach to the problem(s) and related issues.  These issues and
   problems are to be addressed in further documents from the ISATM
   subgroup of the ISSLL working group.

1. Introduction

   The Internet currently has one class of service normally referred to
   as "best effort."  This service is typified by first-come, first-
   serve scheduling at each hop in the network.  Best effort service has
   worked well for electronic mail, World Wide Web (WWW) access, file
   transfer (e.g. ftp), etc.  For real-time traffic such as voice and
   video, the current Internet has performed well only across unloaded
   portions of the network.  In order to provide quality real-time
   traffic, new classes of service and a QoS signalling protocol are






Crawley, et. al.             Informational                      [Page 1]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   being introduced in the Internet [1,6,7], while retaining the
   existing best effort service.  The QoS signalling protocol is RSVP
   [1], the Resource ReSerVation Protocol and the service models

   One of the important features of ATM technology is the ability to
   request a point-to-point Virtual Circuit (VC) with a specified
   Quality of Service (QoS).  An additional feature of ATM technology is
   the ability to request point-to-multipoint VCs with a specified QoS.
   Point-to-multipoint VCs allows leaf nodes to be added and removed
   from the VC dynamically and so provides a mechanism for supporting IP
   multicast. It is only natural that RSVP and the Internet Integrated
   Services (IIS) model would like to utilize the QoS properties of any
   underlying link layer including ATM, and this memo concentrates on
   ATM.

   Classical IP over ATM [10] has solved part of this problem,
   supporting IP unicast best effort traffic over ATM.  Classical IP
   over ATM is based on a Logical IP Subnetwork (LIS), which is a
   separately administered IP subnetwork.  Hosts within an LIS
   communicate using the ATM network, while hosts from different subnets
   communicate only by going through an IP router (even though it may be
   possible to open a direct VC between the two hosts over the ATM
   network).  Classical IP over ATM provides an Address Resolution
   Protocol (ATMARP) for ATM edge devices to resolve IP addresses to
   native ATM addresses.  For any pair of IP/ATM edge devices (i.e.
   hosts or routers), a single VC is created on demand and shared for
   all traffic between the two devices.  A second part of the RSVP and
   IIS over ATM problem, IP multicast, is being solved with MARS [5],
   the Multicast Address Resolution Server.

   MARS compliments ATMARP by allowing an IP address to resolve into a
   list of native ATM addresses, rather than just a single address.

   The ATM Forum's LAN Emulation (LANE) [17, 20] and Multiprotocol Over
   ATM (MPOA) [18] also address the support of IP best effort traffic
   over ATM through similar means.

   A key remaining issue for IP in an ATM environment is the integration
   of RSVP signalling and ATM signalling in support of the Internet
   Integrated Services (IIS) model.  There are two main areas involved
   in supporting the IIS model, QoS translation and VC management. QoS
   translation concerns mapping a QoS from the IIS model to a proper ATM
   QoS, while VC management concentrates on how many VCs are needed and
   which traffic flows are routed over which VCs.







Crawley, et. al.             Informational                      [Page 2]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


1.1 Structure and Related Documents

   This document provides a guide to the issues for IIS over ATM.  It is
   intended to frame the problems that are to be addressed in further
   documents. In this document, the modes and models for RSVP operation
   over ATM will be discussed followed by a discussion of management of
   ATM VCs for RSVP data and control. Lastly, the topic of
   encapsulations will be discussed in relation to the models presented.

   This document is part of a group of documents from the ISATM subgroup
   of the ISSLL working group related to the operation of IntServ and
   RSVP over ATM.  [14] discusses the mapping of the IntServ models for
   Controlled Load and Guaranteed Service to ATM.  [15 and 16] discuss
   detailed implementation requirements and guidelines for RSVP over
   ATM, respectively.  While these documents may not address all the
   issues raised in this document, they should provide enough
   information for development of solutions for IntServ and RSVP over
   ATM.

1.2 Terms

   Several term used in this document are used in many contexts, often
   with different meaning.  These terms are used in this document with
   the following meaning:

   - Sender is used in this document to mean the ingress point to the
     ATM network or "cloud".
   - Receiver is used in this document to refer to the egress point from
     the ATM network or "cloud".
   - 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 [1] for details of each. Each new
     request is referred to in this document as an RSVP reservation, or
     simply reservation.
   - 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).

2. Issues Regarding the Operation of RSVP and IntServ over ATM

   The issues related to RSVP and IntServ over ATM fall into several
   general classes:



Crawley, et. al.             Informational                      [Page 3]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   - How to make RSVP run over ATM now and in the future
   - When to set up a virtual circuit (VC) for a specific Quality of
     Service (QoS) related to RSVP
   - How to map the IntServ models to ATM QoS models
   - How to know that an ATM network is providing the QoS necessary for
     a flow
   - How to handle the many-to-many connectionless features of IP
     multicast and RSVP in the one-to-many connection-oriented world of
     ATM

2.1 Modes/Models for RSVP and IntServ over ATM

   [3] Discusses several different models for running IP over ATM
   networks.  [17, 18, and 20] also provide models for IP in ATM
   environments.  Any one of these models would work as long as the RSVP
   control packets (IP protocol 46) and data packets can follow the same
   IP path through the network.  It is important that the RSVP PATH
   messages follow the same IP path as the data such that appropriate
   PATH state may be installed in the routers along the path.  For an
   ATM subnetwork, this means the ingress and egress points must be the
   same in both directions for the RSVP control and data messages.  Note
   that the RSVP protocol does not require symmetric routing.  The PATH
   state installed by RSVP allows the RESV messages to "retrace" the
   hops that the PATH message crossed.  Within each of the models for IP
   over ATM, there are decisions about using different types of data
   distribution in ATM as well as different connection initiation.  The
   following sections look at some of the different ways QoS connections
   can be set up for RSVP.

2.1.1 UNI 3.x and 4.0

   In the User Network Interface (UNI) 3.0 and 3.1 specifications [8,9]
   and 4.0 specification, both permanent and switched virtual circuits
   (PVC and SVC) may be established with a specified service category
   (CBR, VBR, and UBR for UNI 3.x and VBR-rt and ABR for 4.0) and
   specific traffic descriptors in point-to-point and point-to-
   multipoint configurations.  Additional QoS parameters are not
   available in UNI 3.x and those that are available are vendor-
   specific.  Consequently, the level of QoS control available in
   standard UNI 3.x networks is somewhat limited.  However, using these
   building blocks, it is possible to use RSVP and the IntServ models.
   ATM 4.0 with the Traffic Management (TM) 4.0 specification [21]
   allows much greater control of QoS.  [14] provides the details of
   mapping the IntServ models to UNI 3.x and 4.0 service categories and
   traffic parameters.






Crawley, et. al.             Informational                      [Page 4]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


2.1.1.1 Permanent Virtual Circuits (PVCs)

   PVCs emulate dedicated point-to-point lines in a network, so the
   operation of RSVP can be identical to the operation over any point-
   to-point network.  The QoS of the PVC must be consistent and
   equivalent to the type of traffic and service model used.  The
   devices on either end of the PVC have to provide traffic control
   services in order to multiplex multiple flows over the same PVC.
   With PVCs, there is no issue of when or how long it takes to set up
   VCs, since they are made in advance but the resources of the PVC are
   limited to what has been pre-allocated.  PVCs that are not fully
   utilized can tie up ATM network resources that could be used for
   SVCs.

   An additional issue for using PVCs is one of network engineering.
   Frequently, multiple PVCs are set up such that if all the PVCs were
   running at full capacity, the link would be over-subscribed.  This
   frequently used "statistical multiplexing gain" makes providing IIS
   over PVCs very difficult and unreliable.  Any application of IIS over
   PVCs has to be assured that the PVCs are able to receive all the
   requested QoS.

2.1.1.2 Switched Virtual Circuits (SVCs)

   SVCs allow paths in the ATM network to be set up "on demand".  This
   allows flexibility in the use of RSVP over ATM along with some
   complexity.  Parallel VCs can be set up to allow best-effort and
   better service class paths through the network, as shown in Figure 1.
   The cost and time to set up SVCs can impact their use.  For example,
   it may be better to initially route QoS traffic over existing VCs
   until a SVC with the desired QoS can be set up for the flow.  Scaling
   issues can come into play if a single RSVP flow is used per VC, as
   will be discussed in Section 4.3.1.1. The number of VCs in any ATM
   device may also be limited so the number of RSVP flows that can be
   supported by a device can be strictly limited to the number of VCs
   available, if we assume one flow per VC.  Section 4 discusses the
   topic of VC management for RSVP in greater detail.