rfc2475.txt

RFC 的详细文档！

   deterministic or stochastic thresholds), but this is not required
   (e.g., N equal link shares).  A single PHB defined in isolation is a
   special case of a PHB group.

   PHBs are implemented in nodes by means of some buffer management and
   packet scheduling mechanisms.  PHBs are defined in terms of behavior
   characteristics relevant to service provisioning policies, and not in
   terms of particular implementation mechanisms.  In general, a variety
   of implementation mechanisms may be suitable for implementing a
   particular PHB group.  Furthermore, it is likely that more than one
   PHB group may be implemented on a node and utilized within a domain.
   PHB groups should be defined such that the proper resource allocation
   between groups can be inferred, and integrated mechanisms can be
   implemented which can simultaneously support two or more groups.  A
   PHB group definition should indicate possible conflicts with
   previously documented PHB groups which might prevent simultaneous
   operation.

   As described in [DSFIELD], a PHB is selected at a node by a mapping
   of the DS codepoint in a received packet.  Standardized PHBs have a
   recommended codepoint.  However, the total space of codepoints is
   larger than the space available for recommended codepoints for
   standardized PHBs, and [DSFIELD] leaves provisions for locally
   configurable mappings.  A codepoint->PHB mapping table may contain
   both 1->1 and N->1 mappings.  All codepoints must be mapped to some
   PHB; in the absence of some local policy, codepoints which are not
   mapped to a standardized PHB in accordance with that PHB's
   specification should be mapped to the Default PHB.

2.5  Network Resource Allocation

   The implementation, configuration, operation and administration of
   the supported PHB groups in the nodes of a DS Domain should
   effectively partition the resources of those nodes and the inter-node
   links between behavior aggregates, in accordance with the domain's
   service provisioning policy.  Traffic conditioners can further
   control the usage of these resources through enforcement of TCAs and
   possibly through operational feedback from the nodes and traffic
   conditioners in the domain.  Although a range of services can be
   deployed in the absence of complex traffic conditioning functions
   (e.g., using only static marking policies), functions such as
   policing, shaping, and dynamic re-marking enable the deployment of
   services providing quantitative performance metrics.

   The configuration of and interaction between traffic conditioners and
   interior nodes should be managed by the administrative control of the
   domain and may require operational control through protocols and a
   control entity.  There is a wide range of possible control models.



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


   The precise nature and implementation of the interaction between
   these components is outside the scope of this architecture.  However,
   scalability requires that the control of the domain does not require
   micro-management of the network resources.  The most scalable control
   model would operate nodes in open-loop in the operational timeframe,
   and would only require administrative-timescale management as SLAs
   are varied.  This simple model may be unsuitable in some
   circumstances, and some automated but slowly varying operational
   control (minutes rather than seconds) may be desirable to balance the
   utilization of the network against the recent load profile.

3.  Per-Hop Behavior Specification Guidelines

   Basic requirements for per-hop behavior standardization are given in
   [DSFIELD].  This section elaborates on that text by describing
   additional guidelines for PHB (group) specifications.  This is
   intended to help foster implementation consistency.  Before a PHB
   group is proposed for standardization it should satisfy these
   guidelines, as appropriate, to preserve the integrity of this
   architecture.

   G.1:  A PHB standard must specify a recommended DS codepoint selected
   from the codepoint space reserved for standard mappings [DSFIELD].
   Recommended codepoints will be assigned by the IANA.  A PHB proposal
   may recommend a temporary codepoint from the EXP/LU space to
   facilitate inter-domain experimentation.  Determination of a packet's
   PHB must not require inspection of additional packet header fields
   beyond the DS field.

   G.2:  The specification of each newly proposed PHB group should
   include an overview of the behavior and the purpose of the behavior
   being proposed.  The overview should include a problem or problems
   statement for which the PHB group is targeted.  The overview should
   include the basic concepts behind the PHB group.  These concepts
   should include, but are not restricted to, queueing behavior, discard
   behavior, and output link selection behavior.  Lastly, the overview
   should specify the method by which the PHB group solves the problem
   or problems specified in the problem statement.

   G.3:  A PHB group specification should indicate the number of
   individual PHBs specified.  In the event that multiple PHBs are
   specified, the interactions between these PHBs and constraints that
   must be respected globally by all the PHBs within the group should be
   clearly specified.  As an example, the specification must indicate
   whether the probability of packet reordering within a microflow is
   increased if different packets in that microflow are marked for
   different PHBs within the group.




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


   G.4:  When proper functioning of a PHB group is dependent on
   constraints such as a provisioning restriction, then the PHB
   definition should describe the behavior when these constraints are
   violated.  Further, if actions such as packet discard or re-marking
   are required when these constraints are violated, then these actions
   should be specifically stipulated.

   G.5:  A PHB group may be specified for local use within a domain in
   order to provide some domain-specific functionality or domain-
   specific services.  In this event, the PHB specification is useful
   for providing vendors with a consistent definition of the PHB group.
   However, any PHB group which is defined for local use should not be
   considered for standardization, but may be published as an
   Informational RFC.  In contrast, a PHB group which is intended for
   general use will follow a stricter standardization process.
   Therefore all PHB proposals should specifically state whether they
   are to be considered for general or local use.

   It is recognized that PHB groups can be designed with the intent of
   providing host-to-host, WAN edge-to-WAN edge, and/or domain edge-to-
   domain edge services.  Use of the term "end-to-end" in a PHB
   definition should be interpreted to mean "host-to-host" for
   consistency.

   Other PHB groups may be defined and deployed locally within domains,
   for experimental or operational purposes.  There is no requirement
   that these PHB groups must be publicly documented, but they should
   utilize DS codepoints from one of the EXP/LU pools as defined in
   [DSFIELD].

   G.6:  It may be possible or appropriate for a packet marked for a PHB
   within a PHB group to be re-marked to select another PHB within the
   group; either within a domain or across a domain boundary.  Typically
   there are three reasons for such PHB modification:

   a. The codepoints associated with the PHB group are collectively
      intended to carry state about the network,
   b. Conditions exist which require PHB promotion or demotion of a
      packet (this assumes that PHBs within the group can be ranked in
      some order),
   c. The boundary between two domains is not covered by a SLA.  In this
      case the codepoint/PHB to select when crossing the boundary link
      will be determined by the local policy of the upstream domain.

   A PHB specification should clearly state the circumstances under
   which packets marked for a PHB within a PHB group may, or should be
   modified (e.g., promoted or demoted) to another PHB within the group.
   If it is undesirable for a packet's PHB to be modified, the



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


   specification should clearly state the consequent risks when the PHB
   is modified.   A possible risk to changing a packet's PHB, either
   within or outside a PHB group, is a higher probability of packet re-
   ordering within a microflow.  PHBs within a group may carry some
   host-to-host, WAN edge-to-WAN edge, and/or domain edge-to-domain edge
   semantics which may be difficult to duplicate if packets are re-
   marked to select another PHB from the group (or otherwise).

   For certain PHB groups, it may be appropriate to reflect a state
   change in the node by re-marking packets to specify another PHB from
   within the group.  If a PHB group is designed to reflect the state of
   a network, the PHB definition must adequately describe the
   relationship between the PHBs and the states they reflect.  Further,
   if these PHBs limit the forwarding actions a node can perform in some
   way, these constraints may be specified as actions the node should,
   or must perform.

   G.7:  A PHB group specification should include a section defining the
   implications of tunneling on the utility of the PHB group.  This
   section should specify the implications for the utility of the PHB
   group of a newly created outer header when the original DS field of
   the inner header is encapsulated in a tunnel.  This section should
   also discuss what possible changes should be applied to the inner
   header at the egress of the tunnel, when both the codepoints from the
   inner header and the outer header are accessible (see Sec. 6.2).

   G.8:  The process of specifying PHB groups is likely to be
   incremental in nature.  When new PHB groups are proposed, their known
   interactions with previously specified PHB groups should be
   documented.  When a new PHB group is created, it can be entirely new
   in scope or it can be an extension to an existing PHB group.  If the
   PHB group is entirely independent of some or all of the existing PHB
   specifications, a section should be included in the PHB specification
   which details how the new PHB group can co-exist with those PHB
   groups already standardized.  For example, this section might
   indicate the possibility of packet re-ordering within a microflow for
   packets marked by codepoints associated with two separate PHB groups.
   If concurrent operation of two (or more) different PHB groups in the
   same node is impossible or detrimental this should be stated.  If the
   concurrent operation of two (or more) different PHB groups requires
   some specific behaviors by the node when packets marked for PHBs from
   these different PHB groups are being processed by the node at the
   same time, these behaviors should be stated.

   Care should be taken to avoid circularity in the definitions of PHB
   groups.





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


   If the proposed PHB group is an extension to an existing PHB group, a
   section should be included in the PHB group specification which
   details how this extension interoperates with the behavior being
   extended.  Further, if the extension alters or more narrowly defines
   the existing behavior in some way, this should also be clearly
   indicated.

   G.9:  Each PHB specification should include a section specifying
   minimal conformance requirements for implementations of the PHB
   group.  This conformance section is intended to provide a means for
   specifying the details of a behavior while allowing for
   implementation variation to the extent permitted by the PHB
   specification.  This conformance section can take the form of rules,
   tables, pseudo-code, or tests.

   G.10:  A PHB specification should include a section detailing the
   security implications of the behavior.  This section should include a
   discussion of the re-marking of the inner header's codepoint at the
   egress of a tunnel and its effect on the desired forwarding behavior.

   Further, this section should also discuss how the proposed PHB group
   could be used in denial-of-service attacks, reduction of service
   contract attacks, and service contract violation attacks.  Lastly,
   this section should discuss possible means for detecting such attacks
   as they are relevant to the proposed behavior.

   G.11:  A PHB specification should include a section detailing
   configuration and management issues which may affect the operation of
   the PHB and which may impact candidate services that might utilize
   the PHB.

   G.12:  It is strongly recommended that an appendix be provided with
   each PHB specification that considers the implications of the
   proposed behavior on current and potential services.  These services
   could include but are not restricted to be user-specific, device-
   specific, domain-specific or end-to-end services.  It is also
   strongly recommended that the appendix include a section describing
   how the services are verified by users, devices, and/or domains.

   G.13:  It is recomme