IPCDN QoS MIB: TOS byte -> DSCP field
"Jean-Francois Mule" <[email protected]>
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
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