rfc3289.txt

RFC 的详细文档！

   The Differentiated Services Architecture does not specify how an
   implementation should be assembled.  The [MODEL] describes a general
   approach to implementation design, or to user interface design.  Its
   components could, however, be assembled in a different way.  For
   example, traffic conforming to a meter might be run through a second
   meter, or reclassified.

   This MIB models the same functional data path elements, allowing the
   network manager to assemble them in any fashion that meets the
   relevant policy.  These data path elements include Classifiers,
   Meters, Actions of various sorts, Queues, and Schedulers.

   In many of these tables, a distinction is drawn between the structure
   of the policy (do this, then do that) and the parameters applied to
   specific policy elements.  This is to facilitate configuration, if
   the MIB is used for that.  The concept is that a set of parameters,
   such as the values that describe a specific token bucket, might be
   configured once and applied to many interfaces.

   The RowPointer Textual Convention is therefore used in two ways in
   this MIB.  It is defined for the purpose of connecting an object to
   an entry dynamically; the RowPointer object identifies the first
   object in the target Entry, and in so doing points to the entire
   entry.  In this MIB, it is used as a connector between successive
   functional data path elements, and as the link between the policy
   structure and the parameters that are used.  When used as a
   connector, it says what happens "next"; what happens to classified
   traffic, to traffic conforming or not conforming to a meter, and so
   on.  When used to indicate the parameters applied in a policy, it
   says "specifically" what is meant; the structure points to the
   parameters of its policy.

   The use of RowPointers as connectors allows for the simple extension
   of the MIB.  The RowPointers, whether "next" or "specific", may point
   to Entries defined in other MIB modules.  For example, the only type
   of meter defined in this MIB is a token bucket meter; if another type
   of meter is required, another MIB could be defined describing that
   type of meter, and diffServMeterSpecific could point to it.
   Similarly, if a new action is required, the "next" pointer of the
   previous functional datapath element could point to an Entry defined
   in another MIB, public or proprietary.








Baker, et. al.              Standards Track                     [Page 6]

RFC 3289              Differentiated Services MIB               May 2002


3.1.  Processing Path

   An interface has an ingress and an egress direction, and will
   generally have a different policy in each direction.  As traffic
   enters an edge interface, it may be classified, metered, counted, and
   marked.  Traffic leaving the same interface might be remarked
   according to the contract with the next network, queued to manage the
   bandwidth, and so on.  As [MODEL] points out, the functional datapath
   elements used on ingress and egress are of the same type, but may be
   structured in very different ways to implement the relevant policies.

3.1.1.  diffServDataPathTable - The Data Path Table

   Therefore, when traffic arrives at an ingress or egress interface,
   the first step in applying the policy is determining what policy
   applies.  This MIB does that by providing a table of pointers to the
   first functional data path element, indexed by interface and
   direction on that interface.  The content of the
   diffServDataPathEntry is a single RowPointer, which points to that
   functional data path element.

   When diffServDataPathStart in a direction on an interface is
   undefined or is set to zeroDotZero, the implication is that there is
   no specific policy to apply.

3.2.  Classifier

   Classifiers are used to differentiate among types of traffic.  In the
   Differentiated Services architecture, one usually discusses a
   behavior aggregate identified by the application of one or more
   Differentiated Services Code Points (DSCPs).  However, especially at
   network edges (which include hosts and first hop routers serving
   hosts), traffic may arrive unmarked or the marks may not be trusted.
   In these cases, one applies a Multi-Field Classifier, which may
   select an aggregate as coarse as "all traffic", as fine as a specific
   microflow identified by IP Addresses, IP Protocol, and TCP or UDP
   ports, or variety of slices in between.

   Classifiers can be simple or complex.  In a core interface, one would
   expect to find simple behavior aggregate classification to be used.
   However, in an edge interface, one might first ask what application
   is being used, meter the arriving traffic, and then apply various
   policies to the non-conforming traffic depending on the Autonomous
   System number advertising the destination address.  To accomplish
   such a thing, traffic must be classified, metered, and then
   reclassified.  To this end, the MIB defines separate classifiers,
   which may be applied at any point in processing, and may have
   different content as needed.



Baker, et. al.              Standards Track                     [Page 7]

RFC 3289              Differentiated Services MIB               May 2002


   The MIB also allows for ambiguous classification in a structured
   fashion.  In the end, traffic classification must be unambiguous; one
   must know for certain what policy to apply to any given packet.
   However, writing an unambiguous specification is often tedious, while
   writing a specification in steps that permits and excludes various
   kinds of traffic may be simpler and more intuitive.  In such a case,
   the classification "steps" are enumerated; all classification
   elements of one precedence are applied as if in parallel, and then
   all classification elements of the next precedence.

   This MIB defines a single classifier parameter entry, the Multi-field
   Classifier.  A degenerate case of this multi-field classifier is a
   Behavior Aggregate classifier.  Other classifiers may be defined in
   other MIB modules, to select traffic from a given layer two neighbor
   or a given interface, traffic whose addresses belong to a given BGP
   Community or Autonomous System, and so on.

3.2.1.  diffServClfrElementTable - The Classifier Element Table

   A classifier consists of classifier elements.  A classifier element
   identifies a specific set of traffic that forms part of a behavior
   aggregate; other classifier elements within the same classifier may
   identify other traffic that also falls into the behavior aggregate.
   For example, in identifying AF traffic for the aggregate AF1, one
   might implement separate classifier elements for AF11, AF12, and AF13
   within the same classifier and pointing to the same subsequent meter.

   Generally, one would expect the Data Path Entry to point to a
   classifier (which is to say, a set of one or more classifier
   elements), although it may point to something else when appropriate.
   Reclassification in a functional data path is achieved by pointing to
   another Classifier Entry when appropriate.

   A classifier element is a structural element, indexed by classifier
   ID and element ID.  It has a precedence value, allowing for
   structured ambiguity as described above, a "specific" pointer that
   identifies what rule is to be applied, and a "next" pointer directing
   traffic matching the classifier to the next functional data path
   element.  If the "next" pointer is zeroDotZero, the indication is
   that there is no further differentiated services processing for this
   behavior aggregate.  However, if the "specific" pointer is
   zeroDotZero, the device is misconfigured.  In such a case, the
   classifier element should be operationally treated as if it were not
   present.

   When the MIB is used for configuration, diffServClfrNextFree and
   diffServClfrElementNextFree always contain legal values for
   diffServClfrId and diffServClfrElementId that are not currently used



Baker, et. al.              Standards Track                     [Page 8]

RFC 3289              Differentiated Services MIB               May 2002


   in the system's configuration.  The values are validated when
   creating diffServClfrId and diffServClfrElementId, and in the event
   of a failure (which would happen if two managers simultaneously
   attempted to create an entry) must be re-read.

3.2.2.  diffServMultiFieldClfrTable - The Multi-field Classifier Table

   This MIB defines a single parameter type for classification, the
   Multi-field Classifier.  As a parameter, a filter may be specified
   once and applied to many interfaces, using
   diffServClfrElementSpecific.  This filter matches:

      o  IP source address prefix, including host, CIDR Prefix, and "any
         source address"

      o  IP destination address prefix, including host, CIDR Prefix, and
         "any destination address"

      o  IPv6 Flow ID

      o  IP protocol or "any"

      o  TCP/UDP/SCTP source port range, including "any"

      o  TCP/UDP/SCTP destination port range, including "any"

      o  Differentiated Services Code Point

   Since port ranges, IP prefixes, or "any" are defined in each case, it
   is clear that a wide variety of filters can be constructed.  The
   Differentiated Services Behavior Aggregate filter is a special case
   of this filter, in which only the DSCP is specified.

   Other MIB modules may define similar filters in the same way.  For
   example, a filter for Ethernet information might define source and
   destination MAC addresses of "any", Ethernet Packet Type, IEEE 802.2
   SAPs, and IEEE 802.1 priorities.  A filter related to policy routing
   might be structured like the diffServMultiFieldClfrTable, but contain
   the BGP Communities of the source and destination prefix rather than
   the prefix itself, meaning "any prefix in this community".  For such
   a filter, a table similar to diffServMultiFieldClfrTable is
   constructed, and diffServClfrElementSpecific is configured to point
   to it.








Baker, et. al.              Standards Track                     [Page 9]

RFC 3289              Differentiated Services MIB               May 2002


   When the MIB is used for configuration,
   diffServMultiFieldClfrNextFree always contains a legal value for
   diffServMultiFieldClfrId that is not currently used in the system's
   configuration.

3.3.  Metering Traffic

   As discussed in [MODEL], a meter and a shaper are functions that
   operate on opposing ends of a link.  A shaper schedules traffic for
   transmission at specific times in order to approximate a particular
   line speed or combination of line speeds.  In its simplest form, if
   the traffic stream contains constant sized packets, it might transmit
   one packet per unit time to build the equivalent of a CBR circuit.
   However, various factors intervene to make the approximation inexact;
   multiple classes of traffic may occasionally schedule their traffic
   at the same time, the variable length nature of IP traffic may
   introduce variation, and factors in the link or physical layer may
   change traffic timing.  A meter integrates the arrival rate of
   traffic and determines whether the shaper at the far end was
   correctly applied, or whether the behavior of the application in
   question is naturally close enough to such behavior to be acceptable
   under a given policy.

   A common type of meter is a Token Bucket meter, such as [srTCM] or
   [trTCM].  This type of meter assumes the use of a shaper at a
   previous node; applications which send at a constant rate when
   sending may conform if the token bucket is properly specified.  It
   specifies the acceptable arrival rate and quantifies the acceptable
   variability, often by specifying a burst size or an interval; since
   rate = quantity/time, specifying any two of those parameters implies
   the third, and a large interval provides for a forgiving system.
   Multiple rates may be specified, as in AF, such that a subset of the
   traffic (up to one rate) is accepted with one set of guarantees, and
   traffic in excess of that but below another rate has a different set
   of guarantees.  Other types of meters exist as well.

   One use of a meter is when a service provider sells at most, a
   certain bit rate to one of its customers, and wants to drop the
   excess.  In such a case, the fractal nature of normal Internet
   traffic must be reflected in large burst intervals, as TCP frequently
   sends packet pairs or larger bursts, and responds poorly when more
   than one packet in a round trip interval is dropped.  Applications
   like FTP contain the effect by simply staying below the target bit
   rate; this type of configuration very adversely affects transaction
   applications like HTTP, however.  Another use of a meter is in the AF
   specification, in which excess traffic is marked with a related DSCP
   and subjected to slightly more active queue depth management.  The




Baker, et. al.              Standards Track                    [Page 10]

RFC 3289              Differentiated Services MIB               May 2002


   application is not sharply limited to a contracted rate in such a
   case, but can be readily contained should its traffic create a
   burden.

3.3.1.  diffServMeterTable - The Meter Table

   The Meter Table is a structural table, specifying a specific
   functional data path element.  Its entry consists essentially of
   three RowPointers - a "succeed" pointer, for traffic conforming to
   the meter, a "fail" pointer, for traffic not conforming to the meter,