21 Nov 2003 23:24
ipcdn DOCSIS QoS mib and closure on IP TOS vs. DSCP open issue
Jean-Francois Mule <jf.mule <at> cablelabs.com>
2003-11-21 22:24:34 GMT
2003-11-21 22:24:34 GMT
Bert, At the last IETF meeting, you asked that we provide a short write-up to close the one open issue on the IPCDN DOCSIS QoS MIB draft09. Greg White has put together the attached note integrating thoughts & comments from the IPCDN QoS MIB co-authors - William Murwin & Patrick Michael, Matt Schmitt, Rich and myself (thank you Greg). I believe this write-up answers your request. It provides: - the list of MIB objects using TOS value in the QoS mib object name, the max-access (read-only), what the object is for and whether it is used in the DOCSIS network only (between CM - CMTS) or whether it would potentially get propagated in the backbone (to understand whether this could break the PHB behavior in the backbone), - the range of TOS values these objects can have and how the mapping with the six bits of DSCP can be achieved, - the justification to maintain TOS based on past & current DOCSIS systems along with the limited applicability scope. Let us know what the next steps are to advance the IPCDN QoS MIB. Upon your review & recommendations, it is our intent to release an updated draft10 which will be ready for publication. Thanks, Rich & Jean-Francois - ipcdn wg co-chairs
To: Bert Wijnen <bwijnen <at> lucent.com>, Area Director, IETF Operations and Management Area
From: IPCDN WG Chairs: Richard Woundy <Richard_Woundy <at> cable.comcast.com>, Jean-Francois Mule <jf.mule <at> cablelabs.com>
CC: ipcdn <at> ietf.org
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 }
RSS Feed