rfc2638.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,223 行 · 第 1/5 页

   consisting of the source IP address, destination IP address, protocol
   identifier, source port number, and destination port number. Based on
   this classification, a first-hop router performs traffic shaping and
   sets the designated Premium bit of the precedence field. End-hosts
   are thus not required to be "differentiated services aware", though
   if and when end-systems become universally "aware", they might do
   their own shaping and first-hop routers merely police.

   Adherence to the subscribed rate and burst size must be enforced at
   the entry to the network, either by the end-system or by the first-
   hop router. Within an intranet, administrative domain, or "trust
   region" the packets can then be classified and serviced solely on the
   Premium bit. Where packets cross a boundary, the policing function is
   critical. The entered region will check the prioritized packet flow
   for conformance to a rate the two regions have agreed upon,
   discarding packets that exceed the rate. It is thus in the best
   interests of a region to ensure conformance to the agreed-upon rate
   at the egress. This requirement means that Premium traffic is burst-
   free and, together with the no oversubscription rule, leads directly
   to the observation that Premium queues can easily be sized to prevent
   the need to drop packets and thus the need for a queue management
   policy. At each router, the largest queue size is related to the in-
   degree of other routers and is thus quite small, on the order of ten
   packets.

   Premium bandwidth allocations must not be oversubscribed as they
   represent a commitment by the network and should be priced
   accordingly. Note that, in this architecture, Premium traffic will
   also experience considerably less delay variation than either best
   effort traffic or the Assured data traffic of [3]. Premium rates
   might be configured on a subscription basis in the near-term, or on-
   demand when dynamic set-up or signaling is available.




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


   Figure 1 shows how a Premium packet flow is established within a
   particular administrative domain, Company A, and sent across the
   access link to Company A's ISP. Assume that the host's first-hop
   router has been configured to match a flow from the host's IP address
   to a destination IP address that is reached through ISP. A Premium
   flow is configured from a host with a rate which is both smaller than
   the total Premium allocation Company A has from the ISP, r bytes per
   second, and smaller than the amount of that allocation has been
   assigned to other hosts in Company A. Packets are not marked in any
   special way when they leave the host. The first-hop router clears the
   Premium bit on all arriving packets, sets the Premium bit on all
   packets in the designated flow, shapes packets in the Premium flow to
   a configured rate and burst size, queues best-effort unmarked packets
   in the low priority queue and shaped Premium packets in the high
   priority queue, and sends packets from those two queues at simple
   priority. Intermediate routers internal to Company A enqueue packets
   in one of two output queues based on the Premium bit and service the
   queues with simple priority. Border routers perform quite different
   tasks, depending on whether they are processing an egress flow or an
   ingress flow. An egress border router may perform some reshaping on
   the aggregate Premium traffic to conform to rate r, depending on the
   number of Premium flows aggregated. Ingress border routers only need
   to perform a simple policing function that can be implemented with a
   token bucket. In the example, the ISP accepts all Premium packets
   from A as long as the flow does not exceed r bytes per second.

   Figure 1. Premium traffic flow from end-host to organization's ISP

2.3 Two-bit differentiated services architecture

   Clark's and Jacobson's proposals are markedly similar in the location
   and type of functional blocks that are needed to implement them.
   Furthermore, they implement quite different services which are not
   incompatible in a network. The Premium service implements a
   guaranteed peak bandwidth service with negligible queueing delay that
   cannot starve best effort traffic and can be allocated in a fairly
   straightforward fashion. This service would seem to have a strong
   appeal for commercial applications, video broadcasts, voice-over-IP,
   and VPNs. On the other hand, this service may prove both too
   restrictive (in its hard limits) and overdesigned (no overallocation)
   for some applications. The Assured service implements a service that
   has the same delay characteristics as (undropped) best effort packets
   and the firmness of its guarantee depends on how well individual
   links are provisioned for bursts of Assured packets. On the other
   hand, it permits traffic flows to use any additional available
   capacity without penalty and occasional dropped packets for short
   congestive periods may be acceptable to many users. This service
   might be what an ISP would provide to individual customers who are



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


   willing to pay a bit more for internet service that seems unaffected
   by congestive periods. Both services are only as good as their
   admission control schemes, though this can be more difficult for
   traffic which is not peak-rate allocated.

   There may be some additional benefits of deploying both services. To
   the extent that Premium service is a conservative allocation of
   resources, unused bandwidth that had been allocated to Premium might
   provide some "headroom" for underallocated or burst periods of
   Assured traffic or for best effort. Network elements that deploy both
   services will be performing RED queue management on all non-Premium
   traffic, as suggested in [4], and the effects of mixing the Premium
   streams with best effort might serve to reduce burstiness in the
   latter. A strength of the Assured service is that it allows bursts to
   happen in their natural fashion, but this also makes the
   provisioning, admission control and allocation problem more difficult
   so it may take more time and experimentation before this admission
   policy for this service is completely defined. A Premium service
   could be deployed that employs static allocations on peak rates with
   no statistical sharing.

   As there appear to be a number of advantages to an architecture that
   permits these two types of service and because, as we shall see, they
   can be made to share many of the same mechanisms, we propose
   designating two bit-patterns from the IP header precedence field. We
   leave the explicit designation of these bit-patterns to the standards
   process thus we use the shorthand notation of denoting each pattern
   by a bit, one we will call the Premium or P-bit, the other we call
   the assurance or A-bit. It is possible for a network to implement
   only one of these services and to have network elements that only
   look at the one applicable bit, but we focus on the two service
   architecture. Further, we assume the case where no changes are made
   in the hosts, appropriate packet marking all being done in the
   network, at the first-hop, or leaf, router. We describe the
   forwarding path architecture in this section, assuming that the
   service has been allocated through mechanisms we will discuss in
   section 4.

   In a more general sense, Premium service denotes packets that are
   enqueued at a higher priority than the ordinary best-effort queue.
   Similarly, Assured service denotes packets that are treated
   preferentially with respect to the dropping probability within the
   "normal" queue. There are a number of ways to add more service levels
   within each of these service types [7], but this document takes the
   position of specifying the base-level services of Premium and
   Assured.





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


   The forwarding path mechanisms can be broken down into those that
   happen at the input interface, before packet forwarding, and those
   that happen at the output interface, after packet forwarding.
   Intermediate routers only need to implement the post packet
   forwarding functions, while leaf and border routers must perform
   functions on arriving packets before forwarding. We describe the
   mechanisms this way for illustration; other ways of composing their
   functions are possible.

   Leaf routers are configured with a traffic profile for a particular
   flow based on its packet header. This functionality has been defined
   by the RSVP Working Group in RFC 2205. Figure 2 shows what happens to
   a packet that arrives at the leaf router, before it is passed to the
   forwarding engine. All arriving packets must have both the A-bit and
   the P-bit cleared after which packets are classified on their header.
   If the header does not match any configured values, it is immediately
   forwarded. Matched flows pass through individual Markers that have
   been configured from the usage profile for that flow: service class
   (Premium or Assured), rate (peak for Premium, "expected" for
   Assured), and permissible burst size (may be optional for Premium).
   Assured flow packets emerge from the Marker with their A-bits set
   when the flow is in conformance to its Profile, but the flow is
   otherwise unchanged. For a Premium flow, the Marker will hold packets
   when necessary to enforce their configured rate. Thus Premium flow
   packets emerge from the Marker in a shaped flow with their P-bits
   set. (It is possible for Premium flow packets to be dropped inside of
   the Marker as we describe below.) Packets are passed to the
   forwarding engine when they emerge from Markers. Packets that have
   either their P or A bits set we will refer to as Marked packets.

   Figure 2. Block diagram of leaf router input functionality

   Figure 3 shows the inner workings of the Marker. For both Assured and
   Premium packets, a token bucket "fills" at the flow rate that was
   specified in the usage profile. For Assured service, the token bucket
   depth is set by the Profile's burst size. For Premium service, the
   token bucket depth must be limited to the equivalent of only one or
   two packets. (We suggest a depth of one packet in early deployments.)
   When a token is present, Assured flow packets have their A-bit set to
   one, otherwise the packet is passed to the forwarding engine. For
   Premium-configured Marker, arriving packets that see a token present
   have their P-bits set and are forwarded, but when no token is
   present, Premium flow packets are held until a token arrives. If a
   Premium flow bursts enough to overflow the holding queue, its packets
   will be dropped. Though the flow set up data can be used to configure
   a size limit for the holding queue (this would be the meaning of a
   "burst" in Premium service), it is not necessary. Unconfigured
   holding queues should be capable of holding at least two bandwidth-



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


   delay products, adequate for TCP connections. A smaller value might
   be used to suit delay requirements of a specific application.

   Figure 3. Markers to implement the two different services

   In practice, the token bucket should be implemented in bytes and a
   token is considered to be present if the number of bytes in the
   bucket is equal or larger to the size of the packet. For Premium, the
   bucket can only be allowed to fill to the maximum packet size; while
   Assured may fill to the configured burst parameter. Premium traffic
   is held until a sufficient byte credit has accumulated and this
   holding buffer provides the only real queue the flow sees in the
   network. For Assured, traffic, we just test if the bytes in the
   bucket are sufficient for the packet size and set A if so. If not,
   the only difference is that A is not set. Assured traffic goes into a
   queue following this step and potentially sees a queue at every hop
   along its path.

   Each output interface of a router must have two queues and must
   implement a test on the P-bit to select a packet's output queue. The
   two queues must be serviced by simple priority, Premium packets
   first. Each output interface must implement the RED-based RIO
   mechanism described in [3] on the lower priority queue. RIO uses two
   thresholds for when to begin dropping packets, a lower one based on
   total queue occupancy for ordinary best effort traffic and one based
   on the number of packets enqueued that have their A-bit set. This
   means that any action preferential to Assured service traffic will
   only be taken when the queue's capacity exceeds the threshold value
   for ordinary best effort service. In this case, only unmarked packets
   will be dropped (using the RED algorithm) unless the threshold value
   for Assured service is also reached. Keeping an accurate count of the
   number of A-bit packets currently in a queue requires either testing
   the A-bit at both entry and exit of the queue or some additional
   state in the router. Figure 4 is a block diagram of the output
   interface for all routers.