rfc1633.txt

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

      We conclude that there is an inescapable requirement for routers
      to be able to reserve resources, in order to provide special QoS
      for specific user packet streams, or "flows".  This in turn
      requires flow-specific state in the routers, which represents an
      important and fundamental change to the Internet model.  The
      Internet architecture was been founded on the concept that all
      flow-related state should be in the end systems [Clark88].
      Designing the TCP/IP protocol suite on this concept led to a
      robustness that is one of the keys to its success.  In section 5
      we discuss how the flow state added to the routers for resource
      reservation can be made "soft", to preserve the robustness of the
      Internet protocol suite.

      There is a real-world side effect of resource reservation in
      routers.  Since it implies that some users are getting privileged
      service, resource reservation will need enforcement of policy and
      administrative controls.  This in turn will lead to two kinds of
      authentication requirements:  authentication of users who make
      reservation requests, and authentication of packets that use the
      reserved resources.  However, these issues are not unique to "IS";
      other aspects of the evolution of the Internet, including
      commercialization and commercial security, are leading to the same
      requirements.  We do not discuss the issues of policy or security
      further in this memo, but they will require attention.

      We make another fundamental assumption, that it is desirable to
      use the Internet as a common infrastructure to support both non-
      real-time and real-time communication.  One could alternatively
      build an entirely new, parallel infrastructure for real-time
      services, leaving the Internet unchanged.  We reject this



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


      approach, as it would lose the significant advantages of
      statistical sharing between real-time and non-real-time traffic,
      and it would be much more complex to build and administer than a
      common infrastructure.

      In addition to this assumption of common infrastructure, we adopt
      a unified protocol stack model, employing a single internet-layer
      protocol for both real-time and non-real-time service.  Thus, we
      propose to use the existing internet-layer protocol (e.g., IP or
      CLNP) for real-time data.  Another approach would be to add a new
      real-time protocol in the internet layer [ST2-90].  Our unified
      stack approach provides economy of mechanism, and it allows us to
      fold controlled link-sharing in easily.  It also handles the
      problem of partial coverage, i.e., allowing interoperation between
      IS-capable Internet systems and systems that have not been
      extended, without the complexity of tunneling.

      We take the view that there should be a single service model for
      the Internet.  If there were different service models in different
      parts of the Internet, it is very difficult to see how any end-
      to-end service quality statements could be made.  However, a
      single service model does not necessarily imply a single
      implementation for packet scheduling or admission control.
      Although specific packet scheduling and admission control
      mechanisms that satisfy our service model have been developed, it
      is quite possible that other mechanisms will also satisfy the
      service model.  The reference implementation framework, introduced
      below, is intended to allow discussion of implementation issues
      without mandating a single design.

      Based upon these considerations, we believe that an IS extension
      that includes additional flow state in routers and an explicit
      setup mechanism is necessary to provide the needed service.  A
      partial solution short of this point would not be a wise
      investment.  We believe that the extensions we propose preserve
      the essential robustness and efficiency of the Internet
      architecture, and they allow efficient management of the network
      resources; these will be important goals even if bandwidth becomes
      very inexpensive.

   2.2 Reference Implementation Framework

      We propose a reference implementation framework to realize the IS
      model.  This framework includes four components: the packet
      scheduler, the admission control routine, the classifier, and the
      reservation setup protocol.  These are discussed briefly below and
      more fully in Sections 4 and 5.




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


      In the ensuing discussion, we define the "flow" abstraction as a
      distinguishable stream of related datagrams that results from a
      single user activity and requires the same QoS.  For example, a
      flow might consist of one transport connection or one video stream
      between a given host pair.  It is the finest granularity of packet
      stream distinguishable by the IS.  We define a flow to be simplex,
      i.e., to have a single source but N destinations.  Thus, an N-way
      teleconference will generally require N flows, one originating at
      each site.

      In today's Internet, IP forwarding is completely egalitarian; all
      packets receive the same quality of service, and packets are
      typically forwarded using a strict FIFO queueing discipline.  For
      integrated services, a router must implement an appropriate QoS
      for each flow, in accordance with the service model.  The router
      function that creates different qualities of service is called
      "traffic control".  Traffic control in turn is implemented by
      three components: the packet scheduler, the classifier, and
      admission control.

      o    Packet Scheduler

           The packet scheduler manages the forwarding of different
           packet streams using a set of queues and perhaps other
           mechanisms like timers.  The packet scheduler must be
           implemented at the point where packets are queued; this is
           the output driver level of a typical operating system, and
           corresponds to the link layer protocol.  The details of the
           scheduling algorithm may be specific to the particular output
           medium.  For example, the output driver will need to invoke
           the appropriate link-layer controls when interfacing to a
           network technology that has an internal bandwidth allocation
           mechanism.

           An experimental packet scheduler has been built that
           implements the IS model described in Section 3 and [SCZ93];
           this is known as the CSZ scheduler and is discussed further
           in Section 4.  We note that the CSZ scheme is not mandatory
           to accomplish our service model; indeed for parts of the
           network that are known always to be underloaded, FIFO will
           deliver satisfactory service.

           There is another component that could be considered part of
           the packet scheduler or separate: the estimator [Jacobson91].
           This algorithm is used to measure properties of the outgoing
           traffic stream, to develop statistics that control packet
           scheduling and admission control.  This memo will consider
           the estimator to be a part of the packet scheduler.



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


      o    Classifier

           For the purpose of traffic control (and accounting), each
           incoming packet must be mapped into some class; all packets
           in the same class get the same treatment from the packet
           scheduler.  This mapping is performed by the classifier.
           Choice of a class may be based upon the contents of the
           existing packet header(s) and/or some additional
           classification number added to each packet.

           A class might correspond to a broad category of flows, e.g.,
           all video flows or all flows attributable to a particular
           organization.  On the other hand, a class might hold only a
           single flow.  A class is an abstraction that may be local to
           a particular router; the same packet may be classified
           differently by different routers along the path.  For
           example, backbone routers may choose to map many flows into a
           few aggregated classes, while routers nearer the periphery,
           where there is much less aggregation, may use a separate
           class for each flow.

      o    Admission Control

           Admission control implements the decision algorithm that a
           router or host uses to determine whether a new flow can be
           granted the requested QoS without impacting earlier
           guarantees.  Admission control is invoked at each node to
           make a local accept/reject decision, at the time a host
           requests a real-time service along some path through the
           Internet.  The admission control algorithm must be consistent
           with the service model, and it is logically part of traffic
           control.  Although there are still open research issues in
           admission control, a first cut exists [JCSZ92].

           Admission control is sometimes confused with policing or
           enforcement, which is a packet-by-packet function at the
           "edge" of the network to ensure that a host does not violate
           its promised traffic characteristics.  We consider policing
           to be one of the functions of the packet scheduler.

           In addition to ensuring that QoS guarantees are met,
           admission control will be concerned with enforcing
           administrative policies on resource reservations.  Some
           policies will demand authentication of those requesting
           reservations.  Finally, admission control will play an






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


           important role in accounting and administrative reporting.

      The fourth and final component of our implementation framework is
      a reservation setup protocol, which is necessary to create and
      maintain flow-specific state in the endpoint hosts and in routers
      along the path of a flow.  Section  discusses a reservation setup
      protocol called RSVP (for "ReSerVation Protocol") [RSVP93a,
      RSVP93b].  It may not be possible to insist that there be only one
      reservation protocol in the Internet, but we will argue that
      multiple choices for reservation protocols will cause confusion.
      We believe that multiple protocols should exist only if they
      support different modes of reservation.

      The setup requirements for the link-sharing portion of the service
      model are far less clear than those for resource reservations.
      While we expect that much of this can be done through network
      management interfaces, and thus need not be part of the overall
      architecture, we may also need RSVP to play a role in providing
      the required state.

      In order to state its resource requirements, an application must
      specify the desired QoS using a list of parameters that is called
      a "flowspec" [Partridge92].  The flowspec is carried by the
      reservation setup protocol, passed to admission control for to
      test for acceptability, and ultimately used to parametrize the
      packet scheduling mechanism.

      Figure  shows how these components might fit into an IP router
      that has been extended to provide integrated services.  The router
      has two broad functional divisions:  the forwarding path below the
      double horizontal line, and the background code above the line.

      The forwarding path of the router is executed for every packet and
      must therefore be highly optimized.  Indeed, in most commercial
      routers, its implementation involves a hardware assist.  The
      forwarding path is divided into three sections: input driver,
      internet forwarder, and output driver.  The internet forwarder
      interprets the internetworking protocol header appropriate to the
      protocol suite, e.g., the IP header for TCP/IP, or the CLNP header
      for OSI.  For each packet, an internet forwarder executes a
      suite-dependent classifier and then passes the packet and its
      class to the appropriate output driver.  A classifier must be both