rfc2475.txt

RFC 的详细文档！

   Marker                    a device that performs marking.

   Marking                   the process of setting the DS codepoint in
                             a packet based on defined rules; pre-
                             marking, re-marking.

   Mechanism                 a specific algorithm or operation (e.g.,
                             queueing discipline) that is implemented in
                             a node to realize a set of one or more per-
                             hop behaviors.



Blake, et. al.               Informational                      [Page 5]

RFC 2475        Architecture for Differentiated Services   December 1998


   Meter                     a device that performs metering.

   Metering                  the process of measuring the temporal
                             properties (e.g., rate) of a traffic stream
                             selected by a classifier.  The
                             instantaneous state of this process may be
                             used to affect the operation of a marker,
                             shaper, or dropper, and/or may be used for
                             accounting and measurement purposes.

   Microflow                 a single instance of an application-to-
                             application flow of packets which is
                             identified by source address, source port,
                             destination address, destination port and
                             protocol id.

   MF Classifier             a multi-field (MF) classifier which selects
                             packets based on the content of some
                             arbitrary number of header fields;
                             typically some combination of source
                             address, destination address, DS field,
                             protocol ID, source port and destination
                             port.

   Per-Hop-Behavior (PHB)    the externally observable forwarding
                             behavior applied at a DS-compliant node to
                             a DS behavior aggregate.

   PHB group                 a set of one or more PHBs that can only be
                             meaningfully specified and implemented
                             simultaneously, due to a common constraint
                             applying to all PHBs in the set such as a
                             queue servicing or queue management policy.
                             A PHB group provides a service building
                             block that allows a set of related
                             forwarding behaviors to be specified
                             together (e.g., four dropping priorities).
                             A single PHB is a special case of a PHB
                             group.

   Policing                  the process of discarding packets (by a
                             dropper) within a traffic stream in
                             accordance with the state of a
                             corresponding meter enforcing a traffic
                             profile.

   Pre-mark                  to set the DS codepoint of a packet prior
                             to entry into a downstream DS domain.



Blake, et. al.               Informational                      [Page 6]

RFC 2475        Architecture for Differentiated Services   December 1998


   Provider DS domain        the DS-capable provider of services to a
                             source domain.

   Re-mark                   to change the DS codepoint of a packet,
                             usually performed by a marker in accordance
                             with a TCA.

   Service                   the overall treatment of a defined subset
                             of a customer's traffic within a DS domain
                             or end-to-end.

   Service Level Agreement   a service contract between a customer and a
   (SLA)                     service provider that specifies the
                             forwarding service a customer should
                             receive.  A customer may be a user
                             organization (source domain) or another DS
                             domain (upstream domain).  A SLA may
                             include traffic conditioning rules which
                             constitute a TCA in whole or in part.

   Service Provisioning      a policy which defines how traffic
   Policy                    conditioners are configured on DS boundary
                             nodes and how traffic streams are mapped to
                             DS behavior aggregates to achieve a range
                             of services.

   Shaper                    a device that performs shaping.

   Shaping                   the process of delaying packets within a
                             traffic stream to cause it to conform to
                             some defined traffic profile.

   Source domain             a domain which contains the node(s)
                             originating the traffic receiving a
                             particular service.

   Traffic conditioner       an entity which performs traffic
                             conditioning functions and which may
                             contain meters, markers, droppers, and
                             shapers. Traffic conditioners are typically
                             deployed in DS boundary nodes only.  A
                             traffic conditioner may re-mark a traffic
                             stream or may discard or shape packets to
                             alter the temporal characteristics of the
                             stream and bring it into compliance with a
                             traffic profile.





Blake, et. al.               Informational                      [Page 7]

RFC 2475        Architecture for Differentiated Services   December 1998


   Traffic conditioning      control functions performed to enforce
                             rules specified in a TCA, including
                             metering, marking, shaping, and policing.

   Traffic Conditioning      an agreement specifying classifier rules
   Agreement (TCA)           and any corresponding traffic profiles and
                             metering, marking, discarding and/or
                             shaping rules which are to apply to the
                             traffic streams selected by the classifier.
                             A TCA encompasses all of the traffic
                             conditioning rules explicitly specified
                             within a SLA along with all of the rules
                             implicit from the relevant service
                             requirements and/or from a DS domain's
                             service provisioning policy.

   Traffic profile           a description of the temporal properties
                             of a traffic stream such as rate and burst
                             size.

   Traffic stream            an administratively significant set of one
                             or more microflows which traverse a path
                             segment.  A traffic stream may consist of
                             the set of active microflows which are
                             selected by a particular classifier.

   Upstream DS domain        the DS domain upstream of traffic flow on a
                             boundary link.

1.3  Requirements

   The history of the Internet has been one of continuous growth in the
   number of hosts, the number and variety of applications, and the
   capacity of the network infrastructure, and this growth is expected
   to continue for the foreseeable future.  A scalable architecture for
   service differentiation must be able to accommodate this continued
   growth.

   The following requirements were identified and are addressed in this
   architecture:

   o  should accommodate a wide variety of services and provisioning
      policies, extending end-to-end or within a particular (set of)
      network(s),

   o  should allow decoupling of the service from the particular
      application in use,




Blake, et. al.               Informational                      [Page 8]

RFC 2475        Architecture for Differentiated Services   December 1998


   o  should work with existing applications without the need for
      application programming interface changes or host software
      modifications (assuming suitable deployment of classifiers,
      markers, and other traffic conditioning functions),

   o  should decouple traffic conditioning and service provisioning
      functions from forwarding behaviors implemented within the core
      network nodes,

   o  should not depend on hop-by-hop application signaling,

   o  should require only a small set of forwarding behaviors whose
      implementation complexity does not dominate the cost of a network
      device, and which will not introduce bottlenecks for future high-
      speed system implementations,

   o  should avoid per-microflow or per-customer state within core
      network nodes,

   o  should utilize only aggregated classification state within the
      network core,

   o  should permit simple packet classification implementations in core
      network nodes (BA classifier),

   o  should permit reasonable interoperability with non-DS-compliant
      network nodes,

   o  should accommodate incremental deployment.

1.4  Comparisons with Other Approaches

   The differentiated services architecture specified in this document
   can be contrasted with other existing models of service
   differentiation.  We classify these alternative models into the
   following categories: relative priority marking, service marking,
   label switching, Integrated Services/RSVP, and static per-hop
   classification.

   Examples of the relative priority marking model include IPv4
   Precedence marking as defined in [RFC791], 802.5 Token Ring priority
   [TR], and the default interpretation of 802.1p traffic classes
   [802.1p].  In this model the application, host, or proxy node selects
   a relative priority or "precedence" for a packet (e.g., delay or
   discard priority), and the network nodes along the transit path apply
   the appropriate priority forwarding behavior corresponding to the
   priority value within the packet's header.  Our architecture can be
   considered as a refinement to this model, since we more clearly



Blake, et. al.               Informational                      [Page 9]

RFC 2475        Architecture for Differentiated Services   December 1998


   specify the role and importance of boundary nodes and traffic
   conditioners, and since our per-hop behavior model permits more
   general forwarding behaviors than relative delay or discard priority.

   An example of a service marking model is IPv4 TOS as defined in
   [RFC1349].  In this example each packet is marked with a request for
   a "type of service", which may include "minimize delay", "maximize
   throughput", "maximize reliability", or "minimize cost".  Network
   nodes may select routing paths or forwarding behaviors which are
   suitably engineered to satisfy the service request.  This model is
   subtly different from our architecture.  Note that we do not describe
   the use of the DS field as an input to route selection.  The TOS
   markings defined in [RFC1349] are very generic and do not span the
   range of possible service semantics.  Furthermore, the service
   request is associated with each individual packet, whereas some
   service semantics may depend on the aggregate forwarding behavior of
   a sequence of packets.  The service marking model does not easily
   accommodate growth in the number and range of future services (since
   the codepoint space is small) and involves configuration of the
   "TOS->forwarding behavior" association in each core network node.
   Standardizing service markings implies standardizing service
   offerings, which is outside the scope of the IETF.  Note that
   provisions are made in the allocation of the DS codepoint space to
   allow for locally significant codepoints which may be used by a