rfc1633.txt

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

Network Working Group                                          R. Braden
Request for Comments: 1633                                           ISI
Category: Informational                                         D. Clark
                                                                     MIT
                                                              S. Shenker
                                                              Xerox PARC
                                                               June 1994


     Integrated Services in the Internet Architecture: an Overview

Status of this Memo

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

Abstract

   This memo discusses a proposed extension to the Internet architecture
   and protocols to provide integrated services, i.e., to support real-
   time as well as the current non-real-time service of IP.  This
   extension is necessary to meet the growing need for real-time service
   for a variety of new applications, including teleconferencing, remote
   seminars, telescience, and distributed simulation.

   This memo represents the direct product of recent work by Dave Clark,
   Scott Shenker, Lixia Zhang, Deborah Estrin, Sugih Jamin, John
   Wroclawski, Shai Herzog, and Bob Braden, and indirectly draws upon
   the work of many others.

Table of Contents

   1. Introduction ...................................................2
   2. Elements of the Architecture ...................................3
      2.1 Integrated Services Model ..................................3
      2.2 Reference Implementation Framework .........................6
   3. Integrated Services Model ......................................11
      3.1 Quality of Service Requirements ............................12
      3.2 Resource-Sharing Requirements and Service Models ...........16
      3.3 Packet Dropping ............................................18
      3.4 Usage Feedback .............................................19
      3.5 Reservation Model ..........................................19
   4. Traffic Control Mechanisms .....................................20
      4.1 Basic Functions ............................................20
      4.2 Applying the Mechanisms ....................................23
      4.3 An example .................................................24
   5. Reservation Setup Protocol .....................................25



Braden, Clark & Shenker                                         [Page 1]

RFC 1633            Integrated Services Architecture           June 1994


      5.1 RSVP Overview ..............................................25
      5.2 Routing and Reservations ...................................28
   6. Acknowledgments ................................................30
   References ........................................................31
   Security Considerations ...........................................32
   Authors' Addresses ................................................33

1. Introduction

   The multicasts of IETF meetings across the Internet have formed a
   large-scale experiment in sending digitized voice and video through a
   packet-switched infrastructure.  These highly-visible experiments
   have depended upon three enabling technologies.  (1) Many modern
   workstations now come equipped with built-in multimedia hardware,
   including audio codecs and video frame-grabbers, and the necessary
   video gear is now inexpensive.  (2) IP multicasting, which is not yet
   generally available in commercial routers, is being provided by the
   MBONE, a temporary "multicast backbone".  (3) Highly-sophisticated
   digital audio and video applications have been developed.

   These experiments also showed that an important technical element is
   still missing: real-time applications often do not work well across
   the Internet because of variable queueing delays and congestion
   losses.  The Internet, as originally conceived, offers only a very
   simple quality of service (QoS), point-to-point best-effort data
   delivery.  Before real-time applications such as remote video,
   multimedia conferencing, visualization, and virtual reality can be
   broadly used, the Internet infrastructure must be modified to support
   real-time QoS, which provides some control over end-to-end packet
   delays.  This extension must be designed from the beginning for
   multicasting; simply generalizing from the unicast (point-to-point)
   case does not work.

   Real-time QoS is not the only issue for a next generation of traffic
   management in the Internet.  Network operators are requesting the
   ability to control the sharing of bandwidth on a particular link
   among different traffic classes.  They want to be able to divide
   traffic into a few administrative classes and assign to each a
   minimum percentage of the link bandwidth under conditions of
   overload, while allowing "unused" bandwidth to be available at other
   times.  These classes may represent different user groups or
   different protocol families, for example.  Such a management facility
   is commonly called controlled link-sharing.  We use the term
   integrated services (IS) for an Internet service model that includes
   best-effort service, real-time service, and controlled link sharing.

   The requirements and mechanisms for integrated services have been the
   subjects of much discussion and research over the past several years



Braden, Clark & Shenker                                         [Page 2]

RFC 1633            Integrated Services Architecture           June 1994


   (the literature is much too large to list even a representative
   sample here; see the references in [CSZ92, Floyd92, Jacobson91,
   JSCZ93, Partridge92, SCZ93, RSVP93a] for a partial list).  This work
   has led to the unified approach to integrated services support that
   is described in this memo.  We believe that it is now time to begin
   the engineering that must precede deployment of integrated services
   in the Internet.

   Section 2 of this memo introduces the elements of an IS extension of
   the Internet.  Section 3 discusses real-time service models [SCZ93a,
   SCZ93b].  Section 4 discusses traffic control, the forwarding
   algorithms to be used in routers [CSZ92].  Section 5 discusses the
   design of RSVP, a resource setup protocol compatible with the
   assumptions of our IS model [RSVP93a, RSVP93b].

2. Elements of the Architecture

   The fundamental service model of the Internet, as embodied in the
   best-effort delivery service of IP, has been unchanged since the
   beginning of the Internet research project 20 years ago [CerfKahn74].
   We are now proposing to alter that model to encompass integrated
   service.  From an academic viewpoint, changing the service model of
   the Internet is a major undertaking; however, its impact is mitigated
   by the fact that we wish only to extend the original architecture.
   The new components and mechanisms to be added will supplement but not
   replace the basic IP service.

   Abstractly, the proposed architectural extension is comprised of two
   elements: (1) an extended service model, which we call the IS model,
   and (2) a reference implementation framework, which gives us a set of
   vocabulary and a generic program organization to realize the IS
   model.  It is important to separate the service model, which defines
   the externally visible behavior, from the discussion of the
   implementation, which may (and should) change during the life of the
   service model.  However, the two are related; to make the service
   model credible, it is useful to provide an example of how it might be
   realized.

   2.1 Integrated Services Model

      The IS model we are proposing includes two sorts of service
      targeted towards real-time traffic: guaranteed and predictive
      service.  It integrates these services with controlled link-
      sharing, and it is designed to work well with multicast as well as
      unicast.  Deferring a summary of the IS model to Section 3, we
      first discuss some key assumptions behind the model.





Braden, Clark & Shenker                                         [Page 3]

RFC 1633            Integrated Services Architecture           June 1994


      The first assumption is that resources (e.g., bandwidth) must be
      explicitly managed in order to meet application requirements.
      This implies that "resource reservation" and "admission control"
      are key building blocks of the service.  An alternative approach,
      which we reject, is to attempt to support real-time traffic
      without any explicit changes to the Internet service model.

      The essence of real-time service is the requirement for some
      service guarantees, and we argue that guarantees cannot be
      achieved without reservations.  The term "guarantee" here is to be
      broadly interpreted; they may be absolute or statistical, strict
      or approximate.  However, the user must be able to get a service
      whose quality is sufficiently predictable that the application can
      operate in an acceptable way over a duration of time determined by
      the user.  Again, "sufficiently" and "acceptable" are vague terms.
      In general, stricter guarantees have a higher cost in resources
      that are made unavailable for sharing with others.

      The following arguments have been raised against resource
      guarantees in the Internet.

      o    "Bandwidth will be infinite."

           The incredibly large carrying capacity of an optical fiber
           leads some to conclude that in the future bandwidth will be
           so abundant, ubiquitous, and cheap that there will be no
           communication delays other than the speed of light, and
           therefore there will be no need to reserve resources.
           However, we believe that this will be impossible in the short
           term and unlikely in the medium term.  While raw bandwidth
           may seem inexpensive, bandwidth provided as a network service
           is not likely to become so cheap that wasting it will be the
           most cost-effective design principle.  Even if low-cost
           bandwidth does eventually become commonly available, we do
           not accept that it will be available "everywhere" in the
           Internet.  Unless we provide for the possibility of dealing
           with congested links, then real-time services will simply be
           precluded in those cases.  We find that restriction
           unacceptable.

      o    "Simple priority is sufficient."

           It is true that simply giving higher priority to real-time
           traffic would lead to adequate real-time service at some
           times and under some conditions.  But priority is an
           implementation mechanism, not a service model.  If we define
           the service by means of a specific mechanism, we may not get
           the exact features we want.  In the case of simple priority,



Braden, Clark & Shenker                                         [Page 4]

RFC 1633            Integrated Services Architecture           June 1994


           the issue is that as soon as there are too many real-time
           streams competing for the higher priority, every stream is
           degraded.  Restricting our service to this single failure
           mode is unacceptable.  In some cases, users will demand that
           some streams succeed while some new requests receive a "busy
           signal".

      o    "Applications can adapt."

           The development of adaptive real-time applications, such as
           Jacobson's audio program VAT, does not eliminate the need to
           bound packet delivery time.  Human requirements for
           interaction and intelligibility limit the possible range of
           adaptation to network delays.  We have seen in real
           experiments that, while VAT can adapt to network delays of
           many seconds, the users find that interaction is impossible
           in these cases.