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

Thanks for the follow up. I am checking myself, and I am also
checking with other IESG members to see if this would make
the doc pass when it comes to IESG.

Hope to have an answer before Thanksgiving

Thanks,
Bert 

> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email protected]]
> Sent: vrijdag 21 november 2003 23:25
> To: Bert
> Cc: [email protected]; Richard Woundy @ Comcast; Jean-Francois Mule; Greg
> White; Murwin William-LWM008; Patrick Michael-LZZ007; Eduardo Cardona;
> Matthew Schmitt
> Subject: ipcdn DOCSIS QoS mib and closure on IP TOS vs. DSCP 
> open issue
> 
> 
> 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 <[email protected]>, Area Director, IETF OPS 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 }
> 
> 
> 
> 
>