ipcdn DOCSIS QoS mib and closure on IP TOS vs. DSCP open issue

To: Bert Wijnen <[email protected]>, Area Director, IETF Operations and Management Area
From: IPCDN WG Chairs: Richard Woundy <[email protected]>, Jean-Francois Mule <[email protected]>
CC: [email protected]

RE: ipcdn DOCSIS QoS mib and closure on IP TOS vs. DSCP open issue

The DOCSIS QoS MIB (draft-ietf-ipcdn-qos-mib-09) contains five objects which use the (former) IPv4 TOS octet as defined in RFC 791. All are read-only objects which are used to instrument settings that have been configured via a DOCSIS-defined protocol mechanism (configuration file transfer and/or MAC-layer management message exchange).

The five objects are used for two different functionalities within the DOCSIS access network. 

The first functionality is packet classification to provide Quality of Service on the DOCSIS access network.  The DOCSIS protocol includes messaging to configure packet classification that can match packets based on (among other things) the contents of the TOS octet of the IPv4 header.  This IP Type-of-Service classifier configuration uses three parameters: tos-low, tos-high, and tos-mask.  Packets match the classifier if their "ip-tos" byte meets the criteria: tos-low <= (ip-tos AND tos-mask) <= tos-high.  With proper choices of the three parameters (in particular, tos-mask=0xFC, tos-low=tos-high=DSCP<<2), this functionality could be used to enable a DiffServ-capable access network.  Because this functionality is only used to provide QoS on the DOCSIS access network, and does not modify the contents of the IPv4 datagram, this does not break any usage of DiffServ or ECN on the backbone. The following three read-only objects reflect the configured settings for this functionality:
    docsQosPktClassIpTosLow           
    docsQosPktClassIpTosHigh          
    docsQosPktClassIpTosMask           


The second functionality is TOS Overwrite.  The DOCSIS protocol includes messaging to configure the overwrite of the IPv4 TOS octet for certain packet flows in the upstream (from the customer) direction.  This overwrite is done at the headend (CMTS) before the packets are forwarded to the operator's managed IP metro/aggregation network.  The TOS overwrite functionality uses two parameters: tos-and-mask and tos-or-mask.  The TOS octet in applicable packets is overwritten with the value (orig-ip-tos AND tos-and-mask) OR tos-or-mask. With proper choice of these two parameters (in particular, tos-and-mask=0x03, tos-or-mask=DSCP<<2), the operator can set the DSCP for particular packet flows in order to provide PHBs in their metro/aggregation network, without affecting the ECN bits.  Because the entire TOS octet can be overwritten, there is the potential however that an operator could configure their network to overwrite the ECN bits on packets eventually destined for the backbone.  This clearly should be avoided.  The following two read-only objects reflect the configured settings for this functionality:
    docsQosParamSetTosAndMask        
    docsQosParamSetTosOrMask          


Since these objects are read-only and reflect settings that are configured via a standardized (ITU-T Rec. J.112-B, ITU-T Rec. J.122), widely implemented, and widely deployed protocol, changes to the underlying protocol would be required in order to completely eliminate the possibility of overwriting ECN.  We will ensure that future versions of the protocol do not propagate this behavior.  For the past and current versions (for which this MIB was developed), we suggest that additional text be added to DOCSIS QoS MIB RFC to indicate that the TOS Overwrite functionality should not be configured in such a way that it leads to modification of the ECN field.

In particular, we suggest that the following changes be made to address these concerns:

##Change 1##

Current text:
=============
4.  DOCSIS and IPv4 Type-of-Service(ToS) Field

   The DOCSIS-IETF-QOS-MIB does reflect Differented Services Code Point
   (DSCP) [13], instead it use objects that reflect IPv4 Type-of-Service
   (ToS) fields. The DOCSIS specification does not support Differented
   Services at this time because DOCSIS relies on masking of the IP ToS
   bits. Masking is not allowed in Differented Services because of
   cocern the 2 bit that make up the "Explicit Congestion Notification
   (ECN)" field [14] could be overwritten if the mask consisted of 8
   bits.

Suggested text:
===============
4.  DOCSIS and IPv4 Type-of-Service(ToS) Field

   The DOCSIS-IETF-QOS-MIB MIB module relies on the DOCSIS MAC layer 
   protocols and uses objects that reflect the IPv4 Type-of-Service (ToS) 
   octet as defined in RFC791. The applicability of these objects is 
   limited to the DOCSIS access network. The past and current versions of 
   the DOCSIS specifications for which this MIB module is defined do not 
   reflect Differentiated Services [13] on the DOCSIS access network.  
   However, with proper selection of values for these objects, the 
   network operator can enforce Differentiated Services Per-hop Behaviors 
   (PHBs) on the DOCSIS Access Network, and can configure the 
   modification of the DSCP for certain packet flows as they enter the 
   metro network from the access network, essentially making the DOCSIS 
   access network TOS marking compatible with the wider use of DSCP 
   outside DOCSIS networks.  It should be noted that because the entire 
   IPv4 TOS octet is available for modification via the latter mechanism 
   (due to the current MAC level DOCSIS protocols), there is the 
   possibility that the DOCSIS network could be configured to modify the 
   Explicit Congestion Notification (ECN) field [14] of certain packets.  
   This must clearly be avoided and an attempt has been made in this 
   document to outline this limitation of DOCSIS.



##Change 2##

Current Text:
=============
docsQosParamSetTosAndMask OBJECT-TYPE
    SYNTAX          OCTET STRING (SIZE(1))
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "Specifies the AND mask for IP TOS byte for
                    overwriting IP packets TOS value. The IP packets TOS
                    byte is bitwise ANDed with docsQosParamSetTosAndMask
                    and result is bitwise ORed with
                    docsQosParamSetTosORMask and result is written to IP
                    packet TOS byte.
                    A value of 'FF'H for docsQosParamSetTosAndMask and
                    a value of '00'H for docsQosParamSetTosOrMask means
                    that IP Packet TOS byte is not overwritten.

                    This combination is reported if the referenced
                    parameter is not present in a QOS Parameter Set.

                    Even though the this object is only enforced by the
                    Cable Modem Termination System (CMTS),
                    Cable Modems must report the value as signaled in
                    the referenced parameter."
    REFERENCE      "SP-RFIv1.1-I10-037030, Appendix C.2.2.6.10"
    ::= { docsQosParamSetEntry 21 }


Suggested Text:
=============
docsQosParamSetTosAndMask OBJECT-TYPE
    SYNTAX          OCTET STRING (SIZE(1))
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "Specifies the AND mask for IP TOS byte for
                    overwriting IP packets TOS value. The IP packets TOS
                    byte is bitwise ANDed with docsQosParamSetTosAndMask
                    and result is bitwise ORed with
                    docsQosParamSetTosORMask and result is written to IP
                    packet TOS byte.
                    A value of 'FF'H for docsQosParamSetTosAndMask and
                    a value of '00'H for docsQosParamSetTosOrMask means
                    that IP Packet TOS byte is not overwritten.

                    This combination is reported if the referenced
                    parameter is not present in a QOS Parameter Set.

                    The IP TOS octet as originally defined in RFC 791 has
                    been superseded by the 6 bit Differentiated Services
                    Field (DSField, RFC 3260) and the 2 bit Explicit
                    Congestion Notification Field (ECN field, RFC 3168).
                    Network operators should avoid specifying values of 
                    docsQosParamSetTosAndMask and docsQosParamSetTosORMask 
                    which would result in the modification of the ECN 
                    bits.

                    In particular, operators should not use values of 
                    docsQosParamSetTosAndMask which have either of the 
                    least-significant two bits set to 0.  Similarly, 
                    operators should not use values of 
                    docsQosParamSetTosORMask which have either of the 
                    least-significant two bits set to 1. 

                    Even though the this object is only enforced by the
                    Cable Modem Termination System (CMTS),
                    Cable Modems must report the value as signaled in
                    the referenced parameter."
    REFERENCE      "SP-RFIv1.1-I10-037030, Appendix C.2.2.6.10;
                    RFC 3168, The Addition of Explicit Congestion 
                    Notification (ECN) to IP;
                    RFC 3260, New Terminology and Clarifications for
                    Diffserv."
    ::= { docsQosParamSetEntry 21 }