[Bug 1856] Wrong QoS naming and obsolete defaults

Wed Feb 16 13:50:32 EST 2011

https://bugzilla.mindrot.org/show_bug.cgi?id=1856

--- Comment #3 from Philip Prindeville <philipp at redfish-solutions.com> 2011-02-16 13:50:32 EST ---
Quoting the entire Section 3 of RFC-2474 for reference:

3. Differentiated Services Field Definition

   A replacement header field, called the DS field, is defined, which
is
   intended to supersede the existing definitions of the IPv4 TOS octet
   [RFC791] and the IPv6 Traffic Class octet [IPv6].

   Six bits of the DS field are used as a codepoint (DSCP) to select
the
   PHB a packet experiences at each node.  A two-bit currently unused
   (CU) field is reserved and its definition and interpretation are
   outside the scope of this document.  The value of the CU bits are
   ignored by differentiated services-compliant nodes when determining
   the per-hop behavior to apply to a received packet.

   The DS field structure is presented below:

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      |         DSCP          |  CU   |
      +---+---+---+---+---+---+---+---+

        DSCP: differentiated services codepoint
        CU:   currently unused

   In a DSCP value notation 'xxxxxx' (where 'x' may equal '0' or '1')
   used in this document, the left-most bit signifies bit 0 of the DS
   field (as shown above), and the right-most bit signifies bit 5.

   Implementors should note that the DSCP field is six bits wide.  DS-
   compliant nodes MUST select PHBs by matching against the entire
6-bit
   DSCP field, e.g., by treating the value of the field as a table
index
   which is used to select a particular packet handling mechanism which
   has been implemented in that device.  The value of the CU field MUST
   be ignored by PHB selection.  The DSCP field is defined as an
   unstructured field to facilitate the definition of future per-hop
   behaviors.

   With some exceptions noted below, the mapping of codepoints to PHBs
   MUST be configurable.  A DS-compliant node MUST support the logical
   equivalent of a configurable mapping table from codepoints to PHBs.
   PHB specifications MUST include a recommended default codepoint,
   which MUST be unique for codepoints in the standard space (see Sec.
   6).  Implementations should support the recommended codepoint-to-PHB
   mappings in their default configuration.  Operators may choose to
use
   different codepoints for a PHB, either in addition to or in place of
   the recommended default.  Note that if operators do so choose, re-
   marking of DS fields may be necessary at administrative boundaries
   even if the same PHBs are implemented on both sides of the boundary.

   See [ARCH] for further discussion of re-marking.

   The exceptions to general configurability are for codepoints
'xxx000'
   and are noted in Secs. 4.2.2 and 4.3.

   Packets received with an unrecognized codepoint SHOULD be forwarded
   as if they were marked for the Default behavior (see Sec. 4), and
   their codepoints should not be changed.  Such packets MUST NOT cause
   the network node to malfunction.

   The structure of the DS field shown above is incompatible with the
   existing definition of the IPv4 TOS octet in [RFC791].  The
   presumption is that DS domains protect themselves by deploying re-
   marking boundary nodes, as should networks using the RFC 791
   Precedence designations.  Correct operational procedure SHOULD
follow
   [RFC791], which states: "If the actual use of these precedence
   designations is of concern to a particular network, it is the
   responsibility of that network to control the access to, and use of,
   those precedence designations."  Validating the value of the DS
field
   at DS boundaries is sensible in any case since an upstream node can
   easily set it to any arbitrary value.  DS domains that are not
   isolated by suitably configured boundary nodes may deliver
   unpredictable service.

and excerpting the most pertinent two sentences:

"A replacement header field, called the DS field, is defined, which is
intended to supersede the existing definitions of the IPv4 TOS octet
[RFC791] and the IPv6 Traffic Class octet [IPv6]. [...] The structure
of the DS field shown above is incompatible with the existing
definition of the IPv4 TOS octet in [RFC791]."

and quoting Section 4, also for reference:

4. Historical Codepoint Definitions and PHB Requirements

   The DS field will have a limited backwards compatibility with
current
   practice, as described in this section.  Backwards compatibility is
   addressed in two ways.  First, there are per-hop behaviors that are
   already in widespread use (e.g., those satisfying the IPv4
Precedence
   queueing requirements specified in [RFC1812]), and we wish to permit
   their continued use in DS-compliant nodes.  In addition, there are
   some codepoints that correspond to historical use of the IP
   Precedence field and we reserve these codepoints to map to PHBs that
   meet the general requirements specified in Sec. 4.2.2.2, though the
   specific differentiated services PHBs mapped to by those codepoints
   MAY have additional specifications.

   No attempt is made to maintain backwards compatibility with the
"DTR"
   or TOS bits of the IPv4 TOS octet, as defined in [RFC791].

The most significant sentence being the last one: "No attempt is made
to maintain backwards compatibility with the "DTR" or TOS bits of the
IPv4 TOS octet, as defined in [RFC791]."

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.