rfc2990.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,348 行 · 第 1/5 页

   It is reasonable to anticipate that such forms of premium service and
   customized service will attract an increment on the service tariff.
   The provision of a distinguished service is undertaken with some
   level of additional network resources to support the service, and the
   tariff premium should reflect this altered resource allocation.  Not
   only does such an incremental tariff shift the added cost burden to
   those clients who are requesting a disproportionate level of
   resources, but it provides a means to control the level of demand for
   premium service levels.

   If there are to be incremental tariffs on the use of premium
   services, then some accounting of the use of the premium service
   would appear to be necessary relating use of the service to a
   particular client.  So far there is no definition of such an
   accounting model nor a definition as to how to gather the data to
   support the resource accounting function.

   The impact of this QoS service model may be quite profound to the
   models of Internet service provision.  The commonly adopted model in
   both the public internet and within enterprise networks is that of a
   model of access, where the clients service tariff is based on the
   characteristics of access to the services, rather than that of the
   actual use of the service.  The introduction of QoS services creates
   a strong impetus to move to usage-based tariffs, where the tariff is
   based on the level of use of the network's resources.  This, in turn,
   generates a requirement to meter resource use, which is a form of
   usage accounting.  This topic was been previously studied within the



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


   IETF under the topic of "Internet Accounting" [11], and further
   refinement of the concepts used in this model, as they apply to QoS
   accounting may prove to be a productive initial step in formulating a
   standards-based model for QoS accounting.

3.10 QoS Deployment Diversity

   It is extremely improbable that any single form of service
   differentiation technology will be rolled out across the Internet and
   across all enterprise networks.

   Some networks will deploy some form of service differentiation
   technology while others will not.  Some of these service platforms
   will interoperate seamlessly and other less so.  To expect all
   applications, host systems, network routers, network policies, and
   inter-provider arrangements to coalesce into a single homogeneous
   service environment that can support a broad range of service
   responses is an somewhat unlikely outcome given the diverse nature of
   the available technologies and industry business models.  It is more
   likely that we will see a number of small scale deployment of service
   differentiation mechanisms and some efforts to bridge these
   environments together in some way.

   In this heterogeneous service environment the task of service
   capability discovery is as critical as being able to invoke service
   responses and measure the service outcomes.  QoS architectures will
   need to include protocol capabilities in supporting service discovery
   mechanisms.

   In addition, such a heterogeneous deployment environment will create
   further scaling pressure on the operational network as now there is
   an additional dimension to the size of the network.  Each potential
   path to each host is potentially qualified by the service
   capabilities of the path.  While one path may be considered as a
   candidate best effort path, another path may offer a more precise
   match between the desired service attributes and the capabilities of
   the path to sustain the service.  Inter-domain policy also impacts
   upon this path choice, where inter-domain transit agreements may
   specifically limit the types and total level of quality requests than
   may be supported between the domains.  Much of the brunt of such
   scaling pressures will be seen in the inter-domain and intra-domain
   routing domain where there are pressures to increase the number of
   attributes of a routing entry, and also to use the routing protocol
   in some form of service signaling role.







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


3.11 QoS Inter-Domain signaling

   QoS Path selection is both an intra-domain (interior) and an inter-
   domain (exterior) issue.  Within the inter-domain space, the current
   routing technologies allow each domain to connect to a number of
   other domains, and to express its policies with respect to received
   traffic in terms of inter-domain route object attributes.
   Additionally, each domain may express its policies with respect to
   sending traffic through the use of boundary route object filters,
   allowing a domain to express its preference for selecting one
   domain's advertised routes over another.  The inter-domain routing
   space is a state of dynamic equilibrium between these various route
   policies.

   The introduction of differentiated services adds a further dimension
   to this policy space.  For example, while a providers may execute an
   interconnection agreement with one party to exchange best effort
   traffic, it may execute another agreement with a second party to
   exchange service qualified traffic.  The outcome of this form of
   interconnection is that the service provider will require external
   route advertisements to be qualified by the accepted service
   profiles.  Generalizing from this scenario, it is reasonable to
   suggest that we will require the qualification of routing
   advertisements with some form of service quality attributes.  This
   implies that we will require some form of quality vector-based
   forwarding function, at least in the inter-domain space, and some
   associated routing protocol can pass a quality of service vector in
   an operationally stable fashion.

   The implication of this requirement is that the number of objects
   being managed by routing systems must expand dramatically, as the
   size and number of objects managed within the routing domain
   increases, and the calculation of a dynamic equilibrium of import and
   export policies between interconnected providers will also be subject
   to the same level of scaling pressure.

   This has implications within the inter-domain forwarding space as
   well, as the forwarding decision in such a services differentiated
   environment is then qualified by some form of service quality vector.
   This is required in order to pass exterior traffic to the appropriate
   exterior interconnection gateway.

3.12 QoS Deployment Logistics

   How does the widespread deployment of service-aware networks
   commence?  Which gets built first - host applications or network
   infrastructure?




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


   No network operator will make the significant investment in
   deployment and support of distinguished service infrastructure unless
   there is a set of clients and applications available to make
   immediate use of such facilities.  Clients will not make the
   investment in enhanced services unless they see performance gains in
   applications that are designed to take advantage of such enhanced
   services.  No application designer will attempt to integrate service
   quality features into the application unless there is a model of
   operation supported by widespread deployment that makes the
   additional investment in application complexity worthwhile and
   clients who are willing to purchase such applications.  With all
   parts of the deployment scenario waiting for the others to move,
   widespread deployment of distinguished services may require some
   other external impetus.

   Further aspects of this deployment picture lie in the issues of
   network provisioning and the associated task of traffic engineering.
   Engineering a network to meet the demands of best effort flows
   follows a well understood pattern of matching network points of user
   concentrations to content delivery network points with best effort
   paths.  Integrating QoS-mediated traffic engineering into the
   provisioning model suggests a provisioning requirement that also
   requires input from a QoS demand model.

4. The objective of the QoS architecture

   What is the precise nature of the problem that QoS is attempting to
   solve?  Perhaps this is one of the more fundamental questions
   underlying the QoS effort, and the diversity of potential responses
   is a pointer to the breadth of scope of the QoS effort.

   All of the following responses form a part of the QoS intention:

    -  To control the network service response such that the response
       to a specific service element is consistent and predictable.

    -  To control the network service response such that a service
       element is provided with a level of response equal to or above a
       guaranteed minimum.

    -  To allow a service element to establish in advance the service
       response that can or will be obtained from the network.

    -  To control the contention for network resources such that a
       service element is provided with a superior level of network
       resource.





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


    -  To control the contention for network resources such that a
       service element does not obtain an unfair allocation of
       resources (to some definition of 'fairness').

    -  To allow for efficient total utilization of network resources
       while servicing a spectrum of directed network service outcomes.

   Broadly speaking, the first three responses can be regarded as
   'application-centric', and the latter as 'network-centric'.  It is
   critical to bear in mind that none of these responses can be
   addressed in isolation within any effective QoS architecture.  Within
   the end-to-end architectural model of the Internet, applications make
   minimal demands on the underlying IP network.  In the case of TCP,
   the protocol uses an end-to-end control signal approach to
   dynamically adjust to the prevailing network state.  QoS
   architectures add a somewhat different constraint, in that the
   network is placed in an active role within the task of resource
   allocation and service delivery, rather than being a passive object
   that requires end systems to adapt.

5. Towards an end-to-end QoS architecture

   The challenge facing the QoS architecture lies in addressing the
   weaknesses noted above, and in integrating the various elements of
   the architecture into a cohesive whole that is capable of sustaining
   end-to-end service models across a wide diversity of internet
   platforms.  It should be noted that such an effort may not
   necessarily result in a single resultant architecture, and that it is
   possible to see a number of end-to-end approaches based on different
   combinations of the existing components.

   One approach is to attempt to combine both architectures into an
   end-to-end model, using IntServ as the architecture which allows
   applications to interact with the network, and DiffServ as the
   architecture to manage admission the network's resources [7].  In
   this approach, the basic tension that needs to be resolved lies in
   difference between the per-application view of the IntServ
   architecture and the network boundary-centric view of the DiffServ
   architecture.

   One building block for such an end-to-end service architecture is a
   service signaling protocol.  The RSVP signaling protocol can address
   the needs of applications that require a per-service end-to-end
   service signaling environment.  The abstracted model of RSVP is that
   of a discovery signaling protocol that allows an application to use a
   single transaction to communicate its service requirements to both
   the network and the remote party, and through the response mechanism,
   to allow these network elements to commit to the service



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


   requirements.  The barriers to deployment for this model lie in an
   element-by element approach to service commitment, implying that each
   network element must undertake some level of signaling and processing
   as dictated by this imposed state.  For high precision services this
   implies per-flow signaling and per-flow processing to support this
   service model.  This fine-grained high precision approach to service
   management is seen as imposing an unacceptable level of overhead on
   the central core elements of large carrier networks.

   The DiffServ approach uses a model of abstraction which attempts to