rfc2638.txt

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

   Figure 4. Router output interface for two-bit architecture

   The packet output of a leaf router is thus a shaped stream of packets
   with P-bits set mingled with an unshaped best effort stream of
   packets, some of which may have A-bits set. Premium service clearly
   cannot starve best effort traffic because it is both burst and
   bandwidth controlled. Assured service might rely only on a
   conservative allocation to prevent starvation of unmarked traffic,
   but bursts of Assured traffic might then close out best-effort
   traffic at bottleneck queues during congestive periods.





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


   After [3], we designate the forwarding path objects that test flows
   against their usage profiles "Profile Meters". Border routers will
   require Profile Meters at their input interfaces. The bilateral
   agreement between adjacent administrative domains must specify a peak
   rate on all P traffic and a rate and burst for A traffic (and
   possibly a start time and duration). A Profile Meter is required at
   the ingress of a trust region to ensure that differentiated service
   packet flows are in compliance with their agreed-upon rates. Non-
   compliant packets of Premium flows are discarded while non-compliant
   packets of Assured flows have their A-bits reset. For example, in
   figure 1, if the ISP has agreed to supply Company A with r bytes/sec
   of Premium service, P-bit marked packets that enter the ISP through
   the link from Company A will be dropped if they exceed r. If instead,
   the service in figure 1 was Assured service, the packets would simply
   be unmarked, forwarded as best effort.

   The simplest border router input interface is a Profile Meter
   constructed from a token bucket configured with the contracted rate
   across that ingress link (see figure 5). Each type, Premium or
   Assured, and each interface must have its own profile meter
   corresponding to a particular class across a particular boundary.
   (This is in contrast to models where every flow that crosses the
   boundary must be separately policed and/or shaped.) The exact
   mechanisms required at a border router input interface depend on the
   allocation policy deployed; a more complex approach is presented in
   section 4.

   Figure 5. Border router input interface Profile Meters

3. Mechanisms

3.1 Forwarding Path Primitives

   Section 2.3 introduced the forwarding path objects of Markers and
   Profile Meters. In this section we specify the primitive building
   blocks required to compose them. The primitives are: general
   classifier, bit-pattern classifier, bit setter, priority queues,
   policing token bucket and shaping token bucket. These primitives can
   compose a Marker (either a policing or a shaping token bucket plus a
   bit setter) and a Profile Meter (a policing token bucket plus a
   dropper or bit setter).

   General Classifier: Leaf or first-hop routers must perform a
   transport-level signature matching based on a tuple in the packet
   header, a functionality which is part of any RSVP-capable router.  As
   described above, packets whose tuples match one of the configured
   flows are conformance tested and have the appropriate service bit
   set.  This function is memory- and processing-intensive, but is kept



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


   at the edges of the network where there are fewer flows.

   Bit-pattern classifier: This primitive comprises a simple two-way
   decision based on whether a particular bit-pattern in the IP header
   is set or not. As in figure 4, the P-bit is tested when a packet
   arrives at a non-leaf router to determine whether to enqueue it in
   the high priority output queue or the low priority packet queue. The
   A-bit of packets bound for the low priority queue is tested to 1)
   increment the count of Assured packets in the queue if set and 2)
   determine which drop probability will be used for that packet.
   Packets exiting the low priority queue must also have the A-bit
   tested so that the count of enqueued Assured packets can be
   decremented if necessary.

   Bit setter: The A-bits and P-bits must be set or cleared in several
   places. A functional block that sets the appropriate bits of the IP
   header to a configured bit-pattern would be the most general.

   Priority queues: Every network element must include (at least) two
   levels of simple priority queueing. The high priority queue is for
   the Premium traffic and the service rule is to send packets in that
   queue first and to exhaustion. Recall that Premium traffic must never
   be oversubscribed, thus Premium traffic should see little or no
   queue.

   Shaping token bucket:This is the token bucket required at the leaf
   router for Premium traffic and shown in figure 3. As we shall see,
   shaping is also useful at egress points of a trust region. An
   arriving packet is immediately forwarded if there is a token present
   in the bucket, otherwise the packet is enqueued until the bucket
   contains tokens sufficient to send it. Shaping requires clocking
   mechanisms, packet memory, and some state block for each flow and is
   thus a memory and computation-intensive process.

   Policing token bucket: This is the token bucket required for Profile
   Meters and shown in figure 5. Policing token buckets never hold
   arriving packets, but check on arrival to see if a token is available
   for the packet's service class. If so, the packet is forwarded
   immediately. If not, the policing action is taken, dropping for
   Premium and reclassifying or unmarking for Assured.

3.2 Passing configuration information

    Clearly, mechanisms are required to communicate the information
   about the request to the leaf router. This configuration information
   is the rate, burst, and whether it is a Premium or Assured type.
   There may also need to be a specific field to set or clear this
   configuration. This information can be passed in a number of ways,



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


   including using the semantics of RSVP, SNMP, or directly set by a
   network administrator in some other way. There must be some
   mechanisms for authenticating the sender of this information. We
   expect configuration to be done in a variety of ways in early
   deployments and a protocol and mechanism for this to be a topic for
   future standards work.

3.3 Discussion

   The requirements of shapers motivate their placement at the edges of
   the network where the state per router can be smaller than in the
   middle of a network. The greatest burden of flow matching and shaping
   will be at leaf routers where the speeds and buffering required
   should be less than those that might be required deeper in the
   network. This functionality is not required at every network element
   on the path. Routers that are internal to a trust region will not
   need to shape traffic. Border routers may need or desire to shape the
   aggregate flow of Marked packets at their egress in order to ensure
   that they will not burst into non-compliance with the policing
   mechanism at the ingress to the other domain (though this may not be
   necessary if the in-degree of the router is low). Further, the
   shaping would be applied to an aggregation of all the Premium flows
   that exit the domain via that path, not to each flow individually.

   These mechanisms are within reach of today's technology and it seems
   plausible to us that Premium and Assured services are all that is
   needed in the Internet. If, in time, these services are found
   insufficient, this architecture provides a migration path for
   delivering other kinds of service levels to traffic. The A- and P-
   bits would continue to be used to identify traffic that gets Marked
   service, but further filter matching could be done on packet headers
   to differentiate service levels further. Using the bits this way
   reduces the number of packets that have to have further matching done
   on them rather than filtering every incoming packet. More queue
   levels and more complex scheduling could be added for P-bit traffic
   and more levels of drop priority could be added for A-bit traffic if
   experience shows them to be necessary and processing speeds are
   sufficient. We propose that the services described here be considered
   as "at least" services. Thus, a network element should at least be
   capable of mapping all P-bit traffic to Premium service and of
   mapping all A-bit traffic to be treated with one level of priority in
   the "best effort" queue (it appears that the single level of A-bit
   traffic should map to a priority that is equivalent to the best level
   in a multi-level element that is also in the path).

   On the other hand, what is the downside of deploying an architecture
   for both classes of service if later experience convinces us that
   only one of them is needed? The functional blocks of both service



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


   classes are similar and can be provided by the same mechanism,
   parameterized differently. If Assured service is not used, very
   little is lost. A RED-managed best effort queue has been strongly
   recommended in [4] and, to the extent that the deployment of this
   architecture pushes the deployment of RED-managed best effort queues,
   it is clearly a positive. If Premium service goes unused, the two-
   queues with simple priority service is not required and the shaping
   function of the Marker may be unused, thus these would impose an
   unnecessary implementation cost.

4. The Architectural Framework for Marked Traffic Allocation

   Thus far we have focused on the service definitions and the
   forwarding path mechanisms. We now turn to the problem of allocating
   the level of Marked traffic throughout the Internet. We observe that
   most organizations have fixed portions of their budgets, including
   data communications, that are determined on an annual or quarterly
   basis. Some additional monies might be attached to specific projects
   for discretionary costs that arise in the shorter term. In turn,
   service providers (ISPs and NSPs) must do their planning on annual
   and quarterly bases and thus cannot be expected to provide
   differentiated services purely "on call". Provisioning sets up static
   levels of Marked traffic while call set-up creates an allocation of
   Marked traffic for a single flow's duration. Static levels can be
   provisioned with time-of-day specifications, but cannot be changed in
   response to a dynamic message. We expect both kinds of bandwidth
   allocation to be important. The purchasers of Marked services can
   generally be expected to work on longer-term budget cycles where
   these services will be accounted for similarly to many information
   services today. A mail-order house may wish to purchase a fixed
   allocation of bandwidth in and out of its web-server to give
   potential customers a "fast" feel when browsing their site. This
   allocation might be based on hit rates of the previous quarter or
   some sort of industry-based averages. In addition, there needs to be
   a dynamic allocation capability to respond to particular events, such
   as a demonstration, a network broadcast by a company's CEO, or a
   particular network test. Furthermore, a dynamic capability may be
   needed in order to meet a precommitted service level when the
   particular source or destination is allowed to be "anywhere on the
   Internet". "Dynamic" covers the range from a telephoned or e-mailed
   request to a signalling type model. A strictly statically allocated
   scenario is expected to be useful in initial deployment of
   differentiated services and to make up a major portion of the Marked
   traffic for the forseeable future.

   Without a "per call" dynamic set up, the preconfiguring of usage
   profiles can always be construed as "paying for bits you don't use"
   whether the type of service is Premium or Assured. We prefer to think



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


   of this as paying for the level of service that one expects to have