RE: IPCDN QoS MIB: TOS byte -> DSCP field

Sorry that it took a while (Thomas was on vacation, and in general, the first
week after an IETF meeting thinsg are somewhat slow(er).
 
The proposed changes are acceptable and OK. Pls go ahead and make them if not
already done so.
 

Thanks, Bert 

-----Original Message-----
From: Jean-Francois Mule [mailto:[email protected]]
Sent: Friday, August 06, 2004 21:03
To: [email protected]
Cc: Murwin William-LWM008; Patrick Michael-LZZ007; Richard Woundy @ Comcast; [email protected]
Subject: IPCDN QoS MIB: TOS byte -> DSCP field



Bert, 

   Here is a summary of what we discussed on Tuesday at IETF#60 during the IPCDN wg meeting. Let us know if the proposed changes do address the concerns you and other IETF members raised on this draft before.

   Our objective is to close this one issue so that the authors can release a draft 10 for last call. 

Thanks, 
 Jean-Francois 

--- Summary 
   The DOCSIS QoS MIB (draft-ietf-ipcdn-qos-mib-09) contains 7 objects
which use the (former) IPv4 TOS octet as defined in RFC 791. 5 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). 2 other
objects are currently read-create and we propose to make them
read-only and add a new read-write object for DSCP. 
   The proposed changes listed below should address the concerns raised 
in the past.


--- 5 read-only objects and proposal to address TOS concerns
The five read-only objects are used for two different functionalities
within the existing DOCSIS access networks.
 1. 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

 2. 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 must not be configured in such a way
that it leads to modification of the 2 ECN bits.

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 New 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) bits [14] of certain packets.
   This modification of ECN bits MUST 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 New 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 }

## Change 3 ##
We propose to add the text proposed in Change #2 in all the applicable
TOS objects in this MIB.


--- 2 read-create objects and proposal to address the TOS/ECN concerns
The DOCS QOS MIB draft-ietf-ipcdn-qos-mib-09.txt contains two
additional read-create TOS related MIB objects in the
docsQosServiceClassTable table: docsQosServiceClassTosAndMask and
docsQosServiceClassTosOrMask.



As we discussed in the IETF#60 IPCDN meeting, these objects define the
"TOS Overwrite" parameters for an upstream service class.  They allow
the operator to modify individual bits in the IPv4 TOS Octet including
ECN bits.
The WG chairs have raised the following issues based on the original
feedback you provided from Brian Carpenter:
 - These 2 objects can be SET through SNMP, and their values could
   change a packet's ecn bits.
 - DSCPs are not supposed to be "masked"
 - The use of TOS in object names is discouraged, in favor of DSCP.

The proposed resolution is as follows:
 - Make the 2 TOS objects read-only to reflect the existing
   functionality of DOCSIS.
   This Change #4 allows the operators to maintain existing DOCSIS
   implementations and strongly discourage the improper modification
   of ECN bits.
 - Add a new writable object for "DSCP Overwrite"
   This Change #5 allows diffserv compliant operation & preserves ECN.
   We will use DscpOrAny Textual-Convention from RFC 3289.


## Change 4##

Current Text:
=============
docsQosServiceClassTosAndMask OBJECT-TYPE
    SYNTAX          OCTET STRING (SIZE(1))
    MAX-ACCESS      read-create
    STATUS          current
    DESCRIPTION    "Template for docsQosParamSetTosAndMask."
    DEFVAL          { 'FF'H }
    ::= { docsQosServiceClassEntry 20 }

docsQosServiceClassTosOrMask OBJECT-TYPE
    SYNTAX          OCTET STRING (SIZE(1))
    MAX-ACCESS      read-create
    STATUS          current
    DESCRIPTION    "Template for docsQosParamSetTosOrMask."
    DEFVAL          { '00'H }
    ::= { docsQosServiceClassEntry 21 }

Suggested New Text:
===================
docsQosServiceClassTosAndMask OBJECT-TYPE
    SYNTAX          OCTET STRING (SIZE(1))
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "Template for docsQosParamSetTosAndMask.
                    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
                    docsQosServiceClassTosAndMask and
                    docsQosServiceClassTosOrMask which would result in
                    the modification of the ECN bits.

                    In particular, operators should not use values of
                    docsQosServiceClassTosAndMask which have either of the
                    least-significant two bits set to 0.  Similarly,
                    operators should not use values of
                    docsQosServiceClassTosOrMask which have either of the
                    least-significant two bits set to 1."
    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."
    DEFVAL          { 'FF'H }
    ::= { docsQosServiceClassEntry 20 }

docsQosServiceClassTosOrMask OBJECT-TYPE
    SYNTAX          OCTET STRING (SIZE(1))
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "Template for docsQosParamSetTosOrMask.
                    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
                    docsQosServiceClassTosAndMask and
                    docsQosServiceClassTosOrMask which would result in
                    the modification of the ECN bits.

                    In particular, operators should not use values of
                    docsQosServiceClassTosAndMask which have either of the
                    least-significant two bits set to 0.  Similarly,
                    operators should not use values of
                    docsQosServiceClassTosOrMask which have either of the
                    least-significant two bits set to 1."
    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."
    DEFVAL          { '00'H }
    ::= { docsQosServiceClassEntry 21 }

## Change 5##
(this proposed object has not been reviewed, this is just to
give the idea...)
docsQosServiceClassDSCPOverwrite OBJECT-TYPE
    SYNTAX          DscpOrAny -- TC imported from RFC 3289
    MAX-ACCESS      read-create
    STATUS          current
    DESCRIPTION    "This object allows the overwrite of the DSCP
                    field per RFC 3260."

    REFERENCE      "RFC 3168, The Addition of Explicit Congestion
                    Notification (ECN) to IP;
                    RFC 3260, New Terminology and Clarifications for
                    Diffserv."
    DEFVAL          { -1 }
    ::= { docsQosServiceClassEntry 24 }

_______________________________________________
IPCDN mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn