rfc2638.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,223 行 · 第 1/5 页

Network Working Group                                          K. Nichols
Request for Comments: 2638                                    V. Jacobson
Category: Informational                                             Cisco
                                                                 L. Zhang
                                                                     UCLA
                                                                July 1999


    A Two-bit Differentiated Services Architecture for the Internet

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 (1999).  All Rights Reserved.

Abstract

   This document was originally submitted as an internet draft in
   November of 1997. As one of the documents predating the formation of
   the IETF's Differentiated Services Working Group, many of the ideas
   presented here, in concert with Dave Clark's subsequent presentation
   to the December 1997 meeting of the IETF Integrated Services Working
   Group, were key to the work which led to RFCs 2474 and 2475 and the
   section on allocation remains a timely proposal. For this reason, and
   to provide a reference, it is being submitted in its original form.
   The forwarding path portion of this document is intended as a record
   of where we were at in late 1997 and not as an indication of future
   direction.

   The postscript version of this document includes Clark's slides as an
   appendix. The postscript version of this document also includes many
   figures that aid greatly in its readability.

1. Introduction

   This document presents a differentiated services architecture for the
   internet. Dave Clark and Van Jacobson each presented work on
   differentiated services at the Munich IETF meeting [2,3]. Each
   explained how to use one bit of the IP header to deliver a new kind
   of service to packets in the internet. These were two very different
   kinds of service with quite different policy assumptions. Ensuing
   discussion has convinced us that both service types have merit and
   that both service types can be implemented with a set of very similar



Nichols, et al.              Informational                      [Page 1]

RFC 2638      Two-bit Differentiated Services Architecture     July 1999


   mechanisms. We propose an architectural framework that permits the
   use of both of these service types and exploits their similarities in
   forwarding path mechanisms. The major goals of this architecture are
   each shared with one or both of those two proposals: keep the
   forwarding path simple, push complexity to the edges of the network
   to the extent possible, provide a service that avoids assumptions
   about the type of traffic using it, employ an allocation policy that
   will be compatible with both long-term and short-term provisioning,
   make it possible for the dominant Internet traffic model to remain
   best-effort.

   The major contributions of this document are to present two distinct
   service types, a set of general mechanisms for the forwarding path
   that can be used to implement a range of differentiated services and
   to propose a flexible framework for provisioning a differentiated
   services network. It is precisely this kind of architecture that is
   needed for expedient deployment of differentiated services: we need a
   framework and set of primitives that can be implemented in the
   short-term and provide interoperable services, yet can provide a
   "sandbox" for experimentation and elaboration that can lead in time
   to more levels of differentiation within each service as needed.

   At the risk of belaboring an analogy, we are motivated to provide
   services tiers in somewhat the same fashion as the airlines do with
   first class, business class and coach class. The latter also has
   tiering built in due to the various restrictions put on the purchase.
   A part of the analogy we want to stress is that best effort traffic,
   like coach class seats on an airplane, is still expected to make up
   the bulk of internet traffic. Business and first class carry a small
   number of passengers, but are quite important to the economics of the
   airline industry. The various economic forces and realities combine
   to dictate the relative allocation of the seats and to try to fill
   the airplane. We don't expect that differentiated services will
   comprise all the traffic on the internet, but we do expect that new
   services will lead to a healthy economic and service environment.

   This document is organized into sections describing service
   architecture, mechanisms, the bandwidth allocation architecture, how
   this architecture might interoperate with RSVP/int-serv work, and
   gives recommendations for deployment.











Nichols, et al.              Informational                      [Page 2]

RFC 2638      Two-bit Differentiated Services Architecture     July 1999


2. Architecture

2.1 Background

   The current internet delivers one type of service, best-effort, to
   all traffic. A number of proposals have been made concerning the
   addition of enhanced services to the Internet. We focus on two
   particular methods of adding a differentiated level of service to IP,
   each designated by one bit [1,2,3]. These services represent a
   radical departure from the Internet's traditional service, but they
   are also a radical departure from traditional "quality of service"
   architectures which rely on circuit-based models. Both these
   proposals seek to define a single common mechanism that is used by
   interior network routers, pushing most of the complexity and state of
   differentiated services to the network edges. Both use bandwidth as
   the resource that is being requested and allocated. Clark and
   Wroclawski defined an "Assured" service that follows "expected
   capacity" usage profiles that are statistically provisioned [3]. The
   assurance that the user of such a service receives is that such
   traffic is unlikely to be dropped as long as it stays within the
   expected capacity profile. The exact meaning of "unlikely" depends on
   how well provisioned the service is. An Assured service traffic flow
   may exceed its Profile, but the excess traffic is not given the same
   assurance level. Jacobson defined a "Premium" service that is
   provisioned according to peak capacity Profiles that are strictly not
   oversubscribed and that is given its own high-priority queue in
   routers [2]. A Premium service traffic flow is shaped and hard-
   limited to its provisioned peak rate and shaped so that bursts are
   not injected into the network. Premium service presents a "virtual
   wire" where a flow's bursts may queue at the shaper at the edge of
   the network, but thereafter only in proportion to the indegree of
   each router. Despite their many similarities, these two approaches
   result in fundamentally different services. The former uses buffer
   management to provide a "better effort" service while the latter
   creates a service with little jitter and queueing delay and no need
   for queue management on the Premium packets's queue.

   An Assured service was introduced in [3] by Clark and Wroclawski,
   though we have made some alterations in its specification for our
   architecture. Further refinements and an "Expected Capacity"
   framework are given in Clark and Fang [10].  This framework is
   focused on "providing different levels of best-effort service at
   times of network congestion" but also mentions that it is possible to
   have a separate router queue to implement a "guaranteed" level of
   assurance.  We believe this framework and our Two-bit architecture
   are compatible but this needs further exploration.  As Premium
   service has not been documented elsewhere, we describe it next and
   follow this with a description of the two-bit architecture.



Nichols, et al.              Informational                      [Page 3]

RFC 2638      Two-bit Differentiated Services Architecture     July 1999


2.2 Premium service

   In [2], a Premium service was presented that is fundamentally
   different from the Internet's current best effort service. This
   service is not meant to replace best effort but primarily to meet an
   emerging demand for a commercial service that can share the network
   with best effort traffic. This is desirable economically, since the
   same network can be used for both kinds of traffic. It is expected
   that Premium traffic would be allocated a small percentage of the
   total network capacity, but that it would be priced much higher. One
   use of such a service might be to create "virtual leased lines",
   saving the cost of building and maintaining a separate network.
   Premium service, not unlike a standard telephone line, is a capacity
   which the customer expects to be there when the receiver is lifted,
   although it may, depending on the household, be idle a good deal of
   the time.  Provisioning Premium traffic in this way reduces the
   capacity of the best effort internet by the amount of Premium
   allocated, in the worst case, thus it would have to be priced
   accordingly. On the other hand, whenever that capacity is not being
   used it is available to best effort traffic. In contrast to normal
   best effort traffic which is bursty and requires queue management to
   deal fairly with congestive episodes, this Premium service by design
   creates very regular traffic patterns and small or nonexistent
   queues.

   Premium service levels are specified as a desired peak bit-rate for a
   specific flow (or aggregation of flows). The user contract with the
   network is not to exceed the peak rate. The network contract is that
   the contracted bandwidth will be available when traffic is sent.
   First-hop routers (or other edge devices) filter the packets entering
   the network, set the Premium bit of those that match a Premium
   service specification, and perform traffic shaping on the flow that
   smooths all traffic bursts before they enter the network. This
   approach requires no changes in hosts. A compliant router along the
   path needs two levels of priority queueing, sending all packets with
   the Premium bit set first. Best-effort traffic is unmarked and queued
   and sent at the lower priority. This results in two "virtual
   networks": one which is identical to today's Internet with buffers
   designed to absorb traffic bursts; and one where traffic is limited
   and shaped to a contracted peak-rate, but packets move through a
   network of queues where they experience almost no queueing delay.

   In this architecture, forwarding path decisions are made separately
   and more simply than the setting up of the service agreements and
   traffic profiles. With the exception of policing and shaping at
   administrative or "trust" boundaries, the only actions that need to
   be handled in the forwarding path are to classify a packet into one
   of two queues on a single bit and to service the two queues using



Nichols, et al.              Informational                      [Page 4]

RFC 2638      Two-bit Differentiated Services Architecture     July 1999


   simple priority. Shaping must include both rate and burst parameters;
   the latter is expected to be small, in the one or two packet range.
   Policing at boundaries enforces rate compliance, and may be
   implemented by a simple token bucket. The admission and set-up
   procedures are expected to evolve, in time, to be dynamically
   configurable and fairly complex while the mechanisms in the
   forwarding path remain simple.

   A Premium service built on this architecture can be deployed in a
   useful way once the forwarding path mechanisms are in place by making
   static allocations. Traffic flows can be designated for special
   treatment through network management configuration. Traffic flows
   should be designated by the source, the destination, or any
   combination of fields in the packet header. First-hop (of leaf)
   routers will filter flows on all or part of the header tuple