[Detnet] IP Solution problem: Use of DSCP and ECN fields in IP headers for detnet flow identification

["Black, David" <[e-mail]>]

We have a problem here ...

The detnet IP solution draft (draft-ietf-detnet-dp-sol-ip-01.txt) has this to say about
use of DSCP and ECN fields in IP headers for detnet flow identification:

6.1.1.4.  IPv4 Type of Service and IPv6 Traffic Class Fields

   These fields are used to support Differentiated Services [RFC2474]
   and Explicit Congestion Notification [RFC3168].  Implementations of
   this document MUST support DetNet flow identification based on the
   IPv4 Type of Service field when processing IPv4 packets, and the IPv6
   Traffic Class Field when processing IPv6 packets.  Implementations
   MUST support bimask based matching, where one (1) values in the
   bitmask indicate which subset of the bits in the field are to be used
   in determining a match.  Note that a zero (0) value as a bitmask
   effectively means that these fields are ignored.

That bitmask approach won't work, as it violates both RFC 2474 and RFC 3168.

Starting with ECN (RFC 3168) - the 2-bit ECN field is intended to enable ECN functionality to be
applied to any flow, and the contents of the ECN field can be changed by any router.  Using ECN
field values to identify separate flows is wrong, see Section 5 of RFC 3168, which specifies the
current use of that field..

That leaves the 6-bit DSCP field, which is defined by RFC 2474.  The above bitmask approach is
prohibited by the following paragraph in section 3 of RFC 2474:

   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.

The CU field is now the ECN field (see RFC 3168).  My reading is that the current section 6.1.1.4 text in
the IP solutions draft has managed to violate all three "MUST" requirements in that RFC 2474
paragraph, which is impressive ... and not in a good way.

I suggest that several things be done:

a)      Abandon use of the ECN field for detnet flow identification.

b)      For the DSCP field, change from a bitmask approach to a list of DSCPs.

a.      I would note that a carefully chosen DSCP list can be implemented via a bitmask.

c)      Define one or more Diffserv PHBs that realize DetNet behavior.

a.      I suspect that much of the content needed for this already exists in the
detnet drafts, so this should not be a "from scratch" exercise.

I would also caution that the current IP solution draft text on 6-tuples for flow identification appears
to allow multiple separate detnet flows that differ only in DSCP to use the same IP 5-tuple (source &
destination addresses, transport protocol, source & destination ports).  I believe that this also ought
to be prohibited, as Diffserv uses 5-tuples for flow identification - see the definition and use of the
term "microflow" in RFC 2475.

A quick glance at the MPLS solution suggests that it does not have an analogous problem with the TC
field in labels as the TC field does not appear to be used for detnet flow identification.

Thanks, --David
----------------------------------------------------------------
David L. Black, Senior Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
[phone] New    Mobile: [phone]
[e-mail]<mailto:[e-mail]>
----------------------------------------------------------------