FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs
"Woundy, Richard" <Richard_Woundy@cable.comcast.com> Fri, 07 March 2003 17:49 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19673 for <diffserv-archive@odin.ietf.org>; Fri, 7 Mar 2003 12:49:06 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27I0gM19843 for diffserv-archive@odin.ietf.org; Fri, 7 Mar 2003 13:00:42 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HrbO19012; Fri, 7 Mar 2003 12:53:37 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27EoNO31822 for <diffserv@optimus.ietf.org>; Fri, 7 Mar 2003 09:50:23 -0500
Received: from peacock.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05311 for <diffserv@ietf.org>; Fri, 7 Mar 2003 09:38:17 -0500 (EST)
Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id h27EeNJD029323 for <diffserv@ietf.org>; Fri, 7 Mar 2003 07:40:23 -0700 (MST)
Received: from 147.191.90.10 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Fri, 07 Mar 2003 07:40:15 -0600
Received: by entexchimc03.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id <DKVQ7YYC>; Fri, 7 Mar 2003 07:38:42 -0700
Message-ID: <6732623D2548D61193C90002A5C88DCC05663797@entmaexch02.broadband.att.com>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: "'diffserv@ietf.org'" <diffserv@ietf.org>
Subject: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs
Date: Fri, 07 Mar 2003 07:40:12 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 127670C51148509-01-01
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-BeenThere: diffserv@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>, <mailto:diffserv-request@ietf.org?subject=unsubscribe>
List-Id: Diffserv Discussion List <diffserv.ietf.org>
List-Post: <mailto:diffserv@ietf.org>
List-Help: <mailto:diffserv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>, <mailto:diffserv-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Diffserv folks, I'm looking for further reaction to my email below about DOCSIS/Dscp interaction. Note that I am not subscribed to your mailing list, so please include my email address on replies. -- Rich -----Original Message----- From: Woundy, Richard Sent: Friday, March 07, 2003 9:28 AM To: 'Wilson.Sawyer@arrisi.com'; Wijnen, Bert (Bert) Cc: bwijnen@lucent.com; Ipcdn (E-mail); Thomas Narten (E-mail) Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Folks, I think there are two issues here: are Dscp mask objects legal, and are they worthwhile? Note: in my latest DOCSIS Cable Device MIB submission (e.g. <http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-05.txt>), the new object docsDevFilterInetDscp is defined with SYNTAX DscpOrAny, with no mask object. I can't really say whether Wilson or I are correct on this topic. I agree with Wilson when he emphasizes that these Dscp objects in the various DOCSIS MIB are access filters, not PHB selectors. In fact, such objects enable the DOCSIS equipment to act precisely as "re-marking boundary nodes", which are also described in RFC 2474 Section 3, pages 8-9: The structure of the DS field shown above is incompatible with the existing definition of the IPv4 TOS octet in [RFC791]. The presumption is that DS domains protect themselves by deploying re- marking boundary nodes, as should networks using the RFC 791 Precedence designations. Correct operational procedure SHOULD follow [RFC791], which states: "If the actual use of these precedence designations is of concern to a particular network, it is the responsibility of that network to control the access to, and use of, those precedence designations." Validating the value of the DS field at DS boundaries is sensible in any case since an upstream node can easily set it to any arbitrary value. DS domains that are not isolated by suitably configured boundary nodes may deliver unpredictable service. Nodes MAY rewrite the DS field as needed to provide a desired local or end-to-end service. Specifications of DS field translations at DS boundaries are the subject of service level agreements between providers and users, and are outside the scope of this document. Standardized PHBs allow providers to build their services from a well-known set of packet forwarding treatments that can be expected to be present in the equipment of many vendors. On the other hand, I see the definite lack of structure in the DiffServ codepoints, and I am debating with myself whether a "Dscp mask" is worth the trouble or not. In particular, I am looking at the current codepoint assignments in <http://www.iana.org/assignments/dscp-registry>, and wondering how I could optimize matching on Assured Forwarding class 1 (AF1x) using a Dscp value/mask pair. If I use Dscp value 001000 / mask 111000, I accidentally include Class Selector 1 (CS1) in the matched set. If I specifically add an "ignore" Dscp value 001000 / mask 111111 filter for CS1, then I need two Dscp value/mask filters to capture AF1x traffic -- instead of three Dscp value-only filters for AF1x traffic. This is a small savings. On the other hand, if I desire to optimize matching any of the non-default Class Selectors CS1-7, I could use an "ignore" Dscp value 000000 / mask 111111 filter for CS0, and a second Dscp value 000000 / mask 000111 filter for CS1-7. This is a significant savings compared to the seven Dscp value-only filters for CS1-7. A really tricky case is if I desire to optimize matching any Assured Forwarding or Expedited Forwarding codepoints. I might choose to use an "ignore" Dscp value 000000 / mask 000111 filter for CS0-7, and a second Dscp value 000000 / mask 000000 filter for AFxy and EF PHB. While this represents a huge savings over the thirteen Dscp value-only filters, it may capture traffic with Dscp codepoints that are not yet defined by the IETF/IANA, which represents some risk. -- Rich -----Original Message----- From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] Sent: Friday, March 07, 2003 8:12 AM To: Wijnen, Bert (Bert) Cc: bwijnen@lucent.com; Ipcdn (E-mail); ipcdn-admin@ietf.org; Thomas Narten (E-mail) Subject: Re: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Keep in mind we're talking about a *filter* here, not a PHB selector. And we'e not inferring bit-structure in the implementation, merely allowing the network operator to take advantage of any structure that exists. Do we really want to require the operator to install three separate filters to catch one AF class? I don't find anything in the cited paragraph that contraindicates this sort of usage. The fact that today's PHB selector set is likely to change is all the more reason to give a filter-installer some options for concise representation. - Wilson "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" <ipcdn@ietf.org> <bwijnen@lucent.c cc: bwijnen@lucent.com, "Thomas Narten (E-mail)" om> <narten@us.ibm.com> Sent by: Subject: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs ipcdn-admin@ietf. org 03/07/03 05:57 AM This is one comment I got back from Diffserv list Thanks, Bert -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: woensdag 5 maart 2003 18:29 To: Wijnen, Bert (Bert) Cc: diffserv@ietf.org Subject: Re: [Diffserv] Dscp and DscpOrAny TCs Good catch, Bert. The idea of a mask for the DSCP was killed some time ago in Policy Framework based on its incompatibility with the following explicit prohibition in the definition of the Differentiated Services Field: RFC 2474 Section 3, page 7 Implementors should note that the DSCP field is six bits wide. DS- compliant nodes MUST select PHBs by matching against the entire 6-bit DSCP field, e.g., by treating the value of the field as a table index which is used to select a particular packet handling mechanism which has been implemented in that device. The value of the CU field MUST be ignored by PHB selection. The DSCP field is defined as an unstructured field to facilitate the definition of future per-hop behaviors. John At 11:36 AM 3/5/2003, Wijnen, Bert (Bert) wrote: >Do Diffservers think that the following is wise and makes sense? > > docsSubMgtPktFilterDscpValue OBJECT-TYPE > SYNTAX Dscp > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The Differentiated Services Code Point (DSCP) value to match > in the IP packet." > DEFVAL { 0 } > ::= { docsSubMgtPktFilterEntry 9 } > > docsSubMgtPktFilterDscpMask OBJECT-TYPE > SYNTAX Dscp > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The mask to apply against the DSCP value to be matched in > the IP packet. The default for both these objects taken together > matches all DSCP values. A packet matches this filter if the > following is true: > AND (FilterDscpValue, FilterDscpMask) == > AND (Packet DSCP Value, FilterDscpMask)." > DEFVAL { 0 } > ::= { docsSubMgtPktFilterEntry 10 } > >It is defined in draft-ietf-ipcdn-subscriber-mib-10.txt and I'd like >to hear comments from Diffserv experts. > >Thanks, >Bert _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
- [Diffserv] Dscp and DscpOrAny TCs Wijnen, Bert (Bert)
- Re: [Diffserv] Dscp and DscpOrAny TCs John Schnizlein
- RE: [Diffserv] Dscp and DscpOrAny TCs Andrew Smith
- Re: [Diffserv] Dscp and DscpOrAny TCs Brian E Carpenter
- RE: [Diffserv] Dscp and DscpOrAny TCs Wijnen, Bert (Bert)
- RE: [Diffserv] Dscp and DscpOrAny TCs Andrew Smith
- FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Woundy, Richard
- RE: [Diffserv] Dscp and DscpOrAny TCs Wijnen, Bert (Bert)
- Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… John Schnizlein
- RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Andrew Smith
- RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Andrew Smith
- [Diffserv] simulator for diffserv Sapna Isotupa
- Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… Brian E Carpenter
- RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Woundy, Richard
- RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… Woundy, Richard
- RE: [Diffserv] Dscp and DscpOrAny TCs Woundy, Richard
- RE: [Diffserv] Dscp and DscpOrAny TCs Jean-Francois Mule
- Re: [Diffserv] simulator for diffserv Martin Westhead
- RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… Andrew Smith
- RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… Woundy, Richard