rfc2990.txt

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

   flow resource reservations on routers increase in direct proportion
   to the number of separate reservations that need to be accommodated.
   By the same token, router forwarding performance may be impacted
   adversely by the packet-classification and scheduling mechanisms
   intended to provide differentiated services for these resource-
   reserved flows.  This service architecture also poses some challenges
   to the queuing mechanisms, where there is the requirement to allocate
   absolute levels of egress bandwidth to individual flows, while still
   supporting an unmanaged low priority best effort traffic class.

   The stateless approach to service management is more approximate in
   the nature of its outcomes.  Here there is no explicit negotiation
   between the application's signaling of the service request and the
   network's capability to deliver a particular service response.  If
   the network is incapable of meeting the service request, then the
   request simply will not be honored.  In such a situation there is no
   requirement for the network to inform the application that the



Huston                       Informational                      [Page 5]

RFC 2990            Next Steps for QoS Architecture        November 2000


   request cannot be honored, and it is left to the application to
   determine if the service has not been delivered.  The major attribute
   of this approach is that it can possess excellent scaling properties
   from the perspective of the network.  If the network is capable of
   supporting a limited number of discrete service responses, and the
   routers uses per-packet marking to trigger the service response, then
   the processor and memory requirements in each router do not increase
   in proportion to the level of traffic passed through the router.  Of
   course this approach does introduce some degree of compromise in that
   the service response is more approximate as seen by the end client,
   and scaling the number of clients and applications in such an
   environment may not necessarily result in a highly accurate service
   response to every client's application.

   It is not intended to describe these service architectures in further
   detail within this document.  The reader is referred to RFC1633 [3]
   for an overview of the Integrated Services Architecture (IntServ) and
   RFC2475 [4] for an overview of the Differentiated Services
   architecture (DiffServ).

   These two approaches are the endpoints of what can be seen as a
   continuum of control models, where the fine-grained precision of the
   per application invocation reservation model can be aggregated into
   larger, more general and potentially more approximate aggregate
   reservation states, and the end-to-end element-by-element reservation
   control can be progressively approximated by treating a collection of
   subnetworks or an entire transit network as an aggregate service
   element.  There are a number of work in progress efforts which are
   directed towards these aggregated control models, including
   aggregation of RSVP [5], the RSVP DCLASS Object [6] to allow
   Differentiated Services Code Points (DSCPs) to be carried in RSVP
   message objects, and operation of Integrated Services over
   Differentiated Services networks [7].

3. Next Steps for QoS Architectures

   Both the Integrated Services architecture and the Differentiated
   Services architecture have some critical elements in terms of their
   current definition which appear to be acting as deterrents to
   widespread deployment.  Some of these issues will probably be
   addressed within the efforts to introduce aggregated control and
   response models into these QoS architectures, while others may
   require further refinement through standards-related activities.








Huston                       Informational                      [Page 6]

RFC 2990            Next Steps for QoS Architecture        November 2000


3.1 QoS-Enabled Applications

   One of the basic areas of uncertainty with QoS architectures is
   whether QoS is a per-application service, whether QoS is a
   transport-layer option, or both.  Per-application services have
   obvious implications of extending the QoS architecture into some form
   of Application Protocol Interface (API), so that applications could
   negotiate a QoS response from the network and alter their behavior
   according to the outcome of the response.  Examples of this approach
   include GQOS [8], and RAPI [9].  As a transport layer option, it
   could be envisaged that any application could have its traffic
   carried by some form of QoS-enabled network services by changing the
   host configuration, or by changing the configuration at some other
   network control point, without making any explicit changes to the
   application itself.  The strength of the transport layer approach is
   that there is no requirement to substantially alter application
   behavior, as the application is itself unaware of the
   administratively assigned QoS.  The weakness of this approach is that
   the application is unable to communicate what may be useful
   information to the network or to the policy systems that are managing
   the network's service responses.  In the absence of such information
   the network may provide a service response that is far superior than
   the application's true requirements, or far inferior than what is
   required for the application to function correctly.  An additional
   weakness of a transport level approach refers to those class of
   applications that can adapt their traffic profile to meet the
   available resources within the network.  As a transport level
   mechanism, such network availability information as may be available
   to the transport level is not passed back to the application.

   In the case of the Integrated Services architecture, this transport
   layer approach does not appear to be an available option, as the
   application does require some alteration to function correctly in
   this environment.  The application must be able to provide to the
   service reservation module a profile of its anticipated traffic, or
   in other words the application must be able to predict its traffic
   load.  In addition, the application must be able to share the
   reservation state with the network, so that if the network state
   fails, the application can be informed of the failure.  The more
   general observation is that a network can only formulate an accurate
   response to an application's requirements if the application is
   willing to offer precise statement of its traffic profile, and is
   willing to be policed in order to have its traffic fit within this
   profile.

   In the case of the Differentiated Services architecture there is no
   explicit provision for the application to communicate with the
   network regarding service levels.  This does allow the use of a



Huston                       Informational                      [Page 7]

RFC 2990            Next Steps for QoS Architecture        November 2000


   transport level option within the end system that does not require
   explicit alteration of the application to mark its generated traffic
   with one of the available Differentiated Services service profiles.
   However, whether the application is aware of such service profiles or
   not, there is no level of service assurance to the application in
   such a model.  If the Differentiated Services boundary traffic
   conditioners enter a load shedding state, the application is not
   signaled of this condition, and is not explicitly aware that the
   requested service response is not being provided by the network.  If
   the network itself changes state and is unable to meet the cumulative
   traffic loads admitted by the ingress traffic conditioners, neither
   the ingress traffic conditioners, nor the client applications, are
   informed of this failure to maintain the associated service quality.
   While there is no explicit need to alter application behavior in this
   architecture, as the basic DiffServ mechanism is one that is managed
   within the network itself, the consequence is that an application may
   not be aware whether a particular service state is being delivered to
   the application.

   There is potential in using an explicit signaling model, such as used
   by IntServ, but carrying a signal which allows the network to manage
   the application's traffic within an aggregated service class [6].
   Here the application does not pass a complete picture of its intended
   service profile to the network, but instead is providing some level
   of additional information to the network to assist in managing its
   resources, both in terms of the generic service class that the
   network can associate with the application's traffic, and the
   intended path of the traffic through the network.

   An additional factor for QoS enabled applications is that of receiver
   capability negotiation.  There is no value in the sender establishing
   a QoS-enabled path across a network to the receiver if the receiver
   is incapable of absorbing the consequent data flow.  This implies
   that QoS enabled applications also require some form of end-to-end
   capability negotiation, possibly through a generic protocol to allow
   the sender to match its QoS requirements to the minimum of the flow
   resources that can be provided by the network and the flow resources
   that can be processed by the receiver.  In the case of the Integrated
   services architecture the application end-to-end interaction can be
   integrated into the RSVP negotiation.  In the case of the
   Differentiated Services architecture there is no clear path of
   integrating such receiver control into the signaling model of the
   architecture as it stands.

   If high quality services are to be provided, where `high quality' is
   implied as being `high precision with a fine level of granularity',
   then the implication is that all parts of the network that may be
   involved with servicing the request either have to be over-



Huston                       Informational                      [Page 8]

RFC 2990            Next Steps for QoS Architecture        November 2000


   provisioned such that no load state can compromise the service
   quality, or the network element must undertake explicit allocation of
   resources to each flow that is associated with each service request.

   For end-to-end service delivery it does appear that QoS architectures
   will need to extend to the level of the application requesting the
   service profile.  It appears that further refinement of the QoS
   architecture is required to integrate DiffServ network services into
   an end-to-end service delivery model, as noted in [7].

3.2 The Service Environment

   The outcome of the considerations of these two approaches to QoS
   architecture within the network is that there appears to be no single
   comprehensive service environment that possesses both service
   accuracy and scaling properties.

   The maintained reservation state of the Integrated Services
   architecture and the end-to-end signaling function of RSVP are part
   of a service management architecture, but it is not cost effective,
   or even feasible, to operate a per-application reservation and
   classification state across the high speed core of a network [2].

   While the aggregated behavior state of the Differentiated Services
   architecture does offer excellent scaling properties, the lack of
   end-to-end signaling facilities makes such an approach one that
   cannot operate in isolation within any environment.  The
   Differentiated Services architecture can be characterized as a
   boundary-centric operational model.  With this boundary-centric
   architecture, the signaling of resource availability from the
   interior of the network to the boundary traffic conditioners is not
   defined, nor is the signaling from the traffic conditioners to the
   application that is resident on the end system.  This has been noted
   as an additional work item in the IntServ operations over DiffServ
   work, concerning "definition of mechanisms to efficiently and
   dynamically provision resources in a DiffServ network region". This
   might include protocols by which an "oracle" (...) conveys
   information about resource availability within a DiffServ region to
   border routers." [7]

   What appears to be required within the Differentiated Services
   service model is both resource availability signaling from the core
   of the network to the DiffServ boundary and some form of signaling
   from the boundary to the client application.







Huston                       Informational                      [Page 9]

RFC 2990            Next Steps for QoS Architecture        November 2000


3.3 QoS Discovery

   There is no robust mechanism for network path discovery with specific
   service performance attributes.  The assumption within both IntServ
   and DiffServ architectures is that the best effort routing path is
   used, where the path is either capable of sustaining the service
   load, or not.

   Assuming that the deployment of service differentiating
   infrastructure will be piecemeal, even if only in the initial stages
   of a QoS rollout, such an assumption may be unwarranted.  If this is
   the case, then how can a host application determine if there is a