From mailnull@www1.ietf.org Thu Jan 2 13:06:59 2003 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 NAA09859 for ; Thu, 2 Jan 2003 13:06:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h02IFM510000 for ipcdn-archive@odin.ietf.org; Thu, 2 Jan 2003 13:15:22 -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 h02IF6J09990; Thu, 2 Jan 2003 13:15:06 -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 h02IDoJ09930 for ; Thu, 2 Jan 2003 13:13:50 -0500 Received: from e33.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09811 for ; Thu, 2 Jan 2003 13:04:56 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h02I7vSK015152; Thu, 2 Jan 2003 13:07:57 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h02I7uT7079234; Thu, 2 Jan 2003 11:07:57 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id h02I44T31178; Thu, 2 Jan 2003 13:04:05 -0500 Message-Id: <200301021804.h02I44T31178@rotala.raleigh.ibm.com> To: "Woundy, Richard" cc: "IPCDN (E-mail)" , "Erik Nordmark (E-mail)" , "Jean-Francois Mule (E-mail)" In-Reply-To: Message from "Woundy, Richard" of "Tue, 24 Dec 2002 11:27:27 MST." <6732623D2548D61193C90002A5C88DCC01EBD026@entmaexch02.broadband.att.com> Date: Thu, 02 Jan 2003 13:04:04 -0500 From: Thomas Narten Subject: [ipcdn] Re: Proposal for an interim IPCDN working group meeting Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Rich, An interim meeting certainly has potential for being a good thing. TO justify an interim, I think you (and the WG) need to make a case that there will be sufficient "critical mass" at the interim to make it useful. Also, it would be necessary to have an advance agenda so that folks can decide whether its worth their while to attend, how much time you will need, what documents will be the focus, etc. Also, presumably some work needs to be done in advance of the meeting itself (i.e., revise and/or submit new IDs). I would expect that the folks with such work items would be clearly identified and would need to commit to meeting appropriate deadlines in order for the WG meeting itself to meet its goals. Thomas _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Jan 3 10:07:41 2003 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 KAA10452 for ; Fri, 3 Jan 2003 10:07:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03FGVx31394 for ipcdn-archive@odin.ietf.org; Fri, 3 Jan 2003 10:16:31 -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 h03FGBJ31386; Fri, 3 Jan 2003 10:16:11 -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 h03FE3J31264 for ; Fri, 3 Jan 2003 10:14:03 -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 KAA10361 for ; Fri, 3 Jan 2003 10:04:41 -0500 (EST) Received: from mms02-RelayB.tci.com (mms02-relayb.broadband.att.com [147.191.89.213]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id h03F6FCH005399; Fri, 3 Jan 2003 08:06:15 -0700 (MST) Received: from 147.191.90.11 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Fri, 03 Jan 2003 08:06:11 -0600 Received: by entexchimc04.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 3 Jan 2003 08:05:47 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD04B@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "Alexander Katsnelson (E-mail)" , "Charles Schell (E-mail)" , "David Raftus (E-mail)" , "Doug Jones (E-mail)" , "Eugene Nechamkin (E-mail)" , "Howard Abramson (E-mail)" , "Junming Gao (E-mail)" , "Matt Osman (E-mail)" , "Michael Patrick (E-mail)" , "Satish Kumar (E-mail)" , "Siripunkaw, Pak" , "Sumanth Channabasappa (E-mail)" , "William Murwin (E-mail)" , "Wilson Sawyer (E-mail)" , "Wim De Ketelaere (E-mail)" , "Woundy, Richard" cc: "IPCDN (E-mail)" Date: Fri, 3 Jan 2003 08:06:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 120B796979619-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] FW: Typos in the MIB boilerplate Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit IPCDN authors, Please note the typo corrections below to apply to the new MIB boilerplate, . Also be aware that the MIB Security Considerations is being re-edited at this time. -- Rich -----Original Message----- From: C. M. Heard [mailto:heard@pobox.com] Sent: Thursday, January 02, 2003 10:55 PM To: mibs@ops.ietf.org Subject: Typos in the MIB boilerplate Hello, I noticed a couple of typos in the boilerplate at http://www.ops.ietf.org/mib-boilerplate.html Specifically, the last paragraph should be changed from Y. Informative Refenreces <-- spelling + missing comma V [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. to Y. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. //cmh _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Mon Jan 6 11:26:29 2003 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 LAA06577 for ; Mon, 6 Jan 2003 11:26:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06Gal828040 for ipcdn-archive@odin.ietf.org; Mon, 6 Jan 2003 11:36:47 -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 h06GaYJ28025; Mon, 6 Jan 2003 11:36:34 -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 h06GZuJ27993 for ; Mon, 6 Jan 2003 11:35:56 -0500 Received: from scbh01.terayon.com (desktop.terayon.com [63.201.251.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06552 for ; Mon, 6 Jan 2003 11:25:07 -0500 (EST) Received: by SCBH01 with Internet Mail Service (5.5.2655.55) id ; Mon, 6 Jan 2003 08:26:16 -0800 Message-ID: From: "Raftus, David" To: "'Woundy, Richard'" , "Alexander Katsnelson (E-mail)" , "Charles Schell (E-mail)" , "Raftus, David" , "Doug Jones (E-mail)" , "Eugene Nechamkin (E-mail)" , "Howard Abramson (E-mail)" , "Junming Gao (E-mail)" , "Matt Osman (E-mail)" , "Michael Patrick (E-mail)" , "Satish Kumar (E-mail)" , "Siripunkaw, Pak" , "Sumanth Channabasappa (E-mail)" , "William Murwin (E-mail)" , "Wilson Sawyer (E-mail)" , "Wim De Ketelaere (E-mail)" Cc: "IPCDN (E-mail)" , "Jean-Francois Mule (E-mail)" Date: Mon, 6 Jan 2003 08:24:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] RE: Updating the IPCDN WG milestones Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi, The RF mib track looks fine to me. Dave ************************************ David Raftus Imedia Semiconductor 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 david.raftus@imedia.com 613.592.1052 ext 222 ************************************ -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Tuesday, December 24, 2002 2:35 PM To: Alexander Katsnelson (E-mail); Charles Schell (E-mail); David Raftus (E-mail); Doug Jones (E-mail); Eugene Nechamkin (E-mail); Howard Abramson (E-mail); Junming Gao (E-mail); Matt Osman (E-mail); Michael Patrick (E-mail); Satish Kumar (E-mail); Siripunkaw, Pak; Sumanth Channabasappa (E-mail); William Murwin (E-mail); Wilson Sawyer (E-mail); Wim De Ketelaere (E-mail); Woundy, Richard Cc: IPCDN (E-mail); Jean-Francois Mule (E-mail) Subject: Updating the IPCDN WG milestones Authors, Please provide your feedback by January 10th about whether the working group milestones in are reasonable to you. The milestones enumerate deadlines for drafts, which is why we need your feedback. In some cases (PacketCable and CableHome MIBs in particular), we need your assistance in setting realistic milestone dates. With your input, the IPCDN co-chairs can complete the IPCDN re-chartering process with the IESG. -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 7 17:18:51 2003 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 RAA01078 for ; Tue, 7 Jan 2003 17:18:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07MTjR23075 for ipcdn-archive@odin.ietf.org; Tue, 7 Jan 2003 17:29:45 -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 h07MTSJ23049; Tue, 7 Jan 2003 17:29:28 -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 h07MNVJ22780 for ; Tue, 7 Jan 2003 17:23:31 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00854 for ; Tue, 7 Jan 2003 17:12:05 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h07MFJW15789 for ; Tue, 7 Jan 2003 17:15:19 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Jan 2003 23:15:18 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155989C9B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Wilson.Sawyer@arrisi.com, "Wijnen, Bert (Bert)" Cc: richard_woundy@cable.comcast.com, "Ipcdn (E-mail)" Date: Tue, 7 Jan 2003 23:15:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [ipcdn] RE: (ipcdn) review of subscriber management mib? Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Well, it compiles clean. Good. But... you get me confused. You made some good changes based on my review I think, but it seems they are incomplete. For example I see: docsSubMgtPktFilterSrcAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The source IP address to match in the packet to be classified. By default, this is the all-zero's IP v4 and v6 address. A packet matches the SrcAddr filter if the following is true: AND (FilterSrcAddr, FilterSrcMask) == AND (Packet SrcAddr, FilterSrcMask). The mask value is applied to both the match value in this table and to the packet IP address. The address type of this object is specified by docsSubMgtPktFilterAddrType." DEFVAL { '0400000000'H } -- 0.0.0.0 ::= { docsSubMgtPktFilterEntry 4 } docsSubMgtPktFilterSrcMask OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the number of leftmost 1's bits in an address bit mask. The bit mask that is applied to the source address prior to matching. This, taken with the SrcAddr specifies a matching criteria. By default, the pair specifies a filter which matches all source addresses. The address type of this object is specified by docsSubMgtPktFilterAddrType." DEFVAL { 0 } ::= { docsSubMgtPktFilterEntry 5 } It is good that you use a prefixnow for the Mask (maybe I would just call it Prefix instead of Mask as well, but that is another matter). But now that you have done so, I think that the algorithm from above: A packet matches the SrcAddr filter if the following is true: AND (FilterSrcAddr, FilterSrcMask) == AND (Packet SrcAddr, FilterSrcMask). The mask value is applied to both the match value in this table Of course no longer works, cause the Mask is now not an ipaddress anymore. I also see (In MODULE COMPLIANCE): OBJECT docsSubMgtPktFilterAddrType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." the above is OK OBJECT docsSubMgtPktFilterSrcAddr SYNTAX InetAddress (SIZE(5)) DESCRIPTION "An implementation is only required to support IPv4 addresses." But why has an IP Address (in an InetAddress) all of a sudden become 5 octets instead of 4 (as in your rev 6) ?? More later Thanks, Bert > -----Original Message----- > From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > Sent: maandag 6 januari 2003 16:18 > To: Wijnen, Bert (Bert) > Cc: richard_woundy@cable.comcast.com > Subject: RE: (ipcdn) review of subscriber management mib? > > > > Bert - > > Happy new year! > > Rich and Jean-Francois are organizing an interim ipcdn > meeting in February > and have posed a January 20 deadline for i-d updates from > myself and the > other ipcdn authors. If you can help me meet that, I would be > grateful. > There'll be a draft -08 in any case because: > > -- the SNMP references and boilerplate have changed. > -- someone has pointed out that the filter lists are not > explicit about the > default (matched-no-filter) behavior. > > Regards, > Wilson > > > > > > "Wijnen, Bert > > (Bert)" To: > Wilson.Sawyer@arrisi.com, bert.wijnen@lucent.com > > om> Subject: RE: > (ipcdn) review of subscriber management mib? > > > 12/17/02 10:02 AM > > > > > > > > > > Not yet, but hope to get to it before the end of the year > > Thanks, > Bert > > > -----Original Message----- > > From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > > Sent: dinsdag 17 december 2002 15:37 > > To: bert.wijnen@lucent.com > > Subject: (ipcdn) review of subscriber management mib? > > > > > > Hi Bert, > > > > Have you had a chance to look at > > draft-ietf-ipcdn-subscriber-mib-07.txt, > > now that we're past the November meeting? > > > > Please let me know if there's anything I can do to help. > > > > Regards, > > Wilson > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 7 19:28:21 2003 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 TAA05210 for ; Tue, 7 Jan 2003 19:28:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h080dII32024 for ipcdn-archive@odin.ietf.org; Tue, 7 Jan 2003 19:39:18 -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 h080d9J31989; Tue, 7 Jan 2003 19:39:09 -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 h080aaJ31242 for ; Tue, 7 Jan 2003 19:36:36 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05096 for ; Tue, 7 Jan 2003 19:25:08 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h080SM126361 for ; Tue, 7 Jan 2003 19:28:22 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 01:28:21 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155989CAA@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Wilson.Sawyer@arrisi.com'" , "'Wijnen, Bert (Bert)'" Cc: "'richard_woundy@cable.comcast.com'" , "Ipcdn (E-mail)" Date: Wed, 8 Jan 2003 01:28:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [ipcdn] RE: (ipcdn) review of subscriber management mib? Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , I wrote: > For example I see: > docsSubMgtPktFilterSrcAddr OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The source IP address to match in the packet to be > classified. By default, this is the all-zero's IP v4 and v6 > address. A packet matches the SrcAddr filter if the > following is > true: > AND (FilterSrcAddr, FilterSrcMask) == > AND (Packet SrcAddr, FilterSrcMask). > The mask value is applied to both the match value in this table > > and to the packet IP address. The address type of this object is > specified by docsSubMgtPktFilterAddrType." > DEFVAL { '0400000000'H } -- 0.0.0.0 > ::= { docsSubMgtPktFilterEntry 4 } > > docsSubMgtPktFilterSrcMask OBJECT-TYPE > SYNTAX InetAddressPrefixLength > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Specifies the number of leftmost 1's bits in an address > bit mask. The bit mask that is applied to the source address > prior to matching. This, taken with the SrcAddr specifies a > matching criteria. By default, the pair specifies a filter > which matches all source addresses. The address type of this > object is specified by docsSubMgtPktFilterAddrType." > DEFVAL { 0 } > ::= { docsSubMgtPktFilterEntry 5 } > > It is good that you use a prefixnow for the Mask (maybe I would > just call it Prefix instead of Mask as well, but that is another > matter). But now that you have done so, I think that the algorithm > from above: > A packet matches the SrcAddr filter if the following is > true: > AND (FilterSrcAddr, FilterSrcMask) == > AND (Packet SrcAddr, FilterSrcMask). > The mask value is applied to both the match value in this table > > Of course no longer works, cause the Mask is now not an ipaddress > anymore. After rereading I see you use the prefix to create the mask. So that is kind of OK then I think. It just is that "FileterSrcMask" is the suffix of the descriptor, and so it confused me (and probably will confuse others) to think that you use the prefix number itself to AND... maybe a bit better explanations would help Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 7 19:35:04 2003 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 TAA05525 for ; Tue, 7 Jan 2003 19:35:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h080k2132449 for ipcdn-archive@odin.ietf.org; Tue, 7 Jan 2003 19:46:02 -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 h080k1J32442; Tue, 7 Jan 2003 19:46:01 -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 h080jlJ32412 for ; Tue, 7 Jan 2003 19:45:47 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05496 for ; Tue, 7 Jan 2003 19:34:18 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h080bX128877 for ; Tue, 7 Jan 2003 19:37:33 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 01:37:32 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155989CAC@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Wilson.Sawyer@arrisi.com'" , "'Wijnen, Bert (Bert)'" Cc: "'richard_woundy@cable.comcast.com'" , "'Ipcdn (E-mail)'" Date: Wed, 8 Jan 2003 01:37:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [ipcdn] RE: (ipcdn) review of subscriber management mib? Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Looking in more detail, I start to see why you used length 5 in the MODULE-COMPLIANCE docsSubMgtPktFilterSrcAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The source IP address to match in the packet to be classified. By default, this is the all-zero's IP v4 and v6 address. A packet matches the SrcAddr filter if the following is true: AND (FilterSrcAddr, FilterSrcMask) == AND (Packet SrcAddr, FilterSrcMask). The mask value is applied to both the match value in this table and to the packet IP address. The address type of this object is specified by docsSubMgtPktFilterAddrType." DEFVAL { '0400000000'H } -- 0.0.0.0 ::= { docsSubMgtPktFilterEntry 4 } The 04 in the DEFVAL, what is that? Do you intend it to mean IPv4? Or is it intended to be the length? None of these should be in the InetAddress field. Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 7 20:10:18 2003 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 UAA06790 for ; Tue, 7 Jan 2003 20:10:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h081LGX01945 for ipcdn-archive@odin.ietf.org; Tue, 7 Jan 2003 20:21:16 -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 h081L3J01927; Tue, 7 Jan 2003 20:21:03 -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 h081KuJ01912 for ; Tue, 7 Jan 2003 20:20:56 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06759 for ; Tue, 7 Jan 2003 20:09:26 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id h081Ccmb016471; Tue, 7 Jan 2003 18:12:38 -0700 (MST) content-class: urn:content-classes:message Subject: RE: [ipcdn] RE: (ipcdn) review of subscriber management mib? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 7 Jan 2003 18:12:38 -0700 Message-ID: Thread-Topic: [ipcdn] RE: (ipcdn) review of subscriber management mib? Thread-Index: AcK2rnNsVAbLG7VXQlKuvzJAYgUaWwAAGHAg From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , Cc: , "Ipcdn (E-mail)" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h081KuJ01913 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Wilson, As Bert pointed the 04 will show up only if the ScrAddr (or InetAddress Type ) field were part of a multi-indexed table, It that were the case still not needed in the SYNTAX clause a size 5, the Index encoding will introduce the length of the octet string, the object size itself is still 4 for mib purposes. See RFC3291 section 4.1 Bert, My next question is (in general for all DOCSIS mibs drafts and DOCSIS InetAddress types) : Among the mib documents, there are multiple Compliance statements to specify that inetAddress is required only to specify ipv4 type ""An implementation is only required to support IPv4 addresses." Q: If indeed this is done for all drafts, Would still IETF prefer to define InetAddress TEXTUAL-CONVENTION for all this objects instead of InetAddressIPv4 ? And avoid all those COMPLIANCE statements that are replicating in a verbose way the InetAddressIPv4 SYNTAX . (ipv6, dns types are not required in all DOCSIS modules ) In such way a NMS will have the DISPLAY-HINT 1d.1d.1d.1d ready that is the current pain. I can still illegally have a friend IPv4 representation by adding in the Browser MIB a DISPLAY-HINT to InetAddress TEXTUAL-CONVENTION in RFC3291, but is not the desired solution. Thanks Eduardo -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Tuesday, January 07, 2003 5:37 PM To: 'Wilson.Sawyer@arrisi.com'; 'Wijnen, Bert (Bert)' Cc: 'richard_woundy@cable.comcast.com'; 'Ipcdn (E-mail)' Subject: [ipcdn] RE: (ipcdn) review of subscriber management mib? Looking in more detail, I start to see why you used length 5 in the MODULE-COMPLIANCE docsSubMgtPktFilterSrcAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The source IP address to match in the packet to be classified. By default, this is the all-zero's IP v4 and v6 address. A packet matches the SrcAddr filter if the following is true: AND (FilterSrcAddr, FilterSrcMask) == AND (Packet SrcAddr, FilterSrcMask). The mask value is applied to both the match value in this table and to the packet IP address. The address type of this object is specified by docsSubMgtPktFilterAddrType." DEFVAL { '0400000000'H } -- 0.0.0.0 ::= { docsSubMgtPktFilterEntry 4 } The 04 in the DEFVAL, what is that? Do you intend it to mean IPv4? Or is it intended to be the length? None of these should be in the InetAddress field. Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 7 20:42:12 2003 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 UAA07834 for ; Tue, 7 Jan 2003 20:42:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h081rB703814 for ipcdn-archive@odin.ietf.org; Tue, 7 Jan 2003 20:53:11 -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 h081r6J03806; Tue, 7 Jan 2003 20:53:06 -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 h081qEJ03784 for ; Tue, 7 Jan 2003 20:52:14 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07788 for ; Tue, 7 Jan 2003 20:40:43 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h081hv115638 for ; Tue, 7 Jan 2003 20:43:57 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 02:43:56 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155989CB3@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'wsawyer@ieee.org'" , "'ipcdn@ietf.org'" Cc: "Thomas Narten (E-mail)" , "Erik Nordmark (E-mail)" , "Bert Wijnen (E-mail)" Date: Wed, 8 Jan 2003 02:43:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] RE: MIB Doctor review of: draft-ietf-ipcdn-subscriber-mib-07.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , base on my earlier comments on rev 06 > -----Original Message----- > From: Wijnen, Bert (Bert) > Sent: dinsdag 1 oktober 2002 17:28 > To: wsawyer@ieee.org; ipcdn@ietf.org > Cc: Thomas Narten (E-mail); Erik Nordmark (E-mail); Bert > Wijnen (E-mail) > Subject: MIB Doctor review of: draft-ietf-ipcdn-subscriber-mib-06.txt > > > Took a bit longer than I had hoped. Oh well, here we go > > More or less serious issues/concerns: > - 2nd para in Section 2 starts off with: > "Much of this MIB duplicates capabilities found in > the DOCSIS Cable Device MIB [17]." > So I immediately wonder why we need to duplicate any of > that other stuff, even without looking at the details. > Pls explain/justify. > The other praragraphs in this section try to explain some > of it I think. But what is not clear is: will this MIB > then obsolete the one in reference [17]. > If it only partially obsoletes/replaces it, then maybe > that should be made clear and the [17] may need a > revision to deprecate the objects being replaced. I see text is added, also had some more input from the authors/editors. I have suggested to potentially add some more of the explanations that were given to me to the document in this section. > - In sect 2.1 you write: > "The docsSubMgtCpeControlTable, docsSubMgtCpeIpTable, > and docsSubMgtCmFilterTable augment the > docsIfCmtsCmStatusTable from [18]." > I do see this is true for docsSubMgtCpeControlTable but > for docsSubMgtCmFilterTable you are not using the AUGMENTS > clause. So maybe it is only a sparse augmentation? If so, > the better say so. If it is a real AUGMENT then use the > AUGMENTS clause. docsSubMgtCmFilterTable now uses AUGMENTS. However docsSubMgtCpeIpTable does not. so it seems it rather extends than augments? > - Mmm... sect 2.2 starts to talk about the use of TFTTTP... > what does that have to do with the MIB? Maybe explain that > a bit (better). FOr example, why such is needed. And maybe > you can add a reference where people can find info about it. > The good news is that you do mention possible security aspects > (with references) in the Security Considerations section. Hope > it is acceptable to Security ADs. I don't see any changes... but I won't hold you up on this > - Sect 2.3 > I really wonder if this is smart. Why not give a much larger range > to the index objects and then specify via the MODULE COMPLIANCE > that they only need to support up to 1024. That way you do not > have to change the MIB in the future if you ever need more > than 1024. You then add another compliance statement (which > can actually be done in a different module/document) I had some private emails from authors/editors that I have now responded to. I see that this is now handled much better (or at least in my opinion). I guess the WG agrees. > - The MIB MODULE-IDENTITY also talks about experimental. > You want to removethat if you go for STDs track > - In the MIB you must use 4-digit year notation, so > change > LAST-UPDATED "0202280000Z" -- February 28, 2002 > into > LAST-UPDATED "200202280000Z" -- February 28, 2002 > and also > REVISION "0202280000Z" -- February 28, 2002 > into > REVISION "200202280000Z" -- February 28, 2002 fixed, thanks > - Normally, for a new RFC, we only have one REVISION clause. Whatever > changes were made during the WG process are not recorded in revision > clauses, so you can remove the 2nd revision clause. > In fact the one and only revision clause should say something like: > > REVISION "200202280000Z" -- February 28, 2002 > DESCRIPTION "Initial version, published as RFC xxxx." > -- RFC Editor to assign xxxx fixed, thanks > - I am not comfortable with you putting this MIB under { docsDev 5 } > How does DCOSIS keep track as to hwo makes assignments under > the docsDev OID subtree? > Why can this not be another assignment under mib-2 ?? > Certainly it should not have been docsDev 5 while you were making > all sorts of changes during the WG process or while it was so > called "experimental" ... > - I see: > docsSubMgtCpeControlReset OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This object always returns false on read. If this object is > set to true, the rows with 'learned' addresses in > docsSubMgtCpeIpTable for this CM are deleted from that table." > Mmm.. so if I SET the object to true and do a GET afterwards then > it is back in false? I need to check if SNMP/MIB people are > really happy with this. I saw comment from Mike. I checked with MIB doctors team. here are some comments I got: - As long as there is 1) a time stamp, 2) doing this multiple times in a row doesn't mess anything up, and 3) it cannot fail, then it should be fine. - If you don't get a response back, how do you determine if the action was done? One way is a time stamp, another is a counter. - What happens when one writes a "false" into one of these? Why is it necessary for the object to have two possible values if only one is ever observed? > - I am kind of wondering about the AUGEMENTS for > AUGMENTS { docsIfCmtsCmStatusEntry } > Are all the WG members and potential implementers aware that you are > adding read-write objects to an otherwise read-only table? > I guess it would be good to spell out in the DESCRIPTION clause > of this table: > - that it AUGEMENTS (instead of extends) the docsIfCmtsCmStatusTable > - that it adds 4 WRITEable objects. Mike reacted to the above that the first bullet is covered by RFC2578. I know that. I intended the 2 bullets to go together. I may not have bean clear. The warning in the description I feel should explain that you are adding WRITABLE objects to a READ-ONLY base table. That is something to be aware of I think. I see that such has been done, thanks > - the following 3 objects that define defaults. Can you explain how > that works and when they come into play. I see that hey do when the > registration fails. So is it that when a cable modem registers, then > this MIB-table (at a device in the provider premises?) gets > populated with whatever the user registers? And if he does not > register you still add entries to this MIB-table and the defaults > get picked up in that case? I don;t see any additional explanation. I guess all is clear to the WG and people who need to implement? > I may be confused, because neither in this document > nor in RFC2669/2670 did I find where this MIB and the others reside. > Would be good to have a picture of the devices involved, where they > are located adn what their function is. > - table docsSubMgtPktFilterTable is a read-create table. > I see no StorageType object and no words at all about the > persistency > of that table. We need to understand the behaviour for persistency. > This comment applies to all your read-create tables. In fact it also > applies (I think) to read-write values of other objects and other > tables as well. > - I see: > docsSubMgtPktFilterGroup Integer32, > docsSubMgtPktFilterIndex Integer32, > docsSubMgtPktFilterSrcAddrType InetAddressType, > docsSubMgtPktFilterSrcAddr InetAddress, > docsSubMgtPktFilterSrcMaskType InetAddressType, > docsSubMgtPktFilterSrcMask InetAddress, > docsSubMgtPktFilterDstAddrType InetAddressType, > docsSubMgtPktFilterDstAddr InetAddress, > docsSubMgtPktFilterDstMaskType InetAddressType, > docsSubMgtPktFilterDstMask InetAddress, > A few remarks/questions > - that would give me the impression that the addressType for > address and mask could be different. > - it also gives me the impression that addressType for source > and destination can be different. > - From your COMPLIANCE section that seems not to be the case > for current implementers of this MIB. > Not clear if it will never be the case in the future. > - Anyway, if addressType is the same, then only one such object > is needed. Maybe an old version of the INET-ADDRESS-MIB did > suggest that you needed multiple. But the current version > as per RFC 3291. > - This new version also suggest to use InetAddressPrefixLength > instead of a mask. Pls take a look at that. > - if the DEFVAL for docsSubMgtPktFilterSrcAddrType is ipv4, > then why is the DEFVAL for docsSubMgtPktFilterSrcAddr not 0.0.0.0? Much better now, thanks > - same for Destination address > - object docsSubMgtPktFilterUlp says: > DESCRIPTION > "Upper level protocol to match. If this value is 256, > matches ALL ULP values. Otherwise, this matches the specific > protocol value. Note that if the packet ULP is either 6 (tcp) or > 17 (udp), then docsSubMgtPktTcpUdpFilterTable must also be > consulted (if its entry exists) to see if this entry matches. > If this value is neither tcp(6) nor udp(17), then that > table is not consulted." > while object docsSubMgtTcpUdpFilterTable says: > DESCRIPTION ".... This table > is not consulted unless the upper-layer protocol is TCP, > UDP, or 'any'." > So that seems to conflict with each other. (I would also add (256) > after 'any' so it is easier to make the connection. > In the first object you say it is onlu consulted for tcp and udp > and in the table itself you say that it is also consulted for 'any' Fixed, thanks you > - I see: > docsSubMgtPktFilterAction OBJECT-TYPE > SYNTAX INTEGER > { > accept(1), > drop(2) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The action to take upon this filter matching. Accept means > to accept the packet for further processing. Drop means to drop > the packet." > And I wonder: what does "further processing" mean? Will it be checked > against the next filter... or will it be forwarded, or what. > "drop" seems clear in that the packet gets dropped. I see no change. I will assume it is all clear to the WG and the people who need to implement > - I see: > docsSubMgtTcpUdpSrcPort Integer32, > docsSubMgtTcpUdpDstPort Integer32, > These probably should be of type InetPortNumber instead, see RFC3291 Fixed, thanks. > - object docsSubMgtTcpFlagValues > says: ..................... An attempt to violate this constraint > returns an inconsistentValue error for an SNMPv2 or v3 agent > and a badValue error for an SNMPv1 agent. > We prefer that you just talk about the inconsistentValue error and > not mention SNMPvx at all. RFC2576 has common procedures to > translate such errors between different versions of SNMP. fixed, thanks > - For rowStatus objects, you MUST also indicate which objects must have > proper values before the row can be made active. See RowStatus TC > in RFC2579. SO this comment applies to all your rowStatus objects. I see this has been fixed > - you have no Notifications, so there seems to be no need to define > docsSubMgtNotification OBJECT IDENTIFIER ::= { docsSubMgt 2 } fixed, thanks > - Why have you commented out (in the MODULE COMPLIANCE) > -- SYNTAX InetAddressType { ipv4(1) } > because if you only requite support for IPv4, then that is > exactly how you specify it in the MIB. I know that some older > version of SMICng complians about it... but you can ignore that > error/warning. See for example RFC3289 that uses it too. Fixed, thanks > Now ... are cable modems not supporting IPv6 and will they not > do so in the (near) future? > Cuase. what might be a problem though is that in principle the > IETF requires support for IPv4 and IPv6 these days. > Thomas or Erik, any comment on that? I leave that to Thomas and Erik > - In the security section, you MUST list the objects that are > sensitive (read or read-write or read-create) and then for > each of them explain why they are sensitive and need protection. > Looks much better already... but see below > Administrative/editorial nits: > - In the abstract, it talks about "experimental portion". > Should be just "portion" if you're heading for PS. > - the RFC-Editor does not want unfamiliar acronyms in the > title. See http://www.rfc-editor.org/policy.html > I think MIB is OK, but DOSCIS is probably not OK. > Same comment for abstract. > - 2nd para in abstract is not needed. That is already part > of the MIB boiler plate as you have it in sect 1. > - references need to be split in normative and informative. > Again see: http://www.rfc-editor.org/policy.html > For the references in the MIB boiler-plate, a good sample > of the split is in draft-ietf-rmonmib-hc-alarm-mib-02.txt > - object docsSubMgtCpeIpAddr has a decription clause that > talks about "wiretapping". Not sure you want to use that term. > Look much better now. Now ... since this all took a while... new SNMPv3 RFCs have come out. That means a new MIB boiler plate as per http://www.ops.ietf.org/mib-boilerplate.html And also new security considerations guidelines as per http://www.ops.ietf.org/security.html The good news is they are much shorter and have far less references. So I think it would be easy to pick up. If not, then RFC-Editor will probably have to do it (or at least update the current references to new RFC numbers). While you're editing, I think this is easy to pick up. We laso have another thing to add to the MODULE-DESCRIPTION clause as per: http://www.ietf.org/IESG/STATEMENTS/MIB-COPYRIGHT.txt It is easy to do too I think. If not done, then RFC-Editor will add it as you can read. However, reducing load on RFC-Editor will speed up things in the whole process. Hope this helps, Bert > Thanks, > Bert > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Jan 8 05:19:23 2003 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 FAA15761 for ; Wed, 8 Jan 2003 05:19:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08AUW910867 for ipcdn-archive@odin.ietf.org; Wed, 8 Jan 2003 05:30:32 -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 h08AUCJ10839; Wed, 8 Jan 2003 05:30:12 -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 h08ATqJ10806 for ; Wed, 8 Jan 2003 05:29:52 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15736 for ; Wed, 8 Jan 2003 05:18:12 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h08ALQB10061 for ; Wed, 8 Jan 2003 05:21:26 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Jan 2003 11:21:25 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155989DB5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eduardo Cardona , "Wijnen, Bert (Bert)" , Wilson.Sawyer@arrisi.com Cc: richard_woundy@cable.comcast.com, "Ipcdn (E-mail)" Subject: RE: [ipcdn] RE: (ipcdn) review of subscriber management mib? Date: Wed, 8 Jan 2003 11:21:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Inline > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: woensdag 8 januari 2003 2:13 > To: Wijnen, Bert (Bert); Wilson.Sawyer@arrisi.com > Cc: richard_woundy@cable.comcast.com; Ipcdn (E-mail) > Subject: RE: [ipcdn] RE: (ipcdn) review of subscriber management mib? > > Wilson, As Bert pointed > the 04 will show up only if the ScrAddr (or InetAddress Type ) field > were part of a multi-indexed table, > It that were the case still not needed in the SYNTAX clause a size 5, > the Index encoding will introduce the length of the octet string, the > object size itself is still 4 for mib purposes. > > See RFC3291 section 4.1 > Right. > Bert, > My next question is (in general for all DOCSIS mibs drafts and DOCSIS > InetAddress types) : > > Among the mib documents, there are multiple Compliance statements to > specify that inetAddress is required only to specify ipv4 type "An > implementation is only required to support IPv4 addresses." > Which is good if that is the COMPLIANCE you currently want. > Q: If indeed this is done for all drafts, Would still IETF prefer to > define InetAddress TEXTUAL-CONVENTION for all this objects instead of > InetAddressIPv4 ? And avoid all those COMPLIANCE statements that are > replicating in a verbose way the InetAddressIPv4 SYNTAX . (ipv6, dns > types are not required in all DOCSIS modules ) > The idea of the approach you currently have is that the OBJECT definitions in the MIB Module itself are all ready for IPv6 (and other protocols as well). By the time you (or whoever) decides they want to use this with IPv6 (or whatever other protocol), they can use the MIB Module unchanged. All that is needed is a possible extra MODULE-COMPLIANCE (which could be in a separate document) to show that from then on (or better, in order to claim compliance with the new compliance statement) one must also support IPv6. > In such way a NMS will have the DISPLAY-HINT 1d.1d.1d.1d ready that is > the current pain. I would think that any decent NMS these days should be able to handle the techniques as presented in RFC3291, no? So why would it be so difficult for this specific MIB module. > I can still illegally have a friend IPv4 representation by adding in > the Browser MIB a DISPLAY-HINT to InetAddress TEXTUAL-CONVENTION in > RFC3291, but is not the desired solution. > People can always do illegal things. We are not law (or protocol or stds) enforcement body... so what can I say. Cablelabs should not certify implementations that do illegal things (they have more power than IETF have in this regard). Hope this helps. Bert > Thanks > > Eduardo _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Jan 8 07:45:01 2003 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 HAA18266 for ; Wed, 8 Jan 2003 07:45:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08CuDp19310 for ipcdn-archive@odin.ietf.org; Wed, 8 Jan 2003 07:56:13 -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 h08CuCJ19302; Wed, 8 Jan 2003 07:56:12 -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 h08CtQJ19240 for ; Wed, 8 Jan 2003 07:55:26 -0500 Received: from titan.arrisi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18211; Wed, 8 Jan 2003 07:43:42 -0500 (EST) From: Wilson.Sawyer@arrisi.com Subject: RE: [ipcdn] RE: (ipcdn) review of subscriber management mib? To: "Wijnen, Bert (Bert)" Cc: Eduardo Cardona , "Ipcdn (E-mail)" , ipcdn-admin@ietf.org, richard_woundy@cable.comcast.com X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Wed, 8 Jan 2003 07:45:05 -0500 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.9a |January 7, 2002) at 01/08/2003 07:46:37 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , My mistake. I had hallucinated a leading length octet for some (now incomprehensible) reason. - Wilson "Wijnen, Bert (Bert)" To: Eduardo Cardona , "Wijnen, , Wilson.Sawyer@arrisi.com om> cc: richard_woundy@cable.comcast.com, "Ipcdn (E-mail)" Sent by: ipcdn-admin@ietf. Subject: RE: [ipcdn] RE: (ipcdn) review of subscriber management org mib? 01/08/03 05:21 AM Inline > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: woensdag 8 januari 2003 2:13 > To: Wijnen, Bert (Bert); Wilson.Sawyer@arrisi.com > Cc: richard_woundy@cable.comcast.com; Ipcdn (E-mail) > Subject: RE: [ipcdn] RE: (ipcdn) review of subscriber management mib? > > Wilson, As Bert pointed > the 04 will show up only if the ScrAddr (or InetAddress Type ) field > were part of a multi-indexed table, > It that were the case still not needed in the SYNTAX clause a size 5, > the Index encoding will introduce the length of the octet string, the > object size itself is still 4 for mib purposes. > > See RFC3291 section 4.1 > Right. (remainder snipped) _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Jan 8 08:55:17 2003 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 IAA19836 for ; Wed, 8 Jan 2003 08:55:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08E6V722976 for ipcdn-archive@odin.ietf.org; Wed, 8 Jan 2003 09:06:31 -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 h08E6GJ22966; Wed, 8 Jan 2003 09:06:16 -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 h08E1xJ22764 for ; Wed, 8 Jan 2003 09:01:59 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19656; Wed, 8 Jan 2003 08:50:00 -0500 (EST) Message-Id: <200301081350.IAA19656@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 08 Jan 2003 08:49:59 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-docs-rfmibv2-05.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Radio Frequency (RF) Interface Management Information Base for DOCSIS 2.0 compliant RF interfaces Author(s) : D. Raftus Filename : draft-ietf-ipcdn-docs-rfmibv2-05.txt Pages : 76 Date : 2003-1-7 This memo is a draft revision of the standards track RFC-2670. Please see 'Section 9 Changes from RFC2670' for a description of modifications. This document or its successor will obsolete RFC-2670 when accepted. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS compliant Radio Frequency (RF) interfaces. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2 [5][6][7]. The set of objects are consistent with the SNMP framework and existing SNMP standards. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-docs-rfmibv2-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-7161023.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-docs-rfmibv2-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-7161023.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Jan 8 14:03:17 2003 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 OAA02312 for ; Wed, 8 Jan 2003 14:03:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08JEbJ14495 for ipcdn-archive@odin.ietf.org; Wed, 8 Jan 2003 14:14:37 -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 h08JEGJ14487; Wed, 8 Jan 2003 14:14:16 -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 h08JD1J14444 for ; Wed, 8 Jan 2003 14:13:01 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02231 for ; Wed, 8 Jan 2003 14:01:10 -0500 (EST) Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h08J4naS004830 for ; Wed, 8 Jan 2003 12:04:49 -0700 (MST) Received: [from ca25exm01.GI.COM (ca25exm01.gi.com [168.84.84.121]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id MAA16228 for ; Wed, 8 Jan 2003 12:04:26 -0700 (MST)] Received: by ca25exm01.gi.com with Internet Mail Service (5.5.2656.59) id ; Wed, 8 Jan 2003 11:04:25 -0800 Message-ID: From: Marez Kevin-MGI1375 To: "'ipcdn@ietf.org'" Date: Wed, 8 Jan 2003 11:04:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , To all: 1) InterfaceSet textual convention - The 'all external' description refers to "external physical instantiation". With the introduction of eDOCSIS, the description needs to be clarified. This setting should also include the internal logical interface between the CM and a SAFE (eMTA, ePS, eSTB). - Reference is made to filtering of stack and application traffic. Currently in DOCSIS, stack and CM application traffic are not subject to filtering and it should probably remain this way. Previously, it was unclear if traffic from applications such as eMTA should be subject to filtering. However, eDOCSIS now makes this clear. - With the clarifications made by eDOCSIS, the benefits of updating the objects to use the InterfaceSet textual convention seems to be reduced. IP filters are heavily used today. Does this enhancement provide sufficient benefit to warrant this change? If not, we should stick with what is currently defined in RFC 2669. 2) docsDevNmAccessTable Description. The description contains the following: "If the SNMP-COMMUNITY-MIB table has no entries, then this table has its normal access control (described above)meaning for v1 and v2c access. " The above sentence is contradictory to the current DOCSIS OSSI spec. If the device is in Coexistence mode (the only time that the SNMP-COMMUNITY-MIB is accessible), then the nmAccessTable is not accessible. Everything after the second paragraph could be deleted. 3) Support for software download using HTTP. The motivation for adding the HTTP transport was to support S-MTA software download. DOCSIS requires that software downloads be TFTP. Do we want to consider stating that the HTTP method is optional, either in the description or with the MIBs compliance statement? 4) docsDevSwOperStatus description - "TFTP" should be "TFTP/HTTP". Two instances. Also, Section 3.2.1 will need to be updated to reflect these changes. 5) What is the relationship between docsDevSwServerTransportProtocol and docsDevSwFileNameURL? What if docsDevSwServerTransportProtocol is set to "tftp" and the portion of docsDevSwFileNameURL is set to "http"? 6) What is the relationship between docsDevSwServerAddress and the portion of docsDevSwFilenameURL? 7) What is the syntax for the portion of the docsDevSwFilenameURL? It should be limited to an IP address since DOCSIS doesn't require the ability to resolve domain names. 8) Is there a need to update objects that refer to ports with the InetPortNumber textual convention defined in RFC3291? 9) docsDevCpeV6Table - Support for IP spoofing filters which rely on docsDevCpeTable was made optional in DOCSIS due to issues that couldn't be resolved at the time. Given that, does it make sense to define docsDevCpeV6Table at this time? 10) docsDevVacmAccessExtTable - Is this table really needed when using SNMPv3? The limited security provided in SNMPv1/2 necessitated having this functionality in the nmAccessTable. Given SNMPv3 security, it doesn't seem like this functionality is necessary anymore. Comments? Kevin Marez Motorola _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Jan 8 16:16:24 2003 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 QAA07621 for ; Wed, 8 Jan 2003 16:16:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08LRjP22880 for ipcdn-archive@odin.ietf.org; Wed, 8 Jan 2003 16:27:45 -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 h08LRGJ22857; Wed, 8 Jan 2003 16:27:16 -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 h08LQEJ22823 for ; Wed, 8 Jan 2003 16:26:14 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07581 for ; Wed, 8 Jan 2003 16:14:18 -0500 (EST) Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h08LHQvZ011456; Wed, 8 Jan 2003 14:17:32 -0700 (MST) Received: from 147.191.89.201 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Wed, 08 Jan 2003 14:17:25 -0600 Received: by entexchimc02.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 8 Jan 2003 14:17:19 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD072@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Marez Kevin-MGI1375'" cc: "IPCDN WG (E-mail)" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Date: Wed, 8 Jan 2003 14:17:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12024AEF1009723-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kevin, You have offered a number of very good comments for the Cable Device v2 MIB in your email below. Please give me a few days to process and react to them. I will try to capture the changes in my own January 20th draft submission. In the meantime, what are other folks think about the following aspects of the current Cable Device MIB draft? - the introduction of the InterfaceSet syntax and the InterfaceSet objects: docsDevFilterLLCInterfaceSet, docsDevFilterIpInterfaceSet and docsDevVacmAccessInterfaceSet, - the docsDevCpeTable (which is optional to implement for DOCSIS) and the introduction of the docsDevCpeV6Table, and - the introduction of docsDevVacmAccessExtTable, and the corresponding deprecation of docsDevNmAccessTable. -- Rich -----Original Message----- From: Marez Kevin-MGI1375 [mailto:Kevin.Marez@motorola.com] Sent: Wednesday, January 08, 2003 2:04 PM To: 'ipcdn@ietf.org' Subject: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... To all: 1) InterfaceSet textual convention - The 'all external' description refers to "external physical instantiation". With the introduction of eDOCSIS, the description needs to be clarified. This setting should also include the internal logical interface between the CM and a SAFE (eMTA, ePS, eSTB). - Reference is made to filtering of stack and application traffic. Currently in DOCSIS, stack and CM application traffic are not subject to filtering and it should probably remain this way. Previously, it was unclear if traffic from applications such as eMTA should be subject to filtering. However, eDOCSIS now makes this clear. - With the clarifications made by eDOCSIS, the benefits of updating the objects to use the InterfaceSet textual convention seems to be reduced. IP filters are heavily used today. Does this enhancement provide sufficient benefit to warrant this change? If not, we should stick with what is currently defined in RFC 2669. 2) docsDevNmAccessTable Description. The description contains the following: "If the SNMP-COMMUNITY-MIB table has no entries, then this table has its normal access control (described above)meaning for v1 and v2c access. " The above sentence is contradictory to the current DOCSIS OSSI spec. If the device is in Coexistence mode (the only time that the SNMP-COMMUNITY-MIB is accessible), then the nmAccessTable is not accessible. Everything after the second paragraph could be deleted. 3) Support for software download using HTTP. The motivation for adding the HTTP transport was to support S-MTA software download. DOCSIS requires that software downloads be TFTP. Do we want to consider stating that the HTTP method is optional, either in the description or with the MIBs compliance statement? 4) docsDevSwOperStatus description - "TFTP" should be "TFTP/HTTP". Two instances. Also, Section 3.2.1 will need to be updated to reflect these changes. 5) What is the relationship between docsDevSwServerTransportProtocol and docsDevSwFileNameURL? What if docsDevSwServerTransportProtocol is set to "tftp" and the portion of docsDevSwFileNameURL is set to "http"? 6) What is the relationship between docsDevSwServerAddress and the portion of docsDevSwFilenameURL? 7) What is the syntax for the portion of the docsDevSwFilenameURL? It should be limited to an IP address since DOCSIS doesn't require the ability to resolve domain names. 8) Is there a need to update objects that refer to ports with the InetPortNumber textual convention defined in RFC3291? 9) docsDevCpeV6Table - Support for IP spoofing filters which rely on docsDevCpeTable was made optional in DOCSIS due to issues that couldn't be resolved at the time. Given that, does it make sense to define docsDevCpeV6Table at this time? 10) docsDevVacmAccessExtTable - Is this table really needed when using SNMPv3? The limited security provided in SNMPv1/2 necessitated having this functionality in the nmAccessTable. Given SNMPv3 security, it doesn't seem like this functionality is necessary anymore. Comments? Kevin Marez Motorola _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Jan 8 21:22:12 2003 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 VAA17244 for ; Wed, 8 Jan 2003 21:22:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h092XfB08598 for ipcdn-archive@odin.ietf.org; Wed, 8 Jan 2003 21:33:41 -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 h092XPJ08580; Wed, 8 Jan 2003 21:33:25 -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 h092WDJ08528 for ; Wed, 8 Jan 2003 21:32:13 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17198 for ; Wed, 8 Jan 2003 21:20:12 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id h092NPmb025204; Wed, 8 Jan 2003 19:23:25 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ipcdn] RE: (ipcdn) review of subscriber management mib? X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 8 Jan 2003 19:23:25 -0700 Message-ID: Thread-Topic: [ipcdn] RE: (ipcdn) review of subscriber management mib? Thread-Index: AcK2/7euF0MTyiogRQOZxVsqVg1AWwAHnkug From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , Cc: , "Ipcdn (E-mail)" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h092WDJ08529 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Thanks Bert, For the comments, Maybe the topic is out of the ipcdn group so move back to ipcdn topics. Just see more comments inline '' if interested Thanks Eduardo > Q: If indeed this is done for all drafts, Would still IETF prefer to > define InetAddress TEXTUAL-CONVENTION for all this objects instead of > InetAddressIPv4 ? And avoid all those COMPLIANCE statements that are > replicating in a verbose way the InetAddressIPv4 SYNTAX . (ipv6, dns > types are not required in all DOCSIS modules ) > The idea of the approach you currently have is that the OBJECT definitions in the MIB Module itself are all ready for IPv6 (and other protocols as well). By the time you (or whoever) decides they want to use this with IPv6 (or whatever other protocol), they can use the MIB Module unchanged. All that is needed is a possible extra MODULE-COMPLIANCE (which could be in a separate document) to show that from then on (or better, in order to claim compliance with the new compliance statement) one must also support IPv6. I may abandon my desires on that, due to the fact that I guess RFC2578 Section 9. "Refined Syntax" for OCTET STRING note(3) does not allow an upgrade of TC octet string to augment the size choise (just to reduce it) ? The bottom line is that the TC is OCTET string, so moving from (SIZE(4)) to InetAddress (SIZE(0..255) may not valid. Am I correct? I will say I had no intention to be out of the IPv6 upgrading path. Just getting the minimum COMPLIANCE statements << objectable ) :-) >> But let me explain what weres my thoughs.... Or jump over the next I see this as an analogy: RFC2011 is being proposed to be deprecated by draft-ietf-ipv6-rfc2011-update-01.txt Until someone decided to support Ipv6, there is no need to have support for the 'RFC2011-update'. All instrumentation around mib-2 RFC2011 is no longer valid for IPv6 including (i.e) ipNetToMediaTable, now inetNetToMediaTable ( Time to change the NMS) in the mean time everyone will continue using the traditional RFC2011 ipNetToMediaTable. In DOCSIS, mib drafts there are provisions for IPv6 like InetAddressType and InetAddress* TC rather than IpAddress type. I do no see a hurry of fully implementing 'InetAddress' TC and being IPv6 'ready' when IPv4 is overloaded with a big set of COMPLIANT statements which add few value in the chain (IPv4 is what we care now). (**) The upgrade to Support IPv6 or any other protocol would be ( if IETF allows that) moving from InetAddressIPv4 to InetAddress which technically is no more than moving from SIZE(4) to size(0..255) OCTET STRING -I'd prefer SIZE(4|8|16|20) under a new TC with no dns(16) type - and no compliance statements at all. Or deprecate the mibs just to change the TC as RFC2011 moving from IpAddress to InetAddress ? Because of RFC2578 requirements? Closing the topic : - InetAddress TC is so general, MIB is ready for further IP protocols but the backward IPv4 SMIv2 compatibility problem could be costly at expenses of not still implementing Ipv6 or any other protocol. ( see comment about NMS) > In such way a NMS will have the DISPLAY-HINT 1d.1d.1d.1d ready that is > the current pain. I would think that any decent NMS these days should be able to handle the techniques as presented in RFC3291, no? So why would it be so difficult for this specific MIB module. I guess It is not a problem with this particular mib, it is for all mibs involved with IP objects migrating to Ipv6. The RFC3291 procedure to assign the DISPLAY-HIT based on the object type is not backward compatible with current(before inetAddress)/legacy NMS entities and SMIv2 requirements. Now you need an extra object (inetAddressType) to discriminate the DISPLAY-HINT, so no arbitrary get/getnext request to an Address object will be able to hint the object syntax. IPv4 case: So far 4 browsers/applications I know, handle 'inetAddress' as just plain OCTET STRING SIZE(0..255) -since no DISPLAY-HINT-, then, a user gets a Hex format for ipv4 values. If an "1d." DISPLAY-HINT is set, some of them will present (SNMP GET operations) in friendly ip format d.d.d.d few less will still recognize the hint format and encode properly when doing SNMP SET operations. Those cases are worst in graphical interfaces applications. > I can still illegally have a friend IPv4 representation by adding in > the Browser MIB a DISPLAY-HINT to InetAddress TEXTUAL-CONVENTION in > RFC3291, but is not the desired solution. > People can always do illegal things. We are not law (or protocol or stds) enforcement body... so what can I say. Cablelabs should not certify implementations that do illegal things (they have more power than IETF have in this regard). In this case there is not certainly an ilegal thing that comes with a wrong implementations, It just a work around in the browser side (not the Agent implementation) because is knew that ipv4 is the expected value. What I am saying is I would prefer not having to modified the InetAddress Tcin RFC3291, or advice someone to do that as I've been forced to do in some cases, including CableLabs for testing purposes. We are in an intermedia position: Writing IPv4 implementations requirements with Ipv6 requirements and not even satisfying the IPv4 needs as they were under SMI/SMIv2 IpAddress scheme ( and I will argue RFC3291 is broken, not SMIv2 backward compatible in the management entity side). Hope this helps. Bert > Thanks > > Eduardo _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 9 06:22:56 2003 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 GAA07035 for ; Thu, 9 Jan 2003 06:22:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09BYZt15666 for ipcdn-archive@odin.ietf.org; Thu, 9 Jan 2003 06:34:35 -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 h09BYAJ15637; Thu, 9 Jan 2003 06:34:10 -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 h09BXfJ15617 for ; Thu, 9 Jan 2003 06:33:41 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07007 for ; Thu, 9 Jan 2003 06:21:31 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h09BOfC29593 for ; Thu, 9 Jan 2003 06:24:41 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Jan 2003 12:24:40 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15598A0F6@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eduardo Cardona , "Wijnen, Bert (Bert)" , Wilson.Sawyer@arrisi.com Cc: richard_woundy@cable.comcast.com, "Ipcdn (E-mail)" Subject: RE: [ipcdn] RE: (ipcdn) review of subscriber management mib? Date: Thu, 9 Jan 2003 12:24:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , OK, I think this is a discussion not specific to your IPCDN MIB Modules, but a generic discussion about the INET-ADDRESS-MIB and that is best done on the mibs@ops.ietf.org mailing list (you must subscribe in order to post). I believe that a lot of this discussion did take place in the past already... but it may not be bad to do another rerun if you so desire. You will find that many/most/all SNMP/SMI/MIB people will agree with me (approving the RFC3291 basically means we have IETF consensus on it). If not, then I am surprised that not anyone spoke up on the IETF Last Call for that document (that is what IETF Last Calls are for... if people just ignore such last calls and then object when they later get faced with what we believe to be IETF consensus ... well, then our process is broken.... or people/participants do not understand how the process works). Thanks, Bert > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: donderdag 9 januari 2003 3:23 > To: Wijnen, Bert (Bert); Wilson.Sawyer@arrisi.com > Cc: richard_woundy@cable.comcast.com; Ipcdn (E-mail) > Subject: RE: [ipcdn] RE: (ipcdn) review of subscriber management mib? > > > Thanks Bert, For the comments, > > Maybe the topic is out of the ipcdn group so move back to > ipcdn topics. > > Just see more comments inline '' if interested > > Thanks > > Eduardo > > > > Q: If indeed this is done for all drafts, Would still IETF > prefer to > > define InetAddress TEXTUAL-CONVENTION for all this objects > instead of > > InetAddressIPv4 ? And avoid all those COMPLIANCE statements > that are > > replicating in a verbose way the InetAddressIPv4 SYNTAX . > (ipv6, dns > > types are not required in all DOCSIS modules ) > > > The idea of the approach you currently have is that the OBJECT > definitions in the MIB Module itself are all ready for IPv6 (and other > protocols as well). By the time you (or whoever) decides they want to > use this with IPv6 (or whatever other protocol), they can use the MIB > Module unchanged. All that is needed is a possible extra > MODULE-COMPLIANCE (which could be in a separate document) to show that > from then on (or better, in order to claim compliance with the new > compliance > statement) one must also support IPv6. > > > > I may abandon my desires on that, due to the fact that I guess RFC2578 > Section 9. "Refined Syntax" for OCTET STRING note(3) does not > allow an > upgrade of TC octet string to augment the size choise (just to reduce > it) ? > The bottom line is that the TC is OCTET string, so moving > from (SIZE(4)) > to InetAddress (SIZE(0..255) may not valid. Am I correct? > > I will say I had no intention to be out of the IPv6 upgrading > path. Just > getting the minimum COMPLIANCE statements > << objectable ) :-) >> > > But let me explain what weres my thoughs.... Or jump over the next > > > I see this as an analogy: > RFC2011 is being proposed to be deprecated by > draft-ietf-ipv6-rfc2011-update-01.txt > Until someone decided to support Ipv6, there is no need to > have support > for the 'RFC2011-update'. > All instrumentation around mib-2 RFC2011 is no longer valid for IPv6 > including (i.e) ipNetToMediaTable, now inetNetToMediaTable ( Time to > change the NMS) in the mean time everyone will continue using the > traditional RFC2011 ipNetToMediaTable. > > In DOCSIS, mib drafts there are provisions for IPv6 like > InetAddressType > and InetAddress* TC rather than IpAddress type. > I do no see a hurry of fully implementing 'InetAddress' TC and being > IPv6 'ready' when IPv4 is overloaded with a big set of COMPLIANT > statements which add few value in the chain (IPv4 is what we > care now). > > (**) The upgrade to Support IPv6 or any other protocol would be ( if > IETF allows that) moving from InetAddressIPv4 to InetAddress which > technically is no more than moving from SIZE(4) to size(0..255) OCTET > STRING -I'd prefer SIZE(4|8|16|20) under a new TC with no > dns(16) type - > and no compliance statements at all. > Or deprecate the mibs just to change the TC as RFC2011 moving from > IpAddress to InetAddress ? Because of RFC2578 requirements? > > Closing the topic : > - InetAddress TC is so general, MIB is ready for further IP protocols > but the backward IPv4 SMIv2 compatibility problem could be costly at > expenses of not still implementing Ipv6 or any other protocol. > ( see comment about NMS) > > > > > > In such way a NMS will have the DISPLAY-HINT 1d.1d.1d.1d > ready that is > > > the current pain. > > I would think that any decent NMS these days should be able to > handle the techniques as presented in RFC3291, no? > So why would it be so difficult for this specific MIB module. > > > I guess It is not a problem with this particular mib, it is > for all mibs > involved with IP objects migrating to Ipv6. > > The RFC3291 procedure to assign the DISPLAY-HIT based on the > object type > is not backward compatible with current(before inetAddress)/legacy NMS > entities and SMIv2 requirements. Now you need an extra object > (inetAddressType) to discriminate the DISPLAY-HINT, so no arbitrary > get/getnext request to an Address object will be able to hint > the object > syntax. > > IPv4 case: > So far 4 browsers/applications I know, handle 'inetAddress' as just > plain OCTET STRING SIZE(0..255) -since no DISPLAY-HINT-, then, a user > gets a Hex format for ipv4 values. > > If an "1d." DISPLAY-HINT is set, some of them will present (SNMP GET > operations) in friendly ip format d.d.d.d > few less will still recognize the hint format and encode properly when > doing SNMP SET operations. > Those cases are worst in graphical interfaces applications. > > > > > > I can still illegally have a friend IPv4 representation by > adding in > > the Browser MIB a DISPLAY-HINT to InetAddress TEXTUAL-CONVENTION in > > RFC3291, but is not the desired solution. > > > People can always do illegal things. We are not law (or protocol or > stds) enforcement body... so what can I say. > Cablelabs should not certify implementations that do illegal things > (they have more power than IETF have in this regard). > > > > In this case there is not certainly an ilegal thing that comes with a > wrong implementations, It just a work around in the browser side (not > the Agent implementation) because is knew that ipv4 is the expected > value. What I am saying is I would prefer not having to modified the > InetAddress Tcin RFC3291, or advice someone to do that as I've been > forced to do in some cases, including CableLabs for testing purposes. > > We are in an intermedia position: Writing IPv4 implementations > requirements with Ipv6 requirements and not even satisfying the IPv4 > needs as they were under SMI/SMIv2 IpAddress scheme ( and I will argue > RFC3291 is broken, not SMIv2 backward compatible in the management > entity side). > > > > > > Hope this helps. > Bert > > Thanks > > > > Eduardo > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 9 10:57:59 2003 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 KAA15621 for ; Thu, 9 Jan 2003 10:57:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09G9jX02014 for ipcdn-archive@odin.ietf.org; Thu, 9 Jan 2003 11:09:45 -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 h09G9FJ01986; Thu, 9 Jan 2003 11:09:15 -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 h09G8ZJ01940 for ; Thu, 9 Jan 2003 11:08:35 -0500 Received: from titan.arrisi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15591 for ; Thu, 9 Jan 2003 10:56:17 -0500 (EST) From: Wilson.Sawyer@arrisi.com To: ipcdn@ietf.org Cc: bert.wijnen@lucent.com, vedvyas.shanbhogue@intel.com X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Thu, 9 Jan 2003 10:57:25 -0500 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.9a |January 7, 2002) at 01/09/2003 10:59:14 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [ipcdn] docsis subscriber management: proposed wording for filter action Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Vedvyas Shanbhogue wrote: 1.There should be an object describing the default action to be taken when none of the filters in a filter group match the packet. The default action could be configurable as 'accept' or 'drop' Bert Wijnen had also expressed concern about the original description clause of docsSubMgtPktFilterAction, which was: "The action to take upon this filter matching. Accept means to accept the packet for further processing. Drop means to drop the packet." to wit: what does further processing mean? In particular, what does it mean in terms of continuing with or exiting this table? I have been reluctant to clarify "accepted for further processing" beyond what is necessary for describing the mechanics of this table. Terms like "forwarding" violate the separation of layers needed for a clean definition, and in practice have always provoked confusion. The following is proposed new wording for docsSubMgtPktFilterTable, as well as the -07 text from docsSubMgtPktFilterAction. Are the mechanics of pktFilterAction now sufficiently clear? docsSubMgtPktFilterTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsSubMgtPktFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of filter or classifier criteria. Classifiers are assigned by group to the individual CMs. That assignment is made via the configuration objects sent upstream from the CM to the CMTS during registration. Each filter in the group is applied in index order to each packet. If the filter matches, then the indicated action is taken. If no filter matches then the packet is accepted for further processing." ::= { docsSubMgtObjects 6 } ... docsSubMgtPktFilterAction OBJECT-TYPE SYNTAX INTEGER { accept(1), drop(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The action to take upon this filter matching. Accept means to end filter matching and to accept the packet for further processing. Drop means to drop the packet." DEFVAL { accept } ::= { docsSubMgtPktFilterEntry 11 } _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 9 11:54:29 2003 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 LAA17532 for ; Thu, 9 Jan 2003 11:54:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09H6EM06319 for ipcdn-archive@odin.ietf.org; Thu, 9 Jan 2003 12:06:14 -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 h09H62J06279; Thu, 9 Jan 2003 12:06:02 -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 h09H5JJ06107 for ; Thu, 9 Jan 2003 12:05:19 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17481 for ; Thu, 9 Jan 2003 11:53:01 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id h09Gu1mh015448; Thu, 9 Jan 2003 09:56:14 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ipcdn] docsis subscriber management: proposed wording for filter action X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 9 Jan 2003 09:56:04 -0700 Message-ID: Thread-Topic: [ipcdn] docsis subscriber management: proposed wording for filter action Thread-Index: AcK3+FQwQ9Upud87QcKiJqPVo5i9hAABlD1A From: "Eduardo Cardona" To: , Cc: , X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h09H5JJ06108 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Wilson, to support your concerns in forwarding, "further process" , In docsSubMgtPktFilterTable DESCRIPTION "If no filter matches then the packet is accepted for further processing" What about "If no filter matches then the packet the packet is treated as filter matched with action accept" Eduardo -----Original Message----- From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] Sent: Thursday, January 09, 2003 8:57 AM To: ipcdn@ietf.org Cc: bert.wijnen@lucent.com; vedvyas.shanbhogue@intel.com Subject: [ipcdn] docsis subscriber management: proposed wording for filter action Vedvyas Shanbhogue wrote: 1.There should be an object describing the default action to be taken when none of the filters in a filter group match the packet. The default action could be configurable as 'accept' or 'drop' Bert Wijnen had also expressed concern about the original description clause of docsSubMgtPktFilterAction, which was: "The action to take upon this filter matching. Accept means to accept the packet for further processing. Drop means to drop the packet." to wit: what does further processing mean? In particular, what does it mean in terms of continuing with or exiting this table? I have been reluctant to clarify "accepted for further processing" beyond what is necessary for describing the mechanics of this table. Terms like "forwarding" violate the separation of layers needed for a clean definition, and in practice have always provoked confusion. The following is proposed new wording for docsSubMgtPktFilterTable, as well as the -07 text from docsSubMgtPktFilterAction. Are the mechanics of pktFilterAction now sufficiently clear? docsSubMgtPktFilterTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsSubMgtPktFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of filter or classifier criteria. Classifiers are assigned by group to the individual CMs. That assignment is made via the configuration objects sent upstream from the CM to the CMTS during registration. Each filter in the group is applied in index order to each packet. If the filter matches, then the indicated action is taken. If no filter matches then the packet is accepted for further processing." ::= { docsSubMgtObjects 6 } ... docsSubMgtPktFilterAction OBJECT-TYPE SYNTAX INTEGER { accept(1), drop(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The action to take upon this filter matching. Accept means to end filter matching and to accept the packet for further processing. Drop means to drop the packet." DEFVAL { accept } ::= { docsSubMgtPktFilterEntry 11 } _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 9 15:20:29 2003 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 PAA25214 for ; Thu, 9 Jan 2003 15:20:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09KWK822883 for ipcdn-archive@odin.ietf.org; Thu, 9 Jan 2003 15:32:20 -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 h09KWBJ22871; Thu, 9 Jan 2003 15:32:11 -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 h09KVDJ22843 for ; Thu, 9 Jan 2003 15:31:13 -0500 Received: from titan.arrisi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25196 for ; Thu, 9 Jan 2003 15:18:51 -0500 (EST) From: Wilson.Sawyer@arrisi.com To: ipcdn@ietf.org Cc: bert.wijnen@lucent.com X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Thu, 9 Jan 2003 15:21:45 -0500 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.9a |January 7, 2002) at 01/09/2003 03:21:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [ipcdn] docsis subscriber management: adding timestamp object to docsSubMgtCpeControlTable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Bert has expressed reservations about docsSubMgtCpeControlReset OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object always returns false on read. If this object is set to true, the rows with 'learned' addresses in docsSubMgtCpeIpTable for this CM are deleted from that table." ::= { docsSubMgtCpeControlEntry 4 } since there is no real way to tell whether the operation took place or not. I'm considering adding (at his suggestion) a timestamp object: docsSubMgtCpeControlLastReset OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when docsSubMgtCpeControlReset was last set true. Zero if never reset." ::= { docsSubMgtCpeControlEntry 5 } Does this make sense to everyone? There was also a comment about the apparent uselessness of a TruthValue, since only one value is meaningful. In defense of the TruthValue, I'd note the SNMP test procedure called 'setwalk': it performs a get-next walk of the mib, and for any R/W objects, attempts to 'set' them to their existing value. The assumption** is that such a walk is harmless - setting something to its existing value is assumed to have no side-effects. So a setwalk of this object will change nothing, which is the desired behavior. If the object were changed to have a single value, then the setwalk would have side-effects. ** this assumption is flawed, but there's no need to add yet another exception to its validity. - Wilson _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 9 16:35:24 2003 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 QAA27213 for ; Thu, 9 Jan 2003 16:35:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09LlH828235 for ipcdn-archive@odin.ietf.org; Thu, 9 Jan 2003 16:47:17 -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 h09LlAJ28227; Thu, 9 Jan 2003 16:47:10 -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 h09LkiJ28211 for ; Thu, 9 Jan 2003 16:46:44 -0500 Received: from titan.arrisi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27154 for ; Thu, 9 Jan 2003 16:34:20 -0500 (EST) From: Wilson.Sawyer@arrisi.com To: ipcdn@ietf.org Cc: bert.wijnen@lucent.com X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Thu, 9 Jan 2003 16:37:14 -0500 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.9a |January 7, 2002) at 01/09/2003 04:37:17 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [ipcdn] docsis subscriber management: description of CpeControl defaults Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Bert Wijnen writes: [re: docsSubMgtCpeMaxIpDefault, docsSubMgtCpeActiveDefault, docsSubMgtCpeLearnableDefault] >> - the following 3 objects that define defaults. Can you explain how >> that works and when they come into play. I see that hey do when the >> registration fails. So is it that when a cable modem registers, then >> this MIB-table (at a device in the provider premises?) gets >> populated with whatever the user registers? And if he does not >> register you still add entries to this MIB-table and the defaults >> get picked up in that case? > >I don;t see any additional explanation. >I guess all is clear to the WG and people who need to implement? additional text (in -07) was added to the description of docsSubMgtCpeControlEntry: "A row in the docsSubMgtCpeControlTable. All values are set at successful modem registration, either from the system default, or from objects included in the DOCSIS registration request sent upstream to the CMTS from the CM. The contents of this entry are meaningless unless the corresponding docsIfCmtsCmStatusValue is registrationComplete(6). The persistence of this row is determined solely by the lifespan of the corresponding docsIfCmtsCmStatusEntry (normally StorageType=volatile)." to repeat Bert's question, is this clear to the WG and people who need to implement? - Wilson _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Jan 10 07:37:21 2003 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 HAA26372 for ; Fri, 10 Jan 2003 07:37:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ACnVl27993 for ipcdn-archive@odin.ietf.org; Fri, 10 Jan 2003 07:49:31 -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 h0ACnTJ27988; Fri, 10 Jan 2003 07:49:29 -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 h0ACmYJ27959 for ; Fri, 10 Jan 2003 07:48:34 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26365 for ; Fri, 10 Jan 2003 07:35:53 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0ACd7e13083 for ; Fri, 10 Jan 2003 07:39:08 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Jan 2003 13:39:07 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15598A3D9@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Wilson.Sawyer@arrisi.com, ipcdn@ietf.org Cc: bert.wijnen@lucent.com, vedvyas.shanbhogue@intel.com Date: Fri, 10 Jan 2003 13:39:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [ipcdn] RE: docsis subscriber management: proposed wording for filter act ion Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , I am OK with that Thanks, Bert > -----Original Message----- > From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > Sent: donderdag 9 januari 2003 16:57 > To: ipcdn@ietf.org > Cc: bert.wijnen@lucent.com; vedvyas.shanbhogue@intel.com > Subject: docsis subscriber management: proposed wording for filter > action > > > Vedvyas Shanbhogue wrote: > > 1.There should be an object describing the default > action to be taken when none of the filters in a > filter group match the packet. The default action > could be configurable as 'accept' or 'drop' > > Bert Wijnen had also expressed concern about the original description > clause of docsSubMgtPktFilterAction, which was: > > "The action to take upon this filter matching. Accept means > to accept the > packet for further processing. Drop means to drop the packet." > > to wit: what does further processing mean? In particular, > what does it mean > in terms of continuing with or exiting this table? > > I have been reluctant to clarify "accepted for further > processing" beyond > what is necessary for describing the mechanics of this table. > Terms like > "forwarding" violate the separation of layers needed for a clean > definition, and in practice have always provoked confusion. > > The following is proposed new wording for > docsSubMgtPktFilterTable, as well > as the -07 text from docsSubMgtPktFilterAction. Are the mechanics of > pktFilterAction now sufficiently clear? > > docsSubMgtPktFilterTable OBJECT-TYPE > SYNTAX SEQUENCE OF DocsSubMgtPktFilterEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of filter or classifier criteria. Classifiers are > assigned by group to the individual CMs. That assignment is made > via the configuration objects sent upstream from the CM to the > CMTS during registration. Each filter in the group is applied > in index order to each packet. If the filter matches, then the > indicated action is taken. If no filter matches then the packet > is accepted for further processing." > ::= { docsSubMgtObjects 6 } > > ... > > docsSubMgtPktFilterAction OBJECT-TYPE > SYNTAX INTEGER > { > accept(1), > drop(2) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The action to take upon this filter matching. Accept means > to end filter matching and to accept the packet for further > processing. Drop means to drop the packet." > DEFVAL { accept } > ::= { docsSubMgtPktFilterEntry 11 } > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Jan 10 07:45:51 2003 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 HAA26535 for ; Fri, 10 Jan 2003 07:45:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ACw1o28358 for ipcdn-archive@odin.ietf.org; Fri, 10 Jan 2003 07:58:01 -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 h0ACw1J28345; Fri, 10 Jan 2003 07:58:01 -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 h09KlxJ23989 for ; Thu, 9 Jan 2003 15:47:59 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25570 for ; Thu, 9 Jan 2003 15:35:37 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h09Kcr0E008221; Thu, 9 Jan 2003 12:38:53 -0800 (PST) Received: from cisco.com (bobrandt-w2k.cisco.com [171.71.50.233]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABX63999; Thu, 9 Jan 2003 12:38:52 -0800 (PST) Message-ID: <3E1DDDDC.1E7F930E@cisco.com> Date: Thu, 09 Jan 2003 12:38:52 -0800 From: Azlina Ahmad Reply-To: azlina@cisco.com Organization: CIsco Systems X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Wilson.Sawyer@arrisi.com CC: ipcdn@ietf.org, bert.wijnen@lucent.com Subject: Re: [ipcdn] docsis subscriber management: adding timestamp object todocsSubMgtCpeControlTable References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Make senses! ... or we could also add a new object (timestamp) in docsSubMgtCpeIpTable - WHEN it gets discovered and added to this table. Thanks, Azlina Wilson.Sawyer@arrisi.com wrote: > > Bert has expressed reservations about > > docsSubMgtCpeControlReset OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This object always returns false on read. If this object is > set to true, the rows with 'learned' addresses in > docsSubMgtCpeIpTable for this CM are deleted from that table." > ::= { docsSubMgtCpeControlEntry 4 } > > since there is no real way to tell whether the operation took place or not. > I'm considering adding (at his suggestion) a timestamp object: > > docsSubMgtCpeControlLastReset OBJECT-TYPE > SYNTAX TimeStamp > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of sysUpTime when docsSubMgtCpeControlReset was last > set true. Zero if never reset." > ::= { docsSubMgtCpeControlEntry 5 } > > Does this make sense to everyone? > > There was also a comment about the apparent uselessness of a TruthValue, > since only one value is meaningful. In defense of the TruthValue, I'd note > the SNMP test procedure called 'setwalk': it performs a get-next walk of > the mib, and for any R/W objects, attempts to 'set' them to their existing > value. The assumption** is that such a walk is harmless - setting something > to its existing value is assumed to have no side-effects. So a setwalk of > this object will change nothing, which is the desired behavior. If the > object were changed to have a single value, then the setwalk would have > side-effects. > > ** this assumption is flawed, but there's no need to add yet another > exception to its validity. > > - Wilson > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Jan 10 08:08:53 2003 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 IAA26996 for ; Fri, 10 Jan 2003 08:08:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ADL4h29998 for ipcdn-archive@odin.ietf.org; Fri, 10 Jan 2003 08:21:04 -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 h0ADL2J29984; Fri, 10 Jan 2003 08:21:02 -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 h0ADKmJ29955 for ; Fri, 10 Jan 2003 08:20:48 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26977 for ; Fri, 10 Jan 2003 08:08:06 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0ADBME24339 for ; Fri, 10 Jan 2003 08:11:22 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Jan 2003 14:11:21 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15598A406@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Date: Fri, 10 Jan 2003 14:11:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [ipcdn] docsis subscriber mib - TruthValue for docsBpi2CmAuthReset Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , After I had posted possible safeguards for the ...Reset object, Randy Presuhn even had another (possibly better) suggestion, that is to use TestAndIncr TC from RFC2579. I also saw your response that you use TruthValue in a few other similar objects in IPCDN originated MIB Modules. So I posed the question (to my MIB doctors team) if the problem is serious enough to make you do things different now conmpared to what you have done in other MIB modules. No final answer yet, but below is some input that may be good to review. Thanks, Bert -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: vrijdag 10 januari 2003 0:33 To: Mreview (E-mail) Subject: RE: docsis subscriber mib HI, Randy's suggestion is an efficient way to achieve two results: 1) initiating and action, and 2) determining if the action was initiated when no response is received. It's a somewhat unusual application of the TestAndIncr, and they do have object definitions in the field, and this is a change of solutions. However, it is a superior solution to what they have previously done. Here is the OLD solution.... docsBpi2CmAuthReset OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to TRUE generates a Reauthorize event in the authorization FSM. Reading this object always returns FALSE." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.1.2.3.4." ::= { docsBpi2CmBaseEntry 7 } And here is the NEW solution... docsBpi2CmAuthReset OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to its current value results in incrementing the value and causes a Reauthorize event in the authorization FSM. Reading this object always returns its current value." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.1.2.3.4." ::= { docsBpi2CmBaseEntry 7 } Notes: I would probably define another TC that acted like the TestAndIncr TC, but whose value was the number of "administratively initiated actions", and to initiate and action, I would write the current value plus one (instead of the current value). At 12:17 AM 1/10/2003 +0100, Wijnen, Bert (Bert) wrote: >Possibly... the reason why I forwarded was, >cause they seem to want one common way of doing these >things and we/they already have a set of RFCs that >do this in the same way as they are proposing in this >new MIB module. > >So the question becomes: > - is it so seriously flawed that we want to force them > to change the way they are doing these resets > - if so, then we should make a note so that if they > respind the existing RFCs, that we then also force them > to deprecate and create a new object. > >Or does this not make sense what I am asking here? > >Thanks, >Bert > >> -----Original Message----- >> From: Presuhn, Randy [mailto:Randy_Presuhn@bmc.com] >> Sent: donderdag 9 januari 2003 23:51 >> To: Mreview (E-mail) >> Subject: RE: docsis subscriber mib >> >> >> Hi - >> >> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >> > Sent: Thursday, January 09, 2003 13:47 >> > To: Mreview (E-mail) >> > Subject: Re: docsis subscriber mib >> > >> > >> > This is what I get back (or what I see in terms of discussion >> > on their ipcdn mailing list). >> ... >> >> Elaborating on my earlier comment: >> >> If the purpose of adding an additional time stamp object is >> to support detection of the cases Dave Perkins outlined, >> wouldn't it be simpler to replace the TruthValue with a >> TestAndIncr? This would get rid of the odd read/write >> semantics, prevent the worst replay scenarios, and allow >> recovery in the "lost response" case. >> >> The semantics they're proposing for these objects really >> don't match up with TruthValue. >> >> Randy Presuhn BMC Software, Inc. 1-3141 Regards, /david t. perkins _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Jan 10 08:40:36 2003 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 HAA26537 for ; Fri, 10 Jan 2003 07:45:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ACw2128379 for ipcdn-archive@odin.ietf.org; Fri, 10 Jan 2003 07:58:02 -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 h0ACw2J28372; Fri, 10 Jan 2003 07:58:02 -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 h09LSkJ26501 for ; Thu, 9 Jan 2003 16:28:46 -0500 Received: from mail.correlant.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26504 for ; Thu, 9 Jan 2003 16:16:22 -0500 (EST) Received: from kfriedman (67.82.218.209.transedge.com [209.218.82.67]) by mail.correlant.com (Postfix) with SMTP id 0C879BC125; Thu, 9 Jan 2003 13:17:23 -0800 (PST) From: "Kirk Friedman" To: , Cc: Subject: RE: [ipcdn] docsis subscriber management: adding timestamp object to docsSubMgtCpeControlTable Date: Thu, 9 Jan 2003 13:19:37 -0800 Message-ID: <002501c2b824$d10822e0$4352dad1@correlant.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Wilson, I don't have any objection to this. But there are other MIBs in the DOCSIS set that don't use a timestamp for setting a TruthValue, one of which is an RFC. Should this one be unique? Examples: From draft-ietf-ipcdn-bpiplus-mib-05.txt docsBpi2CmAuthReset OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to TRUE generates a Reauthorize event in the authorization FSM. Reading this object always returns FALSE." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.1.2.3.4." ::= { docsBpi2CmBaseEntry 7 } Same kind of setting for docsBpi2CmtsTEKReset. Equivalent settings in BPI MIB RFC-3083 The Cable Device MIB (RFC 2669)also has docsDevResetNow though if set to TRUE the system should reset, so a timestamp isn't really needed. Thanks, Kirk Friedman Correlant Communications 15110 Avenue Of Science San Diego, CA., 92128 -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Wilson.Sawyer@arrisi.com Sent: Thursday, January 09, 2003 12:22 PM To: ipcdn@ietf.org Cc: bert.wijnen@lucent.com Subject: [ipcdn] docsis subscriber management: adding timestamp object to docsSubMgtCpeControlTable Bert has expressed reservations about docsSubMgtCpeControlReset OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object always returns false on read. If this object is set to true, the rows with 'learned' addresses in docsSubMgtCpeIpTable for this CM are deleted from that table." ::= { docsSubMgtCpeControlEntry 4 } since there is no real way to tell whether the operation took place or not. I'm considering adding (at his suggestion) a timestamp object: docsSubMgtCpeControlLastReset OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when docsSubMgtCpeControlReset was last set true. Zero if never reset." ::= { docsSubMgtCpeControlEntry 5 } Does this make sense to everyone? There was also a comment about the apparent uselessness of a TruthValue, since only one value is meaningful. In defense of the TruthValue, I'd note the SNMP test procedure called 'setwalk': it performs a get-next walk of the mib, and for any R/W objects, attempts to 'set' them to their existing value. The assumption** is that such a walk is harmless - setting something to its existing value is assumed to have no side-effects. So a setwalk of this object will change nothing, which is the desired behavior. If the object were changed to have a single value, then the setwalk would have side-effects. ** this assumption is flawed, but there's no need to add yet another exception to its validity. - Wilson _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Jan 10 10:25:14 2003 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 KAA00557 for ; Fri, 10 Jan 2003 10:25:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AFbSr07378 for ipcdn-archive@odin.ietf.org; Fri, 10 Jan 2003 10:37:28 -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 h0AFb8J06912; Fri, 10 Jan 2003 10:37:08 -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 h0AFa4J06727 for ; Fri, 10 Jan 2003 10:36:04 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00499 for ; Fri, 10 Jan 2003 10:23:18 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id h0AFQXmb020735; Fri, 10 Jan 2003 08:26:34 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ipcdn] docsis subscriber mib - TruthValue for docsBpi2CmAuthReset X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 10 Jan 2003 08:26:33 -0700 Message-ID: Thread-Topic: [ipcdn] docsis subscriber mib - TruthValue for docsBpi2CmAuthReset Thread-Index: AcK4qdtPKjgnMlTLSqOM5qKPH/z93wAEWKBw From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0AFa4J06728 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit All, testAndIncrements /spinlock kind of solution is targeted for s'locking' multiple iterations, would be acceptable but not intuitive. if a massive re-authorization is needed, Why would be needed to read the value and set back , What value is added in the testAndIncrement process? I will suggest that if ThruthValue is not appropiate, eventualy a new label for 1,2 would be appropiated: docsBpi2CmAuthReset OBJECT-TYPE SYNTAX INTEGER { -- or propose any other TC convention for reset-button to IETF reset(1), idle(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to 'reset' generates a Reauthorize event in the authorization FSM. Reading this object always returns idle." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.1.2.3.4." ::= { docsBpi2CmBaseEntry 7 } Eduardo -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Friday, January 10, 2003 6:11 AM To: Ipcdn (E-mail) Subject: [ipcdn] docsis subscriber mib - TruthValue for docsBpi2CmAuthReset After I had posted possible safeguards for the ...Reset object, Randy Presuhn even had another (possibly better) suggestion, that is to use TestAndIncr TC from RFC2579. I also saw your response that you use TruthValue in a few other similar objects in IPCDN originated MIB Modules. So I posed the question (to my MIB doctors team) if the problem is serious enough to make you do things different now conmpared to what you have done in other MIB modules. No final answer yet, but below is some input that may be good to review. Thanks, Bert -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: vrijdag 10 januari 2003 0:33 To: Mreview (E-mail) Subject: RE: docsis subscriber mib HI, Randy's suggestion is an efficient way to achieve two results: 1) initiating and action, and 2) determining if the action was initiated when no response is received. It's a somewhat unusual application of the TestAndIncr, and they do have object definitions in the field, and this is a change of solutions. However, it is a superior solution to what they have previously done. Here is the OLD solution.... docsBpi2CmAuthReset OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to TRUE generates a Reauthorize event in the authorization FSM. Reading this object always returns FALSE." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.1.2.3.4." ::= { docsBpi2CmBaseEntry 7 } And here is the NEW solution... docsBpi2CmAuthReset OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to its current value results in incrementing the value and causes a Reauthorize event in the authorization FSM. Reading this object always returns its current value." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.1.2.3.4." ::= { docsBpi2CmBaseEntry 7 } Notes: I would probably define another TC that acted like the TestAndIncr TC, but whose value was the number of "administratively initiated actions", and to initiate and action, I would write the current value plus one (instead of the current value). At 12:17 AM 1/10/2003 +0100, Wijnen, Bert (Bert) wrote: >Possibly... the reason why I forwarded was, >cause they seem to want one common way of doing these >things and we/they already have a set of RFCs that >do this in the same way as they are proposing in this >new MIB module. > >So the question becomes: > - is it so seriously flawed that we want to force them > to change the way they are doing these resets > - if so, then we should make a note so that if they > respind the existing RFCs, that we then also force them > to deprecate and create a new object. > >Or does this not make sense what I am asking here? > >Thanks, >Bert > >> -----Original Message----- >> From: Presuhn, Randy [mailto:Randy_Presuhn@bmc.com] >> Sent: donderdag 9 januari 2003 23:51 >> To: Mreview (E-mail) >> Subject: RE: docsis subscriber mib >> >> >> Hi - >> >> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >> > Sent: Thursday, January 09, 2003 13:47 >> > To: Mreview (E-mail) >> > Subject: Re: docsis subscriber mib >> > >> > >> > This is what I get back (or what I see in terms of discussion on >> > their ipcdn mailing list). >> ... >> >> Elaborating on my earlier comment: >> >> If the purpose of adding an additional time stamp object is to >> support detection of the cases Dave Perkins outlined, wouldn't it be >> simpler to replace the TruthValue with a TestAndIncr? This would get >> rid of the odd read/write semantics, prevent the worst replay >> scenarios, and allow recovery in the "lost response" case. >> >> The semantics they're proposing for these objects really don't match >> up with TruthValue. >> >> Randy Presuhn BMC Software, Inc. 1-3141 Regards, /david t. perkins _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Jan 10 10:43:55 2003 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 KAA01223 for ; Fri, 10 Jan 2003 10:43:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AFu9X08579 for ipcdn-archive@odin.ietf.org; Fri, 10 Jan 2003 10:56:09 -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 h0AFu8J08572; Fri, 10 Jan 2003 10:56:08 -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 h0AFtrJ08503 for ; Fri, 10 Jan 2003 10:55:53 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01142 for ; Fri, 10 Jan 2003 10:43:07 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id h0AFkMmb021324; Fri, 10 Jan 2003 08:46:22 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ipcdn] : proposed wording X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 10 Jan 2003 08:46:21 -0700 Message-ID: Thread-Topic: [ipcdn] : proposed wording Thread-Index: AcK4pXH76gY3b/1USiGB3ZpgNfBQfQAGIthQ From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , , Cc: , X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0AFtsJ08504 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dummy comment, Would be nice to have a precise enumeration reference in the DESCRIPTION clauses, not sure what is the appropiate one, ie, in RFC 2573 a case shows in the same DESCRIPTION clause (rowstatus) createAndGo(4) and 'notReady' Would prefer an unique one, 'notReady' or notReady(3) to be consistent In IPCDN mibs there is more flavors: i.e docsSubMgtPktFilterAction OBJECT-TYPE SYNTAX INTEGER { accept(1), drop(2) } ..... DESCRIPTION "The action to take upon this filter matching. Accept means to end filter matching and to accept the packet for further processing. Drop means to drop the packet." Would be more clean ( "The action to take upon this filter matching. accept(1) means to end filter matching and to accept the packet for further processing. drop(2) means to drop the packet." Or 'accept' 'drop' Eduardo -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Friday, January 10, 2003 5:39 AM To: Wilson.Sawyer@arrisi.com; ipcdn@ietf.org Cc: bert.wijnen@lucent.com; vedvyas.shanbhogue@intel.com Subject: [ipcdn] RE: docsis subscriber management: proposed wording for filter action I am OK with that Thanks, Bert > -----Original Message----- > From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > Sent: donderdag 9 januari 2003 16:57 > To: ipcdn@ietf.org > Cc: bert.wijnen@lucent.com; vedvyas.shanbhogue@intel.com > Subject: docsis subscriber management: proposed wording for filter > action > > > Vedvyas Shanbhogue wrote: > > 1.There should be an object describing the default > action to be taken when none of the filters in a > filter group match the packet. The default action > could be configurable as 'accept' or 'drop' > > Bert Wijnen had also expressed concern about the original description > clause of docsSubMgtPktFilterAction, which was: > > "The action to take upon this filter matching. Accept means > to accept the > packet for further processing. Drop means to drop the packet." > > to wit: what does further processing mean? In particular, > what does it mean > in terms of continuing with or exiting this table? > > I have been reluctant to clarify "accepted for further > processing" beyond > what is necessary for describing the mechanics of this table. > Terms like > "forwarding" violate the separation of layers needed for a clean > definition, and in practice have always provoked confusion. > > The following is proposed new wording for > docsSubMgtPktFilterTable, as well > as the -07 text from docsSubMgtPktFilterAction. Are the mechanics of > pktFilterAction now sufficiently clear? > > docsSubMgtPktFilterTable OBJECT-TYPE > SYNTAX SEQUENCE OF DocsSubMgtPktFilterEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of filter or classifier criteria. Classifiers are > assigned by group to the individual CMs. That assignment is made > via the configuration objects sent upstream from the CM to the > CMTS during registration. Each filter in the group is applied > in index order to each packet. If the filter matches, then the > indicated action is taken. If no filter matches then the packet > is accepted for further processing." > ::= { docsSubMgtObjects 6 } > > ... > > docsSubMgtPktFilterAction OBJECT-TYPE > SYNTAX INTEGER > { > accept(1), > drop(2) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The action to take upon this filter matching. Accept means > to end filter matching and to accept the packet for further > processing. Drop means to drop the packet." > DEFVAL { accept } > ::= { docsSubMgtPktFilterEntry 11 } > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Jan 10 12:49:55 2003 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 MAA06073 for ; Fri, 10 Jan 2003 12:49:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AI2Be17426 for ipcdn-archive@odin.ietf.org; Fri, 10 Jan 2003 13:02:11 -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 h0AI2AJ17416; Fri, 10 Jan 2003 13:02:10 -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 h0AI1qJ17394 for ; Fri, 10 Jan 2003 13:01:52 -0500 Received: from caduceus.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06030 for ; Fri, 10 Jan 2003 12:49:04 -0500 (EST) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h0AHkuv10343 for ; Fri, 10 Jan 2003 17:46:56 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id h0AGtRH00244 for ; Fri, 10 Jan 2003 16:55:27 GMT Received: from fmsmsx331-2.fm.intel.com ([132.233.42.156]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003011008545724838 ; Fri, 10 Jan 2003 08:54:57 -0800 Received: from fmsmsx404.amr.corp.intel.com ([132.233.42.208]) by fmsmsx331-2.fm.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 10 Jan 2003 08:53:22 -0800 content-class: urn:content-classes:message Date: Fri, 10 Jan 2003 08:53:21 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: docsis subscriber management: proposed wording for filter action X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Thread-Index: AcK3+BwaShXHCiPrEdewVgBQi2jYqAA0J1fA From: "Shanbhogue, Vedvyas" To: , Cc: X-OriginalArrivalTime: 10 Jan 2003 16:53:22.0909 (UTC) FILETIME=[C93EA0D0:01C2B8C8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0AI1qJ17395 Subject: [ipcdn] RE: docsis subscriber management: proposed wording for filter action Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I agree with the wording. regards vedvyas -----Original Message----- From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] Sent: Thursday, January 09, 2003 7:57 AM To: ipcdn@ietf.org Cc: bert.wijnen@lucent.com; Shanbhogue, Vedvyas Subject: docsis subscriber management: proposed wording for filter action Vedvyas Shanbhogue wrote: 1.There should be an object describing the default action to be taken when none of the filters in a filter group match the packet. The default action could be configurable as 'accept' or 'drop' Bert Wijnen had also expressed concern about the original description clause of docsSubMgtPktFilterAction, which was: "The action to take upon this filter matching. Accept means to accept the packet for further processing. Drop means to drop the packet." to wit: what does further processing mean? In particular, what does it mean in terms of continuing with or exiting this table? I have been reluctant to clarify "accepted for further processing" beyond what is necessary for describing the mechanics of this table. Terms like "forwarding" violate the separation of layers needed for a clean definition, and in practice have always provoked confusion. The following is proposed new wording for docsSubMgtPktFilterTable, as well as the -07 text from docsSubMgtPktFilterAction. Are the mechanics of pktFilterAction now sufficiently clear? docsSubMgtPktFilterTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsSubMgtPktFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of filter or classifier criteria. Classifiers are assigned by group to the individual CMs. That assignment is made via the configuration objects sent upstream from the CM to the CMTS during registration. Each filter in the group is applied in index order to each packet. If the filter matches, then the indicated action is taken. If no filter matches then the packet is accepted for further processing." ::= { docsSubMgtObjects 6 } ... docsSubMgtPktFilterAction OBJECT-TYPE SYNTAX INTEGER { accept(1), drop(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The action to take upon this filter matching. Accept means to end filter matching and to accept the packet for further processing. Drop means to drop the packet." DEFVAL { accept } ::= { docsSubMgtPktFilterEntry 11 } _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Jan 10 14:15:51 2003 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 OAA12921 for ; Fri, 10 Jan 2003 14:15:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AJS9d23225 for ipcdn-archive@odin.ietf.org; Fri, 10 Jan 2003 14:28:09 -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 h0AJS7J23218; Fri, 10 Jan 2003 14:28:07 -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 h0AJR1J23148 for ; Fri, 10 Jan 2003 14:27:01 -0500 Received: from mail.correlant.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12873 for ; Fri, 10 Jan 2003 14:14:10 -0500 (EST) Received: from kfriedman (67.82.218.209.transedge.com [209.218.82.67]) by mail.correlant.com (Postfix) with SMTP id D40D7BC100; Fri, 10 Jan 2003 11:15:02 -0800 (PST) From: "Kirk Friedman" To: "'Eduardo Cardona'" , "'Wijnen, Bert (Bert)'" , "'Ipcdn (E-mail)'" Subject: RE: [ipcdn] docsis subscriber mib - TruthValue for docsBpi2CmAuthReset Date: Fri, 10 Jan 2003 11:17:24 -0800 Message-ID: <002201c2b8dc$e8d6c3a0$4352dad1@correlant.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit All, It seems like the testAndIncrement solution would break the 'setwalk' test feature from Wilson's email yesterday. Writing back the same value read would cause the reset or other action that was not intended. The 'setwalk' is used by automated SNMP test programs to make sure that a R/W object is writable. Using the testAndIncrement for these parameters could cause many unexpected consequences. Thanks, Kirk -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Eduardo Cardona Sent: Friday, January 10, 2003 7:27 AM To: Wijnen, Bert (Bert); Ipcdn (E-mail) Subject: RE: [ipcdn] docsis subscriber mib - TruthValue for docsBpi2CmAuthReset All, testAndIncrements /spinlock kind of solution is targeted for s'locking' multiple iterations, would be acceptable but not intuitive. if a massive re-authorization is needed, Why would be needed to read the value and set back , What value is added in the testAndIncrement process? I will suggest that if ThruthValue is not appropiate, eventualy a new label for 1,2 would be appropiated: docsBpi2CmAuthReset OBJECT-TYPE SYNTAX INTEGER { -- or propose any other TC convention for reset-button to IETF reset(1), idle(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to 'reset' generates a Reauthorize event in the authorization FSM. Reading this object always returns idle." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.1.2.3.4." ::= { docsBpi2CmBaseEntry 7 } Eduardo -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Friday, January 10, 2003 6:11 AM To: Ipcdn (E-mail) Subject: [ipcdn] docsis subscriber mib - TruthValue for docsBpi2CmAuthReset After I had posted possible safeguards for the ...Reset object, Randy Presuhn even had another (possibly better) suggestion, that is to use TestAndIncr TC from RFC2579. I also saw your response that you use TruthValue in a few other similar objects in IPCDN originated MIB Modules. So I posed the question (to my MIB doctors team) if the problem is serious enough to make you do things different now conmpared to what you have done in other MIB modules. No final answer yet, but below is some input that may be good to review. Thanks, Bert -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: vrijdag 10 januari 2003 0:33 To: Mreview (E-mail) Subject: RE: docsis subscriber mib HI, Randy's suggestion is an efficient way to achieve two results: 1) initiating and action, and 2) determining if the action was initiated when no response is received. It's a somewhat unusual application of the TestAndIncr, and they do have object definitions in the field, and this is a change of solutions. However, it is a superior solution to what they have previously done. Here is the OLD solution.... docsBpi2CmAuthReset OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to TRUE generates a Reauthorize event in the authorization FSM. Reading this object always returns FALSE." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.1.2.3.4." ::= { docsBpi2CmBaseEntry 7 } And here is the NEW solution... docsBpi2CmAuthReset OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to its current value results in incrementing the value and causes a Reauthorize event in the authorization FSM. Reading this object always returns its current value." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.1.2.3.4." ::= { docsBpi2CmBaseEntry 7 } Notes: I would probably define another TC that acted like the TestAndIncr TC, but whose value was the number of "administratively initiated actions", and to initiate and action, I would write the current value plus one (instead of the current value). At 12:17 AM 1/10/2003 +0100, Wijnen, Bert (Bert) wrote: >Possibly... the reason why I forwarded was, >cause they seem to want one common way of doing these >things and we/they already have a set of RFCs that >do this in the same way as they are proposing in this >new MIB module. > >So the question becomes: > - is it so seriously flawed that we want to force them > to change the way they are doing these resets > - if so, then we should make a note so that if they > respind the existing RFCs, that we then also force them > to deprecate and create a new object. > >Or does this not make sense what I am asking here? > >Thanks, >Bert > >> -----Original Message----- >> From: Presuhn, Randy [mailto:Randy_Presuhn@bmc.com] >> Sent: donderdag 9 januari 2003 23:51 >> To: Mreview (E-mail) >> Subject: RE: docsis subscriber mib >> >> >> Hi - >> >> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >> > Sent: Thursday, January 09, 2003 13:47 >> > To: Mreview (E-mail) >> > Subject: Re: docsis subscriber mib >> > >> > >> > This is what I get back (or what I see in terms of discussion on >> > their ipcdn mailing list). >> ... >> >> Elaborating on my earlier comment: >> >> If the purpose of adding an additional time stamp object is to >> support detection of the cases Dave Perkins outlined, wouldn't it be >> simpler to replace the TruthValue with a TestAndIncr? This would get >> rid of the odd read/write semantics, prevent the worst replay >> scenarios, and allow recovery in the "lost response" case. >> >> The semantics they're proposing for these objects really don't match >> up with TruthValue. >> >> Randy Presuhn BMC Software, Inc. 1-3141 Regards, /david t. perkins _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Jan 10 19:01:00 2003 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 TAA20372 for ; Fri, 10 Jan 2003 19:01:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0B0DNQ08057 for ipcdn-archive@odin.ietf.org; Fri, 10 Jan 2003 19:13:23 -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 h0B0D9J08050; Fri, 10 Jan 2003 19:13:09 -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 h0B0CAJ08020 for ; Fri, 10 Jan 2003 19:12:10 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20326 for ; Fri, 10 Jan 2003 18:59:16 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0B02VO11057 for ; Fri, 10 Jan 2003 19:02:32 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sat, 11 Jan 2003 01:02:31 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15598A509@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kirk Friedman , "'Eduardo Cardona'" , "'Wijnen, Bert (Bert)'" , "'Ipcdn (E-mail)'" Subject: RE: [ipcdn] docsis subscriber mib - TruthValue for docsBpi2CmAuth Reset Date: Sat, 11 Jan 2003 01:02:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , > It seems like the testAndIncrement solution would break > the 'setwalk' test feature from Wilson's email yesterday. > Writing back the same value read would cause the reset or other > action that was not intended. The 'setwalk' is used by automated > SNMP test programs to make sure that a R/W object is writable. Why would setwalk break with a TestAndIncr ??? You can read the value and set it back to the same value (as per RFC2579). And in any event, if the setwalk breaks on it, then it will break already at many places in the MIB tree, cause we do have quite a set of TestAndIncr objects in various stds track MIB modules already. Please note that I was not trying to force the WG to go to TestAndIncr syntax. I have been asking the question to my set of MIB Doctors, and I am forwarding ideas/suggestions that come out of that group. Maybe it was not clear from the email, but I was asking (in my last email to the Mib Doctors) if your current TC is so bad that we would want to force you to change it. I have not yet received a convincing answer that we should. So if you want to keep it... I think it will be fine (unless I hear serious concern over the next few days of my MIB doctors). What the MIB doctors have been doing is passing issues/concerns that you might want to think about, and if they are applicable then they have made suggestion for alternatives. Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Jan 10 19:42:40 2003 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 TAA21121 for ; Fri, 10 Jan 2003 19:42:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0B0t4m09725 for ipcdn-archive@odin.ietf.org; Fri, 10 Jan 2003 19:55:04 -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 h0B0t3J09718; Fri, 10 Jan 2003 19:55:03 -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 h0B0snJ09676 for ; Fri, 10 Jan 2003 19:54:49 -0500 Received: from mail.correlant.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21096 for ; Fri, 10 Jan 2003 19:41:53 -0500 (EST) Received: from kfriedman (67.82.218.209.transedge.com [209.218.82.67]) by mail.correlant.com (Postfix) with SMTP id 1C4C8BC12A; Fri, 10 Jan 2003 16:42:44 -0800 (PST) From: "Kirk Friedman" To: "'Wijnen, Bert (Bert)'" , "'Eduardo Cardona'" , "'Ipcdn (E-mail)'" Subject: RE: [ipcdn] docsis subscriber mib - TruthValue for docsBpi2CmAuthReset Date: Fri, 10 Jan 2003 16:45:07 -0800 Message-ID: <005c01c2b90a$b0896100$4352dad1@correlant.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15598A509@nl0006exch001u.nl.lucent.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Bert, I think we all very much appreciate the ideas, I just want to make sure that this is not going to cause problems for DOCSIS testing and operation. If I understand RFC2579 then reading the value from the object and setting exactly the same value back causes the object to increment the value by 1, and possibly perform the action. Any other set causes an error of 'inconsistentValue'. So snipping from Daniel Perkins example: docsBpi2CmAuthReset OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to its current value results in incrementing the value and causes a Reauthorize event in the authorization FSM. Reading this object always returns its current value." REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification, Section 4.1.2.3.4." ::= { docsBpi2CmBaseEntry 7 } A setwalk would result in an AuthRest for every CM in the system. Does this sound correct? I don't think this is the intended operation of the setwalk test that many vendors use. I think this is why the TruthValue has been used in the past. Is this what you are suggesting for docsSubMgtCpeControlReset? The docsSubMgtCpeControlReset as a TestAndIncr would clear all of the 'learned' addresses in docsSubMgtCpeIpTable for a given CM being deleted. Again, I do not think this is the intended result. Any automated test program would have to realize that after this, any entries in the docsSubMgtCpeIpTable that it read previously, should not be tested. Thanks, Kirk -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Friday, January 10, 2003 4:02 PM To: Kirk Friedman; 'Eduardo Cardona'; 'Wijnen, Bert (Bert)'; 'Ipcdn (E-mail)' Subject: RE: [ipcdn] docsis subscriber mib - TruthValue for docsBpi2CmAuthReset > It seems like the testAndIncrement solution would break > the 'setwalk' test feature from Wilson's email yesterday. > Writing back the same value read would cause the reset or other > action that was not intended. The 'setwalk' is used by automated > SNMP test programs to make sure that a R/W object is writable. Why would setwalk break with a TestAndIncr ??? You can read the value and set it back to the same value (as per RFC2579). And in any event, if the setwalk breaks on it, then it will break already at many places in the MIB tree, cause we do have quite a set of TestAndIncr objects in various stds track MIB modules already. Please note that I was not trying to force the WG to go to TestAndIncr syntax. I have been asking the question to my set of MIB Doctors, and I am forwarding ideas/suggestions that come out of that group. Maybe it was not clear from the email, but I was asking (in my last email to the Mib Doctors) if your current TC is so bad that we would want to force you to change it. I have not yet received a convincing answer that we should. So if you want to keep it... I think it will be fine (unless I hear serious concern over the next few days of my MIB doctors). What the MIB doctors have been doing is passing issues/concerns that you might want to think about, and if they are applicable then they have made suggestion for alternatives. Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Sat Jan 11 10:34:55 2003 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 KAA13325 for ; Sat, 11 Jan 2003 10:34:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0BFlcg27797 for ipcdn-archive@odin.ietf.org; Sat, 11 Jan 2003 10:47:38 -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 h0BFlYJ27778; Sat, 11 Jan 2003 10:47:34 -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 h0BFkSJ27723 for ; Sat, 11 Jan 2003 10:46:28 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13225 for ; Sat, 11 Jan 2003 10:33:01 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0BFaIt22115 for ; Sat, 11 Jan 2003 10:36:18 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sat, 11 Jan 2003 16:36:17 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15598A57D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kirk Friedman , "'Wijnen, Bert (Bert)'" , "'Eduardo Cardona'" , "'Ipcdn (E-mail)'" Subject: RE: [ipcdn] docsis subscriber mib - TruthValue for docsBpi2CmAuth Reset Date: Sat, 11 Jan 2003 16:36:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , I would think that for a RESET button you would actually not let anyone do just a setWalk. In fact, I think that a setWalk is a really bad idea, except for when you are testing the SNMP stack or maybe the instrumentation. You would never do so (I think) on an operational system. Access control (VACM after authenticated access) would make sure that only appropriate personal or tools would get SET access to MIB objects. Inline. Thanks, Bert > -----Original Message----- > From: Kirk Friedman [mailto:kfriedman@correlant.com] > Sent: zaterdag 11 januari 2003 1:45 > To: 'Wijnen, Bert (Bert)'; 'Eduardo Cardona'; 'Ipcdn (E-mail)' > Subject: RE: [ipcdn] docsis subscriber mib - TruthValue for > docsBpi2CmAuthReset > > > Hi Bert, > > I think we all very much appreciate the ideas, I just > want to make sure > that this is not going to cause problems for DOCSIS testing > and operation. > If I understand RFC2579 then reading the value from the > object and setting > exactly the same value back causes the object to increment > the value by 1, > and possibly perform the action. Any other set causes an error of > 'inconsistentValue'. So snipping from Daniel Perkins example: > > docsBpi2CmAuthReset OBJECT-TYPE > SYNTAX TestAndIncr > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Setting this object to its current value results in > incrementing the value and causes a Reauthorize event > in the authorization FSM. Reading this object always > returns its current value." > REFERENCE > "DOCSIS Baseline Privacy Plus Interface Specification, > Section 4.1.2.3.4." > ::= { docsBpi2CmBaseEntry 7 } > > A setwalk would result in an AuthRest for every CM in the > system. Does this > sound correct? I don't think this is the intended operation > of the setwalk test that many vendors use. That is correct, and the setWalk would have that effect. See above why I think you should never run a setWalk on an operational system. > I think this is why the TruthValue has been used in the past. > Sounds like you guys should continue with that. > Is this what you are suggesting for docsSubMgtCpeControlReset? The > docsSubMgtCpeControlReset as a TestAndIncr would clear all of > the 'learned' addresses in docsSubMgtCpeIpTable for a given CM being > deleted. Again, I do not think this is the intended result. > Any automated test program would > have to realize that after this, any entries in the > docsSubMgtCpeIpTable that it read previously, should not be tested. > Even when you use TruthValue, I would NOT allow uncontroled access to this object. Instead protect it via VACM, and never run a setWalk against operational systems (unless you are aware of the side-effects and don't care). Bert > Thanks, > > Kirk > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Friday, January 10, 2003 4:02 PM > To: Kirk Friedman; 'Eduardo Cardona'; 'Wijnen, Bert (Bert)'; 'Ipcdn > (E-mail)' > Subject: RE: [ipcdn] docsis subscriber mib - TruthValue for > docsBpi2CmAuthReset > > > > It seems like the testAndIncrement solution would break > > the 'setwalk' test feature from Wilson's email yesterday. > > Writing back the same value read would cause the reset or other > > action that was not intended. The 'setwalk' is used by automated > > SNMP test programs to make sure that a R/W object is writable. > > Why would setwalk break with a TestAndIncr ??? You can read the > value and set it back to the same value (as per RFC2579). > > And in any event, if the setwalk breaks on it, then it will > break already at many places in the MIB tree, cause we do have > quite a set of TestAndIncr objects in various stds track MIB > modules already. > > Please note that I was not trying to force the WG to go to > TestAndIncr syntax. I have been asking the question to my > set of MIB Doctors, and I am forwarding ideas/suggestions that > come out of that group. > > Maybe it was not clear from the email, but I was asking (in my > last email to the Mib Doctors) if your current TC is so bad > that we would want to force you to change it. I have not yet > received a convincing answer that we should. So if you want > to keep it... I think it will be fine (unless I hear serious > concern over the next few days of my MIB doctors). > > What the MIB doctors have been doing is passing issues/concerns > that you might want to think about, and if they are applicable > then they have made suggestion for alternatives. > > Bert > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Mon Jan 13 14:24:08 2003 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 OAA20841 for ; Mon, 13 Jan 2003 14:24:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DJbt916730 for ipcdn-archive@odin.ietf.org; Mon, 13 Jan 2003 14:37:55 -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 h0DJbWJ16699; Mon, 13 Jan 2003 14:37:32 -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 h0DJaQJ16023 for ; Mon, 13 Jan 2003 14:36:26 -0500 Received: from mail.correlant.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20824 for ; Mon, 13 Jan 2003 14:22:07 -0500 (EST) Received: from kfriedman (67.82.218.209.transedge.com [209.218.82.67]) by mail.correlant.com (Postfix) with SMTP id C9105BC0DE; Mon, 13 Jan 2003 11:22:39 -0800 (PST) From: "Kirk Friedman" To: "'Wijnen, Bert (Bert)'" , "'Eduardo Cardona'" , "'Ipcdn (E-mail)'" Subject: RE: [ipcdn] docsis subscriber mib - TruthValue for docsBpi2CmAuthReset Date: Mon, 13 Jan 2003 11:25:24 -0800 Message-ID: <005a01c2bb39$85fa5260$4352dad1@correlant.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15598A57D@nl0006exch001u.nl.lucent.com> Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Bert, The idea is not for operational systems, but to check correct implementation of the MIB automatically across all objects. I have no objections to making docsSubMgtCpeControlReset or docsBpi2CmAuthReset TestAndIncr as long as CableLabs and other vendors understand and agree. It is simpler and more elegant than adding a timestamp. Thanks, Kirk -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Saturday, January 11, 2003 7:36 AM To: Kirk Friedman; 'Wijnen, Bert (Bert)'; 'Eduardo Cardona'; 'Ipcdn (E-mail)' Subject: RE: [ipcdn] docsis subscriber mib - TruthValue for docsBpi2CmAuthReset I would think that for a RESET button you would actually not let anyone do just a setWalk. In fact, I think that a setWalk is a really bad idea, except for when you are testing the SNMP stack or maybe the instrumentation. You would never do so (I think) on an operational system. Access control (VACM after authenticated access) would make sure that only appropriate personal or tools would get SET access to MIB objects. Inline. Thanks, Bert > -----Original Message----- > From: Kirk Friedman [mailto:kfriedman@correlant.com] > Sent: zaterdag 11 januari 2003 1:45 > To: 'Wijnen, Bert (Bert)'; 'Eduardo Cardona'; 'Ipcdn (E-mail)' > Subject: RE: [ipcdn] docsis subscriber mib - TruthValue for > docsBpi2CmAuthReset > > > Hi Bert, > > I think we all very much appreciate the ideas, I just > want to make sure > that this is not going to cause problems for DOCSIS testing > and operation. > If I understand RFC2579 then reading the value from the > object and setting > exactly the same value back causes the object to increment > the value by 1, > and possibly perform the action. Any other set causes an error of > 'inconsistentValue'. So snipping from Daniel Perkins example: > > docsBpi2CmAuthReset OBJECT-TYPE > SYNTAX TestAndIncr > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Setting this object to its current value results in > incrementing the value and causes a Reauthorize event > in the authorization FSM. Reading this object always > returns its current value." > REFERENCE > "DOCSIS Baseline Privacy Plus Interface Specification, > Section 4.1.2.3.4." > ::= { docsBpi2CmBaseEntry 7 } > > A setwalk would result in an AuthRest for every CM in the > system. Does this > sound correct? I don't think this is the intended operation > of the setwalk test that many vendors use. That is correct, and the setWalk would have that effect. See above why I think you should never run a setWalk on an operational system. > I think this is why the TruthValue has been used in the past. > Sounds like you guys should continue with that. > Is this what you are suggesting for docsSubMgtCpeControlReset? The > docsSubMgtCpeControlReset as a TestAndIncr would clear all of > the 'learned' addresses in docsSubMgtCpeIpTable for a given CM being > deleted. Again, I do not think this is the intended result. > Any automated test program would > have to realize that after this, any entries in the > docsSubMgtCpeIpTable that it read previously, should not be tested. > Even when you use TruthValue, I would NOT allow uncontroled access to this object. Instead protect it via VACM, and never run a setWalk against operational systems (unless you are aware of the side-effects and don't care). Bert > Thanks, > > Kirk > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Friday, January 10, 2003 4:02 PM > To: Kirk Friedman; 'Eduardo Cardona'; 'Wijnen, Bert (Bert)'; 'Ipcdn > (E-mail)' > Subject: RE: [ipcdn] docsis subscriber mib - TruthValue for > docsBpi2CmAuthReset > > > > It seems like the testAndIncrement solution would break > > the 'setwalk' test feature from Wilson's email yesterday. > > Writing back the same value read would cause the reset or other > > action that was not intended. The 'setwalk' is used by automated > > SNMP test programs to make sure that a R/W object is writable. > > Why would setwalk break with a TestAndIncr ??? You can read the > value and set it back to the same value (as per RFC2579). > > And in any event, if the setwalk breaks on it, then it will > break already at many places in the MIB tree, cause we do have > quite a set of TestAndIncr objects in various stds track MIB > modules already. > > Please note that I was not trying to force the WG to go to > TestAndIncr syntax. I have been asking the question to my > set of MIB Doctors, and I am forwarding ideas/suggestions that > come out of that group. > > Maybe it was not clear from the email, but I was asking (in my > last email to the Mib Doctors) if your current TC is so bad > that we would want to force you to change it. I have not yet > received a convincing answer that we should. So if you want > to keep it... I think it will be fine (unless I hear serious > concern over the next few days of my MIB doctors). > > What the MIB doctors have been doing is passing issues/concerns > that you might want to think about, and if they are applicable > then they have made suggestion for alternatives. > > Bert > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 16 13:27:20 2003 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 NAA19267 for ; Thu, 16 Jan 2003 13:27:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GIgWc13105 for ipcdn-archive@odin.ietf.org; Thu, 16 Jan 2003 13:42:32 -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 h0GIgVJ13094; Thu, 16 Jan 2003 13:42:31 -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 h0GIfbJ13052 for ; Thu, 16 Jan 2003 13:41:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19203; Thu, 16 Jan 2003 13:25:54 -0500 (EST) Message-Id: <200301161825.NAA19203@ietf.org> From: "Woundy, Richard" To: IETF-Announce: ; cc: ipcdn@ietf.org Date: Thu, 16 Jan 2003 13:25:53 -0500 Subject: [ipcdn] Proposal for an interim IPCDN working group meeting Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , IP over Cable Data Network WG (IPCDN) Interim Meeting ===================================================== The IPCDN WG is holding an interim meeting on February 13, 2003. This meeting is scheduled the day after the CableLabs Winter Conference, which is being held in Broomfield, Colorado. Time: Thursday, February 13, 2003 at 0900 - 1500 Location: Comcast Westminster Labs 10355 Westmoor Drive Westminster, Colorado Potential alternate location: Cable Television Laboratories 400 Centennial Parkway Louisville, Colorado Co-chairs: Richard Woundy Jean-Francois Mule Internet Area Advisor: Thomas Narten Agenda ------ A formal meeting agenda will be sent out in late January. The intent of this interim meeting is to collect review comments for the DOCSIS, PacketCable, and CableHome MIBs, which are listed at http://www.ipcdn.org/ipcdn-ids.html. - The DOCSIS MIBs for Subscriber Management and Application of the IGMP MIB are in AD review, and are not the primary focus of the interim meeting. - The remaining DOCSIS MIBs are expected to be refreshed by January 20th in preparation for WG last-call, and are the primary focus of the meeting. - The PacketCable MIBs are in preparation for WG last-call by the March IETF meeting in San Francisco. - The CableHome MIBs are being refreshed as individual draft submissions with new authors, in preparation for acceptance as WG action items. Location of Nearby Hotel and Meeting ------------------------------------ The CableLabs Winter Conference is being held at this hotel: The Omni Interlocken Resort Broomfield, Colorado Phone: +1 303-438-6600 The "CableLabs" rate for the conference is $129 per night. More information about the CableLabs conference can be found at http://www.cablelabs.com. The interim WG meeting is scheduled at a Comcast facility in a neighboring community (Westminster). The alternate meeting location is the CableLabs facility in another neighboring community (Louisville). Meeting participants must register with the IPCDN co-chairs by Friday February 9th, by email to the chairs, or via a registration form on http://www.ipcdn.org (soon to be set up). We anticipate that wired connectivity will be provided. Mailing List ------------ General Discussion: To Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Jan 17 15:42:32 2003 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 PAA03919 for ; Fri, 17 Jan 2003 15:42:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HKwGI28911 for ipcdn-archive@odin.ietf.org; Fri, 17 Jan 2003 15:58:16 -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 h0HKugJ28813; Fri, 17 Jan 2003 15:56:42 -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 h0HKtMJ28763 for ; Fri, 17 Jan 2003 15:55:22 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03837 for ; Fri, 17 Jan 2003 15:38:46 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h0HKf0vT019339 for ; Fri, 17 Jan 2003 13:41:00 -0700 (MST) Received: [from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id NAA13368 for ; Fri, 17 Jan 2003 13:42:04 -0700 (MST)] Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59) id ; Fri, 17 Jan 2003 15:42:04 -0500 Message-ID: <19CD0E423FC1D611893500508B6F0B9C084937@ma07exm01.dma.isg.mot.com> From: Murwin William-LWM008 To: "Docsis-Oss (E-mail)" , "IPCDN (E-mail)" Cc: "Michael W. Patrick (E-mail)" , "'Woundy, Richard'" Date: Fri, 17 Jan 2003 15:41:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2BE68.DF7AD300" Subject: [ipcdn] Latest version of draft-ietf-ipcdn-qos-mib-07.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C2BE68.DF7AD300 Content-Type: text/plain; charset="iso-8859-1" Here is the latest version of the DOCSIS-QOS MIB. This is version 7 with the back date of January 1, 2003 so as not to be confused when the draft is submitted to IETF. Please send comments and suggestion as soon as possible so that we can post this on the IETF web site. Our goal is to post the version 7 within a week. Changes are noted at the top of the draft and within the Revision History of the MIB. Thanks, Mike Patrick & Will Murwin <> ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 ------_=_NextPart_000_01C2BE68.DF7AD300 Content-Type: text/plain; name="draft-ietf-ipcdn-qos-mib-07.txt" Content-Disposition: attachment; filename="draft-ietf-ipcdn-qos-mib-07.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= IPCDN Working Group Michael = Patrick=0A= William = Murwin=0A= Motorola BCS=0A= =0A= =0A= =0A= Data Over Cable System Quality of Service=0A= Management Information Base (DOCSIS-QOS MIB)=0A= =0A= January 1, 2003=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Status of this Memo=0A= =0A= This document is an Internet-Draft and is in full conformance = with=0A= all the provisions of Section 10 of RFC2026. Internet-Drafts are=0A= working documents of the Internet Engineering Task Force (IETF), = its=0A= Areas, and its Working Groups. Note that other groups may also=0A= distribute working documents as Internet-Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six = months=0A= and may be updated, replaced, or obsoleted by other documents at = any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as a "work in progress".=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= =0A= Copyright (c) The Internet Society 2001. All Rights Reserved.=0A= =0A= =0A= Abstract=0A= =0A= This document defines a basic set of managed objects for = SNMP-based=0A= management of extended QOS features of Cable Modems (CMs) and = Cable=0A= Modem Termination Systems (CMTSs) conforming to the Data over = Cable=0A= System (DOCSIS) standard version 1.1.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 1]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= Table of Contents=0A= =0A= =0A= Status of this Memo............................... 1=0A= Abstract.......................................... 1=0A= Revision History.................................. 3=0A= =0A= 1. Introduction...................................... 6=0A= 1.1 The Internet-Standard Management Framework... 6=0A= 1.2 Glossary..................................... 6=0A= =0A= 2. Overview.......................................... 8=0A= 2.1 Textual Conventions.......................... 8=0A= 2.2 MIB Organization............................ 8=0A= 2.2.1 docsQosPktClassTable................. 12=0A= 2.2.1.1 InetAddress Transition............... 13=0A= 2.2.2 docsQosParamSetTable................. 14=0A= 2.2.2.1 Interoperation with DOCSIS 1.0....... 15=0A= 2.2.3 docsQosServiceFlowTable.............. 16=0A= 2.2.4 docsQosServiceFlowStatsTable......... 18=0A= 2.2.5 docsQosUpstreamStatsTable............ 18=0A= 2.2.6 docsQosDynamicServiceStatsTable...... 18=0A= 2.2.7 docsQosServiceFlowLogTable........... 19=0A= 2.2.8 docsQosServiceClassTable............. 19=0A= 2.2.9 docsQosServiceClassPolicyTable....... 20=0A= 2.2.10 docsQosPHSTable...................... 20=0A= 2.2.11 docsQosCmtsMacToSrvFlowTable......... 20=0A= =0A= 3. Externally Administered Classification............ 20=0A= =0A= 4. Definitions....................................... 24=0A= =0A= 5. Security Considerations........................... 87=0A= =0A= 6. Intellectual Property............................. 88=0A= =0A= 7. Acknowledgement................................... 89=0A= =0A= 8. Normative References.............................. 89=0A= =0A= 9. Informative References............................ 90=0A= =0A= 10. Author's Address.................................. 90=0A= =0A= 11. Full Copyright Statement.......................... 91=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 2]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= Revision History=0A= =0A= Rev Date Description=0A= --- -------- -----------=0A= -07 1/1/03 Functional Changes:=0A= - Clarified the operation of the RowStatus = objects.=0A= - Added five new 64 bit counter objects.=0A= - Clarified the description for = docsQosPktClassPkts.=0A= - Clarified the description for=0A= docsQosServiceFlowOctets.=0A= - Clarified the description for=0A= docsQosServiceFlowPkts.=0A= - Clarified the operation of the=0A= docsQosServiceClassStatus.=0A= - Changed the description of the reported = default=0A= values for the = docsQosParamSetMaxTrafficBurst and=0A= docsQosParamSetMaxConcatBurst.=0A= - Changed the default values for the=0A= docsQosServiceClassMaxTrafficBurst.=0A= and docsQosServiceClassMaxConcatBurst = objects.=0A= Editorial Changes:=0A= - Updated Author's Address.=0A= - Updated Section 2.2.4 = docsQosServiceFlowStatsTable.=0A= - Section 1.1 was updated to reflect the=0A= most recent MIB boilerplate.=0A= - Section 5 was updated to reflect the=0A= most recent Security Considerations.=0A= - Split References into Normative and = Informative.=0A= - Updated references to refer to current = RFCs.=0A= -06 11/8/01 Functional Changes:=0A= - Deprecated objects that were of type = IpAddress=0A= and added new objects that were of type=0A= InetAddressType and InetAddress, to = support both=0A= IPv4 and IPv6 in the = docsQosPktClassTable.=0A= - Clarified the default value of the=0A= docsQosPktClassIpDestMask and=0A= docsQosPktClassIpSourceMask.=0A= - Clarified that some of counters from = the=0A= docsQosDynamicServiceStatsTable, = include=0A= retries.=0A= - Added objects that were removed from = earlier=0A= revisions of the mib, as obsolete.=0A= - In section 2.2.2.1, in bullet item (1) = removed=0A= requirement of adding row to=0A= docsIfQosProfileTable.=0A= - Clarified the Cable Modem's implementation = of the=0A= docsQosParamSetTosAndMask.=0A= Editorial Changes:=0A= - Corrected the description of the = individual bits=0A= that make up = docsQosParamsSetRequestPolicyOct.=0A= - Corrected the spelling of = docsCableMaclayer in the=0A= =0A= =0A= =0A= Expires July 2003 [Page 3]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= description of the = docsQosServiceFlowLogIfIndex.=0A= - In section 2.2.1, clarified the definition = of=0A= classifiers in the = docsQosPktClassTable.=0A= - In section 2.2.2.1, in bullet item (3) = flexibility=0A= was given to implementing=0A= docsIfQosProfileTable.=0A= - In section 2.2.2.1, added bullet item = (6).=0A= - Changed references to the latest = Data-Over-Cable=0A= Service Interface Specifications: Radio = Frequency=0A= Interface Specification.=0A= - Added section 2.2.1.1 InetAddress = Transition,=0A= to discuss the change from IpAddress = objects=0A= to InetAddressType and InetAddress = objects.=0A= - Changed the description of objects within = the=0A= docsQosServiceClassTable, so that they = were=0A= no longer templates for obsolete = objects.=0A= - Changed section 5 to "Security = Considerations".=0A= - Changed section 6 to "Intellectual = Property".=0A= - "References" where moved to section 8.=0A= - "Author's Address" where moved to section = 9.=0A= - Added section 7, "Acknowledgement".=0A= - Added section 10, "Full Copyright = Statement".=0A= - Section 1.1 was updated to reflect the=0A= most recent MIB boilerplate.=0A= - Updated references to refer to current = RFCs.=0A= =0A= =0A= -05 03/01/01 Functional Changes:=0A= - Changed default values of=0A= dosQosPktClassIpSourceMask and=0A= docsQosPktClassIpDestMask to = 255.255.255.255.=0A= Editorial Changes:=0A= - Corrected ifDirection values in 2.1.=0A= - In section 2.2.2.1, clarified which=0A= packets/bytes are counted in = docsIfCmtsService-=0A= InPkts and docsIfCmtsServiceInOctets.=0A= - Clarified description of = dosQosServiceFlowPkts=0A= to avoid requiring CMs to classify = downstream=0A= packets.=0A= - Clarified that = docsQosServiceFlowPHSUnknowns only=0A= applies to received packets.=0A= - Clarified that docsQosPktClassBitMap = and=0A= docsQosParamSetBitMap indicate all = parameters for=0A= both adds and changes.=0A= =0A= =0A= -04 10/18/00 - Updated descriptions of UGS applicable = QOS=0A= param set objects.=0A= - Added two new docsQosPktClassBitMap = bits=0A= and *renumbered* the bits.=0A= - Added docsQosServiceClassDirection=0A= =0A= =0A= =0A= Expires July 2003 [Page 4]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= -04 10/10/00 - Updated Overview to not mention = restriction=0A= to SnmpV1.=0A= - Updated most docsQosParamSet objects to=0A= clarify default and "not applicable" = values.=0A= - Add docsQosPktClassBitMap, = docsQosParamSetBitMap=0A= - Restore docsQosParamSetServiceClassName=0A= - Add 5 objects to = docsQosServiceFlowLogTable=0A= =0A= -04 10/01/00 - Move six objects from = docsQosServiceFlowTable=0A= back to docsQosParamSetTable.=0A= - Add DCC statistics=0A= - Removed notApplicable(256) from=0A= docsQosParamSetSchedulingType=0A= =0A= -03 08/11/00 Reorganize docsQosParamSetTable.=0A= =0A= -02 12/08/99 Add docsQosServiceFlowStatsTable,=0A= docsQosUpstreamStatsTable,=0A= docsQosDynamicServiceStatsTable,=0A= docsQosServiceFlowLogTable=0A= -01 06/25/99 Complete rewrite based on -I01 draft=0A= -00 08/07/98 Initial draft posted for discussion.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 5]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= 1. Introduction=0A= =0A= This memo specifies a MIB module in a manner that is compliant to = the=0A= SNMP SMIv2[1][2][3]. The set of objects is consistent with the = SNMP=0A= framework and existing SNMP standards.=0A= =0A= This memo is a product of the IPCDN working group within the = Internet=0A= Engineering Task Force. Comments are solicited and should be=0A= addressed to the working group's mailing list at ipcdn@ietf.org=0A= and/or the author.=0A= =0A= =0A= 1.1 The Internet-Standard Management Framework=0A= =0A= For a detailed overview of the documents that describe the = current=0A= Internet-Standard Management Framework, please refer to section 7 = of=0A= RFC 3410 [12].=0A= =0A= Managed objects are accessed via a virtual information store, = termed=0A= the Management Information Base or MIB. MIB objects are = generally=0A= accessed through the Simple Network Management Protocol (SNMP).=0A= Objects in the MIB are defined using the mechanisms defined in = the=0A= Structure of Management Information (SMI). This memo specifies a = MIB=0A= module that is compliant to the SMIv2, which is described in STD = 58,=0A= RFC 2578 [1], STD 58, RFC 2579 [2] and STD 58, RFC 2580 [3].=0A= =0A= 1.2 Glossary=0A= =0A= =0A= =0A= Active QPS Active Qos Parameter Set. The set of QOS = parameters=0A= that describe the current level service provided to = a=0A= Service Flow.=0A= =0A= Active SF Active Service Flow. An SF with a non-empty Active=0A= QPS.=0A= =0A= Admitted QPS Admitted Qos Parameter Set. The set of QOS = parameters=0A= that describe a level of service which the Service=0A= Flow is not currently using, but which it is=0A= guaranteed to receive upon the SF's request to = make=0A= the set Active.=0A= =0A= Admitted SF A Service Flow with a non-empty Admitted QPS.=0A= =0A= CATV Cable TV=0A= =0A= CM Cable Modem, a modem connecting a subscriber's LAN = the=0A= CATF RF network. DOCSIS CMs operate as a MAC layer=0A= bridge between the home LAN and the RF network.=0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 6]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= CMTS Cable Modem Termination System, the "head-end" = device=0A= providing connectivity between the RF network and = the=0A= Internet.=0A= =0A= Downstream The direction from the head end towards the=0A= subscriber.=0A= =0A= DSA Dynamic Service Addition, a DOCSIS MAC management=0A= message requesting the dynamic creation of a new=0A= Service Flow. New SFs are created with a three-=0A= message exchange of a DSA-REQ, DSA-RSP, and = DSA-ACK.=0A= =0A= DSC Dynamic Service Change, a DOCSIS MAC management=0A= message requesting a change to the attributes of a=0A= Service Flow. SFs are changed with a = three-message=0A= exchange of a DSC-REQ, DSC-RSP, and DSC-ACK.=0A= =0A= DSD Dynamic Service Delete, a DOCSIS MAC management=0A= message requesting the deletion of a Service Flow. = SFs=0A= are deleted with a two-message exchange of a = DSD-REQ=0A= and DSD-ACK.=0A= =0A= Head-end The origination point in most cable systems of the=0A= subsriber video signals. It is generally also the=0A= location of the CMTS.=0A= =0A= PHS Payload Header Suppression, a feature of DOCSIS 1.1 = in=0A= which header bytes that are common in a sequence = of=0A= packets of a Service Flow are replaced by a = one-byte=0A= PHSI Index (PHSI) when transmitting the packet on = the=0A= RF network.=0A= =0A= Provisioned QPS A QOS Parameter Set describing an envelope of = service=0A= within which a Service Flow is authorized to = request=0A= admission. All existing service flows must have a=0A= non-empty Provisioned QPS, hence all SFs are=0A= considered to be "Provisioned".=0A= =0A= SCN Service Class Name -- a named set of QOS = parameters.=0A= A Service Flow may or may not be associated with a=0A= single named Service Class. A Service Class has as = an=0A= attribute a Qos Parameter Set that is used as the=0A= default set of values for all Service Flows = belonging=0A= to the Service Class.=0A= =0A= SID Service ID. A 16-bit integer assigned by the CMTS = for=0A= an Upstream Service Flow with a non-empty Active = QOS=0A= Parameter Set.=0A= =0A= SF Service Flow. A unidirectional stream of packets=0A= between the CM and CMTS. SFs are characterized as=0A= =0A= =0A= =0A= Expires July 2003 [Page 7]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= upstream or downstream. The SF is the fundamental=0A= unit of service provided on a DOCSIS CATV network.=0A= =0A= SFID Service Flow ID. A 32-bit unsigned integer = assigned=0A= by the CMTS to each Service Flows=0A= =0A= Upstream The direction from a subscriber CM to the head-end=0A= CMTS.=0A= =0A= =0A= =0A= =0A= 2. Overview=0A= =0A= This MIB provides a set of objects required for the management of=0A= DOCSIS 1.1 compliant Cable Modems (CM) and Cable Modem = Termination=0A= Systems (CMTS). The specification is derived from the DOCSIS 1.1=0A= Radio Frequency Interface specification [4]. Please note that = the=0A= referenced DOCSIS standard only requires Cable Modems to process = IPv4=0A= customer traffic. Design choices in this MIB reflect those=0A= requirements. Future versions of the DOCSIS standard are expected = to=0A= require support for IPv6 as well.=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this=0A= document are to be interpreted as described in [7].=0A= =0A= =0A= 2.1 Textual Conventions=0A= =0A= The textual convention "IfDirection" is defined to indicate the=0A= direction of a packet classifier relative to an interface. It = takes=0A= the values of either downstream(1) or upstream(2).=0A= =0A= The textual convention "BitRate" corresponds to the bits per = second=0A= as defined for QOS Parameter Sets in DOCSIS1.1. This definition=0A= includes all bits of the Ethernet MAC frame as transmitted on the = RF=0A= network, starting with the Destination Address and ending with = the=0A= Ethernet FCS. It does NOT includes bits in the DOCSIS MAC header.=0A= =0A= =0A= =0A= =0A= =0A= 2.2 MIB Organization=0A= =0A= =0A= The structure of the MIB is summarized below:=0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 8]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosMIB=0A= docsQosMIBObjects=0A= docsQosPktClassTable=0A= docsQosPktClassEntry=0A= docsQosPktClassId=0A= docsQosPktClassDirection=0A= docsQosPktClassPriority=0A= docsQosPktClassIpTosLow=0A= docsQosPktClassIpTosHigh=0A= docsQosPktClassIpTosMask=0A= docsQosPktClassIpProtocol=0A= docsQosPktClassIpSourceAddr=0A= docsQosPktClassIpSourceMask=0A= docsQosPktClassIpDestAddr=0A= docsQosPktClassIpDestMask=0A= docsQosPktClassSourcePortStart=0A= docsQosPktClassSourcePortEnd=0A= docsQosPktClassDestPortStart=0A= docsQosPktClassDestPortEnd=0A= docsQosPktClassDestMacAddr=0A= docsQosPktClassDestMacMask=0A= docsQosPktClassSourceMacAddr=0A= docsQosPktClassEnetProtocolType=0A= docsQosPktClassEnetProtocol=0A= docsQosPktClassUserPriApplies=0A= docsQosPktClassUserPriLow=0A= docsQosPktClassUserPriHigh=0A= docsQosPktClassVlanId=0A= docsQosPktClassState=0A= docsQosPktClassPkts=0A= docsQosPktClassBitMap=0A= docsQosPktClassInetSourceAddrType=0A= docsQosPktClassInetSourceAddr=0A= docsQosPktClassInetSourceMaskType=0A= docsQosPktClassInetSourceMask=0A= docsQosPktClassInetDestAddrType=0A= docsQosPktClassInetDestAddr=0A= docsQosPktClassInetDestMaskType=0A= docsQosPktClassInetDestMask=0A= docsQosPktClassHCPkts=0A= docsQosParamSetTable=0A= docsQosParamSetEntry=0A= docsQosParamSetServiceClassName=0A= docsQosParamSetPriority=0A= docsQosParamSetMaxTrafficRate=0A= docsQosParamSetMaxTrafficBurst=0A= docsQosParamSetMinReservedRate=0A= docsQosParamSetMinReservedPkt=0A= docsQosParamSetActiveTimeout=0A= docsQosParamSetAdmittedTimeout=0A= docsQosParamSetMaxConcatBurst=0A= =0A= =0A= =0A= Expires July 2003 [Page 9]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosParamSetSchedulingType=0A= docsQosParamSetNomPollInterval=0A= docsQosParamSetTolPollJitter=0A= docsQosParamSetUnsolicitGrantSize=0A= docsQosParamSetNomGrantInterval=0A= docsQosParamSetTolGrantJitter=0A= docsQosParamSetGrantsPerInterval=0A= docsQosParamSetTosAndMask=0A= docsQosParamSetTosOrMask=0A= docsQosParamSetMaxLatency=0A= docsQosParamSetType=0A= docsQosParamSetRequestPolicyOct=0A= docsQosParamSetBitMap=0A= docsQosServiceFlowTable=0A= docsQosServiceFlowEntry=0A= docsQosServiceFlowId=0A= docsQosServiceFlowProvisionedParamSetIndex=0A= docsQosServiceFlowAdmittedParamSetIndex=0A= docsQosServiceFlowActiveParamSetIndex=0A= docsQosServiceFlowSID=0A= docsQosServiceFlowDirection=0A= docsQosServiceFlowPrimary=0A= docsQosServiceFlowActiveTimeout=0A= docsQosServiceFlowAdmittedTimeout=0A= docsQosServiceFlowSchedulingType=0A= docsQosServiceFlowRequestPolicy=0A= docsQosServiceFlowTosAndMask=0A= docsQosServiceFlowTosOrMask=0A= docsQosServiceFlowStatsTable=0A= docsQosServiceFlowStatsEntry=0A= docsQosServiceFlowPkts=0A= docsQosServiceFlowOctets=0A= docsQosServiceFlowTimeCreated=0A= docsQosServiceFlowTimeActive=0A= docsQosServiceFlowPHSUnknowns=0A= docsQosServiceFlowPolicedDropPkts=0A= docsQosServiceFlowPolicedDelayPkts=0A= docsQosServiceFlowHCPkts=0A= docsQosServiceFlowHCOctets=0A= docsQosUpstreamStatsTable=0A= docsQosUpstreamStatsEntry=0A= docsQosSID=0A= docsQosUpstreamFragments=0A= docsQosUpstreamFragDiscards=0A= docsQosUpstreamConcatBursts=0A= docsQosDynamicServiceStatsTable=0A= docsQosDynamicServiceStatsEntry=0A= docsQosIfDirection=0A= docsQosDSAReqs=0A= docsQosDSARsps=0A= docsQosDSAAcks=0A= =0A= =0A= =0A= Expires July 2003 [Page 10]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosDSCReqs=0A= docsQosDSCRsps=0A= docsQosDSCAcks=0A= docsQosDSDReqs=0A= docsQosDSDRsps=0A= docsQosDynamicAdds=0A= docsQosDynamicAddFails=0A= docsQosDynamicChanges=0A= docsQosDynamicChangeFails=0A= docsQosDynamicDeletes=0A= docsQosDynamicDeleteFails=0A= docsQosDCCReqs=0A= docsQosDCCRsps=0A= docsQosDCCAcks=0A= docsQosDCCs=0A= docsQosDCCFails=0A= docsQosServiceFlowLogTable=0A= docsQosServiceFlowLogEntry=0A= docsQosServiceFlowLogIndex=0A= docsQosServiceFlowLogIfIndex=0A= docsQosServiceFlowLogSFID=0A= docsQosServiceFlowLogCmMac=0A= docsQosServiceFlowLogPkts=0A= docsQosServiceFlowLogOctets=0A= docsQosServiceFlowLogTimeDeleted=0A= docsQosServiceFlowLogTimeCreated=0A= docsQosServiceFlowLogTimeActive=0A= docsQosServiceFlowLogDirection=0A= docsQosServiceFlowLogPrimary=0A= docsQosServiceFlowLogServiceClassName=0A= docsQosServiceFlowLogPolicedDropPkts=0A= docsQosServiceFlowLogPolicedDelayPkts=0A= docsQosServiceFlowLogControl=0A= docsQosServiceFlowLogHCPkts=0A= docsQosServiceFlowLogHCOctets=0A= docsQosServiceClassTable=0A= docsQosServiceClassEntry=0A= docsQosServiceClassName=0A= docsQosServiceClassParamSetIndex=0A= docsQosServiceClassStatus=0A= docsQosServiceClassMaxTrafficRate=0A= docsQosServiceClassMaxTrafficBurst=0A= docsQosServiceClassMinReservedRate=0A= docsQosServiceClassMinReservedPkt=0A= docsQosServiceClassMaxConcatBurst=0A= docsQosServiceClassNomPollInterval=0A= docsQosServiceClassTolPollJitter=0A= docsQosServiceClassUnsolicitGrantSize=0A= docsQosServiceClassNomGrantInterval=0A= docsQosServiceClassTolGrantJitter=0A= docsQosServiceClassGrantsPerInterval=0A= =0A= =0A= =0A= Expires July 2003 [Page 11]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosServiceClassMaxLatency=0A= docsQosServiceClassActiveTimeout=0A= docsQosServiceClassAdmittedTimeout=0A= docsQosServiceClassSchedulingType=0A= docsQosServiceClassRequestPolicy=0A= docsQosServiceClassTosAndMask=0A= docsQosServiceClassTosOrMask=0A= docsQosServiceClassDirection=0A= docsQosServiceClassPolicyTable=0A= docsQosServiceClassPolicyEntry=0A= docsQosServiceClassPolicyIndex=0A= docsQosServiceClassPolicyName=0A= docsQosServiceClassPolicyRulePriority=0A= docsQosServiceClassPolicyStatus=0A= docsQosPHSTable=0A= docsQosPHSEntry=0A= docsQosPHSField=0A= docsQosPHSMask=0A= docsQosPHSSize=0A= docsQosPHSVerify=0A= docsQosPHSClassifierIndex=0A= docsQosPHSIndex=0A= docsQosCmtsMacToSrvFlowTable=0A= docsQosCmtsMacToSrvFlowEntry=0A= docsQosCmtsCmMac=0A= docsQosCmtsServiceFlowId=0A= docsQosCmtsIfIndex=0A= =0A= =0A= =0A= The MIB is organized as 11 tables. Most tables are implemented in=0A= both the CM and CMTS; the docsQosUpstreamStatsTable and=0A= docsQosServiceFlowLogTable are implemented on the CMTS only.=0A= =0A= =0A= 2.2.1 docsQosPktClassTable=0A= =0A= The docsQosPktClassTable reports the Service Flow Classifiers=0A= implemented by the managed device. The table is indexed by the = tuple=0A= { ifIndex, docsQosServiceFlowId, docsQosPktClassId }. The = ifIndex=0A= corresponds to an CATV MAC interface. Each CATV MAC interfaces has = a=0A= set of Service Flows, identified with a docsQosServiceFlowId = value=0A= that is unique for that interface. Each service flow may have a=0A= number of packet classifiers that map packets to the flow. The=0A= ClassifierId for the classifier is unique only within a = particular=0A= service flow.=0A= =0A= The semantics of packet classification are provided in [4]. = Briefly,=0A= the DOCSIS MAC interface calls for matching packets based on = values=0A= within the 802.2 (LLC), 802.3, IP, and/or UDP/TCP headers. = Packets=0A= which map more than one classifier are prioritized according to = their=0A= =0A= =0A= =0A= Expires July 2003 [Page 12]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosPktClassPriority value. The docsQosServiceFlowId (an index=0A= object) indicates to which service flow the packet is classified.=0A= =0A= The docsQosPktClassTable is distinct from the docsDevIpFilterTable = of=0A= [9] in that docsQosPktClassTable is intended only to reflect the=0A= state of the Service Flow Classifiers. Service Flow Classifiers = may=0A= be created only via a CM configuration file or from the Dynamic=0A= Service Addition (DSA) messages. For this reason,=0A= docsQosPktClassTable is read-only.=0A= =0A= The docsDevIpFilterTable is intended for external policy-based=0A= administration of packet classifiers. See the section = "Externally=0A= Administered Classification", below.=0A= =0A= =0A= 2.2.1.1 InetAddress Transition=0A= =0A= Earlier and widely implemented versions of the DOCS-QOS-MIB used = the=0A= IPv4-only "IpAddress" syntax for the four IP address object in = the=0A= docsQosPktClassTable. The MIB now requires the use of InetAddress=0A= syntax as per [11], which supports both IPv4 and IPv6 addresses. = The=0A= four objects that have the IpAddress syntax are deprecated in = favor=0A= of eight equivalent new objects, as shown by the following table:=0A= =0A= = +-----------------------------+-----------------------------------+=0A= | IpAddress | InetAddressType & InetAddress = |=0A= | syntax | syntax = |=0A= = +-----------------------------+-----------------------------------+=0A= | | docsQosPktClassInetSourceAddrType = |=0A= | docsQosPktClassIpSourceAddr | & = |=0A= | | docsQosPktClassInetSourceAddr = |=0A= = +-----------------------------+-----------------------------------+=0A= | | docsQosPktClassInetSourceMaskType = |=0A= | docsQosPktClassIpSourceMask | & = |=0A= | | docsQosPktClassInetSourceMask = |=0A= = +-----------------------------+-----------------------------------+=0A= | | docsQosPktClassInetDestAddrType = |=0A= | docsQosPktClassIpDestAddr | & = |=0A= | | docsQosPktClassInetDestAddr = |=0A= = +-----------------------------+-----------------------------------+=0A= | | docsQosPktClassInetDestMaskType = |=0A= | docsQosPktClassIpDestMask | & = |=0A= | | docsQosPktClassInetDestMask = |=0A= = +-----------------------------+-----------------------------------+=0A= =0A= Agents that choose to implement the deprecated IpAddress syntax=0A= objects MUST report values that match the values read from the=0A= corresponding InetAddress syntax objects with InetAddressType of=0A= ipv4(1). If future versions of the DOCSIS protocol permit the use = of=0A= IPv6 addresses for packet classifiers, the value read from the=0A= deprecated (IPv4-only) IpAddress syntax objects for an IPv6 = address=0A= =0A= =0A= =0A= Expires July 2003 [Page 13]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= shall be as if the referenced packet classifier parameter is not=0A= present.=0A= =0A= =0A= 2.2.2 docsQosParamSetTable=0A= =0A= The docsQosParamSetTable reports the values of Qos Parameter Set = as=0A= defined in Section C.2.2 of [4].=0A= =0A= In general, a Service Flow is associated with three different Qos=0A= Parameter Sets (QPSs): an "active" QPS, an "admitted" QPS, and a=0A= "provisioned" or "authorized" QPS. The relationship of these = three=0A= sets is represented below:=0A= =0A= =0A= =0A= =0A= =0A= +---------------------+=0A= | Provisioned |=0A= | |=0A= | +---------------+ |=0A= | | Admitted | |=0A= | | | |=0A= | | +---------+ | |=0A= | | | Active | | |=0A= | | | | | |=0A= | | +---------+ | |=0A= | | | |=0A= | +---------------+ |=0A= | |=0A= +---------------------+=0A= =0A= Figure 1: Qos Parameter Sets=0A= =0A= =0A= =0A= The Provisioned QPS describes the maximum service envelope for = which=0A= the SF is authorized. The Admitted QPS is the set of services for=0A= which a service flow has requested admission to the DOCSIS RF=0A= network, but which is not yet active. The Admitted QPS is used = during=0A= the two-phase process of IP Telephony service flow admission to = admit=0A= the bandwidth for a bidirectional voice call when the far end is=0A= ringing. Since ringing may occur for up to four minutes, this=0A= permits the bandwidth to be reserved but not actually consumed = during=0A= this interval. The Active QPS is the set of services actually = being=0A= used by the Service Flow. The DOCSIS v1.1 specification [4] = defines=0A= what it means for a QPS envelope to be "within" another. In = general,=0A= an inner QPS is considered to be "within" an outer QPS when all = QOS=0A= parameters represent demands of equal or fewer resources of the=0A= network.=0A= =0A= =0A= =0A= Expires July 2003 [Page 14]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= In addition to their use as attributes of a Service Flow, a QPS = is=0A= also an attribute of a Service Class. A DOCSIS CM configuration = file=0A= or DSA message may request the creation of a new SF and give only = the=0A= Service Class Name. The CMTS "expands the macro" of a Service = Class=0A= Name creation by populating the Provisioned, Admitted, and/or = Active=0A= QPSs of the Service Flow with the QPS of the Service Class Name. = All=0A= of the QPSs of a Service Flow must be expansions of the same = Service=0A= Class, and in this case the SF is said to "belong" to the Service=0A= Class. Changing the contents of a Service Class' QPS does not = affect=0A= the QPS of any Service Flow earlier expanded from that Service = Class=0A= name. Only the CMTS implements docsQosServiceClassTable.=0A= =0A= See [4] section 8 for a full description and the theory of = operation=0A= of Docsis 1.1 QOS operation.=0A= =0A= =0A= =0A= The docsQosParamSetTable sets are indexed by { ifIndex,=0A= docsQosServiceFlowId, docsQosParamSetType}. ifIndex indicates a=0A= particular "DOCSIS MAC Domain". docsQosServiceFlowId uniquely=0A= identifies a service flow on that MAC domain. The=0A= docsQosParamSetType indicates whether the row describes an = active,=0A= admitted, or provisioned Qos Parameter Set.=0A= =0A= The docsQosParamSetTable is read-only, because it indicates the = Qos=0A= Parameter Set contents as defined by DOCSIS signaling. The=0A= docsQosServiceClassTable is read-create to permit managers to = define=0A= a template of Qos Parameters that can be referenced by DOCSIS = modems=0A= when creating their Qos Parameter Sets.=0A= =0A= =0A= 2.2.2.1 Interoperation with DOCSIS 1.0=0A= =0A= The DOCSIS 1.0 DOCS-IF-MIB [10] specifies a docsIfQosProfileTable = to=0A= describe the set of Class Of Service (COS) parameters associated = with=0A= a COS "profile". The docsIfCmServiceTable, which contains one = entry=0A= per SID, references this table with a docsIfCmServiceQosProfile=0A= number.=0A= =0A= The DOCSIS 1.1 CM registration process allows a modem to register = as=0A= operating either with DOCSIS 1.0 or DOCSIS 1.1 functionality. = For=0A= ease of expression, we call a modem registering with DOCSIS 1.0=0A= functionality a "DOCSIS 1.0 modem", regardless of the modem's=0A= capabilities.=0A= =0A= A CMTS or CM supporting both DOCSIS 1.0 and DOCSIS 1.1 implements=0A= both the tables of [10] and the tables of this MIB. The=0A= interoperation goal is that before modem registration, the DOCSIS = 1.0=0A= MIB [10] applies. After registration, either the DOCSIS 1.0 or=0A= DOCSIS 1.1 MIB applies, depending on the mode with which the = modem=0A= registered. The specific interoperation rules are:=0A= =0A= =0A= =0A= Expires July 2003 [Page 15]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= 1. When a CM initially ranges, both the CM and CMTS implement = a=0A= row in DOCS-IF-MIB docsIfCmServiceTable corresponding to = the=0A= default upstream Service ID (SID) used for = pre-registration=0A= upstream traffic. For historical compatibility a row may be=0A= created for the docsIfQosProfileTable with default values,=0A= which may be referenced by the docsIfCmServiceTable = entries.=0A= =0A= =0A= 2. Both a CMTS and CM implementing this MIB MUST NOT implement=0A= docsQosParamSetTable or docsQosServiceFlowTable rows until=0A= after the CM registers with DOCSIS 1.1 modem operation.=0A= =0A= =0A= 3. When a modem registers with the CMTS as a "DOCSIS 1.1" = modem,=0A= any exclusively-referenced row in DOCS-IF-MIB=0A= docsQosProfileTable representing the modems upstream Qos=0A= profile for pre-registration traffic MUST be removed.=0A= Multiply-referenced rows may remain. The=0A= docsQosIfCmServiceQosProfile object in the CM's row of=0A= docsIfCmServiceTable MUST be set to zero. The=0A= docsIfCmServiceTable row for the DOCSIS 1.1 modem continues = to=0A= exist, and the various statistic objects in that row are=0A= incremented.=0A= =0A= =0A= 4. When a DOCSIS 1.1 modem registers, both the CMTS and CM=0A= represent all service flows described in the modem=0A= configuration file in docsQosParamSetTable and=0A= docsQosServiceFlowTable.=0A= =0A= =0A= 5. At the CMTS, the Docsis 1.0 MIB objects=0A= docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets for = a=0A= SID assigned to a Docsis 1.1 modem count only the pre-=0A= registration packets/bytes of those modems.=0A= =0A= =0A= 6. DOCSIS 1.0 modems do not have entries in the DOCS-QOS-MIB.=0A= =0A= =0A= =0A= 2.2.3 docsQosServiceFlowTable=0A= =0A= The docsQosServiceFlowTable provides read-only information about = all=0A= of the service flows known by the device. It is indexed by the=0A= combination of { ifIndex, dosQosServiceFlowId }, where ifIndex=0A= corresponds to a CATV MAC interface and docsQosServiceFlowId is = the=0A= 32- bit integer assigned by the CMTS controlling the MAC domain. = A=0A= CM typically has only a single CATV MAC interface, while a CMTS = may=0A= have several. See [10] for a description of the ifIndex = numbering=0A= for DOCSIS devices.=0A= =0A= =0A= =0A= Expires July 2003 [Page 16]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= The table indicates whether a given SF is in the upstream or=0A= downstream direction, and whether it is the "primary" SF in that=0A= direction. The primary SF carries traffic that is not otherwise=0A= classified to any other SF in that direction.=0A= =0A= =0A= 2.2.4 docsQosServiceFlowStatsTable=0A= =0A= The docsQosServiceFlowStatsTable provides statistics for all=0A= currently existing SFs known by the managed device. It provides=0A= basic packet and octet counters, as well as certain other = SF-specific=0A= stats such as the time at which the flow was created and how many=0A= seconds it has been active.=0A= =0A= The table also provides objects which can be used to fine-tune=0A= admission control decisions, namely the number of packets dropped = or=0A= delayed due to QOS policing decisions enforced by the managed = device.=0A= =0A= The model of the service flows stats table is that there exists a=0A= service flow Classification function followed by a service flow=0A= maximum rate Policing function for packets transmitted onto the=0A= Docsis RF network, as depicted below=0A= =0A= =0A= +----------+=0A= +------------+ clsfy 1 -----+ | Per-SF | = forwarded=0A= Pkts | |-----------> | | Maximum |---> for = Docsis=0A= ----->| Classify | clsfy 2 SF1 |--> | Rate | RF = Network=0A= | Function |-----------> | | Policing | = transmission=0A= | | -----+ | Function |=0A= | | | |----+=0A= | | | | |=0A= | | +----------+ = Dropped=0A= +------------+ | ^=0A= +----+ Delayed=0A= =0A= Packets intended for transmission onto the Docsis RF network=0A= (upstream or downstream) are first classified to a service flow = by=0A= matching one of several possible classifiers associated with that=0A= service flow. The docsQosPktClassPkts count includes the number = of=0A= packets that match the classifier, regardless of the eventual=0A= disposition of the packet.=0A= =0A= DOCSIS requires that each service flow be policed to maintain a=0A= maximum rate of transmission. This is performed by either dropping = or=0A= delaying a packet on that service flow. The=0A= docsQosServiceFlowPolicedDropPkts object counts the number of = service=0A= flow packets dropped by the policing function. The=0A= docsQosServiceFlowPolicedDelayPkts counts the number of packet=0A= delayed but still forwarded. The docsQosServiceFlowPkts object=0A= counts the total number of packets forwarded beyond the policing=0A= =0A= =0A= =0A= Expires July 2003 [Page 17]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= function intended for eventual transmission onto the DOCSIS RF=0A= network. Although packets may be latter dropped by other = functions=0A= (e.g. a transmit queue overflow on a DOCSIS hardware = transmitter),=0A= the docsQos MIB per service-flow counters are not affected in = this=0A= case.=0A= =0A= =0A= 2.2.5 docsQosUpstreamStatsTable=0A= =0A= This table provides statistics that are measured only at the CMTS = in=0A= the upstream direction. These include a count of the number of=0A= fragmentation headers received, fragments discarded, and the = number=0A= of concatenation headers received.=0A= =0A= =0A= 2.2.6 docsQosDynamicServiceStatsTable=0A= =0A= This table provides read-only stats on the operation of the = Dynamic=0A= Service state machines as specified in section 9.4 of [4]. It=0A= provides a set of 14 counters *in each direction* for a Docsis = MAC=0A= layer interface. That is, each Docsis MAC layer interface has one = row=0A= for downstream stats, and a second row for upstream stats.=0A= =0A= Eight of the counters are DSx packet type counts, one counter for=0A= each of the eight DSx packet types. For example, the = docsQosDSAReqs=0A= object in the upstream row at the CMTS counts the number of = DSA-REQ=0A= messages received by the CMTS from that interface. The=0A= docsQosDSAReqs object in the downstream row at the CMTS counts = the=0A= number of DSA-REQ messages transmitted by the CMTS on that = interface.=0A= =0A= The remaining six counters per (interface, direction) combination=0A= count the number of successful and unsuccessful *transactions* = that=0A= were initiated on the interface and direction. For example, the=0A= upstream docsQosDynamicAdds on a CMTS is the number of = successfully=0A= completed CM-initiated dynamic additions, because at the CMTS a = CM-=0A= initiated DSA starts in the upstream direction. The downstream=0A= docsQosDynamicAdds at a CMTS is the number of successful CMTS-=0A= initiated DSA transactions.=0A= =0A= Dynamic service transactions can fail for a number of reasons, as=0A= listed in the state machines of section 9.4. Rather than include=0A= still more counters for each different failure reason, they are=0A= grouped into a single count, e.g docsQosDynamicAddFails. Again, = this=0A= object exists in both directions, so that locally originated vs=0A= remotely originated transaction failures are counted separately.=0A= Further troubleshooting of transaction failures will require = vendor-=0A= specific queries and operation.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 18]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= 2.2.7 docsQosServiceFlowLogTable=0A= =0A= This table contains a log of the Service Flows no longer existing = in=0A= the docsQosServiceFlowTable. It is intended to be periodically = polled=0A= by traffic monitoring and billing agents. It is implemented only = at=0A= the CMTS.=0A= =0A= It contains a chronological log of SF session statistics, including = a=0A= total count of packets and octets transferred on the SF. It = includes=0A= time stamps of the SF creation and deletion time, as well as its=0A= number of active seconds. The active second count is the count of=0A= seconds that the SF had a non-empty Active Qos Parameter Set, i.e. = it=0A= was eligible to pass data. For unicast SFs, it includes the CM = MAC=0A= address associated with the flow for billing reference purposes.=0A= =0A= The maximum number of log records kept by a CMTS, and the = duration=0A= that a log record is maintained in the table is vendor-specific. = An=0A= explicit control object is provided so that the monitoring=0A= application can explicitly delete records it has read.=0A= =0A= =0A= 2.2.8 docsQosServiceClassTable=0A= =0A= This table defines the Service Class Name and references a Qos=0A= Parameter Set for each Service Class defined in a CMTS. It is=0A= indexed by the Service Class Name string itself. The table is = read-=0A= create on a CMTS, and is not implemented in a CM. Each entry of = the=0A= docsQosServiceClassTable should define a template for flows in a=0A= given direction (upstream or downstream). Some parameters of the=0A= docsQosServiceClassTable are specific to a particular direction, = and=0A= so their values are not-applicable when used as a template for = flows=0A= in the other direction.=0A= =0A= =0A= =0A= 2.2.9 docsQosServiceClassPolicyTable=0A= =0A= =0A= The docsQosServiceClassPolicyTable can be referenced by the=0A= docsDevFilterPolicyTable of [9] in order to have a "policy" that=0A= classifies packets to a named Service Class. This is one mechanism = by=0A= which "external" entities (like an SNMP manager) may control the=0A= classification of packet for QOS purposes. Entries are indexed by = a=0A= small integer docsQosServiceClassPolicyIndex. They provide a = Service=0A= Class Name and a Rule Priority. A policy referencing a row of = this=0A= table intends the packet to be forwarded on a Service Flow=0A= "belonging" to the named Service Class. See the section = "Externally=0A= Administered Classification", below.=0A= =0A= This table is implemented on both the CM and CMTS, and is = read-create=0A= on both.=0A= =0A= =0A= =0A= Expires July 2003 [Page 19]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= 2.2.10 docsQosPHSTable=0A= =0A= The Payload Header Suppression (PHS) feature of DOCSIS 1.1 = permits=0A= packets to replace the unchanging bytes of the Ethernet, IP, and = UDP=0A= headers with a one-byte index when transmitting on the cable = network.=0A= This is especially useful for IP Telephony packets, where such=0A= suppression can result in almost twice the number of calls = supported=0A= within the same upstream channel.=0A= =0A= Each entry of the table corresponds to a PHS Rule as described in=0A= section 8.4 of [4]. The rules are identified by their = corresponding=0A= service flow ID and docsQosPktClassId. A PHS rule is associated = with=0A= exactly one classifier. The table is therefore indexed by the = tuple=0A= { ifIndex, docsQosServiceFlowId, docsQosPktClassId}.=0A= =0A= This table is read-only, and MUST be implemented on both the CM = and=0A= CMTS when PHS is supported.=0A= =0A= =0A= 2.2.11 docsQosCmtsMacToSrvFlowTable=0A= =0A= The docsQosCmtsMacToSrvFlowTable provides describes the mapping of = CM=0A= mac addresses to the Service Flow Ids that are uniquely = identified=0A= with that CM. External applications may collect statistics on = all=0A= packets flowing through a CM by determining the SFID of all of = its=0A= flows, and then collecting the statistics of packets and bytes = for=0A= each flow.=0A= =0A= Downstream multicast service flows are not indicated in the=0A= docsQosCmtsMacToSrvFlowTable because they are not associated with=0A= only one CM.=0A= =0A= =0A= =0A= =0A= 3. Externally Administered Classification=0A= =0A= Docsis 1.1 provides rich semantics for the classification of = packets=0A= to service flows with it Service Flow Classifier table. Service = Flow=0A= Classifiers may be created statically in the DOCSIS CM = configuration=0A= file, or may be created dynamically with Dynamic Service Addition=0A= (DSA) and Dynamic Service Change (DSC) DOCSIS MAC messages.=0A= =0A= Several major issues arose with the concept of externally=0A= administered classification, i.e. should an external SNMP manager = be=0A= permitted to create classification rows? One problem was the co-=0A= ordination of classifier IDs, since such an approach would = require=0A= either separate classifier ID number spaces or objects to = co-ordinate=0A= both internal and external classifier ID assignments. A more = serious=0A= problem, however, was the requirement that external creation of = SF=0A= Classifiers would require "knowledge" of the individual Service = Flow=0A= =0A= =0A= =0A= Expires July 2003 [Page 20]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= ID for service flows by external applications. It was strongly = felt=0A= by the committee that SFIDs should remain an internal Docsis = object,=0A= and not be transmitted as part of protocol flows, e.g. for IP = packet=0A= telephony signaling. Docsis 1.1 introduced the concept of named=0A= Service Classes for ease of administration within a domain of CMs = and=0A= CMTSs. What was desired was to permit external classification of=0A= packets to a Service Class, not a particular Service Flow.=0A= =0A= The DOCSIS committee therefore decided to use the already-defined = IP=0A= Packet Filter Table [9] for the external classification of = packets=0A= for QOS purposes. The docsDevIpPacketFilterTable defines similar=0A= packet matching criteria as docsQosPktClassTable, but it matches = a=0A= packet to an arbitrary "policy set" instead of a particular = Service=0A= Flow. One of the policies in the policy set then selects the = Service=0A= Class of the SF on which to forward the packet. The=0A= docsQosServiceClassPolicyTable of this MIB defines the Service = Class=0A= Name to which a packet is classified.=0A= =0A= The interaction of external and internal packet classification is=0A= depicted below.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 21]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= =0A= =0A= |=0A= | Outbound Pkt=0A= V=0A= docsDevIpFilterTable------> docsDevFilterPolicyTable=0A= | |=0A= | V=0A= | docsQosServiceClassPolicyTable=0A= | |=0A= | Pkt | ServiceClassName,=0A= | | = ServiceClassPolicyRulePriority=0A= V V=0A= +--------------------------------------------------------+=0A= | | DOCSIS MAC LAYER ENTITY | |=0A= | | | Select any |=0A= | V | SFID Y in SCN|=0A= | docsQosPktClassTable <---------------| |=0A= | | | |=0A= | | docsQosPktClassPriority, | |=0A= | | SFID X | |=0A= | V V |=0A= | ----------------------------------------+ |=0A= | | Select the SFID associated with the | |=0A= | | higher of docsQosPktClassPriority or | |=0A= | | docsQosServiceClassPolicyRulePriority | |=0A= | +---------------------------------------+ |=0A= | | |=0A= | V |=0A= | | | | | |=0A= | | | ... | | Service Flows |=0A= | +----+ +----+ |=0A= | SFID X SFID Y |=0A= +--------------------------------------------------------+=0A= =0A= Figure 2: Docsis Packet Classification=0A= =0A= =0A= The processing of an outgoing packet proceeds as follows:=0A= =0A= 1. The packet is first checked for matches with rows of = the=0A= docsDevIpFilterTable. If it matches, the matching row=0A= provides a docsDevFilterPolicyId integer.=0A= =0A= 2. The docsDevFilterPolicyId indexes into one (or more) = rows=0A= of docsDevFilterPolicyTable. Each row provides an=0A= arbitrary RowPointer (docsDevFilterPolicyPtr),=0A= corresponding to a policy to be applied to the packet.=0A= =0A= 3. This MIB defines a docsQosServiceClassPolicyTable = whose=0A= entries may be pointed to by docsDevFilterPolicyPtr in=0A= =0A= =0A= =0A= Expires July 2003 [Page 22]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= order to administratively classify packets to a named=0A= DOCSIS Service Class. The = docsQosServiceClassPolicyEntry=0A= provides a Service Class Name (SCN) as=0A= docsQosServiceClassPolicyName and a classification = rule=0A= priority as docsQosServiceClassPolicyRulePriority. = These=0A= are submitted to the device's Docsis MAC Layer entity as = a=0A= special form of the MAC_DATA.request primitive, as=0A= described in Section E.2.1 of [4].=0A= =0A= 4. The MAC Layer selects an SFID ("Y") of an active = Service=0A= Flow belonging to the named class, choosing an SF=0A= arbitrarily if there is more than one.=0A= =0A= 5. The packet is then classified according to the=0A= docsQosPktClassTable, which may classify the packet to = a=0A= different SFID "X". Associated with the classifier is = a=0A= docsQosPktClassPriority.=0A= =0A= 6. In the event of a conflict between the SCN-determined = SFID=0A= and the classified SFID, the greater of=0A= docsQosPktClassPriority and=0A= docsQosServiceClassPolicyRulePriority determines which=0A= SFID is selected to forward the packet.=0A= =0A= A packet which does not match a = docsQosServiceClassPolicyEntry=0A= is directly submitted to the Docsis MAC layer, where the=0A= docsQosPktClassTable selects the SID on which it is to be=0A= forwarded.=0A= =0A= By convention (in [4]), the "internal" = docsQosPktClassPriority=0A= values should be in the range of 64-191, while the = "external"=0A= priorities may be either in the range 192-255 to override = the=0A= internal classification or the range 0-63 to be overridden = by=0A= internal classification.=0A= =0A= This classification mechanism applies both upstream from the = CM=0A= and downstream from the CMTS.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 23]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= 4. Definitions=0A= =0A= --=0A= -- Docsis QOS Extensions MIB=0A= --=0A= =0A= DOCS-QOS-MIB DEFINITIONS ::=3D BEGIN=0A= =0A= IMPORTS=0A= MODULE-IDENTITY,=0A= OBJECT-TYPE,=0A= Integer32,=0A= Counter32,=0A= IpAddress,=0A= Unsigned32,=0A= Counter64=0A= FROM SNMPv2-SMI=0A= =0A= TEXTUAL-CONVENTION,=0A= MacAddress,=0A= RowStatus,=0A= TruthValue,=0A= DisplayString,=0A= TimeStamp=0A= FROM SNMPv2-TC=0A= =0A= OBJECT-GROUP,=0A= MODULE-COMPLIANCE=0A= FROM SNMPv2-CONF=0A= =0A= ifIndex,=0A= InterfaceIndex=0A= FROM IF-MIB=0A= =0A= docsIfMib=0A= FROM DOCS-IF-MIB=0A= =0A= InetAddressType,=0A= InetAddress=0A= FROM INET-ADDRESS-MIB;=0A= =0A= docsQosMIB MODULE-IDENTITY=0A= LAST-UPDATED "200301010000Z" -- January 1, 2003=0A= ORGANIZATION "IETF IPCDN Working Group"=0A= CONTACT-INFO=0A= "=0A= Co-Author: Michael Patrick=0A= Postal: Motorola BCS=0A= 20 Cabot Blvd, MS M2-330=0A= Mansfield, MA 02048-1193=0A= U.S.A.=0A= =0A= =0A= =0A= Expires July 2003 [Page 24]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= Phone: +1 508 851 8402=0A= E-mail: michael.patrick@motorola.com=0A= =0A= Co-Author: William Murwin=0A= Postal: Motorola BCS=0A= 20 Cabot Blvd, MS M2-330=0A= Mansfield, MA 02048-1193=0A= U.S.A.=0A= Phone: +1 508 851 8385=0A= E-mail: w.murwin@motorola.com"=0A= =0A= DESCRIPTION=0A= "This is the management information for=0A= Quality Of Service (QOS) for DOCSIS 1.1."=0A= =0A= REVISION "200301010000Z" -- January 1, 2003=0A= DESCRIPTION=0A= "Published as draft-ietf-ipcdn-qos-mib-07.txt.=0A= =0A= Changes from qos-mib-06 include:=0A= =0A= - Clarified the description for docsQosPktClassPkts.=0A= - Clarified the description for docsQosServiceFlowOctets.=0A= - Clarified the description for docsQosServiceFlowPkts.=0A= - Clarified the operation of the docsQosServiceClassStatus=0A= and the docsQosServiceClassPolicyStatus objects.=0A= - Added five new 64-bit counter objects.=0A= - Changed the description of the reported default values for = the=0A= docsQosParamSetMaxTrafficBurst and = docsQosParamSetMaxConcatBurst.=0A= - Changed the default values for the = docsQosServiceClassMaxTrafficBurst.=0A= and docsQosServiceClassMaxConcatBurst objects.=0A= - Changed references to the latest Data-Over-Cable=0A= Service Interface Specifications: Radio Frequency=0A= Interface Specification."=0A= REVISION "200111090000Z" -- November 9, 2001=0A= DESCRIPTION=0A= "Published as draft-ietf-ipcdn-qos-mib-06.txt.=0A= =0A= Changes from qos-mib-05 include:=0A= -Deprecated objects that were of type IpAddress=0A= and added new objects that were of type=0A= InetAddressType and InetAddress, to support both=0A= IPv4 and IPv6 in the docsQosPktClassTable.=0A= -Clarified the default value of the=0A= docsQosPktClassIpDestMask and=0A= docsQosPktClassIpSourceMask.=0A= -Corrected the description of the individual bits=0A= that make up the docsQosParamsSetRequestPolicyOct.=0A= -Corrected the spelling of docsCableMaclayer in the=0A= description of the docsQosServiceFlowLogIfIndex.=0A= -Clarified that some of counters from the=0A= =0A= =0A= =0A= Expires July 2003 [Page 25]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosDynamicServiceStatsTable, include retries.=0A= -Changed references to the latest Data-Over-Cable=0A= Service Interface Specifications: Radio Frequency=0A= Interface Specification.=0A= -Added objects that were removed from earlier=0A= revisions of the mib, as obsolete.=0A= -Clarified the Cable Modem's implementation of the=0A= docsQosParamSetTosAndMask.=0A= -Change the description of objects within the=0A= docsQosServiceClassTable, so that they were no longer=0A= templates for obsolete objects."=0A= REVISION "200103010000Z" -- March 1, 2001=0A= DESCRIPTION=0A= "Published as draft-ietf-ipcdn-qos-mib-05.txt.=0A= =0A= Changes from qos-mib-04 include:=0A= - Changed default value of docsQosPktClassIpSourceMask and=0A= docsQosPktClassIpDestMask to 255.255.255.255. This is the=0A= only functional change of the revision.=0A= - Clarified description of dosQosServiceFlowPkts to avoid=0A= requiring CMs to classify downstream packets.=0A= - Clarified that docsQosServiceFlowPHSUnknowns only applies = to=0A= received packets.=0A= - Clarified that docsQosPktClassBitMap and = docsQosParamSetBitMap=0A= indicate all parameters for both adds and changes."=0A= ::=3D { docsIfMib 7 } -- BPIPlus mib is docsIfMIb = 6=0A= =0A= docsQosMIBObjects OBJECT IDENTIFIER ::=3D { docsQosMIB 1 }=0A= =0A= -- Textual Conventions=0A= IfDirection ::=3D TEXTUAL-CONVENTION=0A= STATUS current=0A= DESCRIPTION "Indicates a direction on an RF MAC interface.=0A= =0A= The value downstream(1) is from Cable Modem=0A= Termination System to Cable Modem.=0A= =0A= The value upstream(2) is from Cable Modem to=0A= Cable Modem Termination System."=0A= SYNTAX INTEGER {=0A= downstream(1),=0A= upstream(2)=0A= }=0A= =0A= BitRate ::=3D TEXTUAL-CONVENTION=0A= DISPLAY-HINT "d"=0A= STATUS current=0A= DESCRIPTION "The rate of traffic in unit of bits per second.=0A= Used to specify traffic rate for QOS."=0A= SYNTAX Unsigned32=0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 26]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= SchedulingType ::=3D TEXTUAL-CONVENTION=0A= STATUS current=0A= DESCRIPTION "The scheduling service provided by a CMTS for = an=0A= upstream service flow. If the parameter is = omitted=0A= from an upstream QOS Parameter Set, this object = takes=0A= the value of bestEffort (2). This parameter must = be=0A= reported as undefined (1) for downstream QOS = Parameter=0A= Sets."=0A= SYNTAX INTEGER {=0A= undefined (1),=0A= bestEffort (2),=0A= nonRealTimePollingService(3),=0A= realTimePollingService(4),=0A= unsolictedGrantServiceWithAD(5),=0A= unsolictedGrantService(6)=0A= }=0A= =0A= -----------------------------------------------------------------------=0A= --=0A= -- Packet Classifier Table=0A= --=0A= docsQosPktClassTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosPktClassEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes the packet classification=0A= configured on the CM or CMTS.=0A= The model is that a packet either received=0A= as input from an interface or transmitted=0A= for output on an interface may be compared=0A= against an ordered list of rules pertaining to=0A= the packet contents. Each rule is a row of this=0A= table. A matching rule provides a service flow=0A= id to to which the packet is classified.=0A= All rules need to match for a packet to match=0A= a classifier.=0A= =0A= The objects in this row correspond to a set of=0A= Classifier Encoding parameters in a DOCSIS=0A= MAC management message. The = docsQosPktClassBitMap=0A= indicates which particular parameters were = present=0A= in the classifier as signaled in the DOCSIS = message.=0A= If the referenced parameter was not present=0A= in the signaled DOCSIS 1.1 Classifier, the=0A= corresponding object in this row reports a=0A= value as specified in the DESCRIPTION section.=0A= "=0A= ::=3D { docsQosMIBObjects 1 }=0A= =0A= =0A= docsQosPktClassEntry OBJECT-TYPE=0A= =0A= =0A= =0A= Expires July 2003 [Page 27]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= SYNTAX DocsQosPktClassEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "An entry in this table provides a single packet=0A= classifier rule. The index ifIndex is an ifType=0A= of docsCableMaclayer(127)."=0A= INDEX {=0A= ifIndex,=0A= docsQosServiceFlowId,=0A= docsQosPktClassId=0A= }=0A= ::=3D { docsQosPktClassTable 1 }=0A= =0A= =0A= =0A= DocsQosPktClassEntry ::=3D SEQUENCE {=0A= docsQosPktClassId Integer32,=0A= docsQosPktClassDirection IfDirection,=0A= docsQosPktClassPriority Integer32,=0A= docsQosPktClassIpTosLow OCTET STRING,=0A= docsQosPktClassIpTosHigh OCTET STRING,=0A= docsQosPktClassIpTosMask OCTET STRING,=0A= docsQosPktClassIpProtocol Integer32,=0A= docsQosPktClassIpSourceAddr IpAddress,=0A= docsQosPktClassIpSourceMask IpAddress,=0A= docsQosPktClassIpDestAddr IpAddress,=0A= docsQosPktClassIpDestMask IpAddress,=0A= docsQosPktClassSourcePortStart Integer32,=0A= docsQosPktClassSourcePortEnd Integer32,=0A= docsQosPktClassDestPortStart Integer32,=0A= docsQosPktClassDestPortEnd Integer32,=0A= docsQosPktClassDestMacAddr MacAddress,=0A= docsQosPktClassDestMacMask MacAddress,=0A= docsQosPktClassSourceMacAddr MacAddress,=0A= docsQosPktClassEnetProtocolType INTEGER,=0A= docsQosPktClassEnetProtocol Integer32,=0A= docsQosPktClassUserPriApplies TruthValue,=0A= docsQosPktClassUserPriLow Integer32,=0A= docsQosPktClassUserPriHigh Integer32,=0A= docsQosPktClassVlanId Integer32,=0A= docsQosPktClassState INTEGER,=0A= docsQosPktClassPkts Counter32,=0A= docsQosPktClassBitMap BITS,=0A= docsQosPktClassInetSourceAddrType InetAddressType,=0A= docsQosPktClassInetSourceAddr InetAddress,=0A= docsQosPktClassInetSourceMaskType InetAddressType,=0A= docsQosPktClassInetSourceMask InetAddress,=0A= docsQosPktClassInetDestAddrType InetAddressType,=0A= docsQosPktClassInetDestAddr InetAddress,=0A= docsQosPktClassInetDestMaskType InetAddressType,=0A= docsQosPktClassInetDestMask InetAddress,=0A= =0A= =0A= =0A= Expires July 2003 [Page 28]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosPktClassHCPkts Counter64=0A= }=0A= =0A= docsQosPktClassId OBJECT-TYPE=0A= SYNTAX Integer32 (1..65535)=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Index assigned to packet classifier entry by=0A= the CMTS which is unique per service flow."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.3.2"=0A= ::=3D { docsQosPktClassEntry 1 }=0A= =0A= docsQosPktClassDirection OBJECT-TYPE=0A= SYNTAX IfDirection=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Indicates the direction to which the classifier=0A= is applied."=0A= ::=3D { docsQosPktClassEntry 2 }=0A= =0A= docsQosPktClassPriority OBJECT-TYPE=0A= SYNTAX Integer32 (0..255)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The value specifies the order of evaluation=0A= of the classifiers.=0A= The higher the value the higher the priority.=0A= The value of 0 is used as default in=0A= provisioned service flows classifiers.=0A= The default value of 64 is used for dynamic=0A= service flow classifiers.=0A= If the referenced parameter is not present=0A= in a classifier, this object reports the default = value=0A= as defined above."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.3.5"=0A= ::=3D { docsQosPktClassEntry 3 }=0A= =0A= docsQosPktClassIpTosLow OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The low value of a range of TOS byte values.=0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 0."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.1"=0A= ::=3D { docsQosPktClassEntry 4 }=0A= =0A= docsQosPktClassIpTosHigh OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= =0A= =0A= =0A= Expires July 2003 [Page 29]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= DESCRIPTION "The 8-bit high value of a range of TOS byte=0A= values.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 0."=0A= REFERENCE "SP-RFIv1.1-I07-010829, Appendix C.2.1.5.1"=0A= ::=3D { docsQosPktClassEntry 5 }=0A= =0A= docsQosPktClassIpTosMask OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The mask value is bitwise ANDed with TOS byte=0A= in an IP packet and this value is used check=0A= range checking of TosLow and TosHigh.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 0."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.1"=0A= ::=3D { docsQosPktClassEntry 6 }=0A= =0A= docsQosPktClassIpProtocol OBJECT-TYPE=0A= SYNTAX Integer32 (0..258)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object indicates the value of the IP=0A= Protocol field required for IP packets to match=0A= this rule.=0A= =0A= The value 256 matches traffic with any IP = Protocol=0A= value. The value 257 by convention matches both = TCP=0A= and UDP.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 258."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.2"=0A= ::=3D { docsQosPktClassEntry 7 }=0A= =0A= docsQosPktClassIpSourceAddr OBJECT-TYPE=0A= SYNTAX IpAddress=0A= MAX-ACCESS read-only=0A= STATUS deprecated=0A= DESCRIPTION "This object is deprecated in favor of the=0A= object pair docsQosPktClassInetSourceAddrType=0A= and docsQosPktClassInetSourceAddr. Agents that=0A= choose to implement this object MUST report=0A= an address that matches = docsQosPktClassInetSourceAddr=0A= object as long as = docsQosPktClassInetSourceAddrType is=0A= ipv4(1). Otherwise, the value of this object shall = be=0A= 0.0.0.0."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.3"=0A= =0A= =0A= =0A= Expires July 2003 [Page 30]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= ::=3D { docsQosPktClassEntry 8 }=0A= =0A= docsQosPktClassIpSourceMask OBJECT-TYPE=0A= SYNTAX IpAddress=0A= MAX-ACCESS read-only=0A= STATUS deprecated=0A= DESCRIPTION "This object is deprecated in favor of the=0A= object pair docsQosPktClassInetSourceMaskType=0A= and docsQosPktClassInetSourceMask. Agents that=0A= choose to implement this object MUST report=0A= an address that matches = docsQosPktClassInetSourceMask=0A= object as long as = docsQosPktClassInetSourceMaskType is=0A= ipv4(1). Otherwise, the value of this object shall = be=0A= 255.255.255.255.=0A= =0A= SNMP mangers should note that agent = implementation=0A= of previous versions of this MIB report 0.0.0.0 as = the=0A= value when the reference parameter is not = present,=0A= rather than 255.255.255.255."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.4"=0A= ::=3D { docsQosPktClassEntry 9 }=0A= =0A= =0A= docsQosPktClassIpDestAddr OBJECT-TYPE=0A= SYNTAX IpAddress=0A= MAX-ACCESS read-only=0A= STATUS deprecated=0A= DESCRIPTION "This object is deprecated in favor of the=0A= object pair docsQosPktClassInetDestAddrType=0A= and docsQosPktClassInetDestAddr. Agents that=0A= choose to implement this object MUST report=0A= an address that matches = docsQosPktClassInetDestAddr=0A= object as long as docsQosPktClassInetDestAddrType = is=0A= ipv4(1). Otherwise, the value of this object shall = be=0A= 0.0.0.0."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.5"=0A= ::=3D { docsQosPktClassEntry 10 }=0A= =0A= docsQosPktClassIpDestMask OBJECT-TYPE=0A= SYNTAX IpAddress=0A= MAX-ACCESS read-only=0A= STATUS deprecated=0A= DESCRIPTION "This object is deprecated in favor of the=0A= object pair docsQosPktClassInetDestMaskType=0A= and docsQosPktClassInetDestMask. Agents that=0A= choose to implement this object MUST report=0A= an address that matches = docsQosPktClassInetDestMask=0A= object as long as docsQosPktClassInetDestMaskType = is=0A= ipv4(1). Otherwise, the value of this object shall = be=0A= 255.255.255.255.=0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 31]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= SNMP mangers should note that agent = implementation=0A= of previous versions of this MIB report 0.0.0.0 as = the=0A= value when the reference parameter is not = present,=0A= rather than 255.255.255.255."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.6"=0A= ::=3D { docsQosPktClassEntry 11}=0A= =0A= docsQosPktClassSourcePortStart OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies the low end inclusive=0A= range of TCP/UDP source port numbers to which=0A= a packet is compared. This object is irrelevant=0A= for non-TCP/UDP IP packets.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 0."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.7"=0A= ::=3D { docsQosPktClassEntry 12 }=0A= =0A= docsQosPktClassSourcePortEnd OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies the high end inclusive=0A= range of TCP/UDP source port numbers to which=0A= a packet is compared. This object is irrelevant=0A= for non-TCP/UDP IP packets.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= 65535."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.8"=0A= ::=3D { docsQosPktClassEntry 13 }=0A= =0A= docsQosPktClassDestPortStart OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies the low end inclusive=0A= range of TCP/UDP destination port numbers to=0A= which a packet is compared.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 0."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.9"=0A= ::=3D { docsQosPktClassEntry 14 }=0A= =0A= docsQosPktClassDestPortEnd OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= =0A= =0A= =0A= Expires July 2003 [Page 32]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies the high end inclusive=0A= range of TCP/UDP destination port numbers to = which=0A= a packet is compared.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= 65535."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.10"=0A= ::=3D { docsQosPktClassEntry 15 }=0A= =0A= docsQosPktClassDestMacAddr OBJECT-TYPE=0A= SYNTAX MacAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "An Ethernet packet matches an entry when its=0A= destination MAC address bitwise ANDed with=0A= docsQosPktClassDestMacMask equals the value of=0A= docsQosPktClassDestMacAddr.=0A= =0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= '000000000000'H.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.1"=0A= ::=3D { docsQosPktClassEntry 16 }=0A= =0A= docsQosPktClassDestMacMask OBJECT-TYPE=0A= SYNTAX MacAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "An Ethernet packet matches an entry when its=0A= destination MAC address bitwise ANDed with=0A= docsQosPktClassDestMacMask equals the value of=0A= docsQosPktClassDestMacAddr.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= '000000000000'H.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.1"=0A= ::=3D { docsQosPktClassEntry 17 }=0A= =0A= docsQosPktClassSourceMacAddr OBJECT-TYPE=0A= SYNTAX MacAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "An Ethernet packet matches this entry when its=0A= source MAC address equals the value of=0A= =0A= =0A= =0A= Expires July 2003 [Page 33]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= this object.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= 'FFFFFFFFFFFF'H.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.2"=0A= ::=3D { docsQosPktClassEntry 18 }=0A= =0A= docsQosPktClassEnetProtocolType OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= none(0),=0A= ethertype(1),=0A= dsap(2),=0A= mac(3),=0A= all(4)=0A= }=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object indicates the format of the layer 3=0A= protocol id in the Ethernet packet. A value of=0A= none(0) means that the rule does not use the=0A= layer 3 protocol type as a matching criteria.=0A= =0A= A value of ethertype(1) means that the rule=0A= applies only to frames which contains an=0A= EtherType value. Ethertype values are contained=0A= in packets using the Dec-Intel-Xerox (DIX)=0A= encapsulation or the RFC1042 Sub-Network Access=0A= Protocol (SNAP) encapsulation formats.=0A= =0A= A value of dsap(2) means that the rule applies=0A= only to frames using the IEEE802.3=0A= encapsulation format with a Destination Service=0A= Access Point (DSAP) other=0A= than 0xAA (which is reserved for SNAP).=0A= =0A= A value of mac(3) means that the rule applies=0A= only to MAC management messages for MAC = management=0A= messages.=0A= =0A= A value of all(4) means that the rule matches=0A= all Ethernet packets.=0A= =0A= If the Ethernet frame contains an 802.1P/Q Tag=0A= header (i.e. EtherType 0x8100), this object=0A= applies to the embedded EtherType field within=0A= the 802.1P/Q header.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 0.=0A= =0A= =0A= =0A= Expires July 2003 [Page 34]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= =0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.3"=0A= ::=3D { docsQosPktClassEntry 19 }=0A= =0A= docsQosPktClassEnetProtocol OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "If docsQosEthPktClassProtocolType is none(0),=0A= this object is ignored when considering whether=0A= a packet matches the current rule.=0A= =0A= If dosQosPktClassEnetProtocolType is = ethertype(1),=0A= this object gives the 16-bit value of the=0A= EtherType that the packet must match in order to=0A= match the rule.=0A= =0A= If docsQosPktClassEnetProtocolType is dsap(2), = the=0A= lower 8 bits of this object's value must match = the=0A= DSAP byte of the packet in order to match the=0A= rule.=0A= =0A= If docsQosPktClassEnetProtocolType is mac(3), = the=0A= lower 8 bits of this object value represent a=0A= lower bound (inclusive) of MAC management = message=0A= type codes matched, and the upper 8 bits of this=0A= object value represent the upper bound = (inclusive)=0A= of matched MAC message type codes. Certain=0A= message type codes are excluded from matching, = as=0A= specified in the reference.=0A= =0A= If the Ethernet frame contains an 802.1P/Q Tag = header=0A= (i.e. EtherType 0x8100), this object applies to = the=0A= embedded EtherType field within the 802.1P/Q = header.=0A= =0A= If the referenced parameter is not present in = the=0A= classifier, the value of this object is reported as = 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.3"=0A= ::=3D { docsQosPktClassEntry 20 }=0A= =0A= docsQosPktClassUserPriApplies OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-only=0A= STATUS obsolete=0A= DESCRIPTION "This object is obsolete."=0A= ::=3D { docsQosPktClassEntry 21 }=0A= =0A= docsQosPktClassUserPriLow OBJECT-TYPE=0A= SYNTAX Integer32 (0..7)=0A= =0A= =0A= =0A= Expires July 2003 [Page 35]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object applies only to Ethernet frames=0A= using the 802.1P/Q tag header (indicated with=0A= EtherType 0x8100). Such frames include a 16-bit=0A= Tag that contains a 3 bit Priority field and=0A= a 12 bit VLAN number.=0A= =0A= Tagged Ethernet packets must have a 3-bit=0A= Priority field within the range of=0A= docsQosPktClassPriLow and docsQosPktClassPriHigh = in=0A= order to match this rule.=0A= =0A= If the referenced parameter is not present in = the=0A= classifier, the value of this object is reported as = 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.1"=0A= ::=3D { docsQosPktClassEntry 22 }=0A= =0A= docsQosPktClassUserPriHigh OBJECT-TYPE=0A= SYNTAX Integer32 (0..7)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object applies only to Ethernet frames=0A= using the 802.1P/Qtag header (indicated with=0A= EtherType 0x8100). Such frames include a 16-bit=0A= Tag that contains a 3 bit Priority field and=0A= a 12 bit VLAN number.=0A= =0A= Tagged Ethernet packets must have a 3-bit=0A= Priority field within the range of=0A= docsQosPktClassPriLow and=0A= docsQosPktClassPriHigh in order to match this=0A= rule.=0A= =0A= If the referenced parameter is not present in = the=0A= classifier, the value of this object is reported=0A= as 7.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.1"=0A= ::=3D { docsQosPktClassEntry 23 }=0A= =0A= docsQosPktClassVlanId OBJECT-TYPE=0A= SYNTAX Integer32 (0..4095)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object applies only to Ethernet frames=0A= using the 802.1P/Q tag header.=0A= =0A= If this object's value is nonzero, tagged=0A= packets must have a VLAN Identifier that matches=0A= =0A= =0A= =0A= Expires July 2003 [Page 36]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= the value in order to match the rule.=0A= =0A= Only the least significant 12 bits of this = object's=0A= value are valid.=0A= =0A= If the referenced parameter is not present in = the=0A= classifier, the value of this object is reported=0A= as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.2"=0A= ::=3D { docsQosPktClassEntry 24 }=0A= =0A= docsQosPktClassState OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= active(1),=0A= inactive(2)=0A= }=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object indicates whether or not the = classifier=0A= is enabled to classify packets to a Service = Flow.=0A= =0A= If the referenced parameter is not present in = the=0A= classifier, the value of this object is reported=0A= as active(1).=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.3.6"=0A= ::=3D { docsQosPktClassEntry 25 }=0A= =0A= docsQosPktClassPkts OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object counts the number of packets that = have=0A= been classified using this entry. This includes = all=0A= packets delivered to a service flow maximum rate=0A= policing function, whether or not that function=0A= drops the packets."=0A= ::=3D { docsQosPktClassEntry 26 }=0A= =0A= docsQosPktClassBitMap OBJECT-TYPE=0A= SYNTAX BITS { -- Reference = SP-RFIv1.1-I09-020830=0A= rulePriority(0), -- Appendix C.2.1.3.4=0A= activationState(1), -- Appendix C.2.1.3.6=0A= ipTos(2), -- Appendix C.2.1.5.1=0A= ipProtocol(3), -- Appendix C.2.1.5.2=0A= ipSourceAddr(4), -- Appendix C.2.1.5.3=0A= ipSourceMask(5), -- Appendix C.2.1.5.4=0A= ipDestAddr(6), -- Appendix C.2.1.5.5=0A= ipDestMask(7), -- Appendix C.2.1.5.6=0A= sourcePortStart(8), -- Appendix C.2.1.5.7=0A= =0A= =0A= =0A= Expires July 2003 [Page 37]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= sourcePortEnd(9), -- Appendix C.2.1.5.8=0A= destPortStart(10), -- Appendix C.2.1.5.9=0A= destPortEnd(11), -- Appendix C.2.1.5.10=0A= destMac(12), -- Appendix C.2.1.6.1=0A= sourceMac(13), -- Appendix C.2.1.6.2=0A= ethertype(14), -- Appendix C.2.1.6.3=0A= userPri(15), -- Appendix C.2.1.7.1=0A= vlanId(16) -- Appendix C.2.1.7.2=0A= }=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "This object indicates which parameter encodings = were=0A= actually present in the DOCSIS packet classifier=0A= encoding signaled in the DOCSIS message that=0A= created or modified the classifier. Note that=0A= Dynamic Service Change messages have replace=0A= semantics, so that all non-default parameters = must=0A= be present whether the classifier is being = created=0A= or changed.=0A= =0A= A bit of of this object is set to 1 if the = parameter=0A= indicated by the comment was present in the = classifier=0A= encoding, and 0 otherwise.=0A= =0A= Note that BITS are encoded most significant bit=0A= first, so that if e.g. bits 6 and 7 are set, this = object=0A= is encoded as the octet string '030000'H.=0A= "=0A= ::=3D { docsQosPktClassEntry 27 }=0A= =0A= docsQosPktClassInetSourceAddrType OBJECT-TYPE=0A= SYNTAX InetAddressType=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The type of the internet address for=0A= docsQosPktClassInetSourceAddr. This type must = be=0A= the same as the = docsQosPktClassInetSourceMaskType.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= ipv4(1)."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.3"=0A= ::=3D { docsQosPktClassEntry 28 }=0A= =0A= docsQosPktClassInetSourceAddr OBJECT-TYPE=0A= SYNTAX InetAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies the value of the IP=0A= Source Address required for packets to match=0A= =0A= =0A= =0A= Expires July 2003 [Page 38]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= this rule. An IP packet matches the rule when=0A= the packet ip source address bitwise ANDed=0A= with the docsQosPktClassInetSourceMask value=0A= equals the docsQosPktClassInetSourceAddr value.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= '00000000'H."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.3"=0A= ::=3D { docsQosPktClassEntry 29 }=0A= =0A= docsQosPktClassInetSourceMaskType OBJECT-TYPE=0A= SYNTAX InetAddressType=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The type of the internet address for=0A= docsQosPktClassInetSourceMask. This type must = be=0A= the same as the = docsQosPktClassInetSourceAddrType.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= ipv4(1)."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.4"=0A= ::=3D { docsQosPktClassEntry 30 }=0A= =0A= docsQosPktClassInetSourceMask OBJECT-TYPE=0A= SYNTAX InetAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies which bits of a packet's=0A= IP Source Address that are compared to match=0A= this rule.=0A= An IP packet matches the rule when the packet=0A= source address bitwise ANDed with the=0A= docsQosPktClassInetSourceMask value equals the=0A= docsQosIpPktClassInetSourceAddr value.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= 'FFFFFFFF'H."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.4"=0A= ::=3D { docsQosPktClassEntry 31 }=0A= =0A= docsQosPktClassInetDestAddrType OBJECT-TYPE=0A= SYNTAX InetAddressType=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The type of the internet address for=0A= docsQosPktClassInetDestAddr. This type must be=0A= the same as the = docsQosPktClassInetDestMaskType.=0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 39]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= ipv4(1)."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.5"=0A= ::=3D { docsQosPktClassEntry 32 }=0A= =0A= docsQosPktClassInetDestAddr OBJECT-TYPE=0A= SYNTAX InetAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies the value of the IP=0A= Destination Address required for packets to = match=0A= this rule. An IP packet matches the rule when=0A= the packet ip destination address=0A= bitwise ANDed with the=0A= docsQosPktClassInetDestMask value=0A= equals the docsQosPktClassInetDestAddr value.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= '00000000'H."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.5"=0A= ::=3D { docsQosPktClassEntry 33 }=0A= =0A= docsQosPktClassInetDestMaskType OBJECT-TYPE=0A= SYNTAX InetAddressType=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The type of the internet address for=0A= docsQosPktClassInetDestMask. This type must be=0A= the same as the = docsQosPktClassInetDestAddrType.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= ipv4(1)."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.6"=0A= ::=3D { docsQosPktClassEntry 34 }=0A= =0A= docsQosPktClassInetDestMask OBJECT-TYPE=0A= SYNTAX InetAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies which bits of a packet's=0A= IP Destination Address that are compared to=0A= match this rule.=0A= An IP packet matches the rule when the packet=0A= destination address bitwise ANDed with the=0A= docsQosPktClassInetDestMask value equals the=0A= docsQosIpPktClassInetDestAddr value.=0A= =0A= If the referenced parameter is not present=0A= =0A= =0A= =0A= Expires July 2003 [Page 40]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= in a classifier, this object reports the value = of=0A= 'FFFFFFFF'H."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.6"=0A= ::=3D { docsQosPktClassEntry 35 }=0A= =0A= docsQosPktClassHCPkts OBJECT-TYPE=0A= SYNTAX Counter64=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object counts the number of packets that = have=0A= been classified using this entry. This object = does=0A= not include dropped or delayed packets. This=0A= includes all packets delivered to a service flow=0A= maximum rate policing function, whether or not = that=0A= function drops the packets.=0A= =0A= If this 64-bit counter is implemented then the = lower=0A= 32-bits of this counter MUST represent the = corresponding=0A= 32-bits from the docsQosPktClassPkts counter."=0A= ::=3D { docsQosPktClassEntry 36 }=0A= =0A= =0A= =0A= --=0A= -- QOS Parameter Set Table=0A= --=0A= docsQosParamSetTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosParamSetEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes the set of DOCSIS 1.1 QOS=0A= parameters defined in a managed device.=0A= =0A= The ifIndex index specifies a DOCSIS MAC Domain.=0A= The docsQosServiceFlowId index specifies a = particular=0A= Service Flow.=0A= The docsQosParamSetType index indicates whether=0A= the active, admitted, or provisioned QOS = Parameter=0A= Set is being described by the row.=0A= =0A= Only the QOS Parameter Sets of Docsis 1.1 = service=0A= flows are represented in this table. Docsis 1.0=0A= QOS service profiles are not represented in this=0A= table.=0A= =0A= Each row corresponds to a DOCSIS QOS Parameter = Set=0A= as signaled via DOCSIS MAC management messages.=0A= Each object in the row corresponds to one or=0A= part of one DOCSIS 1.1 Service Flow Encoding.=0A= The docsQosParamSetBitMap object in the row = indicates=0A= which particular parameters were signaled in=0A= =0A= =0A= =0A= Expires July 2003 [Page 41]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= the original registration or dynamic service=0A= request message that created the QOS Parameter = Set.=0A= =0A= In many cases, even if a QOS Parameter Set = parameter=0A= was not signaled, the DOCSIS specification calls=0A= for a default value to be used. That default = value=0A= is reported as the value of the corresponding = object=0A= in this row.=0A= =0A= Many objects are not applicable depending on=0A= the service flow direction or upstream = scheduling=0A= type. The object value reported in this case=0A= is specified in the DESCRIPTION clause.=0A= "=0A= ::=3D { docsQosMIBObjects 2 }=0A= =0A= -- docsQosParamSetEntry { docsQosParamSetTable 1 } was=0A= -- removed in an initial and unimplemented version of this mib.=0A= =0A= docsQosParamSetEntry OBJECT-TYPE=0A= SYNTAX DocsQosParamSetEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION=0A= "A unique set of QOS parameters."=0A= INDEX {=0A= ifIndex, docsQosServiceFlowId, docsQosParamSetType=0A= }=0A= ::=3D { docsQosParamSetTable 2 }=0A= =0A= DocsQosParamSetEntry ::=3D SEQUENCE {=0A= docsQosParamSetServiceClassName DisplayString,=0A= docsQosParamSetPriority Integer32,=0A= docsQosParamSetMaxTrafficRate BitRate,=0A= docsQosParamSetMaxTrafficBurst Unsigned32,=0A= docsQosParamSetMinReservedRate BitRate,=0A= docsQosParamSetMinReservedPkt Integer32,=0A= docsQosParamSetActiveTimeout Integer32,=0A= docsQosParamSetAdmittedTimeout Integer32,=0A= docsQosParamSetMaxConcatBurst Integer32,=0A= docsQosParamSetSchedulingType SchedulingType,=0A= docsQosParamSetNomPollInterval Unsigned32,=0A= docsQosParamSetTolPollJitter Unsigned32,=0A= docsQosParamSetUnsolicitGrantSize Integer32,=0A= docsQosParamSetNomGrantInterval Unsigned32,=0A= docsQosParamSetTolGrantJitter Unsigned32,=0A= docsQosParamSetGrantsPerInterval Integer32,=0A= docsQosParamSetTosAndMask OCTET STRING,=0A= docsQosParamSetTosOrMask OCTET STRING,=0A= docsQosParamSetMaxLatency Unsigned32,=0A= docsQosParamSetType INTEGER,=0A= =0A= =0A= =0A= Expires July 2003 [Page 42]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosParamSetRequestPolicyOct OCTET STRING,=0A= docsQosParamSetBitMap BITS=0A= }=0A= =0A= docsQosParamSetServiceClassName OBJECT-TYPE=0A= SYNTAX DisplayString=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Refers to the Service Class Name that the=0A= parameter set values were derived.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object is a zero length string.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.3.4"=0A= ::=3D { docsQosParamSetEntry 4 }=0A= =0A= docsQosParamSetPriority OBJECT-TYPE=0A= SYNTAX Integer32 (0..7)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The relative priority of a service flow.=0A= Higher numbers indicate higher priority.=0A= This priority should only be used to = differentiate=0A= service flow with identical parameter sets.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object is 0. If the parameter is=0A= not applicable, the reported value is 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.1"=0A= ::=3D { docsQosParamSetEntry 5 }=0A= =0A= docsQosParamSetMaxTrafficRate OBJECT-TYPE=0A= SYNTAX BitRate=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Maximum sustained traffic rate allowed for this=0A= service flow in bits/sec. Must count all MAC = frame=0A= data PDU from the bytes following the MAC header = HCS to=0A= the end of the CRC. The number of bytes=0A= forwarded is limited during any time interval.=0A= The value 0 means no maximum traffic rate is=0A= enforced. This object applies to both upstream = and=0A= downstream service flows.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object is 0. If the parameter is=0A= =0A= =0A= =0A= Expires July 2003 [Page 43]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= not applicable, it is reported as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.2"=0A= ::=3D { docsQosParamSetEntry 6 }=0A= =0A= docsQosParamSetMaxTrafficBurst OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the token bucket size in bytes=0A= for this parameter set. The value is calculated=0A= from the byte following the MAC header HCS to=0A= the end of the CRC. This object is applied in=0A= conjunction with docsQosParamSetMaxTrafficRate = to=0A= calculate maximum sustained traffic rate.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object for scheduling types=0A= bestEffort (2), nonRealTimePollingService(3),=0A= and realTimePollingService(4) is 3044.=0A= =0A= If this parameter is not applicable, it is = reported=0A= as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.3"=0A= ::=3D { docsQosParamSetEntry 7 }=0A= =0A= docsQosParamSetMinReservedRate OBJECT-TYPE=0A= SYNTAX BitRate=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the guaranteed minimum rate in=0A= bits/sec for this parameter set. The value is=0A= calculated from the byte following the MAC=0A= header HCS to the end of the CRC. The default=0A= value of 0 has the meaning that no bandwidth=0A= is reserved.=0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object is 0. If the parameter=0A= is not applicable, it is reported as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.4"=0A= ::=3D { docsQosParamSetEntry 8 }=0A= =0A= docsQosParamSetMinReservedPkt OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies an assumed minimum packet size in=0A= =0A= =0A= =0A= Expires July 2003 [Page 44]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= bytes for which the = docsQosParamSetMinReservedRate=0A= will be provided. The value is calculated from=0A= the byte following the MAC header HCS to the=0A= end of the CRC.=0A= =0A= If the referenced parameter is omitted from a=0A= DOCSIS QOS parameter set, the default value is=0A= CMTS implementation dependent. In this case, the=0A= CMTS reports the default value it is using and = the=0A= CM reports a value of 0. If the referenced=0A= parameter is not applicable to the direction or=0A= scheduling type of the service flow, both CMTS = and=0A= CM report this object's value as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.5"=0A= ::=3D { docsQosParamSetEntry 9 }=0A= =0A= docsQosParamSetActiveTimeout OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= UNITS "seconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the maximum duration in seconds that=0A= resources remain unused on an active service=0A= flow before CMTS signals that both active and=0A= admitted parameters set are null.=0A= The default value of 0 signifies an=0A= infinite amount of time.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object is 0.=0A= "=0A= =0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.6"=0A= ::=3D { docsQosParamSetEntry 10 }=0A= =0A= docsQosParamSetAdmittedTimeout OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= UNITS "seconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the maximum duration in seconds that=0A= resources remain in admitted state before=0A= resources must be released.=0A= The value of 0 signifies an infinite amount=0A= of time.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the=0A= default value of this object is 200.=0A= =0A= =0A= =0A= Expires July 2003 [Page 45]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= "=0A= =0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.7"=0A= DEFVAL { 200 }=0A= ::=3D { docsQosParamSetEntry 11 }=0A= =0A= docsQosParamSetMaxConcatBurst OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the maximum concatenated burst in=0A= bytes which an upstream service flow is = allowed.=0A= The value is calculated from the FC byte of the=0A= Concatenation MAC Header to the last CRC byte in=0A= of the last concatenated MAC frame, inclusive.=0A= The value of 0 specifies no maximum burst.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object is 1522. If the parameter = is=0A= not applicable, this object's value is reported=0A= as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.1"=0A= ::=3D { docsQosParamSetEntry 12 }=0A= =0A= =0A= docsQosParamSetSchedulingType OBJECT-TYPE=0A= SYNTAX SchedulingType=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the upstream scheduling service used = for=0A= upstream service flow.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set of an=0A= upstream service flow, the default value of this=0A= object is bestEffort(2). For QOS parameter sets = of=0A= downstream service flows, this object's value is=0A= reported as undefined(1).=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.2"=0A= ::=3D { docsQosParamSetEntry 13 }=0A= =0A= docsQosParamSetNomPollInterval OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the nominal interval in microseconds=0A= between successive unicast request=0A= =0A= =0A= =0A= Expires July 2003 [Page 46]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= opportunities on an upstream service flow.=0A= =0A= This object applies only to upstream service = flows=0A= with schedulingType of value=0A= nonRealTimePollingService(3),=0A= realTimePollingService(4), and=0A= unsolictedGrantServiceWithAD(5). The parameter = is=0A= mandatory for realTimePollingService(4). If the=0A= parameter is omitted with=0A= nonRealTimePollingService(3), the CMTS uses an=0A= implementation dependent value. If the = parameter=0A= is omitted with unsolictedGrantServiceWithAD(5),=0A= the CMTS uses as a default value the value of = the=0A= Nominal Grant Interval parameter. In all cases,=0A= the CMTS reports the value it is using when the=0A= parameter is applicable. The CM reports the=0A= signaled parameter value if it was signaled,=0A= and 0 otherwise.=0A= =0A= If the referenced parameter is not applicable to=0A= the direction or scheduling type of the=0A= corresponding DOCSIS QOS Parameter Set, both=0A= CMTS and CM report this object's value as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.4"=0A= ::=3D { docsQosParamSetEntry 15 }=0A= =0A= docsQosParamSetTolPollJitter OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the maximum amount of time in=0A= microseconds that the unicast request interval=0A= may be delayed from the nominal periodic=0A= schedule on an upstream service flow.=0A= =0A= This parameter is applicable only to upstream=0A= service flows with a Schedulingtype of=0A= realTimePollingService(4) or=0A= unsolictedGrantServiceWithAD(5).=0A= =0A= If the referenced parameter is applicable but = not=0A= present in the corresponding DOCSIS QOS = Parameter=0A= Set, the CMTS uses an implementation dependent=0A= value and reports the value it is using.=0A= The CM reports a value of 0 in this case.=0A= =0A= If the parameter is not applicable to the=0A= direction or upstream scheduling type of the=0A= service flow, both CMTS and CM report this=0A= =0A= =0A= =0A= Expires July 2003 [Page 47]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= object's value as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.5"=0A= ::=3D { docsQosParamSetEntry 16 }=0A= =0A= docsQosParamSetUnsolicitGrantSize OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the unsolicited grant size in bytes.=0A= The grant size includes the entire MAC frame=0A= data PDU from the Frame Control byte to end of=0A= the MAC frame.=0A= =0A= The referenced parameter is applicable only=0A= for upstream flows with a SchedulingType of=0A= of unsolicitedGrantServicewithAD(5) or=0A= unsolicitedGrantService(6), and is mandatory=0A= when applicable. Both CMTS and CM report=0A= the signaled value of the parameter in this=0A= case.=0A= =0A= If the referenced parameter is not applicable to=0A= the direction or scheduling type of the=0A= corresponding DOCSIS QOS Parameter Set, both=0A= CMTS and CM report this object's value as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.6"=0A= ::=3D { docsQosParamSetEntry 17 }=0A= =0A= docsQosParamSetNomGrantInterval OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the nominal interval in microseconds=0A= between successive data grant opportunities=0A= on an upstream service flow.=0A= =0A= The referenced parameter is applicable only=0A= for upstream flows with a SchedulingType of=0A= of unsolicitedGrantServicewithAD(5) or=0A= unsolicitedGrantService(6), and is mandatory=0A= when applicable. Both CMTS and CM report the=0A= signaled value of the parameter in this case.=0A= =0A= If the referenced parameter is not applicable to=0A= the direction or scheduling type of the=0A= corresponding DOCSIS QOS Parameter Set, both=0A= CMTS and CM report this object's value as 0.=0A= "=0A= =0A= =0A= =0A= Expires July 2003 [Page 48]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.7"=0A= ::=3D { docsQosParamSetEntry 18 }=0A= =0A= docsQosParamSetTolGrantJitter OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the maximum amount of time in=0A= microseconds that the transmission opportunities=0A= may be delayed from the nominal periodic = schedule.=0A= =0A= The referenced parameter is applicable only=0A= for upstream flows with a SchedulingType of=0A= of unsolicitedGrantServicewithAD(5) or=0A= unsolicitedGrantService(6), and is mandatory=0A= when applicable. Both CMTS and CM report the=0A= signaled value of the parameter in this case.=0A= =0A= If the referenced parameter is not applicable to=0A= the direction or scheduling type of the=0A= corresponding DOCSIS QOS Parameter Set, both=0A= CMTS and CM report this object's value as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.8"=0A= ::=3D { docsQosParamSetEntry 19 }=0A= =0A= docsQosParamSetGrantsPerInterval OBJECT-TYPE=0A= SYNTAX Integer32 (0..127)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the number of data grants per Nominal=0A= Grant Interval=0A= (docsQosParamSetNomGrantInterval).=0A= =0A= The referenced parameter is applicable only=0A= for upstream flows with a SchedulingType of=0A= of unsolicitedGrantServicewithAD(5) or=0A= unsolicitedGrantService(6), and is mandatory=0A= when applicable. Both CMTS and CM report the=0A= signaled value of the parameter in this case.=0A= =0A= If the referenced parameter is not applicable to=0A= the direction or scheduling type of the=0A= corresponding DOCSIS QOS Parameter Set, both=0A= CMTS and CM report this object's value as 0.=0A= "=0A= =0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.9"=0A= ::=3D { docsQosParamSetEntry 20 }=0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 49]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosParamSetTosAndMask OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the AND mask for IP TOS byte for = overwriting=0A= IP packets TOS value. The IP packets TOS byte = is=0A= bitwise ANDed with docsQosParamSetTosAndMask and=0A= result is bitwise ORed with = docsQosParamSetTosORMask=0A= and result is written to IP packet TOS byte.=0A= A value of 'FF'H for docsQosParamSetTosAndMask = and=0A= a value of '00'H for docsQosParamSetTosOrMask = means=0A= that IP Packet TOS byte is not overwritten.=0A= =0A= Even though the this object is only enforced by = the=0A= Cable Modem Termination System (CMTS),=0A= Cable Modems must report the value as signaled = in=0A= the referenced parameter.=0A= =0A= This combination is reported if the referenced=0A= parameter is not present in a QOS Parameter = Set."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.10"=0A= ::=3D { docsQosParamSetEntry 21 }=0A= =0A= docsQosParamSetTosOrMask OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the OR mask for IP TOS byte.=0A= See the description of docsQosParamSetTosAndMask=0A= for further details."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.10"=0A= ::=3D { docsQosParamSetEntry 22 }=0A= =0A= docsQosParamSetMaxLatency OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the maximum latency between the=0A= reception of a packet by the CMTS on its NSI=0A= and the forwarding of the packet to the RF=0A= interface. A value of 0 signifies no maximum=0A= latency enforced. This object only applies to=0A= downstream service flows.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding downstream DOCSIS QOS Parameter = Set,=0A= the default value is 0. This parameter is=0A= not applicable to upstream DOCSIS QOS Parameter = Sets,=0A= and its value is reported as 0 in this case.=0A= "=0A= =0A= =0A= =0A= Expires July 2003 [Page 50]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.7.1"=0A= ::=3D { docsQosParamSetEntry 23 }=0A= =0A= =0A= docsQosParamSetType OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= active (1),=0A= admitted (2),=0A= provisioned (3)=0A= }=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Defines the type of the QOS parameter set = defined=0A= by this row. active(1) indicates the Active QOS=0A= parameter set, describing the service currently=0A= being provided by the Docsis MAC domain to the=0A= service flow. admitted(2) indicates the Admitted=0A= QOS Parameter Set, describing services reserved = by=0A= by the Docsis MAC domain for use by the service = flow.=0A= provisioned (3) describes the QOS Parameter Set=0A= defined in the DOCSIS CM Configuration file for=0A= the service flow."=0A= REFERENCE "SP-RFIv1.1-I09-020830, 8.1.5"=0A= ::=3D { docsQosParamSetEntry 24 }=0A= =0A= docsQosParamSetRequestPolicyOct OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(4))=0A= -- A 32-bit mask represented most significant = byte=0A= -- first. The 32 bit integer represented in this = manner=0A= -- equals the binary value of the referenced = integer=0A= -- parameter of the DOCSIS RFI specification.=0A= -- The BITS syntax is not used in order to avoid=0A= -- the confusion caused by different bit = numbering=0A= -- conventions.=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies which transmit interval opportunities=0A= the CM omits for upstream transmission requests = and=0A= packet transmissions. This object takes its=0A= default value for downstream service flows.=0A= =0A= Unless otherwise indicated, a bit value of 1 = means=0A= that a CM must *not* use that opportunity for=0A= upstream transmission.=0A= =0A= Calling bit 0 the least significant bit of the=0A= least significant (4th) octet, and increasing=0A= bit number with significance, the bit = definitions=0A= are as defined below:=0A= =0A= broadcastReqOpp(0):=0A= =0A= =0A= =0A= Expires July 2003 [Page 51]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= all CMs broadcast request opportunities=0A= =0A= priorityReqMulticastReq(1):=0A= priority request multicast request = opportunities=0A= =0A= reqDataForReq(2):=0A= request/data opportunities for requests=0A= =0A= reqDataForData(3):=0A= request/data opportunities for data=0A= =0A= piggybackReqWithData(4):=0A= piggyback requests with data=0A= =0A= concatenateData(5):=0A= concatenate data=0A= =0A= fragmentData(6):=0A= fragment data=0A= =0A= suppresspayloadheaders(7):=0A= suppress payload headers=0A= =0A= dropPktsExceedUGSize(8):=0A= A value of 1 mean that service flow must = drop=0A= packet that do not fit in the Unsolicited=0A= Grant size=0A= =0A= If the referenced parameter is not present in=0A= a QOS Parameter Set, the value of this object is=0A= reported as '00000000'H.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.3"=0A= ::=3D { docsQosParamSetEntry 25 }=0A= =0A= docsQosParamSetBitMap OBJECT-TYPE=0A= -- Each bit corresponds to a = parameter=0A= -- from SP-RFI-v1.1-I07-010829, = Appendix C=0A= SYNTAX BITS { -- in the indicated section number.=0A= trafficPriority(0), -- C.2.2.5.1=0A= maxTrafficRate(1), -- C.2.2.5.2=0A= maxTrafficBurst(2), -- C.2.2.5.3=0A= minReservedRate(3), -- C.2.2.5.4=0A= minReservedPkt(4), -- C.2.2.5.5=0A= activeTimeout(5), -- C.2.2.5.6=0A= admittedTimeout(6), -- C.2.2.5.7=0A= maxConcatBurst(7), -- C.2.2.6.1=0A= schedulingType(8), -- C.2.2.6.2=0A= requestPolicy(9), -- C.2.2.6.3=0A= nomPollInterval(10), -- C.2.2.6.4=0A= tolPollJitter(11), -- C.2.2.6.5=0A= =0A= =0A= =0A= Expires July 2003 [Page 52]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= unsolicitGrantSize(12), -- C.2.2.6.6=0A= nomGrantInterval(13), -- C.2.2.6.7=0A= tolGrantJitter(14), -- C.2.2.6.8=0A= grantsPerInterval(15), -- C.2.2.6.9=0A= tosOverwrite(16), -- C.2.2.6.10=0A= maxLatency(17) -- C.2.2.7.1=0A= }=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object indicates the set of QOS Parameter=0A= Set parameters actually signaled in the=0A= DOCSIS registration or dynamic service request=0A= message that created or modified the QOS Parameter = Set.=0A= A bit is set to 1 when the parameter described=0A= by the indicated reference section is present=0A= in the original request.=0A= =0A= Note that when Service Class names are expanded,=0A= the registration or dynamic response message may=0A= contain parameters as expanded by the CMTS based=0A= on a stored service class. These expanded=0A= parameters are *not* indicated by a 1 bit in = this=0A= object.=0A= =0A= Note that even though some QOS Parameter Set=0A= parameters may not be signaled in a message=0A= (so that the paramater's bit in this object is = 0)=0A= the DOCSIS specification calls for default=0A= values to be used. These default values are=0A= reported as the corresponding object's value in=0A= the row.=0A= =0A= Note that BITS objects are encoded most=0A= significant bit first. For example, if bits=0A= 1 and 16 are set, the value of this object=0A= is the octet string '400080'H.=0A= =0A= "=0A= ::=3D { docsQosParamSetEntry 26 }=0A= =0A= --=0A= -- Service Flow Table=0A= --=0A= docsQosServiceFlowTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosServiceFlowEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes the set of Docsis-QOS=0A= Service Flows in a managed device. "=0A= ::=3D { docsQosMIBObjects 3 }=0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 53]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosServiceFlowEntry OBJECT-TYPE=0A= SYNTAX DocsQosServiceFlowEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Describes a service flow.=0A= An entry in the table exists for each=0A= Service Flow ID. The ifIndex is an=0A= ifType of docsCableMaclayer(127)."=0A= INDEX {=0A= ifIndex,=0A= docsQosServiceFlowId=0A= }=0A= ::=3D { docsQosServiceFlowTable 1 }=0A= =0A= DocsQosServiceFlowEntry ::=3D SEQUENCE {=0A= docsQosServiceFlowId Unsigned32,=0A= docsQosServiceFlowProvisionedParamSetIndex Unsigned32,=0A= docsQosServiceFlowAdmittedParamSetIndex Unsigned32,=0A= docsQosServiceFlowActiveParamSetIndex Unsigned32,=0A= docsQosServiceFlowSID Unsigned32,=0A= docsQosServiceFlowDirection IfDirection,=0A= docsQosServiceFlowPrimary TruthValue,=0A= docsQosServiceFlowActiveTimeout Integer32,=0A= docsQosServiceFlowAdmittedTimeout Integer32,=0A= docsQosServiceFlowSchedulingType SchedulingType,=0A= docsQosServiceFlowRequestPolicy OCTET STRING = (SIZE(4)),=0A= docsQosServiceFlowTosAndMask OCTET STRING = (SIZE(1)),=0A= docsQosServiceFlowTosOrMask OCTET STRING = (SIZE(1))=0A= }=0A= =0A= docsQosServiceFlowId OBJECT-TYPE=0A= SYNTAX Unsigned32 (1..4294967295)=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "An index assigned to a service flow by CMTS."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.3.2"=0A= ::=3D { docsQosServiceFlowEntry 1 }=0A= =0A= docsQosServiceFlowProvisionedParamSetIndex OBJECT-TYPE=0A= SYNTAX Unsigned32 (0..4294967295)=0A= MAX-ACCESS read-only=0A= STATUS obsolete=0A= DESCRIPTION "This object is obsolete."=0A= ::=3D { docsQosServiceFlowEntry 3 }=0A= =0A= docsQosServiceFlowAdmittedParamSetIndex OBJECT-TYPE=0A= SYNTAX Unsigned32 (0..4294967295)=0A= MAX-ACCESS read-only=0A= STATUS obsolete=0A= DESCRIPTION "This object is obsolete."=0A= ::=3D { docsQosServiceFlowEntry 4 }=0A= =0A= =0A= =0A= Expires July 2003 [Page 54]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosServiceFlowActiveParamSetIndex OBJECT-TYPE=0A= SYNTAX Unsigned32 (0..4294967295)=0A= MAX-ACCESS read-only=0A= STATUS obsolete=0A= DESCRIPTION "This object is obsolete."=0A= ::=3D { docsQosServiceFlowEntry 5 }=0A= =0A= docsQosServiceFlowSID OBJECT-TYPE=0A= SYNTAX Unsigned32 (0..16383)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Service Identifier (SID) assigned to an=0A= admitted or active service flow. This object=0A= reports a value of 0 if a Service Id is not=0A= associated with the service flow. Only active=0A= or admitted upstream service flows will have a=0A= Service Id (SID)."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.3.3"=0A= ::=3D { docsQosServiceFlowEntry 6 }=0A= =0A= docsQosServiceFlowDirection OBJECT-TYPE=0A= SYNTAX IfDirection=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The direction of the service flow."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.1/2"=0A= ::=3D { docsQosServiceFlowEntry 7 }=0A= =0A= docsQosServiceFlowPrimary OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Object reflects whether service flow is the = primary=0A= or a secondary service flow.=0A= =0A= A primary service flow is the default service = flow=0A= for otherwise unclassified traffic and all MAC=0A= messages."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Section 8.1 "=0A= ::=3D { docsQosServiceFlowEntry 8 }=0A= =0A= docsQosServiceFlowActiveTimeout OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= UNITS "seconds"=0A= MAX-ACCESS read-only=0A= STATUS obsolete=0A= DESCRIPTION "This object is obsolete."=0A= ::=3D { docsQosServiceFlowEntry 9 }=0A= =0A= docsQosServiceFlowAdmittedTimeout OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= =0A= =0A= =0A= Expires July 2003 [Page 55]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= UNITS "seconds"=0A= MAX-ACCESS read-only=0A= STATUS obsolete=0A= DESCRIPTION "This object is obsolete."=0A= ::=3D { docsQosServiceFlowEntry 10 }=0A= =0A= docsQosServiceFlowSchedulingType OBJECT-TYPE=0A= SYNTAX SchedulingType=0A= MAX-ACCESS read-only=0A= STATUS obsolete=0A= DESCRIPTION "This object is obsolete."=0A= ::=3D { docsQosServiceFlowEntry 11 }=0A= =0A= docsQosServiceFlowRequestPolicy OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(4))=0A= MAX-ACCESS read-only=0A= STATUS obsolete=0A= DESCRIPTION "This object is obsolete."=0A= ::=3D { docsQosServiceFlowEntry 12 }=0A= =0A= docsQosServiceFlowTosAndMask OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-only=0A= STATUS obsolete=0A= DESCRIPTION "This object is obsolete."=0A= ::=3D { docsQosServiceFlowEntry 13 }=0A= =0A= docsQosServiceFlowTosOrMask OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-only=0A= STATUS obsolete=0A= DESCRIPTION "This object is obsolete."=0A= ::=3D { docsQosServiceFlowEntry 14 }=0A= =0A= --=0A= -- Service Flow Stats Table=0A= --=0A= docsQosServiceFlowStatsTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosServiceFlowStatsEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes statistics associated with = the=0A= Service Flows in a managed device. "=0A= ::=3D { docsQosMIBObjects 4 }=0A= =0A= docsQosServiceFlowStatsEntry OBJECT-TYPE=0A= SYNTAX DocsQosServiceFlowStatsEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Describes a set of service flow statistics.=0A= An entry in the table exists for each=0A= =0A= =0A= =0A= Expires July 2003 [Page 56]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= Service Flow ID. The ifIndex is an=0A= ifType of docsCableMaclayer(127)."=0A= INDEX {=0A= ifIndex,=0A= docsQosServiceFlowId=0A= }=0A= ::=3D { docsQosServiceFlowStatsTable 1 }=0A= =0A= DocsQosServiceFlowStatsEntry ::=3D SEQUENCE {=0A= docsQosServiceFlowPkts Counter32,=0A= docsQosServiceFlowOctets Counter32,=0A= docsQosServiceFlowTimeCreated TimeStamp,=0A= docsQosServiceFlowTimeActive Counter32,=0A= docsQosServiceFlowPHSUnknowns Counter32,=0A= docsQosServiceFlowPolicedDropPkts Counter32,=0A= docsQosServiceFlowPolicedDelayPkts Counter32,=0A= docsQosServiceFlowHCPkts Counter64,=0A= docsQosServiceFlowHCOctets Counter64=0A= }=0A= =0A= docsQosServiceFlowPkts OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Packet Data PDUs classified to = this=0A= service flow and forwarded beyond a service flow=0A= maximum rate policing function.=0A= This object does not count MAC-specific=0A= management messages.=0A= CMs not classifying downstream packets may = report=0A= this object's value as 0.=0A= =0A= Unclassified upstream user date packets (i.e. = non=0A= MAC-management) forwarded to the default = upstream=0A= service flow should be incremented for this = object.=0A= =0A= This object does include packets counted by=0A= docsQosServiceFlowPolicedDelayPkts, but does not = include=0A= packets counted by = docsQosServiceFlowPolicedDropPkts."=0A= ::=3D { docsQosServiceFlowStatsEntry 1 }=0A= =0A= docsQosServiceFlowOctets OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of octets from the byte after the MAC=0A= header HCS to the end of the CRC for all packets = counted=0A= in the docsQosServiceFlowPkts object for this = row.=0A= Note that this counts the octets after payload = header=0A= suppression has been applied. CMs not classifying = to a=0A= downstream service flow may report this object's=0A= =0A= =0A= =0A= Expires July 2003 [Page 57]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= value as 0 for that flow."=0A= ::=3D { docsQosServiceFlowStatsEntry 2 }=0A= =0A= docsQosServiceFlowTimeCreated OBJECT-TYPE=0A= SYNTAX TimeStamp=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The value of sysUpTime when the service flow=0A= was created."=0A= ::=3D { docsQosServiceFlowStatsEntry 3 }=0A= =0A= docsQosServiceFlowTimeActive OBJECT-TYPE=0A= SYNTAX Counter32=0A= UNITS "seconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The total time that service flow has been = active."=0A= ::=3D { docsQosServiceFlowStatsEntry 4 }=0A= =0A= docsQosServiceFlowPHSUnknowns OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of packets received on the service = flow=0A= with an unknown payload header suppression = index."=0A= ::=3D { docsQosServiceFlowStatsEntry 5 }=0A= =0A= docsQosServiceFlowPolicedDropPkts OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of packets dropped due to policing of=0A= the service flow, especially to limit the = maximum=0A= rate of the flow."=0A= =0A= ::=3D { docsQosServiceFlowStatsEntry 6 }=0A= =0A= docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of packet delayed due to policing of=0A= the service flow, especially to limit the = maximum=0A= rate of the flow."=0A= ::=3D { docsQosServiceFlowStatsEntry 7 }=0A= =0A= docsQosServiceFlowHCPkts OBJECT-TYPE=0A= SYNTAX Counter64=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Packet Data PDUs classified to = this=0A= =0A= =0A= =0A= Expires July 2003 [Page 58]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= service flow and forwarded beyond a service flow=0A= maximum rate policing function.=0A= This object does not count MAC-specific=0A= management messages.=0A= CMs not classifying downstream packets may = report=0A= this object's value as 0.=0A= =0A= Unclassified upstream user date packets (i.e. = non=0A= MAC-management) forwarded to the default = upstream=0A= service flow should be incremented for this = object.=0A= =0A= This object does include packets counted by=0A= docsQosServiceFlowPolicedDelayPkts, but does not = include=0A= packets counted by = docsQosServiceFlowPolicedDropPkts.=0A= =0A= If this 64-bit counter is implemented then the = lower=0A= 32-bits of this counter MUST represent the = corresponding=0A= 32-bits from the docsQosServiceFlowPkts = counter."=0A= ::=3D { docsQosServiceFlowStatsEntry 8 }=0A= =0A= docsQosServiceFlowHCOctets OBJECT-TYPE=0A= SYNTAX Counter64=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of octets from the byte after the MAC=0A= header HCS to the end of the CRC for all packets = counted=0A= in the docsQosServiceFlowPkts object for this = row.=0A= Note that this counts the octets after payload = header=0A= suppression has been applied. CMs not classifying = to a=0A= downstream service flow may report this object's=0A= value as 0 for that flow.=0A= =0A= If this 64-bit counter is implemented then the = lower=0A= 32-bits of this counter MUST represent the = corresponding=0A= 32-bits from the docsQosServiceFlowOctets = counter."=0A= ::=3D { docsQosServiceFlowStatsEntry 9 }=0A= =0A= --=0A= -- Upstream Service Flow Stats Table (CMTS ONLY)=0A= --=0A= docsQosUpstreamStatsTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosUpstreamStatsEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes statistics associated with=0A= upstream service flows. All counted frames must=0A= be received without an FCS error."=0A= ::=3D { docsQosMIBObjects 5 }=0A= =0A= docsQosUpstreamStatsEntry OBJECT-TYPE=0A= SYNTAX DocsQosUpstreamStatsEntry=0A= =0A= =0A= =0A= Expires July 2003 [Page 59]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Describes a set of upstream service flow = statistics.=0A= An entry in the table exists for each=0A= upstream Service Flow in a managed device.=0A= The ifIndex is an ifType of = docsCableMaclayer(127)."=0A= INDEX {=0A= ifIndex,=0A= docsQosSID=0A= }=0A= ::=3D { docsQosUpstreamStatsTable 1 }=0A= =0A= DocsQosUpstreamStatsEntry ::=3D SEQUENCE {=0A= docsQosSID Integer32,=0A= docsQosUpstreamFragments Counter32,=0A= docsQosUpstreamFragDiscards Counter32,=0A= docsQosUpstreamConcatBursts Counter32=0A= }=0A= =0A= docsQosSID OBJECT-TYPE=0A= SYNTAX Integer32 (1..16383)=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Identifies a service id for an admitted or = active=0A= upstream service flow."=0A= ::=3D { docsQosUpstreamStatsEntry 1 }=0A= =0A= docsQosUpstreamFragments OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of fragmentation headers received on = an=0A= upstream service flow, regardless of whether=0A= the fragment was correctly reassembled into a=0A= valid packet. "=0A= ::=3D { docsQosUpstreamStatsEntry 2 }=0A= =0A= docsQosUpstreamFragDiscards OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of upstream fragments discarded and = not=0A= assembled into a valid upstream packet."=0A= ::=3D { docsQosUpstreamStatsEntry 3 }=0A= =0A= docsQosUpstreamConcatBursts OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of concatenation headers received on = an=0A= upstream service flow."=0A= =0A= =0A= =0A= Expires July 2003 [Page 60]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= ::=3D { docsQosUpstreamStatsEntry 4 }=0A= =0A= =0A= --=0A= -- Dynamic Service Stats Table=0A= --=0A= docsQosDynamicServiceStatsTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosDynamicServiceStatsEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes statistics associated with = the=0A= Dynamic Service Flows in a managed device. "=0A= ::=3D { docsQosMIBObjects 6 }=0A= =0A= docsQosDynamicServiceStatsEntry OBJECT-TYPE=0A= SYNTAX DocsQosDynamicServiceStatsEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Describes a set of dynamic service flow = statistics.=0A= Two entries exist for each Docsis mac layer=0A= interface for the upstream and downstream = direction.=0A= On the CMTS, the downstream direction row = indicates=0A= messages transmitted or transactions originated=0A= by the CMTS. The upstream direction row = indicates=0A= messages received or transaction originated by = the=0A= CM. On the CM, the downstream direction row=0A= indicates messages received or transactions=0A= originated by the CMTS. The upstream direction=0A= row indicates messages transmitted by the CM or=0A= transactions originated by the CM.=0A= The ifIndex is an ifType of = docsCableMaclayer(127)."=0A= INDEX {=0A= ifIndex,=0A= docsQosIfDirection=0A= }=0A= ::=3D { docsQosDynamicServiceStatsTable 1 }=0A= =0A= DocsQosDynamicServiceStatsEntry ::=3D SEQUENCE {=0A= docsQosIfDirection IfDirection,=0A= docsQosDSAReqs Counter32,=0A= docsQosDSARsps Counter32,=0A= docsQosDSAAcks Counter32,=0A= docsQosDSCReqs Counter32,=0A= docsQosDSCRsps Counter32,=0A= docsQosDSCAcks Counter32,=0A= docsQosDSDReqs Counter32,=0A= docsQosDSDRsps Counter32,=0A= docsQosDynamicAdds Counter32,=0A= docsQosDynamicAddFails Counter32,=0A= docsQosDynamicChanges Counter32,=0A= docsQosDynamicChangeFails Counter32,=0A= =0A= =0A= =0A= Expires July 2003 [Page 61]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosDynamicDeletes Counter32,=0A= docsQosDynamicDeleteFails Counter32,=0A= docsQosDCCReqs Counter32,=0A= docsQosDCCRsps Counter32,=0A= docsQosDCCAcks Counter32,=0A= docsQosDCCs Counter32,=0A= docsQosDCCFails Counter32=0A= }=0A= =0A= docsQosIfDirection OBJECT-TYPE=0A= SYNTAX IfDirection=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "The direction of interface."=0A= ::=3D { docsQosDynamicServiceStatsEntry 1 }=0A= =0A= docsQosDSAReqs OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Addition Requests,=0A= including retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 2 }=0A= =0A= docsQosDSARsps OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Addition = Responses,=0A= including retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 3 }=0A= =0A= docsQosDSAAcks OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Addition = Acknowledgements,=0A= including retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 4 }=0A= =0A= docsQosDSCReqs OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Change Requests,=0A= including retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 5 }=0A= =0A= docsQosDSCRsps OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= =0A= =0A= =0A= Expires July 2003 [Page 62]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Change Responses,=0A= including retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 6 }=0A= =0A= docsQosDSCAcks OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Change = Acknowledgements,=0A= including retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 7 }=0A= =0A= docsQosDSDReqs OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Delete Requests,=0A= including retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 8 }=0A= =0A= docsQosDSDRsps OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Delete Responses,=0A= including retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 9 }=0A= =0A= docsQosDynamicAdds OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of successful Dynamic Service = Addition=0A= transactions."=0A= ::=3D { docsQosDynamicServiceStatsEntry 10 }=0A= =0A= docsQosDynamicAddFails OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of failed Dynamic Service Addition=0A= transactions."=0A= ::=3D { docsQosDynamicServiceStatsEntry 11 }=0A= =0A= docsQosDynamicChanges OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of successful Dynamic Service Change=0A= transactions."=0A= =0A= =0A= =0A= Expires July 2003 [Page 63]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= ::=3D { docsQosDynamicServiceStatsEntry 12 }=0A= =0A= docsQosDynamicChangeFails OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of failed Dynamic Service Change=0A= transactions."=0A= ::=3D { docsQosDynamicServiceStatsEntry 13 }=0A= =0A= docsQosDynamicDeletes OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of successful Dynamic Service Delete=0A= transactions."=0A= ::=3D { docsQosDynamicServiceStatsEntry 14 }=0A= =0A= docsQosDynamicDeleteFails OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of failed Dynamic Service Delete=0A= transactions."=0A= ::=3D { docsQosDynamicServiceStatsEntry 15 }=0A= =0A= =0A= docsQosDCCReqs OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Channel Change Request = messages=0A= traversing an interface. This count is nonzero only = on=0A= downstream direction rows. This count should=0A= include number of retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 16 }=0A= =0A= docsQosDCCRsps OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Channel Change Response = messages=0A= traversing an interface. This count is nonzero=0A= only on upstream direction rows. This count = should=0A= include number of retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 17 }=0A= =0A= docsQosDCCAcks OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= =0A= =0A= =0A= Expires July 2003 [Page 64]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= DESCRIPTION "The number of Dynamic Channel Change = Acknowledgement=0A= messages traversing an interface. This count=0A= is nonzero only on downstream direction rows.=0A= This count should include number of retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 18 }=0A= =0A= docsQosDCCs OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of successful Dynamic Channel Change=0A= transactions. This count is nonzero only on = downstream=0A= direction rows."=0A= ::=3D { docsQosDynamicServiceStatsEntry 19 }=0A= =0A= docsQosDCCFails OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of failed Dynamic Channel Change=0A= transactions. This count is nonzero only on=0A= downstream direction rows."=0A= ::=3D { docsQosDynamicServiceStatsEntry 20 }=0A= =0A= =0A= --=0A= -- Service Flow Log Table (CMTS ONLY)=0A= --=0A= docsQosServiceFlowLogTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosServiceFlowLogEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table contains a log of the disconnected=0A= Service Flows in a managed device."=0A= ::=3D { docsQosMIBObjects 7 }=0A= =0A= docsQosServiceFlowLogEntry OBJECT-TYPE=0A= SYNTAX DocsQosServiceFlowLogEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "The information regarding a single disconnected=0A= service flow."=0A= INDEX {=0A= docsQosServiceFlowLogIndex=0A= }=0A= ::=3D { docsQosServiceFlowLogTable 1 }=0A= =0A= DocsQosServiceFlowLogEntry ::=3D SEQUENCE {=0A= docsQosServiceFlowLogIndex Unsigned32,=0A= docsQosServiceFlowLogIfIndex InterfaceIndex,=0A= docsQosServiceFlowLogSFID Unsigned32,=0A= =0A= =0A= =0A= Expires July 2003 [Page 65]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosServiceFlowLogCmMac MacAddress,=0A= docsQosServiceFlowLogPkts Counter32,=0A= docsQosServiceFlowLogOctets Counter32,=0A= docsQosServiceFlowLogTimeDeleted TimeStamp,=0A= docsQosServiceFlowLogTimeCreated TimeStamp,=0A= docsQosServiceFlowLogTimeActive Counter32,=0A= docsQosServiceFlowLogDirection IfDirection,=0A= docsQosServiceFlowLogPrimary TruthValue,=0A= docsQosServiceFlowLogServiceClassName DisplayString,=0A= docsQosServiceFlowLogPolicedDropPkts Counter32,=0A= docsQosServiceFlowLogPolicedDelayPkts Counter32,=0A= docsQosServiceFlowLogControl INTEGER,=0A= docsQosServiceFlowLogHCPkts Counter64,=0A= docsQosServiceFlowLogHCOctets Counter64=0A= }=0A= =0A= docsQosServiceFlowLogIndex OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Unique index for a logged service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 1 }=0A= =0A= docsQosServiceFlowLogIfIndex OBJECT-TYPE=0A= SYNTAX InterfaceIndex=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The ifIndex of ifType docsCableMaclayer(127)=0A= on the CMTS where the service flow was = present."=0A= ::=3D { docsQosServiceFlowLogEntry 2 }=0A= =0A= docsQosServiceFlowLogSFID OBJECT-TYPE=0A= SYNTAX Unsigned32 (1..4294967295)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The index assigned to the service flow by the = CMTS."=0A= ::=3D { docsQosServiceFlowLogEntry 3 }=0A= =0A= docsQosServiceFlowLogCmMac OBJECT-TYPE=0A= SYNTAX MacAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The MAC address for the cable modem associated = with=0A= the service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 4 }=0A= =0A= docsQosServiceFlowLogPkts OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of packets counted on this service = flow=0A= =0A= =0A= =0A= Expires July 2003 [Page 66]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= after payload header suppression."=0A= ::=3D { docsQosServiceFlowLogEntry 5 }=0A= =0A= docsQosServiceFlowLogOctets OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of octets counted on this service = flow=0A= after payload header suppression."=0A= ::=3D { docsQosServiceFlowLogEntry 6 }=0A= =0A= =0A= docsQosServiceFlowLogTimeDeleted OBJECT-TYPE=0A= SYNTAX TimeStamp=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The value of sysUpTime when the service flow=0A= was deleted."=0A= ::=3D { docsQosServiceFlowLogEntry 7 }=0A= =0A= docsQosServiceFlowLogTimeCreated OBJECT-TYPE=0A= SYNTAX TimeStamp=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The value of sysUpTime when the service flow=0A= was created."=0A= ::=3D { docsQosServiceFlowLogEntry 8 }=0A= =0A= =0A= docsQosServiceFlowLogTimeActive OBJECT-TYPE=0A= SYNTAX Counter32=0A= UNITS "seconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The total time that service flow was active."=0A= ::=3D { docsQosServiceFlowLogEntry 9 }=0A= =0A= -- docsQosServiceFlowLogControl was formerly { = docsQosServiceFlowLogEntry 10}=0A= -- and was renumbered in an earlier revision of this mib.=0A= =0A= docsQosServiceFlowLogDirection OBJECT-TYPE=0A= SYNTAX IfDirection=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The value of docsQosServiceFlowDirection=0A= for the service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 11}=0A= =0A= docsQosServiceFlowLogPrimary OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-only=0A= =0A= =0A= =0A= Expires July 2003 [Page 67]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= STATUS current=0A= DESCRIPTION "The value of docsQosServiceFlowPrimary for the=0A= service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 12}=0A= =0A= docsQosServiceFlowLogServiceClassName OBJECT-TYPE=0A= SYNTAX DisplayString=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The value of docsQosParamSetServiceClassName for=0A= the provisioned QOS Parameter Set of the=0A= service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 13}=0A= =0A= docsQosServiceFlowLogPolicedDropPkts OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The final value of = docsQosServiceFlowPolicedDropPkts=0A= for the service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 14}=0A= =0A= docsQosServiceFlowLogPolicedDelayPkts OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The final value of = docsQosServiceFlowPolicedDelayPkts=0A= for the service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 15}=0A= =0A= docsQosServiceFlowLogControl OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= active(1),=0A= destroy(6)=0A= }=0A= =0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION "Setting this object to the value destroy(6) = removes=0A= this entry from the table.=0A= Reading this object return the value active(1)."=0A= ::=3D { docsQosServiceFlowLogEntry 16}=0A= =0A= docsQosServiceFlowLogHCPkts OBJECT-TYPE=0A= SYNTAX Counter64=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of packets counted on this service = flow=0A= after payload header suppression.=0A= =0A= If this 64-bit counter is implemented then the = lower=0A= =0A= =0A= =0A= Expires July 2003 [Page 68]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= 32-bits of this counter MUST represent the = corresponding=0A= 32-bits from the docsQosServiceFlowLogPkts = counter."=0A= ::=3D { docsQosServiceFlowLogEntry 17 }=0A= =0A= docsQosServiceFlowLogHCOctets OBJECT-TYPE=0A= SYNTAX Counter64=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of octets counted on this service = flow=0A= after payload header suppression.=0A= =0A= If this 64-bit counter is implemented then the = lower=0A= 32-bits of this counter MUST represent the = corresponding=0A= 32-bits from the docsQosServiceFlowLogOctets = counter."=0A= ::=3D { docsQosServiceFlowLogEntry 18 }=0A= =0A= --=0A= -- Service Class Table (CMTS ONLY)=0A= --=0A= docsQosServiceClassTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosServiceClassEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes the set of Docsis-QOS=0A= Service Classes in a CMTS. "=0A= ::=3D { docsQosMIBObjects 8 }=0A= =0A= docsQosServiceClassEntry OBJECT-TYPE=0A= SYNTAX DocsQosServiceClassEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "A provisioned service class on a CMTS.=0A= Each entry defines a template for certain=0A= DOCSIS QOS Parameter Set values. When a CM=0A= creates or modifies an Admitted QOS Parameter Set for = a=0A= Service Flow, it may reference a Service Class=0A= Name instead of providing explicit QOS Parameter=0A= Set values. In this case, the CMTS populates=0A= the QOS Parameter Set with the applicable=0A= corresponding values from the named Service Class.=0A= Subsequent changes to a Service Class row do *not*=0A= affect the QOS Parameter Set values of any service = flows=0A= already admitted.=0A= =0A= A service class template applies to only=0A= a single direction, as indicated in the=0A= docsQosServiceClassDirection object.=0A= "=0A= INDEX {=0A= docsQosServiceClassName=0A= }=0A= =0A= =0A= =0A= Expires July 2003 [Page 69]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= ::=3D { docsQosServiceClassTable 1 }=0A= =0A= DocsQosServiceClassEntry ::=3D SEQUENCE {=0A= docsQosServiceClassName DisplayString = (SIZE(1..15)),=0A= docsQosServiceClassParamSetIndex Unsigned32,=0A= docsQosServiceClassStatus RowStatus,=0A= docsQosServiceClassPriority Integer32,=0A= docsQosServiceClassMaxTrafficRate BitRate,=0A= docsQosServiceClassMaxTrafficBurst Unsigned32,=0A= docsQosServiceClassMinReservedRate BitRate,=0A= docsQosServiceClassMinReservedPkt Integer32,=0A= docsQosServiceClassMaxConcatBurst Integer32,=0A= docsQosServiceClassNomPollInterval Unsigned32,=0A= docsQosServiceClassTolPollJitter Unsigned32,=0A= docsQosServiceClassUnsolicitGrantSize Integer32,=0A= docsQosServiceClassNomGrantInterval Unsigned32,=0A= docsQosServiceClassTolGrantJitter Unsigned32,=0A= docsQosServiceClassGrantsPerInterval Integer32,=0A= docsQosServiceClassMaxLatency Unsigned32,=0A= docsQosServiceClassActiveTimeout Integer32,=0A= docsQosServiceClassAdmittedTimeout Integer32,=0A= docsQosServiceClassSchedulingType SchedulingType,=0A= docsQosServiceClassRequestPolicy OCTET STRING (SIZE(4)),=0A= docsQosServiceClassTosAndMask OCTET STRING (SIZE(1)),=0A= docsQosServiceClassTosOrMask OCTET STRING (SIZE(1)),=0A= docsQosServiceClassDirection IfDirection=0A= }=0A= =0A= docsQosServiceClassName OBJECT-TYPE=0A= SYNTAX DisplayString (SIZE(1..15))=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Service Class Name. DOCSIS specifies that the=0A= maximum size is 15 printable ASCII characters = with=0A= a terminating zero. The terminating zero is not=0A= represented in this DisplayString syntax object.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.3.4"=0A= ::=3D { docsQosServiceClassEntry 1 }=0A= =0A= docsQosServiceClassParamSetIndex OBJECT-TYPE=0A= SYNTAX Unsigned32 (1..4294967295)=0A= MAX-ACCESS read-create=0A= STATUS obsolete=0A= DESCRIPTION "This object is obsolete."=0A= ::=3D { docsQosServiceClassEntry 2 }=0A= =0A= docsQosServiceClassStatus OBJECT-TYPE=0A= SYNTAX RowStatus=0A= MAX-ACCESS read-create=0A= STATUS current=0A= =0A= =0A= =0A= Expires July 2003 [Page 70]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= DESCRIPTION "Used to create or delete rows in this table.=0A= There is no restriction on the ability=0A= to change values in this row while the row is = active.=0A= Inactive rows need not be timed out."=0A= ::=3D { docsQosServiceClassEntry 3 }=0A= =0A= docsQosServiceClassPriority OBJECT-TYPE=0A= SYNTAX Integer32 (0..7)=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetPriority."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 4 }=0A= =0A= docsQosServiceClassMaxTrafficRate OBJECT-TYPE=0A= SYNTAX BitRate=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetMaxTrafficRate."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 5 }=0A= =0A= docsQosServiceClassMaxTrafficBurst OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetMaxTrafficBurst."=0A= DEFVAL { 3044 }=0A= ::=3D { docsQosServiceClassEntry 6 }=0A= =0A= docsQosServiceClassMinReservedRate OBJECT-TYPE=0A= SYNTAX BitRate=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSEtMinReservedRate."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 7 }=0A= =0A= docsQosServiceClassMinReservedPkt OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetMinReservedPkt."=0A= ::=3D { docsQosServiceClassEntry 8 }=0A= =0A= docsQosServiceClassMaxConcatBurst OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetMaxConcatBurst."=0A= DEFVAL { 1522 }=0A= =0A= =0A= =0A= Expires July 2003 [Page 71]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= ::=3D { docsQosServiceClassEntry 9 }=0A= =0A= docsQosServiceClassNomPollInterval OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetNomPollInterval."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 10 }=0A= =0A= docsQosServiceClassTolPollJitter OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetTolPollJitter."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 11 }=0A= =0A= docsQosServiceClassUnsolicitGrantSize OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetUnsolicitGrantSize."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 12 }=0A= =0A= docsQosServiceClassNomGrantInterval OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetNomGrantInterval."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 13 }=0A= =0A= docsQosServiceClassTolGrantJitter OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetTolGrantJitter."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 14 }=0A= =0A= docsQosServiceClassGrantsPerInterval OBJECT-TYPE=0A= SYNTAX Integer32 (0..127)=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetGrantsPerInterval."=0A= =0A= =0A= =0A= Expires July 2003 [Page 72]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 15 }=0A= =0A= docsQosServiceClassMaxLatency OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetClassMaxLatency."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.7.1"=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 16 }=0A= =0A= docsQosServiceClassActiveTimeout OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= UNITS "seconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetActiveTimeout."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 17 }=0A= =0A= docsQosServiceClassAdmittedTimeout OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= UNITS "seconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetAdmittedTimeout."=0A= DEFVAL { 200 }=0A= ::=3D { docsQosServiceClassEntry 18 }=0A= =0A= docsQosServiceClassSchedulingType OBJECT-TYPE=0A= SYNTAX SchedulingType=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetSchedulingType."=0A= DEFVAL { bestEffort }=0A= ::=3D { docsQosServiceClassEntry 19 }=0A= =0A= docsQosServiceClassRequestPolicy OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(4))=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetRequestPolicyOct."=0A= DEFVAL { '00000000'H } -- no bits are set=0A= ::=3D { docsQosServiceClassEntry 20 }=0A= =0A= docsQosServiceClassTosAndMask OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-create=0A= STATUS current=0A= =0A= =0A= =0A= Expires July 2003 [Page 73]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= DESCRIPTION "Template for docsQosParamSetTosAndMask."=0A= DEFVAL { 'FF'H }=0A= ::=3D { docsQosServiceClassEntry 21 }=0A= =0A= docsQosServiceClassTosOrMask OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetTosOrMask."=0A= DEFVAL { '00'H }=0A= ::=3D { docsQosServiceClassEntry 22 }=0A= =0A= docsQosServiceClassDirection OBJECT-TYPE=0A= SYNTAX IfDirection=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Specifies whether the service class template=0A= applies to upstream or downstream service = flows."=0A= DEFVAL { upstream }=0A= ::=3D { docsQosServiceClassEntry 23 }=0A= =0A= --=0A= -- Service Class PolicyTable=0A= --=0A= docsQosServiceClassPolicyTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosServiceClassPolicyEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes the set of Docsis-QOS=0A= Service Class Policies.=0A= =0A= This table is an adjunct to the=0A= docsDevFilterPolicy table. Entries in=0A= docsDevFilterPolicy table can point to=0A= specific rows in this table.=0A= =0A= This table permits mapping a packet to a service=0A= class name of an active service flow so long as=0A= a classifier does not exist at a higher=0A= priority.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix E.2.1"=0A= ::=3D { docsQosMIBObjects 9 }=0A= =0A= docsQosServiceClassPolicyEntry OBJECT-TYPE=0A= SYNTAX DocsQosServiceClassPolicyEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "A service class name policy entry."=0A= INDEX {=0A= docsQosServiceClassPolicyIndex=0A= =0A= =0A= =0A= Expires July 2003 [Page 74]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= }=0A= ::=3D { docsQosServiceClassPolicyTable 1 }=0A= =0A= DocsQosServiceClassPolicyEntry ::=3D SEQUENCE {=0A= docsQosServiceClassPolicyIndex Integer32,=0A= docsQosServiceClassPolicyName DisplayString,=0A= docsQosServiceClassPolicyRulePriority Integer32,=0A= docsQosServiceClassPolicyStatus RowStatus=0A= }=0A= =0A= docsQosServiceClassPolicyIndex OBJECT-TYPE=0A= SYNTAX Integer32 (1..2147483647)=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Index value to uniquely identify an entry in=0A= this table."=0A= ::=3D { docsQosServiceClassPolicyEntry 1 }=0A= =0A= docsQosServiceClassPolicyName OBJECT-TYPE=0A= SYNTAX DisplayString=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Service Class Name to identify the name of the=0A= service class flow to which the packet should be=0A= directed."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix E.2.1"=0A= ::=3D { docsQosServiceClassPolicyEntry 2 }=0A= =0A= docsQosServiceClassPolicyRulePriority OBJECT-TYPE=0A= SYNTAX Integer32 (0..255)=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Service Class Policy rule priority for the=0A= entry."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.3.5"=0A= ::=3D { docsQosServiceClassPolicyEntry 3 }=0A= =0A= docsQosServiceClassPolicyStatus OBJECT-TYPE=0A= SYNTAX RowStatus=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Used to create or delete rows in this table.=0A= This object should not be deleted if it is=0A= reference by an entry in docsDevFilterPolicy.=0A= The reference should be deleted first.=0A= There is no restriction on the ability=0A= to change values in this row while the row is = active.=0A= Inactive rows need not be timed out."=0A= ::=3D { docsQosServiceClassPolicyEntry 4 }=0A= =0A= --=0A= =0A= =0A= =0A= Expires July 2003 [Page 75]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= -- Payload Header Suppression(PHS) Table=0A= --=0A= docsQosPHSTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosPHSEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes set of payload header=0A= suppression entries."=0A= ::=3D { docsQosMIBObjects 10 }=0A= =0A= docsQosPHSEntry OBJECT-TYPE=0A= SYNTAX DocsQosPHSEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "A payload header suppression entry.=0A= The ifIndex is an ifType of = docsCableMaclayer(127).=0A= The index docsQosServiceFlowId selects one=0A= service flow from the cable MAC layer = interface.=0A= The docsQosPktClassId index matches an=0A= index of the docsQosPktClassTable.=0A= "=0A= INDEX {=0A= ifIndex,=0A= docsQosServiceFlowId,=0A= docsQosPktClassId=0A= }=0A= ::=3D { docsQosPHSTable 1 }=0A= =0A= DocsQosPHSEntry ::=3D SEQUENCE {=0A= docsQosPHSField OCTET STRING,=0A= docsQosPHSMask OCTET STRING,=0A= docsQosPHSSize Integer32,=0A= docsQosPHSVerify TruthValue,=0A= docsQosPHSClassifierIndex Integer32,=0A= docsQosPHSIndex Integer32=0A= }=0A= =0A= -- docsQosPHSIndex { docsQosPHSEntry 1 } was=0A= -- moved to docsQosPHSIndex { docsQosPHSEntry 7 }=0A= -- in an ealier revisions of the mib.=0A= =0A= docsQosPHSField OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(0..255))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Payload header suppression field defines the=0A= bytes of the header which must be=0A= suppressed/restored by the sending/receiving=0A= device.=0A= =0A= The number of octets in this object should be=0A= =0A= =0A= =0A= Expires July 2003 [Page 76]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= the same as the value of docsQosPHSSize."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.1"=0A= ::=3D { docsQosPHSEntry 2 }=0A= =0A= docsQosPHSMask OBJECT-TYPE=0A= SYNTAX OCTET STRING(SIZE(0..32))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Payload header suppression mask defines the=0A= bit mask which used in combination with the=0A= docsQosPHSField defines which bytes in header=0A= must be suppressed/restored by the sending or=0A= receiving device.=0A= =0A= Each bit of this bit mask corresponds to a byte=0A= in the docsQosPHSField, with the least=0A= significant bit corresponding to first byte of=0A= the docsQosPHSField.=0A= =0A= Each bit of the bit mask specifies whether of=0A= not the corresponding byte should be suppressed=0A= in the packet. A bit value of '1' indicates that=0A= the byte should be suppressed by the sending=0A= device and restored by the receiving device.=0A= A bit value of '0' indicates that=0A= the byte should not be suppressed by the sending=0A= device or restored by the receiving device.=0A= =0A= If the bit mask does not contain a bit for each=0A= byte in the docsQosPHSField then the bit mask is=0A= extended with bit values of '1' to be the=0A= necessary length."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.3"=0A= ::=3D { docsQosPHSEntry 3 }=0A= =0A= docsQosPHSSize OBJECT-TYPE=0A= SYNTAX Integer32 (0..255)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Payload header suppression size specifies the=0A= number of bytes in the header to be suppressed=0A= and restored.=0A= =0A= The value of this object must match the number=0A= of bytes in the docsQosPHSField."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.4"=0A= ::=3D { docsQosPHSEntry 4 }=0A= =0A= docsQosPHSVerify OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-only=0A= =0A= =0A= =0A= Expires July 2003 [Page 77]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= STATUS current=0A= DESCRIPTION "Payload header suppression verification value of=0A= 'true' the sender must verify docsQosPHSField=0A= is the same as what is contained in the packet=0A= to be suppressed."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.5"=0A= ::=3D { docsQosPHSEntry 5 }=0A= =0A= docsQosPHSClassifierIndex OBJECT-TYPE=0A= SYNTAX Integer32 (1..65535)=0A= MAX-ACCESS read-only=0A= STATUS obsolete=0A= DESCRIPTION "This object is obsolete."=0A= ::=3D { docsQosPHSEntry 6 }=0A= =0A= docsQosPHSIndex OBJECT-TYPE=0A= SYNTAX Integer32 (1..255)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Payload header suppression index uniquely=0A= references the PHS rule for a given service = flow."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.2"=0A= ::=3D { docsQosPHSEntry 7 }=0A= =0A= =0A= --=0A= -- docsQosCmtsMacToSrvFlowTable (CMTS Only)=0A= --=0A= docsQosCmtsMacToSrvFlowTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosCmtsMacToSrvFlowEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table provide for referencing the service = flows=0A= associated with a particular cable modem. This = allows=0A= for indexing into other docsQos tables that are=0A= indexed by docsQosServiceFlowId and ifIndex."=0A= ::=3D { docsQosMIBObjects 11 }=0A= =0A= docsQosCmtsMacToSrvFlowEntry OBJECT-TYPE=0A= SYNTAX DocsQosCmtsMacToSrvFlowEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "An entry is created by CMTS for each service = flow=0A= connected to this CMTS."=0A= INDEX {=0A= docsQosCmtsCmMac,=0A= docsQosCmtsServiceFlowId=0A= }=0A= ::=3D { docsQosCmtsMacToSrvFlowTable 1 }=0A= =0A= DocsQosCmtsMacToSrvFlowEntry ::=3D SEQUENCE {=0A= =0A= =0A= =0A= Expires July 2003 [Page 78]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosCmtsCmMac MacAddress,=0A= docsQosCmtsServiceFlowId Unsigned32,=0A= docsQosCmtsIfIndex InterfaceIndex=0A= }=0A= =0A= docsQosCmtsCmMac OBJECT-TYPE=0A= SYNTAX MacAddress=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "The MAC address for the referenced CM."=0A= ::=3D { docsQosCmtsMacToSrvFlowEntry 1 }=0A= =0A= docsQosCmtsServiceFlowId OBJECT-TYPE=0A= SYNTAX Unsigned32 (1..4294967295)=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "An index assigned to a service flow by CMTS."=0A= ::=3D { docsQosCmtsMacToSrvFlowEntry 2 }=0A= =0A= docsQosCmtsIfIndex OBJECT-TYPE=0A= SYNTAX InterfaceIndex=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The ifIndex of ifType docsCableMacLayter(127)=0A= on the CMTS that is connected to the Cable = Modem."=0A= ::=3D { docsQosCmtsMacToSrvFlowEntry 3 }=0A= =0A= =0A= --=0A= -- Placeholder for notifications/traps.=0A= --=0A= docsQosNotification OBJECT IDENTIFIER ::=3D { docsQosMIB 2 }=0A= =0A= =0A= --=0A= -- Conformance definitions=0A= --=0A= docsQosConformance OBJECT IDENTIFIER ::=3D { docsQosMIB 3 }=0A= docsQosGroups OBJECT IDENTIFIER ::=3D { docsQosConformance 1 = }=0A= docsQosCompliances OBJECT IDENTIFIER ::=3D { docsQosConformance 2 = }=0A= =0A= docsQosCompliance MODULE-COMPLIANCE=0A= STATUS current=0A= DESCRIPTION=0A= "The compliance statement for MCNS Cable Modems and=0A= Cable Modem Termination Systems that implement DOCSIS=0A= Service Flows."=0A= =0A= MODULE -- docsQosMIB=0A= MANDATORY-GROUPS { docsQosBaseGroup }=0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 79]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= GROUP docsQosCmtsGroup=0A= DESCRIPTION=0A= "This group is mandatory for only Cable Modem = Termination=0A= Systems (CMTS) and not implemented for Cable Modems."=0A= =0A= GROUP docsQosParamSetGroup=0A= DESCRIPTION=0A= "This group is mandatory for Cable Modem Termination=0A= Systems (CMTS) and Cable Modems. Cable modems only = implement=0A= objects in this group as read-only."=0A= =0A= GROUP docsQosSrvClassPolicyGroup=0A= DESCRIPTION=0A= "This group is optional for Cable Modem Termination=0A= Systems (CMTS) and Cable Modems. This group only needs = to=0A= be implement if policy based service flow = classification=0A= is implemented. See docsDevPolicyTable in=0A= DOCS-CABLE-DEVICE-MIB for more details. "=0A= =0A= GROUP docsQosServiceClassGroup=0A= DESCRIPTION=0A= "The docsQosServiceClassTable group of objects. "=0A= =0A= GROUP docsQosHCGroup=0A= DESCRIPTION=0A= "This group is mandatory for Cable Modem Termination=0A= Systems (CMTS) and is optional for Cable Modems."=0A= =0A= OBJECT docsQosPktClassPkts=0A= DESCRIPTION=0A= "This object only needs to be implemented in entries=0A= that are classifying packets and not policing packets."=0A= =0A= OBJECT docsQosPktClassInetSourceAddrType=0A= -- SYNTAX InetAddressType { ipv4(1) }=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= OBJECT docsQosPktClassInetSourceAddr=0A= SYNTAX InetAddress (SIZE(4))=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= OBJECT docsQosPktClassInetSourceMaskType=0A= -- SYNTAX InetAddressType { ipv4(1) }=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 80]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= OBJECT docsQosPktClassInetSourceMask=0A= SYNTAX InetAddress (SIZE(4))=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= OBJECT docsQosPktClassInetDestAddrType=0A= -- SYNTAX InetAddressType { ipv4(1) }=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= OBJECT docsQosPktClassInetDestAddr=0A= SYNTAX InetAddress (SIZE(4))=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= OBJECT docsQosPktClassInetDestMaskType=0A= -- SYNTAX InetAddressType { ipv4(1) }=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= OBJECT docsQosPktClassInetDestMask=0A= SYNTAX InetAddress (SIZE(4))=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= ::=3D { docsQosCompliances 1 }=0A= =0A= docsQosBaseGroup OBJECT-GROUP=0A= OBJECTS {=0A= docsQosPktClassDirection,=0A= docsQosPktClassPriority,=0A= docsQosPktClassIpTosLow,=0A= docsQosPktClassIpTosHigh,=0A= docsQosPktClassIpTosMask,=0A= docsQosPktClassIpProtocol,=0A= docsQosPktClassSourcePortStart,=0A= docsQosPktClassSourcePortEnd,=0A= docsQosPktClassDestPortStart,=0A= docsQosPktClassDestPortEnd,=0A= docsQosPktClassDestMacAddr,=0A= docsQosPktClassDestMacMask,=0A= docsQosPktClassSourceMacAddr,=0A= docsQosPktClassEnetProtocolType,=0A= docsQosPktClassEnetProtocol,=0A= docsQosPktClassUserPriLow,=0A= docsQosPktClassUserPriHigh,=0A= =0A= =0A= =0A= Expires July 2003 [Page 81]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosPktClassVlanId,=0A= docsQosPktClassState,=0A= docsQosPktClassPkts,=0A= docsQosPktClassBitMap,=0A= docsQosPktClassInetSourceAddrType,=0A= docsQosPktClassInetSourceAddr,=0A= docsQosPktClassInetSourceMaskType,=0A= docsQosPktClassInetSourceMask,=0A= docsQosPktClassInetDestAddrType,=0A= docsQosPktClassInetDestAddr,=0A= docsQosPktClassInetDestMaskType,=0A= docsQosPktClassInetDestMask,=0A= =0A= docsQosServiceFlowSID,=0A= docsQosServiceFlowDirection,=0A= docsQosServiceFlowPrimary,=0A= =0A= docsQosServiceFlowPkts, -- not sure if CM should implement=0A= docsQosServiceFlowOctets,=0A= docsQosServiceFlowTimeCreated,=0A= docsQosServiceFlowTimeActive,=0A= docsQosServiceFlowPHSUnknowns,=0A= docsQosServiceFlowPolicedDropPkts,=0A= docsQosServiceFlowPolicedDelayPkts,=0A= =0A= docsQosDSAReqs,=0A= docsQosDSARsps,=0A= docsQosDSAAcks,=0A= docsQosDSCReqs,=0A= docsQosDSCRsps,=0A= docsQosDSCAcks,=0A= docsQosDSDReqs,=0A= docsQosDSDRsps,=0A= docsQosDynamicAdds,=0A= docsQosDynamicAddFails,=0A= docsQosDynamicChanges,=0A= docsQosDynamicChangeFails,=0A= docsQosDynamicDeletes,=0A= docsQosDynamicDeleteFails,=0A= docsQosDCCReqs,=0A= docsQosDCCRsps,=0A= docsQosDCCAcks,=0A= docsQosDCCs,=0A= docsQosDCCFails,=0A= =0A= docsQosPHSField,=0A= docsQosPHSMask,=0A= docsQosPHSSize,=0A= docsQosPHSVerify,=0A= docsQosPHSIndex=0A= }=0A= =0A= =0A= =0A= Expires July 2003 [Page 82]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= STATUS current=0A= DESCRIPTION=0A= "Group of objects implemented in both Cable Modems and=0A= Cable Modem Termination Systems."=0A= ::=3D { docsQosGroups 1 }=0A= =0A= docsQosParamSetGroup OBJECT-GROUP=0A= OBJECTS {=0A= docsQosParamSetServiceClassName,=0A= docsQosParamSetPriority,=0A= docsQosParamSetMaxTrafficRate,=0A= docsQosParamSetMaxTrafficBurst,=0A= docsQosParamSetMinReservedRate,=0A= docsQosParamSetMinReservedPkt,=0A= docsQosParamSetActiveTimeout,=0A= docsQosParamSetAdmittedTimeout,=0A= docsQosParamSetMaxConcatBurst,=0A= docsQosParamSetSchedulingType,=0A= docsQosParamSetNomPollInterval,=0A= docsQosParamSetTolPollJitter,=0A= docsQosParamSetUnsolicitGrantSize,=0A= docsQosParamSetNomGrantInterval,=0A= docsQosParamSetTolGrantJitter,=0A= docsQosParamSetGrantsPerInterval,=0A= docsQosParamSetTosAndMask,=0A= docsQosParamSetTosOrMask,=0A= docsQosParamSetMaxLatency,=0A= docsQosParamSetRequestPolicyOct,=0A= docsQosParamSetBitMap=0A= }=0A= STATUS current=0A= DESCRIPTION=0A= "Group of objects implemenented in both Cable Modems and=0A= Cable Modem Termination Systems for QOS parameter sets."=0A= ::=3D { docsQosGroups 2 }=0A= =0A= =0A= docsQosCmtsGroup OBJECT-GROUP=0A= OBJECTS {=0A= =0A= docsQosUpstreamFragments,=0A= docsQosUpstreamFragDiscards,=0A= docsQosUpstreamConcatBursts,=0A= =0A= docsQosServiceFlowLogIfIndex,=0A= docsQosServiceFlowLogSFID,=0A= docsQosServiceFlowLogCmMac,=0A= docsQosServiceFlowLogPkts,=0A= docsQosServiceFlowLogOctets,=0A= docsQosServiceFlowLogTimeDeleted,=0A= docsQosServiceFlowLogTimeCreated,=0A= =0A= =0A= =0A= Expires July 2003 [Page 83]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosServiceFlowLogTimeActive,=0A= docsQosServiceFlowLogDirection,=0A= docsQosServiceFlowLogPrimary,=0A= docsQosServiceFlowLogServiceClassName,=0A= docsQosServiceFlowLogPolicedDropPkts,=0A= docsQosServiceFlowLogPolicedDelayPkts,=0A= docsQosServiceFlowLogControl,=0A= =0A= docsQosCmtsIfIndex -- docsQosCmtsMacToSrvFlowTable = required=0A= =0A= }=0A= STATUS current=0A= DESCRIPTION=0A= "Mandatory group of objects implemented only in the CMTS."=0A= ::=3D { docsQosGroups 3 }=0A= =0A= docsQosSrvClassPolicyGroup OBJECT-GROUP=0A= OBJECTS {=0A= docsQosServiceClassPolicyName,=0A= docsQosServiceClassPolicyRulePriority,=0A= docsQosServiceClassPolicyStatus=0A= }=0A= STATUS current=0A= DESCRIPTION=0A= "Group of objects implemented in both Cable Modems and=0A= Cable Modem Termination Systems when supporting policy = based=0A= service flows."=0A= ::=3D { docsQosGroups 4 }=0A= =0A= docsQosServiceClassGroup OBJECT-GROUP=0A= OBJECTS {=0A= docsQosServiceClassStatus,=0A= docsQosServiceClassPriority,=0A= docsQosServiceClassMaxTrafficRate,=0A= docsQosServiceClassMaxTrafficBurst,=0A= docsQosServiceClassMinReservedRate,=0A= docsQosServiceClassMinReservedPkt,=0A= docsQosServiceClassMaxConcatBurst,=0A= docsQosServiceClassNomPollInterval,=0A= docsQosServiceClassTolPollJitter,=0A= docsQosServiceClassUnsolicitGrantSize,=0A= docsQosServiceClassNomGrantInterval,=0A= docsQosServiceClassTolGrantJitter,=0A= docsQosServiceClassGrantsPerInterval,=0A= docsQosServiceClassMaxLatency,=0A= docsQosServiceClassActiveTimeout,=0A= docsQosServiceClassAdmittedTimeout,=0A= docsQosServiceClassSchedulingType,=0A= docsQosServiceClassRequestPolicy,=0A= docsQosServiceClassTosAndMask,=0A= docsQosServiceClassTosOrMask,=0A= =0A= =0A= =0A= Expires July 2003 [Page 84]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosServiceClassDirection=0A= }=0A= STATUS current=0A= DESCRIPTION=0A= "The docsQosServiceClassTable objects. If a CMTS implements=0A= expansion of Service Class Names in a QOS Parameter Set,=0A= this group is mandatory on the CMTS. If the CMTS does not=0A= support Service Class Names, this group may be = unimplemented=0A= in the CMTS. This group is not implemented on the CM.=0A= "=0A= ::=3D { docsQosGroups 5 }=0A= =0A= docsQosDeprecatedGroup OBJECT-GROUP=0A= OBJECTS {=0A= docsQosPktClassIpSourceAddr,=0A= docsQosPktClassIpSourceMask,=0A= docsQosPktClassIpDestAddr,=0A= docsQosPktClassIpDestMask=0A= }=0A= STATUS deprecated=0A= DESCRIPTION=0A= "This is a collection of deprecated DOCS-QOS-MIB objects."=0A= ::=3D { docsQosGroups 6 }=0A= =0A= docsQosObsoleteGroup OBJECT-GROUP=0A= OBJECTS {=0A= docsQosPktClassUserPriApplies,=0A= docsQosServiceFlowProvisionedParamSetIndex,=0A= docsQosServiceFlowAdmittedParamSetIndex,=0A= docsQosServiceFlowActiveParamSetIndex,=0A= docsQosServiceFlowActiveTimeout,=0A= docsQosServiceFlowAdmittedTimeout,=0A= docsQosServiceFlowSchedulingType,=0A= docsQosServiceFlowRequestPolicy,=0A= docsQosServiceFlowTosAndMask,=0A= docsQosServiceFlowTosOrMask,=0A= docsQosServiceClassParamSetIndex,=0A= docsQosPHSClassifierIndex=0A= }=0A= STATUS obsolete=0A= DESCRIPTION=0A= "This is a collection of obsolete DOCS-QOS-MIB objects."=0A= ::=3D { docsQosGroups 7 }=0A= =0A= docsQosHCGroup OBJECT-GROUP=0A= OBJECTS {=0A= docsQosPktClassHCPkts,=0A= docsQosServiceFlowHCPkts,=0A= docsQosServiceFlowHCOctets,=0A= docsQosServiceFlowLogHCPkts,=0A= docsQosServiceFlowLogHCOctets=0A= =0A= =0A= =0A= Expires July 2003 [Page 85]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= }=0A= STATUS current=0A= DESCRIPTION=0A= "These objects within this group are 64-bit counters,=0A= providing a larger range than existing 32-bit=0A= counters that agents are required to support.=0A= The 32-bit counters are still mandatory=0A= for backwards compatibility with older agents.=0A= Due to the large amount of traffic passed on the=0A= Cable Modem Termination System (CMTS) these objects=0A= with a larger range are also mandatory. Traffic passed on=0A= a single Cable Modem is substantially less, therefore=0A= these objects are optional for the Cable Modem."=0A= ::=3D { docsQosGroups 8 }=0A= =0A= END=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 86]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= 5. Security Considerations=0A= =0A= =0A= This MIB relates to a agent which will provide metropolitan = public=0A= internet access. As such, improper manipulation of the objects=0A= represented by this MIB may result in denial of service to a = large=0A= number of end-users [9]. Manipulation of the=0A= docsQosServiceClassTable and docsQosServiceClassPolicyTable may = allow=0A= an end-user to increase their service levels, or affect other = end-=0A= users in either a positive or negative manner. In addition,=0A= manipulation of docsQosServiceFlowLogControl could allow an = attacker=0A= to remove logs of packet and byte counts forwarded on a service = flow.=0A= If such logs were used for billing, the attacker would obtain = free=0A= service.=0A= =0A= There are a number of management objects defined in this MIB = module=0A= with a MAX-ACCESS clause of read-write and/or read-create. Such=0A= objects may be considered sensitive or vulnerable in some network=0A= environments. The support for SET operations in a non-secure=0A= environment without proper protection can have a negative effect = on=0A= network operations. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= =0A= o The docsQosServiceClassTable provides a template of QOS=0A= parameters such as maximum rate limits for a named service=0A= class. Changing these parameters would allow an attacker = to=0A= obtain unauthorized class of service.=0A= =0A= o The docsQosServiceClassPolicyTable applies CMTS vendor=0A= proprietary policies for packet forwarding, including=0A= dropping, scheduling, notification, or other policies.=0A= Changing this table could allow an attacker to deny = service=0A= to all subscribers of the CMTS or grant the attacker=0A= unauthorized forwarding policies.=0A= =0A= o The docsQosServiceFlowLogControl object controls the = deletion=0A= of entries in the docsQosServiceFlowLogTable, which acts as = a=0A= historical "detail record" of DOCSIS service flow packets = and=0A= bytes transmitted. Such records may be used for billing=0A= purposes, so the unauthorized deletion of the records can=0A= result in free service.=0A= =0A= Some of the readable objects in this MIB module (i.e., objects with = a=0A= MAX-ACCESS other than not-accessible) may be considered sensitive = or=0A= vulnerable in some network environments. It is thus important to=0A= control even GET access to these objects and possibly to even = encrypt=0A= the values of these objects when sending them over the network = via=0A= SNMP. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= =0A= o Unauthorized SNMP GET access of the docsQosPktClassTable = or=0A= =0A= =0A= =0A= Expires July 2003 [Page 87]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosPHSTable can allow an attacker to learn IP = addresses=0A= permitted to have enhanced quality of service, for = possible=0A= spoofing. This table typically contains the IP addresses=0A= involved in voice-over-IP sessions, for example.=0A= =0A= o Unauthorized SNMP GET access of the docsQosParamSetTable=0A= allows an attacker to learn the names of service classes=0A= which are permitted to have enhanced QOS service, and the=0A= values of that enhanced service. That name can be = referenced=0A= in an unauthorized DOCSIS cable modem configuration file = to=0A= obtain enhanced service.=0A= =0A= o Unauthorized SNMP GET access of the = docsQosServiceFlowTable=0A= can tell an attacker when service flows are active, e.g.=0A= when a voice-over-IP call is in progress.=0A= =0A= o Unauthorized SNMP GET access of the=0A= docsQosServiceFlowStatsTable, docsQosUpstreamStatsTable,=0A= docsQosDynamicServiceStatsTable, = docsQosServiceFlogLogTable,=0A= and docsQosCmtsMacToSrvFlowTable can tell an attacker the=0A= volume of traffic to and from any service flow in the = system,=0A= resulting in loss of privacy of the amount and direction = of=0A= data transfer.=0A= =0A= SNMP versions prior to SNMPv3 did not include adequate security.=0A= Even if the network itself is secure (for example by using = IPSec),=0A= even then, there is no control as to who on the secure network is=0A= allowed to access and GET/SET (read/change/create/delete) the = objects=0A= in this MIB module. It is RECOMMENDED that implementers consider = the=0A= security features as provided by the SNMPv3 framework (see [12],=0A= section 8), including full support for the SNMPv3 cryptographic=0A= mechanisms (for authentication and privacy). Further, deployment = of=0A= SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is=0A= RECOMMENDED to deploy SNMPv3 and to enable cryptographic = security.=0A= It is then a customer/operator responsibility to ensure that the = SNMP=0A= entity giving access to an instance of this MIB module, is = properly=0A= configured to give access to the objects only to those principals=0A= (users) that have legitimate rights to indeed GET or SET=0A= (change/create/delete) them.=0A= =0A= =0A= =0A= 6. Intellectual Property=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= intellectual property or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described = in=0A= this document or the extent to which any license under such = rights=0A= might or might not be available; neither does it represent that = it=0A= has made any effort to identify any such rights. Information on = the=0A= IETF's procedures with respect to rights in standards-track and=0A= =0A= =0A= =0A= Expires July 2003 [Page 88]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= standards-related documentation can be found in BCP-11. Copies = of=0A= claims of rights made available for publication and any assurances = of=0A= licenses to be made available, or the result of an attempt made = to=0A= obtain a general license or permission for the use of such=0A= proprietary rights by implementers or users of this specification = can=0A= be obtained from the IETF Secretariat.=0A= =0A= The IETF invites any interested party to bring to its attention = any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights which may cover technology that may be required to = practice=0A= this standard. Please address the information to the IETF = Executive=0A= Director.=0A= =0A= =0A= =0A= 7. Acknowledgement=0A= =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society.=0A= =0A= =0A= =0A= 8. Normative References=0A= =0A= [1] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure = of=0A= Management Information for Version 2 (SMIv2)", STD 58,=0A= RFC 2578, April 1999.=0A= =0A= [2] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual=0A= Conventions for SMIv2", STD 58, RFC 2579, April 1999.=0A= =0A= [3] McCloghrie, K., Perkins, D. and J. Schoenwaelder, = "Conformance=0A= Statements for SMIv2", STD 58, RFC 2580, April 1999.=0A= =0A= [4] "Data-Over-Cable Service Interface Specifications:=0A= Radio Frequency Interface Specification = SP-RFIv1.1-I09-020830",=0A= DOCSIS, August 2002, http://www.cablemodem.com/.=0A= =0A= [5] L. Steinberg, "Techniques for Managing Asynchronously = Generated=0A= Alerts", RFC 1224, May 1991.=0A= =0A= [6] "Data-Over-Cable Service Interface Specifications: Operations=0A= Support System Interface Specification = SP-OSSIv1.1-I06-020830",=0A= DOCSIS, August 2002, http://www.cablemodem.com/.=0A= =0A= [7] Bradner, S., "Key words for use in RFCs to Indicate = Requirement=0A= Levels", RFC2119, March 1997.=0A= =0A= [8] "Data-Over-Cable Service Interface Specifications: Baseline=0A= Privacy Plus Interface Specification SP-BPI+-I07-020830",=0A= DOCSIS, August 2002, http://www.cablemodem.com/.=0A= =0A= =0A= =0A= Expires July 2003 [Page 89]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= [9] St. Johns, M., "Cable Device Management Information Base for=0A= DOCSIS compliant Cable Modems and Cable Modem Termination=0A= Systems", RFC 2669, August 1999.=0A= =0A= [10] St. Johns, M., "Radio Frequency (RF) Interface Management=0A= Information Base for MCNS/DOCSIS compliant RF interfaces",=0A= RFC 2670, August 1999.=0A= =0A= [11] Daniele, M. et. al.,"Textual Conventions for Internet = Network=0A= Addresses", RFC 2851, June 2000.=0A= =0A= =0A= =0A= 9. Informative References=0A= =0A= [12] Case, J., Mundy, R., Partain, D. and B. Stewart,=0A= "Introduction and Applicability Statements for Internet-=0A= Standard Management Framework", RFC 3410, December 2002.=0A= =0A= =0A= =0A= 10. Author's Address=0A= =0A= Michael Patrick=0A= Motorola Broadband Communications Sector=0A= 20 Cabot Blvd., MS M2-330=0A= Mansfield, MA 02048=0A= Phone: (508) 851-8402=0A= Email: michael.patrick@motorola.com=0A= =0A= William Murwin=0A= Motorola Broadband Communications Sector=0A= 20 Cabot Blvd., MS M2-330=0A= Mansfield, MA 02048=0A= Phone: (508) 851-8385=0A= Email: w.murwin@motorola.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 90]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= 11. Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2001). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished = to=0A= others, and derivative works that comment on or otherwise explain = it=0A= or assist in its implementation may be prepared, copied, = published=0A= and distributed, in whole or in part, without restriction of any=0A= kind, provided that the above copyright notice and this paragraph = are=0A= included on all such copies and derivative works. However, this=0A= document itself may not be modified in any way, such as by = removing=0A= the copyright notice or references to the Internet Society or = other=0A= Internet organizations, except as needed for the purpose of=0A= developing Internet standards in which case the procedures for=0A= copyrights defined in the Internet Standards process must be=0A= followed, or as required to translate it into languages other = than=0A= English.=0A= =0A= The limited permissions granted above are perpetual and will not = be=0A= revoked by the Internet Society or its successors or assigns.=0A= =0A= This document and the information contained herein is provided on = an=0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET = ENGINEERING=0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, = INCLUDING=0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 91]=0A= =0A= =0A= =0A= =0A= ------_=_NextPart_000_01C2BE68.DF7AD300-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Sun Jan 19 22:28:53 2003 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 WAA00086 for ; Sun, 19 Jan 2003 22:28:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0K3jiq07141 for ipcdn-archive@odin.ietf.org; Sun, 19 Jan 2003 22:45:44 -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 h0K3jcJ07131; Sun, 19 Jan 2003 22:45:38 -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 h0K3i9J07069 for ; Sun, 19 Jan 2003 22:44:09 -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 WAA00047 for ; Sun, 19 Jan 2003 22:26:46 -0500 (EST) Received: from mms02-RelayB.tci.com (mms02-relayb.broadband.att.com [147.191.89.213]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id h0K3U4CH021862; Sun, 19 Jan 2003 20:30:04 -0700 (MST) Received: from 147.191.89.203 by mms02-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Sun, 19 Jan 2003 20:29:55 -0600 Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Sun, 19 Jan 2003 20:29:52 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD0A8@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Murwin William-LWM008 '" cc: "'Michael W. Patrick (E-mail) '" , "'Docsis-Oss (E-mail) '" , "'IPCDN (E-mail) '" Date: Sun, 19 Jan 2003 20:29:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1235B2B91052257-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] RE: Latest version of draft-ietf-ipcdn-qos-mib-07.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit William, It's great to see a new version of the QoS MIB. I ran SMICng with Bert's compiler options and came up with the following errors to consider. W: f(DOCS-QOS-MIB.mi2), (1540,48) Item "docsQosServiceFlowRequestPolicy" in sequence "DocsQosServiceFlowEntry" has gratuitous size specified W: f(DOCS-QOS-MIB.mi2), (1541,48) Item "docsQosServiceFlowTosAndMask" in sequence "DocsQosServiceFlowEntry" has gratuitous size specified W: f(DOCS-QOS-MIB.mi2), (1542,48) Item "docsQosServiceFlowTosOrMask" in sequence "DocsQosServiceFlowEntry" has gratuitous size specified W: f(DOCS-QOS-MIB.mi2), (2330,43) Item "docsQosServiceClassName" in sequence "DocsQosServiceClassEntry" has gratuitous size specified W: f(DOCS-QOS-MIB.mi2), (2349,43) Item "docsQosServiceClassRequestPolicy" in sequence "DocsQosServiceClassEntry" has gratuitous size specified W: f(DOCS-QOS-MIB.mi2), (2350,43) Item "docsQosServiceClassTosAndMask" in sequence "DocsQosServiceClassEntry" has gratuitous size specified W: f(DOCS-QOS-MIB.mi2), (2351,43) Item "docsQosServiceClassTosOrMask" in sequence "DocsQosServiceClassEntry" has gratuitous size specified E: f(DOCS-QOS-MIB.mi2), (924,1) Row "docsQosParamSetEntry" must have a value of one for last sub-identifier E: f(DOCS-QOS-MIB.mi2), (2117,13) Index item "docsQosServiceFlowLogIndex" must be defined with syntax that includes a range You can fix the first seven errors by making minor adjustments to the sequence definitions (omitting sizes): DocsQosServiceFlowEntry ::= SEQUENCE { docsQosServiceFlowId Unsigned32, docsQosServiceFlowProvisionedParamSetIndex Unsigned32, docsQosServiceFlowAdmittedParamSetIndex Unsigned32, docsQosServiceFlowActiveParamSetIndex Unsigned32, docsQosServiceFlowSID Unsigned32, docsQosServiceFlowDirection IfDirection, docsQosServiceFlowPrimary TruthValue, docsQosServiceFlowActiveTimeout Integer32, docsQosServiceFlowAdmittedTimeout Integer32, docsQosServiceFlowSchedulingType SchedulingType, docsQosServiceFlowRequestPolicy OCTET STRING, docsQosServiceFlowTosAndMask OCTET STRING, docsQosServiceFlowTosOrMask OCTET STRING } and DocsQosServiceClassEntry ::= SEQUENCE { docsQosServiceClassName DisplayString, docsQosServiceClassParamSetIndex Unsigned32, docsQosServiceClassStatus RowStatus, docsQosServiceClassPriority Integer32, docsQosServiceClassMaxTrafficRate BitRate, docsQosServiceClassMaxTrafficBurst Unsigned32, docsQosServiceClassMinReservedRate BitRate, docsQosServiceClassMinReservedPkt Integer32, docsQosServiceClassMaxConcatBurst Integer32, docsQosServiceClassNomPollInterval Unsigned32, docsQosServiceClassTolPollJitter Unsigned32, docsQosServiceClassUnsolicitGrantSize Integer32, docsQosServiceClassNomGrantInterval Unsigned32, docsQosServiceClassTolGrantJitter Unsigned32, docsQosServiceClassGrantsPerInterval Integer32, docsQosServiceClassMaxLatency Unsigned32, docsQosServiceClassActiveTimeout Integer32, docsQosServiceClassAdmittedTimeout Integer32, docsQosServiceClassSchedulingType SchedulingType, docsQosServiceClassRequestPolicy OCTET STRING, docsQosServiceClassTosAndMask OCTET STRING, docsQosServiceClassTosOrMask OCTET STRING, docsQosServiceClassDirection IfDirection } The next error: E: f(DOCS-QOS-MIB.mi2), (924,1) Row "docsQosParamSetEntry" must have a value of one for last sub-identifier is caused by this: -- docsQosParamSetEntry { docsQosParamSetTable 1 } was -- removed in an initial and unimplemented version of this mib. docsQosParamSetEntry OBJECT-TYPE [...] ::= { docsQosParamSetTable 2 } And the final error: E: f(DOCS-QOS-MIB.mi2), (2117,13) Index item "docsQosServiceFlowLogIndex" must be defined with syntax that includes a range is caused by the lack of a range for: docsQosServiceFlowLogIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Unique index for a logged service flow." ::= { docsQosServiceFlowLogEntry 1 } Two other notes: - It is likely that the MIB doctor will strongly recommend renumbering this MIB under a different OID, which is a new design pattern for our working group. That means that we might be able to purge the deprecated and obsolete objects from the MIB (and fix one of the errors above). - Can we substitute the SnmpAdminString for the uses of DisplayString in this MIB? -- Rich -----Original Message----- From: Murwin William-LWM008 To: Docsis-Oss (E-mail); IPCDN (E-mail) Cc: Michael W. Patrick (E-mail); Woundy, Richard Sent: 1/17/2003 1:41 PM Subject: Latest version of draft-ietf-ipcdn-qos-mib-07.txt Here is the latest version of the DOCSIS-QOS MIB. This is version 7 with the back date of January 1, 2003 so as not to be confused when the draft is submitted to IETF. Please send comments and suggestion as soon as possible so that we can post this on the IETF web site. Our goal is to post the version 7 within a week. Changes are noted at the top of the draft and within the Revision History of the MIB. Thanks, Mike Patrick & Will Murwin <> ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 <> _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Mon Jan 20 07:49:12 2003 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 HAA18250 for ; Mon, 20 Jan 2003 07:49:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KD6GR17076 for ipcdn-archive@odin.ietf.org; Mon, 20 Jan 2003 08:06:16 -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 h0KD6DJ17069; Mon, 20 Jan 2003 08:06:14 -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 h0KD5eJ17027 for ; Mon, 20 Jan 2003 08:05:40 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18165; Mon, 20 Jan 2003 07:48:06 -0500 (EST) Message-Id: <200301201248.HAA18165@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 20 Jan 2003 07:48:05 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-eventmess-01.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Management Event MIB for PacketCable/IPCablecom MTAs Author(s) : W. De Ketelaere, E. Nechamkin Filename : draft-ietf-ipcdn-pktc-eventmess-01.txt Pages : 29 Date : 2003-1-17 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it provides a common data and format definition for events and specifies by what means events are transmitted for PacketCable/IPCablecom compliant Multimedia Terminal Adapter devices. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2 [5][6][7]. The set of objects are consistent with the SNMP framework and existing SNMP standards. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-pktc-eventmess-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-pktc-eventmess-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-17133349.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-pktc-eventmess-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-pktc-eventmess-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-17133349.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Mon Jan 20 10:39:04 2003 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 KAA22074 for ; Mon, 20 Jan 2003 10:39:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KFuAV27307 for ipcdn-archive@odin.ietf.org; Mon, 20 Jan 2003 10:56:10 -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 h0KFu9J27295; Mon, 20 Jan 2003 10:56:09 -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 h0KFt9J27255 for ; Mon, 20 Jan 2003 10:55:09 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22057 for ; Mon, 20 Jan 2003 10:37:32 -0500 (EST) Received: from mms02-relaya.tci.com (mms02-relaya.broadband.att.com [147.191.89.206]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h0KFetvY004214 for ; Mon, 20 Jan 2003 08:40:55 -0700 (MST) Received: from 147.191.89.203 by mms02-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Mon, 20 Jan 2003 08:40:44 -0600 Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Mon, 20 Jan 2003 08:40:41 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD0AB@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'ipcdn@ietf.org'" Date: Mon, 20 Jan 2003 08:40:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1232C7F61082108-02-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] Updates to the IPCDN website Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I made the following updates to the IPCDN website, www.ipcdn.org. First, I added the interim meeting announcement: . Second, I updated the list of meetings to include the interim meeting and the next IETF meeting in San Francisco: Third, I updated the list of internet-drafts, in anticipation of the new wave of drafts being submitted (so it's still a work in progress): -- Richard Woundy, IPCDN Co-Chair _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Jan 22 12:05:26 2003 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 MAA01213 for ; Wed, 22 Jan 2003 12:05:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MHNWD05398 for ipcdn-archive@odin.ietf.org; Wed, 22 Jan 2003 12:23:32 -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 h0MHNVJ05391; Wed, 22 Jan 2003 12:23:31 -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 h0MHMtJ05337 for ; Wed, 22 Jan 2003 12:22:55 -0500 Received: from peacock280.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01201 for ; Wed, 22 Jan 2003 12:04:17 -0500 (EST) Received: from mms02-relaya.tci.com (mms02-relaya.broadband.att.com [147.191.89.206]) by peacock280.tci.com (8.12.2/8.12.2) with ESMTP id h0MH7gIN005778 for ; Wed, 22 Jan 2003 10:07:42 -0700 (MST) Received: from 147.191.90.10 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Wed, 22 Jan 2003 10:07:33 -0600 Received: by entexchimc03.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 22 Jan 2003 10:06:25 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD0CD@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'ipcdn@ietf.org'" Date: Wed, 22 Jan 2003 10:07:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1230105F242551-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] Latest version of the Cable Device MIB Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I have uploaded the latest Cable Device MIB for your analysis, comments, and reactions: I would like to submit this version as an updated internet-draft by close of business Thursday. If you find any obvious errors, please notify me ASAP. A summary of the recent changes: - removing the InterfaceSet textual convention and reverting back to the RFC 2669 docsDevFilterLLCIfIndex and docsDevFilterIpIfIndex objects - modifying the VACM MIB augmentation to use docsDevVacmAccessIfIndex - an update of the handling of the docsDevNmAccessTable with respect to SNMP Coexistence, - simplification of the TFTP/HTTP software download mechanisms, - deprecation of docsDevEvThrottleInhibited in favor of docsDevEvThrottleThresholdExceeded, - leveraging the InetPortNumber syntax in the IP filter table, - making the docsDevCpe tables optional (along with many other MIB compliance changes), and - fixing numerous errors caught by MIB compilers. I will also respond to Kevin Marez's email separately. His ideas obviously influenced a number of my revision decisions. -- Rich P.S. Anyone else planning to submit a draft? _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Jan 22 16:50:56 2003 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 QAA08675 for ; Wed, 22 Jan 2003 16:50:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MM99K24231 for ipcdn-archive@odin.ietf.org; Wed, 22 Jan 2003 17:09:09 -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 h0MM92J24221; Wed, 22 Jan 2003 17:09:02 -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 h0MM8fJ24189 for ; Wed, 22 Jan 2003 17:08:41 -0500 Received: from snowmass280.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08643 for ; Wed, 22 Jan 2003 16:49:56 -0500 (EST) Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by snowmass280.tci.com (8.12.2/8.12.2) with ESMTP id h0MLqnYE024587; Wed, 22 Jan 2003 14:53:20 -0700 (MST) Received: from 147.191.89.201 by mms01-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Wed, 22 Jan 2003 14:53:13 -0600 Received: by entexchimc02.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 22 Jan 2003 14:53:01 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD0D9@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Pollak, Lucy'" , "'Lejeune, Andre'" cc: "IPCDN WG (E-mail)" , "DOCSIS OSS (E-mail)" Subject: RE: [ipcdn] RE: Comment on new Cable Device Mib draft Date: Wed, 22 Jan 2003 14:53:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1231CD43320487-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0MM8fJ24192 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Folks, After considering the comments from Lucy and Andre below, I propose the following simple Cable Device MIB changes. See for the latest full draft proposal. docsDevFilterIpSourcePortLow OBJECT-TYPE -- SYNTAX Integer32 (0..65535) SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "This is the inclusive lower bound of the transport-layer source port range that is to be matched. If the IP protocol of the packet is neither UDP nor TCP, this object is ignored during matching." DEFVAL { 0 } ::= { docsDevFilterIpEntry 12 } docsDevFilterIpSourcePortHigh OBJECT-TYPE -- SYNTAX Integer32 (0..65535) SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "This is the inclusive upper bound of the transport-layer source port range that is to be matched. If the IP protocol of the packet is neither UDP nor TCP, this object is ignored during matching." DEFVAL { 65535 } ::= { docsDevFilterIpEntry 13 } docsDevFilterIpDestPortLow OBJECT-TYPE -- SYNTAX Integer32 (0..65535) SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "This is the inclusive lower bound of the transport-layer destination port range that is to be matched. If the IP protocol of the packet is neither UDP nor TCP, this object is ignored during matching." DEFVAL { 0 } ::= { docsDevFilterIpEntry 14 } docsDevFilterIpDestPortHigh OBJECT-TYPE -- SYNTAX Integer32 (0..65535) SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "This is the inclusive upper bound of the transport-layer destination port range that is to be matched. If the IP protocol of the packet is neither UDP nor TCP, this object is ignored during matching." DEFVAL { 65535 } ::= { docsDevFilterIpEntry 15 } Note that I assert that I can convert existing objects from SYNTAX "Integer32 (0..65535)" to "InetPortNumber" without an OID renumbering. According to RFC 2578 section 10.2: (2) The value of a SYNTAX clause may be replaced by a textual convention, providing the textual convention is defined to use the same primitive ASN.1 type, has the same set of values, and has identical semantics. The common primitive ASN.1 type for both SYNTAXes is "INTEGER", the range of values for both SYNTAXes is "(0..65535)", and the semantics are identical. -- Rich -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, December 25, 2002 12:18 PM To: Woundy, Richard; 'Lejeune, Andre'; ipcdn@ietf.org; DOCSIS OSS (E-mail) Subject: RE: [ipcdn] RE: Comment on new Cable Device Mib draft Rich, I disagree with André. This issue was discussed with CL a number of times, this is correct. But I also remember that there was not consensus how to treat this problem. André's mail from 6/9/01 was unanswered in OSS reflector at least. Even if André's statistic is correct, 50% of vendors need to change their implementations. To do what André propose (filter row will not match if fields are irrelevant), we need to add BIT mask of settled fields as we do it in classifier. This will not be backward compatible to 100% of vendors. The MIB compliant CM must "ignore during matching" port fields if docsDevFilterIpProtocol is not "udp or tcp" in accordance with current MIB text. The only one problem in the text is that docsDevFilterIpProtocol =256(any) is not covered in description. I suppose we should not change the policy to differently opposite, only to clarify it. I agree, that classifiers and filters treat similar fields differently. But I also do not see any problem with this. Each of them are intended to strictly different things. I guess, that the better clarification may be: "If packet's Ip protocol is udp or tcp, this is the inclusive lower bound of the transport-layer source port range that is to be matched, otherwise it is ignored during matching." Thanks. Lucy -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Tuesday, December 24, 2002 6:42 PM To: 'Lejeune, Andre'; ipcdn@ietf.org; DOCSIS OSS (E-mail) Subject: RE: [ipcdn] RE: Comment on new Cable Device Mib draft Andre and other filtering/classification experts, I'm not sure how to resolve Andre's objection in the email below, other than broaden the audience and solicit the opinions of other folks. My perspective is that the definition of the docsDevFilterIpTable is driven by the requirements of the DOCSIS RFI, not vice versa. I also had an informal chat with Matt Schmitt, the author of RFI-N-02115 that is cited below. Matt pointed out that (unfortunately) there has been a different set of packet matching rules for the DOCSIS QoS classifiers (per the ECN) and the docsDevFilterIpTable. Hence, I have been confused about how to resolve Andre's objection. If some folks could help me provide some agreeable new DESCRIPTIONs for docsDevFilterIpSourcePortLow and other Cable Device MIB objects, so they meet CableLabs requirements and don't cause backward compatability problems, I would be very grateful. I would like to publish a working-group last-call-ready version of the Cable Device MIB by January 20th. -- Rich -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, December 03, 2002 4:07 PM To: Woundy, Richard Cc: ipcdn@ietf.org; Raftus, David Subject: [ipcdn] RE: Comment on new Cable Device Mib draft Rich, I know that in the field, some config files are setting protocol to 256 and setting the ports to what they want, and they expect the packets that are not udp or tcp to not match with the filter entry. This is the reason I went through the archive and sent you this comment, btw. This MSO told me that they have 50% of the modems behaving as they expect (matching to the packet) and the other 50% behaving the opposite (matching to the filter protocol). What I am trying to achieve with my wording is to stay along the lines of RFI-N-02115 (attached), which clarified this kind of situation for classifiers. I also understand your comment about the object always being set. But if we go with your definition, currently deployed config files may stop working for some MSOs and that worries me. What about requiring the *Low values to be non-0 or the *High to be non-65535 for both the *Low and *High values to be applicable? Thanks a lot, André -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Tuesday, December 03, 2002 2:04 PM To: 'Lejeune, Andre' Cc: ipcdn@ietf.org; Raftus, David Subject: RE: Comment on new Cable Device Mib draft Andre, I must have missed the original comment from Wim. Sorry. Your proposed modifications to the Cable Device MIB seems reasonably OK to me, with slight wording corrections. In particular, you cannot say "This table entry does not match if [this object] is set and the packet is not tcp or udp", because the DEFVAL clauses ensure that these columns are always "set". If you want to ignore all non-TCP/UDP packets in this row of the IP filter table, then I think you need to set docsDevFilterIpProtocol to the appropriate value. docsDevFilterIpSourcePortLow OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "This is the inclusive lower bound of the transport-layer source port range that is to be matched. If the IP protocol of the packet is neither UDP nor TCP, this object is ignored during matching." DEFVAL { 0 } ::= { docsDevFilterIpEntry 12 } What do other folks think? Did I capture the new wording correctly? -- Rich -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, December 03, 2002 9:49 AM To: Woundy, Richard; ipcdn@ietf.org Cc: Raftus, David Subject: Comment on new Cable Device Mib draft Hi Rich, The following comment (see attached email) was posted on the ipcdn reflector a year ago. Would it be possible to include a change in the new draft to address this? I would like to propose that the MIBs be changed to no longer be dependant on the value of docsDevFilterIpProtocol. Since there was an ECR that explained that the fields are only applicable if relevant, all 4 port related MIBs could be made to match only relevant packets (udp and tcp), irrespective of the docsDevFilterIpProtocol value. This would therefore read something like: docsDevFilterIpSourcePortLow OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "If the protocol of the packet is udp or tcp, this is the inclusive lower bound of the transport-layer source port range that is to be matched. This table entry does not match if it is set and the packet is not tcp or udp." DEFVAL { 0 } ::= { docsDevFilterIpEntry 12 } I am flexible on the actual wording... Thanks, André From: Wim De Ketelaere [mailto:deketelaere@tcomlabs.com] Sent: Thursday, September 06, 2001 1:39 PM To: ipcdn@ietf.org Subject: [ipcdn] docsDevFilterIp requirements Hi all, In draft-ietf-ipcdn-device-mibv2-01.txt I think the definition for docsDevFilterIpSourcePort and equivalent MIBs should be clarified that in the case that docsDevFilterIpProtocol is set to "all", the port numbers need to be checked for matching if the traffic is udp or tcp as udp and tcp are included in "all", this is not clear from the current definitions. Cable operators typically want to block all TCP/UDP ports below a certain port-number, they will use any protocol, and put one port-range in. docsDevFilterIpSourcePortLow OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "If docsDevFilterIpProtocol is udp or tcp, this is the inclusive lower bound of the transport-layer source port range that is to be matched, otherwise it is ignored during matching." DEFVAL { 0 } ::= { docsDevFilterIpEntry 12 } Any comments ? Thanks, Best regards, Wim Wim De Ketelaere CTO tComLabs _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Jan 22 17:15:57 2003 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 RAA09441 for ; Wed, 22 Jan 2003 17:15:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MLtgB22375 for ipcdn-archive@odin.ietf.org; Wed, 22 Jan 2003 16:55: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 h0MLtfJ22360; Wed, 22 Jan 2003 16:55:41 -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 h0MLrFJ22267 for ; Wed, 22 Jan 2003 16:53:15 -0500 Received: from snowmass280.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08094 for ; Wed, 22 Jan 2003 16:34:31 -0500 (EST) Received: from mms01-relayb.tci.com (mms01-relayb.broadband.att.com [147.191.90.1]) by snowmass280.tci.com (8.12.2/8.12.2) with ESMTP id h0MLbwYC019217; Wed, 22 Jan 2003 14:37:58 -0700 (MST) Received: from 147.191.90.10 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Wed, 22 Jan 2003 14:37:51 -0600 Received: by entexchimc03.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 22 Jan 2003 14:36:44 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD0D7@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Marez Kevin-MGI1375'" cc: "IPCDN WG (E-mail)" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Date: Wed, 22 Jan 2003 14:37:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1231D0A5314537-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kevin, This is the first of several responses to your comments about the Cable Device MIB. My responses coincide with what I recently posted at . This response concerns the use of ...IfIndex objects versus ...Interfaces + ...InterfaceSet objects for selecting interfaces in table rows. >1) InterfaceSet textual convention > >- The 'all external' description refers to "external physical >instantiation". With the introduction of eDOCSIS, the description needs >to be clarified. This setting should also include the internal logical >interface between the CM and a SAFE (eMTA, ePS, eSTB). >- Reference is made to filtering of stack and application traffic. >Currently in DOCSIS, stack and CM application traffic are not subject to >filtering and it should probably remain this way. Previously, it was >unclear if traffic from applications such as eMTA should be subject to >filtering. However, eDOCSIS now makes this clear. >- With the clarifications made by eDOCSIS, the benefits of updating the >objects to use the InterfaceSet textual convention seems to be reduced. >IP filters are heavily used today. Does this enhancement provide >sufficient benefit to warrant this change? If not, we should stick with >what is currently defined in RFC 2669. I recognize that the InterfaceSet TEXTUAL-CONVENTION did not catch on in the cable industry, and eDOCSIS seems to have evolved beyond it -- as you noted above. Therefore, in my latest MIB version, I removed the ...Interfaces + ...InterfaceSet objects, and restored the ...IfIndex objects to current status, e.g. docsDevFilterLLCIfIndex and docsDevFilterIpIfIndex. This is a reversion to the RFC 2669 MIB definitions. I also re-defined the VACM extension not to use the InterfaceSet TEXTUAL-CONVENTION, e.g. DocsDevVacmAccessExtEntry ::= SEQUENCE { docsDevVacmAccessIfIndex InterfaceIndexOrZero } docsDevVacmAccessIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "The entry interface to which this filter applies. The value corresponds to ifIndex for either a CATV MAC or another network interface. If the value is zero, the filter applies to all interfaces. In Cable Modems, the default value is the customer side interface(s). In Cable Modem Termination Systems, this object has to be specified to create a row in this table. Note that according to the DOCSIS OSSIv1.1 specification [OSSI1.1], ifIndex '1' means that this row applies to all CPE (customer-facing) interfaces." ::= { docsDevVacmAccessExtEntry 1 } (more about VACM in another email) This allowed me to remove the InterfaceSet TEXTUAL-CONVENTION from the MIB entirely, which avoids the problems you noted above. -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Jan 22 17:31:54 2003 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 RAA09989 for ; Wed, 22 Jan 2003 17:31:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MMo6j26488 for ipcdn-archive@odin.ietf.org; Wed, 22 Jan 2003 17:50:06 -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 h0MMo5J26481; Wed, 22 Jan 2003 17:50:05 -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 h0MMnPJ26441 for ; Wed, 22 Jan 2003 17:49:25 -0500 Received: from snowmass280.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09945 for ; Wed, 22 Jan 2003 17:30:41 -0500 (EST) Received: from mms02-RelayB.tci.com (mms02-relayb.broadband.att.com [147.191.89.213]) by snowmass280.tci.com (8.12.2/8.12.2) with ESMTP id h0MMXfYD008488; Wed, 22 Jan 2003 15:34:06 -0700 (MST) Received: from 147.191.89.201 by mms02-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Wed, 22 Jan 2003 15:33:56 -0600 Received: by entexchimc02.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 22 Jan 2003 15:33:44 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD0DB@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Marez Kevin-MGI1375'" cc: "IPCDN WG (E-mail)" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Date: Wed, 22 Jan 2003 15:33:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1231C3DE291056-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kevin, This response concerns the use of docsDevNmAccessTable with respect to SNMP Coexistence. >2) docsDevNmAccessTable Description. > >The description contains the following: > >"If the SNMP-COMMUNITY-MIB table has no entries, then this table has its >normal access control (described above)meaning for v1 and v2c access. " > >The above sentence is contradictory to the current DOCSIS OSSI spec. If >the device is in Coexistence mode (the only time that the SNMP-COMMUNITY- >MIB is accessible), then the nmAccessTable is not accessible. Everything >after the second paragraph could be deleted. I agree, and I think I incorporated the changes to the DESCRIPTION: docsDevNmAccessTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsDevNmAccessEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This table controls access to SNMP objects by network management stations. If the table is empty, access to SNMP objects is unrestricted. This table exists only on SNMPv1 or v2c agents and does not exist on SNMPv3 agents. See the conformance section for details. Specifically, for v3 agents, the appropriate MIBs and security models apply in lieu of this table. This table is deprecated. Instead, use the SNMP coexistence MIBs from RFC2576, the TARGET and NOTIFICATION MIBs from the SNMP Applications RFC, and the VACM MIBs for SNMPv1 and V2C access." ::= { docsDevMIBObjects 2 } Hopefully I used the correct wording in a related compliance statement: GROUP docsDevNmAccessGroupV2 DESCRIPTION "The objects in this group are only accessible from cable devices which are not operating in SNMP Coexistence mode [RFC2576] or in SNMPv3 mode [RFC3410]. For devices which must support an SNMP operational mode that pre-dates SNMP Coexistence, e.g. [OSSI1.1], this group is mandatory in Cable Modems and is optional in Cable Modem Termination Systems." -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Jan 22 18:23:29 2003 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 SAA11049 for ; Wed, 22 Jan 2003 18:23:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MNfg029618 for ipcdn-archive@odin.ietf.org; Wed, 22 Jan 2003 18:41: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 h0MNfBJ29606; Wed, 22 Jan 2003 18:41:11 -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 h0MNeuJ29579 for ; Wed, 22 Jan 2003 18:40:56 -0500 Received: from peacock280.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11035 for ; Wed, 22 Jan 2003 18:22:10 -0500 (EST) Received: from mms01-relayb.tci.com (mms01-relayb.broadband.att.com [147.191.90.1]) by peacock280.tci.com (8.12.2/8.12.2) with ESMTP id h0MNPYIN003381; Wed, 22 Jan 2003 16:25:34 -0700 (MST) Received: from 147.191.90.10 by mms01-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Wed, 22 Jan 2003 16:25:28 -0600 Received: by entexchimc03.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 22 Jan 2003 16:24:21 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD0DD@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Marez Kevin-MGI1375'" cc: "IPCDN WG (E-mail)" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Date: Wed, 22 Jan 2003 16:25:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1231F7E2333622-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kevin, This response concerns the use of both HTTP and TFTP for software image downloads. >3) Support for software download using HTTP. The motivation for adding >the HTTP transport was to support S-MTA software download. DOCSIS >requires that software downloads be TFTP. Do we want to consider stating >that the HTTP method is optional, either in the description or with the >MIBs compliance statement? > >4) docsDevSwOperStatus description - "TFTP" should be "TFTP/HTTP". Two >instances. Also, Section 3.2.1 will need to be updated to reflect these >changes. > >5) What is the relationship between docsDevSwServerTransportProtocol and >docsDevSwFileNameURL? What if docsDevSwServerTransportProtocol is set to >"tftp" and the portion of docsDevSwFileNameURL is set to >"http"? > >6) What is the relationship between docsDevSwServerAddress and the name> portion of docsDevSwFilenameURL? > >7) What is the syntax for the portion of the >docsDevSwFilenameURL? It should be limited to an IP address since DOCSIS >doesn't require the ability to resolve domain names. After considering all of these comments, I have come to the conclusion that I need to remove the docsDevSwFilenameURL object from the MIB, and restructure the other objects to maintain support for HTTP downloads. Here are my top reasons: - The semantics of the docsDevSwFilenameURL object overlaps too many other software download MIB objects. One example is the conflict with docsDevSwServerTransportProtocol per comment 5. Another example is the conflict with docsDevSwServerAddress per comment 6. - The URL scheme for "tftp" is not yet defined by the IETF. The URL scheme for "http" is defined in RFC 1738 and RFC 2616. "tftp" is not listed in . The Cable Device MIB is probably not the best location to define a new URL/URI scheme for a single MIB object. My new approach is to add only the docsDevSwServerTransportProtocol object to the RFC 2669 MIB, and redefine other objects as appropriate: docsDevSwServerTransportProtocol OBJECT-TYPE SYNTAX INTEGER { tftp(1), http(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the transport protocol (TFTP or HTTP) to be used for software upgrades. If the value of this object is tftp, then the cable device uses TFTP [RFC1350] read request packets to download the docsDevSwFilename from the docsDevSwServerAddress in octet mode. If the value of this object is http, then the cable device uses HTTP 1.0 [RFC1945] or HTTP 1.1 [RFC2616] GET requests sent to host docsDevSwServerAddress to download the software image from path docsDevSwFilename. The default value of this object is tftp." ::= { docsDevSoftware 8 } To clarify that the HTTP download mechanism is optional (comment 3), I added the following compliance statement: OBJECT docsDevSwServerTransportProtocol SYNTAX INTEGER { tftp(1) } DESCRIPTION "An implementation is only required to support TFTP software image downloads." To clarify that the cable device might not be able to resolve a DNS host name for HTTP or TFTP download (comment 7), I added the following compliance statement: OBJECT docsDevSwServerAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." Here is the updated definition of docsDevSwOperStatus, per comment 4. docsDevSwOperStatus OBJECT-TYPE SYNTAX INTEGER { inProgress(1), completeFromProvisioning(2), completeFromMgt(3), failed(4), other(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "InProgress(1) indicates that a TFTP or HTTP download is underway, either as a result of a version mismatch at provisioning or as a result of a upgradeFromMgt request. CompleteFromProvisioning(2) indicates that the last software upgrade was a result of version mismatch at provisioning. CompleteFromMgt(3) indicates that the last software upgrade was a result of setting docsDevSwAdminStatus to upgradeFromMgt. Failed(4) indicates that the last attempted download failed, ordinarily due to TFTP or HTTP timeout." REFERENCE "DOCSIS Radio Frequency Interface Specification, Section 8.2, Downloading Cable Modem Operating Software." ::= { docsDevSoftware 4 } Also per comment 4, here is the update to section 3.2.1: 3.2.1. Handling of Software upgrades The Cable Modem software upgrade process is documented in [RFI1.0]. From a network management station, the operator: o sets docsDevSwServer to the address of the TFTP server for software upgrades o sets docsDevSwFilename to the file pathname of the software upgrade image o sets docsDevSwAdminStatus to upgrade-from-mgt While DOCSIS only specifies the implementation of the TFTP protocol [RFC1350] for file transfers, other functional entities embedded within the cable device (particularly a PacketCable Multimedia Terminal Adapter [MTA-PROV]) specify the optional implementation of the HTTP protocol [RFC1945][RFC2068] for file transfers. The value of the docsDevSwServerTransportProtocol object determines which protocol is used for SNMP-initiated software upgrade. One reason for the SNMP-initiated upgrade is to allow loading of a temporary software image (e.g., special diagnostic software) that differs from the software normally used on that device without changing the provisioning database. Note that software upgrades should not be accepted blindly by the cable device. The cable device may refuse an upgrade if: o The download is incomplete. o The file contents are incomplete or damaged. o The software is not intended for that hardware device (may include the case of a feature set that has not been purchased for this device). A cable device that implements the code verification mechanisms of [BPIPLUS] verifies the source and integrity of the downloaded image by validating one or more Code Verification Signatures that are bundled within the software upgrade. -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Jan 22 19:06:09 2003 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 TAA11780 for ; Wed, 22 Jan 2003 19:06:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N0OO331657 for ipcdn-archive@odin.ietf.org; Wed, 22 Jan 2003 19:24:24 -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 h0N0O6J31645; Wed, 22 Jan 2003 19:24:06 -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 h0N0N8J31614 for ; Wed, 22 Jan 2003 19:23:08 -0500 Received: from pyramid.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11766 for ; Wed, 22 Jan 2003 19:04:22 -0500 (EST) Received: from mms02-RelayB.tci.com (mms02-relayb.broadband.att.com [147.191.89.213]) by pyramid.tci.com (8.12.2/8.12.2) with ESMTP id h0N00pCA025780; Wed, 22 Jan 2003 17:02:21 -0700 (MST) Received: from 147.191.90.11 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Wed, 22 Jan 2003 16:59:19 -0600 Received: by entexchimc04.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 22 Jan 2003 16:58:51 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD0E0@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Marez Kevin-MGI1375'" cc: "IPCDN WG (E-mail)" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Date: Wed, 22 Jan 2003 16:59:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1231EFDD302476-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kevin, Here is my comment on the VACM issue: >10) docsDevVacmAccessExtTable - Is this table really needed when using >SNMPv3? The limited security provided in SNMPv1/2 necessitated having >this functionality in the nmAccessTable. Given SNMPv3 security, it >doesn't seem like this functionality is necessary anymore. I would agree that it is better security to authenticate a keyed hash via SNMPv3, than to rely on the incoming device interface for implied user identification. However, one interesting and important case is a CM diagnostic interface for subscriber-side queries, after the CM registration process is completed. It seems quite useful to allow subscriber tools (with SNMPv3 securityLevel of noAuthNoPriv) to query cable modems over the CMCI (CPE interface) but not over the RFI (RF interface). -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Jan 22 19:08:47 2003 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 TAA11877 for ; Wed, 22 Jan 2003 19:08:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N0R2x31794 for ipcdn-archive@odin.ietf.org; Wed, 22 Jan 2003 19:27:02 -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 h0N0R1J31787; Wed, 22 Jan 2003 19:27:01 -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 h0N0QlJ31758 for ; Wed, 22 Jan 2003 19:26:47 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11869 for ; Wed, 22 Jan 2003 19:08:01 -0500 (EST) Received: from mms01-relayb.tci.com (mms01-relayb.broadband.att.com [147.191.90.1]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h0N0As3R001178; Wed, 22 Jan 2003 17:10:54 -0700 (MST) Received: from 147.191.89.203 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Wed, 22 Jan 2003 17:06:42 -0600 Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 22 Jan 2003 17:06:41 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD0E1@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Marez Kevin-MGI1375'" cc: "IPCDN WG (E-mail)" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Date: Wed, 22 Jan 2003 17:06:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1231ED98332567-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kevin, Here are some additional responses to your comments. >8) Is there a need to update objects that refer to ports with the >InetPortNumber textual convention defined in RFC3291? I assert that I can convert existing objects from SYNTAX "Integer32 (0..65535)" to "InetPortNumber" without an OID renumbering. According to RFC 2578 section 10.2: (2) The value of a SYNTAX clause may be replaced by a textual convention, providing the textual convention is defined to use the same primitive ASN.1 type, has the same set of values, and has identical semantics. The common primitive ASN.1 type for both SYNTAXes is "INTEGER", the range of values for both SYNTAXes is "(0..65535)", and the semantics are identical. >9) docsDevCpeV6Table - Support for IP spoofing filters which rely on >docsDevCpeTable was made optional in DOCSIS due to issues that couldn't be >resolved at the time. Given that, does it make sense to define >docsDevCpeV6Table at this time? I think the MIB doctor would prefer to see analogous objects for IPv4 and IPv6 spoofing filters. On the other hand, previous versions of the MIB indicated that the CPE tables were mandatory, when in fact they have been optional in DOCSIS for some time. That prompted the following new or revised compliance statements: GROUP docsDevCpeGroupV2 DESCRIPTION "This group is optional in Cable Modems, and MUST NOT be implemented in Cable Modem Termination Systems. See [SUBMGT-MIB] for a similar CMTS capability." GROUP docsDevIpV6Group DESCRIPTION "This group is mandatory in IPv6-aware Cable Modems." GROUP docsDevIpV6CpeGroup DESCRIPTION "This group is optional in IPv6-aware Cable Modems." Because of the differences in compliance statements, I split up the docsDevIpV6Group and docsDevIpV6CpeGroup. -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 23 10:50:52 2003 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 KAA10840 for ; Thu, 23 Jan 2003 10:50:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NG9RH03393 for ipcdn-archive@odin.ietf.org; Thu, 23 Jan 2003 11:09:27 -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 h0NG6IJ02516; Thu, 23 Jan 2003 11:06:18 -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 h0NG5JJ02460 for ; Thu, 23 Jan 2003 11:05:19 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10666 for ; Thu, 23 Jan 2003 10:46:12 -0500 (EST) Received: from mms02-RelayB.tci.com (mms02-relayb.broadband.att.com [147.191.89.213]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h0NFnRsu019311; Thu, 23 Jan 2003 08:49:37 -0700 (MST) Received: from 147.191.90.10 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Thu, 23 Jan 2003 08:49:32 -0600 Received: by entexchimc03.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Thu, 23 Jan 2003 08:48:23 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC01EBD0E6@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Pollak, Lucy'" , "'Lejeune, Andre'" cc: "IPCDN WG (E-mail)" , "DOCSIS OSS (E-mail)" Subject: RE: [ipcdn] RE: Comment on new Cable Device Mib draft Date: Thu, 23 Jan 2003 08:49:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 122ED086363401-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think the MIB doctor would strongly prefer us to use the official SYNTAX (InetPortNumber) from RFC 3291, especially if using the new SYNTAX results in no impact to existing implementations... -- Rich -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Thursday, January 23, 2003 10:24 AM To: Woundy, Richard; 'Lejeune, Andre' Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) Subject: RE: [ipcdn] RE: Comment on new Cable Device Mib draft Rich, I agree with your changes, this is very clear. I guess, it is better to leave syntax as is. It is more readable taking into account DEFVALs 0 and 65535. What do you think? Regards. Lucy -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Wednesday, January 22, 2003 11:53 PM To: Pollak, Lucy; 'Lejeune, Andre' Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) Subject: RE: [ipcdn] RE: Comment on new Cable Device Mib draft Folks, After considering the comments from Lucy and Andre below, I propose the following simple Cable Device MIB changes. See for the latest full draft proposal. docsDevFilterIpSourcePortLow OBJECT-TYPE -- SYNTAX Integer32 (0..65535) SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "This is the inclusive lower bound of the transport-layer source port range that is to be matched. If the IP protocol of the packet is neither UDP nor TCP, this object is ignored during matching." DEFVAL { 0 } ::= { docsDevFilterIpEntry 12 } docsDevFilterIpSourcePortHigh OBJECT-TYPE -- SYNTAX Integer32 (0..65535) SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "This is the inclusive upper bound of the transport-layer source port range that is to be matched. If the IP protocol of the packet is neither UDP nor TCP, this object is ignored during matching." DEFVAL { 65535 } ::= { docsDevFilterIpEntry 13 } docsDevFilterIpDestPortLow OBJECT-TYPE -- SYNTAX Integer32 (0..65535) SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "This is the inclusive lower bound of the transport-layer destination port range that is to be matched. If the IP protocol of the packet is neither UDP nor TCP, this object is ignored during matching." DEFVAL { 0 } ::= { docsDevFilterIpEntry 14 } docsDevFilterIpDestPortHigh OBJECT-TYPE -- SYNTAX Integer32 (0..65535) SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "This is the inclusive upper bound of the transport-layer destination port range that is to be matched. If the IP protocol of the packet is neither UDP nor TCP, this object is ignored during matching." DEFVAL { 65535 } ::= { docsDevFilterIpEntry 15 } Note that I assert that I can convert existing objects from SYNTAX "Integer32 (0..65535)" to "InetPortNumber" without an OID renumbering. According to RFC 2578 section 10.2: (2) The value of a SYNTAX clause may be replaced by a textual convention, providing the textual convention is defined to use the same primitive ASN.1 type, has the same set of values, and has identical semantics. The common primitive ASN.1 type for both SYNTAXes is "INTEGER", the range of values for both SYNTAXes is "(0..65535)", and the semantics are identical. -- Rich -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, December 25, 2002 12:18 PM To: Woundy, Richard; 'Lejeune, Andre'; ipcdn@ietf.org; DOCSIS OSS (E-mail) Subject: RE: [ipcdn] RE: Comment on new Cable Device Mib draft Rich, I disagree with André. This issue was discussed with CL a number of times, this is correct. But I also remember that there was not consensus how to treat this problem. André's mail from 6/9/01 was unanswered in OSS reflector at least. Even if André's statistic is correct, 50% of vendors need to change their implementations. To do what André propose (filter row will not match if fields are irrelevant), we need to add BIT mask of settled fields as we do it in classifier. This will not be backward compatible to 100% of vendors. The MIB compliant CM must "ignore during matching" port fields if docsDevFilterIpProtocol is not "udp or tcp" in accordance with current MIB text. The only one problem in the text is that docsDevFilterIpProtocol =256(any) is not covered in description. I suppose we should not change the policy to differently opposite, only to clarify it. I agree, that classifiers and filters treat similar fields differently. But I also do not see any problem with this. Each of them are intended to strictly different things. I guess, that the better clarification may be: "If packet's Ip protocol is udp or tcp, this is the inclusive lower bound of the transport-layer source port range that is to be matched, otherwise it is ignored during matching." Thanks. Lucy -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Tuesday, December 24, 2002 6:42 PM To: 'Lejeune, Andre'; ipcdn@ietf.org; DOCSIS OSS (E-mail) Subject: RE: [ipcdn] RE: Comment on new Cable Device Mib draft Andre and other filtering/classification experts, I'm not sure how to resolve Andre's objection in the email below, other than broaden the audience and solicit the opinions of other folks. My perspective is that the definition of the docsDevFilterIpTable is driven by the requirements of the DOCSIS RFI, not vice versa. I also had an informal chat with Matt Schmitt, the author of RFI-N-02115 that is cited below. Matt pointed out that (unfortunately) there has been a different set of packet matching rules for the DOCSIS QoS classifiers (per the ECN) and the docsDevFilterIpTable. Hence, I have been confused about how to resolve Andre's objection. If some folks could help me provide some agreeable new DESCRIPTIONs for docsDevFilterIpSourcePortLow and other Cable Device MIB objects, so they meet CableLabs requirements and don't cause backward compatability problems, I would be very grateful. I would like to publish a working-group last-call-ready version of the Cable Device MIB by January 20th. -- Rich -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, December 03, 2002 4:07 PM To: Woundy, Richard Cc: ipcdn@ietf.org; Raftus, David Subject: [ipcdn] RE: Comment on new Cable Device Mib draft Rich, I know that in the field, some config files are setting protocol to 256 and setting the ports to what they want, and they expect the packets that are not udp or tcp to not match with the filter entry. This is the reason I went through the archive and sent you this comment, btw. This MSO told me that they have 50% of the modems behaving as they expect (matching to the packet) and the other 50% behaving the opposite (matching to the filter protocol). What I am trying to achieve with my wording is to stay along the lines of RFI-N-02115 (attached), which clarified this kind of situation for classifiers. I also understand your comment about the object always being set. But if we go with your definition, currently deployed config files may stop working for some MSOs and that worries me. What about requiring the *Low values to be non-0 or the *High to be non-65535 for both the *Low and *High values to be applicable? Thanks a lot, André -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Tuesday, December 03, 2002 2:04 PM To: 'Lejeune, Andre' Cc: ipcdn@ietf.org; Raftus, David Subject: RE: Comment on new Cable Device Mib draft Andre, I must have missed the original comment from Wim. Sorry. Your proposed modifications to the Cable Device MIB seems reasonably OK to me, with slight wording corrections. In particular, you cannot say "This table entry does not match if [this object] is set and the packet is not tcp or udp", because the DEFVAL clauses ensure that these columns are always "set". If you want to ignore all non-TCP/UDP packets in this row of the IP filter table, then I think you need to set docsDevFilterIpProtocol to the appropriate value. docsDevFilterIpSourcePortLow OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "This is the inclusive lower bound of the transport-layer source port range that is to be matched. If the IP protocol of the packet is neither UDP nor TCP, this object is ignored during matching." DEFVAL { 0 } ::= { docsDevFilterIpEntry 12 } What do other folks think? Did I capture the new wording correctly? -- Rich -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, December 03, 2002 9:49 AM To: Woundy, Richard; ipcdn@ietf.org Cc: Raftus, David Subject: Comment on new Cable Device Mib draft Hi Rich, The following comment (see attached email) was posted on the ipcdn reflector a year ago. Would it be possible to include a change in the new draft to address this? I would like to propose that the MIBs be changed to no longer be dependant on the value of docsDevFilterIpProtocol. Since there was an ECR that explained that the fields are only applicable if relevant, all 4 port related MIBs could be made to match only relevant packets (udp and tcp), irrespective of the docsDevFilterIpProtocol value. This would therefore read something like: docsDevFilterIpSourcePortLow OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "If the protocol of the packet is udp or tcp, this is the inclusive lower bound of the transport-layer source port range that is to be matched. This table entry does not match if it is set and the packet is not tcp or udp." DEFVAL { 0 } ::= { docsDevFilterIpEntry 12 } I am flexible on the actual wording... Thanks, André From: Wim De Ketelaere [mailto:deketelaere@tcomlabs.com] Sent: Thursday, September 06, 2001 1:39 PM To: ipcdn@ietf.org Subject: [ipcdn] docsDevFilterIp requirements Hi all, In draft-ietf-ipcdn-device-mibv2-01.txt I think the definition for docsDevFilterIpSourcePort and equivalent MIBs should be clarified that in the case that docsDevFilterIpProtocol is set to "all", the port numbers need to be checked for matching if the traffic is udp or tcp as udp and tcp are included in "all", this is not clear from the current definitions. Cable operators typically want to block all TCP/UDP ports below a certain port-number, they will use any protocol, and put one port-range in. docsDevFilterIpSourcePortLow OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "If docsDevFilterIpProtocol is udp or tcp, this is the inclusive lower bound of the transport-layer source port range that is to be matched, otherwise it is ignored during matching." DEFVAL { 0 } ::= { docsDevFilterIpEntry 12 } Any comments ? Thanks, Best regards, Wim Wim De Ketelaere CTO tComLabs _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 23 11:39:34 2003 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 LAA12679 for ; Thu, 23 Jan 2003 11:39:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NGwA306924 for ipcdn-archive@odin.ietf.org; Thu, 23 Jan 2003 11:58:10 -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 h0NGw4J06887; Thu, 23 Jan 2003 11:58:04 -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 h0NGvvJ06847 for ; Thu, 23 Jan 2003 11:57:57 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12649 for ; Thu, 23 Jan 2003 11:38:48 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h0NGevTt006727 for ; Thu, 23 Jan 2003 09:40:58 -0700 (MST) Received: [from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id JAA18904 for ; Thu, 23 Jan 2003 09:42:09 -0700 (MST)] Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59) id ; Thu, 23 Jan 2003 11:42:09 -0500 Message-ID: <19CD0E423FC1D611893500508B6F0B9C084949@ma07exm01.dma.isg.mot.com> From: Murwin William-LWM008 To: "'Pollak, Lucy'" , "Docsis-Oss (E-mail)" , "IPCDN (E-mail)" Cc: "Michael W. Patrick (E-mail)" , "'Woundy, Richard'" Date: Thu, 23 Jan 2003 11:41:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C2FD.BC237EF4" Subject: [ipcdn] RE: Latest version of draft-ietf-ipcdn-qos-mib-07.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C2FD.BC237EF4 Content-Type: text/plain; charset="iso-8859-1" Thanks for the comment. Replies inline. -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Thursday, January 23, 2003 11:29 AM To: Murwin William-LWM008; Docsis-Oss (E-mail); IPCDN (E-mail) Cc: Michael W. Patrick (E-mail); 'Woundy, Richard' Subject: RE: Latest version of draft-ietf-ipcdn-qos-mib-07.txt Mike and Will, I have a number of questions/remarks: 1. I see some conflict in classifier counters definition: docsQosPktClassPkts OBJECT-TYPE DESCRIPTION "This object counts the number of packets that have been classified using this entry. This includes all packets delivered to a service flow maximum rate policing function, whether or not that function drops the packets." docsQosPktClassHCPkts OBJECT-TYPE DESCRIPTION "This object counts the number of packets that have been classified using this entry. This object does not include dropped or delayed packets. This includes all packets delivered to a service flow maximum rate policing function, whether or not that function drops the packets. If this 64-bit counter is implemented then the lower 32-bits of this counter MUST represent the corresponding 32-bits from the docsQosPktClassPkts counter." It seems that "This object does not include dropped or delayed packets" should not be in docsQosPktClassHCPkts definition. [Murwin William-LWM008] Agree. This should be removed. This is a mistake that this is present. 2. I observed some misanderstanding of docsQosParamSetMaxConcatBurst object even in CL TEPs. Please, compare: docsQosParamSetMaxConcatBurst OBJECT-TYPE DESCRIPTION ... If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default value of this object is 1522. If the parameter is not applicable, this object's value is reported as 0. docsQosParamSetMaxTrafficBurst OBJECT-TYPE DESCRIPTION ... If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default value of this object for scheduling types bestEffort (2), nonRealTimePollingService(3), and realTimePollingService(4) is 3044. If this parameter is not applicable, it is reported as 0. Both parameters are defined in RFI spec table 8-4 applicable only to bestEffort (2), nonRealTimePollingService(3) and realTimePollingService(4). It was not a matter when docsQosParamSetMaxConcatBurst default was 0. I suppose, it will be better to write: docsQosParamSetMaxConcatBurst OBJECT-TYPE DESCRIPTION ... If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default value of this object for scheduling types bestEffort (2), nonRealTimePollingService(3), and realTimePollingService(4) is 1522. If the parameter is not applicable, this object's value is reported as 0. [Murwin William-LWM008] Will change. 3. Typo error: docsQosServiceFlowPkts OBJECT-TYPE DESCRIPTION ... Unclassified upstream user date packets (i.e. non MAC-management) forwarded to the default upstream service flow should be incremented for this object. Should be "data". The same for docsQosServiceFlowHCPkts. [Murwin William-LWM008] Agree! Will also make this change. Regards. Lucy -----Original Message----- From: Murwin William-LWM008 [ mailto:W.Murwin@motorola.com ] Sent: Friday, January 17, 2003 10:42 PM To: Docsis-Oss (E-mail); IPCDN (E-mail) Cc: Michael W. Patrick (E-mail); 'Woundy, Richard' Subject: Latest version of draft-ietf-ipcdn-qos-mib-07.txt Here is the latest version of the DOCSIS-QOS MIB. This is version 7 with the back date of January 1, 2003 so as not to be confused when the draft is submitted to IETF. Please send comments and suggestion as soon as possible so that we can post this on the IETF web site. Our goal is to post the version 7 within a week. Changes are noted at the top of the draft and within the Revision History of the MIB. Thanks, Mike Patrick & Will Murwin <> ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 << File: draft-ietf-ipcdn-qos-mib-07.txt >> ------_=_NextPart_001_01C2C2FD.BC237EF4 Content-Type: text/html; charset="iso-8859-1" RE: Latest version of draft-ietf-ipcdn-qos-mib-07.txt
Thanks for the comment. Replies inline.
-----Original Message-----
From: Pollak, Lucy [mailto:Lucy.pollak@ti.com]
Sent: Thursday, January 23, 2003 11:29 AM
To: Murwin William-LWM008; Docsis-Oss (E-mail); IPCDN (E-mail)
Cc: Michael W. Patrick (E-mail); 'Woundy, Richard'
Subject: RE: Latest version of draft-ietf-ipcdn-qos-mib-07.txt

Mike and Will,
I have a number of questions/remarks:
1. I see some conflict in classifier counters definition:
docsQosPktClassPkts OBJECT-TYPE
    DESCRIPTION    "This object counts the number of packets that have
                    been classified using this entry. This includes all
                    packets delivered to a service flow maximum rate
                    policing function, whether or not that function
                    drops the packets."
docsQosPktClassHCPkts OBJECT-TYPE
    DESCRIPTION    "This object counts the number of packets that have
                    been classified using this entry. This object does
                    not include dropped or delayed packets. This
                    includes all packets delivered to a service flow
                    maximum rate policing function, whether or not that
                    function drops the packets.

                    If this 64-bit counter is implemented then the lower
                    32-bits of this counter MUST represent the corresponding
                    32-bits from the docsQosPktClassPkts counter."
It seems that "This object does not include dropped or delayed packets" should not be in docsQosPktClassHCPkts definition.
[Murwin William-LWM008] Agree. This should be removed. This is a mistake that this is present. 

2. I observed some misanderstanding of docsQosParamSetMaxConcatBurst object even in CL TEPs. Please, compare:
docsQosParamSetMaxConcatBurst OBJECT-TYPE
    DESCRIPTION    ...
                    If the referenced parameter is not present in the
                    corresponding DOCSIS QOS Parameter Set, the default
                    value of this object is 1522. If the parameter is
                    not applicable, this object's value is reported
                    as 0.

docsQosParamSetMaxTrafficBurst OBJECT-TYPE
    DESCRIPTION   ...
                    If the referenced parameter is not present in the
                    corresponding DOCSIS QOS Parameter Set, the default
                    value of this object for scheduling types
                    bestEffort (2), nonRealTimePollingService(3),
                    and realTimePollingService(4) is 3044.
                    If this parameter is not applicable, it is reported
                    as 0.
Both parameters are defined in RFI spec table 8-4 applicable only to bestEffort (2), nonRealTimePollingService(3) and realTimePollingService(4). It was not a matter when docsQosParamSetMaxConcatBurst default was 0. I suppose, it will be better to write:

docsQosParamSetMaxConcatBurst OBJECT-TYPE
    DESCRIPTION    ...
                    If the referenced parameter is not present in the
                    corresponding DOCSIS QOS Parameter Set, the default
                    value of this object for scheduling types
                    bestEffort (2), nonRealTimePollingService(3),
                    and realTimePollingService(4) is 1522. If the parameter is
                    not applicable, this object's value is reported
                    as 0.
[Murwin William-LWM008] Will change. 

3. Typo error:
docsQosServiceFlowPkts OBJECT-TYPE
    DESCRIPTION    ...
                    Unclassified upstream user date packets (i.e. non
                    MAC-management) forwarded to the default upstream
                    service flow should be incremented for this object.
Should be "data". The same for docsQosServiceFlowHCPkts.
[Murwin William-LWM008] Agree! Will also make this change. 

Regards.
Lucy

-----Original Message-----
From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com]
Sent: Friday, January 17, 2003 10:42 PM
To: Docsis-Oss (E-mail); IPCDN (E-mail)
Cc: Michael W. Patrick (E-mail); 'Woundy, Richard'
Subject: Latest version of draft-ietf-ipcdn-qos-mib-07.txt


Here is the latest version of the DOCSIS-QOS MIB.
This is version 7 with the back date of January 1, 2003 so as not to be confused when the draft is submitted to IETF.

Please send comments and suggestion as soon as possible so that we can post this on the IETF web site.
Our goal is to post the version 7 within a week.

Changes are noted at the top of the draft and within the Revision History of the MIB.

Thanks,
Mike Patrick &  Will Murwin

 <<draft-ietf-ipcdn-qos-mib-07.txt>>
______________________________
William Murwin
Broadband Communications Sector
Motorola Inc.
Email: W.Murwin@motorola.com
Tel: (508) 851-8385
 << File: draft-ietf-ipcdn-qos-mib-07.txt >>

------_=_NextPart_001_01C2C2FD.BC237EF4-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 23 16:45:42 2003 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 QAA21037 for ; Thu, 23 Jan 2003 16:45:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NM4Of28433 for ipcdn-archive@odin.ietf.org; Thu, 23 Jan 2003 17:04:24 -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 h0NM4KJ28388; Thu, 23 Jan 2003 17:04:20 -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 h0NFdxJ01132 for ; Thu, 23 Jan 2003 10:39:59 -0500 Received: from util.ext.ti.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09941 for ; Thu, 23 Jan 2003 10:20:52 -0500 (EST) Received: from dlep6.itg.ti.com ([157.170.188.9]) by util.ext.ti.com (8.12.6/8.12.6) with ESMTP id h0NFOFPS013374; Thu, 23 Jan 2003 09:24:15 -0600 (CST) Received: from dlep6.itg.ti.com (localhost [127.0.0.1]) by dlep6.itg.ti.com (8.9.3/8.9.3) with ESMTP id JAA03246; Thu, 23 Jan 2003 09:24:13 -0600 (CST) Received: from dlep98.itg.ti.com (dlep98.itg.ti.com [157.170.134.104]) by dlep6.itg.ti.com (8.9.3/8.9.3) with ESMTP id JAA03210; Thu, 23 Jan 2003 09:24:12 -0600 (CST) Received: from dile70.itg.ti.com (dile70.itg.ti.com [137.167.177.22]) by dlep98.itg.ti.com (8.9.3/8.9.3) with ESMTP id JAA03703; Thu, 23 Jan 2003 09:24:02 -0600 (CST) Received: by dile70.itg.ti.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 17:24:01 +0200 Message-ID: <7DF2A1B372BBD611912F00508BDFBA9A9C185A@dile03.itg.ti.com> From: "Pollak, Lucy" To: "'Woundy, Richard'" , "'Lejeune, Andre'" Cc: "IPCDN WG (E-mail)" , "DOCSIS OSS (E-mail)" Subject: RE: [ipcdn] RE: Comment on new Cable Device Mib draft Date: Thu, 23 Jan 2003 17:23:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0NFdxJ01133 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Rich, I agree with your changes, this is very clear. I guess, it is better to leave syntax as is. It is more readable taking into account DEFVALs 0 and 65535. What do you think? Regards. Lucy -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Wednesday, January 22, 2003 11:53 PM To: Pollak, Lucy; 'Lejeune, Andre' Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) Subject: RE: [ipcdn] RE: Comment on new Cable Device Mib draft Folks, After considering the comments from Lucy and Andre below, I propose the following simple Cable Device MIB changes. See for the latest full draft proposal. docsDevFilterIpSourcePortLow OBJECT-TYPE -- SYNTAX Integer32 (0..65535) SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "This is the inclusive lower bound of the transport-layer source port range that is to be matched. If the IP protocol of the packet is neither UDP nor TCP, this object is ignored during matching." DEFVAL { 0 } ::= { docsDevFilterIpEntry 12 } docsDevFilterIpSourcePortHigh OBJECT-TYPE -- SYNTAX Integer32 (0..65535) SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "This is the inclusive upper bound of the transport-layer source port range that is to be matched. If the IP protocol of the packet is neither UDP nor TCP, this object is ignored during matching." DEFVAL { 65535 } ::= { docsDevFilterIpEntry 13 } docsDevFilterIpDestPortLow OBJECT-TYPE -- SYNTAX Integer32 (0..65535) SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "This is the inclusive lower bound of the transport-layer destination port range that is to be matched. If the IP protocol of the packet is neither UDP nor TCP, this object is ignored during matching." DEFVAL { 0 } ::= { docsDevFilterIpEntry 14 } docsDevFilterIpDestPortHigh OBJECT-TYPE -- SYNTAX Integer32 (0..65535) SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "This is the inclusive upper bound of the transport-layer destination port range that is to be matched. If the IP protocol of the packet is neither UDP nor TCP, this object is ignored during matching." DEFVAL { 65535 } ::= { docsDevFilterIpEntry 15 } Note that I assert that I can convert existing objects from SYNTAX "Integer32 (0..65535)" to "InetPortNumber" without an OID renumbering. According to RFC 2578 section 10.2: (2) The value of a SYNTAX clause may be replaced by a textual convention, providing the textual convention is defined to use the same primitive ASN.1 type, has the same set of values, and has identical semantics. The common primitive ASN.1 type for both SYNTAXes is "INTEGER", the range of values for both SYNTAXes is "(0..65535)", and the semantics are identical. -- Rich -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, December 25, 2002 12:18 PM To: Woundy, Richard; 'Lejeune, Andre'; ipcdn@ietf.org; DOCSIS OSS (E-mail) Subject: RE: [ipcdn] RE: Comment on new Cable Device Mib draft Rich, I disagree with André. This issue was discussed with CL a number of times, this is correct. But I also remember that there was not consensus how to treat this problem. André's mail from 6/9/01 was unanswered in OSS reflector at least. Even if André's statistic is correct, 50% of vendors need to change their implementations. To do what André propose (filter row will not match if fields are irrelevant), we need to add BIT mask of settled fields as we do it in classifier. This will not be backward compatible to 100% of vendors. The MIB compliant CM must "ignore during matching" port fields if docsDevFilterIpProtocol is not "udp or tcp" in accordance with current MIB text. The only one problem in the text is that docsDevFilterIpProtocol =256(any) is not covered in description. I suppose we should not change the policy to differently opposite, only to clarify it. I agree, that classifiers and filters treat similar fields differently. But I also do not see any problem with this. Each of them are intended to strictly different things. I guess, that the better clarification may be: "If packet's Ip protocol is udp or tcp, this is the inclusive lower bound of the transport-layer source port range that is to be matched, otherwise it is ignored during matching." Thanks. Lucy -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Tuesday, December 24, 2002 6:42 PM To: 'Lejeune, Andre'; ipcdn@ietf.org; DOCSIS OSS (E-mail) Subject: RE: [ipcdn] RE: Comment on new Cable Device Mib draft Andre and other filtering/classification experts, I'm not sure how to resolve Andre's objection in the email below, other than broaden the audience and solicit the opinions of other folks. My perspective is that the definition of the docsDevFilterIpTable is driven by the requirements of the DOCSIS RFI, not vice versa. I also had an informal chat with Matt Schmitt, the author of RFI-N-02115 that is cited below. Matt pointed out that (unfortunately) there has been a different set of packet matching rules for the DOCSIS QoS classifiers (per the ECN) and the docsDevFilterIpTable. Hence, I have been confused about how to resolve Andre's objection. If some folks could help me provide some agreeable new DESCRIPTIONs for docsDevFilterIpSourcePortLow and other Cable Device MIB objects, so they meet CableLabs requirements and don't cause backward compatability problems, I would be very grateful. I would like to publish a working-group last-call-ready version of the Cable Device MIB by January 20th. -- Rich -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, December 03, 2002 4:07 PM To: Woundy, Richard Cc: ipcdn@ietf.org; Raftus, David Subject: [ipcdn] RE: Comment on new Cable Device Mib draft Rich, I know that in the field, some config files are setting protocol to 256 and setting the ports to what they want, and they expect the packets that are not udp or tcp to not match with the filter entry. This is the reason I went through the archive and sent you this comment, btw. This MSO told me that they have 50% of the modems behaving as they expect (matching to the packet) and the other 50% behaving the opposite (matching to the filter protocol). What I am trying to achieve with my wording is to stay along the lines of RFI-N-02115 (attached), which clarified this kind of situation for classifiers. I also understand your comment about the object always being set. But if we go with your definition, currently deployed config files may stop working for some MSOs and that worries me. What about requiring the *Low values to be non-0 or the *High to be non-65535 for both the *Low and *High values to be applicable? Thanks a lot, André -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Tuesday, December 03, 2002 2:04 PM To: 'Lejeune, Andre' Cc: ipcdn@ietf.org; Raftus, David Subject: RE: Comment on new Cable Device Mib draft Andre, I must have missed the original comment from Wim. Sorry. Your proposed modifications to the Cable Device MIB seems reasonably OK to me, with slight wording corrections. In particular, you cannot say "This table entry does not match if [this object] is set and the packet is not tcp or udp", because the DEFVAL clauses ensure that these columns are always "set". If you want to ignore all non-TCP/UDP packets in this row of the IP filter table, then I think you need to set docsDevFilterIpProtocol to the appropriate value. docsDevFilterIpSourcePortLow OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "This is the inclusive lower bound of the transport-layer source port range that is to be matched. If the IP protocol of the packet is neither UDP nor TCP, this object is ignored during matching." DEFVAL { 0 } ::= { docsDevFilterIpEntry 12 } What do other folks think? Did I capture the new wording correctly? -- Rich -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, December 03, 2002 9:49 AM To: Woundy, Richard; ipcdn@ietf.org Cc: Raftus, David Subject: Comment on new Cable Device Mib draft Hi Rich, The following comment (see attached email) was posted on the ipcdn reflector a year ago. Would it be possible to include a change in the new draft to address this? I would like to propose that the MIBs be changed to no longer be dependant on the value of docsDevFilterIpProtocol. Since there was an ECR that explained that the fields are only applicable if relevant, all 4 port related MIBs could be made to match only relevant packets (udp and tcp), irrespective of the docsDevFilterIpProtocol value. This would therefore read something like: docsDevFilterIpSourcePortLow OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "If the protocol of the packet is udp or tcp, this is the inclusive lower bound of the transport-layer source port range that is to be matched. This table entry does not match if it is set and the packet is not tcp or udp." DEFVAL { 0 } ::= { docsDevFilterIpEntry 12 } I am flexible on the actual wording... Thanks, André From: Wim De Ketelaere [mailto:deketelaere@tcomlabs.com] Sent: Thursday, September 06, 2001 1:39 PM To: ipcdn@ietf.org Subject: [ipcdn] docsDevFilterIp requirements Hi all, In draft-ietf-ipcdn-device-mibv2-01.txt I think the definition for docsDevFilterIpSourcePort and equivalent MIBs should be clarified that in the case that docsDevFilterIpProtocol is set to "all", the port numbers need to be checked for matching if the traffic is udp or tcp as udp and tcp are included in "all", this is not clear from the current definitions. Cable operators typically want to block all TCP/UDP ports below a certain port-number, they will use any protocol, and put one port-range in. docsDevFilterIpSourcePortLow OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "If docsDevFilterIpProtocol is udp or tcp, this is the inclusive lower bound of the transport-layer source port range that is to be matched, otherwise it is ignored during matching." DEFVAL { 0 } ::= { docsDevFilterIpEntry 12 } Any comments ? Thanks, Best regards, Wim Wim De Ketelaere CTO tComLabs _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 23 16:45:43 2003 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 QAA21045 for ; Thu, 23 Jan 2003 16:45:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NM4Pr28446 for ipcdn-archive@odin.ietf.org; Thu, 23 Jan 2003 17:04:25 -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 h0NM4NJ28420; Thu, 23 Jan 2003 17:04:23 -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 h0NGljJ06180 for ; Thu, 23 Jan 2003 11:47:45 -0500 Received: from go4.ext.ti.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12251 for ; Thu, 23 Jan 2003 11:28:37 -0500 (EST) Received: from dlep51.itg.ti.com ([157.170.141.75]) by go4.ext.ti.com (8.12.6/8.12.6) with ESMTP id h0NGVnUw021211; Thu, 23 Jan 2003 10:31:49 -0600 (CST) Received: from dlep98.itg.ti.com (localhost [127.0.0.1]) by dlep51.itg.ti.com (8.12.6/8.12.6) with ESMTP id h0NGVmJG026798; Thu, 23 Jan 2003 10:31:49 -0600 (CST) Received: from dile70.itg.ti.com (dile70.itg.ti.com [137.167.177.22]) by dlep98.itg.ti.com (8.9.3/8.9.3) with ESMTP id KAA16128; Thu, 23 Jan 2003 10:29:47 -0600 (CST) Received: by dile70.itg.ti.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 18:29:16 +0200 Message-ID: <7DF2A1B372BBD611912F00508BDFBA9A9C185B@dile03.itg.ti.com> From: "Pollak, Lucy" To: "'Murwin William-LWM008'" , "Docsis-Oss (E-mail)" , "IPCDN (E-mail)" Cc: "Michael W. Patrick (E-mail)" , "'Woundy, Richard'" Date: Thu, 23 Jan 2003 18:29:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C2FC.91BFCEDE" Subject: [ipcdn] RE: Latest version of draft-ietf-ipcdn-qos-mib-07.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C2FC.91BFCEDE Content-Type: text/plain; charset="iso-8859-1" Mike and Will, I have a number of questions/remarks: 1. I see some conflict in classifier counters definition: docsQosPktClassPkts OBJECT-TYPE DESCRIPTION "This object counts the number of packets that have been classified using this entry. This includes all packets delivered to a service flow maximum rate policing function, whether or not that function drops the packets." docsQosPktClassHCPkts OBJECT-TYPE DESCRIPTION "This object counts the number of packets that have been classified using this entry. This object does not include dropped or delayed packets. This includes all packets delivered to a service flow maximum rate policing function, whether or not that function drops the packets. If this 64-bit counter is implemented then the lower 32-bits of this counter MUST represent the corresponding 32-bits from the docsQosPktClassPkts counter." It seems that "This object does not include dropped or delayed packets" should not be in docsQosPktClassHCPkts definition. 2. I observed some misanderstanding of docsQosParamSetMaxConcatBurst object even in CL TEPs. Please, compare: docsQosParamSetMaxConcatBurst OBJECT-TYPE DESCRIPTION ... If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default value of this object is 1522. If the parameter is not applicable, this object's value is reported as 0. docsQosParamSetMaxTrafficBurst OBJECT-TYPE DESCRIPTION ... If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default value of this object for scheduling types bestEffort (2), nonRealTimePollingService(3), and realTimePollingService(4) is 3044. If this parameter is not applicable, it is reported as 0. Both parameters are defined in RFI spec table 8-4 applicable only to bestEffort (2), nonRealTimePollingService(3) and realTimePollingService(4). It was not a matter when docsQosParamSetMaxConcatBurst default was 0. I suppose, it will be better to write: docsQosParamSetMaxConcatBurst OBJECT-TYPE DESCRIPTION ... If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default value of this object for scheduling types bestEffort (2), nonRealTimePollingService(3), and realTimePollingService(4) is 1522. If the parameter is not applicable, this object's value is reported as 0. 3. Typo error: docsQosServiceFlowPkts OBJECT-TYPE DESCRIPTION ... Unclassified upstream user date packets (i.e. non MAC-management) forwarded to the default upstream service flow should be incremented for this object. Should be "data". The same for docsQosServiceFlowHCPkts. Regards. Lucy -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Friday, January 17, 2003 10:42 PM To: Docsis-Oss (E-mail); IPCDN (E-mail) Cc: Michael W. Patrick (E-mail); 'Woundy, Richard' Subject: Latest version of draft-ietf-ipcdn-qos-mib-07.txt Here is the latest version of the DOCSIS-QOS MIB. This is version 7 with the back date of January 1, 2003 so as not to be confused when the draft is submitted to IETF. Please send comments and suggestion as soon as possible so that we can post this on the IETF web site. Our goal is to post the version 7 within a week. Changes are noted at the top of the draft and within the Revision History of the MIB. Thanks, Mike Patrick & Will Murwin <> ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 << File: draft-ietf-ipcdn-qos-mib-07.txt >> ------_=_NextPart_001_01C2C2FC.91BFCEDE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Latest version of draft-ietf-ipcdn-qos-mib-07.txt

Mike and Will,
I have a number of = questions/remarks:
1. I see some conflict in classifier = counters definition:
docsQosPktClassPkts = OBJECT-TYPE
    = DESCRIPTION    "This object counts the number of = packets that have
         &nb= sp;          been = classified using this entry. This includes all
         &nb= sp;          packets = delivered to a service flow maximum rate
         &nb= sp;          policing = function, whether or not that function
         &nb= sp;          drops the = packets."
docsQosPktClassHCPkts = OBJECT-TYPE
    = DESCRIPTION    "This object counts the number of = packets that have
         &nb= sp;          been = classified using this entry. This object does
         &nb= sp;          not include = dropped or delayed packets. This
         &nb= sp;          includes all = packets delivered to a service flow
         &nb= sp;          maximum rate = policing function, whether or not that
         &nb= sp;          function = drops the packets.

         &nb= sp;          If this = 64-bit counter is implemented then the lower
         &nb= sp;          32-bits of = this counter MUST represent the corresponding
         &nb= sp;          32-bits from = the docsQosPktClassPkts counter."
It seems that = "This object = does not include dropped or delayed packets" should not be in docsQosPktClassHCPkts definition.

2. I observed some misanderstanding of = docsQosParamSetMaxConcatBurst object even in CL TEPs. Please, = compare:
docsQosParamSetMaxConcatBurst = OBJECT-TYPE
    = DESCRIPTION    ...
         &nb= sp;          If the = referenced parameter is not present in the
         &nb= sp;          corresponding = DOCSIS QOS Parameter Set, the default
         &nb= sp;          value of this = object is 1522. If the parameter is
         &nb= sp;          not = applicable, this object's value is reported
         &nb= sp;          as 0.

docsQosParamSetMaxTrafficBurst = OBJECT-TYPE
    = DESCRIPTION   ...
         &nb= sp;          If the = referenced parameter is not present in the
         &nb= sp;          corresponding = DOCSIS QOS Parameter Set, the default
         &nb= sp;          value of this = object for scheduling types
         &nb= sp;          bestEffort = (2), nonRealTimePollingService(3),
         &nb= sp;          and = realTimePollingService(4) is 3044.
         &nb= sp;          If this = parameter is not applicable, it is reported
         &nb= sp;          as 0.=20
Both parameters are defined in RFI = spec table 8-4 applicable only to bestEffort (2), = nonRealTimePollingService(3) and realTimePollingService(4). It was not = a matter when docsQosParamSetMaxConcatBurst default was 0. I suppose, = it will be better to write:

docsQosParamSetMaxConcatBurst = OBJECT-TYPE
    = DESCRIPTION    ...
         &nb= sp;          If the = referenced parameter is not present in the
         &nb= sp;          corresponding = DOCSIS QOS Parameter Set, the default
         &nb= sp;          value of this = object for scheduling types
         &nb= sp;          bestEffort = (2), nonRealTimePollingService(3),
         &nb= sp;          and = realTimePollingService(4) is 1522. If the parameter is
         &nb= sp;          not = applicable, this object's value is reported
         &nb= sp;          as 0.

3. Typo error:
docsQosServiceFlowPkts = OBJECT-TYPE
    = DESCRIPTION    ...
         &nb= sp;          Unclassified = upstream user date packets = (i.e. non
         &nb= sp;          = MAC-management) forwarded to the default upstream
         &nb= sp;          service flow = should be incremented for this object.
Should be "data". The same = for docsQosServiceFlowHCPkts.

Regards.
Lucy

-----Original Message-----
From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com]<= /FONT>
Sent: Friday, January 17, 2003 10:42 = PM
To: Docsis-Oss (E-mail); IPCDN = (E-mail)
Cc: Michael W. Patrick (E-mail); = 'Woundy, Richard'
Subject: Latest version of = draft-ietf-ipcdn-qos-mib-07.txt


Here is the latest version of the = DOCSIS-QOS MIB.
This is version 7 with the back date = of January 1, 2003 so as not to be confused when the draft is submitted = to IETF.

Please send comments and suggestion as = soon as possible so that we can post this on the IETF web site.
Our goal is to post the version 7 = within a week.

Changes are noted at the top of the = draft and within the Revision History of the MIB.

Thanks,
Mike Patrick &  Will = Murwin

 <<draft-ietf-ipcdn-qos-mib-07.txt>> =
______________________________
William Murwin
Broadband Communications = Sector
Motorola Inc.
Email: W.Murwin@motorola.com
Tel: (508) 851-8385
 << File: = draft-ietf-ipcdn-qos-mib-07.txt >>

------_=_NextPart_001_01C2C2FC.91BFCEDE-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 23 18:55:30 2003 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 SAA24744 for ; Thu, 23 Jan 2003 18:55:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0O0EDw05203 for ipcdn-archive@odin.ietf.org; Thu, 23 Jan 2003 19:14:13 -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 h0O0ECJ05192; Thu, 23 Jan 2003 19:14:12 -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 h0O0DTJ05171 for ; Thu, 23 Jan 2003 19:13:29 -0500 Received: from mail.correlant.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24730 for ; Thu, 23 Jan 2003 18:54:14 -0500 (EST) Received: from kfriedman (67.82.218.209.transedge.com [209.218.82.67]) by mail.correlant.com (Postfix) with SMTP id 0D91EBC104; Thu, 23 Jan 2003 15:57:21 -0800 (PST) From: "Kirk Friedman" To: "'Murwin William-LWM008'" , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Cc: "'Michael W. Patrick (E-mail)'" , "'Woundy, Richard'" Subject: RE: [ipcdn] Latest version of draft-ietf-ipcdn-qos-mib-07.txt Date: Thu, 23 Jan 2003 15:57:37 -0800 Message-ID: <006201c2c33b$353137e0$4352dad1@correlant.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <19CD0E423FC1D611893500508B6F0B9C084937@ma07exm01.dma.isg.mot.com> Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Murwin, A couple of minor nits: 1) Section 2.2.2.1 item 1) includes "When a CM initially ranges, both the CM and CMTS implement a row in DOCS-IF-MIB docsIfCmServiceTable corresponding to..." The CMTS does not support docsIfCmServiceTable. Suggest "When a CM initially ranges, the CM implements a row in the DOCS-IF-MIB docsIfCmServiceTable and the CMTS implements a row in the docsIfCmtsServiceTable corresponding to..." 2) In the same section, item 3) the CMTS should retain the docsIfCmtsServiceTable entry for the DOCSIS 1.1 CM. This would mirror the CM requirement. Thanks, Kirk Friedman Correlant Communications 15110 Avenue Of Science San Diego, CA., 92128 -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, January 17, 2003 12:42 PM To: Docsis-Oss (E-mail); IPCDN (E-mail) Cc: Michael W. Patrick (E-mail); 'Woundy, Richard' Subject: [ipcdn] Latest version of draft-ietf-ipcdn-qos-mib-07.txt Here is the latest version of the DOCSIS-QOS MIB. This is version 7 with the back date of January 1, 2003 so as not to be confused when the draft is submitted to IETF. Please send comments and suggestion as soon as possible so that we can post this on the IETF web site. Our goal is to post the version 7 within a week. Changes are noted at the top of the draft and within the Revision History of the MIB. Thanks, Mike Patrick & Will Murwin <> ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Jan 24 07:58:39 2003 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 HAA17497 for ; Fri, 24 Jan 2003 07:58:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ODHcO29468 for ipcdn-archive@odin.ietf.org; Fri, 24 Jan 2003 08:17:38 -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 h0ODHWJ29463; Fri, 24 Jan 2003 08:17:32 -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 h0ODG4J29407 for ; Fri, 24 Jan 2003 08:16:04 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17287; Fri, 24 Jan 2003 07:56:34 -0500 (EST) Message-Id: <200301241256.HAA17287@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 24 Jan 2003 07:56:34 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-08.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management Author(s) : W. Sawyer Filename : draft-ietf-ipcdn-subscriber-mib-08.txt Pages : 28 Date : 2003-1-23 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for SNMP-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the author. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-subscriber-mib-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-subscriber-mib-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-23093942.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-subscriber-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-subscriber-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-23093942.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Jan 24 11:26:09 2003 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 LAA24086 for ; Fri, 24 Jan 2003 11:26:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OGjEk11611 for ipcdn-archive@odin.ietf.org; Fri, 24 Jan 2003 11:45:14 -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 h0OGjDJ11604; Fri, 24 Jan 2003 11:45:13 -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 h0OGirJ11581 for ; Fri, 24 Jan 2003 11:44:53 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24078 for ; Fri, 24 Jan 2003 11:25:17 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h0OGRVFx028243 for ; Fri, 24 Jan 2003 09:27:32 -0700 (MST) Received: [from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id JAA05382 for ; Fri, 24 Jan 2003 09:28:44 -0700 (MST)] Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59) id ; Fri, 24 Jan 2003 11:28:44 -0500 Message-ID: <19CD0E423FC1D611893500508B6F0B9C084951@ma07exm01.dma.isg.mot.com> From: Murwin William-LWM008 To: "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Date: Fri, 24 Jan 2003 11:28:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Jan 24 21:44:40 2003 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 VAA08195 for ; Fri, 24 Jan 2003 21:44:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0P33vt15133 for ipcdn-archive@odin.ietf.org; Fri, 24 Jan 2003 22:03:57 -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 h0P32AJ15075; Fri, 24 Jan 2003 22:02:10 -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 h0P31xJ15059 for ; Fri, 24 Jan 2003 22:01:59 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08138 for ; Fri, 24 Jan 2003 21:42:11 -0500 (EST) Received: from mms02-relaya.tci.com (mms02-relaya.broadband.att.com [147.191.89.206]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h0P2jdst004444 for ; Fri, 24 Jan 2003 19:45:39 -0700 (MST) Received: from 147.191.90.10 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Fri, 24 Jan 2003 19:45:34 -0600 Received: by entexchimc03.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 24 Jan 2003 19:44:25 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056635A3@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'ipcdn@ietf.org'" Date: Fri, 24 Jan 2003 19:45:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 122F25C4569495-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] IPCDN WG Updates Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, The following two DOCSIS internet-drafts were submitted this week: draft-ietf-ipcdn-subscriber-mib-08.txt , and draft-ietf-ipcdn-device-mibv2-04.txt . Also, all five existing CableHome internet drafts were updated, and a sixth for a new CableHome QoS MIB was submitted this week. draft-jones-cable-gateway-addressing-01.txt draft-jones-cable-gateway-config-mib-01.txt draft-jones-cable-gateway-device-mib-01.txt draft-jones-cable-gateway-qos-mib-00.txt draft-jones-cable-gateway-security-mib-01.txt draft-jones-cable-gateway-tools-mib-01.txt As a result, I have updated . Note that it may take a few business days from now until the internet-drafts are posted. I am also working with the authors of the DOCSIS Event Notification MIB and the DOCSIS QoS MIB to get updated internet-drafts submitted by the middle of next week. Note that the RFI MIB was refreshed in December. That means we should be able to review at least four of the five DOCSIS MIBs for working group last-call by the interim meeting in February. And hopefully we should be able to get MIB doctor approval for the Subscriber Management MIB shortly. -- Richard Woundy, IPCDN Co-Chair _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Jan 24 22:01:31 2003 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 WAA08401 for ; Fri, 24 Jan 2003 22:01:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0P3KmH16332 for ipcdn-archive@odin.ietf.org; Fri, 24 Jan 2003 22:20:48 -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 h0P3J3J16219; Fri, 24 Jan 2003 22:19:03 -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 h0P3IgJ16204 for ; Fri, 24 Jan 2003 22:18:42 -0500 Received: from peacock280.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08322 for ; Fri, 24 Jan 2003 21:58:54 -0500 (EST) Received: from mms02-relaya.tci.com (mms02-relaya.broadband.att.com [147.191.89.206]) by peacock280.tci.com (8.12.2/8.12.2) with ESMTP id h0P32LIN023672 for ; Fri, 24 Jan 2003 20:02:21 -0700 (MST) Received: from 147.191.89.201 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Fri, 24 Jan 2003 20:02:17 -0600 Received: by entexchimc02.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 24 Jan 2003 20:02:04 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056635A5@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'ipcdn@ietf.org'" Date: Fri, 24 Jan 2003 20:02:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 122F21B3570417-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] Final edits to draft-ietf-ipcdn-device-mibv2-04.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I made mostly editorial changes between the last posted version of the updated DOCSIS Cable Device MIB, and the version I submitted to IETF, which you can find at . Besides some really minor editorial nits, I made the following tweaks: - I increased the number of groups in the "Structure of the MIB" section from seven to eight, and added a paragraph about the docsDevVacmAccessExt group. - I purged out Integer32 for InetPortNumber for the port number objects, completely. No turning back. ;^) - I added a MIB comment naming the OID for the old conformance statements. - I changed the compliance DESCRIPTION for docsDevNmAccessGroupV2, emphasizing that these objects are needed only for backward compatibility. - I updated the LAST-UPDATED and REVISION clauses for the MIB. The new draft should show up on the IETF reflectors in a few business days. -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Mon Jan 27 15:54:54 2003 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 PAA26206 for ; Mon, 27 Jan 2003 15:54:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RLFVn17554 for ipcdn-archive@odin.ietf.org; Mon, 27 Jan 2003 16:15:31 -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 h0RLFTJ17549; Mon, 27 Jan 2003 16:15:29 -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 h0RLETJ17512 for ; Mon, 27 Jan 2003 16:14:29 -0500 Received: from mms2.broadcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26164 for ; Mon, 27 Jan 2003 15:53:21 -0500 (EST) Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom MMS1 SMTP Relay (MMS v5.5.0)); Mon, 27 Jan 2003 12:54:03 -0700 Received: from ltatlamdolas (dhcp-10-24-65-44.atlanta.broadcom.com [10.24.65.44]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with SMTP id MAA27504; Mon, 27 Jan 2003 12:56:42 -0800 (PST) From: "Margo Dolas" To: "Murwin William-LWM008" , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Mon, 27 Jan 2003 15:56:46 -0500 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <19CD0E423FC1D611893500508B6F0B9C084951@ma07exm01.dma.isg.mot.com> X-WSS-ID: 122B43E150843-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Mon Jan 27 16:13:30 2003 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 QAA27106 for ; Mon, 27 Jan 2003 16:13:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RLY7218114 for ipcdn-archive@odin.ietf.org; Mon, 27 Jan 2003 16:34:07 -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 h0RLY5J18107; Mon, 27 Jan 2003 16:34:05 -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 h0RLXvJ18092 for ; Mon, 27 Jan 2003 16:33:57 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27079 for ; Mon, 27 Jan 2003 16:12:47 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h0RLF0a8018788 for ; Mon, 27 Jan 2003 14:15:00 -0700 (MST) Received: [from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id OAA05577 for ; Mon, 27 Jan 2003 14:16:15 -0700 (MST)] Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 27 Jan 2003 16:16:15 -0500 Message-ID: <19CD0E423FC1D611893500508B6F0B9C084957@ma07exm01.dma.isg.mot.com> From: Murwin William-LWM008 To: "'Margo Dolas'" , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Mon, 27 Jan 2003 16:16:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Mon Jan 27 16:40:45 2003 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 QAA27957 for ; Mon, 27 Jan 2003 16:40:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RM1MB20324 for ipcdn-archive@odin.ietf.org; Mon, 27 Jan 2003 17:01:22 -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 h0RM1AJ20311; Mon, 27 Jan 2003 17:01:10 -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 h0RM0gJ20075 for ; Mon, 27 Jan 2003 17:00:42 -0500 Received: from mms3.broadcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27928 for ; Mon, 27 Jan 2003 16:39:33 -0500 (EST) Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom MMS1 SMTP Relay (MMS v5.5.0)); Mon, 27 Jan 2003 13:43:04 -0700 Received: from ltatlamdolas (dhcp-10-24-65-44.atlanta.broadcom.com [10.24.65.44]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with SMTP id NAA04170; Mon, 27 Jan 2003 13:42:52 -0800 (PST) From: "Margo Dolas" To: "Murwin William-LWM008" , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Mon, 27 Jan 2003 16:42:56 -0500 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <19CD0E423FC1D611893500508B6F0B9C084957@ma07exm01.dma.isg.mot.com> X-WSS-ID: 122B786251727-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 06:49:16 2003 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 GAA22004 for ; Tue, 28 Jan 2003 06:49:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SCABg14004 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 07:10:11 -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 h0SCAAJ13997; Tue, 28 Jan 2003 07:10:10 -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 h0SC6bJ13238 for ; Tue, 28 Jan 2003 07:06:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21811; Tue, 28 Jan 2003 06:45:11 -0500 (EST) Message-Id: <200301281145.GAA21811@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 28 Jan 2003 06:45:11 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-device-mibv2-04.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems Author(s) : R. Woundy Filename : draft-ietf-ipcdn-device-mibv2-04.txt Pages : 71 Date : 2003-1-27 This memo is a draft revision of the standards track RFC-2669. Please see 'Revision Descriptions' below for a description of changes. This document will obsolete RFC-2669 when accepted. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS compliant Cable Modems and Cable Modem Termination Systems. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the author. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-device-mibv2-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-device-mibv2-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-27081536.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-device-mibv2-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-device-mibv2-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-27081536.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 12:07:56 2003 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 MAA01313 for ; Tue, 28 Jan 2003 12:07:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SHSwH04217 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 12:28:58 -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 h0SHSsJ04210; Tue, 28 Jan 2003 12:28:54 -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 h0SHRvJ04173 for ; Tue, 28 Jan 2003 12:27:57 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01273 for ; Tue, 28 Jan 2003 12:06:23 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h0SHAQqO005447 for ; Tue, 28 Jan 2003 10:10:26 -0700 (MST) Received: [from ca25exm01.GI.COM (ca25exm01.gi.com [168.84.84.121]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id KAA01225 for ; Tue, 28 Jan 2003 10:09:53 -0700 (MST)] Received: by ca25exm01 with Internet Mail Service (5.5.2656.59) id ; Tue, 28 Jan 2003 09:09:53 -0800 Message-ID: From: Marez Kevin-MGI1375 To: "'Woundy, Richard'" , Nakanishi Greg-MGI8179 Cc: "IPCDN WG (E-mail)" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Date: Tue, 28 Jan 2003 09:09:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Rich, I understand the scenario you have presented, however, I think MSOs would typically use a private networking space for the RF-side and explicitly prevent access from outside that space. Our concern here is that we are adding an additional level of complexity to the vacmAccess table that doesn't provide a great deal of benefit. Greg, please respond I have misstated anything or if you have anything you'd like to add. Thanks very much, Kevin -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Wednesday, January 22, 2003 3:59 PM To: 'Marez Kevin-MGI1375' Cc: IPCDN WG (E-mail) Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Kevin, Here is my comment on the VACM issue: >10) docsDevVacmAccessExtTable - Is this table really needed when using >SNMPv3? The limited security provided in SNMPv1/2 necessitated having >this functionality in the nmAccessTable. Given SNMPv3 security, it >doesn't seem like this functionality is necessary anymore. I would agree that it is better security to authenticate a keyed hash via SNMPv3, than to rely on the incoming device interface for implied user identification. However, one interesting and important case is a CM diagnostic interface for subscriber-side queries, after the CM registration process is completed. It seems quite useful to allow subscriber tools (with SNMPv3 securityLevel of noAuthNoPriv) to query cable modems over the CMCI (CPE interface) but not over the RFI (RF interface). -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 12:40:24 2003 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 MAA01997 for ; Tue, 28 Jan 2003 12:40:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SI1QJ06187 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 13:01:26 -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 h0SI17J06170; Tue, 28 Jan 2003 13:01:07 -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 h0SI0oJ06107 for ; Tue, 28 Jan 2003 13:00:50 -0500 Received: from motgate5.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01973 for ; Tue, 28 Jan 2003 12:39:16 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h0SHggUV016170 for ; Tue, 28 Jan 2003 10:42:43 -0700 (MST) Received: [from ca25exm01.GI.COM (ca25exm01.gi.com [168.84.84.121]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA02823 for ; Tue, 28 Jan 2003 10:42:45 -0700 (MST)] Received: by ca25exm01 with Internet Mail Service (5.5.2656.59) id ; Tue, 28 Jan 2003 09:42:45 -0800 Message-ID: From: Nakanishi Greg-MGI8179 To: "'IPCDN WG (E-mail)'" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Date: Tue, 28 Jan 2003 09:42:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Kevin, I think your point is accurate. Just to expand upon it some... Typically a CM will get a private IP address via DHCP. This results in access to the CM through the HFC interface being limited to within the MSO's private IP network. "Outsiders" (e.g. user's on the CMCI-side or on the Internet) will not be able to access a CM through the HFC interface. Access to the CM from the CMCI interface is still allowed if the proper SNMP access controls are setup. I want to make sure that this proposed extension to the VACM table provides a good benefit over what is acheivable today with the mechanisms we already have. greg > -----Original Message----- > From: Marez Kevin-MGI1375 > Sent: Tuesday, January 28, 2003 9:10 AM > To: 'Woundy, Richard'; Nakanishi Greg-MGI8179 > Cc: IPCDN WG (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Rich, > > I understand the scenario you have presented, however, I > think MSOs would typically use a private networking space for > the RF-side and explicitly prevent access from outside that space. > > Our concern here is that we are adding an additional level of > complexity to the vacmAccess table that doesn't provide a > great deal of benefit. > > Greg, please respond I have misstated anything or if you have > anything you'd like to add. Thanks very much, > > Kevin > > > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Wednesday, January 22, 2003 3:59 PM > To: 'Marez Kevin-MGI1375' > Cc: IPCDN WG (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Kevin, > > Here is my comment on the VACM issue: > > >10) docsDevVacmAccessExtTable - Is this table really needed > when using > >SNMPv3? The limited security provided in SNMPv1/2 > necessitated having > >this functionality in the nmAccessTable. Given SNMPv3 security, it > >doesn't seem like this functionality is necessary anymore. > > I would agree that it is better security to authenticate a > keyed hash via > SNMPv3, than to rely on the incoming device interface for implied user > identification. > > However, one interesting and important case is a CM > diagnostic interface for > subscriber-side queries, after the CM registration process is > completed. It > seems quite useful to allow subscriber tools (with SNMPv3 > securityLevel of > noAuthNoPriv) to query cable modems over the CMCI (CPE > interface) but not > over the RFI (RF interface). > > -- Rich > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 13:12:46 2003 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 NAA02650 for ; Tue, 28 Jan 2003 13:12:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SIXns08059 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 13:33:49 -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 h0SIXJJ08018; Tue, 28 Jan 2003 13:33:20 -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 h0SIWHJ07990 for ; Tue, 28 Jan 2003 13:32:17 -0500 Received: from mms2.broadcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02626 for ; Tue, 28 Jan 2003 13:10:42 -0500 (EST) Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom MMS1 SMTP Relay (MMS v5.5.0)); Tue, 28 Jan 2003 10:11:17 -0700 Received: from ltatlamdolas (dhcp-10-24-65-44.atlanta.broadcom.com [10.24.65.44]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with SMTP id KAA09099; Tue, 28 Jan 2003 10:13:58 -0800 (PST) From: "Margo Dolas" To: "Lejeune, Andre" , "Murwin William-LWM008" , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Tue, 28 Jan 2003 13:13:56 -0500 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-MIME-Autoconverted: from 8bit to quoted-printable by mon-irva-11.broadcom.com id KAA09099 X-WSS-ID: 1228184F134939-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SIWHJ07991 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Andre, Maximum Sustained Rate is not applicable for UGS flows (per section 8.2.7 and table 8-4 of the RFI I09 spec), so packets cannot violate the Maximum Sustained Rate for an UGS flow. In an UGS flow, you only evaluate the packet size versus the UGS grant size, and then queue the packet until you receive a grant for the flow's SID. If the queue is full (because packets are arriving faster than the grant rate), then the packet is dropped and ifOutDiscards is incremented. Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 11:17 AM To: Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I have a problem with the proposed text because I don't understand how to distinguish packets that are in violation of the Maximum Sustained rate from packets with arrival rate faster than the grant rate. What is the difference? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 4:43 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 13:50:30 2003 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 NAA03530 for ; Tue, 28 Jan 2003 13:50:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SJBYD10816 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 14:11:34 -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 h0SJB6J10771; Tue, 28 Jan 2003 14:11:06 -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 h0SJ9MJ10683 for ; Tue, 28 Jan 2003 14:09:22 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03465 for ; Tue, 28 Jan 2003 13:47:45 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id h0SIpDwH004547; Tue, 28 Jan 2003 11:51:14 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 28 Jan 2003 11:51:13 -0700 Message-ID: Thread-Topic: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Thread-Index: AcLG9Npz4v4pAFNwTyeW6tGFuGjAWQACPO5w From: "Eduardo Cardona" To: "Nakanishi Greg-MGI8179" , "IPCDN WG (E-mail)" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SJ9MJ10684 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Kevin, Greg, Following your thoughts. I think I got more findings that need to be addressed in any case. The vacmAccess Interface requirements is being as a proposal since the early versions of this draft. We know your concerns and they are also related to different discussion in the reflector (i.e. controlling the number of traps/notification by touching the Notification Originator subsystem in the SNMP entity ) In this case the difficulty is to modify the Access Control Subsystem in the SNMP entity, to being able to add the interface scheme, which is perfectly valid under RFC2571/3411 architecture and AUGMENT clause in RFC2578 We need more thoughs in the SNMP constrains we are trying to achieve with the full coverage of MSO needs. The need is there: what the SNMP stack providers may solve? (Greg concerns of available tools/design framework) Will be Feasible or agree in certain MSO/management constrains? ( few options below) Is the SNMPv3 group addressing this case or had ever think about this as a standard mechanism? Will that be clearly extended for embedded cases with logical interfaces instead of physical ones ( to avoid security holes ? Typical case: "Many" (how many is many?) CMs used to bridge the traffic (SNMP) directed to the CM DHCP IP from the CPE through the RF interface Upstream. For blocking traffic: These is trivial since MSO is able to place SNMP filters in the CMTS/backbone For getting CPE traffic: Could be cumbersome in the presence of SNMP filters in the gateway or a CM unable to register. In the other hand the MSO/technician/User, must know the CM IP that could be a problem or not desired always. That one was partially solved with the well known IP 192.168.100.1 What is still a MSO constrain: CMs able to talk to the SNMP stack from any CPE subnet ( spoof NMS IP ) ( 1 hop) and use the v1, v2c vacmAccess constrains for full access. Also v3 noAuthNoPriv does not support the subletting as RFC 2576 defined for coexistence v1 v2c and there is where Rich's case applied for granting or blocking access. If we agree the well know IP is the "only" way to talk to the CM for a CPE with one hop ( CPE to CM DHCP IP queries forwarded through RF ) we are OK and the vacm requirement may not needed, but some clarifications are needed in the spec. It creates the need to reconfigure the user CPE any time that a user may need to talk to the CM. With current requirements in either case: In the SNMP framework snmpv3 noAuthNoPRiv the access will be the same for MSO and user Access. With the Interface scheme an MSO will be able to set two different v3 users noAuthNoPriv with different access. If not the case we still have the issue of blocking NMS spoofed Ips) and the vacmAccessInterface is a way to block that. Or define the ip forward mechanism better. Eduardo -----Original Message----- From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] Sent: Tuesday, January 28, 2003 10:43 AM To: 'IPCDN WG (E-mail)' Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Kevin, I think your point is accurate. Just to expand upon it some... Typically a CM will get a private IP address via DHCP. This results in access to the CM through the HFC interface being limited to within the MSO's private IP network. "Outsiders" (e.g. user's on the CMCI-side or on the Internet) will not be able to access a CM through the HFC interface. Access to the CM from the CMCI interface is still allowed if the proper SNMP access controls are setup. I want to make sure that this proposed extension to the VACM table provides a good benefit over what is acheivable today with the mechanisms we already have. greg > -----Original Message----- > From: Marez Kevin-MGI1375 > Sent: Tuesday, January 28, 2003 9:10 AM > To: 'Woundy, Richard'; Nakanishi Greg-MGI8179 > Cc: IPCDN WG (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Rich, > > I understand the scenario you have presented, however, I > think MSOs would typically use a private networking space for > the RF-side and explicitly prevent access from outside that space. > > Our concern here is that we are adding an additional level of > complexity to the vacmAccess table that doesn't provide a > great deal of benefit. > > Greg, please respond I have misstated anything or if you have > anything you'd like to add. Thanks very much, > > Kevin > > > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Wednesday, January 22, 2003 3:59 PM > To: 'Marez Kevin-MGI1375' > Cc: IPCDN WG (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Kevin, > > Here is my comment on the VACM issue: > > >10) docsDevVacmAccessExtTable - Is this table really needed > when using > >SNMPv3? The limited security provided in SNMPv1/2 > necessitated having > >this functionality in the nmAccessTable. Given SNMPv3 security, it > >doesn't seem like this functionality is necessary anymore. > > I would agree that it is better security to authenticate a > keyed hash via > SNMPv3, than to rely on the incoming device interface for implied user > identification. > > However, one interesting and important case is a CM > diagnostic interface for > subscriber-side queries, after the CM registration process is > completed. It > seems quite useful to allow subscriber tools (with SNMPv3 > securityLevel of > noAuthNoPriv) to query cable modems over the CMCI (CPE > interface) but not > over the RFI (RF interface). > > -- Rich > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 14:56:09 2003 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 OAA05346 for ; Tue, 28 Jan 2003 14:56:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SKHFE15242 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 15:17:15 -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 h0SKHBJ15237; Tue, 28 Jan 2003 15:17:11 -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 h0SKGvJ15201 for ; Tue, 28 Jan 2003 15:16:57 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05302 for ; Tue, 28 Jan 2003 14:55:19 -0500 (EST) Received: from mms02-RelayB.tci.com (mms02-relayb.broadband.att.com [147.191.89.213]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h0SJwlst000553; Tue, 28 Jan 2003 12:58:47 -0700 (MST) Received: from 147.191.89.203 by mms02-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Tue, 28 Jan 2003 12:58:35 -0600 Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 28 Jan 2003 12:58:41 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056635BF@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "Nakanishi Greg-MGI8179" , "'Eduardo Cardona'" cc: "IPCDN WG (E-mail)" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Date: Tue, 28 Jan 2003 12:58:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12283F61929194-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Eduardo, I am sympathetic to Greg and Kevin's argument that perhaps the docsDevVacmAccessExtTable extension to VACM should be deleted from the Cable Device MIB, for three reasons: 1. Greg seems to have proposed a workaround for the use case I proposed. Restating, the DOCSIS configuration file could set up the docsDevFilterIpTable to reject UDP/SNMP traffic arriving on the RF/HFC interface from any IP subnets other than the MSOs management station subnets. This sounds like reasonable security practice in any case, i.e. don't just rely on SNMPv3 authentication. It enables subscriber CM management from the CMCI side, but not subscriber/random user access from the RF/HFC side, per my use case. 2. I agree it would be much easier for vendors if they could leverage standard SNMP agent stack implementations as much as possible. The extension for DOCSIS-only devices makes this objective more difficult. 3. There is also a possibility that the IETF MIB doctor might frown on a DOCSIS-specific extension to the VACM MIB. Does anyone disagree? Shall I make this deletion? Are there any other comments on the current Cable Device MIB -- which is now posted on the IETF reflector, ? -- Rich -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@cablelabs.com] Sent: Tuesday, January 28, 2003 1:51 PM To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail) Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Kevin, Greg, Following your thoughts. I think I got more findings that need to be addressed in any case. The vacmAccess Interface requirements is being as a proposal since the early versions of this draft. We know your concerns and they are also related to different discussion in the reflector (i.e. controlling the number of traps/notification by touching the Notification Originator subsystem in the SNMP entity ) In this case the difficulty is to modify the Access Control Subsystem in the SNMP entity, to being able to add the interface scheme, which is perfectly valid under RFC2571/3411 architecture and AUGMENT clause in RFC2578 We need more thoughs in the SNMP constrains we are trying to achieve with the full coverage of MSO needs. The need is there: what the SNMP stack providers may solve? (Greg concerns of available tools/design framework) Will be Feasible or agree in certain MSO/management constrains? ( few options below) Is the SNMPv3 group addressing this case or had ever think about this as a standard mechanism? Will that be clearly extended for embedded cases with logical interfaces instead of physical ones ( to avoid security holes ? Typical case: "Many" (how many is many?) CMs used to bridge the traffic (SNMP) directed to the CM DHCP IP from the CPE through the RF interface Upstream. For blocking traffic: These is trivial since MSO is able to place SNMP filters in the CMTS/backbone For getting CPE traffic: Could be cumbersome in the presence of SNMP filters in the gateway or a CM unable to register. In the other hand the MSO/technician/User, must know the CM IP that could be a problem or not desired always. That one was partially solved with the well known IP 192.168.100.1 What is still a MSO constrain: CMs able to talk to the SNMP stack from any CPE subnet ( spoof NMS IP ) ( 1 hop) and use the v1, v2c vacmAccess constrains for full access. Also v3 noAuthNoPriv does not support the subletting as RFC 2576 defined for coexistence v1 v2c and there is where Rich's case applied for granting or blocking access. If we agree the well know IP is the "only" way to talk to the CM for a CPE with one hop ( CPE to CM DHCP IP queries forwarded through RF ) we are OK and the vacm requirement may not needed, but some clarifications are needed in the spec. It creates the need to reconfigure the user CPE any time that a user may need to talk to the CM. With current requirements in either case: In the SNMP framework snmpv3 noAuthNoPRiv the access will be the same for MSO and user Access. With the Interface scheme an MSO will be able to set two different v3 users noAuthNoPriv with different access. If not the case we still have the issue of blocking NMS spoofed Ips) and the vacmAccessInterface is a way to block that. Or define the ip forward mechanism better. Eduardo -----Original Message----- From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] Sent: Tuesday, January 28, 2003 10:43 AM To: 'IPCDN WG (E-mail)' Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Kevin, I think your point is accurate. Just to expand upon it some... Typically a CM will get a private IP address via DHCP. This results in access to the CM through the HFC interface being limited to within the MSO's private IP network. "Outsiders" (e.g. user's on the CMCI-side or on the Internet) will not be able to access a CM through the HFC interface. Access to the CM from the CMCI interface is still allowed if the proper SNMP access controls are setup. I want to make sure that this proposed extension to the VACM table provides a good benefit over what is acheivable today with the mechanisms we already have. greg > -----Original Message----- > From: Marez Kevin-MGI1375 > Sent: Tuesday, January 28, 2003 9:10 AM > To: 'Woundy, Richard'; Nakanishi Greg-MGI8179 > Cc: IPCDN WG (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Rich, > > I understand the scenario you have presented, however, I > think MSOs would typically use a private networking space for > the RF-side and explicitly prevent access from outside that space. > > Our concern here is that we are adding an additional level of > complexity to the vacmAccess table that doesn't provide a > great deal of benefit. > > Greg, please respond I have misstated anything or if you have > anything you'd like to add. Thanks very much, > > Kevin > > > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Wednesday, January 22, 2003 3:59 PM > To: 'Marez Kevin-MGI1375' > Cc: IPCDN WG (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Kevin, > > Here is my comment on the VACM issue: > > >10) docsDevVacmAccessExtTable - Is this table really needed > when using > >SNMPv3? The limited security provided in SNMPv1/2 > necessitated having > >this functionality in the nmAccessTable. Given SNMPv3 security, it > >doesn't seem like this functionality is necessary anymore. > > I would agree that it is better security to authenticate a > keyed hash via > SNMPv3, than to rely on the incoming device interface for implied user > identification. > > However, one interesting and important case is a CM > diagnostic interface for > subscriber-side queries, after the CM registration process is > completed. It > seems quite useful to allow subscriber tools (with SNMPv3 > securityLevel of > noAuthNoPriv) to query cable modems over the CMCI (CPE > interface) but not > over the RFI (RF interface). > > -- Rich > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 16:17:09 2003 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 QAA07935 for ; Tue, 28 Jan 2003 16:17:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SLcFm21367 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 16:38:15 -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 h0SLc6J21352; Tue, 28 Jan 2003 16:38:06 -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 h0SLaeJ20618 for ; Tue, 28 Jan 2003 16:36:40 -0500 Received: from mms2.broadcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07805 for ; Tue, 28 Jan 2003 16:15:01 -0500 (EST) Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom MMS1 SMTP Relay (MMS v5.5.0)); Tue, 28 Jan 2003 13:15:36 -0700 Received: from ltatlamdolas (dhcp-10-24-65-44.atlanta.broadcom.com [10.24.65.44]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with SMTP id NAA14782; Tue, 28 Jan 2003 13:18:17 -0800 (PST) From: "Margo Dolas" To: "Lejeune, Andre" , "Murwin William-LWM008" , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Tue, 28 Jan 2003 16:18:15 -0500 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-MIME-Autoconverted: from 8bit to quoted-printable by mon-irva-11.broadcom.com id NAA14782 X-WSS-ID: 12282D72152316-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SLafJ20619 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Andre, I agree with your simplification. The new text for the docsQosServiceFlowPolicedDropPkts description would then be - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." A similar simplification could be made to the description of docsQosServiceFlowPolicedDelayPkts. The new text would be - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 2:08 PM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I understand why I did not read this text properly then. I took the last sentence out of context. I don't think I had to stretch my imagination that much to take it out of context, it does not make any mention of UGS, and when the Maximum Sustained Traffic Rate is exceeded, the packet arrival rate does exceed the packet transmission rate. Instead of providing a series of examples for UGS flows, would it not be simpler to replace it with a statement that the parameter does not apply to UGS flows, since Max Sustained Rate is not applicable? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 1:14 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, Maximum Sustained Rate is not applicable for UGS flows (per section 8.2.7 and table 8-4 of the RFI I09 spec), so packets cannot violate the Maximum Sustained Rate for an UGS flow. In an UGS flow, you only evaluate the packet size versus the UGS grant size, and then queue the packet until you receive a grant for the flow's SID. If the queue is full (because packets are arriving faster than the grant rate), then the packet is dropped and ifOutDiscards is incremented. Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 11:17 AM To: Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I have a problem with the proposed text because I don't understand how to distinguish packets that are in violation of the Maximum Sustained rate from packets with arrival rate faster than the grant rate. What is the difference? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 4:43 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 16:25:59 2003 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 QAA08341 for ; Tue, 28 Jan 2003 16:25:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SLl5A21967 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 16:47:05 -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 h0SLl2J21952; Tue, 28 Jan 2003 16:47:02 -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 h0SLkwJ21931 for ; Tue, 28 Jan 2003 16:46:58 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08324 for ; Tue, 28 Jan 2003 16:25:18 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id h0SLShwH010046; Tue, 28 Jan 2003 14:28:44 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 28 Jan 2003 14:28:43 -0700 Message-ID: Thread-Topic: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Thread-Index: AcLHB61tE25IWwNXSZepmIdvYjB2IwAC79Aw From: "Eduardo Cardona" To: "Woundy, Richard" , "Nakanishi Greg-MGI8179" Cc: "IPCDN WG (E-mail)" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SLkwJ21932 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I agree, The vacm extension should be removed, The IpFilter mechanism is a good practice and close all doors. Eduardo -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Tuesday, January 28, 2003 12:58 PM To: Nakanishi Greg-MGI8179; Eduardo Cardona Cc: IPCDN WG (E-mail) Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Eduardo, I am sympathetic to Greg and Kevin's argument that perhaps the docsDevVacmAccessExtTable extension to VACM should be deleted from the Cable Device MIB, for three reasons: 1. Greg seems to have proposed a workaround for the use case I proposed. Restating, the DOCSIS configuration file could set up the docsDevFilterIpTable to reject UDP/SNMP traffic arriving on the RF/HFC interface from any IP subnets other than the MSOs management station subnets. This sounds like reasonable security practice in any case, i.e. don't just rely on SNMPv3 authentication. It enables subscriber CM management from the CMCI side, but not subscriber/random user access from the RF/HFC side, per my use case. 2. I agree it would be much easier for vendors if they could leverage standard SNMP agent stack implementations as much as possible. The extension for DOCSIS-only devices makes this objective more difficult. 3. There is also a possibility that the IETF MIB doctor might frown on a DOCSIS-specific extension to the VACM MIB. Does anyone disagree? Shall I make this deletion? Are there any other comments on the current Cable Device MIB -- which is now posted on the IETF reflector, ? -- Rich -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@cablelabs.com] Sent: Tuesday, January 28, 2003 1:51 PM To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail) Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Kevin, Greg, Following your thoughts. I think I got more findings that need to be addressed in any case. The vacmAccess Interface requirements is being as a proposal since the early versions of this draft. We know your concerns and they are also related to different discussion in the reflector (i.e. controlling the number of traps/notification by touching the Notification Originator subsystem in the SNMP entity ) In this case the difficulty is to modify the Access Control Subsystem in the SNMP entity, to being able to add the interface scheme, which is perfectly valid under RFC2571/3411 architecture and AUGMENT clause in RFC2578 We need more thoughs in the SNMP constrains we are trying to achieve with the full coverage of MSO needs. The need is there: what the SNMP stack providers may solve? (Greg concerns of available tools/design framework) Will be Feasible or agree in certain MSO/management constrains? ( few options below) Is the SNMPv3 group addressing this case or had ever think about this as a standard mechanism? Will that be clearly extended for embedded cases with logical interfaces instead of physical ones ( to avoid security holes ? Typical case: "Many" (how many is many?) CMs used to bridge the traffic (SNMP) directed to the CM DHCP IP from the CPE through the RF interface Upstream. For blocking traffic: These is trivial since MSO is able to place SNMP filters in the CMTS/backbone For getting CPE traffic: Could be cumbersome in the presence of SNMP filters in the gateway or a CM unable to register. In the other hand the MSO/technician/User, must know the CM IP that could be a problem or not desired always. That one was partially solved with the well known IP 192.168.100.1 What is still a MSO constrain: CMs able to talk to the SNMP stack from any CPE subnet ( spoof NMS IP ) ( 1 hop) and use the v1, v2c vacmAccess constrains for full access. Also v3 noAuthNoPriv does not support the subletting as RFC 2576 defined for coexistence v1 v2c and there is where Rich's case applied for granting or blocking access. If we agree the well know IP is the "only" way to talk to the CM for a CPE with one hop ( CPE to CM DHCP IP queries forwarded through RF ) we are OK and the vacm requirement may not needed, but some clarifications are needed in the spec. It creates the need to reconfigure the user CPE any time that a user may need to talk to the CM. With current requirements in either case: In the SNMP framework snmpv3 noAuthNoPRiv the access will be the same for MSO and user Access. With the Interface scheme an MSO will be able to set two different v3 users noAuthNoPriv with different access. If not the case we still have the issue of blocking NMS spoofed Ips) and the vacmAccessInterface is a way to block that. Or define the ip forward mechanism better. Eduardo -----Original Message----- From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] Sent: Tuesday, January 28, 2003 10:43 AM To: 'IPCDN WG (E-mail)' Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Kevin, I think your point is accurate. Just to expand upon it some... Typically a CM will get a private IP address via DHCP. This results in access to the CM through the HFC interface being limited to within the MSO's private IP network. "Outsiders" (e.g. user's on the CMCI-side or on the Internet) will not be able to access a CM through the HFC interface. Access to the CM from the CMCI interface is still allowed if the proper SNMP access controls are setup. I want to make sure that this proposed extension to the VACM table provides a good benefit over what is acheivable today with the mechanisms we already have. greg > -----Original Message----- > From: Marez Kevin-MGI1375 > Sent: Tuesday, January 28, 2003 9:10 AM > To: 'Woundy, Richard'; Nakanishi Greg-MGI8179 > Cc: IPCDN WG (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Rich, > > I understand the scenario you have presented, however, I think MSOs > would typically use a private networking space for the RF-side and > explicitly prevent access from outside that space. > > Our concern here is that we are adding an additional level of > complexity to the vacmAccess table that doesn't provide a great deal > of benefit. > > Greg, please respond I have misstated anything or if you have anything > you'd like to add. Thanks very much, > > Kevin > > > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Wednesday, January 22, 2003 3:59 PM > To: 'Marez Kevin-MGI1375' > Cc: IPCDN WG (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Kevin, > > Here is my comment on the VACM issue: > > >10) docsDevVacmAccessExtTable - Is this table really needed > when using > >SNMPv3? The limited security provided in SNMPv1/2 > necessitated having > >this functionality in the nmAccessTable. Given SNMPv3 security, it > >doesn't seem like this functionality is necessary anymore. > > I would agree that it is better security to authenticate a keyed hash > via SNMPv3, than to rely on the incoming device interface for implied > user identification. > > However, one interesting and important case is a CM diagnostic > interface for subscriber-side queries, after the CM registration > process is completed. It > seems quite useful to allow subscriber tools (with SNMPv3 > securityLevel of > noAuthNoPriv) to query cable modems over the CMCI (CPE > interface) but not > over the RFI (RF interface). > > -- Rich > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 16:51:03 2003 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 QAA09078 for ; Tue, 28 Jan 2003 16:51:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SMCAf24082 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 17:12:10 -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 h0SMC6J24071; Tue, 28 Jan 2003 17:12:06 -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 h0SMBKJ24022 for ; Tue, 28 Jan 2003 17:11:20 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09013 for ; Tue, 28 Jan 2003 16:49:40 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id h0SLr5wH010873; Tue, 28 Jan 2003 14:53:05 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 28 Jan 2003 14:53:04 -0700 Message-ID: Thread-Topic: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Thread-Index: AcLHB61tE25IWwNXSZepmIdvYjB2IwADRRMQ From: "Eduardo Cardona" To: "Woundy, Richard" , "Nakanishi Greg-MGI8179" Cc: "IPCDN WG (E-mail)" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SMBLJ24023 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I forgot to mention something, 3.3.2.2. SNMPv3 Interface via vacm extension to be removed Going back to Greg's comments? Is the filtering flow in 3.3 accurated enough to solve that in terms of this filter schems? Seems that SNMP traffic (Section 3.3) is not intuitively "forced" to go to the ip filters (which after removing vacmExt will be mere NmAccess Mode) before hitting the agent. ( I mean the NmAccess text from rfc2669 is distracting ?) I've seen people with different interpretations of how to "implement" the filters based on directed to CM traffic or CM forwarded traffic It may create confusion that as the diagram is following the Stack for the RF-CPE or CPE-RF traffic the RF-CM CPE-CM trattic is not properly represented : I add a little box of possible interpretation that should be clarified. ***************** * LLC Filter In * ***************** | v ******************* * Special Filters * * | * * V * * ************ * * * IP Spoof * * * ************ * * | * * v * * *************** * * * SNMP Access * * * *************** * * | * ******************* | ------> Wrong : SNMP to CM traffic processing v **************** * IP Filter In * **************** | -------> Rigth: SNMP to CM traffic processing v ***************** * IP Filter Out * ***************** | v ****************** * LLC Filter Out * ****************** -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Tuesday, January 28, 2003 12:58 PM To: Nakanishi Greg-MGI8179; Eduardo Cardona Cc: IPCDN WG (E-mail) Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Eduardo, I am sympathetic to Greg and Kevin's argument that perhaps the docsDevVacmAccessExtTable extension to VACM should be deleted from the Cable Device MIB, for three reasons: 1. Greg seems to have proposed a workaround for the use case I proposed. Restating, the DOCSIS configuration file could set up the docsDevFilterIpTable to reject UDP/SNMP traffic arriving on the RF/HFC interface from any IP subnets other than the MSOs management station subnets. This sounds like reasonable security practice in any case, i.e. don't just rely on SNMPv3 authentication. It enables subscriber CM management from the CMCI side, but not subscriber/random user access from the RF/HFC side, per my use case. 2. I agree it would be much easier for vendors if they could leverage standard SNMP agent stack implementations as much as possible. The extension for DOCSIS-only devices makes this objective more difficult. 3. There is also a possibility that the IETF MIB doctor might frown on a DOCSIS-specific extension to the VACM MIB. Does anyone disagree? Shall I make this deletion? Are there any other comments on the current Cable Device MIB -- which is now posted on the IETF reflector, ? -- Rich -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@cablelabs.com] Sent: Tuesday, January 28, 2003 1:51 PM To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail) Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Kevin, Greg, Following your thoughts. I think I got more findings that need to be addressed in any case. The vacmAccess Interface requirements is being as a proposal since the early versions of this draft. We know your concerns and they are also related to different discussion in the reflector (i.e. controlling the number of traps/notification by touching the Notification Originator subsystem in the SNMP entity ) In this case the difficulty is to modify the Access Control Subsystem in the SNMP entity, to being able to add the interface scheme, which is perfectly valid under RFC2571/3411 architecture and AUGMENT clause in RFC2578 We need more thoughs in the SNMP constrains we are trying to achieve with the full coverage of MSO needs. The need is there: what the SNMP stack providers may solve? (Greg concerns of available tools/design framework) Will be Feasible or agree in certain MSO/management constrains? ( few options below) Is the SNMPv3 group addressing this case or had ever think about this as a standard mechanism? Will that be clearly extended for embedded cases with logical interfaces instead of physical ones ( to avoid security holes ? Typical case: "Many" (how many is many?) CMs used to bridge the traffic (SNMP) directed to the CM DHCP IP from the CPE through the RF interface Upstream. For blocking traffic: These is trivial since MSO is able to place SNMP filters in the CMTS/backbone For getting CPE traffic: Could be cumbersome in the presence of SNMP filters in the gateway or a CM unable to register. In the other hand the MSO/technician/User, must know the CM IP that could be a problem or not desired always. That one was partially solved with the well known IP 192.168.100.1 What is still a MSO constrain: CMs able to talk to the SNMP stack from any CPE subnet ( spoof NMS IP ) ( 1 hop) and use the v1, v2c vacmAccess constrains for full access. Also v3 noAuthNoPriv does not support the subletting as RFC 2576 defined for coexistence v1 v2c and there is where Rich's case applied for granting or blocking access. If we agree the well know IP is the "only" way to talk to the CM for a CPE with one hop ( CPE to CM DHCP IP queries forwarded through RF ) we are OK and the vacm requirement may not needed, but some clarifications are needed in the spec. It creates the need to reconfigure the user CPE any time that a user may need to talk to the CM. With current requirements in either case: In the SNMP framework snmpv3 noAuthNoPRiv the access will be the same for MSO and user Access. With the Interface scheme an MSO will be able to set two different v3 users noAuthNoPriv with different access. If not the case we still have the issue of blocking NMS spoofed Ips) and the vacmAccessInterface is a way to block that. Or define the ip forward mechanism better. Eduardo -----Original Message----- From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] Sent: Tuesday, January 28, 2003 10:43 AM To: 'IPCDN WG (E-mail)' Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Kevin, I think your point is accurate. Just to expand upon it some... Typically a CM will get a private IP address via DHCP. This results in access to the CM through the HFC interface being limited to within the MSO's private IP network. "Outsiders" (e.g. user's on the CMCI-side or on the Internet) will not be able to access a CM through the HFC interface. Access to the CM from the CMCI interface is still allowed if the proper SNMP access controls are setup. I want to make sure that this proposed extension to the VACM table provides a good benefit over what is acheivable today with the mechanisms we already have. greg > -----Original Message----- > From: Marez Kevin-MGI1375 > Sent: Tuesday, January 28, 2003 9:10 AM > To: 'Woundy, Richard'; Nakanishi Greg-MGI8179 > Cc: IPCDN WG (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Rich, > > I understand the scenario you have presented, however, I think MSOs > would typically use a private networking space for the RF-side and > explicitly prevent access from outside that space. > > Our concern here is that we are adding an additional level of > complexity to the vacmAccess table that doesn't provide a great deal > of benefit. > > Greg, please respond I have misstated anything or if you have anything > you'd like to add. Thanks very much, > > Kevin > > > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Wednesday, January 22, 2003 3:59 PM > To: 'Marez Kevin-MGI1375' > Cc: IPCDN WG (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Kevin, > > Here is my comment on the VACM issue: > > >10) docsDevVacmAccessExtTable - Is this table really needed > when using > >SNMPv3? The limited security provided in SNMPv1/2 > necessitated having > >this functionality in the nmAccessTable. Given SNMPv3 security, it > >doesn't seem like this functionality is necessary anymore. > > I would agree that it is better security to authenticate a keyed hash > via SNMPv3, than to rely on the incoming device interface for implied > user identification. > > However, one interesting and important case is a CM diagnostic > interface for subscriber-side queries, after the CM registration > process is completed. It > seems quite useful to allow subscriber tools (with SNMPv3 > securityLevel of > noAuthNoPriv) to query cable modems over the CMCI (CPE > interface) but not > over the RFI (RF interface). > > -- Rich > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 16:57:58 2003 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 QAA09343 for ; Tue, 28 Jan 2003 16:57:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SMJ5u24487 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 17:19:05 -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 h0SMJ2J24425; Tue, 28 Jan 2003 17:19:02 -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 h0SGllJ00696 for ; Tue, 28 Jan 2003 11:47:47 -0500 Received: from scbh01.terayon.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29847 for ; Tue, 28 Jan 2003 11:26:14 -0500 (EST) Received: by SCBH01 with Internet Mail Service (5.5.2655.55) id ; Tue, 28 Jan 2003 08:19:39 -0800 Message-ID: From: "Lejeune, Andre" To: Margo Dolas , Murwin William-LWM008 , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Tue, 28 Jan 2003 08:17:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SGllJ00697 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I have a problem with the proposed text because I don't understand how to distinguish packets that are in violation of the Maximum Sustained rate from packets with arrival rate faster than the grant rate. What is the difference? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 4:43 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 16:57:58 2003 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 QAA09345 for ; Tue, 28 Jan 2003 16:57:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SMJ5I24500 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 17:19:05 -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 h0SMJ3J24440; Tue, 28 Jan 2003 17:19:03 -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 h0SJTWJ11653 for ; Tue, 28 Jan 2003 14:29:32 -0500 Received: from scbh01.terayon.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03960 for ; Tue, 28 Jan 2003 14:07:55 -0500 (EST) Received: by SCBH01 with Internet Mail Service (5.5.2655.55) id ; Tue, 28 Jan 2003 11:10:02 -0800 Message-ID: From: "Lejeune, Andre" To: Margo Dolas , "Lejeune, Andre" , Murwin William-LWM008 , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Tue, 28 Jan 2003 11:07:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SJTXJ11654 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I understand why I did not read this text properly then. I took the last sentence out of context. I don't think I had to stretch my imagination that much to take it out of context, it does not make any mention of UGS, and when the Maximum Sustained Traffic Rate is exceeded, the packet arrival rate does exceed the packet transmission rate. Instead of providing a series of examples for UGS flows, would it not be simpler to replace it with a statement that the parameter does not apply to UGS flows, since Max Sustained Rate is not applicable? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 1:14 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, Maximum Sustained Rate is not applicable for UGS flows (per section 8.2.7 and table 8-4 of the RFI I09 spec), so packets cannot violate the Maximum Sustained Rate for an UGS flow. In an UGS flow, you only evaluate the packet size versus the UGS grant size, and then queue the packet until you receive a grant for the flow's SID. If the queue is full (because packets are arriving faster than the grant rate), then the packet is dropped and ifOutDiscards is incremented. Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 11:17 AM To: Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I have a problem with the proposed text because I don't understand how to distinguish packets that are in violation of the Maximum Sustained rate from packets with arrival rate faster than the grant rate. What is the difference? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 4:43 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 17:17:04 2003 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 RAA09855 for ; Tue, 28 Jan 2003 17:17:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SMcBv26014 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 17:38:11 -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 h0SMc9J26006; Tue, 28 Jan 2003 17:38:09 -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 h0SMbZJ25983 for ; Tue, 28 Jan 2003 17:37:35 -0500 Received: from mms3.broadcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09841 for ; Tue, 28 Jan 2003 17:15:55 -0500 (EST) Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom MMS1 SMTP Relay (MMS v5.5.0)); Tue, 28 Jan 2003 14:19:21 -0700 Received: from ltatlamdolas (dhcp-10-24-65-44.atlanta.broadcom.com [10.24.65.44]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with SMTP id OAA26032; Tue, 28 Jan 2003 14:19:11 -0800 (PST) From: "Margo Dolas" To: "Lejeune, Andre" , "Murwin William-LWM008" , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Tue, 28 Jan 2003 17:19:09 -0500 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-MIME-Autoconverted: from 8bit to quoted-printable by mon-irva-11.broadcom.com id OAA26032 X-WSS-ID: 1229DE63151154-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SMbZJ25984 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Andre, In thinking about it a bit more, I'd prefer to see more explicit text for the policed packets. What do you think of the following text? For the docsQosServiceFlowPolicedDropPkts description - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: owner-docsis-oss@cablelabs.com [mailto:owner-docsis-oss@cablelabs.com]On Behalf Of Margo Dolas Sent: Tuesday, 28 January, 2003 4:18 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, I agree with your simplification. The new text for the docsQosServiceFlowPolicedDropPkts description would then be - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." A similar simplification could be made to the description of docsQosServiceFlowPolicedDelayPkts. The new text would be - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 2:08 PM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I understand why I did not read this text properly then. I took the last sentence out of context. I don't think I had to stretch my imagination that much to take it out of context, it does not make any mention of UGS, and when the Maximum Sustained Traffic Rate is exceeded, the packet arrival rate does exceed the packet transmission rate. Instead of providing a series of examples for UGS flows, would it not be simpler to replace it with a statement that the parameter does not apply to UGS flows, since Max Sustained Rate is not applicable? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 1:14 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, Maximum Sustained Rate is not applicable for UGS flows (per section 8.2.7 and table 8-4 of the RFI I09 spec), so packets cannot violate the Maximum Sustained Rate for an UGS flow. In an UGS flow, you only evaluate the packet size versus the UGS grant size, and then queue the packet until you receive a grant for the flow's SID. If the queue is full (because packets are arriving faster than the grant rate), then the packet is dropped and ifOutDiscards is incremented. Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 11:17 AM To: Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I have a problem with the proposed text because I don't understand how to distinguish packets that are in violation of the Maximum Sustained rate from packets with arrival rate faster than the grant rate. What is the difference? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 4:43 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 18:25:14 2003 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 SAA11406 for ; Tue, 28 Jan 2003 18:25:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SNkNl30043 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 18:46:23 -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 h0SNkKJ30035; Tue, 28 Jan 2003 18:46:20 -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 h0SNjFJ29998 for ; Tue, 28 Jan 2003 18:45:15 -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 SAA11359 for ; Tue, 28 Jan 2003 18:23:32 -0500 (EST) Received: from mms02-RelayB.tci.com (mms02-relayb.broadband.att.com [147.191.89.213]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id h0SNQwJD023053; Tue, 28 Jan 2003 16:26:58 -0700 (MST) Received: from 147.191.89.201 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Tue, 28 Jan 2003 16:26:48 -0600 Received: by entexchimc02.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 28 Jan 2003 16:26:33 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056635C6@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Eduardo Cardona'" , "Nakanishi Greg-MGI8179" cc: "IPCDN WG (E-mail)" , "DOCSIS OSS (E-mail)" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Date: Tue, 28 Jan 2003 16:26:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1229CE32961938-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I wonder whether current CM vendors typically check the docsDevFilterIpTable before they process a locally-addressed SNMP PDU. Anyone know? -- Rich -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] Sent: Tuesday, January 28, 2003 4:53 PM To: Woundy, Richard; Nakanishi Greg-MGI8179 Cc: IPCDN WG (E-mail) Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... I forgot to mention something, 3.3.2.2. SNMPv3 Interface via vacm extension to be removed Going back to Greg's comments? Is the filtering flow in 3.3 accurated enough to solve that in terms of this filter schems? Seems that SNMP traffic (Section 3.3) is not intuitively "forced" to go to the ip filters (which after removing vacmExt will be mere NmAccess Mode) before hitting the agent. ( I mean the NmAccess text from rfc2669 is distracting ?) I've seen people with different interpretations of how to "implement" the filters based on directed to CM traffic or CM forwarded traffic It may create confusion that as the diagram is following the Stack for the RF-CPE or CPE-RF traffic the RF-CM CPE-CM trattic is not properly represented : I add a little box of possible interpretation that should be clarified. ***************** * LLC Filter In * ***************** | v ******************* * Special Filters * * | * * V * * ************ * * * IP Spoof * * * ************ * * | * * v * * *************** * * * SNMP Access * * * *************** * * | * ******************* | ------> Wrong : SNMP to CM traffic processing v **************** * IP Filter In * **************** | -------> Rigth: SNMP to CM traffic processing v ***************** * IP Filter Out * ***************** | v ****************** * LLC Filter Out * ****************** -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Tuesday, January 28, 2003 12:58 PM To: Nakanishi Greg-MGI8179; Eduardo Cardona Cc: IPCDN WG (E-mail) Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Eduardo, I am sympathetic to Greg and Kevin's argument that perhaps the docsDevVacmAccessExtTable extension to VACM should be deleted from the Cable Device MIB, for three reasons: 1. Greg seems to have proposed a workaround for the use case I proposed. Restating, the DOCSIS configuration file could set up the docsDevFilterIpTable to reject UDP/SNMP traffic arriving on the RF/HFC interface from any IP subnets other than the MSOs management station subnets. This sounds like reasonable security practice in any case, i.e. don't just rely on SNMPv3 authentication. It enables subscriber CM management from the CMCI side, but not subscriber/random user access from the RF/HFC side, per my use case. 2. I agree it would be much easier for vendors if they could leverage standard SNMP agent stack implementations as much as possible. The extension for DOCSIS-only devices makes this objective more difficult. 3. There is also a possibility that the IETF MIB doctor might frown on a DOCSIS-specific extension to the VACM MIB. Does anyone disagree? Shall I make this deletion? Are there any other comments on the current Cable Device MIB -- which is now posted on the IETF reflector, ? -- Rich -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@cablelabs.com] Sent: Tuesday, January 28, 2003 1:51 PM To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail) Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Kevin, Greg, Following your thoughts. I think I got more findings that need to be addressed in any case. The vacmAccess Interface requirements is being as a proposal since the early versions of this draft. We know your concerns and they are also related to different discussion in the reflector (i.e. controlling the number of traps/notification by touching the Notification Originator subsystem in the SNMP entity ) In this case the difficulty is to modify the Access Control Subsystem in the SNMP entity, to being able to add the interface scheme, which is perfectly valid under RFC2571/3411 architecture and AUGMENT clause in RFC2578 We need more thoughs in the SNMP constrains we are trying to achieve with the full coverage of MSO needs. The need is there: what the SNMP stack providers may solve? (Greg concerns of available tools/design framework) Will be Feasible or agree in certain MSO/management constrains? ( few options below) Is the SNMPv3 group addressing this case or had ever think about this as a standard mechanism? Will that be clearly extended for embedded cases with logical interfaces instead of physical ones ( to avoid security holes ? Typical case: "Many" (how many is many?) CMs used to bridge the traffic (SNMP) directed to the CM DHCP IP from the CPE through the RF interface Upstream. For blocking traffic: These is trivial since MSO is able to place SNMP filters in the CMTS/backbone For getting CPE traffic: Could be cumbersome in the presence of SNMP filters in the gateway or a CM unable to register. In the other hand the MSO/technician/User, must know the CM IP that could be a problem or not desired always. That one was partially solved with the well known IP 192.168.100.1 What is still a MSO constrain: CMs able to talk to the SNMP stack from any CPE subnet ( spoof NMS IP ) ( 1 hop) and use the v1, v2c vacmAccess constrains for full access. Also v3 noAuthNoPriv does not support the subletting as RFC 2576 defined for coexistence v1 v2c and there is where Rich's case applied for granting or blocking access. If we agree the well know IP is the "only" way to talk to the CM for a CPE with one hop ( CPE to CM DHCP IP queries forwarded through RF ) we are OK and the vacm requirement may not needed, but some clarifications are needed in the spec. It creates the need to reconfigure the user CPE any time that a user may need to talk to the CM. With current requirements in either case: In the SNMP framework snmpv3 noAuthNoPRiv the access will be the same for MSO and user Access. With the Interface scheme an MSO will be able to set two different v3 users noAuthNoPriv with different access. If not the case we still have the issue of blocking NMS spoofed Ips) and the vacmAccessInterface is a way to block that. Or define the ip forward mechanism better. Eduardo -----Original Message----- From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] Sent: Tuesday, January 28, 2003 10:43 AM To: 'IPCDN WG (E-mail)' Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Kevin, I think your point is accurate. Just to expand upon it some... Typically a CM will get a private IP address via DHCP. This results in access to the CM through the HFC interface being limited to within the MSO's private IP network. "Outsiders" (e.g. user's on the CMCI-side or on the Internet) will not be able to access a CM through the HFC interface. Access to the CM from the CMCI interface is still allowed if the proper SNMP access controls are setup. I want to make sure that this proposed extension to the VACM table provides a good benefit over what is acheivable today with the mechanisms we already have. greg > -----Original Message----- > From: Marez Kevin-MGI1375 > Sent: Tuesday, January 28, 2003 9:10 AM > To: 'Woundy, Richard'; Nakanishi Greg-MGI8179 > Cc: IPCDN WG (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Rich, > > I understand the scenario you have presented, however, I think MSOs > would typically use a private networking space for the RF-side and > explicitly prevent access from outside that space. > > Our concern here is that we are adding an additional level of > complexity to the vacmAccess table that doesn't provide a great deal > of benefit. > > Greg, please respond I have misstated anything or if you have anything > you'd like to add. Thanks very much, > > Kevin > > > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Wednesday, January 22, 2003 3:59 PM > To: 'Marez Kevin-MGI1375' > Cc: IPCDN WG (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Kevin, > > Here is my comment on the VACM issue: > > >10) docsDevVacmAccessExtTable - Is this table really needed > when using > >SNMPv3? The limited security provided in SNMPv1/2 > necessitated having > >this functionality in the nmAccessTable. Given SNMPv3 security, it > >doesn't seem like this functionality is necessary anymore. > > I would agree that it is better security to authenticate a keyed hash > via SNMPv3, than to rely on the incoming device interface for implied > user identification. > > However, one interesting and important case is a CM diagnostic > interface for subscriber-side queries, after the CM registration > process is completed. It > seems quite useful to allow subscriber tools (with SNMPv3 > securityLevel of > noAuthNoPriv) to query cable modems over the CMCI (CPE > interface) but not > over the RFI (RF interface). > > -- Rich > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 19:01:25 2003 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 TAA11918 for ; Tue, 28 Jan 2003 19:01:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0T0MaD31979 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 19:22:36 -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 h0T0M6J31952; Tue, 28 Jan 2003 19:22:06 -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 h0T0LRJ31922 for ; Tue, 28 Jan 2003 19:21:27 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11872 for ; Tue, 28 Jan 2003 18:59:44 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h0T03ExN006492 for ; Tue, 28 Jan 2003 17:03:14 -0700 (MST) Received: [from ca25exm01.GI.COM (ca25exm01.gi.com [168.84.84.121]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id RAA27092 for ; Tue, 28 Jan 2003 17:02:14 -0700 (MST)] Received: by ca25exm01 with Internet Mail Service (5.5.2656.59) id ; Tue, 28 Jan 2003 16:03:14 -0800 Message-ID: From: Nakanishi Greg-MGI8179 To: "'Woundy, Richard'" , "'Eduardo Cardona'" Cc: "IPCDN WG (E-mail)" , "DOCSIS OSS (E-mail)" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Date: Tue, 28 Jan 2003 16:03:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , I agree that the application of ipFilters to packets addressed to the CM is not very clear in the spec. This topic comes up every now and then on the reflector. I believe the generally accepted interpretation is that traffic addressed to the CM is NOT filtered. The workaround that I proposed does not rely on the use of IP filters. It just relies on the the partitioning of the private IP network that the CM is part of and the public IP network that the CPE is part of. Typically, the CMTS will not route between these networks. A user can access through SNMP his/her own CM through the diagnostic IP address; however, a user cannot access someone elses CM. The packets from the user's CPE on the public network will not be routed by the CMTS to the private network on which someone else's CM resides. greg > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Tuesday, January 28, 2003 3:27 PM > To: 'Eduardo Cardona'; Nakanishi Greg-MGI8179 > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > I wonder whether current CM vendors typically check the > docsDevFilterIpTable > before they process a locally-addressed SNMP PDU. > > Anyone know? > > -- Rich > > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: Tuesday, January 28, 2003 4:53 PM > To: Woundy, Richard; Nakanishi Greg-MGI8179 > Cc: IPCDN WG (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > I forgot to mention something, > > 3.3.2.2. SNMPv3 Interface via vacm extension to be removed > > Going back to Greg's comments? > > Is the filtering flow in 3.3 accurated enough to solve that > in terms of > this filter schems? > > Seems that SNMP traffic (Section 3.3) is not intuitively > "forced" to go > to the ip filters (which after removing vacmExt will be mere NmAccess > Mode) before hitting the agent. ( I mean the NmAccess text > from rfc2669 > is distracting ?) > > I've seen people with different interpretations of how to "implement" > the filters based on directed to CM traffic or CM forwarded traffic > It may create confusion that as the diagram is following the Stack for > the RF-CPE or CPE-RF traffic the RF-CM CPE-CM trattic is not properly > represented : I add a little box of possible interpretation > that should > be clarified. > > > > ***************** > * LLC Filter In * > ***************** > | > v > ******************* > * Special Filters * > * | * > * V * > * ************ * > * * IP Spoof * * > * ************ * > * | * > * v * > > * *************** * > * * SNMP Access * * > * *************** * > * | * > ******************* > | ------> Wrong : SNMP to > CM traffic > processing > v > **************** > * IP Filter In * > **************** > | -------> Rigth: SNMP to > CM traffic > processing > v > ***************** > * IP Filter Out * > ***************** > | > v > ****************** > * LLC Filter Out * > ****************** > > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Tuesday, January 28, 2003 12:58 PM > To: Nakanishi Greg-MGI8179; Eduardo Cardona > Cc: IPCDN WG (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Eduardo, > > I am sympathetic to Greg and Kevin's argument that perhaps the > docsDevVacmAccessExtTable extension to VACM should be deleted from the > Cable Device MIB, for three reasons: > > 1. Greg seems to have proposed a workaround for the use case > I proposed. > Restating, the DOCSIS configuration file could set up the > docsDevFilterIpTable to reject UDP/SNMP traffic arriving on the RF/HFC > interface from any IP subnets other than the MSOs management station > subnets. This sounds like reasonable security practice in any > case, i.e. > don't just rely on SNMPv3 authentication. It enables subscriber CM > management from the CMCI side, but not subscriber/random user access > from the RF/HFC side, per my use case. 2. I agree it would be much > easier for vendors if they could leverage standard SNMP agent stack > implementations as much as possible. The extension for DOCSIS-only > devices makes this objective more difficult. 3. There is also a > possibility that the IETF MIB doctor might frown on a DOCSIS-specific > extension to the VACM MIB. > > Does anyone disagree? Shall I make this deletion? > > Are there any other comments on the current Cable Device MIB > -- which is > now posted on the IETF reflector, > bv2-04.txt > >? > > -- Rich > > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@cablelabs.com] > Sent: Tuesday, January 28, 2003 1:51 PM > To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Kevin, Greg, > > Following your thoughts. I think I got more findings that need to be > addressed in any case. > The vacmAccess Interface requirements is being as a proposal since the > early versions of this draft. > > We know your concerns and they are also related to different > discussion > in the reflector (i.e. controlling the number of traps/notification by > touching the Notification Originator subsystem in the SNMP entity ) > > In this case the difficulty is to modify the Access Control > Subsystem in > the SNMP entity, to being able to add the interface scheme, which is > perfectly valid under RFC2571/3411 architecture and AUGMENT clause in > RFC2578 > > > We need more thoughs in the SNMP constrains we are trying to achieve > with the full coverage of MSO needs. > > The need is there: > > what the SNMP stack providers may solve? (Greg concerns of available > tools/design framework) Will be Feasible or agree in certain > MSO/management constrains? ( few options below) Is the SNMPv3 group > addressing this case or had ever think about this as a standard > mechanism? > Will that be clearly extended for embedded cases with logical > interfaces > instead of physical ones ( to avoid security holes ? > > > Typical case: > > "Many" (how many is many?) CMs used to bridge the traffic (SNMP) > directed to the CM DHCP IP from the CPE through the RF interface > Upstream. > > For blocking traffic: > These is trivial since MSO is able to place SNMP filters in the > CMTS/backbone For getting CPE traffic: > Could be cumbersome in the presence of SNMP filters in the > gateway or a > CM unable to register. In the other hand the > MSO/technician/User, must > know the CM IP that could be a problem or not desired always. > > That one was partially solved with the well known IP 192.168.100.1 > > What is still a MSO constrain: > CMs able to talk to the SNMP stack from any CPE subnet ( > spoof NMS IP ) > ( 1 hop) and use the v1, v2c vacmAccess constrains for full access. > > Also v3 noAuthNoPriv does not support the subletting as RFC > 2576 defined > for coexistence v1 v2c and there is where Rich's case applied for > granting or blocking access. > > If we agree the well know IP is the "only" way to talk to the CM for a > CPE with one hop ( CPE to CM DHCP IP queries forwarded through RF ) we > are OK and the vacm requirement may not needed, but some > clarifications > are needed in the spec. It creates the need to reconfigure > the user CPE > any time that a user may need to talk to the CM. > > > With current requirements in either case: > In the SNMP framework snmpv3 noAuthNoPRiv the access will be the same > for MSO and user Access. > > With the Interface scheme an MSO will be able to set two different v3 > users noAuthNoPriv with different access. > > If not the case we still have the issue of blocking NMS > spoofed Ips) and > the vacmAccessInterface is a way to block that. Or define the > ip forward > mechanism better. > > Eduardo > > > > > > -----Original Message----- > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > Sent: Tuesday, January 28, 2003 10:43 AM > To: 'IPCDN WG (E-mail)' > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Kevin, I think your point is accurate. > > Just to expand upon it some... > > Typically a CM will get a private IP address via DHCP. This > results in > access to the CM through the HFC interface being limited to within the > MSO's private IP network. "Outsiders" (e.g. user's on the > CMCI-side or > on the Internet) will not be able to access a CM through the HFC > interface. Access to the CM from the CMCI interface is still > allowed if > the proper SNMP access controls are setup. > > I want to make sure that this proposed extension to the VACM table > provides a good benefit over what is acheivable today with the > mechanisms we already have. > > greg > > > -----Original Message----- > > From: Marez Kevin-MGI1375 > > Sent: Tuesday, January 28, 2003 9:10 AM > > To: 'Woundy, Richard'; Nakanishi Greg-MGI8179 > > Cc: IPCDN WG (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > Rich, > > > > I understand the scenario you have presented, however, I think MSOs > > would typically use a private networking space for the RF-side and > > explicitly prevent access from outside that space. > > > > Our concern here is that we are adding an additional level of > > complexity to the vacmAccess table that doesn't provide a > great deal > > of benefit. > > > > Greg, please respond I have misstated anything or if you > have anything > > > you'd like to add. Thanks very much, > > > > Kevin > > > > > > -----Original Message----- > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > Sent: Wednesday, January 22, 2003 3:59 PM > > To: 'Marez Kevin-MGI1375' > > Cc: IPCDN WG (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > Kevin, > > > > Here is my comment on the VACM issue: > > > > >10) docsDevVacmAccessExtTable - Is this table really needed > > when using > > >SNMPv3? The limited security provided in SNMPv1/2 > > necessitated having > > >this functionality in the nmAccessTable. Given SNMPv3 > security, it > > >doesn't seem like this functionality is necessary anymore. > > > > I would agree that it is better security to authenticate a > keyed hash > > via SNMPv3, than to rely on the incoming device interface > for implied > > user identification. > > > > However, one interesting and important case is a CM diagnostic > > interface for subscriber-side queries, after the CM registration > > process is completed. It > > seems quite useful to allow subscriber tools (with SNMPv3 > > securityLevel of > > noAuthNoPriv) to query cable modems over the CMCI (CPE > > interface) but not > > over the RFI (RF interface). > > > > -- Rich > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 19:09:57 2003 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 TAA12078 for ; Tue, 28 Jan 2003 19:09:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0T0V7e32389 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 19:31:07 -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 h0T0V5J32380; Tue, 28 Jan 2003 19:31:05 -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 h0T0UKJ32329 for ; Tue, 28 Jan 2003 19:30:20 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12067 for ; Tue, 28 Jan 2003 19:08:37 -0500 (EST) Received: from mms01-relayb.tci.com (mms01-relayb.broadband.att.com [147.191.90.1]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h0T0C6st024799; Tue, 28 Jan 2003 17:12:06 -0700 (MST) Received: from 147.191.89.203 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Tue, 28 Jan 2003 17:11:58 -0600 Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 28 Jan 2003 17:12:03 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056635C9@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Nakanishi Greg-MGI8179'" , "'Eduardo Cardona'" cc: "IPCDN WG (E-mail)" , "DOCSIS OSS (E-mail)" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Date: Tue, 28 Jan 2003 17:11:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1229C3C41053889-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit You're assuming that the CMTS implements the Subscriber Management MIB, and has docsSubMgtPktFilterTable configured to prevent the forwarding of subscriber CPE traffic to the private net CMs, right? -- Rich -----Original Message----- From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] Sent: Tuesday, January 28, 2003 7:03 PM To: Woundy, Richard; 'Eduardo Cardona' Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... I agree that the application of ipFilters to packets addressed to the CM is not very clear in the spec. This topic comes up every now and then on the reflector. I believe the generally accepted interpretation is that traffic addressed to the CM is NOT filtered. The workaround that I proposed does not rely on the use of IP filters. It just relies on the the partitioning of the private IP network that the CM is part of and the public IP network that the CPE is part of. Typically, the CMTS will not route between these networks. A user can access through SNMP his/her own CM through the diagnostic IP address; however, a user cannot access someone elses CM. The packets from the user's CPE on the public network will not be routed by the CMTS to the private network on which someone else's CM resides. greg > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Tuesday, January 28, 2003 3:27 PM > To: 'Eduardo Cardona'; Nakanishi Greg-MGI8179 > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > I wonder whether current CM vendors typically check the > docsDevFilterIpTable > before they process a locally-addressed SNMP PDU. > > Anyone know? > > -- Rich > > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: Tuesday, January 28, 2003 4:53 PM > To: Woundy, Richard; Nakanishi Greg-MGI8179 > Cc: IPCDN WG (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > I forgot to mention something, > > 3.3.2.2. SNMPv3 Interface via vacm extension to be removed > > Going back to Greg's comments? > > Is the filtering flow in 3.3 accurated enough to solve that > in terms of > this filter schems? > > Seems that SNMP traffic (Section 3.3) is not intuitively > "forced" to go > to the ip filters (which after removing vacmExt will be mere NmAccess > Mode) before hitting the agent. ( I mean the NmAccess text > from rfc2669 > is distracting ?) > > I've seen people with different interpretations of how to "implement" > the filters based on directed to CM traffic or CM forwarded traffic > It may create confusion that as the diagram is following the Stack for > the RF-CPE or CPE-RF traffic the RF-CM CPE-CM trattic is not properly > represented : I add a little box of possible interpretation > that should > be clarified. > > > > ***************** > * LLC Filter In * > ***************** > | > v > ******************* > * Special Filters * > * | * > * V * > * ************ * > * * IP Spoof * * > * ************ * > * | * > * v * > > * *************** * > * * SNMP Access * * > * *************** * > * | * > ******************* > | ------> Wrong : SNMP to > CM traffic > processing > v > **************** > * IP Filter In * > **************** > | -------> Rigth: SNMP to > CM traffic > processing > v > ***************** > * IP Filter Out * > ***************** > | > v > ****************** > * LLC Filter Out * > ****************** > > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Tuesday, January 28, 2003 12:58 PM > To: Nakanishi Greg-MGI8179; Eduardo Cardona > Cc: IPCDN WG (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Eduardo, > > I am sympathetic to Greg and Kevin's argument that perhaps the > docsDevVacmAccessExtTable extension to VACM should be deleted from the > Cable Device MIB, for three reasons: > > 1. Greg seems to have proposed a workaround for the use case > I proposed. > Restating, the DOCSIS configuration file could set up the > docsDevFilterIpTable to reject UDP/SNMP traffic arriving on the RF/HFC > interface from any IP subnets other than the MSOs management station > subnets. This sounds like reasonable security practice in any > case, i.e. > don't just rely on SNMPv3 authentication. It enables subscriber CM > management from the CMCI side, but not subscriber/random user access > from the RF/HFC side, per my use case. 2. I agree it would be much > easier for vendors if they could leverage standard SNMP agent stack > implementations as much as possible. The extension for DOCSIS-only > devices makes this objective more difficult. 3. There is also a > possibility that the IETF MIB doctor might frown on a DOCSIS-specific > extension to the VACM MIB. > > Does anyone disagree? Shall I make this deletion? > > Are there any other comments on the current Cable Device MIB > -- which is > now posted on the IETF reflector, > bv2-04.txt > >? > > -- Rich > > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@cablelabs.com] > Sent: Tuesday, January 28, 2003 1:51 PM > To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Kevin, Greg, > > Following your thoughts. I think I got more findings that need to be > addressed in any case. > The vacmAccess Interface requirements is being as a proposal since the > early versions of this draft. > > We know your concerns and they are also related to different > discussion > in the reflector (i.e. controlling the number of traps/notification by > touching the Notification Originator subsystem in the SNMP entity ) > > In this case the difficulty is to modify the Access Control > Subsystem in > the SNMP entity, to being able to add the interface scheme, which is > perfectly valid under RFC2571/3411 architecture and AUGMENT clause in > RFC2578 > > > We need more thoughs in the SNMP constrains we are trying to achieve > with the full coverage of MSO needs. > > The need is there: > > what the SNMP stack providers may solve? (Greg concerns of available > tools/design framework) Will be Feasible or agree in certain > MSO/management constrains? ( few options below) Is the SNMPv3 group > addressing this case or had ever think about this as a standard > mechanism? > Will that be clearly extended for embedded cases with logical > interfaces > instead of physical ones ( to avoid security holes ? > > > Typical case: > > "Many" (how many is many?) CMs used to bridge the traffic (SNMP) > directed to the CM DHCP IP from the CPE through the RF interface > Upstream. > > For blocking traffic: > These is trivial since MSO is able to place SNMP filters in the > CMTS/backbone For getting CPE traffic: > Could be cumbersome in the presence of SNMP filters in the > gateway or a > CM unable to register. In the other hand the > MSO/technician/User, must > know the CM IP that could be a problem or not desired always. > > That one was partially solved with the well known IP 192.168.100.1 > > What is still a MSO constrain: > CMs able to talk to the SNMP stack from any CPE subnet ( > spoof NMS IP ) > ( 1 hop) and use the v1, v2c vacmAccess constrains for full access. > > Also v3 noAuthNoPriv does not support the subletting as RFC > 2576 defined > for coexistence v1 v2c and there is where Rich's case applied for > granting or blocking access. > > If we agree the well know IP is the "only" way to talk to the CM for a > CPE with one hop ( CPE to CM DHCP IP queries forwarded through RF ) we > are OK and the vacm requirement may not needed, but some > clarifications > are needed in the spec. It creates the need to reconfigure > the user CPE > any time that a user may need to talk to the CM. > > > With current requirements in either case: > In the SNMP framework snmpv3 noAuthNoPRiv the access will be the same > for MSO and user Access. > > With the Interface scheme an MSO will be able to set two different v3 > users noAuthNoPriv with different access. > > If not the case we still have the issue of blocking NMS > spoofed Ips) and > the vacmAccessInterface is a way to block that. Or define the > ip forward > mechanism better. > > Eduardo > > > > > > -----Original Message----- > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > Sent: Tuesday, January 28, 2003 10:43 AM > To: 'IPCDN WG (E-mail)' > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Kevin, I think your point is accurate. > > Just to expand upon it some... > > Typically a CM will get a private IP address via DHCP. This > results in > access to the CM through the HFC interface being limited to within the > MSO's private IP network. "Outsiders" (e.g. user's on the > CMCI-side or > on the Internet) will not be able to access a CM through the HFC > interface. Access to the CM from the CMCI interface is still > allowed if > the proper SNMP access controls are setup. > > I want to make sure that this proposed extension to the VACM table > provides a good benefit over what is acheivable today with the > mechanisms we already have. > > greg > > > -----Original Message----- > > From: Marez Kevin-MGI1375 > > Sent: Tuesday, January 28, 2003 9:10 AM > > To: 'Woundy, Richard'; Nakanishi Greg-MGI8179 > > Cc: IPCDN WG (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > Rich, > > > > I understand the scenario you have presented, however, I think MSOs > > would typically use a private networking space for the RF-side and > > explicitly prevent access from outside that space. > > > > Our concern here is that we are adding an additional level of > > complexity to the vacmAccess table that doesn't provide a > great deal > > of benefit. > > > > Greg, please respond I have misstated anything or if you > have anything > > > you'd like to add. Thanks very much, > > > > Kevin > > > > > > -----Original Message----- > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > Sent: Wednesday, January 22, 2003 3:59 PM > > To: 'Marez Kevin-MGI1375' > > Cc: IPCDN WG (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > Kevin, > > > > Here is my comment on the VACM issue: > > > > >10) docsDevVacmAccessExtTable - Is this table really needed > > when using > > >SNMPv3? The limited security provided in SNMPv1/2 > > necessitated having > > >this functionality in the nmAccessTable. Given SNMPv3 > security, it > > >doesn't seem like this functionality is necessary anymore. > > > > I would agree that it is better security to authenticate a > keyed hash > > via SNMPv3, than to rely on the incoming device interface > for implied > > user identification. > > > > However, one interesting and important case is a CM diagnostic > > interface for subscriber-side queries, after the CM registration > > process is completed. It > > seems quite useful to allow subscriber tools (with SNMPv3 > > securityLevel of > > noAuthNoPriv) to query cable modems over the CMCI (CPE > > interface) but not > > over the RFI (RF interface). > > > > -- Rich > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 19:21:06 2003 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 TAA12263 for ; Tue, 28 Jan 2003 19:21:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0T0gHn00958 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 19:42:17 -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 h0T0gFJ00943; Tue, 28 Jan 2003 19:42:15 -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 h0T0emJ00839 for ; Tue, 28 Jan 2003 19:40:48 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12230 for ; Tue, 28 Jan 2003 19:19:05 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h0T0MZxN011266 for ; Tue, 28 Jan 2003 17:22:35 -0700 (MST) Received: [from ca25exm01.GI.COM (ca25exm01.gi.com [168.84.84.121]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id RAA03480 for ; Tue, 28 Jan 2003 17:21:35 -0700 (MST)] Received: by ca25exm01 with Internet Mail Service (5.5.2656.59) id ; Tue, 28 Jan 2003 16:22:35 -0800 Message-ID: From: Nakanishi Greg-MGI8179 To: "'Woundy, Richard'" , "'Eduardo Cardona'" Cc: "IPCDN WG (E-mail)" , "DOCSIS OSS (E-mail)" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Date: Tue, 28 Jan 2003 16:22:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , That could be one implementation. Another possibility is it could be done through IP forwarding tables. Conceptually, the CMTS HFC interface is connected to two networks - one public and one private. When a packet is received on the public interface (i.e. from the CPE) that is addressed to the private network, the forwarding table would not have a route for it and discards the packet. Although I don't know the CMTS implementation specifics, my understanding is that the described behavior is the way most MSOs operate their network. i.e. CPE cannot communicate with someone else's CM. greg > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Tuesday, January 28, 2003 4:12 PM > To: 'Nakanishi Greg-MGI8179'; 'Eduardo Cardona' > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > You're assuming that the CMTS implements the Subscriber > Management MIB, and > has docsSubMgtPktFilterTable configured to prevent the forwarding of > subscriber CPE traffic to the private net CMs, right? > > -- Rich > > -----Original Message----- > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > Sent: Tuesday, January 28, 2003 7:03 PM > To: Woundy, Richard; 'Eduardo Cardona' > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > I agree that the application of ipFilters to packets > addressed to the CM is > not very clear in the spec. This topic comes up every now > and then on the > reflector. I believe the generally accepted interpretation > is that traffic > addressed to the CM is NOT filtered. > > The workaround that I proposed does not rely on the use of IP > filters. It > just relies on the the partitioning of the private IP network > that the CM is > part of and the public IP network that the CPE is part of. > Typically, the > CMTS will not route between these networks. > > A user can access through SNMP his/her own CM through the > diagnostic IP > address; however, a user cannot access someone elses CM. The > packets from > the user's CPE on the public network will not be routed by > the CMTS to the > private network on which someone else's CM resides. > > greg > > > -----Original Message----- > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > Sent: Tuesday, January 28, 2003 3:27 PM > > To: 'Eduardo Cardona'; Nakanishi Greg-MGI8179 > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > I wonder whether current CM vendors typically check the > > docsDevFilterIpTable > > before they process a locally-addressed SNMP PDU. > > > > Anyone know? > > > > -- Rich > > > > -----Original Message----- > > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > > Sent: Tuesday, January 28, 2003 4:53 PM > > To: Woundy, Richard; Nakanishi Greg-MGI8179 > > Cc: IPCDN WG (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > I forgot to mention something, > > > > 3.3.2.2. SNMPv3 Interface via vacm extension to be removed > > > > Going back to Greg's comments? > > > > Is the filtering flow in 3.3 accurated enough to solve that > > in terms of > > this filter schems? > > > > Seems that SNMP traffic (Section 3.3) is not intuitively > > "forced" to go > > to the ip filters (which after removing vacmExt will be > mere NmAccess > > Mode) before hitting the agent. ( I mean the NmAccess text > > from rfc2669 > > is distracting ?) > > > > I've seen people with different interpretations of how to > "implement" > > the filters based on directed to CM traffic or CM forwarded traffic > > It may create confusion that as the diagram is following > the Stack for > > the RF-CPE or CPE-RF traffic the RF-CM CPE-CM trattic is > not properly > > represented : I add a little box of possible interpretation > > that should > > be clarified. > > > > > > > > ***************** > > * LLC Filter In * > > ***************** > > | > > v > > ******************* > > * Special Filters * > > * | * > > * V * > > * ************ * > > * * IP Spoof * * > > * ************ * > > * | * > > * v * > > > > * *************** * > > * * SNMP Access * * > > * *************** * > > * | * > > ******************* > > | ------> Wrong : SNMP to > > CM traffic > > processing > > v > > **************** > > * IP Filter In * > > **************** > > | -------> Rigth: SNMP to > > CM traffic > > processing > > v > > ***************** > > * IP Filter Out * > > ***************** > > | > > v > > ****************** > > * LLC Filter Out * > > ****************** > > > > -----Original Message----- > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > Sent: Tuesday, January 28, 2003 12:58 PM > > To: Nakanishi Greg-MGI8179; Eduardo Cardona > > Cc: IPCDN WG (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > Eduardo, > > > > I am sympathetic to Greg and Kevin's argument that perhaps the > > docsDevVacmAccessExtTable extension to VACM should be > deleted from the > > Cable Device MIB, for three reasons: > > > > 1. Greg seems to have proposed a workaround for the use case > > I proposed. > > Restating, the DOCSIS configuration file could set up the > > docsDevFilterIpTable to reject UDP/SNMP traffic arriving on > the RF/HFC > > interface from any IP subnets other than the MSOs management station > > subnets. This sounds like reasonable security practice in any > > case, i.e. > > don't just rely on SNMPv3 authentication. It enables subscriber CM > > management from the CMCI side, but not subscriber/random user access > > from the RF/HFC side, per my use case. 2. I agree it would be much > > easier for vendors if they could leverage standard SNMP agent stack > > implementations as much as possible. The extension for DOCSIS-only > > devices makes this objective more difficult. 3. There is also a > > possibility that the IETF MIB doctor might frown on a > DOCSIS-specific > > extension to the VACM MIB. > > > > Does anyone disagree? Shall I make this deletion? > > > > Are there any other comments on the current Cable Device MIB > > -- which is > > now posted on the IETF reflector, > > > bv2-04.txt > > >? > > > > -- Rich > > > > -----Original Message----- > > From: Eduardo Cardona [mailto:e.cardona@cablelabs.com] > > Sent: Tuesday, January 28, 2003 1:51 PM > > To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > Kevin, Greg, > > > > Following your thoughts. I think I got more findings that need to be > > addressed in any case. > > The vacmAccess Interface requirements is being as a > proposal since the > > early versions of this draft. > > > > We know your concerns and they are also related to different > > discussion > > in the reflector (i.e. controlling the number of > traps/notification by > > touching the Notification Originator subsystem in the SNMP entity ) > > > > In this case the difficulty is to modify the Access Control > > Subsystem in > > the SNMP entity, to being able to add the interface scheme, which is > > perfectly valid under RFC2571/3411 architecture and AUGMENT > clause in > > RFC2578 > > > > > > We need more thoughs in the SNMP constrains we are trying to achieve > > with the full coverage of MSO needs. > > > > The need is there: > > > > what the SNMP stack providers may solve? (Greg concerns of > available > > tools/design framework) Will be Feasible or agree in certain > > MSO/management constrains? ( few options below) Is the SNMPv3 group > > addressing this case or had ever think about this as a standard > > mechanism? > > Will that be clearly extended for embedded cases with logical > > interfaces > > instead of physical ones ( to avoid security holes ? > > > > > > Typical case: > > > > "Many" (how many is many?) CMs used to bridge the traffic (SNMP) > > directed to the CM DHCP IP from the CPE through the RF interface > > Upstream. > > > > For blocking traffic: > > These is trivial since MSO is able to place SNMP filters in the > > CMTS/backbone For getting CPE traffic: > > Could be cumbersome in the presence of SNMP filters in the > > gateway or a > > CM unable to register. In the other hand the > > MSO/technician/User, must > > know the CM IP that could be a problem or not desired always. > > > > That one was partially solved with the well known IP 192.168.100.1 > > > > What is still a MSO constrain: > > CMs able to talk to the SNMP stack from any CPE subnet ( > > spoof NMS IP ) > > ( 1 hop) and use the v1, v2c vacmAccess constrains for full access. > > > > Also v3 noAuthNoPriv does not support the subletting as RFC > > 2576 defined > > for coexistence v1 v2c and there is where Rich's case applied for > > granting or blocking access. > > > > If we agree the well know IP is the "only" way to talk to > the CM for a > > CPE with one hop ( CPE to CM DHCP IP queries forwarded > through RF ) we > > are OK and the vacm requirement may not needed, but some > > clarifications > > are needed in the spec. It creates the need to reconfigure > > the user CPE > > any time that a user may need to talk to the CM. > > > > > > With current requirements in either case: > > In the SNMP framework snmpv3 noAuthNoPRiv the access will > be the same > > for MSO and user Access. > > > > With the Interface scheme an MSO will be able to set two > different v3 > > users noAuthNoPriv with different access. > > > > If not the case we still have the issue of blocking NMS > > spoofed Ips) and > > the vacmAccessInterface is a way to block that. Or define the > > ip forward > > mechanism better. > > > > Eduardo > > > > > > > > > > > > -----Original Message----- > > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > > Sent: Tuesday, January 28, 2003 10:43 AM > > To: 'IPCDN WG (E-mail)' > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > Kevin, I think your point is accurate. > > > > Just to expand upon it some... > > > > Typically a CM will get a private IP address via DHCP. This > > results in > > access to the CM through the HFC interface being limited to > within the > > MSO's private IP network. "Outsiders" (e.g. user's on the > > CMCI-side or > > on the Internet) will not be able to access a CM through the HFC > > interface. Access to the CM from the CMCI interface is still > > allowed if > > the proper SNMP access controls are setup. > > > > I want to make sure that this proposed extension to the VACM table > > provides a good benefit over what is acheivable today with the > > mechanisms we already have. > > > > greg > > > > > -----Original Message----- > > > From: Marez Kevin-MGI1375 > > > Sent: Tuesday, January 28, 2003 9:10 AM > > > To: 'Woundy, Richard'; Nakanishi Greg-MGI8179 > > > Cc: IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Rich, > > > > > > I understand the scenario you have presented, however, I > think MSOs > > > would typically use a private networking space for the > RF-side and > > > explicitly prevent access from outside that space. > > > > > > Our concern here is that we are adding an additional level of > > > complexity to the vacmAccess table that doesn't provide a > > great deal > > > of benefit. > > > > > > Greg, please respond I have misstated anything or if you > > have anything > > > > > you'd like to add. Thanks very much, > > > > > > Kevin > > > > > > > > > -----Original Message----- > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > Sent: Wednesday, January 22, 2003 3:59 PM > > > To: 'Marez Kevin-MGI1375' > > > Cc: IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Kevin, > > > > > > Here is my comment on the VACM issue: > > > > > > >10) docsDevVacmAccessExtTable - Is this table really needed > > > when using > > > >SNMPv3? The limited security provided in SNMPv1/2 > > > necessitated having > > > >this functionality in the nmAccessTable. Given SNMPv3 > > security, it > > > >doesn't seem like this functionality is necessary anymore. > > > > > > I would agree that it is better security to authenticate a > > keyed hash > > > via SNMPv3, than to rely on the incoming device interface > > for implied > > > user identification. > > > > > > However, one interesting and important case is a CM diagnostic > > > interface for subscriber-side queries, after the CM registration > > > process is completed. It > > > seems quite useful to allow subscriber tools (with SNMPv3 > > > securityLevel of > > > noAuthNoPriv) to query cable modems over the CMCI (CPE > > > interface) but not > > > over the RFI (RF interface). > > > > > > -- Rich > > > > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipcdn > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipcdn > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 19:24:50 2003 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 TAA12398 for ; Tue, 28 Jan 2003 19:24:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0T0k1B01172 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 19:46:01 -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 h0T0k0J01161; Tue, 28 Jan 2003 19:46:00 -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 h0T0jjJ01134 for ; Tue, 28 Jan 2003 19:45:45 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12369 for ; Tue, 28 Jan 2003 19:24:03 -0500 (EST) Received: from mms01-relayb.tci.com (mms01-relayb.broadband.att.com [147.191.90.1]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h0T0RYst028432; Tue, 28 Jan 2003 17:27:34 -0700 (MST) Received: from 147.191.90.11 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Tue, 28 Jan 2003 17:27:24 -0600 Received: by entexchimc04.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 28 Jan 2003 17:26:53 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056635CB@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "David Raftus (E-mail)" cc: "IPCDN WG (E-mail)" Date: Tue, 28 Jan 2003 17:27:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1229C0661055426-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] SMICng warnings from draft-ietf-ipcdn-docs-rfmibv2-05.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit David, I generated the following SMICng warning message in compiling : W: f(DOCS-IF-MIB.mi2), (1005,21) Item "docsIfSigQEqualizationData" should have SIZE specified W: f(DOCS-IF-MIB.mi2), (1246,21) Item "docsIfCmStatusCode" should have SIZE specified W: f(DOCS-IF-MIB.mi2), (1413,21) Item "docsIfCmStatusEqualizationData" should have SIZE specified W: f(DOCS-IF-MIB.mi2), (1962,21) Item "docsIfCmtsCmStatusEqualizationData" should have SIZE specified W: f(DOCS-IF-MIB.mi2), (2882,1) Item "docsIfCmtsDownChnlCtrId" is not contained in any group defined in the current module W: f(DOCS-IF-MIB.mi2), (3013,1) Item "docsIfCmtsUpChnlCtrId" is not contained in any group defined in the current module W: f(DOCS-IF-MIB.mi2), (3657,9) Duplicate item "docsIfQosProfPriority" in compliances list for module "DOCS-IF-MIB" Let me know if you need any assistance in fixing the warnings above. I also found but am ignoring these two warning messages: W: f(DOCS-IF-MIB.mi2), (3932,1) OBJECT-GROUP "docsIfObsoleteGroup" is not used in a MODULE-COMPLIANCE in current module W: f(DOCS-IF-MIB.mi2), (3942,1) OBJECT-GROUP "docsIfDeprecatedGroup" is not used in a MODULE-COMPLIANCE in current module -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 20:02:57 2003 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 UAA13088 for ; Tue, 28 Jan 2003 20:02:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0T1O9Q03437 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 20:24:09 -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 h0T1O8J03430; Tue, 28 Jan 2003 20:24:08 -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 h0T1N6J03402 for ; Tue, 28 Jan 2003 20:23:06 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13079 for ; Tue, 28 Jan 2003 20:01:21 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id h0T14nwH016986; Tue, 28 Jan 2003 18:04:49 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 28 Jan 2003 18:04:48 -0700 Message-ID: Thread-Topic: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Thread-Index: AcLHLIm1pzW3gD1xS/WOSxhBCp/4ZgAASiyw From: "Eduardo Cardona" To: "Nakanishi Greg-MGI8179" , "Woundy, Richard" Cc: "IPCDN WG (E-mail)" , "DOCSIS OSS Majordomo List" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0T1N6J03403 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Greg, The IP spaces is fine as soon as the user does not try to spoof an NMS IP (where NmAccess beats SNMP by supporting interfaces for the non authenticated communication) Q1: Does ALL CMs forward (theoretically yes because are bridges) to RFI all ( no ICMP) traffic (including CM DHCP IP) but "diagnostic IP destination? If YES Greg's scenario follows the MSO normal filtering conditions ( i.e UDP/TCP port fitering between subnets) If NO The case I am mentioning is a user spoofing an NMS IP (matches Ip subnet) and contacting the CH DHCP IP and then, the CM processes packet without forwarding it to the network, replying back to the user. To avoid the vacmExt, if the answer is 'NO', I think the below rules may aliviate some problems: Flow type Destination 1) CPE -> CM SNMP "Diagnostic IP" YES 2) CPE -> CM SNMP CM DHCP IP NO -Q1- 3) CPE -> CM ICMP "Diagnostic IP" YES 4) CPE -> CM ICMP CM DHCP IP YES 5) CPE -> CM Other IP both NO ( some cases YES as top services run in CM stack like HTTP) Req 2) seems to be the problem for the Interface requirement. What makes is: Address Q1 in Coexistence v1, v2c V3 noAuthNoPriv if configured, (nothing to do) : same access level both NMS and CPE users ( limited view recommended) Eduardo -----Original Message----- From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] Sent: Tuesday, January 28, 2003 5:22 PM To: 'Woundy, Richard'; Eduardo Cardona Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... That could be one implementation. Another possibility is it could be done through IP forwarding tables. Conceptually, the CMTS HFC interface is connected to two networks - one public and one private. When a packet is received on the public interface (i.e. from the CPE) that is addressed to the private network, the forwarding table would not have a route for it and discards the packet. Although I don't know the CMTS implementation specifics, my understanding is that the described behavior is the way most MSOs operate their network. i.e. CPE cannot communicate with someone else's CM. greg > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Tuesday, January 28, 2003 4:12 PM > To: 'Nakanishi Greg-MGI8179'; 'Eduardo Cardona' > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > You're assuming that the CMTS implements the Subscriber > Management MIB, and > has docsSubMgtPktFilterTable configured to prevent the forwarding of > subscriber CPE traffic to the private net CMs, right? > > -- Rich > > -----Original Message----- > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > Sent: Tuesday, January 28, 2003 7:03 PM > To: Woundy, Richard; 'Eduardo Cardona' > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > I agree that the application of ipFilters to packets > addressed to the CM is > not very clear in the spec. This topic comes up every now > and then on the > reflector. I believe the generally accepted interpretation > is that traffic > addressed to the CM is NOT filtered. > > The workaround that I proposed does not rely on the use of IP > filters. It > just relies on the the partitioning of the private IP network > that the CM is > part of and the public IP network that the CPE is part of. > Typically, the > CMTS will not route between these networks. > > A user can access through SNMP his/her own CM through the > diagnostic IP > address; however, a user cannot access someone elses CM. The > packets from > the user's CPE on the public network will not be routed by > the CMTS to the > private network on which someone else's CM resides. > > greg > > > -----Original Message----- > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > Sent: Tuesday, January 28, 2003 3:27 PM > > To: 'Eduardo Cardona'; Nakanishi Greg-MGI8179 > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > I wonder whether current CM vendors typically check the > > docsDevFilterIpTable > > before they process a locally-addressed SNMP PDU. > > > > Anyone know? > > > > -- Rich > > > > -----Original Message----- > > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > > Sent: Tuesday, January 28, 2003 4:53 PM > > To: Woundy, Richard; Nakanishi Greg-MGI8179 > > Cc: IPCDN WG (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > I forgot to mention something, > > > > 3.3.2.2. SNMPv3 Interface via vacm extension to be removed > > > > Going back to Greg's comments? > > > > Is the filtering flow in 3.3 accurated enough to solve that > > in terms of > > this filter schems? > > > > Seems that SNMP traffic (Section 3.3) is not intuitively > > "forced" to go > > to the ip filters (which after removing vacmExt will be > mere NmAccess > > Mode) before hitting the agent. ( I mean the NmAccess text > > from rfc2669 > > is distracting ?) > > > > I've seen people with different interpretations of how to > "implement" > > the filters based on directed to CM traffic or CM forwarded traffic > > It may create confusion that as the diagram is following > the Stack for > > the RF-CPE or CPE-RF traffic the RF-CM CPE-CM trattic is > not properly > > represented : I add a little box of possible interpretation > > that should > > be clarified. > > > > > > > > ***************** > > * LLC Filter In * > > ***************** > > | > > v > > ******************* > > * Special Filters * > > * | * > > * V * > > * ************ * > > * * IP Spoof * * > > * ************ * > > * | * > > * v * > > > > * *************** * > > * * SNMP Access * * > > * *************** * > > * | * > > ******************* > > | ------> Wrong : SNMP to > > CM traffic > > processing > > v > > **************** > > * IP Filter In * > > **************** > > | -------> Rigth: SNMP to > > CM traffic > > processing > > v > > ***************** > > * IP Filter Out * > > ***************** > > | > > v > > ****************** > > * LLC Filter Out * > > ****************** > > > > -----Original Message----- > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > Sent: Tuesday, January 28, 2003 12:58 PM > > To: Nakanishi Greg-MGI8179; Eduardo Cardona > > Cc: IPCDN WG (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > Eduardo, > > > > I am sympathetic to Greg and Kevin's argument that perhaps the > > docsDevVacmAccessExtTable extension to VACM should be > deleted from the > > Cable Device MIB, for three reasons: > > > > 1. Greg seems to have proposed a workaround for the use case > > I proposed. > > Restating, the DOCSIS configuration file could set up the > > docsDevFilterIpTable to reject UDP/SNMP traffic arriving on > the RF/HFC > > interface from any IP subnets other than the MSOs management station > > subnets. This sounds like reasonable security practice in any case, > > i.e. don't just rely on SNMPv3 authentication. It enables subscriber > > CM management from the CMCI side, but not subscriber/random user > > access from the RF/HFC side, per my use case. 2. I agree it would be > > much easier for vendors if they could leverage standard SNMP agent > > stack implementations as much as possible. The extension for > > DOCSIS-only devices makes this objective more difficult. 3. There is > > also a possibility that the IETF MIB doctor might frown on a > DOCSIS-specific > > extension to the VACM MIB. > > > > Does anyone disagree? Shall I make this deletion? > > > > Are there any other comments on the current Cable Device MIB > > -- which is > > now posted on the IETF reflector, > > > bv2-04.txt > > >? > > > > -- Rich > > > > -----Original Message----- > > From: Eduardo Cardona [mailto:e.cardona@cablelabs.com] > > Sent: Tuesday, January 28, 2003 1:51 PM > > To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > Kevin, Greg, > > > > Following your thoughts. I think I got more findings that need to be > > addressed in any case. The vacmAccess Interface requirements is > > being as a > proposal since the > > early versions of this draft. > > > > We know your concerns and they are also related to different > > discussion > > in the reflector (i.e. controlling the number of > traps/notification by > > touching the Notification Originator subsystem in the SNMP entity ) > > > > In this case the difficulty is to modify the Access Control > > Subsystem in > > the SNMP entity, to being able to add the interface scheme, which is > > perfectly valid under RFC2571/3411 architecture and AUGMENT > clause in > > RFC2578 > > > > > > We need more thoughs in the SNMP constrains we are trying to achieve > > with the full coverage of MSO needs. > > > > The need is there: > > > > what the SNMP stack providers may solve? (Greg concerns of > available > > tools/design framework) Will be Feasible or agree in certain > > MSO/management constrains? ( few options below) Is the SNMPv3 group > > addressing this case or had ever think about this as a standard > > mechanism? Will that be clearly extended for embedded cases with > > logical interfaces > > instead of physical ones ( to avoid security holes ? > > > > > > Typical case: > > > > "Many" (how many is many?) CMs used to bridge the traffic (SNMP) > > directed to the CM DHCP IP from the CPE through the RF interface > > Upstream. > > > > For blocking traffic: > > These is trivial since MSO is able to place SNMP filters in the > > CMTS/backbone For getting CPE traffic: > > Could be cumbersome in the presence of SNMP filters in the > > gateway or a > > CM unable to register. In the other hand the > > MSO/technician/User, must > > know the CM IP that could be a problem or not desired always. > > > > That one was partially solved with the well known IP 192.168.100.1 > > > > What is still a MSO constrain: > > CMs able to talk to the SNMP stack from any CPE subnet ( > > spoof NMS IP ) > > ( 1 hop) and use the v1, v2c vacmAccess constrains for full access. > > > > Also v3 noAuthNoPriv does not support the subletting as RFC > > 2576 defined > > for coexistence v1 v2c and there is where Rich's case applied for > > granting or blocking access. > > > > If we agree the well know IP is the "only" way to talk to > the CM for a > > CPE with one hop ( CPE to CM DHCP IP queries forwarded > through RF ) we > > are OK and the vacm requirement may not needed, but some > > clarifications > > are needed in the spec. It creates the need to reconfigure > > the user CPE > > any time that a user may need to talk to the CM. > > > > > > With current requirements in either case: > > In the SNMP framework snmpv3 noAuthNoPRiv the access will > be the same > > for MSO and user Access. > > > > With the Interface scheme an MSO will be able to set two > different v3 > > users noAuthNoPriv with different access. > > > > If not the case we still have the issue of blocking NMS > > spoofed Ips) and > > the vacmAccessInterface is a way to block that. Or define the > > ip forward > > mechanism better. > > > > Eduardo > > > > > > > > > > > > -----Original Message----- > > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > > Sent: Tuesday, January 28, 2003 10:43 AM > > To: 'IPCDN WG (E-mail)' > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > Kevin, I think your point is accurate. > > > > Just to expand upon it some... > > > > Typically a CM will get a private IP address via DHCP. This > > results in > > access to the CM through the HFC interface being limited to > within the > > MSO's private IP network. "Outsiders" (e.g. user's on the > > CMCI-side or > > on the Internet) will not be able to access a CM through the HFC > > interface. Access to the CM from the CMCI interface is still > > allowed if > > the proper SNMP access controls are setup. > > > > I want to make sure that this proposed extension to the VACM table > > provides a good benefit over what is acheivable today with the > > mechanisms we already have. > > > > greg > > > > > -----Original Message----- > > > From: Marez Kevin-MGI1375 > > > Sent: Tuesday, January 28, 2003 9:10 AM > > > To: 'Woundy, Richard'; Nakanishi Greg-MGI8179 > > > Cc: IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Rich, > > > > > > I understand the scenario you have presented, however, I > think MSOs > > > would typically use a private networking space for the > RF-side and > > > explicitly prevent access from outside that space. > > > > > > Our concern here is that we are adding an additional level of > > > complexity to the vacmAccess table that doesn't provide a > > great deal > > > of benefit. > > > > > > Greg, please respond I have misstated anything or if you > > have anything > > > > > you'd like to add. Thanks very much, > > > > > > Kevin > > > > > > > > > -----Original Message----- > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > Sent: Wednesday, January 22, 2003 3:59 PM > > > To: 'Marez Kevin-MGI1375' > > > Cc: IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Kevin, > > > > > > Here is my comment on the VACM issue: > > > > > > >10) docsDevVacmAccessExtTable - Is this table really needed > > > when using > > > >SNMPv3? The limited security provided in SNMPv1/2 > > > necessitated having > > > >this functionality in the nmAccessTable. Given SNMPv3 > > security, it > > > >doesn't seem like this functionality is necessary anymore. > > > > > > I would agree that it is better security to authenticate a > > keyed hash > > > via SNMPv3, than to rely on the incoming device interface > > for implied > > > user identification. > > > > > > However, one interesting and important case is a CM diagnostic > > > interface for subscriber-side queries, after the CM registration > > > process is completed. It > > > seems quite useful to allow subscriber tools (with SNMPv3 > > > securityLevel of > > > noAuthNoPriv) to query cable modems over the CMCI (CPE > > > interface) but not > > > over the RFI (RF interface). > > > > > > -- Rich > > > > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipcdn > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipcdn > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 20:14:50 2003 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 UAA13275 for ; Tue, 28 Jan 2003 20:14:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0T1a2j03964 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 20:36:02 -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 h0T1a0J03945; Tue, 28 Jan 2003 20:36:00 -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 h0T1ZXJ03915 for ; Tue, 28 Jan 2003 20:35:33 -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 UAA13260 for ; Tue, 28 Jan 2003 20:13:48 -0500 (EST) Received: from mms02-relaya.tci.com (mms02-relaya.broadband.att.com [147.191.89.206]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id h0T1HHJD019504; Tue, 28 Jan 2003 18:17:17 -0700 (MST) Received: from 147.191.89.203 by mms02-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Tue, 28 Jan 2003 18:17:10 -0600 Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 28 Jan 2003 18:17:16 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056635CD@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Nakanishi Greg-MGI8179'" , "'Eduardo Cardona'" cc: "IPCDN WG (E-mail)" , "DOCSIS OSS (E-mail)" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Date: Tue, 28 Jan 2003 18:17:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1229F41C969930-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Most CMTS deployments (that I am aware of) use a CMTS with a single IP forwarding table, which forwards traffic based on destination IP address only. That's even true in the Comcast and TWC footprints that concurrently support multiple Internet service providers. Some CMTS software supports multiple IP forwarding tables, where different forwarding tables are used for different traffic sources. That is particularly true for CMTSs that support MPLS and/or MPLS VPNs. Note that a CMTS can be implemented as a pure bridge, with no IP forwarding table at all. Hence my comment about the Subscriber Management MIB. But I guess we agree that there are multiple technical alternatives to extending the VACM table for CM diagnostic access by subscribers. -- Rich -----Original Message----- From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] Sent: Tuesday, January 28, 2003 7:22 PM To: Woundy, Richard; 'Eduardo Cardona' Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... That could be one implementation. Another possibility is it could be done through IP forwarding tables. Conceptually, the CMTS HFC interface is connected to two networks - one public and one private. When a packet is received on the public interface (i.e. from the CPE) that is addressed to the private network, the forwarding table would not have a route for it and discards the packet. Although I don't know the CMTS implementation specifics, my understanding is that the described behavior is the way most MSOs operate their network. i.e. CPE cannot communicate with someone else's CM. greg > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Tuesday, January 28, 2003 4:12 PM > To: 'Nakanishi Greg-MGI8179'; 'Eduardo Cardona' > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > You're assuming that the CMTS implements the Subscriber > Management MIB, and > has docsSubMgtPktFilterTable configured to prevent the forwarding of > subscriber CPE traffic to the private net CMs, right? > > -- Rich > > -----Original Message----- > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > Sent: Tuesday, January 28, 2003 7:03 PM > To: Woundy, Richard; 'Eduardo Cardona' > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > I agree that the application of ipFilters to packets > addressed to the CM is > not very clear in the spec. This topic comes up every now > and then on the > reflector. I believe the generally accepted interpretation > is that traffic > addressed to the CM is NOT filtered. > > The workaround that I proposed does not rely on the use of IP > filters. It > just relies on the the partitioning of the private IP network > that the CM is > part of and the public IP network that the CPE is part of. > Typically, the > CMTS will not route between these networks. > > A user can access through SNMP his/her own CM through the > diagnostic IP > address; however, a user cannot access someone elses CM. The > packets from > the user's CPE on the public network will not be routed by > the CMTS to the > private network on which someone else's CM resides. > > greg > > > -----Original Message----- > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > Sent: Tuesday, January 28, 2003 3:27 PM > > To: 'Eduardo Cardona'; Nakanishi Greg-MGI8179 > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > I wonder whether current CM vendors typically check the > > docsDevFilterIpTable > > before they process a locally-addressed SNMP PDU. > > > > Anyone know? > > > > -- Rich > > > > -----Original Message----- > > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > > Sent: Tuesday, January 28, 2003 4:53 PM > > To: Woundy, Richard; Nakanishi Greg-MGI8179 > > Cc: IPCDN WG (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > I forgot to mention something, > > > > 3.3.2.2. SNMPv3 Interface via vacm extension to be removed > > > > Going back to Greg's comments? > > > > Is the filtering flow in 3.3 accurated enough to solve that > > in terms of > > this filter schems? > > > > Seems that SNMP traffic (Section 3.3) is not intuitively > > "forced" to go > > to the ip filters (which after removing vacmExt will be > mere NmAccess > > Mode) before hitting the agent. ( I mean the NmAccess text > > from rfc2669 > > is distracting ?) > > > > I've seen people with different interpretations of how to > "implement" > > the filters based on directed to CM traffic or CM forwarded traffic > > It may create confusion that as the diagram is following > the Stack for > > the RF-CPE or CPE-RF traffic the RF-CM CPE-CM trattic is > not properly > > represented : I add a little box of possible interpretation > > that should > > be clarified. > > > > > > > > ***************** > > * LLC Filter In * > > ***************** > > | > > v > > ******************* > > * Special Filters * > > * | * > > * V * > > * ************ * > > * * IP Spoof * * > > * ************ * > > * | * > > * v * > > > > * *************** * > > * * SNMP Access * * > > * *************** * > > * | * > > ******************* > > | ------> Wrong : SNMP to > > CM traffic > > processing > > v > > **************** > > * IP Filter In * > > **************** > > | -------> Rigth: SNMP to > > CM traffic > > processing > > v > > ***************** > > * IP Filter Out * > > ***************** > > | > > v > > ****************** > > * LLC Filter Out * > > ****************** > > > > -----Original Message----- > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > Sent: Tuesday, January 28, 2003 12:58 PM > > To: Nakanishi Greg-MGI8179; Eduardo Cardona > > Cc: IPCDN WG (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > Eduardo, > > > > I am sympathetic to Greg and Kevin's argument that perhaps the > > docsDevVacmAccessExtTable extension to VACM should be > deleted from the > > Cable Device MIB, for three reasons: > > > > 1. Greg seems to have proposed a workaround for the use case > > I proposed. > > Restating, the DOCSIS configuration file could set up the > > docsDevFilterIpTable to reject UDP/SNMP traffic arriving on > the RF/HFC > > interface from any IP subnets other than the MSOs management station > > subnets. This sounds like reasonable security practice in any > > case, i.e. > > don't just rely on SNMPv3 authentication. It enables subscriber CM > > management from the CMCI side, but not subscriber/random user access > > from the RF/HFC side, per my use case. 2. I agree it would be much > > easier for vendors if they could leverage standard SNMP agent stack > > implementations as much as possible. The extension for DOCSIS-only > > devices makes this objective more difficult. 3. There is also a > > possibility that the IETF MIB doctor might frown on a > DOCSIS-specific > > extension to the VACM MIB. > > > > Does anyone disagree? Shall I make this deletion? > > > > Are there any other comments on the current Cable Device MIB > > -- which is > > now posted on the IETF reflector, > > > bv2-04.txt > > >? > > > > -- Rich > > > > -----Original Message----- > > From: Eduardo Cardona [mailto:e.cardona@cablelabs.com] > > Sent: Tuesday, January 28, 2003 1:51 PM > > To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > Kevin, Greg, > > > > Following your thoughts. I think I got more findings that need to be > > addressed in any case. > > The vacmAccess Interface requirements is being as a > proposal since the > > early versions of this draft. > > > > We know your concerns and they are also related to different > > discussion > > in the reflector (i.e. controlling the number of > traps/notification by > > touching the Notification Originator subsystem in the SNMP entity ) > > > > In this case the difficulty is to modify the Access Control > > Subsystem in > > the SNMP entity, to being able to add the interface scheme, which is > > perfectly valid under RFC2571/3411 architecture and AUGMENT > clause in > > RFC2578 > > > > > > We need more thoughs in the SNMP constrains we are trying to achieve > > with the full coverage of MSO needs. > > > > The need is there: > > > > what the SNMP stack providers may solve? (Greg concerns of > available > > tools/design framework) Will be Feasible or agree in certain > > MSO/management constrains? ( few options below) Is the SNMPv3 group > > addressing this case or had ever think about this as a standard > > mechanism? > > Will that be clearly extended for embedded cases with logical > > interfaces > > instead of physical ones ( to avoid security holes ? > > > > > > Typical case: > > > > "Many" (how many is many?) CMs used to bridge the traffic (SNMP) > > directed to the CM DHCP IP from the CPE through the RF interface > > Upstream. > > > > For blocking traffic: > > These is trivial since MSO is able to place SNMP filters in the > > CMTS/backbone For getting CPE traffic: > > Could be cumbersome in the presence of SNMP filters in the > > gateway or a > > CM unable to register. In the other hand the > > MSO/technician/User, must > > know the CM IP that could be a problem or not desired always. > > > > That one was partially solved with the well known IP 192.168.100.1 > > > > What is still a MSO constrain: > > CMs able to talk to the SNMP stack from any CPE subnet ( > > spoof NMS IP ) > > ( 1 hop) and use the v1, v2c vacmAccess constrains for full access. > > > > Also v3 noAuthNoPriv does not support the subletting as RFC > > 2576 defined > > for coexistence v1 v2c and there is where Rich's case applied for > > granting or blocking access. > > > > If we agree the well know IP is the "only" way to talk to > the CM for a > > CPE with one hop ( CPE to CM DHCP IP queries forwarded > through RF ) we > > are OK and the vacm requirement may not needed, but some > > clarifications > > are needed in the spec. It creates the need to reconfigure > > the user CPE > > any time that a user may need to talk to the CM. > > > > > > With current requirements in either case: > > In the SNMP framework snmpv3 noAuthNoPRiv the access will > be the same > > for MSO and user Access. > > > > With the Interface scheme an MSO will be able to set two > different v3 > > users noAuthNoPriv with different access. > > > > If not the case we still have the issue of blocking NMS > > spoofed Ips) and > > the vacmAccessInterface is a way to block that. Or define the > > ip forward > > mechanism better. > > > > Eduardo > > > > > > > > > > > > -----Original Message----- > > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > > Sent: Tuesday, January 28, 2003 10:43 AM > > To: 'IPCDN WG (E-mail)' > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > Kevin, I think your point is accurate. > > > > Just to expand upon it some... > > > > Typically a CM will get a private IP address via DHCP. This > > results in > > access to the CM through the HFC interface being limited to > within the > > MSO's private IP network. "Outsiders" (e.g. user's on the > > CMCI-side or > > on the Internet) will not be able to access a CM through the HFC > > interface. Access to the CM from the CMCI interface is still > > allowed if > > the proper SNMP access controls are setup. > > > > I want to make sure that this proposed extension to the VACM table > > provides a good benefit over what is acheivable today with the > > mechanisms we already have. > > > > greg > > > > > -----Original Message----- > > > From: Marez Kevin-MGI1375 > > > Sent: Tuesday, January 28, 2003 9:10 AM > > > To: 'Woundy, Richard'; Nakanishi Greg-MGI8179 > > > Cc: IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Rich, > > > > > > I understand the scenario you have presented, however, I > think MSOs > > > would typically use a private networking space for the > RF-side and > > > explicitly prevent access from outside that space. > > > > > > Our concern here is that we are adding an additional level of > > > complexity to the vacmAccess table that doesn't provide a > > great deal > > > of benefit. > > > > > > Greg, please respond I have misstated anything or if you > > have anything > > > > > you'd like to add. Thanks very much, > > > > > > Kevin > > > > > > > > > -----Original Message----- > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > Sent: Wednesday, January 22, 2003 3:59 PM > > > To: 'Marez Kevin-MGI1375' > > > Cc: IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Kevin, > > > > > > Here is my comment on the VACM issue: > > > > > > >10) docsDevVacmAccessExtTable - Is this table really needed > > > when using > > > >SNMPv3? The limited security provided in SNMPv1/2 > > > necessitated having > > > >this functionality in the nmAccessTable. Given SNMPv3 > > security, it > > > >doesn't seem like this functionality is necessary anymore. > > > > > > I would agree that it is better security to authenticate a > > keyed hash > > > via SNMPv3, than to rely on the incoming device interface > > for implied > > > user identification. > > > > > > However, one interesting and important case is a CM diagnostic > > > interface for subscriber-side queries, after the CM registration > > > process is completed. It > > > seems quite useful to allow subscriber tools (with SNMPv3 > > > securityLevel of > > > noAuthNoPriv) to query cable modems over the CMCI (CPE > > > interface) but not > > > over the RFI (RF interface). > > > > > > -- Rich > > > > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipcdn > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipcdn > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 20:32:56 2003 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 UAA13580 for ; Tue, 28 Jan 2003 20:32:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0T1s8W05368 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 20:54:08 -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 h0T1s4J05346; Tue, 28 Jan 2003 20:54:04 -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 h0T1rkJ05315 for ; Tue, 28 Jan 2003 20:53:46 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13570 for ; Tue, 28 Jan 2003 20:32:00 -0500 (EST) Received: from mms01-relayb.tci.com (mms01-relayb.broadband.att.com [147.191.90.1]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h0T1ZTst012404; Tue, 28 Jan 2003 18:35:29 -0700 (MST) Received: from 147.191.89.203 by mms01-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Tue, 28 Jan 2003 18:35:16 -0600 Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 28 Jan 2003 18:35:22 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056635CE@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Eduardo Cardona'" , "Nakanishi Greg-MGI8179" cc: "IPCDN WG (E-mail)" , "DOCSIS OSS Majordomo List" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Date: Tue, 28 Jan 2003 18:35:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1229F05E1083651-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Eduardo, There are at least five available standardized mechanisms to prevent subscriber CPEs from spoofing NMS (or other) IP addresses: 1. The CPE IP address management controls on the CM from the Cable Device MIB, aka docsDevCpe. These controls were made optional by the OSSI because they were difficult to implement and deploy correctly, e.g. it is too easy to capture an autoconfigured IP address as the "current" CPE IP address. 2. The CPE IP address management controls on the CMTS from the Subscriber Management MIB, aka docsSubMgtCpeIpTable. 3. The source IP address filtering controls on the CM from the Cable Device MIB, aka docsDevFilterIpTable. This can be used to prevent subscriber CPEs from spoofing IP addresses at the granularity of IP subnets, but might not be able to prevent spoofing the IP address of another subscriber CPE. 4. The source IP address filtering controls on the CMTS from the Subscriber Management MIB, aka docsSubMgtPktFilterTable. This can be used to prevent subscriber CPEs from spoofing IP addresses at the granularity of IP subnets, but might not be able to prevent spoofing the IP address of another subscriber CPE. 5. The CMTS source address filtering enabled by the DHCP lease query message defined in draft-ietf-dhc-leasequery-04.txt. Probably the most common deployed mechanism today would be #4 or a variant of #4, e.g. CMTS router access control lists. -- Rich -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] Sent: Tuesday, January 28, 2003 8:05 PM To: Nakanishi Greg-MGI8179; Woundy, Richard Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Greg, The IP spaces is fine as soon as the user does not try to spoof an NMS IP (where NmAccess beats SNMP by supporting interfaces for the non authenticated communication) Q1: Does ALL CMs forward (theoretically yes because are bridges) to RFI all ( no ICMP) traffic (including CM DHCP IP) but "diagnostic IP destination? If YES Greg's scenario follows the MSO normal filtering conditions ( i.e UDP/TCP port fitering between subnets) If NO The case I am mentioning is a user spoofing an NMS IP (matches Ip subnet) and contacting the CH DHCP IP and then, the CM processes packet without forwarding it to the network, replying back to the user. To avoid the vacmExt, if the answer is 'NO', I think the below rules may aliviate some problems: Flow type Destination 1) CPE -> CM SNMP "Diagnostic IP" YES 2) CPE -> CM SNMP CM DHCP IP NO -Q1- 3) CPE -> CM ICMP "Diagnostic IP" YES 4) CPE -> CM ICMP CM DHCP IP YES 5) CPE -> CM Other IP both NO ( some cases YES as top services run in CM stack like HTTP) Req 2) seems to be the problem for the Interface requirement. What makes is: Address Q1 in Coexistence v1, v2c V3 noAuthNoPriv if configured, (nothing to do) : same access level both NMS and CPE users ( limited view recommended) Eduardo -----Original Message----- From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] Sent: Tuesday, January 28, 2003 5:22 PM To: 'Woundy, Richard'; Eduardo Cardona Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... That could be one implementation. Another possibility is it could be done through IP forwarding tables. Conceptually, the CMTS HFC interface is connected to two networks - one public and one private. When a packet is received on the public interface (i.e. from the CPE) that is addressed to the private network, the forwarding table would not have a route for it and discards the packet. Although I don't know the CMTS implementation specifics, my understanding is that the described behavior is the way most MSOs operate their network. i.e. CPE cannot communicate with someone else's CM. greg > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Tuesday, January 28, 2003 4:12 PM > To: 'Nakanishi Greg-MGI8179'; 'Eduardo Cardona' > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > You're assuming that the CMTS implements the Subscriber > Management MIB, and > has docsSubMgtPktFilterTable configured to prevent the forwarding of > subscriber CPE traffic to the private net CMs, right? > > -- Rich > > -----Original Message----- > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > Sent: Tuesday, January 28, 2003 7:03 PM > To: Woundy, Richard; 'Eduardo Cardona' > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > I agree that the application of ipFilters to packets > addressed to the CM is > not very clear in the spec. This topic comes up every now > and then on the > reflector. I believe the generally accepted interpretation > is that traffic > addressed to the CM is NOT filtered. > > The workaround that I proposed does not rely on the use of IP > filters. It > just relies on the the partitioning of the private IP network > that the CM is > part of and the public IP network that the CPE is part of. > Typically, the > CMTS will not route between these networks. > > A user can access through SNMP his/her own CM through the > diagnostic IP > address; however, a user cannot access someone elses CM. The > packets from > the user's CPE on the public network will not be routed by > the CMTS to the > private network on which someone else's CM resides. > > greg > > > -----Original Message----- > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > Sent: Tuesday, January 28, 2003 3:27 PM > > To: 'Eduardo Cardona'; Nakanishi Greg-MGI8179 > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > I wonder whether current CM vendors typically check the > > docsDevFilterIpTable > > before they process a locally-addressed SNMP PDU. > > > > Anyone know? > > > > -- Rich > > > > -----Original Message----- > > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > > Sent: Tuesday, January 28, 2003 4:53 PM > > To: Woundy, Richard; Nakanishi Greg-MGI8179 > > Cc: IPCDN WG (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > I forgot to mention something, > > > > 3.3.2.2. SNMPv3 Interface via vacm extension to be removed > > > > Going back to Greg's comments? > > > > Is the filtering flow in 3.3 accurated enough to solve that > > in terms of > > this filter schems? > > > > Seems that SNMP traffic (Section 3.3) is not intuitively > > "forced" to go > > to the ip filters (which after removing vacmExt will be > mere NmAccess > > Mode) before hitting the agent. ( I mean the NmAccess text > > from rfc2669 > > is distracting ?) > > > > I've seen people with different interpretations of how to > "implement" > > the filters based on directed to CM traffic or CM forwarded traffic > > It may create confusion that as the diagram is following > the Stack for > > the RF-CPE or CPE-RF traffic the RF-CM CPE-CM trattic is > not properly > > represented : I add a little box of possible interpretation > > that should > > be clarified. > > > > > > > > ***************** > > * LLC Filter In * > > ***************** > > | > > v > > ******************* > > * Special Filters * > > * | * > > * V * > > * ************ * > > * * IP Spoof * * > > * ************ * > > * | * > > * v * > > > > * *************** * > > * * SNMP Access * * > > * *************** * > > * | * > > ******************* > > | ------> Wrong : SNMP to > > CM traffic > > processing > > v > > **************** > > * IP Filter In * > > **************** > > | -------> Rigth: SNMP to > > CM traffic > > processing > > v > > ***************** > > * IP Filter Out * > > ***************** > > | > > v > > ****************** > > * LLC Filter Out * > > ****************** > > > > -----Original Message----- > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > Sent: Tuesday, January 28, 2003 12:58 PM > > To: Nakanishi Greg-MGI8179; Eduardo Cardona > > Cc: IPCDN WG (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > Eduardo, > > > > I am sympathetic to Greg and Kevin's argument that perhaps the > > docsDevVacmAccessExtTable extension to VACM should be > deleted from the > > Cable Device MIB, for three reasons: > > > > 1. Greg seems to have proposed a workaround for the use case > > I proposed. > > Restating, the DOCSIS configuration file could set up the > > docsDevFilterIpTable to reject UDP/SNMP traffic arriving on > the RF/HFC > > interface from any IP subnets other than the MSOs management station > > subnets. This sounds like reasonable security practice in any case, > > i.e. don't just rely on SNMPv3 authentication. It enables subscriber > > CM management from the CMCI side, but not subscriber/random user > > access from the RF/HFC side, per my use case. 2. I agree it would be > > much easier for vendors if they could leverage standard SNMP agent > > stack implementations as much as possible. The extension for > > DOCSIS-only devices makes this objective more difficult. 3. There is > > also a possibility that the IETF MIB doctor might frown on a > DOCSIS-specific > > extension to the VACM MIB. > > > > Does anyone disagree? Shall I make this deletion? > > > > Are there any other comments on the current Cable Device MIB > > -- which is > > now posted on the IETF reflector, > > > bv2-04.txt > > >? > > > > -- Rich > > > > -----Original Message----- > > From: Eduardo Cardona [mailto:e.cardona@cablelabs.com] > > Sent: Tuesday, January 28, 2003 1:51 PM > > To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > Kevin, Greg, > > > > Following your thoughts. I think I got more findings that need to be > > addressed in any case. The vacmAccess Interface requirements is > > being as a > proposal since the > > early versions of this draft. > > > > We know your concerns and they are also related to different > > discussion > > in the reflector (i.e. controlling the number of > traps/notification by > > touching the Notification Originator subsystem in the SNMP entity ) > > > > In this case the difficulty is to modify the Access Control > > Subsystem in > > the SNMP entity, to being able to add the interface scheme, which is > > perfectly valid under RFC2571/3411 architecture and AUGMENT > clause in > > RFC2578 > > > > > > We need more thoughs in the SNMP constrains we are trying to achieve > > with the full coverage of MSO needs. > > > > The need is there: > > > > what the SNMP stack providers may solve? (Greg concerns of > available > > tools/design framework) Will be Feasible or agree in certain > > MSO/management constrains? ( few options below) Is the SNMPv3 group > > addressing this case or had ever think about this as a standard > > mechanism? Will that be clearly extended for embedded cases with > > logical interfaces > > instead of physical ones ( to avoid security holes ? > > > > > > Typical case: > > > > "Many" (how many is many?) CMs used to bridge the traffic (SNMP) > > directed to the CM DHCP IP from the CPE through the RF interface > > Upstream. > > > > For blocking traffic: > > These is trivial since MSO is able to place SNMP filters in the > > CMTS/backbone For getting CPE traffic: > > Could be cumbersome in the presence of SNMP filters in the > > gateway or a > > CM unable to register. In the other hand the > > MSO/technician/User, must > > know the CM IP that could be a problem or not desired always. > > > > That one was partially solved with the well known IP 192.168.100.1 > > > > What is still a MSO constrain: > > CMs able to talk to the SNMP stack from any CPE subnet ( > > spoof NMS IP ) > > ( 1 hop) and use the v1, v2c vacmAccess constrains for full access. > > > > Also v3 noAuthNoPriv does not support the subletting as RFC > > 2576 defined > > for coexistence v1 v2c and there is where Rich's case applied for > > granting or blocking access. > > > > If we agree the well know IP is the "only" way to talk to > the CM for a > > CPE with one hop ( CPE to CM DHCP IP queries forwarded > through RF ) we > > are OK and the vacm requirement may not needed, but some > > clarifications > > are needed in the spec. It creates the need to reconfigure > > the user CPE > > any time that a user may need to talk to the CM. > > > > > > With current requirements in either case: > > In the SNMP framework snmpv3 noAuthNoPRiv the access will > be the same > > for MSO and user Access. > > > > With the Interface scheme an MSO will be able to set two > different v3 > > users noAuthNoPriv with different access. > > > > If not the case we still have the issue of blocking NMS > > spoofed Ips) and > > the vacmAccessInterface is a way to block that. Or define the > > ip forward > > mechanism better. > > > > Eduardo > > > > > > > > > > > > -----Original Message----- > > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > > Sent: Tuesday, January 28, 2003 10:43 AM > > To: 'IPCDN WG (E-mail)' > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > Kevin, I think your point is accurate. > > > > Just to expand upon it some... > > > > Typically a CM will get a private IP address via DHCP. This > > results in > > access to the CM through the HFC interface being limited to > within the > > MSO's private IP network. "Outsiders" (e.g. user's on the > > CMCI-side or > > on the Internet) will not be able to access a CM through the HFC > > interface. Access to the CM from the CMCI interface is still > > allowed if > > the proper SNMP access controls are setup. > > > > I want to make sure that this proposed extension to the VACM table > > provides a good benefit over what is acheivable today with the > > mechanisms we already have. > > > > greg > > > > > -----Original Message----- > > > From: Marez Kevin-MGI1375 > > > Sent: Tuesday, January 28, 2003 9:10 AM > > > To: 'Woundy, Richard'; Nakanishi Greg-MGI8179 > > > Cc: IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Rich, > > > > > > I understand the scenario you have presented, however, I > think MSOs > > > would typically use a private networking space for the > RF-side and > > > explicitly prevent access from outside that space. > > > > > > Our concern here is that we are adding an additional level of > > > complexity to the vacmAccess table that doesn't provide a > > great deal > > > of benefit. > > > > > > Greg, please respond I have misstated anything or if you > > have anything > > > > > you'd like to add. Thanks very much, > > > > > > Kevin > > > > > > > > > -----Original Message----- > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > Sent: Wednesday, January 22, 2003 3:59 PM > > > To: 'Marez Kevin-MGI1375' > > > Cc: IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Kevin, > > > > > > Here is my comment on the VACM issue: > > > > > > >10) docsDevVacmAccessExtTable - Is this table really needed > > > when using > > > >SNMPv3? The limited security provided in SNMPv1/2 > > > necessitated having > > > >this functionality in the nmAccessTable. Given SNMPv3 > > security, it > > > >doesn't seem like this functionality is necessary anymore. > > > > > > I would agree that it is better security to authenticate a > > keyed hash > > > via SNMPv3, than to rely on the incoming device interface > > for implied > > > user identification. > > > > > > However, one interesting and important case is a CM diagnostic > > > interface for subscriber-side queries, after the CM registration > > > process is completed. It > > > seems quite useful to allow subscriber tools (with SNMPv3 > > > securityLevel of > > > noAuthNoPriv) to query cable modems over the CMCI (CPE > > > interface) but not > > > over the RFI (RF interface). > > > > > > -- Rich > > > > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipcdn > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipcdn > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Jan 28 20:32:57 2003 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 UAA13593 for ; Tue, 28 Jan 2003 20:32:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0T1s9705381 for ipcdn-archive@odin.ietf.org; Tue, 28 Jan 2003 20:54:09 -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 h0T1s7J05361; Tue, 28 Jan 2003 20:54:07 -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 h0T1s0J05330 for ; Tue, 28 Jan 2003 20:54:00 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13573 for ; Tue, 28 Jan 2003 20:32:15 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h0T1Zl2I027042 for ; Tue, 28 Jan 2003 18:35:47 -0700 (MST) Received: [from ca25exm01.GI.COM (ca25exm01.gi.com [168.84.84.121]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id SAA05939 for ; Tue, 28 Jan 2003 18:35:46 -0700 (MST)] Received: by ca25exm01 with Internet Mail Service (5.5.2656.59) id ; Tue, 28 Jan 2003 17:35:46 -0800 Message-ID: From: Nakanishi Greg-MGI8179 To: "'Eduardo Cardona'" , "Woundy, Richard" Cc: "IPCDN WG (E-mail)" , DOCSIS OSS Majordomo List Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Date: Tue, 28 Jan 2003 17:35:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Eduardo, The original use case given was the ability for the CPE to access it's own CM via SNMP, but not be able to access someone else's CM through the RF interface. I'm assuming it OK for MSO staff to access the CM. Allowing access to local CM -- To allow the CPE to access it's own CM, all that is required is a VACM entry with noAuthnoPriv to allow access to a restricted set of MIB objects. In this case, from a security point of view, it shouldn't matter which IP address the SNMP request is sent to. The VACM table will determine if access is allowed regardless of the IP address used. Preventing access to someone else's CM -- This is supported by restricting the routing of packets between the public and private networks. As we've been discussing, it appears there are a few methods in which this can be done. MSO staff to access the CM -- If the SNMP request is generated from within the private network (e.g. MSO's NMS)then the access to the CM will be determined by the VACM table. Does this address your concern? greg > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: Tuesday, January 28, 2003 5:05 PM > To: Nakanishi Greg-MGI8179; Woundy, Richard > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Greg, > > The IP spaces is fine as soon as the user does not try to spoof an NMS > IP (where NmAccess beats SNMP by supporting interfaces for the non > authenticated communication) > > Q1: > Does ALL CMs forward (theoretically yes because are bridges) > to RFI all > ( no ICMP) traffic (including CM DHCP IP) but "diagnostic IP > destination? > > If YES Greg's scenario follows the MSO normal filtering > conditions ( i.e > UDP/TCP port fitering between subnets) > > If NO > > The case I am mentioning is a user spoofing an NMS IP (matches Ip > subnet) and contacting the CH DHCP IP and then, the CM > processes packet > without forwarding it to the network, replying back to the user. > > To avoid the vacmExt, if the answer is 'NO', I think the > below rules may > aliviate some problems: > > Flow type Destination > 1) CPE -> CM SNMP "Diagnostic IP" YES > 2) CPE -> CM SNMP CM DHCP IP NO -Q1- > 3) CPE -> CM ICMP "Diagnostic IP" YES > 4) CPE -> CM ICMP CM DHCP IP YES > 5) CPE -> CM Other IP both NO ( some cases YES as > top services run in CM stack like HTTP) > > Req 2) seems to be the problem for the Interface requirement. > What makes is: > Address Q1 in Coexistence v1, v2c > V3 noAuthNoPriv if configured, (nothing to do) : same access > level both > NMS and CPE users ( limited view recommended) > > Eduardo > > -----Original Message----- > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > Sent: Tuesday, January 28, 2003 5:22 PM > To: 'Woundy, Richard'; Eduardo Cardona > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > That could be one implementation. > > Another possibility is it could be done through IP forwarding tables. > Conceptually, the CMTS HFC interface is connected to two > networks - one > public and one private. When a packet is received on the public > interface (i.e. from the CPE) that is addressed to the > private network, > the forwarding table would not have a route for it and discards the > packet. > > Although I don't know the CMTS implementation specifics, my > understanding is that the described behavior is the way most MSOs > operate their network. i.e. CPE cannot communicate with > someone else's > CM. > > greg > > > -----Original Message----- > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > Sent: Tuesday, January 28, 2003 4:12 PM > > To: 'Nakanishi Greg-MGI8179'; 'Eduardo Cardona' > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > You're assuming that the CMTS implements the Subscriber > > Management MIB, and > > has docsSubMgtPktFilterTable configured to prevent the forwarding of > > subscriber CPE traffic to the private net CMs, right? > > > > -- Rich > > > > -----Original Message----- > > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > > Sent: Tuesday, January 28, 2003 7:03 PM > > To: Woundy, Richard; 'Eduardo Cardona' > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > I agree that the application of ipFilters to packets > > addressed to the CM is > > not very clear in the spec. This topic comes up every now > > and then on the > > reflector. I believe the generally accepted interpretation > > is that traffic > > addressed to the CM is NOT filtered. > > > > The workaround that I proposed does not rely on the use of IP > > filters. It > > just relies on the the partitioning of the private IP network > > that the CM is > > part of and the public IP network that the CPE is part of. > > Typically, the > > CMTS will not route between these networks. > > > > A user can access through SNMP his/her own CM through the > > diagnostic IP > > address; however, a user cannot access someone elses CM. The > > packets from > > the user's CPE on the public network will not be routed by > > the CMTS to the > > private network on which someone else's CM resides. > > > > greg > > > > > -----Original Message----- > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > Sent: Tuesday, January 28, 2003 3:27 PM > > > To: 'Eduardo Cardona'; Nakanishi Greg-MGI8179 > > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > I wonder whether current CM vendors typically check the > > > docsDevFilterIpTable > > > before they process a locally-addressed SNMP PDU. > > > > > > Anyone know? > > > > > > -- Rich > > > > > > -----Original Message----- > > > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > > > Sent: Tuesday, January 28, 2003 4:53 PM > > > To: Woundy, Richard; Nakanishi Greg-MGI8179 > > > Cc: IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > I forgot to mention something, > > > > > > 3.3.2.2. SNMPv3 Interface via vacm extension to be removed > > > > > > Going back to Greg's comments? > > > > > > Is the filtering flow in 3.3 accurated enough to solve that > > > in terms of > > > this filter schems? > > > > > > Seems that SNMP traffic (Section 3.3) is not intuitively > > > "forced" to go > > > to the ip filters (which after removing vacmExt will be > > mere NmAccess > > > Mode) before hitting the agent. ( I mean the NmAccess text > > > from rfc2669 > > > is distracting ?) > > > > > > I've seen people with different interpretations of how to > > "implement" > > > the filters based on directed to CM traffic or CM > forwarded traffic > > > It may create confusion that as the diagram is following > > the Stack for > > > the RF-CPE or CPE-RF traffic the RF-CM CPE-CM trattic is > > not properly > > > represented : I add a little box of possible interpretation > > > that should > > > be clarified. > > > > > > > > > > > > ***************** > > > * LLC Filter In * > > > ***************** > > > | > > > v > > > ******************* > > > * Special Filters * > > > * | * > > > * V * > > > * ************ * > > > * * IP Spoof * * > > > * ************ * > > > * | * > > > * v * > > > > > > * *************** * > > > * * SNMP Access * * > > > * *************** * > > > * | * > > > ******************* > > > | ------> Wrong : SNMP to > > > CM traffic > > > processing > > > v > > > **************** > > > * IP Filter In * > > > **************** > > > | -------> Rigth: SNMP to > > > CM traffic > > > processing > > > v > > > ***************** > > > * IP Filter Out * > > > ***************** > > > | > > > v > > > ****************** > > > * LLC Filter Out * > > > ****************** > > > > > > -----Original Message----- > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > Sent: Tuesday, January 28, 2003 12:58 PM > > > To: Nakanishi Greg-MGI8179; Eduardo Cardona > > > Cc: IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Eduardo, > > > > > > I am sympathetic to Greg and Kevin's argument that perhaps the > > > docsDevVacmAccessExtTable extension to VACM should be > > deleted from the > > > Cable Device MIB, for three reasons: > > > > > > 1. Greg seems to have proposed a workaround for the use case > > > I proposed. > > > Restating, the DOCSIS configuration file could set up the > > > docsDevFilterIpTable to reject UDP/SNMP traffic arriving on > > the RF/HFC > > > interface from any IP subnets other than the MSOs > management station > > > > subnets. This sounds like reasonable security practice in > any case, > > > i.e. don't just rely on SNMPv3 authentication. It enables > subscriber > > > > CM management from the CMCI side, but not subscriber/random user > > > access from the RF/HFC side, per my use case. 2. I agree > it would be > > > > much easier for vendors if they could leverage standard > SNMP agent > > > stack implementations as much as possible. The extension for > > > DOCSIS-only devices makes this objective more difficult. > 3. There is > > > > also a possibility that the IETF MIB doctor might frown on a > > DOCSIS-specific > > > extension to the VACM MIB. > > > > > > Does anyone disagree? Shall I make this deletion? > > > > > > Are there any other comments on the current Cable Device MIB > > > -- which is > > > now posted on the IETF reflector, > > > > > bv2-04.txt > > > >? > > > > > > -- Rich > > > > > > -----Original Message----- > > > From: Eduardo Cardona [mailto:e.cardona@cablelabs.com] > > > Sent: Tuesday, January 28, 2003 1:51 PM > > > To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Kevin, Greg, > > > > > > Following your thoughts. I think I got more findings that > need to be > > > > addressed in any case. The vacmAccess Interface requirements is > > > being as a > > proposal since the > > > early versions of this draft. > > > > > > We know your concerns and they are also related to different > > > discussion > > > in the reflector (i.e. controlling the number of > > traps/notification by > > > touching the Notification Originator subsystem in the > SNMP entity ) > > > > > > In this case the difficulty is to modify the Access Control > > > Subsystem in > > > the SNMP entity, to being able to add the interface > scheme, which is > > > perfectly valid under RFC2571/3411 architecture and AUGMENT > > clause in > > > RFC2578 > > > > > > > > > We need more thoughs in the SNMP constrains we are trying > to achieve > > > > with the full coverage of MSO needs. > > > > > > The need is there: > > > > > > what the SNMP stack providers may solve? (Greg concerns of > > available > > > tools/design framework) Will be Feasible or agree in certain > > > MSO/management constrains? ( few options below) Is the > SNMPv3 group > > > > addressing this case or had ever think about this as a standard > > > mechanism? Will that be clearly extended for embedded cases with > > > logical interfaces > > > instead of physical ones ( to avoid security holes ? > > > > > > > > > Typical case: > > > > > > "Many" (how many is many?) CMs used to bridge the traffic (SNMP) > > > directed to the CM DHCP IP from the CPE through the RF interface > > > Upstream. > > > > > > For blocking traffic: > > > These is trivial since MSO is able to place SNMP filters in the > > > CMTS/backbone For getting CPE traffic: > > > Could be cumbersome in the presence of SNMP filters in the > > > gateway or a > > > CM unable to register. In the other hand the > > > MSO/technician/User, must > > > know the CM IP that could be a problem or not desired always. > > > > > > That one was partially solved with the well known IP 192.168.100.1 > > > > > > What is still a MSO constrain: > > > CMs able to talk to the SNMP stack from any CPE subnet ( > > > spoof NMS IP ) > > > ( 1 hop) and use the v1, v2c vacmAccess constrains for > full access. > > > > > > Also v3 noAuthNoPriv does not support the subletting as RFC > > > 2576 defined > > > for coexistence v1 v2c and there is where Rich's case applied for > > > granting or blocking access. > > > > > > If we agree the well know IP is the "only" way to talk to > > the CM for a > > > CPE with one hop ( CPE to CM DHCP IP queries forwarded > > through RF ) we > > > are OK and the vacm requirement may not needed, but some > > > clarifications > > > are needed in the spec. It creates the need to reconfigure > > > the user CPE > > > any time that a user may need to talk to the CM. > > > > > > > > > With current requirements in either case: > > > In the SNMP framework snmpv3 noAuthNoPRiv the access will > > be the same > > > for MSO and user Access. > > > > > > With the Interface scheme an MSO will be able to set two > > different v3 > > > users noAuthNoPriv with different access. > > > > > > If not the case we still have the issue of blocking NMS > > > spoofed Ips) and > > > the vacmAccessInterface is a way to block that. Or define the > > > ip forward > > > mechanism better. > > > > > > Eduardo > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > > > Sent: Tuesday, January 28, 2003 10:43 AM > > > To: 'IPCDN WG (E-mail)' > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Kevin, I think your point is accurate. > > > > > > Just to expand upon it some... > > > > > > Typically a CM will get a private IP address via DHCP. This > > > results in > > > access to the CM through the HFC interface being limited to > > within the > > > MSO's private IP network. "Outsiders" (e.g. user's on the > > > CMCI-side or > > > on the Internet) will not be able to access a CM through the HFC > > > interface. Access to the CM from the CMCI interface is still > > > allowed if > > > the proper SNMP access controls are setup. > > > > > > I want to make sure that this proposed extension to the > VACM table > > > provides a good benefit over what is acheivable today with the > > > mechanisms we already have. > > > > > > greg > > > > > > > -----Original Message----- > > > > From: Marez Kevin-MGI1375 > > > > Sent: Tuesday, January 28, 2003 9:10 AM > > > > To: 'Woundy, Richard'; Nakanishi Greg-MGI8179 > > > > Cc: IPCDN WG (E-mail) > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > > > > Rich, > > > > > > > > I understand the scenario you have presented, however, I > > think MSOs > > > > would typically use a private networking space for the > > RF-side and > > > > explicitly prevent access from outside that space. > > > > > > > > Our concern here is that we are adding an additional level of > > > > complexity to the vacmAccess table that doesn't provide a > > > great deal > > > > of benefit. > > > > > > > > Greg, please respond I have misstated anything or if you > > > have anything > > > > > > > you'd like to add. Thanks very much, > > > > > > > > Kevin > > > > > > > > > > > > -----Original Message----- > > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > > Sent: Wednesday, January 22, 2003 3:59 PM > > > > To: 'Marez Kevin-MGI1375' > > > > Cc: IPCDN WG (E-mail) > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > > > > Kevin, > > > > > > > > Here is my comment on the VACM issue: > > > > > > > > >10) docsDevVacmAccessExtTable - Is this table really needed > > > > when using > > > > >SNMPv3? The limited security provided in SNMPv1/2 > > > > necessitated having > > > > >this functionality in the nmAccessTable. Given SNMPv3 > > > security, it > > > > >doesn't seem like this functionality is necessary anymore. > > > > > > > > I would agree that it is better security to authenticate a > > > keyed hash > > > > via SNMPv3, than to rely on the incoming device interface > > > for implied > > > > user identification. > > > > > > > > However, one interesting and important case is a CM diagnostic > > > > interface for subscriber-side queries, after the CM > registration > > > > process is completed. It > > > > seems quite useful to allow subscriber tools (with SNMPv3 > > > > securityLevel of > > > > noAuthNoPriv) to query cable modems over the CMCI (CPE > > > > interface) but not > > > > over the RFI (RF interface). > > > > > > > > -- Rich > > > > > > > _______________________________________________ > > > IPCDN mailing list > > > IPCDN@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ipcdn > > > _______________________________________________ > > > IPCDN mailing list > > > IPCDN@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Jan 29 08:59:45 2003 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 IAA19623 for ; Wed, 29 Jan 2003 08:59:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TELDv28165 for ipcdn-archive@odin.ietf.org; Wed, 29 Jan 2003 09:21:13 -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 h0TELCJ28158; Wed, 29 Jan 2003 09:21:12 -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 h0TEKcJ28116 for ; Wed, 29 Jan 2003 09:20:38 -0500 Received: from scbh01.terayon.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19595 for ; Wed, 29 Jan 2003 08:58:39 -0500 (EST) Received: by SCBH01 with Internet Mail Service (5.5.2655.55) id ; Wed, 29 Jan 2003 06:02:08 -0800 Message-ID: From: "Raftus, David" To: "'Woundy, Richard'" , "Raftus, David" Cc: "IPCDN WG (E-mail)" Date: Wed, 29 Jan 2003 05:59:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] RE: SMICng warnings from draft-ietf-ipcdn-docs-rfmibv2-05.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi Rich, Thanks. I'll check them out. Dave ************************************ David Raftus Imedia Semiconductor 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 david.raftus@imedia.com 613.592.1052 ext 222 ************************************ -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Tuesday, January 28, 2003 7:27 PM To: David Raftus (E-mail) Cc: IPCDN WG (E-mail) Subject: SMICng warnings from draft-ietf-ipcdn-docs-rfmibv2-05.txt David, I generated the following SMICng warning message in compiling : W: f(DOCS-IF-MIB.mi2), (1005,21) Item "docsIfSigQEqualizationData" should have SIZE specified W: f(DOCS-IF-MIB.mi2), (1246,21) Item "docsIfCmStatusCode" should have SIZE specified W: f(DOCS-IF-MIB.mi2), (1413,21) Item "docsIfCmStatusEqualizationData" should have SIZE specified W: f(DOCS-IF-MIB.mi2), (1962,21) Item "docsIfCmtsCmStatusEqualizationData" should have SIZE specified W: f(DOCS-IF-MIB.mi2), (2882,1) Item "docsIfCmtsDownChnlCtrId" is not contained in any group defined in the current module W: f(DOCS-IF-MIB.mi2), (3013,1) Item "docsIfCmtsUpChnlCtrId" is not contained in any group defined in the current module W: f(DOCS-IF-MIB.mi2), (3657,9) Duplicate item "docsIfQosProfPriority" in compliances list for module "DOCS-IF-MIB" Let me know if you need any assistance in fixing the warnings above. I also found but am ignoring these two warning messages: W: f(DOCS-IF-MIB.mi2), (3932,1) OBJECT-GROUP "docsIfObsoleteGroup" is not used in a MODULE-COMPLIANCE in current module W: f(DOCS-IF-MIB.mi2), (3942,1) OBJECT-GROUP "docsIfDeprecatedGroup" is not used in a MODULE-COMPLIANCE in current module -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Jan 29 08:59:46 2003 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 IAA19630 for ; Wed, 29 Jan 2003 08:59:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TELDH28179 for ipcdn-archive@odin.ietf.org; Wed, 29 Jan 2003 09:21:13 -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 h0TELBJ28139; Wed, 29 Jan 2003 09:21:11 -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 h0TEKEJ28085 for ; Wed, 29 Jan 2003 09:20:14 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19586 for ; Wed, 29 Jan 2003 08:58:12 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id h0TE1ewH004200; Wed, 29 Jan 2003 07:01:41 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 29 Jan 2003 07:01:40 -0700 Message-ID: Thread-Topic: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Thread-Index: AcLHNsHZfxM4qCc8R7OjpXnbTvjjjQAZAh+A From: "Eduardo Cardona" To: "Nakanishi Greg-MGI8179" , "Woundy, Richard" Cc: "IPCDN WG (E-mail)" , "DOCSIS OSS Majordomo List" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0TEKEJ28086 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Greg, Rich, Sorry if I wasn't clear. I am fine with all the comments about spoofing and subnets isolation mechanisms. The case I am presenting ( not spoofing other CM's Ips) It is the case of a user spoofing an NMS IP address with the solely purpose of getting access to the SNMP entity of its own CM ( not traffic intervention in the RF), ( simulating the NMS network in the CPE side), then the subnet Mask mechanism for Coesistence v1 v2c may failed in the case of a CM that reply to SNMP request from CPEs ( CM believes that the request is from a valid subnet, user still needs to guess the comminity string) In the case of v3 noAuthNoPriv as soon as is defined such view it becomes a CPE user view ( no interface/subnet filtering). MSO can't have an username for CPE and think in another user ( more privileges/access) for exclusive MSO administration. The point I am trying to get into is as more routing/ip aware stuff is placed in the CMs: Just guessing: A common behavior of a CPE SNMP request directed to CM DHCP IP is forwarding to RF US and bounce back to CM side due the bridge nature of the implementation. That may stop happening since some CMs failed to filter SNMP traffic based on interfaces since the CPE traffic appear as RF traffic ( bounded back) What some inmplementations may did was to start listening to SNMP to CM DHCP IP and apply the NmAccess interface filter, If that's the case a CM will recognize a CM IP in -----Original Message----- From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] Sent: Tuesday, January 28, 2003 6:36 PM To: Eduardo Cardona; Woundy, Richard Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Eduardo, The original use case given was the ability for the CPE to access it's own CM via SNMP, but not be able to access someone else's CM through the RF interface. I'm assuming it OK for MSO staff to access the CM. Allowing access to local CM -- To allow the CPE to access it's own CM, all that is required is a VACM entry with noAuthnoPriv to allow access to a restricted set of MIB objects. In this case, from a security point of view, it shouldn't matter which IP address the SNMP request is sent to. The VACM table will determine if access is allowed regardless of the IP address used. Preventing access to someone else's CM -- This is supported by restricting the routing of packets between the public and private networks. As we've been discussing, it appears there are a few methods in which this can be done. MSO staff to access the CM -- If the SNMP request is generated from within the private network (e.g. MSO's NMS)then the access to the CM will be determined by the VACM table. Does this address your concern? greg > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: Tuesday, January 28, 2003 5:05 PM > To: Nakanishi Greg-MGI8179; Woundy, Richard > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Greg, > > The IP spaces is fine as soon as the user does not try to spoof an NMS > IP (where NmAccess beats SNMP by supporting interfaces for the non > authenticated communication) > > Q1: > Does ALL CMs forward (theoretically yes because are bridges) > to RFI all > ( no ICMP) traffic (including CM DHCP IP) but "diagnostic IP > destination? > > If YES Greg's scenario follows the MSO normal filtering > conditions ( i.e > UDP/TCP port fitering between subnets) > > If NO > > The case I am mentioning is a user spoofing an NMS IP (matches Ip > subnet) and contacting the CH DHCP IP and then, the CM > processes packet > without forwarding it to the network, replying back to the user. > > To avoid the vacmExt, if the answer is 'NO', I think the > below rules may > aliviate some problems: > > Flow type Destination > 1) CPE -> CM SNMP "Diagnostic IP" YES > 2) CPE -> CM SNMP CM DHCP IP NO -Q1- > 3) CPE -> CM ICMP "Diagnostic IP" YES > 4) CPE -> CM ICMP CM DHCP IP YES > 5) CPE -> CM Other IP both NO ( some cases YES as > top services run in CM stack like HTTP) > > Req 2) seems to be the problem for the Interface requirement. What > makes is: > Address Q1 in Coexistence v1, v2c > V3 noAuthNoPriv if configured, (nothing to do) : same access > level both > NMS and CPE users ( limited view recommended) > > Eduardo > > -----Original Message----- > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > Sent: Tuesday, January 28, 2003 5:22 PM > To: 'Woundy, Richard'; Eduardo Cardona > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > That could be one implementation. > > Another possibility is it could be done through IP forwarding tables. > Conceptually, the CMTS HFC interface is connected to two networks - > one public and one private. When a packet is received on the public > interface (i.e. from the CPE) that is addressed to the > private network, > the forwarding table would not have a route for it and discards the > packet. > > Although I don't know the CMTS implementation specifics, my > understanding is that the described behavior is the way most MSOs > operate their network. i.e. CPE cannot communicate with someone > else's CM. > > greg > > > -----Original Message----- > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > Sent: Tuesday, January 28, 2003 4:12 PM > > To: 'Nakanishi Greg-MGI8179'; 'Eduardo Cardona' > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > You're assuming that the CMTS implements the Subscriber Management > > MIB, and has docsSubMgtPktFilterTable configured to prevent the > > forwarding of subscriber CPE traffic to the private net CMs, right? > > > > -- Rich > > > > -----Original Message----- > > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > > Sent: Tuesday, January 28, 2003 7:03 PM > > To: Woundy, Richard; 'Eduardo Cardona' > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > I agree that the application of ipFilters to packets addressed to > > the CM is not very clear in the spec. This topic comes up every now > > and then on the > > reflector. I believe the generally accepted interpretation > > is that traffic > > addressed to the CM is NOT filtered. > > > > The workaround that I proposed does not rely on the use of IP > > filters. It just relies on the the partitioning of the private IP > > network that the CM is > > part of and the public IP network that the CPE is part of. > > Typically, the > > CMTS will not route between these networks. > > > > A user can access through SNMP his/her own CM through the diagnostic > > IP address; however, a user cannot access someone elses CM. The > > packets from > > the user's CPE on the public network will not be routed by > > the CMTS to the > > private network on which someone else's CM resides. > > > > greg > > > > > -----Original Message----- > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > Sent: Tuesday, January 28, 2003 3:27 PM > > > To: 'Eduardo Cardona'; Nakanishi Greg-MGI8179 > > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > I wonder whether current CM vendors typically check the > > > docsDevFilterIpTable before they process a locally-addressed SNMP > > > PDU. > > > > > > Anyone know? > > > > > > -- Rich > > > > > > -----Original Message----- > > > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > > > Sent: Tuesday, January 28, 2003 4:53 PM > > > To: Woundy, Richard; Nakanishi Greg-MGI8179 > > > Cc: IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > I forgot to mention something, > > > > > > 3.3.2.2. SNMPv3 Interface via vacm extension to be removed > > > > > > Going back to Greg's comments? > > > > > > Is the filtering flow in 3.3 accurated enough to solve that in > > > terms of this filter schems? > > > > > > Seems that SNMP traffic (Section 3.3) is not intuitively "forced" > > > to go to the ip filters (which after removing vacmExt will be > > mere NmAccess > > > Mode) before hitting the agent. ( I mean the NmAccess text from > > > rfc2669 is distracting ?) > > > > > > I've seen people with different interpretations of how to > > "implement" > > > the filters based on directed to CM traffic or CM > forwarded traffic > > > It may create confusion that as the diagram is following > > the Stack for > > > the RF-CPE or CPE-RF traffic the RF-CM CPE-CM trattic is > > not properly > > > represented : I add a little box of possible interpretation that > > > should be clarified. > > > > > > > > > > > > ***************** > > > * LLC Filter In * > > > ***************** > > > | > > > v > > > ******************* > > > * Special Filters * > > > * | * > > > * V * > > > * ************ * > > > * * IP Spoof * * > > > * ************ * > > > * | * > > > * v * > > > > > > * *************** * > > > * * SNMP Access * * > > > * *************** * > > > * | * > > > ******************* > > > | ------> Wrong : SNMP to > > > CM traffic > > > processing > > > v > > > **************** > > > * IP Filter In * > > > **************** > > > | -------> Rigth: SNMP to > > > CM traffic > > > processing > > > v > > > ***************** > > > * IP Filter Out * > > > ***************** > > > | > > > v > > > ****************** > > > * LLC Filter Out * > > > ****************** > > > > > > -----Original Message----- > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > Sent: Tuesday, January 28, 2003 12:58 PM > > > To: Nakanishi Greg-MGI8179; Eduardo Cardona > > > Cc: IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Eduardo, > > > > > > I am sympathetic to Greg and Kevin's argument that perhaps the > > > docsDevVacmAccessExtTable extension to VACM should be > > deleted from the > > > Cable Device MIB, for three reasons: > > > > > > 1. Greg seems to have proposed a workaround for the use case I > > > proposed. Restating, the DOCSIS configuration file could set up > > > the docsDevFilterIpTable to reject UDP/SNMP traffic arriving on > > the RF/HFC > > > interface from any IP subnets other than the MSOs > management station > > > > subnets. This sounds like reasonable security practice in > any case, > > > i.e. don't just rely on SNMPv3 authentication. It enables > subscriber > > > > CM management from the CMCI side, but not subscriber/random user > > > access from the RF/HFC side, per my use case. 2. I agree > it would be > > > > much easier for vendors if they could leverage standard > SNMP agent > > > stack implementations as much as possible. The extension for > > > DOCSIS-only devices makes this objective more difficult. > 3. There is > > > > also a possibility that the IETF MIB doctor might frown on a > > DOCSIS-specific > > > extension to the VACM MIB. > > > > > > Does anyone disagree? Shall I make this deletion? > > > > > > Are there any other comments on the current Cable Device MIB > > > -- which is > > > now posted on the IETF reflector, > > > > > bv2-04.txt > > > >? > > > > > > -- Rich > > > > > > -----Original Message----- > > > From: Eduardo Cardona [mailto:e.cardona@cablelabs.com] > > > Sent: Tuesday, January 28, 2003 1:51 PM > > > To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Kevin, Greg, > > > > > > Following your thoughts. I think I got more findings that > need to be > > > > addressed in any case. The vacmAccess Interface requirements is > > > being as a > > proposal since the > > > early versions of this draft. > > > > > > We know your concerns and they are also related to different > > > discussion in the reflector (i.e. controlling the number of > > traps/notification by > > > touching the Notification Originator subsystem in the > SNMP entity ) > > > > > > In this case the difficulty is to modify the Access Control > > > Subsystem in the SNMP entity, to being able to add the interface > scheme, which is > > > perfectly valid under RFC2571/3411 architecture and AUGMENT > > clause in > > > RFC2578 > > > > > > > > > We need more thoughs in the SNMP constrains we are trying > to achieve > > > > with the full coverage of MSO needs. > > > > > > The need is there: > > > > > > what the SNMP stack providers may solve? (Greg concerns of > > available > > > tools/design framework) Will be Feasible or agree in certain > > > MSO/management constrains? ( few options below) Is the > SNMPv3 group > > > > addressing this case or had ever think about this as a standard > > > mechanism? Will that be clearly extended for embedded cases with > > > logical interfaces > > > instead of physical ones ( to avoid security holes ? > > > > > > > > > Typical case: > > > > > > "Many" (how many is many?) CMs used to bridge the traffic (SNMP) > > > directed to the CM DHCP IP from the CPE through the RF interface > > > Upstream. > > > > > > For blocking traffic: > > > These is trivial since MSO is able to place SNMP filters in the > > > CMTS/backbone For getting CPE traffic: Could be cumbersome in the > > > presence of SNMP filters in the gateway or a > > > CM unable to register. In the other hand the > > > MSO/technician/User, must > > > know the CM IP that could be a problem or not desired always. > > > > > > That one was partially solved with the well known IP 192.168.100.1 > > > > > > What is still a MSO constrain: > > > CMs able to talk to the SNMP stack from any CPE subnet ( spoof NMS > > > IP ) ( 1 hop) and use the v1, v2c vacmAccess constrains for > full access. > > > > > > Also v3 noAuthNoPriv does not support the subletting as RFC 2576 > > > defined for coexistence v1 v2c and there is where Rich's case > > > applied for granting or blocking access. > > > > > > If we agree the well know IP is the "only" way to talk to > > the CM for a > > > CPE with one hop ( CPE to CM DHCP IP queries forwarded > > through RF ) we > > > are OK and the vacm requirement may not needed, but some > > > clarifications are needed in the spec. It creates the need to > > > reconfigure the user CPE > > > any time that a user may need to talk to the CM. > > > > > > > > > With current requirements in either case: > > > In the SNMP framework snmpv3 noAuthNoPRiv the access will > > be the same > > > for MSO and user Access. > > > > > > With the Interface scheme an MSO will be able to set two > > different v3 > > > users noAuthNoPriv with different access. > > > > > > If not the case we still have the issue of blocking NMS spoofed > > > Ips) and the vacmAccessInterface is a way to block that. Or define > > > the ip forward > > > mechanism better. > > > > > > Eduardo > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > > > Sent: Tuesday, January 28, 2003 10:43 AM > > > To: 'IPCDN WG (E-mail)' > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Kevin, I think your point is accurate. > > > > > > Just to expand upon it some... > > > > > > Typically a CM will get a private IP address via DHCP. This > > > results in access to the CM through the HFC interface being > > > limited to > > within the > > > MSO's private IP network. "Outsiders" (e.g. user's on the > > > CMCI-side or on the Internet) will not be able to access a CM > > > through the HFC interface. Access to the CM from the CMCI > > > interface is still allowed if > > > the proper SNMP access controls are setup. > > > > > > I want to make sure that this proposed extension to the > VACM table > > > provides a good benefit over what is acheivable today with the > > > mechanisms we already have. > > > > > > greg > > > > > > > -----Original Message----- > > > > From: Marez Kevin-MGI1375 > > > > Sent: Tuesday, January 28, 2003 9:10 AM > > > > To: 'Woundy, Richard'; Nakanishi Greg-MGI8179 > > > > Cc: IPCDN WG (E-mail) > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > > > > Rich, > > > > > > > > I understand the scenario you have presented, however, I > > think MSOs > > > > would typically use a private networking space for the > > RF-side and > > > > explicitly prevent access from outside that space. > > > > > > > > Our concern here is that we are adding an additional level of > > > > complexity to the vacmAccess table that doesn't provide a > > > great deal > > > > of benefit. > > > > > > > > Greg, please respond I have misstated anything or if you > > > have anything > > > > > > > you'd like to add. Thanks very much, > > > > > > > > Kevin > > > > > > > > > > > > -----Original Message----- > > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > > Sent: Wednesday, January 22, 2003 3:59 PM > > > > To: 'Marez Kevin-MGI1375' > > > > Cc: IPCDN WG (E-mail) > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > > > > Kevin, > > > > > > > > Here is my comment on the VACM issue: > > > > > > > > >10) docsDevVacmAccessExtTable - Is this table really needed > > > > when using > > > > >SNMPv3? The limited security provided in SNMPv1/2 > > > > necessitated having > > > > >this functionality in the nmAccessTable. Given SNMPv3 > > > security, it > > > > >doesn't seem like this functionality is necessary anymore. > > > > > > > > I would agree that it is better security to authenticate a > > > keyed hash > > > > via SNMPv3, than to rely on the incoming device interface > > > for implied > > > > user identification. > > > > > > > > However, one interesting and important case is a CM diagnostic > > > > interface for subscriber-side queries, after the CM > registration > > > > process is completed. It > > > > seems quite useful to allow subscriber tools (with SNMPv3 > > > > securityLevel of > > > > noAuthNoPriv) to query cable modems over the CMCI (CPE > > > > interface) but not > > > > over the RFI (RF interface). > > > > > > > > -- Rich > > > > > > > _______________________________________________ > > > IPCDN mailing list > > > IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn > > > _______________________________________________ > > > IPCDN mailing list > > > IPCDN@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Jan 29 12:35:19 2003 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 MAA24213 for ; Wed, 29 Jan 2003 12:35:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0THuoO10334 for ipcdn-archive@odin.ietf.org; Wed, 29 Jan 2003 12:56:50 -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 h0THuEJ10311; Wed, 29 Jan 2003 12:56:14 -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 h0THtmJ10289 for ; Wed, 29 Jan 2003 12:55:48 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24191 for ; Wed, 29 Jan 2003 12:33:17 -0500 (EST) Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h0THajst010903; Wed, 29 Jan 2003 10:36:45 -0700 (MST) Received: from 147.191.90.11 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Wed, 29 Jan 2003 10:36:41 -0600 Received: by entexchimc04.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 29 Jan 2003 10:36:11 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056635DF@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Eduardo Cardona'" , "Nakanishi Greg-MGI8179" cc: "IPCDN WG (E-mail)" , "DOCSIS OSS Majordomo List" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Date: Wed, 29 Jan 2003 10:36:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1226CEA31136216-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I guess the biggest problem is when we don't use SNMPv3 authentication, and when we don't use the docsDevNmAccessTable (e.g. with docsDevNmAccessInterfaces restricting access from the CMCI) -- e.g. SNMP Coexistence. In the case of SNMP Coexistence, the only thing that stops end-users from operator-level SNMP access is knowledge of the community string, which is probably exposed as a plain-text ASCII string in the DOCSIS config files on the TFTP servers. Am I misinformed? -- Rich -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] Sent: Wednesday, January 29, 2003 9:02 AM To: Nakanishi Greg-MGI8179; Woundy, Richard Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Greg, Rich, Sorry if I wasn't clear. I am fine with all the comments about spoofing and subnets isolation mechanisms. The case I am presenting ( not spoofing other CM's Ips) It is the case of a user spoofing an NMS IP address with the solely purpose of getting access to the SNMP entity of its own CM ( not traffic intervention in the RF), ( simulating the NMS network in the CPE side), then the subnet Mask mechanism for Coesistence v1 v2c may failed in the case of a CM that reply to SNMP request from CPEs ( CM believes that the request is from a valid subnet, user still needs to guess the comminity string) In the case of v3 noAuthNoPriv as soon as is defined such view it becomes a CPE user view ( no interface/subnet filtering). MSO can't have an username for CPE and think in another user ( more privileges/access) for exclusive MSO administration. The point I am trying to get into is as more routing/ip aware stuff is placed in the CMs: Just guessing: A common behavior of a CPE SNMP request directed to CM DHCP IP is forwarding to RF US and bounce back to CM side due the bridge nature of the implementation. That may stop happening since some CMs failed to filter SNMP traffic based on interfaces since the CPE traffic appear as RF traffic ( bounded back) What some inmplementations may did was to start listening to SNMP to CM DHCP IP and apply the NmAccess interface filter, If that's the case a CM will recognize a CM IP in -----Original Message----- From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] Sent: Tuesday, January 28, 2003 6:36 PM To: Eduardo Cardona; Woundy, Richard Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Eduardo, The original use case given was the ability for the CPE to access it's own CM via SNMP, but not be able to access someone else's CM through the RF interface. I'm assuming it OK for MSO staff to access the CM. Allowing access to local CM -- To allow the CPE to access it's own CM, all that is required is a VACM entry with noAuthnoPriv to allow access to a restricted set of MIB objects. In this case, from a security point of view, it shouldn't matter which IP address the SNMP request is sent to. The VACM table will determine if access is allowed regardless of the IP address used. Preventing access to someone else's CM -- This is supported by restricting the routing of packets between the public and private networks. As we've been discussing, it appears there are a few methods in which this can be done. MSO staff to access the CM -- If the SNMP request is generated from within the private network (e.g. MSO's NMS)then the access to the CM will be determined by the VACM table. Does this address your concern? greg > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: Tuesday, January 28, 2003 5:05 PM > To: Nakanishi Greg-MGI8179; Woundy, Richard > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Greg, > > The IP spaces is fine as soon as the user does not try to spoof an NMS > IP (where NmAccess beats SNMP by supporting interfaces for the non > authenticated communication) > > Q1: > Does ALL CMs forward (theoretically yes because are bridges) > to RFI all > ( no ICMP) traffic (including CM DHCP IP) but "diagnostic IP > destination? > > If YES Greg's scenario follows the MSO normal filtering > conditions ( i.e > UDP/TCP port fitering between subnets) > > If NO > > The case I am mentioning is a user spoofing an NMS IP (matches Ip > subnet) and contacting the CH DHCP IP and then, the CM > processes packet > without forwarding it to the network, replying back to the user. > > To avoid the vacmExt, if the answer is 'NO', I think the > below rules may > aliviate some problems: > > Flow type Destination > 1) CPE -> CM SNMP "Diagnostic IP" YES > 2) CPE -> CM SNMP CM DHCP IP NO -Q1- > 3) CPE -> CM ICMP "Diagnostic IP" YES > 4) CPE -> CM ICMP CM DHCP IP YES > 5) CPE -> CM Other IP both NO ( some cases YES as > top services run in CM stack like HTTP) > > Req 2) seems to be the problem for the Interface requirement. What > makes is: > Address Q1 in Coexistence v1, v2c > V3 noAuthNoPriv if configured, (nothing to do) : same access > level both > NMS and CPE users ( limited view recommended) > > Eduardo > > -----Original Message----- > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > Sent: Tuesday, January 28, 2003 5:22 PM > To: 'Woundy, Richard'; Eduardo Cardona > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > That could be one implementation. > > Another possibility is it could be done through IP forwarding tables. > Conceptually, the CMTS HFC interface is connected to two networks - > one public and one private. When a packet is received on the public > interface (i.e. from the CPE) that is addressed to the > private network, > the forwarding table would not have a route for it and discards the > packet. > > Although I don't know the CMTS implementation specifics, my > understanding is that the described behavior is the way most MSOs > operate their network. i.e. CPE cannot communicate with someone > else's CM. > > greg > > > -----Original Message----- > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > Sent: Tuesday, January 28, 2003 4:12 PM > > To: 'Nakanishi Greg-MGI8179'; 'Eduardo Cardona' > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > You're assuming that the CMTS implements the Subscriber Management > > MIB, and has docsSubMgtPktFilterTable configured to prevent the > > forwarding of subscriber CPE traffic to the private net CMs, right? > > > > -- Rich > > > > -----Original Message----- > > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > > Sent: Tuesday, January 28, 2003 7:03 PM > > To: Woundy, Richard; 'Eduardo Cardona' > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > I agree that the application of ipFilters to packets addressed to > > the CM is not very clear in the spec. This topic comes up every now > > and then on the > > reflector. I believe the generally accepted interpretation > > is that traffic > > addressed to the CM is NOT filtered. > > > > The workaround that I proposed does not rely on the use of IP > > filters. It just relies on the the partitioning of the private IP > > network that the CM is > > part of and the public IP network that the CPE is part of. > > Typically, the > > CMTS will not route between these networks. > > > > A user can access through SNMP his/her own CM through the diagnostic > > IP address; however, a user cannot access someone elses CM. The > > packets from > > the user's CPE on the public network will not be routed by > > the CMTS to the > > private network on which someone else's CM resides. > > > > greg > > > > > -----Original Message----- > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > Sent: Tuesday, January 28, 2003 3:27 PM > > > To: 'Eduardo Cardona'; Nakanishi Greg-MGI8179 > > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > I wonder whether current CM vendors typically check the > > > docsDevFilterIpTable before they process a locally-addressed SNMP > > > PDU. > > > > > > Anyone know? > > > > > > -- Rich > > > > > > -----Original Message----- > > > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > > > Sent: Tuesday, January 28, 2003 4:53 PM > > > To: Woundy, Richard; Nakanishi Greg-MGI8179 > > > Cc: IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > I forgot to mention something, > > > > > > 3.3.2.2. SNMPv3 Interface via vacm extension to be removed > > > > > > Going back to Greg's comments? > > > > > > Is the filtering flow in 3.3 accurated enough to solve that in > > > terms of this filter schems? > > > > > > Seems that SNMP traffic (Section 3.3) is not intuitively "forced" > > > to go to the ip filters (which after removing vacmExt will be > > mere NmAccess > > > Mode) before hitting the agent. ( I mean the NmAccess text from > > > rfc2669 is distracting ?) > > > > > > I've seen people with different interpretations of how to > > "implement" > > > the filters based on directed to CM traffic or CM > forwarded traffic > > > It may create confusion that as the diagram is following > > the Stack for > > > the RF-CPE or CPE-RF traffic the RF-CM CPE-CM trattic is > > not properly > > > represented : I add a little box of possible interpretation that > > > should be clarified. > > > > > > > > > > > > ***************** > > > * LLC Filter In * > > > ***************** > > > | > > > v > > > ******************* > > > * Special Filters * > > > * | * > > > * V * > > > * ************ * > > > * * IP Spoof * * > > > * ************ * > > > * | * > > > * v * > > > > > > * *************** * > > > * * SNMP Access * * > > > * *************** * > > > * | * > > > ******************* > > > | ------> Wrong : SNMP to > > > CM traffic > > > processing > > > v > > > **************** > > > * IP Filter In * > > > **************** > > > | -------> Rigth: SNMP to > > > CM traffic > > > processing > > > v > > > ***************** > > > * IP Filter Out * > > > ***************** > > > | > > > v > > > ****************** > > > * LLC Filter Out * > > > ****************** > > > > > > -----Original Message----- > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > Sent: Tuesday, January 28, 2003 12:58 PM > > > To: Nakanishi Greg-MGI8179; Eduardo Cardona > > > Cc: IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Eduardo, > > > > > > I am sympathetic to Greg and Kevin's argument that perhaps the > > > docsDevVacmAccessExtTable extension to VACM should be > > deleted from the > > > Cable Device MIB, for three reasons: > > > > > > 1. Greg seems to have proposed a workaround for the use case I > > > proposed. Restating, the DOCSIS configuration file could set up > > > the docsDevFilterIpTable to reject UDP/SNMP traffic arriving on > > the RF/HFC > > > interface from any IP subnets other than the MSOs > management station > > > > subnets. This sounds like reasonable security practice in > any case, > > > i.e. don't just rely on SNMPv3 authentication. It enables > subscriber > > > > CM management from the CMCI side, but not subscriber/random user > > > access from the RF/HFC side, per my use case. 2. I agree > it would be > > > > much easier for vendors if they could leverage standard > SNMP agent > > > stack implementations as much as possible. The extension for > > > DOCSIS-only devices makes this objective more difficult. > 3. There is > > > > also a possibility that the IETF MIB doctor might frown on a > > DOCSIS-specific > > > extension to the VACM MIB. > > > > > > Does anyone disagree? Shall I make this deletion? > > > > > > Are there any other comments on the current Cable Device MIB > > > -- which is > > > now posted on the IETF reflector, > > > > > bv2-04.txt > > > >? > > > > > > -- Rich > > > > > > -----Original Message----- > > > From: Eduardo Cardona [mailto:e.cardona@cablelabs.com] > > > Sent: Tuesday, January 28, 2003 1:51 PM > > > To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Kevin, Greg, > > > > > > Following your thoughts. I think I got more findings that > need to be > > > > addressed in any case. The vacmAccess Interface requirements is > > > being as a > > proposal since the > > > early versions of this draft. > > > > > > We know your concerns and they are also related to different > > > discussion in the reflector (i.e. controlling the number of > > traps/notification by > > > touching the Notification Originator subsystem in the > SNMP entity ) > > > > > > In this case the difficulty is to modify the Access Control > > > Subsystem in the SNMP entity, to being able to add the interface > scheme, which is > > > perfectly valid under RFC2571/3411 architecture and AUGMENT > > clause in > > > RFC2578 > > > > > > > > > We need more thoughs in the SNMP constrains we are trying > to achieve > > > > with the full coverage of MSO needs. > > > > > > The need is there: > > > > > > what the SNMP stack providers may solve? (Greg concerns of > > available > > > tools/design framework) Will be Feasible or agree in certain > > > MSO/management constrains? ( few options below) Is the > SNMPv3 group > > > > addressing this case or had ever think about this as a standard > > > mechanism? Will that be clearly extended for embedded cases with > > > logical interfaces > > > instead of physical ones ( to avoid security holes ? > > > > > > > > > Typical case: > > > > > > "Many" (how many is many?) CMs used to bridge the traffic (SNMP) > > > directed to the CM DHCP IP from the CPE through the RF interface > > > Upstream. > > > > > > For blocking traffic: > > > These is trivial since MSO is able to place SNMP filters in the > > > CMTS/backbone For getting CPE traffic: Could be cumbersome in the > > > presence of SNMP filters in the gateway or a > > > CM unable to register. In the other hand the > > > MSO/technician/User, must > > > know the CM IP that could be a problem or not desired always. > > > > > > That one was partially solved with the well known IP 192.168.100.1 > > > > > > What is still a MSO constrain: > > > CMs able to talk to the SNMP stack from any CPE subnet ( spoof NMS > > > IP ) ( 1 hop) and use the v1, v2c vacmAccess constrains for > full access. > > > > > > Also v3 noAuthNoPriv does not support the subletting as RFC 2576 > > > defined for coexistence v1 v2c and there is where Rich's case > > > applied for granting or blocking access. > > > > > > If we agree the well know IP is the "only" way to talk to > > the CM for a > > > CPE with one hop ( CPE to CM DHCP IP queries forwarded > > through RF ) we > > > are OK and the vacm requirement may not needed, but some > > > clarifications are needed in the spec. It creates the need to > > > reconfigure the user CPE > > > any time that a user may need to talk to the CM. > > > > > > > > > With current requirements in either case: > > > In the SNMP framework snmpv3 noAuthNoPRiv the access will > > be the same > > > for MSO and user Access. > > > > > > With the Interface scheme an MSO will be able to set two > > different v3 > > > users noAuthNoPriv with different access. > > > > > > If not the case we still have the issue of blocking NMS spoofed > > > Ips) and the vacmAccessInterface is a way to block that. Or define > > > the ip forward > > > mechanism better. > > > > > > Eduardo > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > > > Sent: Tuesday, January 28, 2003 10:43 AM > > > To: 'IPCDN WG (E-mail)' > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Kevin, I think your point is accurate. > > > > > > Just to expand upon it some... > > > > > > Typically a CM will get a private IP address via DHCP. This > > > results in access to the CM through the HFC interface being > > > limited to > > within the > > > MSO's private IP network. "Outsiders" (e.g. user's on the > > > CMCI-side or on the Internet) will not be able to access a CM > > > through the HFC interface. Access to the CM from the CMCI > > > interface is still allowed if > > > the proper SNMP access controls are setup. > > > > > > I want to make sure that this proposed extension to the > VACM table > > > provides a good benefit over what is acheivable today with the > > > mechanisms we already have. > > > > > > greg > > > > > > > -----Original Message----- > > > > From: Marez Kevin-MGI1375 > > > > Sent: Tuesday, January 28, 2003 9:10 AM > > > > To: 'Woundy, Richard'; Nakanishi Greg-MGI8179 > > > > Cc: IPCDN WG (E-mail) > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > > > > Rich, > > > > > > > > I understand the scenario you have presented, however, I > > think MSOs > > > > would typically use a private networking space for the > > RF-side and > > > > explicitly prevent access from outside that space. > > > > > > > > Our concern here is that we are adding an additional level of > > > > complexity to the vacmAccess table that doesn't provide a > > > great deal > > > > of benefit. > > > > > > > > Greg, please respond I have misstated anything or if you > > > have anything > > > > > > > you'd like to add. Thanks very much, > > > > > > > > Kevin > > > > > > > > > > > > -----Original Message----- > > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > > Sent: Wednesday, January 22, 2003 3:59 PM > > > > To: 'Marez Kevin-MGI1375' > > > > Cc: IPCDN WG (E-mail) > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > > > > Kevin, > > > > > > > > Here is my comment on the VACM issue: > > > > > > > > >10) docsDevVacmAccessExtTable - Is this table really needed > > > > when using > > > > >SNMPv3? The limited security provided in SNMPv1/2 > > > > necessitated having > > > > >this functionality in the nmAccessTable. Given SNMPv3 > > > security, it > > > > >doesn't seem like this functionality is necessary anymore. > > > > > > > > I would agree that it is better security to authenticate a > > > keyed hash > > > > via SNMPv3, than to rely on the incoming device interface > > > for implied > > > > user identification. > > > > > > > > However, one interesting and important case is a CM diagnostic > > > > interface for subscriber-side queries, after the CM > registration > > > > process is completed. It > > > > seems quite useful to allow subscriber tools (with SNMPv3 > > > > securityLevel of > > > > noAuthNoPriv) to query cable modems over the CMCI (CPE > > > > interface) but not > > > > over the RFI (RF interface). > > > > > > > > -- Rich > > > > > > > _______________________________________________ > > > IPCDN mailing list > > > IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn > > > _______________________________________________ > > > IPCDN mailing list > > > IPCDN@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Jan 29 14:34:55 2003 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 OAA27437 for ; Wed, 29 Jan 2003 14:34:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TJuUB18230 for ipcdn-archive@odin.ietf.org; Wed, 29 Jan 2003 14:56:30 -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 h0TJuBJ18215; Wed, 29 Jan 2003 14:56:11 -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 h0TJt9J18148 for ; Wed, 29 Jan 2003 14:55:09 -0500 Received: from mms3.broadcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27374 for ; Wed, 29 Jan 2003 14:33:02 -0500 (EST) Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom MMS1 SMTP Relay (MMS v5.5.0)); Wed, 29 Jan 2003 11:36:33 -0700 Received: from ltatlamdolas (dhcp-10-24-65-44.atlanta.broadcom.com [10.24.65.44]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with SMTP id LAA17536; Wed, 29 Jan 2003 11:36:22 -0800 (PST) From: "Margo Dolas" To: "Pollak, Lucy" , "'Lejeune, Andre'" , "Murwin William-LWM008" , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Wed, 29 Jan 2003 14:36:25 -0500 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <7DF2A1B372BBD611912F00508BDFBA9A9C1872@dile03.itg.ti.com> X-MIME-Autoconverted: from 8bit to quoted-printable by mon-irva-11.broadcom.com id LAA17536 X-WSS-ID: 1226F2CB243562-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0TJt9J18149 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Andre and Lucy, I believe that the test failures occurred because the spec was unclear in the past. The original understanding was that the docsQosServiceFlowPolicedDropPkts counter include only packets dropped in violation of the Max(T) equation. However, with failures at tComLabs dues to lack of clarity in the spec, many vendors coded to the test. I thought that adding a new counter to count UGS packets dropped because the packet exceeds the UGS grant would add an appropriate place to count these dropped packets. However, having said this, my objective is clarity in the descriptions. If the consensus is to count the dropped UGS packets in the docsQosServiceFlowPolicedDropPkts counter, the description should be changed to explicitly state this. Regards, Margo -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, 29 January, 2003 1:55 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 André. I do not think that to count something twice is so bad. The ifOutDiscard counter is integrated counter which shows the sum of all dropped packets on US. The docsQosServiceFlowPolicedDropPkts is per interface counter and give more detailed information. Again, I do not see a reason to change docsQosServiceFlowPolicedDropPkts definition. Thanks. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 8:43 PM To: Pollak, Lucy; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 In trying to make sure that the text was as clear as possible, I think I lost sight of the general goal, which should be to ensure that each dropped packet is counted somewhere and counted only once. We too implemented the counter to include UGS dropped packets, in particular if the rt policy is set to drop UGS packets that are too large. In reality, there are only 2 counters that count dropped packets: ifOutDiscard and docsQosServiceFlowPolicedDropPkts. So if a UGS packet needs to be dropped, where is it counted if it is not in docsQosServiceFlowPolicedDropPkts? André "does not know what he wants" L. -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, January 29, 2003 12:00 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Margo and André. I want to understand the reason for this change. I also familiar with this discussion and in the beginning understood "especially to limit the maximum rate of the flow" as "only to limit the maximum rate of the flow". But with this understanding we failed tComLabs tests. Now, I guess, most of the CMs already implemented this counter as integrated counter: Max rate + max size + grant size + grant rate dropped packets. And it seems the correct behavior, if somebody wants to compare classified packets against dropped+send. I suppose, for backward compatibility we need to leave docsQosServiceFlowPolicedDropPkts as is or even add the definition that it will count all dropped packets. In addition, I agree, we may add the set of reason's defined packet counters: docsQosServiceFlowSizeDropPkts docsQosServiceFlowRateDropPkts I do not see a reason to differentiate UGS and other SF types. In definition we can tell that MAX rate or grant rate is the reason for the drop. The same about size. I do not see a reason to change delayed packet also. Again, "especially" gives us opportunity to apply it to UGS also. The SF type will not be changed on-the-fly. What is the problem to show the same information for UGS? Regards. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 12:41 AM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Looks much better! I like it. Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 5:19 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, In thinking about it a bit more, I'd prefer to see more explicit text for the policed packets. What do you think of the following text? For the docsQosServiceFlowPolicedDropPkts description - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: owner-docsis-oss@cablelabs.com [mailto:owner-docsis-oss@cablelabs.com]On Behalf Of Margo Dolas Sent: Tuesday, 28 January, 2003 4:18 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, I agree with your simplification. The new text for the docsQosServiceFlowPolicedDropPkts description would then be - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." A similar simplification could be made to the description of docsQosServiceFlowPolicedDelayPkts. The new text would be - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 2:08 PM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I understand why I did not read this text properly then. I took the last sentence out of context. I don't think I had to stretch my imagination that much to take it out of context, it does not make any mention of UGS, and when the Maximum Sustained Traffic Rate is exceeded, the packet arrival rate does exceed the packet transmission rate. Instead of providing a series of examples for UGS flows, would it not be simpler to replace it with a statement that the parameter does not apply to UGS flows, since Max Sustained Rate is not applicable? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 1:14 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, Maximum Sustained Rate is not applicable for UGS flows (per section 8.2.7 and table 8-4 of the RFI I09 spec), so packets cannot violate the Maximum Sustained Rate for an UGS flow. In an UGS flow, you only evaluate the packet size versus the UGS grant size, and then queue the packet until you receive a grant for the flow's SID. If the queue is full (because packets are arriving faster than the grant rate), then the packet is dropped and ifOutDiscards is incremented. Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 11:17 AM To: Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I have a problem with the proposed text because I don't understand how to distinguish packets that are in violation of the Maximum Sustained rate from packets with arrival rate faster than the grant rate. What is the difference? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 4:43 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Jan 29 16:34:22 2003 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 QAA00621 for ; Wed, 29 Jan 2003 16:34:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TLtxc26132 for ipcdn-archive@odin.ietf.org; Wed, 29 Jan 2003 16:55:59 -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 h0TLtrJ26125; Wed, 29 Jan 2003 16:55:53 -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 h0TLsrJ26070 for ; Wed, 29 Jan 2003 16:54:53 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00590 for ; Wed, 29 Jan 2003 16:32:42 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id h0TLaBwH020532; Wed, 29 Jan 2003 14:36:11 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 29 Jan 2003 14:36:11 -0700 Message-ID: Thread-Topic: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Thread-Index: AcLHvQEm/atvZmyiQwSQLS9p9bT7GwABvD+w From: "Eduardo Cardona" To: "Woundy, Richard" , "Nakanishi Greg-MGI8179" Cc: "IPCDN WG (E-mail)" , "DOCSIS OSS Majordomo List" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0TLsrJ26071 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Rich, That's right. v3 noAuthNoPriv, is exactly what you say, MSOs should not have more than minimal access to users (any : internal, customers) at that level Coexistence v1, v2c is almost what you said, with a little bit of extra protection MSO can use the TMAsk from RFC2576 to allow only some IP/subnets mask associated with a community string ( indicated in the config file). 1) If a CM forward the SNMP CPE to CM IP traffic through the RF there is no problem, traffic goes away 2) If the CM does not forward the SNMP traffic, a User may be able to spoof the NMS ip and get access to operator-level by gessing or capturing the CM community string from config file of sniffing the RF somw how. Diagnostic IP forces the CPE to be in 192.168.100.x, solve the problem only if CM forced to be in the same subnet ( limited view associated with that) One solution I see for 2) is to force the CM to not respond directly to SNMP from CPE and forward the packet to RF wich means only with Diagnostic IP a CPE user can talk to the CM directly. If CMs are no longer dumm bridges -case 1)-, IP applications on to of the CM may create a relaxed packet handling for arbitrary configured IPs in the CPEs Eduardo -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Wednesday, January 29, 2003 10:37 AM To: Eduardo Cardona; Nakanishi Greg-MGI8179 Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... I guess the biggest problem is when we don't use SNMPv3 authentication, and when we don't use the docsDevNmAccessTable (e.g. with docsDevNmAccessInterfaces restricting access from the CMCI) -- e.g. SNMP Coexistence. In the case of SNMP Coexistence, the only thing that stops end-users from operator-level SNMP access is knowledge of the community string, which is probably exposed as a plain-text ASCII string in the DOCSIS config files on the TFTP servers. Am I misinformed? -- Rich -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] Sent: Wednesday, January 29, 2003 9:02 AM To: Nakanishi Greg-MGI8179; Woundy, Richard Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Greg, Rich, Sorry if I wasn't clear. I am fine with all the comments about spoofing and subnets isolation mechanisms. The case I am presenting ( not spoofing other CM's Ips) It is the case of a user spoofing an NMS IP address with the solely purpose of getting access to the SNMP entity of its own CM ( not traffic intervention in the RF), ( simulating the NMS network in the CPE side), then the subnet Mask mechanism for Coesistence v1 v2c may failed in the case of a CM that reply to SNMP request from CPEs ( CM believes that the request is from a valid subnet, user still needs to guess the comminity string) In the case of v3 noAuthNoPriv as soon as is defined such view it becomes a CPE user view ( no interface/subnet filtering). MSO can't have an username for CPE and think in another user ( more privileges/access) for exclusive MSO administration. The point I am trying to get into is as more routing/ip aware stuff is placed in the CMs: Just guessing: A common behavior of a CPE SNMP request directed to CM DHCP IP is forwarding to RF US and bounce back to CM side due the bridge nature of the implementation. That may stop happening since some CMs failed to filter SNMP traffic based on interfaces since the CPE traffic appear as RF traffic ( bounded back) What some inmplementations may did was to start listening to SNMP to CM DHCP IP and apply the NmAccess interface filter, If that's the case a CM will recognize a CM IP in ( -----Original Message----- From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] Sent: Tuesday, January 28, 2003 6:36 PM To: Eduardo Cardona; Woundy, Richard Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Eduardo, The original use case given was the ability for the CPE to access it's own CM via SNMP, but not be able to access someone else's CM through the RF interface. I'm assuming it OK for MSO staff to access the CM. Allowing access to local CM -- To allow the CPE to access it's own CM, all that is required is a VACM entry with noAuthnoPriv to allow access to a restricted set of MIB objects. In this case, from a security point of view, it shouldn't matter which IP address the SNMP request is sent to. The VACM table will determine if access is allowed regardless of the IP address used. Preventing access to someone else's CM -- This is supported by restricting the routing of packets between the public and private networks. As we've been discussing, it appears there are a few methods in which this can be done. MSO staff to access the CM -- If the SNMP request is generated from within the private network (e.g. MSO's NMS)then the access to the CM will be determined by the VACM table. Does this address your concern? greg > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: Tuesday, January 28, 2003 5:05 PM > To: Nakanishi Greg-MGI8179; Woundy, Richard > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Greg, > > The IP spaces is fine as soon as the user does not try to spoof an NMS > IP (where NmAccess beats SNMP by supporting interfaces for the non > authenticated communication) > > Q1: > Does ALL CMs forward (theoretically yes because are bridges) to RFI > all ( no ICMP) traffic (including CM DHCP IP) but "diagnostic IP > destination? > > If YES Greg's scenario follows the MSO normal filtering conditions ( > i.e UDP/TCP port fitering between subnets) > > If NO > > The case I am mentioning is a user spoofing an NMS IP (matches Ip > subnet) and contacting the CH DHCP IP and then, the CM processes > packet without forwarding it to the network, replying back to the > user. > > To avoid the vacmExt, if the answer is 'NO', I think the below rules > may aliviate some problems: > > Flow type Destination > 1) CPE -> CM SNMP "Diagnostic IP" YES > 2) CPE -> CM SNMP CM DHCP IP NO -Q1- > 3) CPE -> CM ICMP "Diagnostic IP" YES > 4) CPE -> CM ICMP CM DHCP IP YES > 5) CPE -> CM Other IP both NO ( some cases YES as > top services run in CM stack like HTTP) > > Req 2) seems to be the problem for the Interface requirement. What > makes is: > Address Q1 in Coexistence v1, v2c > V3 noAuthNoPriv if configured, (nothing to do) : same access > level both > NMS and CPE users ( limited view recommended) > > Eduardo > > -----Original Message----- > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > Sent: Tuesday, January 28, 2003 5:22 PM > To: 'Woundy, Richard'; Eduardo Cardona > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > That could be one implementation. > > Another possibility is it could be done through IP forwarding tables. > Conceptually, the CMTS HFC interface is connected to two networks - > one public and one private. When a packet is received on the public > interface (i.e. from the CPE) that is addressed to the > private network, > the forwarding table would not have a route for it and discards the > packet. > > Although I don't know the CMTS implementation specifics, my > understanding is that the described behavior is the way most MSOs > operate their network. i.e. CPE cannot communicate with someone > else's CM. > > greg > > > -----Original Message----- > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > Sent: Tuesday, January 28, 2003 4:12 PM > > To: 'Nakanishi Greg-MGI8179'; 'Eduardo Cardona' > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > You're assuming that the CMTS implements the Subscriber Management > > MIB, and has docsSubMgtPktFilterTable configured to prevent the > > forwarding of subscriber CPE traffic to the private net CMs, right? > > > > -- Rich > > > > -----Original Message----- > > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > > Sent: Tuesday, January 28, 2003 7:03 PM > > To: Woundy, Richard; 'Eduardo Cardona' > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > I agree that the application of ipFilters to packets addressed to > > the CM is not very clear in the spec. This topic comes up every now > > and then on the > > reflector. I believe the generally accepted interpretation > > is that traffic > > addressed to the CM is NOT filtered. > > > > The workaround that I proposed does not rely on the use of IP > > filters. It just relies on the the partitioning of the private IP > > network that the CM is > > part of and the public IP network that the CPE is part of. > > Typically, the > > CMTS will not route between these networks. > > > > A user can access through SNMP his/her own CM through the diagnostic > > IP address; however, a user cannot access someone elses CM. The > > packets from the user's CPE on the public network will not be routed > > by the CMTS to the > > private network on which someone else's CM resides. > > > > greg > > > > > -----Original Message----- > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > Sent: Tuesday, January 28, 2003 3:27 PM > > > To: 'Eduardo Cardona'; Nakanishi Greg-MGI8179 > > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > I wonder whether current CM vendors typically check the > > > docsDevFilterIpTable before they process a locally-addressed SNMP > > > PDU. > > > > > > Anyone know? > > > > > > -- Rich > > > > > > -----Original Message----- > > > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > > > Sent: Tuesday, January 28, 2003 4:53 PM > > > To: Woundy, Richard; Nakanishi Greg-MGI8179 > > > Cc: IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > I forgot to mention something, > > > > > > 3.3.2.2. SNMPv3 Interface via vacm extension to be removed > > > > > > Going back to Greg's comments? > > > > > > Is the filtering flow in 3.3 accurated enough to solve that in > > > terms of this filter schems? > > > > > > Seems that SNMP traffic (Section 3.3) is not intuitively "forced" > > > to go to the ip filters (which after removing vacmExt will be > > mere NmAccess > > > Mode) before hitting the agent. ( I mean the NmAccess text from > > > rfc2669 is distracting ?) > > > > > > I've seen people with different interpretations of how to > > "implement" > > > the filters based on directed to CM traffic or CM > forwarded traffic > > > It may create confusion that as the diagram is following > > the Stack for > > > the RF-CPE or CPE-RF traffic the RF-CM CPE-CM trattic is > > not properly > > > represented : I add a little box of possible interpretation that > > > should be clarified. > > > > > > > > > > > > ***************** > > > * LLC Filter In * > > > ***************** > > > | > > > v > > > ******************* > > > * Special Filters * > > > * | * > > > * V * > > > * ************ * > > > * * IP Spoof * * > > > * ************ * > > > * | * > > > * v * > > > > > > * *************** * > > > * * SNMP Access * * > > > * *************** * > > > * | * > > > ******************* > > > | ------> Wrong : SNMP to > > > CM traffic > > > processing > > > v > > > **************** > > > * IP Filter In * > > > **************** > > > | -------> Rigth: SNMP to > > > CM traffic > > > processing > > > v > > > ***************** > > > * IP Filter Out * > > > ***************** > > > | > > > v > > > ****************** > > > * LLC Filter Out * > > > ****************** > > > > > > -----Original Message----- > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > Sent: Tuesday, January 28, 2003 12:58 PM > > > To: Nakanishi Greg-MGI8179; Eduardo Cardona > > > Cc: IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Eduardo, > > > > > > I am sympathetic to Greg and Kevin's argument that perhaps the > > > docsDevVacmAccessExtTable extension to VACM should be > > deleted from the > > > Cable Device MIB, for three reasons: > > > > > > 1. Greg seems to have proposed a workaround for the use case I > > > proposed. Restating, the DOCSIS configuration file could set up > > > the docsDevFilterIpTable to reject UDP/SNMP traffic arriving on > > the RF/HFC > > > interface from any IP subnets other than the MSOs > management station > > > > subnets. This sounds like reasonable security practice in > any case, > > > i.e. don't just rely on SNMPv3 authentication. It enables > subscriber > > > > CM management from the CMCI side, but not subscriber/random user > > > access from the RF/HFC side, per my use case. 2. I agree > it would be > > > > much easier for vendors if they could leverage standard > SNMP agent > > > stack implementations as much as possible. The extension for > > > DOCSIS-only devices makes this objective more difficult. > 3. There is > > > > also a possibility that the IETF MIB doctor might frown on a > > DOCSIS-specific > > > extension to the VACM MIB. > > > > > > Does anyone disagree? Shall I make this deletion? > > > > > > Are there any other comments on the current Cable Device MIB > > > -- which is > > > now posted on the IETF reflector, > > > > > bv2-04.txt > > > >? > > > > > > -- Rich > > > > > > -----Original Message----- > > > From: Eduardo Cardona [mailto:e.cardona@cablelabs.com] > > > Sent: Tuesday, January 28, 2003 1:51 PM > > > To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Kevin, Greg, > > > > > > Following your thoughts. I think I got more findings that > need to be > > > > addressed in any case. The vacmAccess Interface requirements is > > > being as a > > proposal since the > > > early versions of this draft. > > > > > > We know your concerns and they are also related to different > > > discussion in the reflector (i.e. controlling the number of > > traps/notification by > > > touching the Notification Originator subsystem in the > SNMP entity ) > > > > > > In this case the difficulty is to modify the Access Control > > > Subsystem in the SNMP entity, to being able to add the interface > scheme, which is > > > perfectly valid under RFC2571/3411 architecture and AUGMENT > > clause in > > > RFC2578 > > > > > > > > > We need more thoughs in the SNMP constrains we are trying > to achieve > > > > with the full coverage of MSO needs. > > > > > > The need is there: > > > > > > what the SNMP stack providers may solve? (Greg concerns of > > available > > > tools/design framework) Will be Feasible or agree in certain > > > MSO/management constrains? ( few options below) Is the > SNMPv3 group > > > > addressing this case or had ever think about this as a standard > > > mechanism? Will that be clearly extended for embedded cases with > > > logical interfaces instead of physical ones ( to avoid security > > > holes ? > > > > > > > > > Typical case: > > > > > > "Many" (how many is many?) CMs used to bridge the traffic (SNMP) > > > directed to the CM DHCP IP from the CPE through the RF interface > > > Upstream. > > > > > > For blocking traffic: > > > These is trivial since MSO is able to place SNMP filters in the > > > CMTS/backbone For getting CPE traffic: Could be cumbersome in the > > > presence of SNMP filters in the gateway or a > > > CM unable to register. In the other hand the > > > MSO/technician/User, must > > > know the CM IP that could be a problem or not desired always. > > > > > > That one was partially solved with the well known IP 192.168.100.1 > > > > > > What is still a MSO constrain: > > > CMs able to talk to the SNMP stack from any CPE subnet ( spoof NMS > > > IP ) ( 1 hop) and use the v1, v2c vacmAccess constrains for > full access. > > > > > > Also v3 noAuthNoPriv does not support the subletting as RFC 2576 > > > defined for coexistence v1 v2c and there is where Rich's case > > > applied for granting or blocking access. > > > > > > If we agree the well know IP is the "only" way to talk to > > the CM for a > > > CPE with one hop ( CPE to CM DHCP IP queries forwarded > > through RF ) we > > > are OK and the vacm requirement may not needed, but some > > > clarifications are needed in the spec. It creates the need to > > > reconfigure the user CPE > > > any time that a user may need to talk to the CM. > > > > > > > > > With current requirements in either case: > > > In the SNMP framework snmpv3 noAuthNoPRiv the access will > > be the same > > > for MSO and user Access. > > > > > > With the Interface scheme an MSO will be able to set two > > different v3 > > > users noAuthNoPriv with different access. > > > > > > If not the case we still have the issue of blocking NMS spoofed > > > Ips) and the vacmAccessInterface is a way to block that. Or define > > > the ip forward > > > mechanism better. > > > > > > Eduardo > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > > > Sent: Tuesday, January 28, 2003 10:43 AM > > > To: 'IPCDN WG (E-mail)' > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > Kevin, I think your point is accurate. > > > > > > Just to expand upon it some... > > > > > > Typically a CM will get a private IP address via DHCP. This > > > results in access to the CM through the HFC interface being > > > limited to > > within the > > > MSO's private IP network. "Outsiders" (e.g. user's on the > > > CMCI-side or on the Internet) will not be able to access a CM > > > through the HFC interface. Access to the CM from the CMCI > > > interface is still allowed if > > > the proper SNMP access controls are setup. > > > > > > I want to make sure that this proposed extension to the > VACM table > > > provides a good benefit over what is acheivable today with the > > > mechanisms we already have. > > > > > > greg > > > > > > > -----Original Message----- > > > > From: Marez Kevin-MGI1375 > > > > Sent: Tuesday, January 28, 2003 9:10 AM > > > > To: 'Woundy, Richard'; Nakanishi Greg-MGI8179 > > > > Cc: IPCDN WG (E-mail) > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > > > > Rich, > > > > > > > > I understand the scenario you have presented, however, I > > think MSOs > > > > would typically use a private networking space for the > > RF-side and > > > > explicitly prevent access from outside that space. > > > > > > > > Our concern here is that we are adding an additional level of > > > > complexity to the vacmAccess table that doesn't provide a > > > great deal > > > > of benefit. > > > > > > > > Greg, please respond I have misstated anything or if you > > > have anything > > > > > > > you'd like to add. Thanks very much, > > > > > > > > Kevin > > > > > > > > > > > > -----Original Message----- > > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > > Sent: Wednesday, January 22, 2003 3:59 PM > > > > To: 'Marez Kevin-MGI1375' > > > > Cc: IPCDN WG (E-mail) > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > > > > Kevin, > > > > > > > > Here is my comment on the VACM issue: > > > > > > > > >10) docsDevVacmAccessExtTable - Is this table really needed > > > > when using > > > > >SNMPv3? The limited security provided in SNMPv1/2 > > > > necessitated having > > > > >this functionality in the nmAccessTable. Given SNMPv3 > > > security, it > > > > >doesn't seem like this functionality is necessary anymore. > > > > > > > > I would agree that it is better security to authenticate a > > > keyed hash > > > > via SNMPv3, than to rely on the incoming device interface > > > for implied > > > > user identification. > > > > > > > > However, one interesting and important case is a CM diagnostic > > > > interface for subscriber-side queries, after the CM > registration > > > > process is completed. It > > > > seems quite useful to allow subscriber tools (with SNMPv3 > > > > securityLevel of > > > > noAuthNoPriv) to query cable modems over the CMCI (CPE > > > > interface) but not > > > > over the RFI (RF interface). > > > > > > > > -- Rich > > > > > > > _______________________________________________ > > > IPCDN mailing list > > > IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn > > > _______________________________________________ > > > IPCDN mailing list > > > IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 30 01:42:28 2003 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 BAA10569 for ; Thu, 30 Jan 2003 01:42:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TN23631142 for ipcdn-archive@odin.ietf.org; Wed, 29 Jan 2003 18:02:03 -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 h0TN1pJ31130; Wed, 29 Jan 2003 18:01:51 -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 h0TN03J31013 for ; Wed, 29 Jan 2003 18:00:03 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02462 for ; Wed, 29 Jan 2003 17:37:51 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h0TMfLxN012926 for ; Wed, 29 Jan 2003 15:41:21 -0700 (MST) Received: [from ca25exm01.GI.COM (ca25exm01.gi.com [168.84.84.121]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA26764 for ; Wed, 29 Jan 2003 15:40:20 -0700 (MST)] Received: by ca25exm01 with Internet Mail Service (5.5.2656.59) id ; Wed, 29 Jan 2003 14:41:20 -0800 Message-ID: From: Nakanishi Greg-MGI8179 To: "'Eduardo Cardona'" , "Woundy, Richard" Cc: "IPCDN WG (E-mail)" , DOCSIS OSS Majordomo List Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Date: Wed, 29 Jan 2003 14:41:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Eduardo, How much of an issue is this? This issue exists today independent of SNMP. Has there been any operational problems caused because of this? This issue is orthogonal to the SNMP access control. Seems to me that the proper SNMPv3 access control should be the preferred method for restricting access to important information. If noAuthnoPriv or the Community table is used, then it should be OK for anyone to access the information, otherwise setup the proper keys for secure access. IMO, you don't want to force the CM to have to forward the packet upstream, just to have it returned by the CMTS. This just wastes bandwidth. Granted that as a dumb bridge this is what would happen. However, the CM could be smart about it and turn it around internally. greg > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: Wednesday, January 29, 2003 1:36 PM > To: Woundy, Richard; Nakanishi Greg-MGI8179 > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Rich, That's right. > > v3 noAuthNoPriv, is exactly what you say, MSOs should not > have more than > minimal access to users (any : internal, customers) at that level > > Coexistence v1, v2c is almost what you said, with a little > bit of extra > protection > > MSO can use the TMAsk from RFC2576 to allow only some IP/subnets mask > associated with a community string ( indicated in the config file). > > 1) If a CM forward the SNMP CPE to CM IP traffic through the > RF there is > no problem, traffic goes away > 2) If the CM does not forward the SNMP traffic, a User may be able to > spoof the NMS ip and get access to operator-level by gessing or > capturing the CM community string from config file of sniffing the RF > somw how. > > Diagnostic IP forces the CPE to be in 192.168.100.x, solve the problem > only if CM forced to be in the same subnet ( limited view associated > with that) > > One solution I see for 2) is to force the CM to not respond > directly to > SNMP from CPE and forward the packet to RF wich means only with > Diagnostic IP a CPE user can talk to the CM directly. > > If CMs are no longer dumm bridges -case 1)-, IP applications on to of > the CM may create a relaxed packet handling for arbitrary > configured IPs > in the CPEs > > > Eduardo > > > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Wednesday, January 29, 2003 10:37 AM > To: Eduardo Cardona; Nakanishi Greg-MGI8179 > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > I guess the biggest problem is when we don't use SNMPv3 > authentication, > and when we don't use the docsDevNmAccessTable (e.g. with > docsDevNmAccessInterfaces restricting access from the CMCI) > -- e.g. SNMP > Coexistence. > > In the case of SNMP Coexistence, the only thing that stops end-users > from operator-level SNMP access is knowledge of the community string, > which is probably exposed as a plain-text ASCII string in the DOCSIS > config files on the TFTP servers. > > Am I misinformed? > > -- Rich > > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: Wednesday, January 29, 2003 9:02 AM > To: Nakanishi Greg-MGI8179; Woundy, Richard > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Greg, Rich, > > > Sorry if I wasn't clear. > > I am fine with all the comments about spoofing and subnets isolation > mechanisms. > > The case I am presenting ( not spoofing other CM's Ips) > > It is the case of a user spoofing an NMS IP address with the solely > purpose of getting access to the SNMP entity of its own CM ( > not traffic > intervention in the RF), ( simulating the NMS network in the > CPE side), > then the subnet Mask mechanism for Coesistence v1 v2c may > failed in the > case of a CM that reply to SNMP request from CPEs ( CM > believes that the > request is from a valid subnet, user still needs to guess the > comminity > string) > > In the case of v3 noAuthNoPriv as soon as is defined such view it > becomes a CPE user view ( no interface/subnet filtering). MSO > can't have > an username for CPE and think in another user ( more > privileges/access) > for exclusive MSO administration. > > > > > The point I am trying to get into is as more routing/ip aware stuff is > placed in the CMs: > > Just guessing: > > A common behavior of a CPE SNMP request directed to CM DHCP IP is > forwarding to RF US and bounce back to CM side due the bridge > nature of > the implementation. > > That may stop happening since some CMs failed to filter SNMP traffic > based on interfaces since the CPE traffic appear as RF > traffic ( bounded > back) > > What some inmplementations may did was to start listening to > SNMP to CM > DHCP IP and apply the NmAccess interface filter, > > If that's the case a CM will recognize a CM IP in ( > > > -----Original Message----- > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > Sent: Tuesday, January 28, 2003 6:36 PM > To: Eduardo Cardona; Woundy, Richard > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Eduardo, > > The original use case given was the ability for the CPE to access it's > own CM via SNMP, but not be able to access someone else's CM > through the > RF interface. I'm assuming it OK for MSO staff to access the CM. > > Allowing access to local CM -- > To allow the CPE to access it's own CM, all that is required is a VACM > entry with noAuthnoPriv to allow access to a restricted set of MIB > objects. In this case, from a security point of view, it shouldn't > matter which IP address the SNMP request is sent to. The VACM table > will determine if access is allowed regardless of the IP address used. > > Preventing access to someone else's CM -- > This is supported by restricting the routing of packets between the > public and private networks. As we've been discussing, it > appears there > are a few methods in which this can be done. > > MSO staff to access the CM -- > If the SNMP request is generated from within the private network (e.g. > MSO's NMS)then the access to the CM will be determined by the VACM > table. > > Does this address your concern? > > greg > > > > > -----Original Message----- > > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > > Sent: Tuesday, January 28, 2003 5:05 PM > > To: Nakanishi Greg-MGI8179; Woundy, Richard > > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > Greg, > > > > The IP spaces is fine as soon as the user does not try to > spoof an NMS > > > IP (where NmAccess beats SNMP by supporting interfaces for the non > > authenticated communication) > > > > Q1: > > Does ALL CMs forward (theoretically yes because are bridges) to RFI > > all ( no ICMP) traffic (including CM DHCP IP) but "diagnostic IP > > destination? > > > > If YES Greg's scenario follows the MSO normal filtering > conditions ( > > i.e UDP/TCP port fitering between subnets) > > > > If NO > > > > The case I am mentioning is a user spoofing an NMS IP (matches Ip > > subnet) and contacting the CH DHCP IP and then, the CM processes > > packet without forwarding it to the network, replying back to the > > user. > > > > To avoid the vacmExt, if the answer is 'NO', I think the > below rules > > may aliviate some problems: > > > > Flow type Destination > > 1) CPE -> CM SNMP "Diagnostic IP" YES > > 2) CPE -> CM SNMP CM DHCP IP NO -Q1- > > 3) CPE -> CM ICMP "Diagnostic IP" YES > > 4) CPE -> CM ICMP CM DHCP IP YES > > 5) CPE -> CM Other IP both NO ( some > cases YES as > > top services run in CM stack like HTTP) > > > > Req 2) seems to be the problem for the Interface requirement. What > > makes is: > > Address Q1 in Coexistence v1, v2c > > V3 noAuthNoPriv if configured, (nothing to do) : same access > > level both > > NMS and CPE users ( limited view recommended) > > > > Eduardo > > > > -----Original Message----- > > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > > Sent: Tuesday, January 28, 2003 5:22 PM > > To: 'Woundy, Richard'; Eduardo Cardona > > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > That could be one implementation. > > > > Another possibility is it could be done through IP > forwarding tables. > > Conceptually, the CMTS HFC interface is connected to two networks - > > one public and one private. When a packet is received on the public > > interface (i.e. from the CPE) that is addressed to the > > private network, > > the forwarding table would not have a route for it and discards the > > packet. > > > > Although I don't know the CMTS implementation specifics, my > > understanding is that the described behavior is the way most MSOs > > operate their network. i.e. CPE cannot communicate with someone > > else's CM. > > > > greg > > > > > -----Original Message----- > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > Sent: Tuesday, January 28, 2003 4:12 PM > > > To: 'Nakanishi Greg-MGI8179'; 'Eduardo Cardona' > > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > You're assuming that the CMTS implements the Subscriber Management > > > MIB, and has docsSubMgtPktFilterTable configured to prevent the > > > forwarding of subscriber CPE traffic to the private net > CMs, right? > > > > > > -- Rich > > > > > > -----Original Message----- > > > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > > > Sent: Tuesday, January 28, 2003 7:03 PM > > > To: Woundy, Richard; 'Eduardo Cardona' > > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > I agree that the application of ipFilters to packets addressed to > > > the CM is not very clear in the spec. This topic comes > up every now > > > and then on the > > > reflector. I believe the generally accepted interpretation > > > is that traffic > > > addressed to the CM is NOT filtered. > > > > > > The workaround that I proposed does not rely on the use of IP > > > filters. It just relies on the the partitioning of the > private IP > > > > network that the CM is > > > part of and the public IP network that the CPE is part of. > > > Typically, the > > > CMTS will not route between these networks. > > > > > > A user can access through SNMP his/her own CM through the > diagnostic > > > > IP address; however, a user cannot access someone elses CM. The > > > packets from the user's CPE on the public network will > not be routed > > > > by the CMTS to the > > > private network on which someone else's CM resides. > > > > > > greg > > > > > > > -----Original Message----- > > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > > Sent: Tuesday, January 28, 2003 3:27 PM > > > > To: 'Eduardo Cardona'; Nakanishi Greg-MGI8179 > > > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > > > > I wonder whether current CM vendors typically check the > > > > docsDevFilterIpTable before they process a > locally-addressed SNMP > > > > PDU. > > > > > > > > Anyone know? > > > > > > > > -- Rich > > > > > > > > -----Original Message----- > > > > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > > > > Sent: Tuesday, January 28, 2003 4:53 PM > > > > To: Woundy, Richard; Nakanishi Greg-MGI8179 > > > > Cc: IPCDN WG (E-mail) > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > > > > I forgot to mention something, > > > > > > > > 3.3.2.2. SNMPv3 Interface via vacm extension to be removed > > > > > > > > Going back to Greg's comments? > > > > > > > > Is the filtering flow in 3.3 accurated enough to solve that in > > > > terms of this filter schems? > > > > > > > > Seems that SNMP traffic (Section 3.3) is not > intuitively "forced" > > > > to go to the ip filters (which after removing vacmExt will be > > > mere NmAccess > > > > Mode) before hitting the agent. ( I mean the NmAccess text from > > > > rfc2669 is distracting ?) > > > > > > > > I've seen people with different interpretations of how to > > > "implement" > > > > the filters based on directed to CM traffic or CM > > forwarded traffic > > > > It may create confusion that as the diagram is following > > > the Stack for > > > > the RF-CPE or CPE-RF traffic the RF-CM CPE-CM trattic is > > > not properly > > > > represented : I add a little box of possible interpretation that > > > > should be clarified. > > > > > > > > > > > > > > > > ***************** > > > > * LLC Filter In * > > > > ***************** > > > > | > > > > v > > > > ******************* > > > > * Special Filters * > > > > * | * > > > > * V * > > > > * ************ * > > > > * * IP Spoof * * > > > > * ************ * > > > > * | * > > > > * v * > > > > > > > > * *************** * > > > > * * SNMP Access * * > > > > * *************** * > > > > * | * > > > > ******************* > > > > | ------> Wrong : SNMP to > > > > CM traffic > > > > processing > > > > v > > > > **************** > > > > * IP Filter In * > > > > **************** > > > > | -------> Rigth: SNMP to > > > > CM traffic > > > > processing > > > > v > > > > ***************** > > > > * IP Filter Out * > > > > ***************** > > > > | > > > > v > > > > ****************** > > > > * LLC Filter Out * > > > > ****************** > > > > > > > > -----Original Message----- > > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > > Sent: Tuesday, January 28, 2003 12:58 PM > > > > To: Nakanishi Greg-MGI8179; Eduardo Cardona > > > > Cc: IPCDN WG (E-mail) > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > > > > Eduardo, > > > > > > > > I am sympathetic to Greg and Kevin's argument that perhaps the > > > > docsDevVacmAccessExtTable extension to VACM should be > > > deleted from the > > > > Cable Device MIB, for three reasons: > > > > > > > > 1. Greg seems to have proposed a workaround for the use case I > > > > proposed. Restating, the DOCSIS configuration file could set up > > > > the docsDevFilterIpTable to reject UDP/SNMP traffic arriving on > > > the RF/HFC > > > > interface from any IP subnets other than the MSOs > > management station > > > > > > subnets. This sounds like reasonable security practice in > > any case, > > > > i.e. don't just rely on SNMPv3 authentication. It enables > > subscriber > > > > > > CM management from the CMCI side, but not > subscriber/random user > > > > access from the RF/HFC side, per my use case. 2. I agree > > it would be > > > > > > much easier for vendors if they could leverage standard > > SNMP agent > > > > stack implementations as much as possible. The extension for > > > > DOCSIS-only devices makes this objective more difficult. > > 3. There is > > > > > > also a possibility that the IETF MIB doctor might frown on a > > > DOCSIS-specific > > > > extension to the VACM MIB. > > > > > > > > Does anyone disagree? Shall I make this deletion? > > > > > > > > Are there any other comments on the current Cable Device MIB > > > > -- which is > > > > now posted on the IETF reflector, > > > > > > > bv2-04.txt > > > > >? > > > > > > > > -- Rich > > > > > > > > -----Original Message----- > > > > From: Eduardo Cardona [mailto:e.cardona@cablelabs.com] > > > > Sent: Tuesday, January 28, 2003 1:51 PM > > > > To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail) > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > > > > Kevin, Greg, > > > > > > > > Following your thoughts. I think I got more findings that > > need to be > > > > > > addressed in any case. The vacmAccess Interface requirements is > > > > being as a > > > proposal since the > > > > early versions of this draft. > > > > > > > > We know your concerns and they are also related to different > > > > discussion in the reflector (i.e. controlling the number of > > > traps/notification by > > > > touching the Notification Originator subsystem in the > > SNMP entity ) > > > > > > > > In this case the difficulty is to modify the Access Control > > > > Subsystem in the SNMP entity, to being able to add the interface > > scheme, which is > > > > perfectly valid under RFC2571/3411 architecture and AUGMENT > > > clause in > > > > RFC2578 > > > > > > > > > > > > We need more thoughs in the SNMP constrains we are trying > > to achieve > > > > > > with the full coverage of MSO needs. > > > > > > > > The need is there: > > > > > > > > what the SNMP stack providers may solve? (Greg concerns of > > > available > > > > tools/design framework) Will be Feasible or agree in certain > > > > MSO/management constrains? ( few options below) Is the > > SNMPv3 group > > > > > > addressing this case or had ever think about this as a standard > > > > mechanism? Will that be clearly extended for embedded > cases with > > > > logical interfaces instead of physical ones ( to avoid security > > > > holes ? > > > > > > > > > > > > Typical case: > > > > > > > > "Many" (how many is many?) CMs used to bridge the > traffic (SNMP) > > > > directed to the CM DHCP IP from the CPE through the RF > interface > > > > Upstream. > > > > > > > > For blocking traffic: > > > > These is trivial since MSO is able to place SNMP filters in the > > > > CMTS/backbone For getting CPE traffic: Could be > cumbersome in the > > > > > presence of SNMP filters in the gateway or a > > > > CM unable to register. In the other hand the > > > > MSO/technician/User, must > > > > know the CM IP that could be a problem or not desired always. > > > > > > > > That one was partially solved with the well known IP > 192.168.100.1 > > > > > > > > What is still a MSO constrain: > > > > CMs able to talk to the SNMP stack from any CPE subnet > ( spoof NMS > > > > > IP ) ( 1 hop) and use the v1, v2c vacmAccess constrains for > > full access. > > > > > > > > Also v3 noAuthNoPriv does not support the subletting as RFC 2576 > > > > defined for coexistence v1 v2c and there is where Rich's case > > > > applied for granting or blocking access. > > > > > > > > If we agree the well know IP is the "only" way to talk to > > > the CM for a > > > > CPE with one hop ( CPE to CM DHCP IP queries forwarded > > > through RF ) we > > > > are OK and the vacm requirement may not needed, but some > > > > clarifications are needed in the spec. It creates the need to > > > > reconfigure the user CPE > > > > any time that a user may need to talk to the CM. > > > > > > > > > > > > With current requirements in either case: > > > > In the SNMP framework snmpv3 noAuthNoPRiv the access will > > > be the same > > > > for MSO and user Access. > > > > > > > > With the Interface scheme an MSO will be able to set two > > > different v3 > > > > users noAuthNoPriv with different access. > > > > > > > > If not the case we still have the issue of blocking NMS spoofed > > > > Ips) and the vacmAccessInterface is a way to block > that. Or define > > > > > the ip forward > > > > mechanism better. > > > > > > > > Eduardo > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > > > > Sent: Tuesday, January 28, 2003 10:43 AM > > > > To: 'IPCDN WG (E-mail)' > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > > > > Kevin, I think your point is accurate. > > > > > > > > Just to expand upon it some... > > > > > > > > Typically a CM will get a private IP address via DHCP. This > > > > results in access to the CM through the HFC interface being > > > > limited to > > > within the > > > > MSO's private IP network. "Outsiders" (e.g. user's on the > > > > CMCI-side or on the Internet) will not be able to access a CM > > > > through the HFC interface. Access to the CM from the CMCI > > > > interface is still allowed if > > > > the proper SNMP access controls are setup. > > > > > > > > I want to make sure that this proposed extension to the > > VACM table > > > > provides a good benefit over what is acheivable today with the > > > > mechanisms we already have. > > > > > > > > greg > > > > > > > > > -----Original Message----- > > > > > From: Marez Kevin-MGI1375 > > > > > Sent: Tuesday, January 28, 2003 9:10 AM > > > > > To: 'Woundy, Richard'; Nakanishi Greg-MGI8179 > > > > > Cc: IPCDN WG (E-mail) > > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE > DEVICE MIB... > > > > > > > > > > > > > > > Rich, > > > > > > > > > > I understand the scenario you have presented, however, I > > > think MSOs > > > > > would typically use a private networking space for the > > > RF-side and > > > > > explicitly prevent access from outside that space. > > > > > > > > > > Our concern here is that we are adding an additional level of > > > > > complexity to the vacmAccess table that doesn't provide a > > > > great deal > > > > > of benefit. > > > > > > > > > > Greg, please respond I have misstated anything or if you > > > > have anything > > > > > > > > > you'd like to add. Thanks very much, > > > > > > > > > > Kevin > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Woundy, Richard > [mailto:Richard_Woundy@cable.comcast.com] > > > > > Sent: Wednesday, January 22, 2003 3:59 PM > > > > > To: 'Marez Kevin-MGI1375' > > > > > Cc: IPCDN WG (E-mail) > > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE > DEVICE MIB... > > > > > > > > > > > > > > > Kevin, > > > > > > > > > > Here is my comment on the VACM issue: > > > > > > > > > > >10) docsDevVacmAccessExtTable - Is this table really needed > > > > > when using > > > > > >SNMPv3? The limited security provided in SNMPv1/2 > > > > > necessitated having > > > > > >this functionality in the nmAccessTable. Given SNMPv3 > > > > security, it > > > > > >doesn't seem like this functionality is necessary anymore. > > > > > > > > > > I would agree that it is better security to authenticate a > > > > keyed hash > > > > > via SNMPv3, than to rely on the incoming device interface > > > > for implied > > > > > user identification. > > > > > > > > > > However, one interesting and important case is a CM diagnostic > > > > > interface for subscriber-side queries, after the CM > > registration > > > > > process is completed. It > > > > > seems quite useful to allow subscriber tools (with SNMPv3 > > > > > securityLevel of > > > > > noAuthNoPriv) to query cable modems over the CMCI (CPE > > > > > interface) but not > > > > > over the RFI (RF interface). > > > > > > > > > > -- Rich > > > > > > > > > _______________________________________________ > > > > IPCDN mailing list > > > > IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn > > > > _______________________________________________ > > > > IPCDN mailing list > > > > IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 30 07:02:46 2003 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 HAA24933 for ; Thu, 30 Jan 2003 07:02:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UCOe026687 for ipcdn-archive@odin.ietf.org; Thu, 30 Jan 2003 07:24:40 -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 h0UCOOJ26608; Thu, 30 Jan 2003 07:24:24 -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 h0THIcJ08104 for ; Wed, 29 Jan 2003 12:18:38 -0500 Received: from go4.ext.ti.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23502 for ; Wed, 29 Jan 2003 11:56:35 -0500 (EST) Received: from dlep52.itg.ti.com ([157.170.134.103]) by go4.ext.ti.com (8.12.6/8.12.6) with ESMTP id h0TH03Uw009395; Wed, 29 Jan 2003 11:00:03 -0600 (CST) Received: from dlep98.itg.ti.com (localhost [127.0.0.1]) by dlep52.itg.ti.com (8.12.6/8.12.6) with ESMTP id h0TH02FX020194; Wed, 29 Jan 2003 11:00:02 -0600 (CST) Received: from dile70.itg.ti.com (dile70.itg.ti.com [137.167.177.22]) by dlep98.itg.ti.com (8.9.3/8.9.3) with ESMTP id LAA12868; Wed, 29 Jan 2003 11:00:00 -0600 (CST) Received: by dile70.itg.ti.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Jan 2003 18:59:59 +0200 Message-ID: <7DF2A1B372BBD611912F00508BDFBA9A9C1871@dile03.itg.ti.com> From: "Pollak, Lucy" To: "'Lejeune, Andre'" , Margo Dolas , Murwin William-LWM008 , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Wed, 29 Jan 2003 18:59:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0THIdJ08107 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Margo and André. I want to understand the reason for this change. I also familiar with this discussion and in the beginning understood "especially to limit the maximum rate of the flow" as "only to limit the maximum rate of the flow". But with this understanding we failed tComLabs tests. Now, I guess, most of the CMs already implemented this counter as integrated counter: Max rate + max size + grant size + grant rate dropped packets. And it seems the correct behavior, if somebody wants to compare classified packets against dropped+send. I suppose, for backward compatibility we need to leave docsQosServiceFlowPolicedDropPkts as is or even add the definition that it will count all dropped packets. In addition, I agree, we may add the set of reason's defined packet counters: docsQosServiceFlowSizeDropPkts docsQosServiceFlowRateDropPkts I do not see a reason to differentiate UGS and other SF types. In definition we can tell that MAX rate or grant rate is the reason for the drop. The same about size. I do not see a reason to change delayed packet also. Again, "especially" gives us opportunity to apply it to UGS also. The SF type will not be changed on-the-fly. What is the problem to show the same information for UGS? Regards. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 12:41 AM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Looks much better! I like it. Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 5:19 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, In thinking about it a bit more, I'd prefer to see more explicit text for the policed packets. What do you think of the following text? For the docsQosServiceFlowPolicedDropPkts description - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: owner-docsis-oss@cablelabs.com [mailto:owner-docsis-oss@cablelabs.com]On Behalf Of Margo Dolas Sent: Tuesday, 28 January, 2003 4:18 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, I agree with your simplification. The new text for the docsQosServiceFlowPolicedDropPkts description would then be - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." A similar simplification could be made to the description of docsQosServiceFlowPolicedDelayPkts. The new text would be - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 2:08 PM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I understand why I did not read this text properly then. I took the last sentence out of context. I don't think I had to stretch my imagination that much to take it out of context, it does not make any mention of UGS, and when the Maximum Sustained Traffic Rate is exceeded, the packet arrival rate does exceed the packet transmission rate. Instead of providing a series of examples for UGS flows, would it not be simpler to replace it with a statement that the parameter does not apply to UGS flows, since Max Sustained Rate is not applicable? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 1:14 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, Maximum Sustained Rate is not applicable for UGS flows (per section 8.2.7 and table 8-4 of the RFI I09 spec), so packets cannot violate the Maximum Sustained Rate for an UGS flow. In an UGS flow, you only evaluate the packet size versus the UGS grant size, and then queue the packet until you receive a grant for the flow's SID. If the queue is full (because packets are arriving faster than the grant rate), then the packet is dropped and ifOutDiscards is incremented. Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 11:17 AM To: Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I have a problem with the proposed text because I don't understand how to distinguish packets that are in violation of the Maximum Sustained rate from packets with arrival rate faster than the grant rate. What is the difference? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 4:43 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 30 07:02:48 2003 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 HAA24946 for ; Thu, 30 Jan 2003 07:02:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UCOgi26701 for ipcdn-archive@odin.ietf.org; Thu, 30 Jan 2003 07:24: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 h0UCOMJ26593; Thu, 30 Jan 2003 07:24:22 -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 h0SNWIJ28815 for ; Tue, 28 Jan 2003 18:32:18 -0500 Received: from scbh01.terayon.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11072 for ; Tue, 28 Jan 2003 18:10:36 -0500 (EST) Received: by SCBH01 with Internet Mail Service (5.5.2655.55) id ; Tue, 28 Jan 2003 14:42:57 -0800 Message-ID: From: "Lejeune, Andre" To: Margo Dolas , "Lejeune, Andre" , Murwin William-LWM008 , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Tue, 28 Jan 2003 14:40:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SNWIJ28816 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Looks much better! I like it. Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 5:19 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, In thinking about it a bit more, I'd prefer to see more explicit text for the policed packets. What do you think of the following text? For the docsQosServiceFlowPolicedDropPkts description - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: owner-docsis-oss@cablelabs.com [mailto:owner-docsis-oss@cablelabs.com]On Behalf Of Margo Dolas Sent: Tuesday, 28 January, 2003 4:18 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, I agree with your simplification. The new text for the docsQosServiceFlowPolicedDropPkts description would then be - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." A similar simplification could be made to the description of docsQosServiceFlowPolicedDelayPkts. The new text would be - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 2:08 PM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I understand why I did not read this text properly then. I took the last sentence out of context. I don't think I had to stretch my imagination that much to take it out of context, it does not make any mention of UGS, and when the Maximum Sustained Traffic Rate is exceeded, the packet arrival rate does exceed the packet transmission rate. Instead of providing a series of examples for UGS flows, would it not be simpler to replace it with a statement that the parameter does not apply to UGS flows, since Max Sustained Rate is not applicable? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 1:14 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, Maximum Sustained Rate is not applicable for UGS flows (per section 8.2.7 and table 8-4 of the RFI I09 spec), so packets cannot violate the Maximum Sustained Rate for an UGS flow. In an UGS flow, you only evaluate the packet size versus the UGS grant size, and then queue the packet until you receive a grant for the flow's SID. If the queue is full (because packets are arriving faster than the grant rate), then the packet is dropped and ifOutDiscards is incremented. Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 11:17 AM To: Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I have a problem with the proposed text because I don't understand how to distinguish packets that are in violation of the Maximum Sustained rate from packets with arrival rate faster than the grant rate. What is the difference? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 4:43 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 30 07:02:49 2003 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 HAA24959 for ; Thu, 30 Jan 2003 07:02:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UCOhJ26715 for ipcdn-archive@odin.ietf.org; Thu, 30 Jan 2003 07:24:43 -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 h0UCOPJ26623; Thu, 30 Jan 2003 07:24:25 -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 h0TJ3OJ14236 for ; Wed, 29 Jan 2003 14:03:24 -0500 Received: from scbh01.terayon.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25682 for ; Wed, 29 Jan 2003 13:41:18 -0500 (EST) Received: by SCBH01 with Internet Mail Service (5.5.2655.55) id ; Wed, 29 Jan 2003 10:44:49 -0800 Message-ID: From: "Lejeune, Andre" To: "Pollak, Lucy" , Margo Dolas , Murwin William-LWM008 , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Wed, 29 Jan 2003 10:42:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0TJ3OJ14238 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit In trying to make sure that the text was as clear as possible, I think I lost sight of the general goal, which should be to ensure that each dropped packet is counted somewhere and counted only once. We too implemented the counter to include UGS dropped packets, in particular if the rt policy is set to drop UGS packets that are too large. In reality, there are only 2 counters that count dropped packets: ifOutDiscard and docsQosServiceFlowPolicedDropPkts. So if a UGS packet needs to be dropped, where is it counted if it is not in docsQosServiceFlowPolicedDropPkts? André "does not know what he wants" L. -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, January 29, 2003 12:00 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Margo and André. I want to understand the reason for this change. I also familiar with this discussion and in the beginning understood "especially to limit the maximum rate of the flow" as "only to limit the maximum rate of the flow". But with this understanding we failed tComLabs tests. Now, I guess, most of the CMs already implemented this counter as integrated counter: Max rate + max size + grant size + grant rate dropped packets. And it seems the correct behavior, if somebody wants to compare classified packets against dropped+send. I suppose, for backward compatibility we need to leave docsQosServiceFlowPolicedDropPkts as is or even add the definition that it will count all dropped packets. In addition, I agree, we may add the set of reason's defined packet counters: docsQosServiceFlowSizeDropPkts docsQosServiceFlowRateDropPkts I do not see a reason to differentiate UGS and other SF types. In definition we can tell that MAX rate or grant rate is the reason for the drop. The same about size. I do not see a reason to change delayed packet also. Again, "especially" gives us opportunity to apply it to UGS also. The SF type will not be changed on-the-fly. What is the problem to show the same information for UGS? Regards. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 12:41 AM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Looks much better! I like it. Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 5:19 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, In thinking about it a bit more, I'd prefer to see more explicit text for the policed packets. What do you think of the following text? For the docsQosServiceFlowPolicedDropPkts description - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: owner-docsis-oss@cablelabs.com [mailto:owner-docsis-oss@cablelabs.com]On Behalf Of Margo Dolas Sent: Tuesday, 28 January, 2003 4:18 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, I agree with your simplification. The new text for the docsQosServiceFlowPolicedDropPkts description would then be - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." A similar simplification could be made to the description of docsQosServiceFlowPolicedDelayPkts. The new text would be - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 2:08 PM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I understand why I did not read this text properly then. I took the last sentence out of context. I don't think I had to stretch my imagination that much to take it out of context, it does not make any mention of UGS, and when the Maximum Sustained Traffic Rate is exceeded, the packet arrival rate does exceed the packet transmission rate. Instead of providing a series of examples for UGS flows, would it not be simpler to replace it with a statement that the parameter does not apply to UGS flows, since Max Sustained Rate is not applicable? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 1:14 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, Maximum Sustained Rate is not applicable for UGS flows (per section 8.2.7 and table 8-4 of the RFI I09 spec), so packets cannot violate the Maximum Sustained Rate for an UGS flow. In an UGS flow, you only evaluate the packet size versus the UGS grant size, and then queue the packet until you receive a grant for the flow's SID. If the queue is full (because packets are arriving faster than the grant rate), then the packet is dropped and ifOutDiscards is incremented. Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 11:17 AM To: Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I have a problem with the proposed text because I don't understand how to distinguish packets that are in violation of the Maximum Sustained rate from packets with arrival rate faster than the grant rate. What is the difference? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 4:43 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 30 07:02:50 2003 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 HAA24961 for ; Thu, 30 Jan 2003 07:02:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UCOhH26729 for ipcdn-archive@odin.ietf.org; Thu, 30 Jan 2003 07:24:43 -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 h0UCOPJ26638; Thu, 30 Jan 2003 07:24:25 -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 h0TJE9J15471 for ; Wed, 29 Jan 2003 14:14:09 -0500 Received: from util.ext.ti.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26153 for ; Wed, 29 Jan 2003 13:52:03 -0500 (EST) Received: from dlep50.itg.ti.com ([157.170.141.74]) by util.ext.ti.com (8.12.6/8.12.6) with ESMTP id h0TItUPS018307; Wed, 29 Jan 2003 12:55:31 -0600 (CST) Received: from dlep98.itg.ti.com (localhost [127.0.0.1]) by dlep50.itg.ti.com (8.12.6/8.12.6) with ESMTP id h0TItP42027098; Wed, 29 Jan 2003 12:55:25 -0600 (CST) Received: from dile70.itg.ti.com (dile70.itg.ti.com [137.167.177.22]) by dlep98.itg.ti.com (8.9.3/8.9.3) with ESMTP id MAA07582; Wed, 29 Jan 2003 12:55:23 -0600 (CST) Received: by dile70.itg.ti.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Jan 2003 20:55:22 +0200 Message-ID: <7DF2A1B372BBD611912F00508BDFBA9A9C1872@dile03.itg.ti.com> From: "Pollak, Lucy" To: "'Lejeune, Andre'" , Margo Dolas , Murwin William-LWM008 , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Wed, 29 Jan 2003 20:55:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0TJE9J15472 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit André. I do not think that to count something twice is so bad. The ifOutDiscard counter is integrated counter which shows the sum of all dropped packets on US. The docsQosServiceFlowPolicedDropPkts is per interface counter and give more detailed information. Again, I do not see a reason to change docsQosServiceFlowPolicedDropPkts definition. Thanks. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 8:43 PM To: Pollak, Lucy; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 In trying to make sure that the text was as clear as possible, I think I lost sight of the general goal, which should be to ensure that each dropped packet is counted somewhere and counted only once. We too implemented the counter to include UGS dropped packets, in particular if the rt policy is set to drop UGS packets that are too large. In reality, there are only 2 counters that count dropped packets: ifOutDiscard and docsQosServiceFlowPolicedDropPkts. So if a UGS packet needs to be dropped, where is it counted if it is not in docsQosServiceFlowPolicedDropPkts? André "does not know what he wants" L. -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, January 29, 2003 12:00 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Margo and André. I want to understand the reason for this change. I also familiar with this discussion and in the beginning understood "especially to limit the maximum rate of the flow" as "only to limit the maximum rate of the flow". But with this understanding we failed tComLabs tests. Now, I guess, most of the CMs already implemented this counter as integrated counter: Max rate + max size + grant size + grant rate dropped packets. And it seems the correct behavior, if somebody wants to compare classified packets against dropped+send. I suppose, for backward compatibility we need to leave docsQosServiceFlowPolicedDropPkts as is or even add the definition that it will count all dropped packets. In addition, I agree, we may add the set of reason's defined packet counters: docsQosServiceFlowSizeDropPkts docsQosServiceFlowRateDropPkts I do not see a reason to differentiate UGS and other SF types. In definition we can tell that MAX rate or grant rate is the reason for the drop. The same about size. I do not see a reason to change delayed packet also. Again, "especially" gives us opportunity to apply it to UGS also. The SF type will not be changed on-the-fly. What is the problem to show the same information for UGS? Regards. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 12:41 AM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Looks much better! I like it. Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 5:19 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, In thinking about it a bit more, I'd prefer to see more explicit text for the policed packets. What do you think of the following text? For the docsQosServiceFlowPolicedDropPkts description - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: owner-docsis-oss@cablelabs.com [mailto:owner-docsis-oss@cablelabs.com]On Behalf Of Margo Dolas Sent: Tuesday, 28 January, 2003 4:18 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, I agree with your simplification. The new text for the docsQosServiceFlowPolicedDropPkts description would then be - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." A similar simplification could be made to the description of docsQosServiceFlowPolicedDelayPkts. The new text would be - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 2:08 PM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I understand why I did not read this text properly then. I took the last sentence out of context. I don't think I had to stretch my imagination that much to take it out of context, it does not make any mention of UGS, and when the Maximum Sustained Traffic Rate is exceeded, the packet arrival rate does exceed the packet transmission rate. Instead of providing a series of examples for UGS flows, would it not be simpler to replace it with a statement that the parameter does not apply to UGS flows, since Max Sustained Rate is not applicable? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 1:14 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, Maximum Sustained Rate is not applicable for UGS flows (per section 8.2.7 and table 8-4 of the RFI I09 spec), so packets cannot violate the Maximum Sustained Rate for an UGS flow. In an UGS flow, you only evaluate the packet size versus the UGS grant size, and then queue the packet until you receive a grant for the flow's SID. If the queue is full (because packets are arriving faster than the grant rate), then the packet is dropped and ifOutDiscards is incremented. Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 11:17 AM To: Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I have a problem with the proposed text because I don't understand how to distinguish packets that are in violation of the Maximum Sustained rate from packets with arrival rate faster than the grant rate. What is the difference? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 4:43 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 30 07:02:51 2003 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 HAA24985 for ; Thu, 30 Jan 2003 07:02:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UCOjC26744 for ipcdn-archive@odin.ietf.org; Thu, 30 Jan 2003 07:24:45 -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 h0UCOQJ26653; Thu, 30 Jan 2003 07:24:26 -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 h0TJUjJ16183 for ; Wed, 29 Jan 2003 14:30:45 -0500 Received: from scbh01.terayon.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26560 for ; Wed, 29 Jan 2003 14:08:39 -0500 (EST) Received: by SCBH01 with Internet Mail Service (5.5.2655.55) id ; Wed, 29 Jan 2003 11:09:20 -0800 Message-ID: From: "Lejeune, Andre" To: "Pollak, Lucy" , Margo Dolas , Murwin William-LWM008 , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Wed, 29 Jan 2003 11:07:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0TJUjJ16184 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit In the case you bring up, I agree. I think this example is acceptable because one is a standard MIB and the other is Cable specific and provides more specific info. This would be a problem if we were designing it within the same MIB, which we always naturally avoid. André -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, January 29, 2003 1:55 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 André. I do not think that to count something twice is so bad. The ifOutDiscard counter is integrated counter which shows the sum of all dropped packets on US. The docsQosServiceFlowPolicedDropPkts is per interface counter and give more detailed information. Again, I do not see a reason to change docsQosServiceFlowPolicedDropPkts definition. Thanks. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 8:43 PM To: Pollak, Lucy; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 In trying to make sure that the text was as clear as possible, I think I lost sight of the general goal, which should be to ensure that each dropped packet is counted somewhere and counted only once. We too implemented the counter to include UGS dropped packets, in particular if the rt policy is set to drop UGS packets that are too large. In reality, there are only 2 counters that count dropped packets: ifOutDiscard and docsQosServiceFlowPolicedDropPkts. So if a UGS packet needs to be dropped, where is it counted if it is not in docsQosServiceFlowPolicedDropPkts? André "does not know what he wants" L. -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, January 29, 2003 12:00 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Margo and André. I want to understand the reason for this change. I also familiar with this discussion and in the beginning understood "especially to limit the maximum rate of the flow" as "only to limit the maximum rate of the flow". But with this understanding we failed tComLabs tests. Now, I guess, most of the CMs already implemented this counter as integrated counter: Max rate + max size + grant size + grant rate dropped packets. And it seems the correct behavior, if somebody wants to compare classified packets against dropped+send. I suppose, for backward compatibility we need to leave docsQosServiceFlowPolicedDropPkts as is or even add the definition that it will count all dropped packets. In addition, I agree, we may add the set of reason's defined packet counters: docsQosServiceFlowSizeDropPkts docsQosServiceFlowRateDropPkts I do not see a reason to differentiate UGS and other SF types. In definition we can tell that MAX rate or grant rate is the reason for the drop. The same about size. I do not see a reason to change delayed packet also. Again, "especially" gives us opportunity to apply it to UGS also. The SF type will not be changed on-the-fly. What is the problem to show the same information for UGS? Regards. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 12:41 AM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Looks much better! I like it. Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 5:19 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, In thinking about it a bit more, I'd prefer to see more explicit text for the policed packets. What do you think of the following text? For the docsQosServiceFlowPolicedDropPkts description - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: owner-docsis-oss@cablelabs.com [mailto:owner-docsis-oss@cablelabs.com]On Behalf Of Margo Dolas Sent: Tuesday, 28 January, 2003 4:18 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, I agree with your simplification. The new text for the docsQosServiceFlowPolicedDropPkts description would then be - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." A similar simplification could be made to the description of docsQosServiceFlowPolicedDelayPkts. The new text would be - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 2:08 PM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I understand why I did not read this text properly then. I took the last sentence out of context. I don't think I had to stretch my imagination that much to take it out of context, it does not make any mention of UGS, and when the Maximum Sustained Traffic Rate is exceeded, the packet arrival rate does exceed the packet transmission rate. Instead of providing a series of examples for UGS flows, would it not be simpler to replace it with a statement that the parameter does not apply to UGS flows, since Max Sustained Rate is not applicable? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 1:14 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, Maximum Sustained Rate is not applicable for UGS flows (per section 8.2.7 and table 8-4 of the RFI I09 spec), so packets cannot violate the Maximum Sustained Rate for an UGS flow. In an UGS flow, you only evaluate the packet size versus the UGS grant size, and then queue the packet until you receive a grant for the flow's SID. If the queue is full (because packets are arriving faster than the grant rate), then the packet is dropped and ifOutDiscards is incremented. Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 11:17 AM To: Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I have a problem with the proposed text because I don't understand how to distinguish packets that are in violation of the Maximum Sustained rate from packets with arrival rate faster than the grant rate. What is the difference? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 4:43 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 30 07:02:55 2003 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 HAA25001 for ; Thu, 30 Jan 2003 07:02:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UCOnH26762 for ipcdn-archive@odin.ietf.org; Thu, 30 Jan 2003 07:24:49 -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 h0UCOQJ26668; Thu, 30 Jan 2003 07:24:26 -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 h0UAJXJ19469 for ; Thu, 30 Jan 2003 05:19:33 -0500 Received: from dragon.ti.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23336 for ; Thu, 30 Jan 2003 04:57:08 -0500 (EST) Received: from dlep51.itg.ti.com ([157.170.141.75]) by dragon.ti.com (8.12.6/8.12.6) with ESMTP id h0UA0cFG018419; Thu, 30 Jan 2003 04:00:38 -0600 (CST) Received: from dlep98.itg.ti.com (localhost [127.0.0.1]) by dlep51.itg.ti.com (8.12.6/8.12.6) with ESMTP id h0UA0bDN013165; Thu, 30 Jan 2003 04:00:37 -0600 (CST) Received: from dile70.itg.ti.com (dile70.itg.ti.com [137.167.177.22]) by dlep98.itg.ti.com (8.9.3/8.9.3) with ESMTP id EAA27644; Thu, 30 Jan 2003 04:00:35 -0600 (CST) Received: by dile70.itg.ti.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Jan 2003 12:00:35 +0200 Message-ID: <7DF2A1B372BBD611912F00508BDFBA9A9C1874@dile03.itg.ti.com> From: "Pollak, Lucy" To: "'Margo Dolas'" , "'Lejeune, Andre'" , Murwin William-LWM008 , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Thu, 30 Jan 2003 12:00:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UAJXJ19471 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Margo, I also do not see a problem if USG and best effort will share the same counter. What do you think about size dropped? I guess, all dropped should be counted together. Do you want to add different detailed counters for size and rate dropped? Personally, I think that existed counter is good enough. I agree, that description should be clarified. William, would you like to propose new text for docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts counters? Regards. Lucy -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Wednesday, January 29, 2003 9:36 PM To: Pollak, Lucy; 'Lejeune, Andre'; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre and Lucy, I believe that the test failures occurred because the spec was unclear in the past. The original understanding was that the docsQosServiceFlowPolicedDropPkts counter include only packets dropped in violation of the Max(T) equation. However, with failures at tComLabs dues to lack of clarity in the spec, many vendors coded to the test. I thought that adding a new counter to count UGS packets dropped because the packet exceeds the UGS grant would add an appropriate place to count these dropped packets. However, having said this, my objective is clarity in the descriptions. If the consensus is to count the dropped UGS packets in the docsQosServiceFlowPolicedDropPkts counter, the description should be changed to explicitly state this. Regards, Margo -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, 29 January, 2003 1:55 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 André. I do not think that to count something twice is so bad. The ifOutDiscard counter is integrated counter which shows the sum of all dropped packets on US. The docsQosServiceFlowPolicedDropPkts is per interface counter and give more detailed information. Again, I do not see a reason to change docsQosServiceFlowPolicedDropPkts definition. Thanks. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 8:43 PM To: Pollak, Lucy; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 In trying to make sure that the text was as clear as possible, I think I lost sight of the general goal, which should be to ensure that each dropped packet is counted somewhere and counted only once. We too implemented the counter to include UGS dropped packets, in particular if the rt policy is set to drop UGS packets that are too large. In reality, there are only 2 counters that count dropped packets: ifOutDiscard and docsQosServiceFlowPolicedDropPkts. So if a UGS packet needs to be dropped, where is it counted if it is not in docsQosServiceFlowPolicedDropPkts? André "does not know what he wants" L. -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, January 29, 2003 12:00 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Margo and André. I want to understand the reason for this change. I also familiar with this discussion and in the beginning understood "especially to limit the maximum rate of the flow" as "only to limit the maximum rate of the flow". But with this understanding we failed tComLabs tests. Now, I guess, most of the CMs already implemented this counter as integrated counter: Max rate + max size + grant size + grant rate dropped packets. And it seems the correct behavior, if somebody wants to compare classified packets against dropped+send. I suppose, for backward compatibility we need to leave docsQosServiceFlowPolicedDropPkts as is or even add the definition that it will count all dropped packets. In addition, I agree, we may add the set of reason's defined packet counters: docsQosServiceFlowSizeDropPkts docsQosServiceFlowRateDropPkts I do not see a reason to differentiate UGS and other SF types. In definition we can tell that MAX rate or grant rate is the reason for the drop. The same about size. I do not see a reason to change delayed packet also. Again, "especially" gives us opportunity to apply it to UGS also. The SF type will not be changed on-the-fly. What is the problem to show the same information for UGS? Regards. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 12:41 AM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Looks much better! I like it. Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 5:19 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, In thinking about it a bit more, I'd prefer to see more explicit text for the policed packets. What do you think of the following text? For the docsQosServiceFlowPolicedDropPkts description - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: owner-docsis-oss@cablelabs.com [mailto:owner-docsis-oss@cablelabs.com]On Behalf Of Margo Dolas Sent: Tuesday, 28 January, 2003 4:18 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, I agree with your simplification. The new text for the docsQosServiceFlowPolicedDropPkts description would then be - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." A similar simplification could be made to the description of docsQosServiceFlowPolicedDelayPkts. The new text would be - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 2:08 PM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I understand why I did not read this text properly then. I took the last sentence out of context. I don't think I had to stretch my imagination that much to take it out of context, it does not make any mention of UGS, and when the Maximum Sustained Traffic Rate is exceeded, the packet arrival rate does exceed the packet transmission rate. Instead of providing a series of examples for UGS flows, would it not be simpler to replace it with a statement that the parameter does not apply to UGS flows, since Max Sustained Rate is not applicable? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 1:14 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, Maximum Sustained Rate is not applicable for UGS flows (per section 8.2.7 and table 8-4 of the RFI I09 spec), so packets cannot violate the Maximum Sustained Rate for an UGS flow. In an UGS flow, you only evaluate the packet size versus the UGS grant size, and then queue the packet until you receive a grant for the flow's SID. If the queue is full (because packets are arriving faster than the grant rate), then the packet is dropped and ifOutDiscards is incremented. Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 11:17 AM To: Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I have a problem with the proposed text because I don't understand how to distinguish packets that are in violation of the Maximum Sustained rate from packets with arrival rate faster than the grant rate. What is the difference? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 4:43 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 30 09:38:32 2003 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 JAA29717 for ; Thu, 30 Jan 2003 09:38:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UF0Uo25419 for ipcdn-archive@odin.ietf.org; Thu, 30 Jan 2003 10:00:30 -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 h0UF0DJ25258; Thu, 30 Jan 2003 10:00:13 -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 h0UF00J25097 for ; Thu, 30 Jan 2003 10:00:00 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29678 for ; Thu, 30 Jan 2003 09:37:27 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id h0UEeswH015604; Thu, 30 Jan 2003 07:40:55 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 30 Jan 2003 07:40:54 -0700 Message-ID: Thread-Topic: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Thread-Index: AcLH548y4kEBqgPST/axiKsO4ibNMgAAHKEA From: "Eduardo Cardona" To: "Nakanishi Greg-MGI8179" , "Woundy, Richard" Cc: "IPCDN WG (E-mail)" , "DOCSIS OSS Majordomo List" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UF00J25098 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Greg, I agree with you that v3 noAuthNoPriv is in fact open access whatever is made to try to secure the MSO SNMP access-level in other flavors of SNMP. As I understand the v3 Auth management will take some time to happen mainly to reconvert all MSO business and operation processes around that. The fact is that NmAccess v1, v2c works and very well. In standard Network environments v1, v2c may be insecure but in a DOCSIS network is secure enough (BPI and MSO NMS firewalls around its private network). Two things: A) CM Filters not clear in how to handle snmp traffic directed to CM IP, B) "smart" CMs is valid but is not generalized across the implementations: One of the reasons for Diagnostic IP (after registration) was to not having to know the CM DHCP IP. Also was brought up that many CMs are not "smart" so the traffic was in any case lost due the MSO in place gateway UDP/TCP port policy filter in the return/forward path. If there is no convergence in what is the required behavior, and all kind of combinations can happen, no efforts in try to find work arounds to simulate the vacm Ext interface will conduct to something practical. We need to know if Coexistence v1, v2c at MSO access-level is needed, otherwise we have to preclude RFC2576 or state in the spec the trivial monitoring scope as you said to help MSOs to have a clear migration path. Or leave (Rich may have more clues for this) the deprecated NmAccess (CABLE-DEVICE-MIB) as the main core management at the operational level. Eduardo -----Original Message----- From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] Sent: Wednesday, January 29, 2003 3:41 PM To: Eduardo Cardona; Woundy, Richard Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... Eduardo, How much of an issue is this? This issue exists today independent of SNMP. Has there been any operational problems caused because of this? This issue is orthogonal to the SNMP access control. Seems to me that the proper SNMPv3 access control should be the preferred method for restricting access to important information. If noAuthnoPriv or the Community table is used, then it should be OK for anyone to access the information, otherwise setup the proper keys for secure access. IMO, you don't want to force the CM to have to forward the packet upstream, just to have it returned by the CMTS. This just wastes bandwidth. Granted that as a dumb bridge this is what would happen. However, the CM could be smart about it and turn it around internally. greg > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: Wednesday, January 29, 2003 1:36 PM > To: Woundy, Richard; Nakanishi Greg-MGI8179 > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Rich, That's right. > > v3 noAuthNoPriv, is exactly what you say, MSOs should not have more > than minimal access to users (any : internal, customers) at that level > > Coexistence v1, v2c is almost what you said, with a little bit of > extra protection > > MSO can use the TMAsk from RFC2576 to allow only some IP/subnets mask > associated with a community string ( indicated in the config file). > > 1) If a CM forward the SNMP CPE to CM IP traffic through the RF there > is no problem, traffic goes away > 2) If the CM does not forward the SNMP traffic, a User may be able to > spoof the NMS ip and get access to operator-level by gessing or > capturing the CM community string from config file of sniffing the RF > somw how. > > Diagnostic IP forces the CPE to be in 192.168.100.x, solve the problem > only if CM forced to be in the same subnet ( limited view associated > with that) > > One solution I see for 2) is to force the CM to not respond directly > to SNMP from CPE and forward the packet to RF wich means only with > Diagnostic IP a CPE user can talk to the CM directly. > > If CMs are no longer dumm bridges -case 1)-, IP applications on to of > the CM may create a relaxed packet handling for arbitrary configured > IPs in the CPEs > > > Eduardo > > > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Wednesday, January 29, 2003 10:37 AM > To: Eduardo Cardona; Nakanishi Greg-MGI8179 > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > I guess the biggest problem is when we don't use SNMPv3 > authentication, and when we don't use the docsDevNmAccessTable (e.g. > with docsDevNmAccessInterfaces restricting access from the CMCI) > -- e.g. SNMP > Coexistence. > > In the case of SNMP Coexistence, the only thing that stops end-users > from operator-level SNMP access is knowledge of the community string, > which is probably exposed as a plain-text ASCII string in the DOCSIS > config files on the TFTP servers. > > Am I misinformed? > > -- Rich > > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: Wednesday, January 29, 2003 9:02 AM > To: Nakanishi Greg-MGI8179; Woundy, Richard > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Greg, Rich, > > > Sorry if I wasn't clear. > > I am fine with all the comments about spoofing and subnets isolation > mechanisms. > > The case I am presenting ( not spoofing other CM's Ips) > > It is the case of a user spoofing an NMS IP address with the solely > purpose of getting access to the SNMP entity of its own CM ( not > traffic intervention in the RF), ( simulating the NMS network in the > CPE side), > then the subnet Mask mechanism for Coesistence v1 v2c may > failed in the > case of a CM that reply to SNMP request from CPEs ( CM > believes that the > request is from a valid subnet, user still needs to guess the > comminity > string) > > In the case of v3 noAuthNoPriv as soon as is defined such view it > becomes a CPE user view ( no interface/subnet filtering). MSO can't > have an username for CPE and think in another user ( more > privileges/access) > for exclusive MSO administration. > > > > > The point I am trying to get into is as more routing/ip aware stuff is > placed in the CMs: > > Just guessing: > > A common behavior of a CPE SNMP request directed to CM DHCP IP is > forwarding to RF US and bounce back to CM side due the bridge nature > of the implementation. > > That may stop happening since some CMs failed to filter SNMP traffic > based on interfaces since the CPE traffic appear as RF traffic ( > bounded > back) > > What some inmplementations may did was to start listening to SNMP to > CM DHCP IP and apply the NmAccess interface filter, > > If that's the case a CM will recognize a CM IP in ( > > > -----Original Message----- > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > Sent: Tuesday, January 28, 2003 6:36 PM > To: Eduardo Cardona; Woundy, Richard > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > Eduardo, > > The original use case given was the ability for the CPE to access it's > own CM via SNMP, but not be able to access someone else's CM through > the RF interface. I'm assuming it OK for MSO staff to access the CM. > > Allowing access to local CM -- > To allow the CPE to access it's own CM, all that is required is a VACM > entry with noAuthnoPriv to allow access to a restricted set of MIB > objects. In this case, from a security point of view, it shouldn't > matter which IP address the SNMP request is sent to. The VACM table > will determine if access is allowed regardless of the IP address used. > > Preventing access to someone else's CM -- > This is supported by restricting the routing of packets between the > public and private networks. As we've been discussing, it appears > there are a few methods in which this can be done. > > MSO staff to access the CM -- > If the SNMP request is generated from within the private network (e.g. > MSO's NMS)then the access to the CM will be determined by the VACM > table. > > Does this address your concern? > > greg > > > > > -----Original Message----- > > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > > Sent: Tuesday, January 28, 2003 5:05 PM > > To: Nakanishi Greg-MGI8179; Woundy, Richard > > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > Greg, > > > > The IP spaces is fine as soon as the user does not try to > spoof an NMS > > > IP (where NmAccess beats SNMP by supporting interfaces for the non > > authenticated communication) > > > > Q1: > > Does ALL CMs forward (theoretically yes because are bridges) to RFI > > all ( no ICMP) traffic (including CM DHCP IP) but "diagnostic IP > > destination? > > > > If YES Greg's scenario follows the MSO normal filtering > conditions ( > > i.e UDP/TCP port fitering between subnets) > > > > If NO > > > > The case I am mentioning is a user spoofing an NMS IP (matches Ip > > subnet) and contacting the CH DHCP IP and then, the CM processes > > packet without forwarding it to the network, replying back to the > > user. > > > > To avoid the vacmExt, if the answer is 'NO', I think the > below rules > > may aliviate some problems: > > > > Flow type Destination > > 1) CPE -> CM SNMP "Diagnostic IP" YES > > 2) CPE -> CM SNMP CM DHCP IP NO -Q1- > > 3) CPE -> CM ICMP "Diagnostic IP" YES > > 4) CPE -> CM ICMP CM DHCP IP YES > > 5) CPE -> CM Other IP both NO ( some > cases YES as > > top services run in CM stack like HTTP) > > > > Req 2) seems to be the problem for the Interface requirement. What > > makes is: Address Q1 in Coexistence v1, v2c > > V3 noAuthNoPriv if configured, (nothing to do) : same access > > level both > > NMS and CPE users ( limited view recommended) > > > > Eduardo > > > > -----Original Message----- > > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > > Sent: Tuesday, January 28, 2003 5:22 PM > > To: 'Woundy, Richard'; Eduardo Cardona > > Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > That could be one implementation. > > > > Another possibility is it could be done through IP > forwarding tables. > > Conceptually, the CMTS HFC interface is connected to two networks - > > one public and one private. When a packet is received on the public > > interface (i.e. from the CPE) that is addressed to the private > > network, the forwarding table would not have a route for it and > > discards the packet. > > > > Although I don't know the CMTS implementation specifics, my > > understanding is that the described behavior is the way most MSOs > > operate their network. i.e. CPE cannot communicate with someone > > else's CM. > > > > greg > > > > > -----Original Message----- > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > Sent: Tuesday, January 28, 2003 4:12 PM > > > To: 'Nakanishi Greg-MGI8179'; 'Eduardo Cardona' > > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > You're assuming that the CMTS implements the Subscriber Management > > > MIB, and has docsSubMgtPktFilterTable configured to prevent the > > > forwarding of subscriber CPE traffic to the private net > CMs, right? > > > > > > -- Rich > > > > > > -----Original Message----- > > > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > > > Sent: Tuesday, January 28, 2003 7:03 PM > > > To: Woundy, Richard; 'Eduardo Cardona' > > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > I agree that the application of ipFilters to packets addressed to > > > the CM is not very clear in the spec. This topic comes > up every now > > > and then on the > > > reflector. I believe the generally accepted interpretation is > > > that traffic addressed to the CM is NOT filtered. > > > > > > The workaround that I proposed does not rely on the use of IP > > > filters. It just relies on the the partitioning of the > private IP > > > > network that the CM is > > > part of and the public IP network that the CPE is part of. > > > Typically, the CMTS will not route between these networks. > > > > > > A user can access through SNMP his/her own CM through the > diagnostic > > > > IP address; however, a user cannot access someone elses CM. The > > > packets from the user's CPE on the public network will > not be routed > > > > by the CMTS to the > > > private network on which someone else's CM resides. > > > > > > greg > > > > > > > -----Original Message----- > > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > > Sent: Tuesday, January 28, 2003 3:27 PM > > > > To: 'Eduardo Cardona'; Nakanishi Greg-MGI8179 > > > > Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail) > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > > > > I wonder whether current CM vendors typically check the > > > > docsDevFilterIpTable before they process a > locally-addressed SNMP > > > > PDU. > > > > > > > > Anyone know? > > > > > > > > -- Rich > > > > > > > > -----Original Message----- > > > > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > > > > Sent: Tuesday, January 28, 2003 4:53 PM > > > > To: Woundy, Richard; Nakanishi Greg-MGI8179 > > > > Cc: IPCDN WG (E-mail) > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > > > > I forgot to mention something, > > > > > > > > 3.3.2.2. SNMPv3 Interface via vacm extension to be removed > > > > > > > > Going back to Greg's comments? > > > > > > > > Is the filtering flow in 3.3 accurated enough to solve that in > > > > terms of this filter schems? > > > > > > > > Seems that SNMP traffic (Section 3.3) is not > intuitively "forced" > > > > to go to the ip filters (which after removing vacmExt will be > > > mere NmAccess > > > > Mode) before hitting the agent. ( I mean the NmAccess text from > > > > rfc2669 is distracting ?) > > > > > > > > I've seen people with different interpretations of how to > > > "implement" > > > > the filters based on directed to CM traffic or CM > > forwarded traffic > > > > It may create confusion that as the diagram is following > > > the Stack for > > > > the RF-CPE or CPE-RF traffic the RF-CM CPE-CM trattic is > > > not properly > > > > represented : I add a little box of possible interpretation that > > > > should be clarified. > > > > > > > > > > > > > > > > ***************** > > > > * LLC Filter In * > > > > ***************** > > > > | > > > > v > > > > ******************* > > > > * Special Filters * > > > > * | * > > > > * V * > > > > * ************ * > > > > * * IP Spoof * * > > > > * ************ * > > > > * | * > > > > * v * > > > > > > > > * *************** * > > > > * * SNMP Access * * > > > > * *************** * > > > > * | * > > > > ******************* > > > > | ------> Wrong : SNMP to > > > > CM traffic > > > > processing > > > > v > > > > **************** > > > > * IP Filter In * > > > > **************** > > > > | -------> Rigth: SNMP to > > > > CM traffic > > > > processing > > > > v > > > > ***************** > > > > * IP Filter Out * > > > > ***************** > > > > | > > > > v > > > > ****************** > > > > * LLC Filter Out * > > > > ****************** > > > > > > > > -----Original Message----- > > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > > Sent: Tuesday, January 28, 2003 12:58 PM > > > > To: Nakanishi Greg-MGI8179; Eduardo Cardona > > > > Cc: IPCDN WG (E-mail) > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > > > > Eduardo, > > > > > > > > I am sympathetic to Greg and Kevin's argument that perhaps the > > > > docsDevVacmAccessExtTable extension to VACM should be > > > deleted from the > > > > Cable Device MIB, for three reasons: > > > > > > > > 1. Greg seems to have proposed a workaround for the use case I > > > > proposed. Restating, the DOCSIS configuration file could set up > > > > the docsDevFilterIpTable to reject UDP/SNMP traffic arriving on > > > the RF/HFC > > > > interface from any IP subnets other than the MSOs > > management station > > > > > > subnets. This sounds like reasonable security practice in > > any case, > > > > i.e. don't just rely on SNMPv3 authentication. It enables > > subscriber > > > > > > CM management from the CMCI side, but not > subscriber/random user > > > > access from the RF/HFC side, per my use case. 2. I agree > > it would be > > > > > > much easier for vendors if they could leverage standard > > SNMP agent > > > > stack implementations as much as possible. The extension for > > > > DOCSIS-only devices makes this objective more difficult. > > 3. There is > > > > > > also a possibility that the IETF MIB doctor might frown on a > > > DOCSIS-specific > > > > extension to the VACM MIB. > > > > > > > > Does anyone disagree? Shall I make this deletion? > > > > > > > > Are there any other comments on the current Cable Device MIB > > > > -- which is > > > > now posted on the IETF reflector, > > > > > > > bv2-04.txt > > > > >? > > > > > > > > -- Rich > > > > > > > > -----Original Message----- > > > > From: Eduardo Cardona [mailto:e.cardona@cablelabs.com] > > > > Sent: Tuesday, January 28, 2003 1:51 PM > > > > To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail) > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > > > > Kevin, Greg, > > > > > > > > Following your thoughts. I think I got more findings that > > need to be > > > > > > addressed in any case. The vacmAccess Interface requirements is > > > > being as a > > > proposal since the > > > > early versions of this draft. > > > > > > > > We know your concerns and they are also related to different > > > > discussion in the reflector (i.e. controlling the number of > > > traps/notification by > > > > touching the Notification Originator subsystem in the > > SNMP entity ) > > > > > > > > In this case the difficulty is to modify the Access Control > > > > Subsystem in the SNMP entity, to being able to add the interface > > scheme, which is > > > > perfectly valid under RFC2571/3411 architecture and AUGMENT > > > clause in > > > > RFC2578 > > > > > > > > > > > > We need more thoughs in the SNMP constrains we are trying > > to achieve > > > > > > with the full coverage of MSO needs. > > > > > > > > The need is there: > > > > > > > > what the SNMP stack providers may solve? (Greg concerns of > > > available > > > > tools/design framework) Will be Feasible or agree in certain > > > > MSO/management constrains? ( few options below) Is the > > SNMPv3 group > > > > > > addressing this case or had ever think about this as a standard > > > > mechanism? Will that be clearly extended for embedded > cases with > > > > logical interfaces instead of physical ones ( to avoid security > > > > holes ? > > > > > > > > > > > > Typical case: > > > > > > > > "Many" (how many is many?) CMs used to bridge the > traffic (SNMP) > > > > directed to the CM DHCP IP from the CPE through the RF > interface > > > > Upstream. > > > > > > > > For blocking traffic: > > > > These is trivial since MSO is able to place SNMP filters in the > > > > CMTS/backbone For getting CPE traffic: Could be > cumbersome in the > > > > > presence of SNMP filters in the gateway or a > > > > CM unable to register. In the other hand the > > > > MSO/technician/User, must know the CM IP that could be a problem > > > > or not desired always. > > > > > > > > That one was partially solved with the well known IP > 192.168.100.1 > > > > > > > > What is still a MSO constrain: > > > > CMs able to talk to the SNMP stack from any CPE subnet > ( spoof NMS > > > > > IP ) ( 1 hop) and use the v1, v2c vacmAccess constrains for > > full access. > > > > > > > > Also v3 noAuthNoPriv does not support the subletting as RFC 2576 > > > > defined for coexistence v1 v2c and there is where Rich's case > > > > applied for granting or blocking access. > > > > > > > > If we agree the well know IP is the "only" way to talk to > > > the CM for a > > > > CPE with one hop ( CPE to CM DHCP IP queries forwarded > > > through RF ) we > > > > are OK and the vacm requirement may not needed, but some > > > > clarifications are needed in the spec. It creates the need to > > > > reconfigure the user CPE any time that a user may need to talk > > > > to the CM. > > > > > > > > > > > > With current requirements in either case: > > > > In the SNMP framework snmpv3 noAuthNoPRiv the access will > > > be the same > > > > for MSO and user Access. > > > > > > > > With the Interface scheme an MSO will be able to set two > > > different v3 > > > > users noAuthNoPriv with different access. > > > > > > > > If not the case we still have the issue of blocking NMS spoofed > > > > Ips) and the vacmAccessInterface is a way to block > that. Or define > > > > > the ip forward > > > > mechanism better. > > > > > > > > Eduardo > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > > > > Sent: Tuesday, January 28, 2003 10:43 AM > > > > To: 'IPCDN WG (E-mail)' > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB... > > > > > > > > > > > > Kevin, I think your point is accurate. > > > > > > > > Just to expand upon it some... > > > > > > > > Typically a CM will get a private IP address via DHCP. This > > > > results in access to the CM through the HFC interface being > > > > limited to > > > within the > > > > MSO's private IP network. "Outsiders" (e.g. user's on the > > > > CMCI-side or on the Internet) will not be able to access a CM > > > > through the HFC interface. Access to the CM from the CMCI > > > > interface is still allowed if the proper SNMP access controls > > > > are setup. > > > > > > > > I want to make sure that this proposed extension to the > > VACM table > > > > provides a good benefit over what is acheivable today with the > > > > mechanisms we already have. > > > > > > > > greg > > > > > > > > > -----Original Message----- > > > > > From: Marez Kevin-MGI1375 > > > > > Sent: Tuesday, January 28, 2003 9:10 AM > > > > > To: 'Woundy, Richard'; Nakanishi Greg-MGI8179 > > > > > Cc: IPCDN WG (E-mail) > > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE > DEVICE MIB... > > > > > > > > > > > > > > > Rich, > > > > > > > > > > I understand the scenario you have presented, however, I > > > think MSOs > > > > > would typically use a private networking space for the > > > RF-side and > > > > > explicitly prevent access from outside that space. > > > > > > > > > > Our concern here is that we are adding an additional level of > > > > > complexity to the vacmAccess table that doesn't provide a > > > > great deal > > > > > of benefit. > > > > > > > > > > Greg, please respond I have misstated anything or if you > > > > have anything > > > > > > > > > you'd like to add. Thanks very much, > > > > > > > > > > Kevin > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Woundy, Richard > [mailto:Richard_Woundy@cable.comcast.com] > > > > > Sent: Wednesday, January 22, 2003 3:59 PM > > > > > To: 'Marez Kevin-MGI1375' > > > > > Cc: IPCDN WG (E-mail) > > > > > Subject: RE: [ipcdn] Comments on draft-03 of CABLE > DEVICE MIB... > > > > > > > > > > > > > > > Kevin, > > > > > > > > > > Here is my comment on the VACM issue: > > > > > > > > > > >10) docsDevVacmAccessExtTable - Is this table really needed > > > > > when using > > > > > >SNMPv3? The limited security provided in SNMPv1/2 > > > > > necessitated having > > > > > >this functionality in the nmAccessTable. Given SNMPv3 > > > > security, it > > > > > >doesn't seem like this functionality is necessary anymore. > > > > > > > > > > I would agree that it is better security to authenticate a > > > > keyed hash > > > > > via SNMPv3, than to rely on the incoming device interface > > > > for implied > > > > > user identification. > > > > > > > > > > However, one interesting and important case is a CM diagnostic > > > > > interface for subscriber-side queries, after the CM > > registration > > > > > process is completed. It > > > > > seems quite useful to allow subscriber tools (with SNMPv3 > > > > > securityLevel of > > > > > noAuthNoPriv) to query cable modems over the CMCI (CPE > > > > > interface) but not > > > > > over the RFI (RF interface). > > > > > > > > > > -- Rich > > > > > > > > > _______________________________________________ > > > > IPCDN mailing list > > > > IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn > > > > _______________________________________________ > > > > IPCDN mailing list > > > > IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 30 09:48:24 2003 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 JAA00042 for ; Thu, 30 Jan 2003 09:48:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UFAME30480 for ipcdn-archive@odin.ietf.org; Thu, 30 Jan 2003 10:10:22 -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 h0UFA4J30317; Thu, 30 Jan 2003 10:10:04 -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 h0UF9BJ29922 for ; Thu, 30 Jan 2003 10:09:11 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29970 for ; Thu, 30 Jan 2003 09:46:40 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h0UEmrrs016425 for ; Thu, 30 Jan 2003 07:48:53 -0700 (MST) Received: [from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id HAA27778 for ; Thu, 30 Jan 2003 07:50:12 -0700 (MST)] Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59) id ; Thu, 30 Jan 2003 09:49:22 -0500 Message-ID: <19CD0E423FC1D611893500508B6F0B9C084964@ma07exm01.dma.isg.mot.com> From: Murwin William-LWM008 To: "'Pollak, Lucy'" , "'Margo Dolas'" , "'Lejeune, Andre'" , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Thu, 30 Jan 2003 09:49:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UF9CJ29923 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Here is the propose text: docsQosServiceFlowPolicedDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object counts packets dropped because because the packet exceeds the UGS grant size." ::= { docsQosServiceFlowStatsEntry 6 } docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not count packets queued awaiting grants." ::= { docsQosServiceFlowStatsEntry 7 } There will be no new object! Please respond ASAP as the MIB gets posted today! Will Murwin -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Thursday, January 30, 2003 5:01 AM To: 'Margo Dolas'; 'Lejeune, Andre'; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Margo, I also do not see a problem if USG and best effort will share the same counter. What do you think about size dropped? I guess, all dropped should be counted together. Do you want to add different detailed counters for size and rate dropped? Personally, I think that existed counter is good enough. I agree, that description should be clarified. William, would you like to propose new text for docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts counters? Regards. Lucy -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Wednesday, January 29, 2003 9:36 PM To: Pollak, Lucy; 'Lejeune, Andre'; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre and Lucy, I believe that the test failures occurred because the spec was unclear in the past. The original understanding was that the docsQosServiceFlowPolicedDropPkts counter include only packets dropped in violation of the Max(T) equation. However, with failures at tComLabs dues to lack of clarity in the spec, many vendors coded to the test. I thought that adding a new counter to count UGS packets dropped because the packet exceeds the UGS grant would add an appropriate place to count these dropped packets. However, having said this, my objective is clarity in the descriptions. If the consensus is to count the dropped UGS packets in the docsQosServiceFlowPolicedDropPkts counter, the description should be changed to explicitly state this. Regards, Margo -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, 29 January, 2003 1:55 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 André. I do not think that to count something twice is so bad. The ifOutDiscard counter is integrated counter which shows the sum of all dropped packets on US. The docsQosServiceFlowPolicedDropPkts is per interface counter and give more detailed information. Again, I do not see a reason to change docsQosServiceFlowPolicedDropPkts definition. Thanks. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 8:43 PM To: Pollak, Lucy; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 In trying to make sure that the text was as clear as possible, I think I lost sight of the general goal, which should be to ensure that each dropped packet is counted somewhere and counted only once. We too implemented the counter to include UGS dropped packets, in particular if the rt policy is set to drop UGS packets that are too large. In reality, there are only 2 counters that count dropped packets: ifOutDiscard and docsQosServiceFlowPolicedDropPkts. So if a UGS packet needs to be dropped, where is it counted if it is not in docsQosServiceFlowPolicedDropPkts? André "does not know what he wants" L. -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, January 29, 2003 12:00 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Margo and André. I want to understand the reason for this change. I also familiar with this discussion and in the beginning understood "especially to limit the maximum rate of the flow" as "only to limit the maximum rate of the flow". But with this understanding we failed tComLabs tests. Now, I guess, most of the CMs already implemented this counter as integrated counter: Max rate + max size + grant size + grant rate dropped packets. And it seems the correct behavior, if somebody wants to compare classified packets against dropped+send. I suppose, for backward compatibility we need to leave docsQosServiceFlowPolicedDropPkts as is or even add the definition that it will count all dropped packets. In addition, I agree, we may add the set of reason's defined packet counters: docsQosServiceFlowSizeDropPkts docsQosServiceFlowRateDropPkts I do not see a reason to differentiate UGS and other SF types. In definition we can tell that MAX rate or grant rate is the reason for the drop. The same about size. I do not see a reason to change delayed packet also. Again, "especially" gives us opportunity to apply it to UGS also. The SF type will not be changed on-the-fly. What is the problem to show the same information for UGS? Regards. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 12:41 AM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Looks much better! I like it. Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 5:19 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, In thinking about it a bit more, I'd prefer to see more explicit text for the policed packets. What do you think of the following text? For the docsQosServiceFlowPolicedDropPkts description - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: owner-docsis-oss@cablelabs.com [mailto:owner-docsis-oss@cablelabs.com]On Behalf Of Margo Dolas Sent: Tuesday, 28 January, 2003 4:18 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, I agree with your simplification. The new text for the docsQosServiceFlowPolicedDropPkts description would then be - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." A similar simplification could be made to the description of docsQosServiceFlowPolicedDelayPkts. The new text would be - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 2:08 PM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I understand why I did not read this text properly then. I took the last sentence out of context. I don't think I had to stretch my imagination that much to take it out of context, it does not make any mention of UGS, and when the Maximum Sustained Traffic Rate is exceeded, the packet arrival rate does exceed the packet transmission rate. Instead of providing a series of examples for UGS flows, would it not be simpler to replace it with a statement that the parameter does not apply to UGS flows, since Max Sustained Rate is not applicable? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 1:14 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, Maximum Sustained Rate is not applicable for UGS flows (per section 8.2.7 and table 8-4 of the RFI I09 spec), so packets cannot violate the Maximum Sustained Rate for an UGS flow. In an UGS flow, you only evaluate the packet size versus the UGS grant size, and then queue the packet until you receive a grant for the flow's SID. If the queue is full (because packets are arriving faster than the grant rate), then the packet is dropped and ifOutDiscards is incremented. Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 11:17 AM To: Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I have a problem with the proposed text because I don't understand how to distinguish packets that are in violation of the Maximum Sustained rate from packets with arrival rate faster than the grant rate. What is the difference? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 4:43 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 30 11:51:50 2003 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 LAA04006 for ; Thu, 30 Jan 2003 11:51:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UGsux14254 for ipcdn-archive@odin.ietf.org; Thu, 30 Jan 2003 11:54:56 -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 h0UGsVJ14219; Thu, 30 Jan 2003 11:54:31 -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 h0UGrgJ14194 for ; Thu, 30 Jan 2003 11:53:42 -0500 Received: from mms3.broadcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03968 for ; Thu, 30 Jan 2003 11:50:03 -0500 (EST) Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom MMS1 SMTP Relay (MMS v5.5.0)); Thu, 30 Jan 2003 08:53:36 -0700 Received: from ltatlamdolas (dhcp-10-24-65-44.atlanta.broadcom.com [10.24.65.44]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with SMTP id IAA27080; Thu, 30 Jan 2003 08:53:25 -0800 (PST) From: "Margo Dolas" To: "Murwin William-LWM008" , "'Pollak, Lucy'" , "'Lejeune, Andre'" , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Thu, 30 Jan 2003 11:53:25 -0500 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <19CD0E423FC1D611893500508B6F0B9C084964@ma07exm01.dma.isg.mot.com> X-MIME-Autoconverted: from 8bit to quoted-printable by mon-irva-11.broadcom.com id IAA27080 X-WSS-ID: 1227871A336865-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UGrgJ14195 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit William, I think that the description for docsQosServiceFlowPolicedDelayPkts looks good. What do you think of changing the description of docsQosServiceFlowPolicedDropPkts to read - "This object counts packets dropped in violation of the Maximum Sustained Traffic Rate. For UGS flows, this object counts packets dropped because the packet exceeds the UGS grant size." Regards, Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Thursday, 30 January, 2003 9:49 AM To: 'Pollak, Lucy'; 'Margo Dolas'; 'Lejeune, Andre'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Here is the propose text: docsQosServiceFlowPolicedDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object counts packets dropped because because the packet exceeds the UGS grant size." ::= { docsQosServiceFlowStatsEntry 6 } docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not count packets queued awaiting grants." ::= { docsQosServiceFlowStatsEntry 7 } There will be no new object! Please respond ASAP as the MIB gets posted today! Will Murwin -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Thursday, January 30, 2003 5:01 AM To: 'Margo Dolas'; 'Lejeune, Andre'; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Margo, I also do not see a problem if USG and best effort will share the same counter. What do you think about size dropped? I guess, all dropped should be counted together. Do you want to add different detailed counters for size and rate dropped? Personally, I think that existed counter is good enough. I agree, that description should be clarified. William, would you like to propose new text for docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts counters? Regards. Lucy -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Wednesday, January 29, 2003 9:36 PM To: Pollak, Lucy; 'Lejeune, Andre'; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre and Lucy, I believe that the test failures occurred because the spec was unclear in the past. The original understanding was that the docsQosServiceFlowPolicedDropPkts counter include only packets dropped in violation of the Max(T) equation. However, with failures at tComLabs dues to lack of clarity in the spec, many vendors coded to the test. I thought that adding a new counter to count UGS packets dropped because the packet exceeds the UGS grant would add an appropriate place to count these dropped packets. However, having said this, my objective is clarity in the descriptions. If the consensus is to count the dropped UGS packets in the docsQosServiceFlowPolicedDropPkts counter, the description should be changed to explicitly state this. Regards, Margo -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, 29 January, 2003 1:55 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 André. I do not think that to count something twice is so bad. The ifOutDiscard counter is integrated counter which shows the sum of all dropped packets on US. The docsQosServiceFlowPolicedDropPkts is per interface counter and give more detailed information. Again, I do not see a reason to change docsQosServiceFlowPolicedDropPkts definition. Thanks. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 8:43 PM To: Pollak, Lucy; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 In trying to make sure that the text was as clear as possible, I think I lost sight of the general goal, which should be to ensure that each dropped packet is counted somewhere and counted only once. We too implemented the counter to include UGS dropped packets, in particular if the rt policy is set to drop UGS packets that are too large. In reality, there are only 2 counters that count dropped packets: ifOutDiscard and docsQosServiceFlowPolicedDropPkts. So if a UGS packet needs to be dropped, where is it counted if it is not in docsQosServiceFlowPolicedDropPkts? André "does not know what he wants" L. -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, January 29, 2003 12:00 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Margo and André. I want to understand the reason for this change. I also familiar with this discussion and in the beginning understood "especially to limit the maximum rate of the flow" as "only to limit the maximum rate of the flow". But with this understanding we failed tComLabs tests. Now, I guess, most of the CMs already implemented this counter as integrated counter: Max rate + max size + grant size + grant rate dropped packets. And it seems the correct behavior, if somebody wants to compare classified packets against dropped+send. I suppose, for backward compatibility we need to leave docsQosServiceFlowPolicedDropPkts as is or even add the definition that it will count all dropped packets. In addition, I agree, we may add the set of reason's defined packet counters: docsQosServiceFlowSizeDropPkts docsQosServiceFlowRateDropPkts I do not see a reason to differentiate UGS and other SF types. In definition we can tell that MAX rate or grant rate is the reason for the drop. The same about size. I do not see a reason to change delayed packet also. Again, "especially" gives us opportunity to apply it to UGS also. The SF type will not be changed on-the-fly. What is the problem to show the same information for UGS? Regards. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 12:41 AM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Looks much better! I like it. Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 5:19 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, In thinking about it a bit more, I'd prefer to see more explicit text for the policed packets. What do you think of the following text? For the docsQosServiceFlowPolicedDropPkts description - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: owner-docsis-oss@cablelabs.com [mailto:owner-docsis-oss@cablelabs.com]On Behalf Of Margo Dolas Sent: Tuesday, 28 January, 2003 4:18 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, I agree with your simplification. The new text for the docsQosServiceFlowPolicedDropPkts description would then be - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." A similar simplification could be made to the description of docsQosServiceFlowPolicedDelayPkts. The new text would be - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 2:08 PM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I understand why I did not read this text properly then. I took the last sentence out of context. I don't think I had to stretch my imagination that much to take it out of context, it does not make any mention of UGS, and when the Maximum Sustained Traffic Rate is exceeded, the packet arrival rate does exceed the packet transmission rate. Instead of providing a series of examples for UGS flows, would it not be simpler to replace it with a statement that the parameter does not apply to UGS flows, since Max Sustained Rate is not applicable? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 1:14 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, Maximum Sustained Rate is not applicable for UGS flows (per section 8.2.7 and table 8-4 of the RFI I09 spec), so packets cannot violate the Maximum Sustained Rate for an UGS flow. In an UGS flow, you only evaluate the packet size versus the UGS grant size, and then queue the packet until you receive a grant for the flow's SID. If the queue is full (because packets are arriving faster than the grant rate), then the packet is dropped and ifOutDiscards is incremented. Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 11:17 AM To: Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I have a problem with the proposed text because I don't understand how to distinguish packets that are in violation of the Maximum Sustained rate from packets with arrival rate faster than the grant rate. What is the difference? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 4:43 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 30 12:34:00 2003 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 MAA05001 for ; Thu, 30 Jan 2003 12:34:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UHb5O16968 for ipcdn-archive@odin.ietf.org; Thu, 30 Jan 2003 12:37:05 -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 h0UHabJ16854; Thu, 30 Jan 2003 12:36:38 -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 h0UHYrJ16784 for ; Thu, 30 Jan 2003 12:34:53 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04947 for ; Thu, 30 Jan 2003 12:31:15 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h0UHYk2I004159 for ; Thu, 30 Jan 2003 10:34:46 -0700 (MST) Received: [from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id KAA27039 for ; Thu, 30 Jan 2003 10:34:46 -0700 (MST)] Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59) id ; Thu, 30 Jan 2003 12:34:46 -0500 Message-ID: <19CD0E423FC1D611893500508B6F0B9C084966@ma07exm01.dma.isg.mot.com> From: Murwin William-LWM008 To: "'Lejeune, Andre'" , Margo Dolas , "'Pollak, Lucy'" , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Thu, 30 Jan 2003 12:34:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UHYrJ16785 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit What do you propose then for the description of the docsQosServiceFlowPolicedDropPkts. I am content with the latest change to docsQosServiceFlowPolicedDelayPkts. Will Murwin -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Thursday, January 30, 2003 12:04 PM To: Margo Dolas; Murwin William-LWM008; 'Pollak, Lucy'; 'Lejeune, Andre'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Actually, for delayed packets, I preferred the version that was posted by Margo at some point. It is clear and leaves no ambiguity: For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." The problem with dropped packets is that there are more reasons why a packet may be dropped for a given SID queue, and I thought we were going to cover them all. The current definition does not cover them all. 1-What about packets (UGS BE or others) dropped when they cannot be transmitted because the DS signal was momentarily lost, sufficiently to stop upstream transmissions? 2-What about UGS packets dropped because the arrival rate exceeded the tx rate sufficiently to require cleaning the queue? Other cases may exist... I would like to suggest that we do not try to distinguish the reasons why packets are dropped, and count them all. André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Thursday, January 30, 2003 11:53 AM To: Murwin William-LWM008; 'Pollak, Lucy'; 'Lejeune, Andre'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I think that the description for docsQosServiceFlowPolicedDelayPkts looks good. What do you think of changing the description of docsQosServiceFlowPolicedDropPkts to read - "This object counts packets dropped in violation of the Maximum Sustained Traffic Rate. For UGS flows, this object counts packets dropped because the packet exceeds the UGS grant size." Regards, Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Thursday, 30 January, 2003 9:49 AM To: 'Pollak, Lucy'; 'Margo Dolas'; 'Lejeune, Andre'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Here is the propose text: docsQosServiceFlowPolicedDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object counts packets dropped because because the packet exceeds the UGS grant size." ::= { docsQosServiceFlowStatsEntry 6 } docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not count packets queued awaiting grants." ::= { docsQosServiceFlowStatsEntry 7 } There will be no new object! Please respond ASAP as the MIB gets posted today! Will Murwin -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Thursday, January 30, 2003 5:01 AM To: 'Margo Dolas'; 'Lejeune, Andre'; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Margo, I also do not see a problem if USG and best effort will share the same counter. What do you think about size dropped? I guess, all dropped should be counted together. Do you want to add different detailed counters for size and rate dropped? Personally, I think that existed counter is good enough. I agree, that description should be clarified. William, would you like to propose new text for docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts counters? Regards. Lucy -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Wednesday, January 29, 2003 9:36 PM To: Pollak, Lucy; 'Lejeune, Andre'; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre and Lucy, I believe that the test failures occurred because the spec was unclear in the past. The original understanding was that the docsQosServiceFlowPolicedDropPkts counter include only packets dropped in violation of the Max(T) equation. However, with failures at tComLabs dues to lack of clarity in the spec, many vendors coded to the test. I thought that adding a new counter to count UGS packets dropped because the packet exceeds the UGS grant would add an appropriate place to count these dropped packets. However, having said this, my objective is clarity in the descriptions. If the consensus is to count the dropped UGS packets in the docsQosServiceFlowPolicedDropPkts counter, the description should be changed to explicitly state this. Regards, Margo -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, 29 January, 2003 1:55 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 André. I do not think that to count something twice is so bad. The ifOutDiscard counter is integrated counter which shows the sum of all dropped packets on US. The docsQosServiceFlowPolicedDropPkts is per interface counter and give more detailed information. Again, I do not see a reason to change docsQosServiceFlowPolicedDropPkts definition. Thanks. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 8:43 PM To: Pollak, Lucy; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 In trying to make sure that the text was as clear as possible, I think I lost sight of the general goal, which should be to ensure that each dropped packet is counted somewhere and counted only once. We too implemented the counter to include UGS dropped packets, in particular if the rt policy is set to drop UGS packets that are too large. In reality, there are only 2 counters that count dropped packets: ifOutDiscard and docsQosServiceFlowPolicedDropPkts. So if a UGS packet needs to be dropped, where is it counted if it is not in docsQosServiceFlowPolicedDropPkts? André "does not know what he wants" L. -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, January 29, 2003 12:00 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Margo and André. I want to understand the reason for this change. I also familiar with this discussion and in the beginning understood "especially to limit the maximum rate of the flow" as "only to limit the maximum rate of the flow". But with this understanding we failed tComLabs tests. Now, I guess, most of the CMs already implemented this counter as integrated counter: Max rate + max size + grant size + grant rate dropped packets. And it seems the correct behavior, if somebody wants to compare classified packets against dropped+send. I suppose, for backward compatibility we need to leave docsQosServiceFlowPolicedDropPkts as is or even add the definition that it will count all dropped packets. In addition, I agree, we may add the set of reason's defined packet counters: docsQosServiceFlowSizeDropPkts docsQosServiceFlowRateDropPkts I do not see a reason to differentiate UGS and other SF types. In definition we can tell that MAX rate or grant rate is the reason for the drop. The same about size. I do not see a reason to change delayed packet also. Again, "especially" gives us opportunity to apply it to UGS also. The SF type will not be changed on-the-fly. What is the problem to show the same information for UGS? Regards. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 12:41 AM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Looks much better! I like it. Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 5:19 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, In thinking about it a bit more, I'd prefer to see more explicit text for the policed packets. What do you think of the following text? For the docsQosServiceFlowPolicedDropPkts description - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: owner-docsis-oss@cablelabs.com [mailto:owner-docsis-oss@cablelabs.com]On Behalf Of Margo Dolas Sent: Tuesday, 28 January, 2003 4:18 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, I agree with your simplification. The new text for the docsQosServiceFlowPolicedDropPkts description would then be - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." A similar simplification could be made to the description of docsQosServiceFlowPolicedDelayPkts. The new text would be - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 2:08 PM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I understand why I did not read this text properly then. I took the last sentence out of context. I don't think I had to stretch my imagination that much to take it out of context, it does not make any mention of UGS, and when the Maximum Sustained Traffic Rate is exceeded, the packet arrival rate does exceed the packet transmission rate. Instead of providing a series of examples for UGS flows, would it not be simpler to replace it with a statement that the parameter does not apply to UGS flows, since Max Sustained Rate is not applicable? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 1:14 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, Maximum Sustained Rate is not applicable for UGS flows (per section 8.2.7 and table 8-4 of the RFI I09 spec), so packets cannot violate the Maximum Sustained Rate for an UGS flow. In an UGS flow, you only evaluate the packet size versus the UGS grant size, and then queue the packet until you receive a grant for the flow's SID. If the queue is full (because packets are arriving faster than the grant rate), then the packet is dropped and ifOutDiscards is incremented. Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 11:17 AM To: Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I have a problem with the proposed text because I don't understand how to distinguish packets that are in violation of the Maximum Sustained rate from packets with arrival rate faster than the grant rate. What is the difference? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 4:43 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 30 14:13:19 2003 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 OAA07598 for ; Thu, 30 Jan 2003 14:13:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UJGRH23061 for ipcdn-archive@odin.ietf.org; Thu, 30 Jan 2003 14:16:27 -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 h0UJGDJ23037; Thu, 30 Jan 2003 14:16:13 -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 h0UJDOJ22914 for ; Thu, 30 Jan 2003 14:13:24 -0500 Received: from alpha.jnpr.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07418 for ; Thu, 30 Jan 2003 14:09:45 -0500 (EST) Received: from electron.jnpr.net ([172.24.15.21]) by alpha.jnpr.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 30 Jan 2003 11:13:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Thu, 30 Jan 2003 11:13:16 -0800 Message-ID: <5EB31780BD297F46812C8F495FA08F620D090B@electron.jnpr.net> Thread-Topic: [ipcdn] Deadline for Comments of QoS MIB version 7 Thread-Index: AcLIhkHMuS4QkhInRcKCZFhb1eQfowADHQSQ From: "Victor Hou" To: "Murwin William-LWM008" , "Docsis-Oss (E-mail)" , "IPCDN (E-mail)" X-OriginalArrivalTime: 30 Jan 2003 19:13:16.0854 (UTC) FILETIME=[A4AFFD60:01C2C893] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UJDPJ22916 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit William, I would like point out one issue. For the description of object docsQosServiceFlowSID, it says: "Only active or admitted upstream service flows will have a Service Id (SID)." Per the DOCSIS 1.1 RFI document in Section 6.1.2.3 at the bottom of p. 55, only active service flows have a SID, and that understanding seems to have been consistent from the beginning. Thus, the sentence in the QoS MIB document should be changed to "Only active upstream service flows will have a Service Id (SID)." Victor _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 30 14:35:57 2003 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 OAA08508 for ; Thu, 30 Jan 2003 14:35:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UJd6n24577 for ipcdn-archive@odin.ietf.org; Thu, 30 Jan 2003 14:39:06 -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 h0UJd5J24570; Thu, 30 Jan 2003 14:39:05 -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 h0UJcHJ24541 for ; Thu, 30 Jan 2003 14:38:17 -0500 Received: from motgate4.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08465 for ; Thu, 30 Jan 2003 14:34:37 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h0UJc9xN018407 for ; Thu, 30 Jan 2003 12:38:09 -0700 (MST) Received: [from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id MAA24400 for ; Thu, 30 Jan 2003 12:37:07 -0700 (MST)] Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59) id ; Thu, 30 Jan 2003 14:38:08 -0500 Message-ID: <19CD0E423FC1D611893500508B6F0B9C084968@ma07exm01.dma.isg.mot.com> From: Murwin William-LWM008 To: "'Victor Hou'" , "Docsis-Oss (E-mail)" , "IPCDN (E-mail)" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Thu, 30 Jan 2003 14:38:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Please refer to Section C.2.2.3.3 Service Identifier "C.2.2.3.3 Service Identifier The value of this field specifies the Service Identifier assigned by the CMTS to a Service Flow with a non-null AdmittedQosParameterSet or ActiveQosParameterSet. This is used in the bandwidth allocation MAP to assign upstream bandwidth. This field MUST be present in CMTS-initiated DSA-REQ or DSC-REQ message related to establishing an admitted or active upstream Service Flow. This field MUST also be present in REG-RSP, DSA-RSP and DSC-RSP messages related to the successful establishment of an admitted or active upstream Service Flow. Even though a Service Flow has been successfully admitted or activated (i.e., has an assigned Service ID) the Service Flow ID MUST be used for subsequent DSx message signalling as it is the primary handle for a service flow. If a Service Flow is no longer admitted or active (via DSC-REQ) its Service ID MAY be reassigned by the CMTS." In Section 6.1.2.3, "6.1.2.3 Service Flows The concept of Service Flows is central to the operation of the MAC protocol. Service Flows provide a mechanism for upstream and downstream Quality of Service management. In particular, they are integral to bandwidth allocation. A Service Flow ID defines a particular unidirectional mapping between a CM and the CMTS. Active Upstream Service Flow IDs also have associated Service IDs or SIDs. Upstream bandwidth is allocated to SIDs, and hence ..." All this section is saying is that Active Flow MUST have SIDs. However is also true that admitted upstream service flows are allowed to have SIDs. -----Original Message----- From: Victor Hou [mailto:vhou@juniper.net] Sent: Thursday, January 30, 2003 2:13 PM To: Murwin William-LWM008; Docsis-Oss (E-mail); IPCDN (E-mail) Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I would like point out one issue. For the description of object docsQosServiceFlowSID, it says: "Only active or admitted upstream service flows will have a Service Id (SID)." Per the DOCSIS 1.1 RFI document in Section 6.1.2.3 at the bottom of p. 55, only active service flows have a SID, and that understanding seems to have been consistent from the beginning. Thus, the sentence in the QoS MIB document should be changed to "Only active upstream service flows will have a Service Id (SID)." Victor _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 30 15:16:13 2003 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 PAA09339 for ; Thu, 30 Jan 2003 15:16:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UKJMV26869 for ipcdn-archive@odin.ietf.org; Thu, 30 Jan 2003 15:19:22 -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 h0UKH8J26754; Thu, 30 Jan 2003 15:17:08 -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 h0UKGUJ26722 for ; Thu, 30 Jan 2003 15:16:30 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09199 for ; Thu, 30 Jan 2003 15:12:28 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h0UKEfrs014287 for ; Thu, 30 Jan 2003 13:14:41 -0700 (MST) Received: [from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA13640 for ; Thu, 30 Jan 2003 13:14:50 -0700 (MST)] Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59) id ; Thu, 30 Jan 2003 15:15:49 -0500 Message-ID: <19CD0E423FC1D611893500508B6F0B9C084969@ma07exm01.dma.isg.mot.com> From: Murwin William-LWM008 To: "Docsis-Oss (E-mail) (E-mail)" , "IPCDN (E-mail) (E-mail)" Date: Thu, 30 Jan 2003 15:15:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2C89C.3EED38A4" Subject: [ipcdn] Draft-ietf-ipcdn-qos-mib.txt Jan 30, 2003 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C2C89C.3EED38A4 Content-Type: text/plain; charset="iso-8859-1" This is the latest draft of the docQosMib version 7 dated Jan 30, 2003. We have decided to extended the deadline to submit to IETF till Feb 1, 2003. This way we will have a full 6 months before the version 7 expires. NOTE: The DOCS-QOS-MIB has been re-rooted ::= {docsQosMib XXX } because of compilation errors. (1) Thus all of the QoS MIB depercated and obsolete objects have been removed. (2) The High Capacity Object have been removed and the existing 32-bit objects have become 64-bit objects. (3) The IpAddress syntax has been removed. (4) All of the objects within a table have been re-numbered inorder. This version ends the QoS MIB's backwards compatibility with older versions. It will now be the responsiblity of CableLabs to maintain a version of DOC-QOS-MIB v4 for those cable operators wanting to manage agents that are currently in the field that no longer are supported by their vendor. ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 <> <> ------_=_NextPart_000_01C2C89C.3EED38A4 Content-Type: text/plain; name="draft-ietf-ipcdn-qos-mib-07.txt" Content-Disposition: attachment; filename="draft-ietf-ipcdn-qos-mib-07.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= IPCDN Working Group Michael = Patrick=0A= William = Murwin=0A= Motorola BCS=0A= =0A= =0A= =0A= Data Over Cable System Quality of Service=0A= Management Information Base (DOCSIS-QOS MIB)=0A= =0A= January 30, 2003=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Status of this Memo=0A= =0A= This document is an Internet-Draft and is in full conformance = with=0A= all the provisions of Section 10 of RFC2026. Internet-Drafts are=0A= working documents of the Internet Engineering Task Force (IETF), = its=0A= Areas, and its Working Groups. Note that other groups may also=0A= distribute working documents as Internet-Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six = months=0A= and may be updated, replaced, or obsoleted by other documents at = any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as a "work in progress".=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= =0A= Copyright (c) The Internet Society 2001. All Rights Reserved.=0A= =0A= =0A= Abstract=0A= =0A= This document defines a basic set of managed objects for = SNMP-based=0A= management of extended QOS features of Cable Modems (CMs) and = Cable=0A= Modem Termination Systems (CMTSs) conforming to the Data over = Cable=0A= System (DOCSIS) standard version 1.1.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 1]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= Table of Contents=0A= =0A= =0A= Status of this Memo............................... 1=0A= Abstract.......................................... 1=0A= Revision History.................................. 3=0A= =0A= 1. Introduction...................................... 6=0A= 1.1 The Internet-Standard Management Framework... 6=0A= 1.2 Glossary..................................... 6=0A= =0A= 2. Overview.......................................... 8=0A= 2.1 Textual Conventions.......................... 8=0A= 2.2 MIB Organization............................ 8=0A= 2.2.1 docsQosPktClassTable................. 12=0A= 2.2.2 docsQosParamSetTable................. 12=0A= 2.2.2.1 Interoperation with DOCSIS 1.0....... 14=0A= 2.2.3 docsQosServiceFlowTable.............. 15=0A= 2.2.4 docsQosServiceFlowStatsTable......... 16=0A= 2.2.5 docsQosUpstreamStatsTable............ 17=0A= 2.2.6 docsQosDynamicServiceStatsTable...... 17=0A= 2.2.7 docsQosServiceFlowLogTable........... 17=0A= 2.2.8 docsQosServiceClassTable............. 18=0A= 2.2.9 docsQosServiceClassPolicyTable....... 18=0A= 2.2.10 docsQosPHSTable...................... 18=0A= 2.2.11 docsQosCmtsMacToSrvFlowTable......... 19=0A= =0A= 3. Externally Administered Classification............ 19=0A= =0A= 4. Definitions....................................... 23=0A= =0A= 5. Security Considerations........................... 80=0A= =0A= 6. Intellectual Property............................. 81=0A= =0A= 7. Acknowledgement................................... 82=0A= =0A= 8. Normative References.............................. 82=0A= =0A= 9. Informative References............................ 83=0A= =0A= 10. Author's Address.................................. 83=0A= =0A= 11. Full Copyright Statement.......................... 84=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 2]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= Revision History=0A= =0A= Rev Date Description=0A= --- -------- -----------=0A= -07 1/30/03 Functional Changes:=0A= - Re-routed the docQosMib because of = compilation=0A= errors.=0A= - Removed obsolete and deprecated = objects.=0A= - Renumbered existing objects after removal = of=0A= obsolete and deprecated objects.=0A= - Clarified the operation of the RowStatus = objects.=0A= - Clarified the description for = docsQosPktClassPkts.=0A= - Clarified the description for=0A= docsQosServiceFlowOctets.=0A= - Clarified the description for=0A= docsQosServiceFlowPkts.=0A= - Clarified the operation of the=0A= docsQosServiceClassStatus.=0A= - Changed the description of the reported = default=0A= values for the = docsQosParamSetMaxTrafficBurst and=0A= docsQosParamSetMaxConcatBurst.=0A= - Changed the default values for the=0A= docsQosServiceClassMaxTrafficBurst.=0A= and docsQosServiceClassMaxConcatBurst = objects.=0A= - Changed docsQosPktClassPkts to a 64-bit = counter.=0A= - Changed docsQosServiceFlowOctets to a=0A= 64-bit counter.=0A= - Changed docsQosServiceFlowPkts to a = 64-bit=0A= counter.=0A= - Changed docsQosServiceFlowLogPkts to a = 64-bit=0A= counter.=0A= - Changed docsQosServiceFlowLogOctets to a = 64-bit=0A= counter.=0A= Editorial Changes:=0A= - Updated Author's Address.=0A= - Updated Section 2.2.4 = docsQosServiceFlowStatsTable.=0A= - Section 1.1 was updated to reflect the=0A= most recent MIB boilerplate.=0A= - Section 5 was updated to reflect the=0A= most recent Security Considerations.=0A= - Split References into Normative and = Informative.=0A= - Updated references to refer to current = RFCs.=0A= - Removed section 2.2.1.1 InetAddress = Transition.=0A= -06 11/8/01 Functional Changes:=0A= - Deprecated objects that were of type = IpAddress=0A= and added new objects that were of type=0A= InetAddressType and InetAddress, to = support both=0A= IPv4 and IPv6 in the = docsQosPktClassTable.=0A= - Clarified the default value of the=0A= docsQosPktClassIpDestMask and=0A= docsQosPktClassIpSourceMask.=0A= =0A= =0A= =0A= Expires July 2003 [Page 3]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= - Clarified that some of counters from = the=0A= docsQosDynamicServiceStatsTable, = include=0A= retries.=0A= - Added objects that were removed from = earlier=0A= revisions of the mib, as obsolete.=0A= - In section 2.2.2.1, in bullet item (1) = removed=0A= requirement of adding row to=0A= docsIfQosProfileTable.=0A= - Clarified the Cable Modem's implementation = of the=0A= docsQosParamSetTosAndMask.=0A= Editorial Changes:=0A= - Corrected the description of the = individual bits=0A= that make up = docsQosParamsSetRequestPolicyOct.=0A= - Corrected the spelling of = docsCableMaclayer in the=0A= description of the = docsQosServiceFlowLogIfIndex.=0A= - In section 2.2.1, clarified the definition = of=0A= classifiers in the = docsQosPktClassTable.=0A= - In section 2.2.2.1, in bullet item (3) = flexibility=0A= was given to implementing=0A= docsIfQosProfileTable.=0A= - In section 2.2.2.1, added bullet item = (6).=0A= - Changed references to the latest = Data-Over-Cable=0A= Service Interface Specifications: Radio = Frequency=0A= Interface Specification.=0A= - Added section 2.2.1.1 InetAddress = Transition,=0A= to discuss the change from IpAddress = objects=0A= to InetAddressType and InetAddress = objects.=0A= - Changed the description of objects within = the=0A= docsQosServiceClassTable, so that they = were=0A= no longer templates for obsolete = objects.=0A= - Changed section 5 to "Security = Considerations".=0A= - Changed section 6 to "Intellectual = Property".=0A= - "References" where moved to section 8.=0A= - "Author's Address" where moved to section = 9.=0A= - Added section 7, "Acknowledgement".=0A= - Added section 10, "Full Copyright = Statement".=0A= - Section 1.1 was updated to reflect the=0A= most recent MIB boilerplate.=0A= - Updated references to refer to current = RFCs.=0A= =0A= =0A= -05 03/01/01 Functional Changes:=0A= - Changed default values of=0A= dosQosPktClassIpSourceMask and=0A= docsQosPktClassIpDestMask to = 255.255.255.255.=0A= Editorial Changes:=0A= - Corrected ifDirection values in 2.1.=0A= - In section 2.2.2.1, clarified which=0A= packets/bytes are counted in = docsIfCmtsService-=0A= InPkts and docsIfCmtsServiceInOctets.=0A= - Clarified description of = dosQosServiceFlowPkts=0A= =0A= =0A= =0A= Expires July 2003 [Page 4]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= to avoid requiring CMs to classify = downstream=0A= packets.=0A= - Clarified that = docsQosServiceFlowPHSUnknowns only=0A= applies to received packets.=0A= - Clarified that docsQosPktClassBitMap = and=0A= docsQosParamSetBitMap indicate all = parameters for=0A= both adds and changes.=0A= =0A= =0A= -04 10/18/00 - Updated descriptions of UGS applicable = QOS=0A= param set objects.=0A= - Added two new docsQosPktClassBitMap = bits=0A= and *renumbered* the bits.=0A= - Added docsQosServiceClassDirection=0A= =0A= -04 10/10/00 - Updated Overview to not mention = restriction=0A= to SnmpV1.=0A= - Updated most docsQosParamSet objects to=0A= clarify default and "not applicable" = values.=0A= - Add docsQosPktClassBitMap, = docsQosParamSetBitMap=0A= - Restore docsQosParamSetServiceClassName=0A= - Add 5 objects to = docsQosServiceFlowLogTable=0A= =0A= -04 10/01/00 - Move six objects from = docsQosServiceFlowTable=0A= back to docsQosParamSetTable.=0A= - Add DCC statistics=0A= - Removed notApplicable(256) from=0A= docsQosParamSetSchedulingType=0A= =0A= -03 08/11/00 Reorganize docsQosParamSetTable.=0A= =0A= -02 12/08/99 Add docsQosServiceFlowStatsTable,=0A= docsQosUpstreamStatsTable,=0A= docsQosDynamicServiceStatsTable,=0A= docsQosServiceFlowLogTable=0A= -01 06/25/99 Complete rewrite based on -I01 draft=0A= -00 08/07/98 Initial draft posted for discussion.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 5]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= 1. Introduction=0A= =0A= This memo specifies a MIB module in a manner that is compliant to = the=0A= SNMP SMIv2[1][2][3]. The set of objects is consistent with the = SNMP=0A= framework and existing SNMP standards.=0A= =0A= This memo is a product of the IPCDN working group within the = Internet=0A= Engineering Task Force. Comments are solicited and should be=0A= addressed to the working group's mailing list at ipcdn@ietf.org=0A= and/or the author.=0A= =0A= =0A= 1.1 The Internet-Standard Management Framework=0A= =0A= For a detailed overview of the documents that describe the = current=0A= Internet-Standard Management Framework, please refer to section 7 = of=0A= RFC 3410 [12].=0A= =0A= Managed objects are accessed via a virtual information store, = termed=0A= the Management Information Base or MIB. MIB objects are = generally=0A= accessed through the Simple Network Management Protocol (SNMP).=0A= Objects in the MIB are defined using the mechanisms defined in = the=0A= Structure of Management Information (SMI). This memo specifies a = MIB=0A= module that is compliant to the SMIv2, which is described in STD = 58,=0A= RFC 2578 [1], STD 58, RFC 2579 [2] and STD 58, RFC 2580 [3].=0A= =0A= 1.2 Glossary=0A= =0A= =0A= =0A= Active QPS Active Qos Parameter Set. The set of QOS = parameters=0A= that describe the current level service provided to = a=0A= Service Flow.=0A= =0A= Active SF Active Service Flow. An SF with a non-empty Active=0A= QPS.=0A= =0A= Admitted QPS Admitted Qos Parameter Set. The set of QOS = parameters=0A= that describe a level of service which the Service=0A= Flow is not currently using, but which it is=0A= guaranteed to receive upon the SF's request to = make=0A= the set Active.=0A= =0A= Admitted SF A Service Flow with a non-empty Admitted QPS.=0A= =0A= CATV Cable TV=0A= =0A= CM Cable Modem, a modem connecting a subscriber's LAN = the=0A= CATF RF network. DOCSIS CMs operate as a MAC layer=0A= bridge between the home LAN and the RF network.=0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 6]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= CMTS Cable Modem Termination System, the "head-end" = device=0A= providing connectivity between the RF network and = the=0A= Internet.=0A= =0A= Downstream The direction from the head end towards the=0A= subscriber.=0A= =0A= DSA Dynamic Service Addition, a DOCSIS MAC management=0A= message requesting the dynamic creation of a new=0A= Service Flow. New SFs are created with a three-=0A= message exchange of a DSA-REQ, DSA-RSP, and = DSA-ACK.=0A= =0A= DSC Dynamic Service Change, a DOCSIS MAC management=0A= message requesting a change to the attributes of a=0A= Service Flow. SFs are changed with a = three-message=0A= exchange of a DSC-REQ, DSC-RSP, and DSC-ACK.=0A= =0A= DSD Dynamic Service Delete, a DOCSIS MAC management=0A= message requesting the deletion of a Service Flow. = SFs=0A= are deleted with a two-message exchange of a = DSD-REQ=0A= and DSD-ACK.=0A= =0A= Head-end The origination point in most cable systems of the=0A= subsriber video signals. It is generally also the=0A= location of the CMTS.=0A= =0A= PHS Payload Header Suppression, a feature of DOCSIS 1.1 = in=0A= which header bytes that are common in a sequence = of=0A= packets of a Service Flow are replaced by a = one-byte=0A= PHSI Index (PHSI) when transmitting the packet on = the=0A= RF network.=0A= =0A= Provisioned QPS A QOS Parameter Set describing an envelope of = service=0A= within which a Service Flow is authorized to = request=0A= admission. All existing service flows must have a=0A= non-empty Provisioned QPS, hence all SFs are=0A= considered to be "Provisioned".=0A= =0A= SCN Service Class Name -- a named set of QOS = parameters.=0A= A Service Flow may or may not be associated with a=0A= single named Service Class. A Service Class has as = an=0A= attribute a Qos Parameter Set that is used as the=0A= default set of values for all Service Flows = belonging=0A= to the Service Class.=0A= =0A= SID Service ID. A 16-bit integer assigned by the CMTS = for=0A= an Upstream Service Flow with a non-empty Active = QOS=0A= Parameter Set.=0A= =0A= SF Service Flow. A unidirectional stream of packets=0A= between the CM and CMTS. SFs are characterized as=0A= =0A= =0A= =0A= Expires July 2003 [Page 7]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= upstream or downstream. The SF is the fundamental=0A= unit of service provided on a DOCSIS CATV network.=0A= =0A= SFID Service Flow ID. A 32-bit unsigned integer = assigned=0A= by the CMTS to each Service Flows=0A= =0A= Upstream The direction from a subscriber CM to the head-end=0A= CMTS.=0A= =0A= =0A= =0A= =0A= 2. Overview=0A= =0A= This MIB provides a set of objects required for the management of=0A= DOCSIS 1.1 compliant Cable Modems (CM) and Cable Modem = Termination=0A= Systems (CMTS). The specification is derived from the DOCSIS 1.1=0A= Radio Frequency Interface specification [4]. Please note that = the=0A= referenced DOCSIS standard only requires Cable Modems to process = IPv4=0A= customer traffic. Design choices in this MIB reflect those=0A= requirements. Future versions of the DOCSIS standard are expected = to=0A= require support for IPv6 as well.=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this=0A= document are to be interpreted as described in [7].=0A= =0A= =0A= 2.1 Textual Conventions=0A= =0A= The textual convention "IfDirection" is defined to indicate the=0A= direction of a packet classifier relative to an interface. It = takes=0A= the values of either downstream(1) or upstream(2).=0A= =0A= The textual convention "BitRate" corresponds to the bits per = second=0A= as defined for QOS Parameter Sets in DOCSIS1.1. This definition=0A= includes all bits of the Ethernet MAC frame as transmitted on the = RF=0A= network, starting with the Destination Address and ending with = the=0A= Ethernet FCS. It does NOT includes bits in the DOCSIS MAC header.=0A= =0A= =0A= =0A= =0A= =0A= 2.2 MIB Organization=0A= =0A= =0A= The structure of the MIB is summarized below:=0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 8]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosMIB=0A= docsQosMIBObjects=0A= docsQosPktClassTable=0A= docsQosPktClassEntry=0A= docsQosPktClassId=0A= docsQosPktClassDirection=0A= docsQosPktClassPriority=0A= docsQosPktClassIpTosLow=0A= docsQosPktClassIpTosHigh=0A= docsQosPktClassIpTosMask=0A= docsQosPktClassIpProtocol=0A= docsQosPktClassInetSourceAddrType=0A= docsQosPktClassInetSourceAddr=0A= docsQosPktClassInetSourceMaskType=0A= docsQosPktClassInetSourceMask=0A= docsQosPktClassInetDestAddrType=0A= docsQosPktClassInetDestAddr=0A= docsQosPktClassInetDestMaskType=0A= docsQosPktClassInetDestMask=0A= docsQosPktClassSourcePortStart=0A= docsQosPktClassSourcePortEnd=0A= docsQosPktClassDestPortStart=0A= docsQosPktClassDestPortEnd=0A= docsQosPktClassDestMacAddr=0A= docsQosPktClassDestMacMask=0A= docsQosPktClassSourceMacAddr=0A= docsQosPktClassEnetProtocolType=0A= docsQosPktClassEnetProtocol=0A= docsQosPktClassUserPriLow=0A= docsQosPktClassUserPriHigh=0A= docsQosPktClassVlanId=0A= docsQosPktClassState=0A= docsQosPktClassPkts=0A= docsQosPktClassBitMap=0A= docsQosParamSetTable=0A= docsQosParamSetEntry=0A= docsQosParamSetServiceClassName=0A= docsQosParamSetPriority=0A= docsQosParamSetMaxTrafficRate=0A= docsQosParamSetMaxTrafficBurst=0A= docsQosParamSetMinReservedRate=0A= docsQosParamSetMinReservedPkt=0A= docsQosParamSetActiveTimeout=0A= docsQosParamSetAdmittedTimeout=0A= docsQosParamSetMaxConcatBurst=0A= docsQosParamSetSchedulingType=0A= docsQosParamSetNomPollInterval=0A= docsQosParamSetTolPollJitter=0A= docsQosParamSetUnsolicitGrantSize=0A= docsQosParamSetNomGrantInterval=0A= docsQosParamSetTolGrantJitter=0A= =0A= =0A= =0A= Expires July 2003 [Page 9]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosParamSetGrantsPerInterval=0A= docsQosParamSetTosAndMask=0A= docsQosParamSetTosOrMask=0A= docsQosParamSetMaxLatency=0A= docsQosParamSetType=0A= docsQosParamSetRequestPolicyOct=0A= docsQosParamSetBitMap=0A= docsQosServiceFlowTable=0A= docsQosServiceFlowEntry=0A= docsQosServiceFlowId=0A= docsQosServiceFlowSID=0A= docsQosServiceFlowDirection=0A= docsQosServiceFlowPrimary=0A= docsQosServiceFlowStatsTable=0A= docsQosServiceFlowStatsEntry=0A= docsQosServiceFlowPkts=0A= docsQosServiceFlowOctets=0A= docsQosServiceFlowTimeCreated=0A= docsQosServiceFlowTimeActive=0A= docsQosServiceFlowPHSUnknowns=0A= docsQosServiceFlowPolicedDropPkts=0A= docsQosServiceFlowPolicedDelayPkts=0A= docsQosUpstreamStatsTable=0A= docsQosUpstreamStatsEntry=0A= docsQosSID=0A= docsQosUpstreamFragments=0A= docsQosUpstreamFragDiscards=0A= docsQosUpstreamConcatBursts=0A= docsQosDynamicServiceStatsTable=0A= docsQosDynamicServiceStatsEntry=0A= docsQosIfDirection=0A= docsQosDSAReqs=0A= docsQosDSARsps=0A= docsQosDSAAcks=0A= docsQosDSCReqs=0A= docsQosDSCRsps=0A= docsQosDSCAcks=0A= docsQosDSDReqs=0A= docsQosDSDRsps=0A= docsQosDynamicAdds=0A= docsQosDynamicAddFails=0A= docsQosDynamicChanges=0A= docsQosDynamicChangeFails=0A= docsQosDynamicDeletes=0A= docsQosDynamicDeleteFails=0A= docsQosDCCReqs=0A= docsQosDCCRsps=0A= docsQosDCCAcks=0A= docsQosDCCs=0A= docsQosDCCFails=0A= docsQosServiceFlowLogTable=0A= =0A= =0A= =0A= Expires July 2003 [Page 10]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosServiceFlowLogEntry=0A= docsQosServiceFlowLogIndex=0A= docsQosServiceFlowLogIfIndex=0A= docsQosServiceFlowLogSFID=0A= docsQosServiceFlowLogCmMac=0A= docsQosServiceFlowLogPkts=0A= docsQosServiceFlowLogOctets=0A= docsQosServiceFlowLogTimeDeleted=0A= docsQosServiceFlowLogTimeCreated=0A= docsQosServiceFlowLogTimeActive=0A= docsQosServiceFlowLogDirection=0A= docsQosServiceFlowLogPrimary=0A= docsQosServiceFlowLogServiceClassName=0A= docsQosServiceFlowLogPolicedDropPkts=0A= docsQosServiceFlowLogPolicedDelayPkts=0A= docsQosServiceFlowLogControl=0A= docsQosServiceClassTable=0A= docsQosServiceClassEntry=0A= docsQosServiceClassName=0A= docsQosServiceClassStatus=0A= docsQosServiceClassMaxTrafficRate=0A= docsQosServiceClassMaxTrafficBurst=0A= docsQosServiceClassMinReservedRate=0A= docsQosServiceClassMinReservedPkt=0A= docsQosServiceClassMaxConcatBurst=0A= docsQosServiceClassNomPollInterval=0A= docsQosServiceClassTolPollJitter=0A= docsQosServiceClassUnsolicitGrantSize=0A= docsQosServiceClassNomGrantInterval=0A= docsQosServiceClassTolGrantJitter=0A= docsQosServiceClassGrantsPerInterval=0A= docsQosServiceClassMaxLatency=0A= docsQosServiceClassActiveTimeout=0A= docsQosServiceClassAdmittedTimeout=0A= docsQosServiceClassSchedulingType=0A= docsQosServiceClassRequestPolicy=0A= docsQosServiceClassTosAndMask=0A= docsQosServiceClassTosOrMask=0A= docsQosServiceClassDirection=0A= docsQosServiceClassPolicyTable=0A= docsQosServiceClassPolicyEntry=0A= docsQosServiceClassPolicyIndex=0A= docsQosServiceClassPolicyName=0A= docsQosServiceClassPolicyRulePriority=0A= docsQosServiceClassPolicyStatus=0A= docsQosPHSTable=0A= docsQosPHSEntry=0A= docsQosPHSField=0A= docsQosPHSMask=0A= docsQosPHSSize=0A= docsQosPHSVerify=0A= =0A= =0A= =0A= Expires July 2003 [Page 11]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosPHSIndex=0A= docsQosCmtsMacToSrvFlowTable=0A= docsQosCmtsMacToSrvFlowEntry=0A= docsQosCmtsCmMac=0A= docsQosCmtsServiceFlowId=0A= docsQosCmtsIfIndex=0A= =0A= =0A= =0A= The MIB is organized as 11 tables. Most tables are implemented in=0A= both the CM and CMTS; the docsQosUpstreamStatsTable and=0A= docsQosServiceFlowLogTable are implemented on the CMTS only.=0A= =0A= =0A= 2.2.1 docsQosPktClassTable=0A= =0A= The docsQosPktClassTable reports the Service Flow Classifiers=0A= implemented by the managed device. The table is indexed by the = tuple=0A= { ifIndex, docsQosServiceFlowId, docsQosPktClassId }. The = ifIndex=0A= corresponds to an CATV MAC interface. Each CATV MAC interfaces has = a=0A= set of Service Flows, identified with a docsQosServiceFlowId = value=0A= that is unique for that interface. Each service flow may have a=0A= number of packet classifiers that map packets to the flow. The=0A= ClassifierId for the classifier is unique only within a = particular=0A= service flow.=0A= =0A= The semantics of packet classification are provided in [4]. = Briefly,=0A= the DOCSIS MAC interface calls for matching packets based on = values=0A= within the 802.2 (LLC), 802.3, IP, and/or UDP/TCP headers. = Packets=0A= which map more than one classifier are prioritized according to = their=0A= docsQosPktClassPriority value. The docsQosServiceFlowId (an index=0A= object) indicates to which service flow the packet is classified.=0A= =0A= The docsQosPktClassTable is distinct from the docsDevIpFilterTable = of=0A= [9] in that docsQosPktClassTable is intended only to reflect the=0A= state of the Service Flow Classifiers. Service Flow Classifiers = may=0A= be created only via a CM configuration file or from the Dynamic=0A= Service Addition (DSA) messages. For this reason,=0A= docsQosPktClassTable is read-only.=0A= =0A= The docsDevIpFilterTable is intended for external policy-based=0A= administration of packet classifiers. See the section = "Externally=0A= Administered Classification", below.=0A= =0A= =0A= 2.2.2 docsQosParamSetTable=0A= =0A= The docsQosParamSetTable reports the values of Qos Parameter Set = as=0A= defined in Section C.2.2 of [4].=0A= =0A= In general, a Service Flow is associated with three different Qos=0A= =0A= =0A= =0A= Expires July 2003 [Page 12]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= Parameter Sets (QPSs): an "active" QPS, an "admitted" QPS, and a=0A= "provisioned" or "authorized" QPS. The relationship of these = three=0A= sets is represented below:=0A= =0A= =0A= =0A= =0A= =0A= +---------------------+=0A= | Provisioned |=0A= | |=0A= | +---------------+ |=0A= | | Admitted | |=0A= | | | |=0A= | | +---------+ | |=0A= | | | Active | | |=0A= | | | | | |=0A= | | +---------+ | |=0A= | | | |=0A= | +---------------+ |=0A= | |=0A= +---------------------+=0A= =0A= Figure 1: Qos Parameter Sets=0A= =0A= =0A= =0A= The Provisioned QPS describes the maximum service envelope for = which=0A= the SF is authorized. The Admitted QPS is the set of services for=0A= which a service flow has requested admission to the DOCSIS RF=0A= network, but which is not yet active. The Admitted QPS is used = during=0A= the two-phase process of IP Telephony service flow admission to = admit=0A= the bandwidth for a bidirectional voice call when the far end is=0A= ringing. Since ringing may occur for up to four minutes, this=0A= permits the bandwidth to be reserved but not actually consumed = during=0A= this interval. The Active QPS is the set of services actually = being=0A= used by the Service Flow. The DOCSIS v1.1 specification [4] = defines=0A= what it means for a QPS envelope to be "within" another. In = general,=0A= an inner QPS is considered to be "within" an outer QPS when all = QOS=0A= parameters represent demands of equal or fewer resources of the=0A= network.=0A= =0A= In addition to their use as attributes of a Service Flow, a QPS = is=0A= also an attribute of a Service Class. A DOCSIS CM configuration = file=0A= or DSA message may request the creation of a new SF and give only = the=0A= Service Class Name. The CMTS "expands the macro" of a Service = Class=0A= Name creation by populating the Provisioned, Admitted, and/or = Active=0A= QPSs of the Service Flow with the QPS of the Service Class Name. = All=0A= of the QPSs of a Service Flow must be expansions of the same = Service=0A= Class, and in this case the SF is said to "belong" to the Service=0A= Class. Changing the contents of a Service Class' QPS does not = affect=0A= =0A= =0A= =0A= Expires July 2003 [Page 13]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= the QPS of any Service Flow earlier expanded from that Service = Class=0A= name. Only the CMTS implements docsQosServiceClassTable.=0A= =0A= See [4] section 8 for a full description and the theory of = operation=0A= of Docsis 1.1 QOS operation.=0A= =0A= =0A= =0A= The docsQosParamSetTable sets are indexed by { ifIndex,=0A= docsQosServiceFlowId, docsQosParamSetType}. ifIndex indicates a=0A= particular "DOCSIS MAC Domain". docsQosServiceFlowId uniquely=0A= identifies a service flow on that MAC domain. The=0A= docsQosParamSetType indicates whether the row describes an = active,=0A= admitted, or provisioned Qos Parameter Set.=0A= =0A= The docsQosParamSetTable is read-only, because it indicates the = Qos=0A= Parameter Set contents as defined by DOCSIS signaling. The=0A= docsQosServiceClassTable is read-create to permit managers to = define=0A= a template of Qos Parameters that can be referenced by DOCSIS = modems=0A= when creating their Qos Parameter Sets.=0A= =0A= =0A= 2.2.2.1 Interoperation with DOCSIS 1.0=0A= =0A= The DOCSIS 1.0 DOCS-IF-MIB [10] specifies a docsIfQosProfileTable = to=0A= describe the set of Class Of Service (COS) parameters associated = with=0A= a COS "profile". The docsIfCmServiceTable, which contains one = entry=0A= per SID, references this table with a docsIfCmServiceQosProfile=0A= number.=0A= =0A= The DOCSIS 1.1 CM registration process allows a modem to register = as=0A= operating either with DOCSIS 1.0 or DOCSIS 1.1 functionality. = For=0A= ease of expression, we call a modem registering with DOCSIS 1.0=0A= functionality a "DOCSIS 1.0 modem", regardless of the modem's=0A= capabilities.=0A= =0A= A CMTS or CM supporting both DOCSIS 1.0 and DOCSIS 1.1 implements=0A= both the tables of [10] and the tables of this MIB. The=0A= interoperation goal is that before modem registration, the DOCSIS = 1.0=0A= MIB [10] applies. After registration, either the DOCSIS 1.0 or=0A= DOCSIS 1.1 MIB applies, depending on the mode with which the = modem=0A= registered. The specific interoperation rules are:=0A= =0A= =0A= 1. When a CM initially ranges, the CM implements a row in the=0A= DOCS-IF-MIB docsIfCmServiceTable and the CMTS implements a = row=0A= in the DOCS-IF-MIB docsIfCmtsServiceTable corresponding to = the=0A= default upstream Service ID (SID) used for = pre-registration=0A= upstream traffic. For historical compatibility a row may be=0A= created for the docsIfQosProfileTable with default values,=0A= which may be referenced by the docsIfCmServiceTable = entries.=0A= =0A= =0A= =0A= Expires July 2003 [Page 14]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= 2. Both a CMTS and CM implementing this MIB MUST NOT implement=0A= docsQosParamSetTable or docsQosServiceFlowTable rows until=0A= after the CM registers with DOCSIS 1.1 modem operation.=0A= =0A= =0A= 3. When a modem registers with the CMTS as a "DOCSIS 1.1" = modem,=0A= any exclusively-referenced row in DOCS-IF-MIB=0A= docsQosProfileTable representing the modems upstream Qos=0A= profile for pre-registration traffic MUST be removed.=0A= Multiply-referenced rows may remain. The=0A= docsQosIfCmServiceQosProfile object in the CM's row of=0A= docsIfCmServiceTable MUST be set to zero. The=0A= docsIfCmServiceTable row for the DOCSIS 1.1 modem continues = to=0A= exist, and the various statistic objects in that row are=0A= incremented. The CMTS should retain the = docsIfCmtsServiceTable=0A= entry for the DOCSIS 1.1 CM.=0A= =0A= =0A= 4. When a DOCSIS 1.1 modem registers, both the CMTS and CM=0A= represent all service flows described in the modem=0A= configuration file in docsQosParamSetTable and=0A= docsQosServiceFlowTable.=0A= =0A= =0A= 5. At the CMTS, the Docsis 1.0 MIB objects=0A= docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets for = a=0A= SID assigned to a Docsis 1.1 modem count only the pre-=0A= registration packets/bytes of those modems.=0A= =0A= =0A= 6. DOCSIS 1.0 modems do not have entries in the DOCS-QOS-MIB.=0A= =0A= =0A= =0A= 2.2.3 docsQosServiceFlowTable=0A= =0A= The docsQosServiceFlowTable provides read-only information about = all=0A= of the service flows known by the device. It is indexed by the=0A= combination of { ifIndex, dosQosServiceFlowId }, where ifIndex=0A= corresponds to a CATV MAC interface and docsQosServiceFlowId is = the=0A= 32- bit integer assigned by the CMTS controlling the MAC domain. = A=0A= CM typically has only a single CATV MAC interface, while a CMTS = may=0A= have several. See [10] for a description of the ifIndex = numbering=0A= for DOCSIS devices.=0A= =0A= The table indicates whether a given SF is in the upstream or=0A= downstream direction, and whether it is the "primary" SF in that=0A= direction. The primary SF carries traffic that is not otherwise=0A= classified to any other SF in that direction.=0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 15]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= 2.2.4 docsQosServiceFlowStatsTable=0A= =0A= The docsQosServiceFlowStatsTable provides statistics for all=0A= currently existing SFs known by the managed device. It provides=0A= basic packet and octet counters, as well as certain other = SF-specific=0A= stats such as the time at which the flow was created and how many=0A= seconds it has been active.=0A= =0A= The table also provides objects which can be used to fine-tune=0A= admission control decisions, namely the number of packets dropped = or=0A= delayed due to QOS policing decisions enforced by the managed = device.=0A= =0A= The model of the service flows stats table is that there exists a=0A= service flow Classification function followed by a service flow=0A= maximum rate Policing function for packets transmitted onto the=0A= Docsis RF network, as depicted below=0A= =0A= =0A= +----------+=0A= +------------+ clsfy 1 -----+ | Per-SF | = forwarded=0A= Pkts | |-----------> | | Maximum |---> for = Docsis=0A= ----->| Classify | clsfy 2 SF1 |--> | Rate | RF = Network=0A= | Function |-----------> | | Policing | = transmission=0A= | | -----+ | Function |=0A= | | | |----+=0A= | | | | |=0A= | | +----------+ = Dropped=0A= +------------+ | ^=0A= +----+ Delayed=0A= =0A= Packets intended for transmission onto the Docsis RF network=0A= (upstream or downstream) are first classified to a service flow = by=0A= matching one of several possible classifiers associated with that=0A= service flow. The docsQosPktClassPkts count includes the number = of=0A= packets that match the classifier, regardless of the eventual=0A= disposition of the packet.=0A= =0A= DOCSIS requires that each service flow be policed to maintain a=0A= maximum rate of transmission. This is performed by either dropping = or=0A= delaying a packet on that service flow. The=0A= docsQosServiceFlowPolicedDropPkts object counts the number of = service=0A= flow packets dropped by the policing function. The=0A= docsQosServiceFlowPolicedDelayPkts counts the number of packet=0A= delayed but still forwarded. The docsQosServiceFlowPkts object=0A= counts the total number of packets forwarded beyond the policing=0A= function intended for eventual transmission onto the DOCSIS RF=0A= network. Although packets may be latter dropped by other = functions=0A= (e.g. a transmit queue overflow on a DOCSIS hardware = transmitter),=0A= the docsQos MIB per service-flow counters are not affected in = this=0A= case.=0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 16]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= 2.2.5 docsQosUpstreamStatsTable=0A= =0A= This table provides statistics that are measured only at the CMTS = in=0A= the upstream direction. These include a count of the number of=0A= fragmentation headers received, fragments discarded, and the = number=0A= of concatenation headers received.=0A= =0A= =0A= 2.2.6 docsQosDynamicServiceStatsTable=0A= =0A= This table provides read-only stats on the operation of the = Dynamic=0A= Service state machines as specified in section 9.4 of [4]. It=0A= provides a set of 14 counters *in each direction* for a Docsis = MAC=0A= layer interface. That is, each Docsis MAC layer interface has one = row=0A= for downstream stats, and a second row for upstream stats.=0A= =0A= Eight of the counters are DSx packet type counts, one counter for=0A= each of the eight DSx packet types. For example, the = docsQosDSAReqs=0A= object in the upstream row at the CMTS counts the number of = DSA-REQ=0A= messages received by the CMTS from that interface. The=0A= docsQosDSAReqs object in the downstream row at the CMTS counts = the=0A= number of DSA-REQ messages transmitted by the CMTS on that = interface.=0A= =0A= The remaining six counters per (interface, direction) combination=0A= count the number of successful and unsuccessful *transactions* = that=0A= were initiated on the interface and direction. For example, the=0A= upstream docsQosDynamicAdds on a CMTS is the number of = successfully=0A= completed CM-initiated dynamic additions, because at the CMTS a = CM-=0A= initiated DSA starts in the upstream direction. The downstream=0A= docsQosDynamicAdds at a CMTS is the number of successful CMTS-=0A= initiated DSA transactions.=0A= =0A= Dynamic service transactions can fail for a number of reasons, as=0A= listed in the state machines of section 9.4. Rather than include=0A= still more counters for each different failure reason, they are=0A= grouped into a single count, e.g docsQosDynamicAddFails. Again, = this=0A= object exists in both directions, so that locally originated vs=0A= remotely originated transaction failures are counted separately.=0A= Further troubleshooting of transaction failures will require = vendor-=0A= specific queries and operation.=0A= =0A= =0A= 2.2.7 docsQosServiceFlowLogTable=0A= =0A= This table contains a log of the Service Flows no longer existing = in=0A= the docsQosServiceFlowTable. It is intended to be periodically = polled=0A= by traffic monitoring and billing agents. It is implemented only = at=0A= the CMTS.=0A= =0A= It contains a chronological log of SF session statistics, including = a=0A= total count of packets and octets transferred on the SF. It = includes=0A= =0A= =0A= =0A= Expires July 2003 [Page 17]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= time stamps of the SF creation and deletion time, as well as its=0A= number of active seconds. The active second count is the count of=0A= seconds that the SF had a non-empty Active Qos Parameter Set, i.e. = it=0A= was eligible to pass data. For unicast SFs, it includes the CM = MAC=0A= address associated with the flow for billing reference purposes.=0A= =0A= The maximum number of log records kept by a CMTS, and the = duration=0A= that a log record is maintained in the table is vendor-specific. = An=0A= explicit control object is provided so that the monitoring=0A= application can explicitly delete records it has read.=0A= =0A= =0A= 2.2.8 docsQosServiceClassTable=0A= =0A= This table defines the Service Class Name and references a Qos=0A= Parameter Set for each Service Class defined in a CMTS. It is=0A= indexed by the Service Class Name string itself. The table is = read-=0A= create on a CMTS, and is not implemented in a CM. Each entry of = the=0A= docsQosServiceClassTable should define a template for flows in a=0A= given direction (upstream or downstream). Some parameters of the=0A= docsQosServiceClassTable are specific to a particular direction, = and=0A= so their values are not-applicable when used as a template for = flows=0A= in the other direction.=0A= =0A= =0A= =0A= 2.2.9 docsQosServiceClassPolicyTable=0A= =0A= =0A= The docsQosServiceClassPolicyTable can be referenced by the=0A= docsDevFilterPolicyTable of [9] in order to have a "policy" that=0A= classifies packets to a named Service Class. This is one mechanism = by=0A= which "external" entities (like an SNMP manager) may control the=0A= classification of packet for QOS purposes. Entries are indexed by = a=0A= small integer docsQosServiceClassPolicyIndex. They provide a = Service=0A= Class Name and a Rule Priority. A policy referencing a row of = this=0A= table intends the packet to be forwarded on a Service Flow=0A= "belonging" to the named Service Class. See the section = "Externally=0A= Administered Classification", below.=0A= =0A= This table is implemented on both the CM and CMTS, and is = read-create=0A= on both.=0A= =0A= =0A= 2.2.10 docsQosPHSTable=0A= =0A= The Payload Header Suppression (PHS) feature of DOCSIS 1.1 = permits=0A= packets to replace the unchanging bytes of the Ethernet, IP, and = UDP=0A= headers with a one-byte index when transmitting on the cable = network.=0A= This is especially useful for IP Telephony packets, where such=0A= suppression can result in almost twice the number of calls = supported=0A= =0A= =0A= =0A= Expires July 2003 [Page 18]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= within the same upstream channel.=0A= =0A= Each entry of the table corresponds to a PHS Rule as described in=0A= section 8.4 of [4]. The rules are identified by their = corresponding=0A= service flow ID and docsQosPktClassId. A PHS rule is associated = with=0A= exactly one classifier. The table is therefore indexed by the = tuple=0A= { ifIndex, docsQosServiceFlowId, docsQosPktClassId}.=0A= =0A= This table is read-only, and MUST be implemented on both the CM = and=0A= CMTS when PHS is supported.=0A= =0A= =0A= 2.2.11 docsQosCmtsMacToSrvFlowTable=0A= =0A= The docsQosCmtsMacToSrvFlowTable provides describes the mapping of = CM=0A= mac addresses to the Service Flow Ids that are uniquely = identified=0A= with that CM. External applications may collect statistics on = all=0A= packets flowing through a CM by determining the SFID of all of = its=0A= flows, and then collecting the statistics of packets and bytes = for=0A= each flow.=0A= =0A= Downstream multicast service flows are not indicated in the=0A= docsQosCmtsMacToSrvFlowTable because they are not associated with=0A= only one CM.=0A= =0A= =0A= =0A= =0A= 3. Externally Administered Classification=0A= =0A= Docsis 1.1 provides rich semantics for the classification of = packets=0A= to service flows with it Service Flow Classifier table. Service = Flow=0A= Classifiers may be created statically in the DOCSIS CM = configuration=0A= file, or may be created dynamically with Dynamic Service Addition=0A= (DSA) and Dynamic Service Change (DSC) DOCSIS MAC messages.=0A= =0A= Several major issues arose with the concept of externally=0A= administered classification, i.e. should an external SNMP manager = be=0A= permitted to create classification rows? One problem was the co-=0A= ordination of classifier IDs, since such an approach would = require=0A= either separate classifier ID number spaces or objects to = co-ordinate=0A= both internal and external classifier ID assignments. A more = serious=0A= problem, however, was the requirement that external creation of = SF=0A= Classifiers would require "knowledge" of the individual Service = Flow=0A= ID for service flows by external applications. It was strongly = felt=0A= by the committee that SFIDs should remain an internal Docsis = object,=0A= and not be transmitted as part of protocol flows, e.g. for IP = packet=0A= telephony signaling. Docsis 1.1 introduced the concept of named=0A= Service Classes for ease of administration within a domain of CMs = and=0A= CMTSs. What was desired was to permit external classification of=0A= packets to a Service Class, not a particular Service Flow.=0A= =0A= =0A= =0A= Expires July 2003 [Page 19]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= The DOCSIS committee therefore decided to use the already-defined = IP=0A= Packet Filter Table [9] for the external classification of = packets=0A= for QOS purposes. The docsDevIpPacketFilterTable defines similar=0A= packet matching criteria as docsQosPktClassTable, but it matches = a=0A= packet to an arbitrary "policy set" instead of a particular = Service=0A= Flow. One of the policies in the policy set then selects the = Service=0A= Class of the SF on which to forward the packet. The=0A= docsQosServiceClassPolicyTable of this MIB defines the Service = Class=0A= Name to which a packet is classified.=0A= =0A= The interaction of external and internal packet classification is=0A= depicted below.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 20]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= =0A= =0A= |=0A= | Outbound Pkt=0A= V=0A= docsDevIpFilterTable------> docsDevFilterPolicyTable=0A= | |=0A= | V=0A= | docsQosServiceClassPolicyTable=0A= | |=0A= | Pkt | ServiceClassName,=0A= | | = ServiceClassPolicyRulePriority=0A= V V=0A= +--------------------------------------------------------+=0A= | | DOCSIS MAC LAYER ENTITY | |=0A= | | | Select any |=0A= | V | SFID Y in SCN|=0A= | docsQosPktClassTable <---------------| |=0A= | | | |=0A= | | docsQosPktClassPriority, | |=0A= | | SFID X | |=0A= | V V |=0A= | ----------------------------------------+ |=0A= | | Select the SFID associated with the | |=0A= | | higher of docsQosPktClassPriority or | |=0A= | | docsQosServiceClassPolicyRulePriority | |=0A= | +---------------------------------------+ |=0A= | | |=0A= | V |=0A= | | | | | |=0A= | | | ... | | Service Flows |=0A= | +----+ +----+ |=0A= | SFID X SFID Y |=0A= +--------------------------------------------------------+=0A= =0A= Figure 2: Docsis Packet Classification=0A= =0A= =0A= The processing of an outgoing packet proceeds as follows:=0A= =0A= 1. The packet is first checked for matches with rows of = the=0A= docsDevIpFilterTable. If it matches, the matching row=0A= provides a docsDevFilterPolicyId integer.=0A= =0A= 2. The docsDevFilterPolicyId indexes into one (or more) = rows=0A= of docsDevFilterPolicyTable. Each row provides an=0A= arbitrary RowPointer (docsDevFilterPolicyPtr),=0A= corresponding to a policy to be applied to the packet.=0A= =0A= 3. This MIB defines a docsQosServiceClassPolicyTable = whose=0A= entries may be pointed to by docsDevFilterPolicyPtr in=0A= =0A= =0A= =0A= Expires July 2003 [Page 21]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= order to administratively classify packets to a named=0A= DOCSIS Service Class. The = docsQosServiceClassPolicyEntry=0A= provides a Service Class Name (SCN) as=0A= docsQosServiceClassPolicyName and a classification = rule=0A= priority as docsQosServiceClassPolicyRulePriority. = These=0A= are submitted to the device's Docsis MAC Layer entity as = a=0A= special form of the MAC_DATA.request primitive, as=0A= described in Section E.2.1 of [4].=0A= =0A= 4. The MAC Layer selects an SFID ("Y") of an active = Service=0A= Flow belonging to the named class, choosing an SF=0A= arbitrarily if there is more than one.=0A= =0A= 5. The packet is then classified according to the=0A= docsQosPktClassTable, which may classify the packet to = a=0A= different SFID "X". Associated with the classifier is = a=0A= docsQosPktClassPriority.=0A= =0A= 6. In the event of a conflict between the SCN-determined = SFID=0A= and the classified SFID, the greater of=0A= docsQosPktClassPriority and=0A= docsQosServiceClassPolicyRulePriority determines which=0A= SFID is selected to forward the packet.=0A= =0A= A packet which does not match a = docsQosServiceClassPolicyEntry=0A= is directly submitted to the Docsis MAC layer, where the=0A= docsQosPktClassTable selects the SID on which it is to be=0A= forwarded.=0A= =0A= By convention (in [4]), the "internal" = docsQosPktClassPriority=0A= values should be in the range of 64-191, while the = "external"=0A= priorities may be either in the range 192-255 to override = the=0A= internal classification or the range 0-63 to be overridden = by=0A= internal classification.=0A= =0A= This classification mechanism applies both upstream from the = CM=0A= and downstream from the CMTS.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 22]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= 4. Definitions=0A= =0A= --=0A= -- Docsis QOS Extensions MIB=0A= --=0A= =0A= DOCS-QOS-MIB DEFINITIONS ::=3D BEGIN=0A= =0A= IMPORTS=0A= MODULE-IDENTITY,=0A= OBJECT-TYPE,=0A= Integer32,=0A= Counter32,=0A= Unsigned32,=0A= Counter64=0A= FROM SNMPv2-SMI=0A= =0A= TEXTUAL-CONVENTION,=0A= MacAddress,=0A= RowStatus,=0A= TruthValue,=0A= DisplayString,=0A= TimeStamp=0A= FROM SNMPv2-TC=0A= =0A= OBJECT-GROUP,=0A= MODULE-COMPLIANCE=0A= FROM SNMPv2-CONF=0A= =0A= ifIndex,=0A= InterfaceIndex=0A= FROM IF-MIB=0A= =0A= docsIfMib=0A= FROM DOCS-IF-MIB=0A= =0A= InetAddressType,=0A= InetAddress=0A= FROM INET-ADDRESS-MIB;=0A= =0A= docsQosMIB MODULE-IDENTITY=0A= LAST-UPDATED "200301300000Z" -- January 30, 2003=0A= ORGANIZATION "IETF IPCDN Working Group"=0A= CONTACT-INFO=0A= "=0A= Co-Author: Michael Patrick=0A= Postal: Motorola BCS=0A= 20 Cabot Blvd, MS M2-330=0A= Mansfield, MA 02048-1193=0A= U.S.A.=0A= Phone: +1 508 851 8402=0A= =0A= =0A= =0A= Expires July 2003 [Page 23]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= E-mail: michael.patrick@motorola.com=0A= =0A= Co-Author: William Murwin=0A= Postal: Motorola BCS=0A= 20 Cabot Blvd, MS M2-330=0A= Mansfield, MA 02048-1193=0A= U.S.A.=0A= Phone: +1 508 851 8385=0A= E-mail: w.murwin@motorola.com"=0A= =0A= DESCRIPTION=0A= "This is the management information for=0A= Quality Of Service (QOS) for DOCSIS 1.1."=0A= =0A= REVISION "200301300000Z" -- January 30, 2003=0A= DESCRIPTION=0A= "Published as draft-ietf-ipcdn-qos-mib-07.txt.=0A= =0A= Changes from qos-mib-06 include:=0A= =0A= - Re-routed the docQosMib because of compilation errors.=0A= - Removed obsolete and deprecated objects.=0A= - Renumbered existing objects after removal of=0A= obsolete and deprecated objects.=0A= - Clarified the description for = docsQosServiceFlowPolicedDropPkts.=0A= - Clarified the description for = docsQosServiceFlowPolicedDelayPkts.=0A= - Clarified the description for docsQosPktClassPkts.=0A= - Clarified the description for docsQosServiceFlowOctets.=0A= - Clarified the description for docsQosServiceFlowPkts.=0A= - Clarified the operation of the docsQosServiceClassStatus=0A= and the docsQosServiceClassPolicyStatus objects.=0A= - Changed docsQosPktClassPkts to a 64-bit counter.=0A= - Changed docsQosServiceFlowOctets to a 64-bit counter.=0A= - Changed docsQosServiceFlowPkts to a 64-bit counter.=0A= - Changed docsQosServiceFlowLogPkts to a 64-bit counter.=0A= - Changed docsQosServiceFlowLogOctets to a 64-bit counter.=0A= - Changed the description of the reported default values for = the=0A= docsQosParamSetMaxTrafficBurst and = docsQosParamSetMaxConcatBurst.=0A= - Changed the default values for the = docsQosServiceClassMaxTrafficBurst.=0A= and docsQosServiceClassMaxConcatBurst objects.=0A= - Changed references to the latest Data-Over-Cable=0A= Service Interface Specifications: Radio Frequency=0A= Interface Specification."=0A= REVISION "200111090000Z" -- November 9, 2001=0A= DESCRIPTION=0A= "Published as draft-ietf-ipcdn-qos-mib-06.txt.=0A= =0A= Changes from qos-mib-05 include:=0A= -Deprecated objects that were of type IpAddress=0A= and added new objects that were of type=0A= InetAddressType and InetAddress, to support both=0A= =0A= =0A= =0A= Expires July 2003 [Page 24]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= IPv4 and IPv6 in the docsQosPktClassTable.=0A= -Clarified the default value of the=0A= docsQosPktClassIpDestMask and=0A= docsQosPktClassIpSourceMask.=0A= -Corrected the description of the individual bits=0A= that make up the docsQosParamsSetRequestPolicyOct.=0A= -Corrected the spelling of docsCableMaclayer in the=0A= description of the docsQosServiceFlowLogIfIndex.=0A= -Clarified that some of counters from the=0A= docsQosDynamicServiceStatsTable, include retries.=0A= -Changed references to the latest Data-Over-Cable=0A= Service Interface Specifications: Radio Frequency=0A= Interface Specification.=0A= -Added objects that were removed from earlier=0A= revisions of the mib, as obsolete.=0A= -Clarified the Cable Modem's implementation of the=0A= docsQosParamSetTosAndMask.=0A= -Change the description of objects within the=0A= docsQosServiceClassTable, so that they were no longer=0A= templates for obsolete objects."=0A= REVISION "200103010000Z" -- March 1, 2001=0A= DESCRIPTION=0A= "Published as draft-ietf-ipcdn-qos-mib-05.txt.=0A= =0A= Changes from qos-mib-04 include:=0A= - Changed default value of docsQosPktClassIpSourceMask and=0A= docsQosPktClassIpDestMask to 255.255.255.255. This is the=0A= only functional change of the revision.=0A= - Clarified description of dosQosServiceFlowPkts to avoid=0A= requiring CMs to classify downstream packets.=0A= - Clarified that docsQosServiceFlowPHSUnknowns only applies = to=0A= received packets.=0A= - Clarified that docsQosPktClassBitMap and = docsQosParamSetBitMap=0A= indicate all parameters for both adds and changes."=0A= ::=3D { docsIfMib XXX } -- BPIPlus mib is docsIfMIb = 6=0A= =0A= docsQosMIBObjects OBJECT IDENTIFIER ::=3D { docsQosMIB 1 }=0A= =0A= -- Textual Conventions=0A= IfDirection ::=3D TEXTUAL-CONVENTION=0A= STATUS current=0A= DESCRIPTION "Indicates a direction on an RF MAC interface.=0A= =0A= The value downstream(1) is from Cable Modem=0A= Termination System to Cable Modem.=0A= =0A= The value upstream(2) is from Cable Modem to=0A= Cable Modem Termination System."=0A= SYNTAX INTEGER {=0A= downstream(1),=0A= upstream(2)=0A= =0A= =0A= =0A= Expires July 2003 [Page 25]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= }=0A= =0A= BitRate ::=3D TEXTUAL-CONVENTION=0A= DISPLAY-HINT "d"=0A= STATUS current=0A= DESCRIPTION "The rate of traffic in unit of bits per second.=0A= Used to specify traffic rate for QOS."=0A= SYNTAX Unsigned32=0A= =0A= SchedulingType ::=3D TEXTUAL-CONVENTION=0A= STATUS current=0A= DESCRIPTION "The scheduling service provided by a CMTS for = an=0A= upstream service flow. If the parameter is = omitted=0A= from an upstream QOS Parameter Set, this object = takes=0A= the value of bestEffort (2). This parameter must = be=0A= reported as undefined (1) for downstream QOS = Parameter=0A= Sets."=0A= SYNTAX INTEGER {=0A= undefined (1),=0A= bestEffort (2),=0A= nonRealTimePollingService(3),=0A= realTimePollingService(4),=0A= unsolictedGrantServiceWithAD(5),=0A= unsolictedGrantService(6)=0A= }=0A= =0A= -----------------------------------------------------------------------=0A= --=0A= -- Packet Classifier Table=0A= --=0A= docsQosPktClassTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosPktClassEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes the packet classification=0A= configured on the CM or CMTS.=0A= The model is that a packet either received=0A= as input from an interface or transmitted=0A= for output on an interface may be compared=0A= against an ordered list of rules pertaining to=0A= the packet contents. Each rule is a row of this=0A= table. A matching rule provides a service flow=0A= id to to which the packet is classified.=0A= All rules need to match for a packet to match=0A= a classifier.=0A= =0A= The objects in this row correspond to a set of=0A= Classifier Encoding parameters in a DOCSIS=0A= MAC management message. The = docsQosPktClassBitMap=0A= indicates which particular parameters were = present=0A= in the classifier as signaled in the DOCSIS = message.=0A= =0A= =0A= =0A= Expires July 2003 [Page 26]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= If the referenced parameter was not present=0A= in the signaled DOCSIS 1.1 Classifier, the=0A= corresponding object in this row reports a=0A= value as specified in the DESCRIPTION section.=0A= "=0A= ::=3D { docsQosMIBObjects 1 }=0A= =0A= =0A= docsQosPktClassEntry OBJECT-TYPE=0A= SYNTAX DocsQosPktClassEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "An entry in this table provides a single packet=0A= classifier rule. The index ifIndex is an ifType=0A= of docsCableMaclayer(127)."=0A= INDEX {=0A= ifIndex,=0A= docsQosServiceFlowId,=0A= docsQosPktClassId=0A= }=0A= ::=3D { docsQosPktClassTable 1 }=0A= =0A= =0A= =0A= DocsQosPktClassEntry ::=3D SEQUENCE {=0A= docsQosPktClassId Integer32,=0A= docsQosPktClassDirection IfDirection,=0A= docsQosPktClassPriority Integer32,=0A= docsQosPktClassIpTosLow OCTET STRING,=0A= docsQosPktClassIpTosHigh OCTET STRING,=0A= docsQosPktClassIpTosMask OCTET STRING,=0A= docsQosPktClassIpProtocol Integer32,=0A= docsQosPktClassInetSourceAddrType InetAddressType,=0A= docsQosPktClassInetSourceAddr InetAddress,=0A= docsQosPktClassInetSourceMaskType InetAddressType,=0A= docsQosPktClassInetSourceMask InetAddress,=0A= docsQosPktClassInetDestAddrType InetAddressType,=0A= docsQosPktClassInetDestAddr InetAddress,=0A= docsQosPktClassInetDestMaskType InetAddressType,=0A= docsQosPktClassInetDestMask InetAddress,=0A= docsQosPktClassSourcePortStart Integer32,=0A= docsQosPktClassSourcePortEnd Integer32,=0A= docsQosPktClassDestPortStart Integer32,=0A= docsQosPktClassDestPortEnd Integer32,=0A= docsQosPktClassDestMacAddr MacAddress,=0A= docsQosPktClassDestMacMask MacAddress,=0A= docsQosPktClassSourceMacAddr MacAddress,=0A= docsQosPktClassEnetProtocolType INTEGER,=0A= docsQosPktClassEnetProtocol Integer32,=0A= docsQosPktClassUserPriLow Integer32,=0A= docsQosPktClassUserPriHigh Integer32,=0A= =0A= =0A= =0A= Expires July 2003 [Page 27]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosPktClassVlanId Integer32,=0A= docsQosPktClassState INTEGER,=0A= docsQosPktClassPkts Counter64,=0A= docsQosPktClassBitMap BITS=0A= }=0A= =0A= docsQosPktClassId OBJECT-TYPE=0A= SYNTAX Integer32 (1..65535)=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Index assigned to packet classifier entry by=0A= the CMTS which is unique per service flow."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.3.2"=0A= ::=3D { docsQosPktClassEntry 1 }=0A= =0A= docsQosPktClassDirection OBJECT-TYPE=0A= SYNTAX IfDirection=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Indicates the direction to which the classifier=0A= is applied."=0A= ::=3D { docsQosPktClassEntry 2 }=0A= =0A= docsQosPktClassPriority OBJECT-TYPE=0A= SYNTAX Integer32 (0..255)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The value specifies the order of evaluation=0A= of the classifiers.=0A= The higher the value the higher the priority.=0A= The value of 0 is used as default in=0A= provisioned service flows classifiers.=0A= The default value of 64 is used for dynamic=0A= service flow classifiers.=0A= If the referenced parameter is not present=0A= in a classifier, this object reports the default = value=0A= as defined above."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.3.5"=0A= ::=3D { docsQosPktClassEntry 3 }=0A= =0A= docsQosPktClassIpTosLow OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The low value of a range of TOS byte values.=0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 0."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.1"=0A= ::=3D { docsQosPktClassEntry 4 }=0A= =0A= docsQosPktClassIpTosHigh OBJECT-TYPE=0A= =0A= =0A= =0A= Expires July 2003 [Page 28]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The 8-bit high value of a range of TOS byte=0A= values.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 0."=0A= REFERENCE "SP-RFIv1.1-I07-010829, Appendix C.2.1.5.1"=0A= ::=3D { docsQosPktClassEntry 5 }=0A= =0A= docsQosPktClassIpTosMask OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The mask value is bitwise ANDed with TOS byte=0A= in an IP packet and this value is used check=0A= range checking of TosLow and TosHigh.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 0."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.1"=0A= ::=3D { docsQosPktClassEntry 6 }=0A= =0A= docsQosPktClassIpProtocol OBJECT-TYPE=0A= SYNTAX Integer32 (0..258)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object indicates the value of the IP=0A= Protocol field required for IP packets to match=0A= this rule.=0A= =0A= The value 256 matches traffic with any IP = Protocol=0A= value. The value 257 by convention matches both = TCP=0A= and UDP.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 258."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.2"=0A= ::=3D { docsQosPktClassEntry 7 }=0A= =0A= docsQosPktClassInetSourceAddrType OBJECT-TYPE=0A= SYNTAX InetAddressType=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The type of the internet address for=0A= docsQosPktClassInetSourceAddr. This type must = be=0A= the same as the = docsQosPktClassInetSourceMaskType.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= =0A= =0A= =0A= Expires July 2003 [Page 29]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= ipv4(1)."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.3"=0A= ::=3D { docsQosPktClassEntry 8 }=0A= =0A= docsQosPktClassInetSourceAddr OBJECT-TYPE=0A= SYNTAX InetAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies the value of the IP=0A= Source Address required for packets to match=0A= this rule. An IP packet matches the rule when=0A= the packet ip source address bitwise ANDed=0A= with the docsQosPktClassInetSourceMask value=0A= equals the docsQosPktClassInetSourceAddr value.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= '00000000'H."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.3"=0A= ::=3D { docsQosPktClassEntry 9 }=0A= =0A= docsQosPktClassInetSourceMaskType OBJECT-TYPE=0A= SYNTAX InetAddressType=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The type of the internet address for=0A= docsQosPktClassInetSourceMask. This type must = be=0A= the same as the = docsQosPktClassInetSourceAddrType.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= ipv4(1)."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.4"=0A= ::=3D { docsQosPktClassEntry 10 }=0A= =0A= docsQosPktClassInetSourceMask OBJECT-TYPE=0A= SYNTAX InetAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies which bits of a packet's=0A= IP Source Address that are compared to match=0A= this rule.=0A= An IP packet matches the rule when the packet=0A= source address bitwise ANDed with the=0A= docsQosPktClassInetSourceMask value equals the=0A= docsQosIpPktClassInetSourceAddr value.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= 'FFFFFFFF'H."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.4"=0A= =0A= =0A= =0A= Expires July 2003 [Page 30]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= ::=3D { docsQosPktClassEntry 11 }=0A= =0A= docsQosPktClassInetDestAddrType OBJECT-TYPE=0A= SYNTAX InetAddressType=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The type of the internet address for=0A= docsQosPktClassInetDestAddr. This type must be=0A= the same as the = docsQosPktClassInetDestMaskType.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= ipv4(1)."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.5"=0A= ::=3D { docsQosPktClassEntry 12 }=0A= =0A= docsQosPktClassInetDestAddr OBJECT-TYPE=0A= SYNTAX InetAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies the value of the IP=0A= Destination Address required for packets to = match=0A= this rule. An IP packet matches the rule when=0A= the packet ip destination address=0A= bitwise ANDed with the=0A= docsQosPktClassInetDestMask value=0A= equals the docsQosPktClassInetDestAddr value.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= '00000000'H."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.5"=0A= ::=3D { docsQosPktClassEntry 13 }=0A= =0A= docsQosPktClassInetDestMaskType OBJECT-TYPE=0A= SYNTAX InetAddressType=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The type of the internet address for=0A= docsQosPktClassInetDestMask. This type must be=0A= the same as the = docsQosPktClassInetDestAddrType.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= ipv4(1)."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.6"=0A= ::=3D { docsQosPktClassEntry 14 }=0A= =0A= docsQosPktClassInetDestMask OBJECT-TYPE=0A= SYNTAX InetAddress=0A= MAX-ACCESS read-only=0A= =0A= =0A= =0A= Expires July 2003 [Page 31]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= STATUS current=0A= DESCRIPTION "This object specifies which bits of a packet's=0A= IP Destination Address that are compared to=0A= match this rule.=0A= An IP packet matches the rule when the packet=0A= destination address bitwise ANDed with the=0A= docsQosPktClassInetDestMask value equals the=0A= docsQosIpPktClassInetDestAddr value.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= 'FFFFFFFF'H."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.6"=0A= ::=3D { docsQosPktClassEntry 15 }=0A= =0A= docsQosPktClassSourcePortStart OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies the low end inclusive=0A= range of TCP/UDP source port numbers to which=0A= a packet is compared. This object is irrelevant=0A= for non-TCP/UDP IP packets.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of 0= ."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.7"=0A= ::=3D { docsQosPktClassEntry 16 }=0A= =0A= docsQosPktClassSourcePortEnd OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies the high end inclusive=0A= range of TCP/UDP source port numbers to which=0A= a packet is compared. This object is irrelevant=0A= for non-TCP/UDP IP packets.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= 65535."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.8"=0A= ::=3D { docsQosPktClassEntry 17 }=0A= =0A= docsQosPktClassDestPortStart OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies the low end inclusive=0A= range of TCP/UDP destination port numbers to=0A= which a packet is compared.=0A= =0A= =0A= =0A= Expires July 2003 [Page 32]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 0."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.9"=0A= ::=3D { docsQosPktClassEntry 18 }=0A= =0A= docsQosPktClassDestPortEnd OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies the high end inclusive=0A= range of TCP/UDP destination port numbers to = which=0A= a packet is compared.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= 65535."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.10"=0A= ::=3D { docsQosPktClassEntry 19 }=0A= =0A= docsQosPktClassDestMacAddr OBJECT-TYPE=0A= SYNTAX MacAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "An Ethernet packet matches an entry when its=0A= destination MAC address bitwise ANDed with=0A= docsQosPktClassDestMacMask equals the value of=0A= docsQosPktClassDestMacAddr.=0A= =0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= '000000000000'H.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.1"=0A= ::=3D { docsQosPktClassEntry 20 }=0A= =0A= docsQosPktClassDestMacMask OBJECT-TYPE=0A= SYNTAX MacAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "An Ethernet packet matches an entry when its=0A= destination MAC address bitwise ANDed with=0A= docsQosPktClassDestMacMask equals the value of=0A= docsQosPktClassDestMacAddr.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= '000000000000'H.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.1"=0A= ::=3D { docsQosPktClassEntry 21 }=0A= =0A= =0A= =0A= Expires July 2003 [Page 33]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosPktClassSourceMacAddr OBJECT-TYPE=0A= SYNTAX MacAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "An Ethernet packet matches this entry when its=0A= source MAC address equals the value of=0A= this object.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= 'FFFFFFFFFFFF'H.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.2"=0A= ::=3D { docsQosPktClassEntry 22 }=0A= =0A= docsQosPktClassEnetProtocolType OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= none(0),=0A= ethertype(1),=0A= dsap(2),=0A= mac(3),=0A= all(4)=0A= }=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object indicates the format of the layer 3=0A= protocol id in the Ethernet packet. A value of=0A= none(0) means that the rule does not use the=0A= layer 3 protocol type as a matching criteria.=0A= =0A= A value of ethertype(1) means that the rule=0A= applies only to frames which contains an=0A= EtherType value. Ethertype values are contained=0A= in packets using the Dec-Intel-Xerox (DIX)=0A= encapsulation or the RFC1042 Sub-Network Access=0A= Protocol (SNAP) encapsulation formats.=0A= =0A= A value of dsap(2) means that the rule applies=0A= only to frames using the IEEE802.3=0A= encapsulation format with a Destination Service=0A= Access Point (DSAP) other=0A= than 0xAA (which is reserved for SNAP).=0A= =0A= A value of mac(3) means that the rule applies=0A= only to MAC management messages for MAC = management=0A= messages.=0A= =0A= A value of all(4) means that the rule matches=0A= all Ethernet packets.=0A= =0A= If the Ethernet frame contains an 802.1P/Q Tag=0A= =0A= =0A= =0A= Expires July 2003 [Page 34]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= header (i.e. EtherType 0x8100), this object=0A= applies to the embedded EtherType field within=0A= the 802.1P/Q header.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 0.=0A= =0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.3"=0A= ::=3D { docsQosPktClassEntry 23 }=0A= =0A= docsQosPktClassEnetProtocol OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "If docsQosEthPktClassProtocolType is none(0),=0A= this object is ignored when considering whether=0A= a packet matches the current rule.=0A= =0A= If dosQosPktClassEnetProtocolType is = ethertype(1),=0A= this object gives the 16-bit value of the=0A= EtherType that the packet must match in order to=0A= match the rule.=0A= =0A= If docsQosPktClassEnetProtocolType is dsap(2), = the=0A= lower 8 bits of this object's value must match = the=0A= DSAP byte of the packet in order to match the=0A= rule.=0A= =0A= If docsQosPktClassEnetProtocolType is mac(3), = the=0A= lower 8 bits of this object value represent a=0A= lower bound (inclusive) of MAC management = message=0A= type codes matched, and the upper 8 bits of this=0A= object value represent the upper bound = (inclusive)=0A= of matched MAC message type codes. Certain=0A= message type codes are excluded from matching, = as=0A= specified in the reference.=0A= =0A= If the Ethernet frame contains an 802.1P/Q Tag = header=0A= (i.e. EtherType 0x8100), this object applies to = the=0A= embedded EtherType field within the 802.1P/Q = header.=0A= =0A= If the referenced parameter is not present in = the=0A= classifier, the value of this object is reported as = 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.3"=0A= ::=3D { docsQosPktClassEntry 24 }=0A= =0A= docsQosPktClassUserPriLow OBJECT-TYPE=0A= SYNTAX Integer32 (0..7)=0A= MAX-ACCESS read-only=0A= =0A= =0A= =0A= Expires July 2003 [Page 35]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= STATUS current=0A= DESCRIPTION "This object applies only to Ethernet frames=0A= using the 802.1P/Q tag header (indicated with=0A= EtherType 0x8100). Such frames include a 16-bit=0A= Tag that contains a 3 bit Priority field and=0A= a 12 bit VLAN number.=0A= =0A= Tagged Ethernet packets must have a 3-bit=0A= Priority field within the range of=0A= docsQosPktClassPriLow and docsQosPktClassPriHigh = in=0A= order to match this rule.=0A= =0A= If the referenced parameter is not present in = the=0A= classifier, the value of this object is reported as = 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.1"=0A= ::=3D { docsQosPktClassEntry 25 }=0A= =0A= docsQosPktClassUserPriHigh OBJECT-TYPE=0A= SYNTAX Integer32 (0..7)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object applies only to Ethernet frames=0A= using the 802.1P/Qtag header (indicated with=0A= EtherType 0x8100). Such frames include a 16-bit=0A= Tag that contains a 3 bit Priority field and=0A= a 12 bit VLAN number.=0A= =0A= Tagged Ethernet packets must have a 3-bit=0A= Priority field within the range of=0A= docsQosPktClassPriLow and=0A= docsQosPktClassPriHigh in order to match this=0A= rule.=0A= =0A= If the referenced parameter is not present in = the=0A= classifier, the value of this object is reported=0A= as 7.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.1"=0A= ::=3D { docsQosPktClassEntry 26 }=0A= =0A= docsQosPktClassVlanId OBJECT-TYPE=0A= SYNTAX Integer32 (0..4095)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object applies only to Ethernet frames=0A= using the 802.1P/Q tag header.=0A= =0A= If this object's value is nonzero, tagged=0A= packets must have a VLAN Identifier that matches=0A= the value in order to match the rule.=0A= =0A= =0A= =0A= Expires July 2003 [Page 36]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= Only the least significant 12 bits of this = object's=0A= value are valid.=0A= =0A= If the referenced parameter is not present in = the=0A= classifier, the value of this object is reported=0A= as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.2"=0A= ::=3D { docsQosPktClassEntry 27 }=0A= =0A= docsQosPktClassState OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= active(1),=0A= inactive(2)=0A= }=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object indicates whether or not the = classifier=0A= is enabled to classify packets to a Service = Flow.=0A= =0A= If the referenced parameter is not present in = the=0A= classifier, the value of this object is reported=0A= as active(1).=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.3.6"=0A= ::=3D { docsQosPktClassEntry 28 }=0A= =0A= docsQosPktClassPkts OBJECT-TYPE=0A= SYNTAX Counter64=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object counts the number of packets that = have=0A= been classified using this entry. This=0A= includes all packets delivered to a service flow=0A= maximum rate policing function, whether or not = that=0A= function drops the packets."=0A= ::=3D { docsQosPktClassEntry 29 }=0A= =0A= =0A= docsQosPktClassBitMap OBJECT-TYPE=0A= SYNTAX BITS { -- Reference = SP-RFIv1.1-I09-020830=0A= rulePriority(0), -- Appendix C.2.1.3.4=0A= activationState(1), -- Appendix C.2.1.3.6=0A= ipTos(2), -- Appendix C.2.1.5.1=0A= ipProtocol(3), -- Appendix C.2.1.5.2=0A= ipSourceAddr(4), -- Appendix C.2.1.5.3=0A= ipSourceMask(5), -- Appendix C.2.1.5.4=0A= ipDestAddr(6), -- Appendix C.2.1.5.5=0A= ipDestMask(7), -- Appendix C.2.1.5.6=0A= sourcePortStart(8), -- Appendix C.2.1.5.7=0A= sourcePortEnd(9), -- Appendix C.2.1.5.8=0A= =0A= =0A= =0A= Expires July 2003 [Page 37]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= destPortStart(10), -- Appendix C.2.1.5.9=0A= destPortEnd(11), -- Appendix C.2.1.5.10=0A= destMac(12), -- Appendix C.2.1.6.1=0A= sourceMac(13), -- Appendix C.2.1.6.2=0A= ethertype(14), -- Appendix C.2.1.6.3=0A= userPri(15), -- Appendix C.2.1.7.1=0A= vlanId(16) -- Appendix C.2.1.7.2=0A= }=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "This object indicates which parameter encodings = were=0A= actually present in the DOCSIS packet classifier=0A= encoding signaled in the DOCSIS message that=0A= created or modified the classifier. Note that=0A= Dynamic Service Change messages have replace=0A= semantics, so that all non-default parameters = must=0A= be present whether the classifier is being = created=0A= or changed.=0A= =0A= A bit of of this object is set to 1 if the = parameter=0A= indicated by the comment was present in the = classifier=0A= encoding, and 0 otherwise.=0A= =0A= Note that BITS are encoded most significant bit=0A= first, so that if e.g. bits 6 and 7 are set, this = object=0A= is encoded as the octet string '030000'H.=0A= "=0A= ::=3D { docsQosPktClassEntry 30 }=0A= =0A= --=0A= -- QOS Parameter Set Table=0A= --=0A= docsQosParamSetTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosParamSetEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes the set of DOCSIS 1.1 QOS=0A= parameters defined in a managed device.=0A= =0A= The ifIndex index specifies a DOCSIS MAC Domain.=0A= The docsQosServiceFlowId index specifies a = particular=0A= Service Flow.=0A= The docsQosParamSetType index indicates whether=0A= the active, admitted, or provisioned QOS = Parameter=0A= Set is being described by the row.=0A= =0A= Only the QOS Parameter Sets of Docsis 1.1 = service=0A= flows are represented in this table. Docsis 1.0=0A= QOS service profiles are not represented in this=0A= table.=0A= =0A= =0A= =0A= Expires July 2003 [Page 38]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= Each row corresponds to a DOCSIS QOS Parameter = Set=0A= as signaled via DOCSIS MAC management messages.=0A= Each object in the row corresponds to one or=0A= part of one DOCSIS 1.1 Service Flow Encoding.=0A= The docsQosParamSetBitMap object in the row = indicates=0A= which particular parameters were signaled in=0A= the original registration or dynamic service=0A= request message that created the QOS Parameter = Set.=0A= =0A= In many cases, even if a QOS Parameter Set = parameter=0A= was not signaled, the DOCSIS specification calls=0A= for a default value to be used. That default = value=0A= is reported as the value of the corresponding = object=0A= in this row.=0A= =0A= Many objects are not applicable depending on=0A= the service flow direction or upstream = scheduling=0A= type. The object value reported in this case=0A= is specified in the DESCRIPTION clause.=0A= "=0A= ::=3D { docsQosMIBObjects 2 }=0A= =0A= -- docsQosParamSetEntry { docsQosParamSetTable 1 } was=0A= -- removed in an initial and unimplemented version of this mib.=0A= =0A= docsQosParamSetEntry OBJECT-TYPE=0A= SYNTAX DocsQosParamSetEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION=0A= "A unique set of QOS parameters."=0A= INDEX {=0A= ifIndex, docsQosServiceFlowId, docsQosParamSetType=0A= }=0A= ::=3D { docsQosParamSetTable 1 }=0A= =0A= DocsQosParamSetEntry ::=3D SEQUENCE {=0A= docsQosParamSetServiceClassName DisplayString,=0A= docsQosParamSetPriority Integer32,=0A= docsQosParamSetMaxTrafficRate BitRate,=0A= docsQosParamSetMaxTrafficBurst Unsigned32,=0A= docsQosParamSetMinReservedRate BitRate,=0A= docsQosParamSetMinReservedPkt Integer32,=0A= docsQosParamSetActiveTimeout Integer32,=0A= docsQosParamSetAdmittedTimeout Integer32,=0A= docsQosParamSetMaxConcatBurst Integer32,=0A= docsQosParamSetSchedulingType SchedulingType,=0A= docsQosParamSetNomPollInterval Unsigned32,=0A= docsQosParamSetTolPollJitter Unsigned32,=0A= docsQosParamSetUnsolicitGrantSize Integer32,=0A= docsQosParamSetNomGrantInterval Unsigned32,=0A= =0A= =0A= =0A= Expires July 2003 [Page 39]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosParamSetTolGrantJitter Unsigned32,=0A= docsQosParamSetGrantsPerInterval Integer32,=0A= docsQosParamSetTosAndMask OCTET STRING,=0A= docsQosParamSetTosOrMask OCTET STRING,=0A= docsQosParamSetMaxLatency Unsigned32,=0A= docsQosParamSetType INTEGER,=0A= docsQosParamSetRequestPolicyOct OCTET STRING,=0A= docsQosParamSetBitMap BITS=0A= }=0A= =0A= docsQosParamSetServiceClassName OBJECT-TYPE=0A= SYNTAX DisplayString=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Refers to the Service Class Name that the=0A= parameter set values were derived.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object is a zero length string.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.3.4"=0A= ::=3D { docsQosParamSetEntry 4 }=0A= =0A= docsQosParamSetPriority OBJECT-TYPE=0A= SYNTAX Integer32 (0..7)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The relative priority of a service flow.=0A= Higher numbers indicate higher priority.=0A= This priority should only be used to = differentiate=0A= service flow with identical parameter sets.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object is 0. If the parameter is=0A= not applicable, the reported value is 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.1"=0A= ::=3D { docsQosParamSetEntry 5 }=0A= =0A= docsQosParamSetMaxTrafficRate OBJECT-TYPE=0A= SYNTAX BitRate=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Maximum sustained traffic rate allowed for this=0A= service flow in bits/sec. Must count all MAC = frame=0A= data PDU from the bytes following the MAC header = HCS to=0A= the end of the CRC. The number of bytes=0A= forwarded is limited during any time interval.=0A= The value 0 means no maximum traffic rate is=0A= =0A= =0A= =0A= Expires July 2003 [Page 40]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= enforced. This object applies to both upstream = and=0A= downstream service flows.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object is 0. If the parameter is=0A= not applicable, it is reported as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.2"=0A= ::=3D { docsQosParamSetEntry 6 }=0A= =0A= docsQosParamSetMaxTrafficBurst OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the token bucket size in bytes=0A= for this parameter set. The value is calculated=0A= from the byte following the MAC header HCS to=0A= the end of the CRC. This object is applied in=0A= conjunction with docsQosParamSetMaxTrafficRate = to=0A= calculate maximum sustained traffic rate.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object for scheduling types=0A= bestEffort (2), nonRealTimePollingService(3),=0A= and realTimePollingService(4) is 3044.=0A= =0A= If this parameter is not applicable, it is = reported=0A= as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.3"=0A= ::=3D { docsQosParamSetEntry 7 }=0A= =0A= docsQosParamSetMinReservedRate OBJECT-TYPE=0A= SYNTAX BitRate=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the guaranteed minimum rate in=0A= bits/sec for this parameter set. The value is=0A= calculated from the byte following the MAC=0A= header HCS to the end of the CRC. The default=0A= value of 0 has the meaning that no bandwidth=0A= is reserved.=0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object is 0. If the parameter=0A= is not applicable, it is reported as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.4"=0A= ::=3D { docsQosParamSetEntry 8 }=0A= =0A= =0A= =0A= Expires July 2003 [Page 41]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosParamSetMinReservedPkt OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies an assumed minimum packet size in=0A= bytes for which the = docsQosParamSetMinReservedRate=0A= will be provided. The value is calculated from=0A= the byte following the MAC header HCS to the=0A= end of the CRC.=0A= =0A= If the referenced parameter is omitted from a=0A= DOCSIS QOS parameter set, the default value is=0A= CMTS implementation dependent. In this case, the=0A= CMTS reports the default value it is using and = the=0A= CM reports a value of 0. If the referenced=0A= parameter is not applicable to the direction or=0A= scheduling type of the service flow, both CMTS = and=0A= CM report this object's value as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.5"=0A= ::=3D { docsQosParamSetEntry 9 }=0A= =0A= docsQosParamSetActiveTimeout OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= UNITS "seconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the maximum duration in seconds that=0A= resources remain unused on an active service=0A= flow before CMTS signals that both active and=0A= admitted parameters set are null.=0A= The default value of 0 signifies an=0A= infinite amount of time.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object is 0.=0A= "=0A= =0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.6"=0A= ::=3D { docsQosParamSetEntry 10 }=0A= =0A= docsQosParamSetAdmittedTimeout OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= UNITS "seconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the maximum duration in seconds that=0A= resources remain in admitted state before=0A= resources must be released.=0A= The value of 0 signifies an infinite amount=0A= =0A= =0A= =0A= Expires July 2003 [Page 42]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= of time.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the=0A= default value of this object is 200.=0A= "=0A= =0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.7"=0A= DEFVAL { 200 }=0A= ::=3D { docsQosParamSetEntry 11 }=0A= =0A= docsQosParamSetMaxConcatBurst OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the maximum concatenated burst in=0A= bytes which an upstream service flow is = allowed.=0A= The value is calculated from the FC byte of the=0A= Concatenation MAC Header to the last CRC byte in=0A= of the last concatenated MAC frame, inclusive.=0A= The value of 0 specifies no maximum burst.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object for scheduling types=0A= bestEffort(2), nonRealTimePollingService(3), and=0A= realTimePollongSerivce is 1522. If the parameter = is=0A= not applicable, this object's value is reported=0A= as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.1"=0A= ::=3D { docsQosParamSetEntry 12 }=0A= =0A= =0A= docsQosParamSetSchedulingType OBJECT-TYPE=0A= SYNTAX SchedulingType=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the upstream scheduling service used = for=0A= upstream service flow.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set of an=0A= upstream service flow, the default value of this=0A= object is bestEffort(2). For QOS parameter sets = of=0A= downstream service flows, this object's value is=0A= reported as undefined(1).=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.2"=0A= ::=3D { docsQosParamSetEntry 13 }=0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 43]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosParamSetNomPollInterval OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the nominal interval in microseconds=0A= between successive unicast request=0A= opportunities on an upstream service flow.=0A= =0A= This object applies only to upstream service = flows=0A= with schedulingType of value=0A= nonRealTimePollingService(3),=0A= realTimePollingService(4), and=0A= unsolictedGrantServiceWithAD(5). The parameter = is=0A= mandatory for realTimePollingService(4). If the=0A= parameter is omitted with=0A= nonRealTimePollingService(3), the CMTS uses an=0A= implementation dependent value. If the = parameter=0A= is omitted with unsolictedGrantServiceWithAD(5),=0A= the CMTS uses as a default value the value of = the=0A= Nominal Grant Interval parameter. In all cases,=0A= the CMTS reports the value it is using when the=0A= parameter is applicable. The CM reports the=0A= signaled parameter value if it was signaled,=0A= and 0 otherwise.=0A= =0A= If the referenced parameter is not applicable to=0A= the direction or scheduling type of the=0A= corresponding DOCSIS QOS Parameter Set, both=0A= CMTS and CM report this object's value as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.4"=0A= ::=3D { docsQosParamSetEntry 15 }=0A= =0A= docsQosParamSetTolPollJitter OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the maximum amount of time in=0A= microseconds that the unicast request interval=0A= may be delayed from the nominal periodic=0A= schedule on an upstream service flow.=0A= =0A= This parameter is applicable only to upstream=0A= service flows with a Schedulingtype of=0A= realTimePollingService(4) or=0A= unsolictedGrantServiceWithAD(5).=0A= =0A= If the referenced parameter is applicable but = not=0A= present in the corresponding DOCSIS QOS = Parameter=0A= =0A= =0A= =0A= Expires July 2003 [Page 44]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= Set, the CMTS uses an implementation dependent=0A= value and reports the value it is using.=0A= The CM reports a value of 0 in this case.=0A= =0A= If the parameter is not applicable to the=0A= direction or upstream scheduling type of the=0A= service flow, both CMTS and CM report this=0A= object's value as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.5"=0A= ::=3D { docsQosParamSetEntry 16 }=0A= =0A= docsQosParamSetUnsolicitGrantSize OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the unsolicited grant size in bytes.=0A= The grant size includes the entire MAC frame=0A= data PDU from the Frame Control byte to end of=0A= the MAC frame.=0A= =0A= The referenced parameter is applicable only=0A= for upstream flows with a SchedulingType of=0A= of unsolicitedGrantServicewithAD(5) or=0A= unsolicitedGrantService(6), and is mandatory=0A= when applicable. Both CMTS and CM report=0A= the signaled value of the parameter in this=0A= case.=0A= =0A= If the referenced parameter is not applicable to=0A= the direction or scheduling type of the=0A= corresponding DOCSIS QOS Parameter Set, both=0A= CMTS and CM report this object's value as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.6"=0A= ::=3D { docsQosParamSetEntry 17 }=0A= =0A= docsQosParamSetNomGrantInterval OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the nominal interval in microseconds=0A= between successive data grant opportunities=0A= on an upstream service flow.=0A= =0A= The referenced parameter is applicable only=0A= for upstream flows with a SchedulingType of=0A= of unsolicitedGrantServicewithAD(5) or=0A= unsolicitedGrantService(6), and is mandatory=0A= when applicable. Both CMTS and CM report the=0A= =0A= =0A= =0A= Expires July 2003 [Page 45]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= signaled value of the parameter in this case.=0A= =0A= If the referenced parameter is not applicable to=0A= the direction or scheduling type of the=0A= corresponding DOCSIS QOS Parameter Set, both=0A= CMTS and CM report this object's value as 0.=0A= "=0A= =0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.7"=0A= ::=3D { docsQosParamSetEntry 18 }=0A= =0A= docsQosParamSetTolGrantJitter OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the maximum amount of time in=0A= microseconds that the transmission opportunities=0A= may be delayed from the nominal periodic = schedule.=0A= =0A= The referenced parameter is applicable only=0A= for upstream flows with a SchedulingType of=0A= of unsolicitedGrantServicewithAD(5) or=0A= unsolicitedGrantService(6), and is mandatory=0A= when applicable. Both CMTS and CM report the=0A= signaled value of the parameter in this case.=0A= =0A= If the referenced parameter is not applicable to=0A= the direction or scheduling type of the=0A= corresponding DOCSIS QOS Parameter Set, both=0A= CMTS and CM report this object's value as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.8"=0A= ::=3D { docsQosParamSetEntry 19 }=0A= =0A= docsQosParamSetGrantsPerInterval OBJECT-TYPE=0A= SYNTAX Integer32 (0..127)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the number of data grants per Nominal=0A= Grant Interval=0A= (docsQosParamSetNomGrantInterval).=0A= =0A= The referenced parameter is applicable only=0A= for upstream flows with a SchedulingType of=0A= of unsolicitedGrantServicewithAD(5) or=0A= unsolicitedGrantService(6), and is mandatory=0A= when applicable. Both CMTS and CM report the=0A= signaled value of the parameter in this case.=0A= =0A= If the referenced parameter is not applicable to=0A= =0A= =0A= =0A= Expires July 2003 [Page 46]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= the direction or scheduling type of the=0A= corresponding DOCSIS QOS Parameter Set, both=0A= CMTS and CM report this object's value as 0.=0A= "=0A= =0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.9"=0A= ::=3D { docsQosParamSetEntry 20 }=0A= =0A= docsQosParamSetTosAndMask OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the AND mask for IP TOS byte for = overwriting=0A= IP packets TOS value. The IP packets TOS byte = is=0A= bitwise ANDed with docsQosParamSetTosAndMask and=0A= result is bitwise ORed with = docsQosParamSetTosORMask=0A= and result is written to IP packet TOS byte.=0A= A value of 'FF'H for docsQosParamSetTosAndMask = and=0A= a value of '00'H for docsQosParamSetTosOrMask = means=0A= that IP Packet TOS byte is not overwritten.=0A= =0A= Even though the this object is only enforced by = the=0A= Cable Modem Termination System (CMTS),=0A= Cable Modems must report the value as signaled = in=0A= the referenced parameter.=0A= =0A= This combination is reported if the referenced=0A= parameter is not present in a QOS Parameter = Set."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.10"=0A= ::=3D { docsQosParamSetEntry 21 }=0A= =0A= docsQosParamSetTosOrMask OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the OR mask for IP TOS byte.=0A= See the description of docsQosParamSetTosAndMask=0A= for further details."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.10"=0A= ::=3D { docsQosParamSetEntry 22 }=0A= =0A= docsQosParamSetMaxLatency OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the maximum latency between the=0A= reception of a packet by the CMTS on its NSI=0A= and the forwarding of the packet to the RF=0A= interface. A value of 0 signifies no maximum=0A= latency enforced. This object only applies to=0A= =0A= =0A= =0A= Expires July 2003 [Page 47]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= downstream service flows.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding downstream DOCSIS QOS Parameter = Set,=0A= the default value is 0. This parameter is=0A= not applicable to upstream DOCSIS QOS Parameter = Sets,=0A= and its value is reported as 0 in this case.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.7.1"=0A= ::=3D { docsQosParamSetEntry 23 }=0A= =0A= =0A= docsQosParamSetType OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= active (1),=0A= admitted (2),=0A= provisioned (3)=0A= }=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Defines the type of the QOS parameter set = defined=0A= by this row. active(1) indicates the Active QOS=0A= parameter set, describing the service currently=0A= being provided by the Docsis MAC domain to the=0A= service flow. admitted(2) indicates the Admitted=0A= QOS Parameter Set, describing services reserved = by=0A= by the Docsis MAC domain for use by the service = flow.=0A= provisioned (3) describes the QOS Parameter Set=0A= defined in the DOCSIS CM Configuration file for=0A= the service flow."=0A= REFERENCE "SP-RFIv1.1-I09-020830, 8.1.5"=0A= ::=3D { docsQosParamSetEntry 24 }=0A= =0A= docsQosParamSetRequestPolicyOct OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(4))=0A= -- A 32-bit mask represented most significant = byte=0A= -- first. The 32 bit integer represented in this = manner=0A= -- equals the binary value of the referenced = integer=0A= -- parameter of the DOCSIS RFI specification.=0A= -- The BITS syntax is not used in order to avoid=0A= -- the confusion caused by different bit = numbering=0A= -- conventions.=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies which transmit interval opportunities=0A= the CM omits for upstream transmission requests = and=0A= packet transmissions. This object takes its=0A= default value for downstream service flows.=0A= =0A= Unless otherwise indicated, a bit value of 1 = means=0A= that a CM must *not* use that opportunity for=0A= =0A= =0A= =0A= Expires July 2003 [Page 48]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= upstream transmission.=0A= =0A= Calling bit 0 the least significant bit of the=0A= least significant (4th) octet, and increasing=0A= bit number with significance, the bit = definitions=0A= are as defined below:=0A= =0A= broadcastReqOpp(0):=0A= all CMs broadcast request opportunities=0A= =0A= priorityReqMulticastReq(1):=0A= priority request multicast request = opportunities=0A= =0A= reqDataForReq(2):=0A= request/data opportunities for requests=0A= =0A= reqDataForData(3):=0A= request/data opportunities for data=0A= =0A= piggybackReqWithData(4):=0A= piggyback requests with data=0A= =0A= concatenateData(5):=0A= concatenate data=0A= =0A= fragmentData(6):=0A= fragment data=0A= =0A= suppresspayloadheaders(7):=0A= suppress payload headers=0A= =0A= dropPktsExceedUGSize(8):=0A= A value of 1 mean that service flow must = drop=0A= packet that do not fit in the Unsolicited=0A= Grant size=0A= =0A= If the referenced parameter is not present in=0A= a QOS Parameter Set, the value of this object is=0A= reported as '00000000'H.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.3"=0A= ::=3D { docsQosParamSetEntry 25 }=0A= =0A= docsQosParamSetBitMap OBJECT-TYPE=0A= -- Each bit corresponds to a = parameter=0A= -- from SP-RFI-v1.1-I07-010829, = Appendix C=0A= SYNTAX BITS { -- in the indicated section number.=0A= trafficPriority(0), -- C.2.2.5.1=0A= maxTrafficRate(1), -- C.2.2.5.2=0A= maxTrafficBurst(2), -- C.2.2.5.3=0A= minReservedRate(3), -- C.2.2.5.4=0A= =0A= =0A= =0A= Expires July 2003 [Page 49]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= minReservedPkt(4), -- C.2.2.5.5=0A= activeTimeout(5), -- C.2.2.5.6=0A= admittedTimeout(6), -- C.2.2.5.7=0A= maxConcatBurst(7), -- C.2.2.6.1=0A= schedulingType(8), -- C.2.2.6.2=0A= requestPolicy(9), -- C.2.2.6.3=0A= nomPollInterval(10), -- C.2.2.6.4=0A= tolPollJitter(11), -- C.2.2.6.5=0A= unsolicitGrantSize(12), -- C.2.2.6.6=0A= nomGrantInterval(13), -- C.2.2.6.7=0A= tolGrantJitter(14), -- C.2.2.6.8=0A= grantsPerInterval(15), -- C.2.2.6.9=0A= tosOverwrite(16), -- C.2.2.6.10=0A= maxLatency(17) -- C.2.2.7.1=0A= }=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object indicates the set of QOS Parameter=0A= Set parameters actually signaled in the=0A= DOCSIS registration or dynamic service request=0A= message that created or modified the QOS Parameter = Set.=0A= A bit is set to 1 when the parameter described=0A= by the indicated reference section is present=0A= in the original request.=0A= =0A= Note that when Service Class names are expanded,=0A= the registration or dynamic response message may=0A= contain parameters as expanded by the CMTS based=0A= on a stored service class. These expanded=0A= parameters are *not* indicated by a 1 bit in = this=0A= object.=0A= =0A= Note that even though some QOS Parameter Set=0A= parameters may not be signaled in a message=0A= (so that the paramater's bit in this object is = 0)=0A= the DOCSIS specification calls for default=0A= values to be used. These default values are=0A= reported as the corresponding object's value in=0A= the row.=0A= =0A= Note that BITS objects are encoded most=0A= significant bit first. For example, if bits=0A= 1 and 16 are set, the value of this object=0A= is the octet string '400080'H.=0A= =0A= "=0A= ::=3D { docsQosParamSetEntry 26 }=0A= =0A= --=0A= -- Service Flow Table=0A= --=0A= =0A= =0A= =0A= Expires July 2003 [Page 50]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosServiceFlowTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosServiceFlowEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes the set of Docsis-QOS=0A= Service Flows in a managed device. "=0A= ::=3D { docsQosMIBObjects 3 }=0A= =0A= docsQosServiceFlowEntry OBJECT-TYPE=0A= SYNTAX DocsQosServiceFlowEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Describes a service flow.=0A= An entry in the table exists for each=0A= Service Flow ID. The ifIndex is an=0A= ifType of docsCableMaclayer(127)."=0A= INDEX {=0A= ifIndex,=0A= docsQosServiceFlowId=0A= }=0A= ::=3D { docsQosServiceFlowTable 1 }=0A= =0A= DocsQosServiceFlowEntry ::=3D SEQUENCE {=0A= docsQosServiceFlowId Unsigned32,=0A= docsQosServiceFlowSID Unsigned32,=0A= docsQosServiceFlowDirection IfDirection,=0A= docsQosServiceFlowPrimary TruthValue=0A= }=0A= =0A= docsQosServiceFlowId OBJECT-TYPE=0A= SYNTAX Unsigned32 (1..4294967295)=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "An index assigned to a service flow by CMTS."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.3.2"=0A= ::=3D { docsQosServiceFlowEntry 1 }=0A= =0A= docsQosServiceFlowSID OBJECT-TYPE=0A= SYNTAX Unsigned32 (0..16383)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Service Identifier (SID) assigned to an=0A= admitted or active service flow. This object=0A= reports a value of 0 if a Service Id is not=0A= associated with the service flow. Only active=0A= or admitted upstream service flows will have a=0A= Service Id (SID)."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.3.3"=0A= ::=3D { docsQosServiceFlowEntry 2 }=0A= =0A= docsQosServiceFlowDirection OBJECT-TYPE=0A= =0A= =0A= =0A= Expires July 2003 [Page 51]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= SYNTAX IfDirection=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The direction of the service flow."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.1/2"=0A= ::=3D { docsQosServiceFlowEntry 3 }=0A= =0A= docsQosServiceFlowPrimary OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Object reflects whether service flow is the = primary=0A= or a secondary service flow.=0A= =0A= A primary service flow is the default service = flow=0A= for otherwise unclassified traffic and all MAC=0A= messages."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Section 8.1 "=0A= ::=3D { docsQosServiceFlowEntry 4 }=0A= =0A= --=0A= -- Service Flow Stats Table=0A= --=0A= docsQosServiceFlowStatsTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosServiceFlowStatsEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes statistics associated with = the=0A= Service Flows in a managed device. "=0A= ::=3D { docsQosMIBObjects 4 }=0A= =0A= docsQosServiceFlowStatsEntry OBJECT-TYPE=0A= SYNTAX DocsQosServiceFlowStatsEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Describes a set of service flow statistics.=0A= An entry in the table exists for each=0A= Service Flow ID. The ifIndex is an=0A= ifType of docsCableMaclayer(127)."=0A= INDEX {=0A= ifIndex,=0A= docsQosServiceFlowId=0A= }=0A= ::=3D { docsQosServiceFlowStatsTable 1 }=0A= =0A= DocsQosServiceFlowStatsEntry ::=3D SEQUENCE {=0A= docsQosServiceFlowPkts Counter64,=0A= docsQosServiceFlowOctets Counter64,=0A= docsQosServiceFlowTimeCreated TimeStamp,=0A= docsQosServiceFlowTimeActive Counter32,=0A= docsQosServiceFlowPHSUnknowns Counter32,=0A= =0A= =0A= =0A= Expires July 2003 [Page 52]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosServiceFlowPolicedDropPkts Counter32,=0A= docsQosServiceFlowPolicedDelayPkts Counter32=0A= }=0A= =0A= docsQosServiceFlowPkts OBJECT-TYPE=0A= SYNTAX Counter64=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Packet Data PDUs classified to = this=0A= service flow and forwarded beyond a service flow=0A= maximum rate policing function.=0A= This object does not count MAC-specific=0A= management messages.=0A= CMs not classifying downstream packets may = report=0A= this object's value as 0.=0A= =0A= Particularly for UGS flows, packets sent on the=0A= primary service flow in violation of the UGS = grant=0A= size should be counted only on the primary = service=0A= flow's counters.=0A= =0A= Unclassified upstream user data packets (i.e. = non=0A= MAC-management) forwarded to the default = upstream=0A= service flow should be incremented for this = object.=0A= =0A= This object does include packets counted by=0A= docsQosServiceFlowPolicedDelayPkts, but does not = include=0A= packets counted by = docsQosServiceFlowPolicedDropPkts."=0A= ::=3D { docsQosServiceFlowStatsEntry 1 }=0A= =0A= docsQosServiceFlowOctets OBJECT-TYPE=0A= SYNTAX Counter64=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of octets from the byte after the MAC=0A= header HCS to the end of the CRC for all packets = counted=0A= in the docsQosServiceFlowPkts object for this = row.=0A= Note that this counts the octets after payload = header=0A= suppression has been applied. CMs not classifying = to a=0A= downstream service flow may report this object's=0A= value as 0 for that flow."=0A= ::=3D { docsQosServiceFlowStatsEntry 2 }=0A= =0A= docsQosServiceFlowTimeCreated OBJECT-TYPE=0A= SYNTAX TimeStamp=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The value of sysUpTime when the service flow=0A= was created."=0A= ::=3D { docsQosServiceFlowStatsEntry 3 }=0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 53]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosServiceFlowTimeActive OBJECT-TYPE=0A= SYNTAX Counter32=0A= UNITS "seconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The total time that service flow has been = active."=0A= ::=3D { docsQosServiceFlowStatsEntry 4 }=0A= =0A= docsQosServiceFlowPHSUnknowns OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of packets received on the service = flow=0A= with an unknown payload header suppression = index."=0A= ::=3D { docsQosServiceFlowStatsEntry 5 }=0A= =0A= docsQosServiceFlowPolicedDropPkts OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Packet Data PDUs classified to = this=0A= service flow, but dropped for some reason such = as=0A= violation of the Maximum Sustained Traffic Rate = or=0A= UGS packet exceeding the grant size.=0A= =0A= This object does not count dropped MAC-specific=0A= management messages.=0A= =0A= Dropped unclassified upstream user date packets = (i.e.=0A= non MAC-management) forwarded to the default = upstream=0A= service flow should be incremented for this = object."=0A= ::=3D { docsQosServiceFlowStatsEntry 6 }=0A= =0A= docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object counts only packets delayed in = violation of=0A= the Maximum Sustained Traffic Rate. This object = will=0A= always report a value of 0 for UGS flows because = the=0A= Maximum Sustained Traffic Rate does not apply."=0A= ::=3D { docsQosServiceFlowStatsEntry 7 }=0A= =0A= --=0A= -- Upstream Service Flow Stats Table (CMTS ONLY)=0A= --=0A= docsQosUpstreamStatsTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosUpstreamStatsEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes statistics associated with=0A= =0A= =0A= =0A= Expires July 2003 [Page 54]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= upstream service flows. All counted frames must=0A= be received without an FCS error."=0A= ::=3D { docsQosMIBObjects 5 }=0A= =0A= docsQosUpstreamStatsEntry OBJECT-TYPE=0A= SYNTAX DocsQosUpstreamStatsEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Describes a set of upstream service flow = statistics.=0A= An entry in the table exists for each=0A= upstream Service Flow in a managed device.=0A= The ifIndex is an ifType of = docsCableMaclayer(127)."=0A= INDEX {=0A= ifIndex,=0A= docsQosSID=0A= }=0A= ::=3D { docsQosUpstreamStatsTable 1 }=0A= =0A= DocsQosUpstreamStatsEntry ::=3D SEQUENCE {=0A= docsQosSID Integer32,=0A= docsQosUpstreamFragments Counter32,=0A= docsQosUpstreamFragDiscards Counter32,=0A= docsQosUpstreamConcatBursts Counter32=0A= }=0A= =0A= docsQosSID OBJECT-TYPE=0A= SYNTAX Integer32 (1..16383)=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Identifies a service id for an admitted or = active=0A= upstream service flow."=0A= ::=3D { docsQosUpstreamStatsEntry 1 }=0A= =0A= docsQosUpstreamFragments OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of fragmentation headers received on = an=0A= upstream service flow, regardless of whether=0A= the fragment was correctly reassembled into a=0A= valid packet. "=0A= ::=3D { docsQosUpstreamStatsEntry 2 }=0A= =0A= docsQosUpstreamFragDiscards OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of upstream fragments discarded and = not=0A= assembled into a valid upstream packet."=0A= ::=3D { docsQosUpstreamStatsEntry 3 }=0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 55]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosUpstreamConcatBursts OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of concatenation headers received on = an=0A= upstream service flow."=0A= ::=3D { docsQosUpstreamStatsEntry 4 }=0A= =0A= =0A= --=0A= -- Dynamic Service Stats Table=0A= --=0A= docsQosDynamicServiceStatsTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosDynamicServiceStatsEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes statistics associated with = the=0A= Dynamic Service Flows in a managed device. "=0A= ::=3D { docsQosMIBObjects 6 }=0A= =0A= docsQosDynamicServiceStatsEntry OBJECT-TYPE=0A= SYNTAX DocsQosDynamicServiceStatsEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Describes a set of dynamic service flow = statistics.=0A= Two entries exist for each Docsis mac layer=0A= interface for the upstream and downstream = direction.=0A= On the CMTS, the downstream direction row = indicates=0A= messages transmitted or transactions originated=0A= by the CMTS. The upstream direction row = indicates=0A= messages received or transaction originated by = the=0A= CM. On the CM, the downstream direction row=0A= indicates messages received or transactions=0A= originated by the CMTS. The upstream direction=0A= row indicates messages transmitted by the CM or=0A= transactions originated by the CM.=0A= The ifIndex is an ifType of = docsCableMaclayer(127)."=0A= INDEX {=0A= ifIndex,=0A= docsQosIfDirection=0A= }=0A= ::=3D { docsQosDynamicServiceStatsTable 1 }=0A= =0A= DocsQosDynamicServiceStatsEntry ::=3D SEQUENCE {=0A= docsQosIfDirection IfDirection,=0A= docsQosDSAReqs Counter32,=0A= docsQosDSARsps Counter32,=0A= docsQosDSAAcks Counter32,=0A= docsQosDSCReqs Counter32,=0A= docsQosDSCRsps Counter32,=0A= docsQosDSCAcks Counter32,=0A= =0A= =0A= =0A= Expires July 2003 [Page 56]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosDSDReqs Counter32,=0A= docsQosDSDRsps Counter32,=0A= docsQosDynamicAdds Counter32,=0A= docsQosDynamicAddFails Counter32,=0A= docsQosDynamicChanges Counter32,=0A= docsQosDynamicChangeFails Counter32,=0A= docsQosDynamicDeletes Counter32,=0A= docsQosDynamicDeleteFails Counter32,=0A= docsQosDCCReqs Counter32,=0A= docsQosDCCRsps Counter32,=0A= docsQosDCCAcks Counter32,=0A= docsQosDCCs Counter32,=0A= docsQosDCCFails Counter32=0A= }=0A= =0A= docsQosIfDirection OBJECT-TYPE=0A= SYNTAX IfDirection=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "The direction of interface."=0A= ::=3D { docsQosDynamicServiceStatsEntry 1 }=0A= =0A= docsQosDSAReqs OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Addition Requests,=0A= including retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 2 }=0A= =0A= docsQosDSARsps OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Addition = Responses,=0A= including retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 3 }=0A= =0A= docsQosDSAAcks OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Addition = Acknowledgements,=0A= including retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 4 }=0A= =0A= docsQosDSCReqs OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Change Requests,=0A= =0A= =0A= =0A= Expires July 2003 [Page 57]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= including retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 5 }=0A= =0A= docsQosDSCRsps OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Change Responses,=0A= including retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 6 }=0A= =0A= docsQosDSCAcks OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Change = Acknowledgements,=0A= including retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 7 }=0A= =0A= docsQosDSDReqs OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Delete Requests,=0A= including retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 8 }=0A= =0A= docsQosDSDRsps OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Delete Responses,=0A= including retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 9 }=0A= =0A= docsQosDynamicAdds OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of successful Dynamic Service = Addition=0A= transactions."=0A= ::=3D { docsQosDynamicServiceStatsEntry 10 }=0A= =0A= docsQosDynamicAddFails OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of failed Dynamic Service Addition=0A= transactions."=0A= ::=3D { docsQosDynamicServiceStatsEntry 11 }=0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 58]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosDynamicChanges OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of successful Dynamic Service Change=0A= transactions."=0A= ::=3D { docsQosDynamicServiceStatsEntry 12 }=0A= =0A= docsQosDynamicChangeFails OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of failed Dynamic Service Change=0A= transactions."=0A= ::=3D { docsQosDynamicServiceStatsEntry 13 }=0A= =0A= docsQosDynamicDeletes OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of successful Dynamic Service Delete=0A= transactions."=0A= ::=3D { docsQosDynamicServiceStatsEntry 14 }=0A= =0A= docsQosDynamicDeleteFails OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of failed Dynamic Service Delete=0A= transactions."=0A= ::=3D { docsQosDynamicServiceStatsEntry 15 }=0A= =0A= =0A= docsQosDCCReqs OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Channel Change Request = messages=0A= traversing an interface. This count is nonzero only = on=0A= downstream direction rows. This count should=0A= include number of retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 16 }=0A= =0A= docsQosDCCRsps OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Channel Change Response = messages=0A= traversing an interface. This count is nonzero=0A= only on upstream direction rows. This count = should=0A= include number of retries."=0A= =0A= =0A= =0A= Expires July 2003 [Page 59]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= ::=3D { docsQosDynamicServiceStatsEntry 17 }=0A= =0A= docsQosDCCAcks OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Channel Change = Acknowledgement=0A= messages traversing an interface. This count=0A= is nonzero only on downstream direction rows.=0A= This count should include number of retries."=0A= ::=3D { docsQosDynamicServiceStatsEntry 18 }=0A= =0A= docsQosDCCs OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of successful Dynamic Channel Change=0A= transactions. This count is nonzero only on = downstream=0A= direction rows."=0A= ::=3D { docsQosDynamicServiceStatsEntry 19 }=0A= =0A= docsQosDCCFails OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of failed Dynamic Channel Change=0A= transactions. This count is nonzero only on=0A= downstream direction rows."=0A= ::=3D { docsQosDynamicServiceStatsEntry 20 }=0A= =0A= =0A= --=0A= -- Service Flow Log Table (CMTS ONLY)=0A= --=0A= docsQosServiceFlowLogTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosServiceFlowLogEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table contains a log of the disconnected=0A= Service Flows in a managed device."=0A= ::=3D { docsQosMIBObjects 7 }=0A= =0A= docsQosServiceFlowLogEntry OBJECT-TYPE=0A= SYNTAX DocsQosServiceFlowLogEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "The information regarding a single disconnected=0A= service flow."=0A= INDEX {=0A= docsQosServiceFlowLogIndex=0A= }=0A= =0A= =0A= =0A= Expires July 2003 [Page 60]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= ::=3D { docsQosServiceFlowLogTable 1 }=0A= =0A= DocsQosServiceFlowLogEntry ::=3D SEQUENCE {=0A= docsQosServiceFlowLogIndex Unsigned32,=0A= docsQosServiceFlowLogIfIndex InterfaceIndex,=0A= docsQosServiceFlowLogSFID Unsigned32,=0A= docsQosServiceFlowLogCmMac MacAddress,=0A= docsQosServiceFlowLogPkts Counter64,=0A= docsQosServiceFlowLogOctets Counter64,=0A= docsQosServiceFlowLogTimeDeleted TimeStamp,=0A= docsQosServiceFlowLogTimeCreated TimeStamp,=0A= docsQosServiceFlowLogTimeActive Counter32,=0A= docsQosServiceFlowLogDirection IfDirection,=0A= docsQosServiceFlowLogPrimary TruthValue,=0A= docsQosServiceFlowLogServiceClassName DisplayString,=0A= docsQosServiceFlowLogPolicedDropPkts Counter32,=0A= docsQosServiceFlowLogPolicedDelayPkts Counter32,=0A= docsQosServiceFlowLogControl INTEGER=0A= }=0A= =0A= docsQosServiceFlowLogIndex OBJECT-TYPE=0A= SYNTAX Unsigned32 (1..4294967295)=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Unique index for a logged service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 1 }=0A= =0A= docsQosServiceFlowLogIfIndex OBJECT-TYPE=0A= SYNTAX InterfaceIndex=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The ifIndex of ifType docsCableMaclayer(127)=0A= on the CMTS where the service flow was = present."=0A= ::=3D { docsQosServiceFlowLogEntry 2 }=0A= =0A= docsQosServiceFlowLogSFID OBJECT-TYPE=0A= SYNTAX Unsigned32 (1..4294967295)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The index assigned to the service flow by the = CMTS."=0A= ::=3D { docsQosServiceFlowLogEntry 3 }=0A= =0A= docsQosServiceFlowLogCmMac OBJECT-TYPE=0A= SYNTAX MacAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The MAC address for the cable modem associated = with=0A= the service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 4 }=0A= =0A= docsQosServiceFlowLogPkts OBJECT-TYPE=0A= =0A= =0A= =0A= Expires July 2003 [Page 61]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= SYNTAX Counter64=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of packets counted on this service = flow=0A= after payload header suppression."=0A= ::=3D { docsQosServiceFlowLogEntry 5 }=0A= =0A= docsQosServiceFlowLogOctets OBJECT-TYPE=0A= SYNTAX Counter64=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of octets counted on this service = flow=0A= after payload header suppression."=0A= ::=3D { docsQosServiceFlowLogEntry 6 }=0A= =0A= docsQosServiceFlowLogTimeDeleted OBJECT-TYPE=0A= SYNTAX TimeStamp=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The value of sysUpTime when the service flow=0A= was deleted."=0A= ::=3D { docsQosServiceFlowLogEntry 7 }=0A= =0A= docsQosServiceFlowLogTimeCreated OBJECT-TYPE=0A= SYNTAX TimeStamp=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The value of sysUpTime when the service flow=0A= was created."=0A= ::=3D { docsQosServiceFlowLogEntry 8 }=0A= =0A= docsQosServiceFlowLogTimeActive OBJECT-TYPE=0A= SYNTAX Counter32=0A= UNITS "seconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The total time that service flow was active."=0A= ::=3D { docsQosServiceFlowLogEntry 9 }=0A= =0A= docsQosServiceFlowLogDirection OBJECT-TYPE=0A= SYNTAX IfDirection=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The value of docsQosServiceFlowDirection=0A= for the service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 10 }=0A= =0A= docsQosServiceFlowLogPrimary OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-only=0A= STATUS current=0A= =0A= =0A= =0A= Expires July 2003 [Page 62]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= DESCRIPTION "The value of docsQosServiceFlowPrimary for the=0A= service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 11 }=0A= =0A= docsQosServiceFlowLogServiceClassName OBJECT-TYPE=0A= SYNTAX DisplayString=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The value of docsQosParamSetServiceClassName for=0A= the provisioned QOS Parameter Set of the=0A= service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 12 }=0A= =0A= docsQosServiceFlowLogPolicedDropPkts OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The final value of = docsQosServiceFlowPolicedDropPkts=0A= for the service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 13 }=0A= =0A= docsQosServiceFlowLogPolicedDelayPkts OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The final value of = docsQosServiceFlowPolicedDelayPkts=0A= for the service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 14 }=0A= =0A= docsQosServiceFlowLogControl OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= active(1),=0A= destroy(6)=0A= }=0A= =0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION "Setting this object to the value destroy(6) = removes=0A= this entry from the table.=0A= Reading this object return the value active(1)."=0A= ::=3D { docsQosServiceFlowLogEntry 15 }=0A= =0A= --=0A= -- Service Class Table (CMTS ONLY)=0A= --=0A= docsQosServiceClassTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosServiceClassEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes the set of Docsis-QOS=0A= Service Classes in a CMTS. "=0A= =0A= =0A= =0A= Expires July 2003 [Page 63]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= ::=3D { docsQosMIBObjects 8 }=0A= =0A= docsQosServiceClassEntry OBJECT-TYPE=0A= SYNTAX DocsQosServiceClassEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "A provisioned service class on a CMTS.=0A= Each entry defines a template for certain=0A= DOCSIS QOS Parameter Set values. When a CM=0A= creates or modifies an Admitted QOS Parameter Set for = a=0A= Service Flow, it may reference a Service Class=0A= Name instead of providing explicit QOS Parameter=0A= Set values. In this case, the CMTS populates=0A= the QOS Parameter Set with the applicable=0A= corresponding values from the named Service Class.=0A= Subsequent changes to a Service Class row do *not*=0A= affect the QOS Parameter Set values of any service = flows=0A= already admitted.=0A= =0A= A service class template applies to only=0A= a single direction, as indicated in the=0A= docsQosServiceClassDirection object.=0A= "=0A= INDEX {=0A= docsQosServiceClassName=0A= }=0A= ::=3D { docsQosServiceClassTable 1 }=0A= =0A= DocsQosServiceClassEntry ::=3D SEQUENCE {=0A= docsQosServiceClassName DisplayString,=0A= docsQosServiceClassStatus RowStatus,=0A= docsQosServiceClassPriority Integer32,=0A= docsQosServiceClassMaxTrafficRate BitRate,=0A= docsQosServiceClassMaxTrafficBurst Unsigned32,=0A= docsQosServiceClassMinReservedRate BitRate,=0A= docsQosServiceClassMinReservedPkt Integer32,=0A= docsQosServiceClassMaxConcatBurst Integer32,=0A= docsQosServiceClassNomPollInterval Unsigned32,=0A= docsQosServiceClassTolPollJitter Unsigned32,=0A= docsQosServiceClassUnsolicitGrantSize Integer32,=0A= docsQosServiceClassNomGrantInterval Unsigned32,=0A= docsQosServiceClassTolGrantJitter Unsigned32,=0A= docsQosServiceClassGrantsPerInterval Integer32,=0A= docsQosServiceClassMaxLatency Unsigned32,=0A= docsQosServiceClassActiveTimeout Integer32,=0A= docsQosServiceClassAdmittedTimeout Integer32,=0A= docsQosServiceClassSchedulingType SchedulingType,=0A= docsQosServiceClassRequestPolicy OCTET STRING,=0A= docsQosServiceClassTosAndMask OCTET STRING,=0A= docsQosServiceClassTosOrMask OCTET STRING,=0A= docsQosServiceClassDirection IfDirection=0A= =0A= =0A= =0A= Expires July 2003 [Page 64]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= }=0A= =0A= docsQosServiceClassName OBJECT-TYPE=0A= SYNTAX DisplayString (SIZE(1..15))=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Service Class Name. DOCSIS specifies that the=0A= maximum size is 15 printable ASCII characters = with=0A= a terminating zero. The terminating zero is not=0A= represented in this DisplayString syntax object.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.3.4"=0A= ::=3D { docsQosServiceClassEntry 1 }=0A= =0A= docsQosServiceClassStatus OBJECT-TYPE=0A= SYNTAX RowStatus=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Used to create or delete rows in this table.=0A= There is no restriction on the ability=0A= to change values in this row while the row is = active.=0A= Inactive rows need not be timed out."=0A= ::=3D { docsQosServiceClassEntry 2 }=0A= =0A= docsQosServiceClassPriority OBJECT-TYPE=0A= SYNTAX Integer32 (0..7)=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetPriority."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 3 }=0A= =0A= docsQosServiceClassMaxTrafficRate OBJECT-TYPE=0A= SYNTAX BitRate=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetMaxTrafficRate."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 4 }=0A= =0A= docsQosServiceClassMaxTrafficBurst OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetMaxTrafficBurst."=0A= DEFVAL { 3044 }=0A= ::=3D { docsQosServiceClassEntry 5 }=0A= =0A= docsQosServiceClassMinReservedRate OBJECT-TYPE=0A= SYNTAX BitRate=0A= MAX-ACCESS read-create=0A= =0A= =0A= =0A= Expires July 2003 [Page 65]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSEtMinReservedRate."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 6 }=0A= =0A= docsQosServiceClassMinReservedPkt OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetMinReservedPkt."=0A= ::=3D { docsQosServiceClassEntry 7 }=0A= =0A= docsQosServiceClassMaxConcatBurst OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetMaxConcatBurst."=0A= DEFVAL { 1522 }=0A= ::=3D { docsQosServiceClassEntry 8 }=0A= =0A= docsQosServiceClassNomPollInterval OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetNomPollInterval."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 9 }=0A= =0A= docsQosServiceClassTolPollJitter OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetTolPollJitter."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 10 }=0A= =0A= docsQosServiceClassUnsolicitGrantSize OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetUnsolicitGrantSize."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 11 }=0A= =0A= docsQosServiceClassNomGrantInterval OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= =0A= =0A= =0A= Expires July 2003 [Page 66]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= DESCRIPTION "Template for docsQosParamSetNomGrantInterval."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 12 }=0A= =0A= docsQosServiceClassTolGrantJitter OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetTolGrantJitter."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 13 }=0A= =0A= docsQosServiceClassGrantsPerInterval OBJECT-TYPE=0A= SYNTAX Integer32 (0..127)=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetGrantsPerInterval."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 14 }=0A= =0A= docsQosServiceClassMaxLatency OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetClassMaxLatency."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.7.1"=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 15 }=0A= =0A= docsQosServiceClassActiveTimeout OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= UNITS "seconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetActiveTimeout."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 16 }=0A= =0A= docsQosServiceClassAdmittedTimeout OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= UNITS "seconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetAdmittedTimeout."=0A= DEFVAL { 200 }=0A= ::=3D { docsQosServiceClassEntry 17 }=0A= =0A= docsQosServiceClassSchedulingType OBJECT-TYPE=0A= SYNTAX SchedulingType=0A= =0A= =0A= =0A= Expires July 2003 [Page 67]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetSchedulingType."=0A= DEFVAL { bestEffort }=0A= ::=3D { docsQosServiceClassEntry 18 }=0A= =0A= docsQosServiceClassRequestPolicy OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(4))=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetRequestPolicyOct."=0A= DEFVAL { '00000000'H } -- no bits are set=0A= ::=3D { docsQosServiceClassEntry 19 }=0A= =0A= docsQosServiceClassTosAndMask OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetTosAndMask."=0A= DEFVAL { 'FF'H }=0A= ::=3D { docsQosServiceClassEntry 20 }=0A= =0A= docsQosServiceClassTosOrMask OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetTosOrMask."=0A= DEFVAL { '00'H }=0A= ::=3D { docsQosServiceClassEntry 21 }=0A= =0A= docsQosServiceClassDirection OBJECT-TYPE=0A= SYNTAX IfDirection=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Specifies whether the service class template=0A= applies to upstream or downstream service = flows."=0A= DEFVAL { upstream }=0A= ::=3D { docsQosServiceClassEntry 22 }=0A= =0A= --=0A= -- Service Class PolicyTable=0A= --=0A= docsQosServiceClassPolicyTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosServiceClassPolicyEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes the set of Docsis-QOS=0A= Service Class Policies.=0A= =0A= This table is an adjunct to the=0A= docsDevFilterPolicy table. Entries in=0A= =0A= =0A= =0A= Expires July 2003 [Page 68]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsDevFilterPolicy table can point to=0A= specific rows in this table.=0A= =0A= This table permits mapping a packet to a service=0A= class name of an active service flow so long as=0A= a classifier does not exist at a higher=0A= priority.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix E.2.1"=0A= ::=3D { docsQosMIBObjects 9 }=0A= =0A= docsQosServiceClassPolicyEntry OBJECT-TYPE=0A= SYNTAX DocsQosServiceClassPolicyEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "A service class name policy entry."=0A= INDEX {=0A= docsQosServiceClassPolicyIndex=0A= }=0A= ::=3D { docsQosServiceClassPolicyTable 1 }=0A= =0A= DocsQosServiceClassPolicyEntry ::=3D SEQUENCE {=0A= docsQosServiceClassPolicyIndex Integer32,=0A= docsQosServiceClassPolicyName DisplayString,=0A= docsQosServiceClassPolicyRulePriority Integer32,=0A= docsQosServiceClassPolicyStatus RowStatus=0A= }=0A= =0A= docsQosServiceClassPolicyIndex OBJECT-TYPE=0A= SYNTAX Integer32 (1..2147483647)=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Index value to uniquely identify an entry in=0A= this table."=0A= ::=3D { docsQosServiceClassPolicyEntry 1 }=0A= =0A= docsQosServiceClassPolicyName OBJECT-TYPE=0A= SYNTAX DisplayString=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Service Class Name to identify the name of the=0A= service class flow to which the packet should be=0A= directed."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix E.2.1"=0A= ::=3D { docsQosServiceClassPolicyEntry 2 }=0A= =0A= docsQosServiceClassPolicyRulePriority OBJECT-TYPE=0A= SYNTAX Integer32 (0..255)=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Service Class Policy rule priority for the=0A= =0A= =0A= =0A= Expires July 2003 [Page 69]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= entry."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.3.5"=0A= ::=3D { docsQosServiceClassPolicyEntry 3 }=0A= =0A= docsQosServiceClassPolicyStatus OBJECT-TYPE=0A= SYNTAX RowStatus=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Used to create or delete rows in this table.=0A= This object should not be deleted if it is=0A= reference by an entry in docsDevFilterPolicy.=0A= The reference should be deleted first.=0A= There is no restriction on the ability=0A= to change values in this row while the row is = active.=0A= Inactive rows need not be timed out."=0A= ::=3D { docsQosServiceClassPolicyEntry 4 }=0A= =0A= --=0A= -- Payload Header Suppression(PHS) Table=0A= --=0A= docsQosPHSTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosPHSEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes set of payload header=0A= suppression entries."=0A= ::=3D { docsQosMIBObjects 10 }=0A= =0A= docsQosPHSEntry OBJECT-TYPE=0A= SYNTAX DocsQosPHSEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "A payload header suppression entry.=0A= The ifIndex is an ifType of = docsCableMaclayer(127).=0A= The index docsQosServiceFlowId selects one=0A= service flow from the cable MAC layer = interface.=0A= The docsQosPktClassId index matches an=0A= index of the docsQosPktClassTable.=0A= "=0A= INDEX {=0A= ifIndex,=0A= docsQosServiceFlowId,=0A= docsQosPktClassId=0A= }=0A= ::=3D { docsQosPHSTable 1 }=0A= =0A= DocsQosPHSEntry ::=3D SEQUENCE {=0A= docsQosPHSField OCTET STRING,=0A= docsQosPHSMask OCTET STRING,=0A= docsQosPHSSize Integer32,=0A= docsQosPHSVerify TruthValue,=0A= =0A= =0A= =0A= Expires July 2003 [Page 70]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosPHSIndex Integer32=0A= }=0A= =0A= -- docsQosPHSIndex { docsQosPHSEntry 1 } was=0A= -- moved to docsQosPHSIndex { docsQosPHSEntry 7 }=0A= -- in an ealier revisions of the mib.=0A= =0A= docsQosPHSField OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(0..255))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Payload header suppression field defines the=0A= bytes of the header which must be=0A= suppressed/restored by the sending/receiving=0A= device.=0A= =0A= The number of octets in this object should be=0A= the same as the value of docsQosPHSSize."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.1"=0A= ::=3D { docsQosPHSEntry 2 }=0A= =0A= docsQosPHSMask OBJECT-TYPE=0A= SYNTAX OCTET STRING(SIZE(0..32))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Payload header suppression mask defines the=0A= bit mask which used in combination with the=0A= docsQosPHSField defines which bytes in header=0A= must be suppressed/restored by the sending or=0A= receiving device.=0A= =0A= Each bit of this bit mask corresponds to a byte=0A= in the docsQosPHSField, with the least=0A= significant bit corresponding to first byte of=0A= the docsQosPHSField.=0A= =0A= Each bit of the bit mask specifies whether of=0A= not the corresponding byte should be suppressed=0A= in the packet. A bit value of '1' indicates that=0A= the byte should be suppressed by the sending=0A= device and restored by the receiving device.=0A= A bit value of '0' indicates that=0A= the byte should not be suppressed by the sending=0A= device or restored by the receiving device.=0A= =0A= If the bit mask does not contain a bit for each=0A= byte in the docsQosPHSField then the bit mask is=0A= extended with bit values of '1' to be the=0A= necessary length."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.3"=0A= ::=3D { docsQosPHSEntry 3 }=0A= =0A= =0A= =0A= Expires July 2003 [Page 71]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosPHSSize OBJECT-TYPE=0A= SYNTAX Integer32 (0..255)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Payload header suppression size specifies the=0A= number of bytes in the header to be suppressed=0A= and restored.=0A= =0A= The value of this object must match the number=0A= of bytes in the docsQosPHSField."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.4"=0A= ::=3D { docsQosPHSEntry 4 }=0A= =0A= docsQosPHSVerify OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Payload header suppression verification value of=0A= 'true' the sender must verify docsQosPHSField=0A= is the same as what is contained in the packet=0A= to be suppressed."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.5"=0A= ::=3D { docsQosPHSEntry 5 }=0A= =0A= docsQosPHSIndex OBJECT-TYPE=0A= SYNTAX Integer32 (1..255)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Payload header suppression index uniquely=0A= references the PHS rule for a given service = flow."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.2"=0A= ::=3D { docsQosPHSEntry 6 }=0A= =0A= =0A= --=0A= -- docsQosCmtsMacToSrvFlowTable (CMTS Only)=0A= --=0A= docsQosCmtsMacToSrvFlowTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosCmtsMacToSrvFlowEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table provide for referencing the service = flows=0A= associated with a particular cable modem. This = allows=0A= for indexing into other docsQos tables that are=0A= indexed by docsQosServiceFlowId and ifIndex."=0A= ::=3D { docsQosMIBObjects 11 }=0A= =0A= docsQosCmtsMacToSrvFlowEntry OBJECT-TYPE=0A= SYNTAX DocsQosCmtsMacToSrvFlowEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= =0A= =0A= =0A= Expires July 2003 [Page 72]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= DESCRIPTION "An entry is created by CMTS for each service = flow=0A= connected to this CMTS."=0A= INDEX {=0A= docsQosCmtsCmMac,=0A= docsQosCmtsServiceFlowId=0A= }=0A= ::=3D { docsQosCmtsMacToSrvFlowTable 1 }=0A= =0A= DocsQosCmtsMacToSrvFlowEntry ::=3D SEQUENCE {=0A= docsQosCmtsCmMac MacAddress,=0A= docsQosCmtsServiceFlowId Unsigned32,=0A= docsQosCmtsIfIndex InterfaceIndex=0A= }=0A= =0A= docsQosCmtsCmMac OBJECT-TYPE=0A= SYNTAX MacAddress=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "The MAC address for the referenced CM."=0A= ::=3D { docsQosCmtsMacToSrvFlowEntry 1 }=0A= =0A= docsQosCmtsServiceFlowId OBJECT-TYPE=0A= SYNTAX Unsigned32 (1..4294967295)=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "An index assigned to a service flow by CMTS."=0A= ::=3D { docsQosCmtsMacToSrvFlowEntry 2 }=0A= =0A= docsQosCmtsIfIndex OBJECT-TYPE=0A= SYNTAX InterfaceIndex=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The ifIndex of ifType docsCableMacLayter(127)=0A= on the CMTS that is connected to the Cable = Modem."=0A= ::=3D { docsQosCmtsMacToSrvFlowEntry 3 }=0A= =0A= =0A= --=0A= -- Placeholder for notifications/traps.=0A= --=0A= docsQosNotification OBJECT IDENTIFIER ::=3D { docsQosMIB 2 }=0A= =0A= =0A= --=0A= -- Conformance definitions=0A= --=0A= docsQosConformance OBJECT IDENTIFIER ::=3D { docsQosMIB 3 }=0A= docsQosGroups OBJECT IDENTIFIER ::=3D { docsQosConformance 1 = }=0A= docsQosCompliances OBJECT IDENTIFIER ::=3D { docsQosConformance 2 = }=0A= =0A= docsQosCompliance MODULE-COMPLIANCE=0A= =0A= =0A= =0A= Expires July 2003 [Page 73]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= STATUS current=0A= DESCRIPTION=0A= "The compliance statement for MCNS Cable Modems and=0A= Cable Modem Termination Systems that implement DOCSIS=0A= Service Flows."=0A= =0A= MODULE -- docsQosMIB=0A= MANDATORY-GROUPS { docsQosBaseGroup }=0A= =0A= GROUP docsQosCmtsGroup=0A= DESCRIPTION=0A= "This group is mandatory for only Cable Modem = Termination=0A= Systems (CMTS) and not implemented for Cable Modems."=0A= =0A= GROUP docsQosParamSetGroup=0A= DESCRIPTION=0A= "This group is mandatory for Cable Modem Termination=0A= Systems (CMTS) and Cable Modems. Cable modems only = implement=0A= objects in this group as read-only."=0A= =0A= GROUP docsQosSrvClassPolicyGroup=0A= DESCRIPTION=0A= "This group is optional for Cable Modem Termination=0A= Systems (CMTS) and Cable Modems. This group only needs = to=0A= be implement if policy based service flow = classification=0A= is implemented. See docsDevPolicyTable in=0A= DOCS-CABLE-DEVICE-MIB for more details. "=0A= =0A= GROUP docsQosServiceClassGroup=0A= DESCRIPTION=0A= "The docsQosServiceClassTable group of objects."=0A= =0A= OBJECT docsQosPktClassPkts=0A= DESCRIPTION=0A= "This object only needs to be implemented in entries=0A= that are classifying packets and not policing packets."=0A= =0A= OBJECT docsQosPktClassInetSourceAddrType=0A= -- SYNTAX InetAddressType { ipv4(1) }=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= OBJECT docsQosPktClassInetSourceAddr=0A= SYNTAX InetAddress (SIZE(4))=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= OBJECT docsQosPktClassInetSourceMaskType=0A= -- SYNTAX InetAddressType { ipv4(1) }=0A= =0A= =0A= =0A= Expires July 2003 [Page 74]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= OBJECT docsQosPktClassInetSourceMask=0A= SYNTAX InetAddress (SIZE(4))=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= OBJECT docsQosPktClassInetDestAddrType=0A= -- SYNTAX InetAddressType { ipv4(1) }=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= OBJECT docsQosPktClassInetDestAddr=0A= SYNTAX InetAddress (SIZE(4))=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= OBJECT docsQosPktClassInetDestMaskType=0A= -- SYNTAX InetAddressType { ipv4(1) }=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= OBJECT docsQosPktClassInetDestMask=0A= SYNTAX InetAddress (SIZE(4))=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= ::=3D { docsQosCompliances 1 }=0A= =0A= docsQosBaseGroup OBJECT-GROUP=0A= OBJECTS {=0A= docsQosPktClassDirection,=0A= docsQosPktClassPriority,=0A= docsQosPktClassIpTosLow,=0A= docsQosPktClassIpTosHigh,=0A= docsQosPktClassIpTosMask,=0A= docsQosPktClassIpProtocol,=0A= docsQosPktClassSourcePortStart,=0A= docsQosPktClassSourcePortEnd,=0A= docsQosPktClassDestPortStart,=0A= docsQosPktClassDestPortEnd,=0A= docsQosPktClassDestMacAddr,=0A= docsQosPktClassDestMacMask,=0A= docsQosPktClassSourceMacAddr,=0A= =0A= =0A= =0A= Expires July 2003 [Page 75]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosPktClassEnetProtocolType,=0A= docsQosPktClassEnetProtocol,=0A= docsQosPktClassUserPriLow,=0A= docsQosPktClassUserPriHigh,=0A= docsQosPktClassVlanId,=0A= docsQosPktClassState,=0A= docsQosPktClassPkts,=0A= docsQosPktClassBitMap,=0A= docsQosPktClassInetSourceAddrType,=0A= docsQosPktClassInetSourceAddr,=0A= docsQosPktClassInetSourceMaskType,=0A= docsQosPktClassInetSourceMask,=0A= docsQosPktClassInetDestAddrType,=0A= docsQosPktClassInetDestAddr,=0A= docsQosPktClassInetDestMaskType,=0A= docsQosPktClassInetDestMask,=0A= =0A= docsQosServiceFlowSID,=0A= docsQosServiceFlowDirection,=0A= docsQosServiceFlowPrimary,=0A= =0A= docsQosServiceFlowPkts, -- not sure if CM should implement=0A= docsQosServiceFlowOctets,=0A= docsQosServiceFlowTimeCreated,=0A= docsQosServiceFlowTimeActive,=0A= docsQosServiceFlowPHSUnknowns,=0A= docsQosServiceFlowPolicedDropPkts,=0A= docsQosServiceFlowPolicedDelayPkts,=0A= =0A= docsQosDSAReqs,=0A= docsQosDSARsps,=0A= docsQosDSAAcks,=0A= docsQosDSCReqs,=0A= docsQosDSCRsps,=0A= docsQosDSCAcks,=0A= docsQosDSDReqs,=0A= docsQosDSDRsps,=0A= docsQosDynamicAdds,=0A= docsQosDynamicAddFails,=0A= docsQosDynamicChanges,=0A= docsQosDynamicChangeFails,=0A= docsQosDynamicDeletes,=0A= docsQosDynamicDeleteFails,=0A= docsQosDCCReqs,=0A= docsQosDCCRsps,=0A= docsQosDCCAcks,=0A= docsQosDCCs,=0A= docsQosDCCFails,=0A= =0A= docsQosPHSField,=0A= docsQosPHSMask,=0A= =0A= =0A= =0A= Expires July 2003 [Page 76]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosPHSSize,=0A= docsQosPHSVerify,=0A= docsQosPHSIndex=0A= }=0A= STATUS current=0A= DESCRIPTION=0A= "Group of objects implemented in both Cable Modems and=0A= Cable Modem Termination Systems."=0A= ::=3D { docsQosGroups 1 }=0A= =0A= docsQosParamSetGroup OBJECT-GROUP=0A= OBJECTS {=0A= docsQosParamSetServiceClassName,=0A= docsQosParamSetPriority,=0A= docsQosParamSetMaxTrafficRate,=0A= docsQosParamSetMaxTrafficBurst,=0A= docsQosParamSetMinReservedRate,=0A= docsQosParamSetMinReservedPkt,=0A= docsQosParamSetActiveTimeout,=0A= docsQosParamSetAdmittedTimeout,=0A= docsQosParamSetMaxConcatBurst,=0A= docsQosParamSetSchedulingType,=0A= docsQosParamSetNomPollInterval,=0A= docsQosParamSetTolPollJitter,=0A= docsQosParamSetUnsolicitGrantSize,=0A= docsQosParamSetNomGrantInterval,=0A= docsQosParamSetTolGrantJitter,=0A= docsQosParamSetGrantsPerInterval,=0A= docsQosParamSetTosAndMask,=0A= docsQosParamSetTosOrMask,=0A= docsQosParamSetMaxLatency,=0A= docsQosParamSetRequestPolicyOct,=0A= docsQosParamSetBitMap=0A= }=0A= STATUS current=0A= DESCRIPTION=0A= "Group of objects implemenented in both Cable Modems and=0A= Cable Modem Termination Systems for QOS parameter sets."=0A= ::=3D { docsQosGroups 2 }=0A= =0A= =0A= docsQosCmtsGroup OBJECT-GROUP=0A= OBJECTS {=0A= =0A= docsQosUpstreamFragments,=0A= docsQosUpstreamFragDiscards,=0A= docsQosUpstreamConcatBursts,=0A= =0A= docsQosServiceFlowLogIfIndex,=0A= docsQosServiceFlowLogSFID,=0A= docsQosServiceFlowLogCmMac,=0A= =0A= =0A= =0A= Expires July 2003 [Page 77]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosServiceFlowLogPkts,=0A= docsQosServiceFlowLogOctets,=0A= docsQosServiceFlowLogTimeDeleted,=0A= docsQosServiceFlowLogTimeCreated,=0A= docsQosServiceFlowLogTimeActive,=0A= docsQosServiceFlowLogDirection,=0A= docsQosServiceFlowLogPrimary,=0A= docsQosServiceFlowLogServiceClassName,=0A= docsQosServiceFlowLogPolicedDropPkts,=0A= docsQosServiceFlowLogPolicedDelayPkts,=0A= docsQosServiceFlowLogControl,=0A= =0A= docsQosCmtsIfIndex -- docsQosCmtsMacToSrvFlowTable = required=0A= =0A= }=0A= STATUS current=0A= DESCRIPTION=0A= "Mandatory group of objects implemented only in the CMTS."=0A= ::=3D { docsQosGroups 3 }=0A= =0A= docsQosSrvClassPolicyGroup OBJECT-GROUP=0A= OBJECTS {=0A= docsQosServiceClassPolicyName,=0A= docsQosServiceClassPolicyRulePriority,=0A= docsQosServiceClassPolicyStatus=0A= }=0A= STATUS current=0A= DESCRIPTION=0A= "Group of objects implemented in both Cable Modems and=0A= Cable Modem Termination Systems when supporting policy = based=0A= service flows."=0A= ::=3D { docsQosGroups 4 }=0A= =0A= docsQosServiceClassGroup OBJECT-GROUP=0A= OBJECTS {=0A= docsQosServiceClassStatus,=0A= docsQosServiceClassPriority,=0A= docsQosServiceClassMaxTrafficRate,=0A= docsQosServiceClassMaxTrafficBurst,=0A= docsQosServiceClassMinReservedRate,=0A= docsQosServiceClassMinReservedPkt,=0A= docsQosServiceClassMaxConcatBurst,=0A= docsQosServiceClassNomPollInterval,=0A= docsQosServiceClassTolPollJitter,=0A= docsQosServiceClassUnsolicitGrantSize,=0A= docsQosServiceClassNomGrantInterval,=0A= docsQosServiceClassTolGrantJitter,=0A= docsQosServiceClassGrantsPerInterval,=0A= docsQosServiceClassMaxLatency,=0A= docsQosServiceClassActiveTimeout,=0A= docsQosServiceClassAdmittedTimeout,=0A= =0A= =0A= =0A= Expires July 2003 [Page 78]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosServiceClassSchedulingType,=0A= docsQosServiceClassRequestPolicy,=0A= docsQosServiceClassTosAndMask,=0A= docsQosServiceClassTosOrMask,=0A= docsQosServiceClassDirection=0A= }=0A= STATUS current=0A= DESCRIPTION=0A= "The docsQosServiceClassTable objects. If a CMTS implements=0A= expansion of Service Class Names in a QOS Parameter Set,=0A= this group is mandatory on the CMTS. If the CMTS does not=0A= support Service Class Names, this group may be = unimplemented=0A= in the CMTS. This group is not implemented on the CM.=0A= "=0A= ::=3D { docsQosGroups 5 }=0A= =0A= END=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 79]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= 5. Security Considerations=0A= =0A= =0A= This MIB relates to a agent which will provide metropolitan = public=0A= internet access. As such, improper manipulation of the objects=0A= represented by this MIB may result in denial of service to a = large=0A= number of end-users [9]. Manipulation of the=0A= docsQosServiceClassTable and docsQosServiceClassPolicyTable may = allow=0A= an end-user to increase their service levels, or affect other = end-=0A= users in either a positive or negative manner. In addition,=0A= manipulation of docsQosServiceFlowLogControl could allow an = attacker=0A= to remove logs of packet and byte counts forwarded on a service = flow.=0A= If such logs were used for billing, the attacker would obtain = free=0A= service.=0A= =0A= There are a number of management objects defined in this MIB = module=0A= with a MAX-ACCESS clause of read-write and/or read-create. Such=0A= objects may be considered sensitive or vulnerable in some network=0A= environments. The support for SET operations in a non-secure=0A= environment without proper protection can have a negative effect = on=0A= network operations. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= =0A= o The docsQosServiceClassTable provides a template of QOS=0A= parameters such as maximum rate limits for a named service=0A= class. Changing these parameters would allow an attacker = to=0A= obtain unauthorized class of service.=0A= =0A= o The docsQosServiceClassPolicyTable applies CMTS vendor=0A= proprietary policies for packet forwarding, including=0A= dropping, scheduling, notification, or other policies.=0A= Changing this table could allow an attacker to deny = service=0A= to all subscribers of the CMTS or grant the attacker=0A= unauthorized forwarding policies.=0A= =0A= o The docsQosServiceFlowLogControl object controls the = deletion=0A= of entries in the docsQosServiceFlowLogTable, which acts as = a=0A= historical "detail record" of DOCSIS service flow packets = and=0A= bytes transmitted. Such records may be used for billing=0A= purposes, so the unauthorized deletion of the records can=0A= result in free service.=0A= =0A= Some of the readable objects in this MIB module (i.e., objects with = a=0A= MAX-ACCESS other than not-accessible) may be considered sensitive = or=0A= vulnerable in some network environments. It is thus important to=0A= control even GET access to these objects and possibly to even = encrypt=0A= the values of these objects when sending them over the network = via=0A= SNMP. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= =0A= o Unauthorized SNMP GET access of the docsQosPktClassTable = or=0A= =0A= =0A= =0A= Expires July 2003 [Page 80]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= docsQosPHSTable can allow an attacker to learn IP = addresses=0A= permitted to have enhanced quality of service, for = possible=0A= spoofing. This table typically contains the IP addresses=0A= involved in voice-over-IP sessions, for example.=0A= =0A= o Unauthorized SNMP GET access of the docsQosParamSetTable=0A= allows an attacker to learn the names of service classes=0A= which are permitted to have enhanced QOS service, and the=0A= values of that enhanced service. That name can be = referenced=0A= in an unauthorized DOCSIS cable modem configuration file = to=0A= obtain enhanced service.=0A= =0A= o Unauthorized SNMP GET access of the = docsQosServiceFlowTable=0A= can tell an attacker when service flows are active, e.g.=0A= when a voice-over-IP call is in progress.=0A= =0A= o Unauthorized SNMP GET access of the=0A= docsQosServiceFlowStatsTable, docsQosUpstreamStatsTable,=0A= docsQosDynamicServiceStatsTable, = docsQosServiceFlogLogTable,=0A= and docsQosCmtsMacToSrvFlowTable can tell an attacker the=0A= volume of traffic to and from any service flow in the = system,=0A= resulting in loss of privacy of the amount and direction = of=0A= data transfer.=0A= =0A= SNMP versions prior to SNMPv3 did not include adequate security.=0A= Even if the network itself is secure (for example by using = IPSec),=0A= even then, there is no control as to who on the secure network is=0A= allowed to access and GET/SET (read/change/create/delete) the = objects=0A= in this MIB module. It is RECOMMENDED that implementers consider = the=0A= security features as provided by the SNMPv3 framework (see [12],=0A= section 8), including full support for the SNMPv3 cryptographic=0A= mechanisms (for authentication and privacy). Further, deployment = of=0A= SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is=0A= RECOMMENDED to deploy SNMPv3 and to enable cryptographic = security.=0A= It is then a customer/operator responsibility to ensure that the = SNMP=0A= entity giving access to an instance of this MIB module, is = properly=0A= configured to give access to the objects only to those principals=0A= (users) that have legitimate rights to indeed GET or SET=0A= (change/create/delete) them.=0A= =0A= =0A= =0A= 6. Intellectual Property=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= intellectual property or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described = in=0A= this document or the extent to which any license under such = rights=0A= might or might not be available; neither does it represent that = it=0A= has made any effort to identify any such rights. Information on = the=0A= IETF's procedures with respect to rights in standards-track and=0A= =0A= =0A= =0A= Expires July 2003 [Page 81]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= standards-related documentation can be found in BCP-11. Copies = of=0A= claims of rights made available for publication and any assurances = of=0A= licenses to be made available, or the result of an attempt made = to=0A= obtain a general license or permission for the use of such=0A= proprietary rights by implementers or users of this specification = can=0A= be obtained from the IETF Secretariat.=0A= =0A= The IETF invites any interested party to bring to its attention = any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights which may cover technology that may be required to = practice=0A= this standard. Please address the information to the IETF = Executive=0A= Director.=0A= =0A= =0A= =0A= 7. Acknowledgement=0A= =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society.=0A= =0A= =0A= =0A= 8. Normative References=0A= =0A= [1] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure = of=0A= Management Information for Version 2 (SMIv2)", STD 58,=0A= RFC 2578, April 1999.=0A= =0A= [2] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual=0A= Conventions for SMIv2", STD 58, RFC 2579, April 1999.=0A= =0A= [3] McCloghrie, K., Perkins, D. and J. Schoenwaelder, = "Conformance=0A= Statements for SMIv2", STD 58, RFC 2580, April 1999.=0A= =0A= [4] "Data-Over-Cable Service Interface Specifications:=0A= Radio Frequency Interface Specification = SP-RFIv1.1-I09-020830",=0A= DOCSIS, August 2002, http://www.cablemodem.com/.=0A= =0A= [5] L. Steinberg, "Techniques for Managing Asynchronously = Generated=0A= Alerts", RFC 1224, May 1991.=0A= =0A= [6] "Data-Over-Cable Service Interface Specifications: Operations=0A= Support System Interface Specification = SP-OSSIv1.1-I06-020830",=0A= DOCSIS, August 2002, http://www.cablemodem.com/.=0A= =0A= [7] Bradner, S., "Key words for use in RFCs to Indicate = Requirement=0A= Levels", RFC2119, March 1997.=0A= =0A= [8] "Data-Over-Cable Service Interface Specifications: Baseline=0A= Privacy Plus Interface Specification SP-BPI+-I07-020830",=0A= DOCSIS, August 2002, http://www.cablemodem.com/.=0A= =0A= =0A= =0A= Expires July 2003 [Page 82]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= [9] St. Johns, M., "Cable Device Management Information Base for=0A= DOCSIS compliant Cable Modems and Cable Modem Termination=0A= Systems", RFC 2669, August 1999.=0A= =0A= [10] St. Johns, M., "Radio Frequency (RF) Interface Management=0A= Information Base for MCNS/DOCSIS compliant RF interfaces",=0A= RFC 2670, August 1999.=0A= =0A= [11] Daniele, M. et. al.,"Textual Conventions for Internet = Network=0A= Addresses", RFC 2851, June 2000.=0A= =0A= =0A= =0A= 9. Informative References=0A= =0A= [12] Case, J., Mundy, R., Partain, D. and B. Stewart,=0A= "Introduction and Applicability Statements for Internet-=0A= Standard Management Framework", RFC 3410, December 2002.=0A= =0A= =0A= =0A= 10. Author's Address=0A= =0A= Michael Patrick=0A= Motorola Broadband Communications Sector=0A= 20 Cabot Blvd., MS M2-330=0A= Mansfield, MA 02048=0A= Phone: (508) 851-8402=0A= Email: michael.patrick@motorola.com=0A= =0A= William Murwin=0A= Motorola Broadband Communications Sector=0A= 20 Cabot Blvd., MS M2-330=0A= Mansfield, MA 02048=0A= Phone: (508) 851-8385=0A= Email: w.murwin@motorola.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 83]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT January 2003=0A= =0A= =0A= =0A= 11. Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2001). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished = to=0A= others, and derivative works that comment on or otherwise explain = it=0A= or assist in its implementation may be prepared, copied, = published=0A= and distributed, in whole or in part, without restriction of any=0A= kind, provided that the above copyright notice and this paragraph = are=0A= included on all such copies and derivative works. However, this=0A= document itself may not be modified in any way, such as by = removing=0A= the copyright notice or references to the Internet Society or = other=0A= Internet organizations, except as needed for the purpose of=0A= developing Internet standards in which case the procedures for=0A= copyrights defined in the Internet Standards process must be=0A= followed, or as required to translate it into languages other = than=0A= English.=0A= =0A= The limited permissions granted above are perpetual and will not = be=0A= revoked by the Internet Society or its successors or assigns.=0A= =0A= This document and the information contained herein is provided on = an=0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET = ENGINEERING=0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, = INCLUDING=0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires July 2003 [Page 84]=0A= =0A= =0A= =0A= =0A= ------_=_NextPart_000_01C2C89C.3EED38A4 Content-Type: application/octet-stream; name="qos_07.mib" Content-Disposition: attachment; filename="qos_07.mib" Content-Transfer-Encoding: quoted-printable -- -- Docsis QOS Extensions MIB -- DOCS-QOS-MIB DEFINITIONS ::=3D BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, Unsigned32, Counter64=09 FROM SNMPv2-SMI TEXTUAL-CONVENTION, MacAddress, RowStatus, TruthValue, DisplayString, TimeStamp FROM SNMPv2-TC OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF ifIndex, InterfaceIndex FROM IF-MIB docsIfMib FROM DOCS-IF-MIB InetAddressType, InetAddress FROM INET-ADDRESS-MIB; docsQosMIB MODULE-IDENTITY LAST-UPDATED "200301300000Z" -- January 30, 2003 ORGANIZATION "IETF IPCDN Working Group" CONTACT-INFO " Co-Author: Michael Patrick Postal: Motorola BCS 20 Cabot Blvd, MS M2-330 Mansfield, MA 02048-1193 U.S.A. Phone: +1 508 851 8402 E-mail: michael.patrick@motorola.com Co-Author: William Murwin Postal: Motorola BCS 20 Cabot Blvd, MS M2-330 Mansfield, MA 02048-1193 U.S.A. Phone: +1 508 851 8385 E-mail: w.murwin@motorola.com" DESCRIPTION =20 "This is the management information for Quality Of Service (QOS) for DOCSIS 1.1." REVISION "200301300000Z" -- January 30, 2003 DESCRIPTION "Published as draft-ietf-ipcdn-qos-mib-07.txt. =09 Changes from qos-mib-06 include: =09 - Re-routed the docQosMib because of compilation errors. - Removed obsolete and deprecated objects. - Renumbered existing objects after removal of=20 obsolete and deprecated objects. - Clarified the description for docsQosServiceFlowPolicedDropPkts. - Clarified the description for docsQosServiceFlowPolicedDelayPkts. - Clarified the description for docsQosPktClassPkts. - Clarified the description for docsQosServiceFlowOctets. - Clarified the description for docsQosServiceFlowPkts. - Clarified the operation of the docsQosServiceClassStatus=20 and the docsQosServiceClassPolicyStatus objects. - Changed docsQosPktClassPkts to a 64-bit counter. - Changed docsQosServiceFlowOctets to a 64-bit counter. - Changed docsQosServiceFlowPkts to a 64-bit counter. - Changed docsQosServiceFlowLogPkts to a 64-bit counter. - Changed docsQosServiceFlowLogOctets to a 64-bit counter. - Changed the description of the reported default values for the docsQosParamSetMaxTrafficBurst and docsQosParamSetMaxConcatBurst. - Changed the default values for the = docsQosServiceClassMaxTrafficBurst. and docsQosServiceClassMaxConcatBurst objects.=09 - Changed references to the latest Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification." REVISION "200111090000Z" -- November 9, 2001 DESCRIPTION "Published as draft-ietf-ipcdn-qos-mib-06.txt. Changes from qos-mib-05 include: -Deprecated objects that were of type IpAddress and added new objects that were of type InetAddressType and InetAddress, to support both IPv4 and IPv6 in the docsQosPktClassTable. -Clarified the default value of the docsQosPktClassIpDestMask and docsQosPktClassIpSourceMask. -Corrected the description of the individual bits that make up the docsQosParamsSetRequestPolicyOct. -Corrected the spelling of docsCableMaclayer in the description of the docsQosServiceFlowLogIfIndex. -Clarified that some of counters from the docsQosDynamicServiceStatsTable, include retries. -Changed references to the latest Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification. -Added objects that were removed from earlier revisions of the mib, as obsolete. -Clarified the Cable Modem's implementation of the docsQosParamSetTosAndMask. -Change the description of objects within the docsQosServiceClassTable, so that they were no longer templates for obsolete objects." REVISION "200103010000Z" -- March 1, 2001 DESCRIPTION "Published as draft-ietf-ipcdn-qos-mib-05.txt. Changes from qos-mib-04 include: - Changed default value of docsQosPktClassIpSourceMask and docsQosPktClassIpDestMask to 255.255.255.255. This is the only functional change of the revision. - Clarified description of dosQosServiceFlowPkts to avoid=20 requiring CMs to classify downstream packets. - Clarified that docsQosServiceFlowPHSUnknowns only applies to received packets. - Clarified that docsQosPktClassBitMap and = docsQosParamSetBitMap indicate all parameters for both adds and changes." ::=3D { docsIfMib XXX } -- BPIPlus mib is docsIfMIb = 6 docsQosMIBObjects OBJECT IDENTIFIER ::=3D { docsQosMIB 1 } -- Textual Conventions IfDirection ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates a direction on an RF MAC interface.=20 The value downstream(1) is from Cable Modem=20 Termination System to Cable Modem. =20 The value upstream(2) is from Cable Modem to=20 Cable Modem Termination System." SYNTAX INTEGER { downstream(1), upstream(2) } BitRate ::=3D TEXTUAL-CONVENTION =20 DISPLAY-HINT "d" =20 STATUS current DESCRIPTION "The rate of traffic in unit of bits per second. Used to specify traffic rate for QOS." SYNTAX Unsigned32 SchedulingType ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "The scheduling service provided by a CMTS for an upstream service flow. If the parameter is omitted from an upstream QOS Parameter Set, this object = takes the value of bestEffort (2). This parameter must be reported as undefined (1) for downstream QOS = Parameter Sets." SYNTAX INTEGER { undefined (1), bestEffort (2), nonRealTimePollingService(3), realTimePollingService(4), unsolictedGrantServiceWithAD(5), unsolictedGrantService(6) } ----------------------------------------------------------------------- -- -- Packet Classifier Table -- docsQosPktClassTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsQosPktClassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the packet classification configured on the CM or CMTS. =20 The model is that a packet either received as input from an interface or transmitted=20 for output on an interface may be compared=20 against an ordered list of rules pertaining to the packet contents. Each rule is a row of this table. A matching rule provides a service flow id to to which the packet is classified.=20 All rules need to match for a packet to match=20 a classifier.=20 The objects in this row correspond to a set of Classifier Encoding parameters in a DOCSIS MAC management message. The docsQosPktClassBitMap indicates which particular parameters were present in the classifier as signaled in the DOCSIS = message. If the referenced parameter was not present in the signaled DOCSIS 1.1 Classifier, the corresponding object in this row reports a=20 value as specified in the DESCRIPTION section. " ::=3D { docsQosMIBObjects 1 } =20 docsQosPktClassEntry OBJECT-TYPE SYNTAX DocsQosPktClassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table provides a single packet classifier rule. The index ifIndex is an ifType of docsCableMaclayer(127)." INDEX {=20 ifIndex,=20 docsQosServiceFlowId, docsQosPktClassId } ::=3D { docsQosPktClassTable 1 } DocsQosPktClassEntry ::=3D SEQUENCE { docsQosPktClassId Integer32, docsQosPktClassDirection IfDirection, docsQosPktClassPriority Integer32, docsQosPktClassIpTosLow OCTET STRING, docsQosPktClassIpTosHigh OCTET STRING, docsQosPktClassIpTosMask OCTET STRING, docsQosPktClassIpProtocol Integer32, docsQosPktClassInetSourceAddrType InetAddressType, docsQosPktClassInetSourceAddr InetAddress, docsQosPktClassInetSourceMaskType InetAddressType, docsQosPktClassInetSourceMask InetAddress, docsQosPktClassInetDestAddrType InetAddressType, docsQosPktClassInetDestAddr InetAddress, docsQosPktClassInetDestMaskType InetAddressType, docsQosPktClassInetDestMask InetAddress, =20 docsQosPktClassSourcePortStart Integer32, docsQosPktClassSourcePortEnd Integer32, docsQosPktClassDestPortStart Integer32, docsQosPktClassDestPortEnd Integer32, docsQosPktClassDestMacAddr MacAddress, docsQosPktClassDestMacMask MacAddress, docsQosPktClassSourceMacAddr MacAddress, docsQosPktClassEnetProtocolType INTEGER, =20 docsQosPktClassEnetProtocol Integer32, docsQosPktClassUserPriLow Integer32, docsQosPktClassUserPriHigh Integer32, docsQosPktClassVlanId Integer32, docsQosPktClassState INTEGER, docsQosPktClassPkts Counter64, docsQosPktClassBitMap BITS } docsQosPktClassId OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index assigned to packet classifier entry by=20 the CMTS which is unique per service flow." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.3.2" ::=3D { docsQosPktClassEntry 1 } docsQosPktClassDirection OBJECT-TYPE SYNTAX IfDirection MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the direction to which the classifier=20 is applied." ::=3D { docsQosPktClassEntry 2 } docsQosPktClassPriority OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The value specifies the order of evaluation of the classifiers. The higher the value the higher the priority. The value of 0 is used as default in=20 provisioned service flows classifiers.=20 The default value of 64 is used for dynamic=20 service flow classifiers. If the referenced parameter is not present in a classifier, this object reports the default = value as defined above." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.3.5" ::=3D { docsQosPktClassEntry 3 } docsQosPktClassIpTosLow OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only STATUS current DESCRIPTION "The low value of a range of TOS byte values. If the referenced parameter is not present in a classifier, this object reports the value of = 0." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.1" ::=3D { docsQosPktClassEntry 4 } docsQosPktClassIpTosHigh OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only STATUS current DESCRIPTION "The 8-bit high value of a range of TOS byte values. If the referenced parameter is not present in a classifier, this object reports the value of = 0." REFERENCE "SP-RFIv1.1-I07-010829, Appendix C.2.1.5.1" ::=3D { docsQosPktClassEntry 5 } docsQosPktClassIpTosMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only STATUS current DESCRIPTION "The mask value is bitwise ANDed with TOS byte=20 in an IP packet and this value is used check=20 range checking of TosLow and TosHigh. If the referenced parameter is not present in a classifier, this object reports the value of = 0." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.1" ::=3D { docsQosPktClassEntry 6 } docsQosPktClassIpProtocol OBJECT-TYPE SYNTAX Integer32 (0..258) MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the value of the IP Protocol field required for IP packets to match this rule.=20 The value 256 matches traffic with any IP Protocol=20 value. The value 257 by convention matches both TCP and UDP.=20 If the referenced parameter is not present in a classifier, this object reports the value of = 258." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.2" ::=3D { docsQosPktClassEntry 7 } docsQosPktClassInetSourceAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the internet address for docsQosPktClassInetSourceAddr. This type must be the same as the docsQosPktClassInetSourceMaskType.=09 If the referenced parameter is not present in a classifier, this object reports the value of=20 ipv4(1)." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.3" ::=3D { docsQosPktClassEntry 8 } docsQosPktClassInetSourceAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the value of the IP=20 Source Address required for packets to match this rule. An IP packet matches the rule when the packet ip source address bitwise ANDed with the docsQosPktClassInetSourceMask value equals the docsQosPktClassInetSourceAddr value. If the referenced parameter is not present in a classifier, this object reports the value of=20 '00000000'H." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.3" ::=3D { docsQosPktClassEntry 9 } docsQosPktClassInetSourceMaskType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the internet address for docsQosPktClassInetSourceMask. This type must be the same as the docsQosPktClassInetSourceAddrType.=09 If the referenced parameter is not present in a classifier, this object reports the value of=20 ipv4(1)." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.4" ::=3D { docsQosPktClassEntry 10 } docsQosPktClassInetSourceMask OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies which bits of a packet's IP Source Address that are compared to match this rule.=20 An IP packet matches the rule when the packet=20 source address bitwise ANDed with the docsQosPktClassInetSourceMask value equals the=20 docsQosIpPktClassInetSourceAddr value. If the referenced parameter is not present in a classifier, this object reports the value of=20 'FFFFFFFF'H." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.4" ::=3D { docsQosPktClassEntry 11 } docsQosPktClassInetDestAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the internet address for docsQosPktClassInetDestAddr. This type must be the same as the docsQosPktClassInetDestMaskType.=09 If the referenced parameter is not present in a classifier, this object reports the value of=20 ipv4(1)." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.5" ::=3D { docsQosPktClassEntry 12 } docsQosPktClassInetDestAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the value of the IP=20 Destination Address required for packets to match this rule. An IP packet matches the rule when the packet ip destination address=20 bitwise ANDed with the=20 docsQosPktClassInetDestMask value equals the docsQosPktClassInetDestAddr value. If the referenced parameter is not present in a classifier, this object reports the value of=20 '00000000'H." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.5" ::=3D { docsQosPktClassEntry 13 } docsQosPktClassInetDestMaskType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the internet address for docsQosPktClassInetDestMask. This type must be the same as the docsQosPktClassInetDestAddrType.=09 If the referenced parameter is not present in a classifier, this object reports the value of=20 ipv4(1)." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.6" ::=3D { docsQosPktClassEntry 14 } docsQosPktClassInetDestMask OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies which bits of a packet's IP Destination Address that are compared to=20 match this rule.=20 An IP packet matches the rule when the packet=20 destination address bitwise ANDed with the docsQosPktClassInetDestMask value equals the=20 docsQosIpPktClassInetDestAddr value. If the referenced parameter is not present in a classifier, this object reports the value of=20 'FFFFFFFF'H." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.6" ::=3D { docsQosPktClassEntry 15 } docsQosPktClassSourcePortStart OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the low end inclusive range of TCP/UDP source port numbers to which a packet is compared. This object is irrelevant for non-TCP/UDP IP packets. If the referenced parameter is not present in a classifier, this object reports the value of = 0." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.7" ::=3D { docsQosPktClassEntry 16 } docsQosPktClassSourcePortEnd OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the high end inclusive range of TCP/UDP source port numbers to which a packet is compared. This object is irrelevant for non-TCP/UDP IP packets. If the referenced parameter is not present in a classifier, this object reports the value of=20 65535." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.8" ::=3D { docsQosPktClassEntry 17 } docsQosPktClassDestPortStart OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the low end inclusive range of TCP/UDP destination port numbers to which a packet is compared. If the referenced parameter is not present in a classifier, this object reports the value of = 0." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.9" ::=3D { docsQosPktClassEntry 18 } docsQosPktClassDestPortEnd OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This object specifies the high end inclusive range of TCP/UDP destination port numbers to which a packet is compared. If the referenced parameter is not present in a classifier, this object reports the value of=20 65535." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.10" ::=3D { docsQosPktClassEntry 19 } docsQosPktClassDestMacAddr OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "An Ethernet packet matches an entry when its=20 destination MAC address bitwise ANDed with=20 docsQosPktClassDestMacMask equals the value of=20 docsQosPktClassDestMacAddr. =20 If the referenced parameter is not present in a classifier, this object reports the value of=20 '000000000000'H. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.1" ::=3D { docsQosPktClassEntry 20 } docsQosPktClassDestMacMask OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "An Ethernet packet matches an entry when its=20 destination MAC address bitwise ANDed with=20 docsQosPktClassDestMacMask equals the value of=20 docsQosPktClassDestMacAddr. If the referenced parameter is not present in a classifier, this object reports the value of=20 '000000000000'H. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.1" ::=3D { docsQosPktClassEntry 21 } docsQosPktClassSourceMacAddr OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "An Ethernet packet matches this entry when its=20 source MAC address equals the value of=20 this object. If the referenced parameter is not present in a classifier, this object reports the value of=20 'FFFFFFFFFFFF'H. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.2" ::=3D { docsQosPktClassEntry 22 } docsQosPktClassEnetProtocolType OBJECT-TYPE SYNTAX INTEGER { none(0), ethertype(1), dsap(2), mac(3), all(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the format of the layer 3=20 protocol id in the Ethernet packet. A value of=20 none(0) means that the rule does not use the=20 layer 3 protocol type as a matching criteria. A value of ethertype(1) means that the rule applies only to frames which contains an=20 EtherType value. Ethertype values are contained in packets using the Dec-Intel-Xerox (DIX) encapsulation or the RFC1042 Sub-Network Access Protocol (SNAP) encapsulation formats. A value of dsap(2) means that the rule applies only to frames using the IEEE802.3 encapsulation format with a Destination Service Access Point (DSAP) other=20 than 0xAA (which is reserved for SNAP). A value of mac(3) means that the rule applies=20 only to MAC management messages for MAC management messages. A value of all(4) means that the rule matches all Ethernet packets.=20 If the Ethernet frame contains an 802.1P/Q Tag=20 header (i.e. EtherType 0x8100), this object applies to the embedded EtherType field within=20 the 802.1P/Q header. If the referenced parameter is not present in a classifier, this object reports the value of = 0. =20 " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.3" ::=3D { docsQosPktClassEntry 23 } docsQosPktClassEnetProtocol OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "If docsQosEthPktClassProtocolType is none(0),=20 this object is ignored when considering whether=20 a packet matches the current rule. If dosQosPktClassEnetProtocolType is ethertype(1), this object gives the 16-bit value of the EtherType that the packet must match in order to match the rule. If docsQosPktClassEnetProtocolType is dsap(2), the lower 8 bits of this object's value must match the DSAP byte of the packet in order to match the rule. If docsQosPktClassEnetProtocolType is mac(3), the lower 8 bits of this object value represent a lower bound (inclusive) of MAC management message type codes matched, and the upper 8 bits of this object value represent the upper bound (inclusive) of matched MAC message type codes. Certain message type codes are excluded from matching, as specified in the reference. If the Ethernet frame contains an 802.1P/Q Tag = header=20 (i.e. EtherType 0x8100), this object applies to the = embedded EtherType field within the 802.1P/Q = header. If the referenced parameter is not present in the classifier, the value of this object is reported as = 0. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.3" ::=3D { docsQosPktClassEntry 24 } docsQosPktClassUserPriLow OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS read-only STATUS current DESCRIPTION "This object applies only to Ethernet frames=20 using the 802.1P/Q tag header (indicated with=20 EtherType 0x8100). Such frames include a 16-bit=20 Tag that contains a 3 bit Priority field and a 12 bit VLAN number. Tagged Ethernet packets must have a 3-bit Priority field within the range of=20 docsQosPktClassPriLow and docsQosPktClassPriHigh in = order to match this rule. If the referenced parameter is not present in the classifier, the value of this object is reported as = 0. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.1" ::=3D { docsQosPktClassEntry 25 } docsQosPktClassUserPriHigh OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS read-only STATUS current DESCRIPTION "This object applies only to Ethernet frames=20 using the 802.1P/Qtag header (indicated with=20 EtherType 0x8100). Such frames include a 16-bit=20 Tag that contains a 3 bit Priority field and a 12 bit VLAN number. Tagged Ethernet packets must have a 3-bit Priority field within the range of=20 docsQosPktClassPriLow and=20 docsQosPktClassPriHigh in order to match this rule. If the referenced parameter is not present in the classifier, the value of this object is reported=20 as 7. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.1" ::=3D { docsQosPktClassEntry 26 } docsQosPktClassVlanId OBJECT-TYPE SYNTAX Integer32 (0..4095) MAX-ACCESS read-only STATUS current DESCRIPTION "This object applies only to Ethernet frames=20 using the 802.1P/Q tag header. If this object's value is nonzero, tagged packets must have a VLAN Identifier that matches the value in order to match the rule. Only the least significant 12 bits of this object's value are valid.=20 If the referenced parameter is not present in the classifier, the value of this object is reported=20 as 0. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.2" ::=3D { docsQosPktClassEntry 27 } docsQosPktClassState OBJECT-TYPE SYNTAX INTEGER { active(1), inactive(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether or not the classifier is enabled to classify packets to a Service Flow. If the referenced parameter is not present in the classifier, the value of this object is reported=20 as active(1). " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.3.6" ::=3D { docsQosPktClassEntry 28 } docsQosPktClassPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of packets that have been classified using this entry. This=20 includes all packets delivered to a service flow=20 maximum rate policing function, whether or not that function drops the packets." ::=3D { docsQosPktClassEntry 29 } docsQosPktClassBitMap OBJECT-TYPE SYNTAX BITS { -- Reference = SP-RFIv1.1-I09-020830 rulePriority(0), -- Appendix C.2.1.3.4 activationState(1), -- Appendix C.2.1.3.6 ipTos(2), -- Appendix C.2.1.5.1 ipProtocol(3), -- Appendix C.2.1.5.2 ipSourceAddr(4), -- Appendix C.2.1.5.3 ipSourceMask(5), -- Appendix C.2.1.5.4 ipDestAddr(6), -- Appendix C.2.1.5.5 ipDestMask(7), -- Appendix C.2.1.5.6 sourcePortStart(8), -- Appendix C.2.1.5.7 sourcePortEnd(9), -- Appendix C.2.1.5.8 destPortStart(10), -- Appendix C.2.1.5.9 destPortEnd(11), -- Appendix C.2.1.5.10 destMac(12), -- Appendix C.2.1.6.1 sourceMac(13), -- Appendix C.2.1.6.2 ethertype(14), -- Appendix C.2.1.6.3 userPri(15), -- Appendix C.2.1.7.1 vlanId(16) -- Appendix C.2.1.7.2 } MAX-ACCESS read-only STATUS current DESCRIPTION=20 "This object indicates which parameter encodings = were actually present in the DOCSIS packet classifier encoding signaled in the DOCSIS message that created or modified the classifier. Note that Dynamic Service Change messages have replace semantics, so that all non-default parameters must be present whether the classifier is being created or changed. A bit of of this object is set to 1 if the = parameter indicated by the comment was present in the = classifier=20 encoding, and 0 otherwise. Note that BITS are encoded most significant bit first, so that if e.g. bits 6 and 7 are set, this = object is encoded as the octet string '030000'H. " ::=3D { docsQosPktClassEntry 30 } =20 -- -- QOS Parameter Set Table -- docsQosParamSetTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsQosParamSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the set of DOCSIS 1.1 QOS=20 parameters defined in a managed device. =20 The ifIndex index specifies a DOCSIS MAC Domain. The docsQosServiceFlowId index specifies a = particular Service Flow.=20 The docsQosParamSetType index indicates whether the active, admitted, or provisioned QOS Parameter=20 Set is being described by the row. Only the QOS Parameter Sets of Docsis 1.1 service flows are represented in this table. Docsis 1.0 QOS service profiles are not represented in this table. Each row corresponds to a DOCSIS QOS Parameter Set as signaled via DOCSIS MAC management messages. Each object in the row corresponds to one or=20 part of one DOCSIS 1.1 Service Flow Encoding. The docsQosParamSetBitMap object in the row = indicates which particular parameters were signaled in=20 the original registration or dynamic service request message that created the QOS Parameter Set. In many cases, even if a QOS Parameter Set = parameter was not signaled, the DOCSIS specification calls for a default value to be used. That default value is reported as the value of the corresponding = object in this row. Many objects are not applicable depending on the service flow direction or upstream scheduling type. The object value reported in this case is specified in the DESCRIPTION clause. " ::=3D { docsQosMIBObjects 2 } -- docsQosParamSetEntry { docsQosParamSetTable 1 } was=20 -- removed in an initial and unimplemented version of this mib. =20 docsQosParamSetEntry OBJECT-TYPE SYNTAX DocsQosParamSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique set of QOS parameters." INDEX {=20 ifIndex, docsQosServiceFlowId, docsQosParamSetType } ::=3D { docsQosParamSetTable 1 } DocsQosParamSetEntry ::=3D SEQUENCE { =20 docsQosParamSetServiceClassName DisplayString, docsQosParamSetPriority Integer32, docsQosParamSetMaxTrafficRate BitRate, docsQosParamSetMaxTrafficBurst Unsigned32, docsQosParamSetMinReservedRate BitRate, docsQosParamSetMinReservedPkt Integer32, docsQosParamSetActiveTimeout Integer32, docsQosParamSetAdmittedTimeout Integer32, docsQosParamSetMaxConcatBurst Integer32, docsQosParamSetSchedulingType SchedulingType, docsQosParamSetNomPollInterval Unsigned32, docsQosParamSetTolPollJitter Unsigned32, docsQosParamSetUnsolicitGrantSize Integer32, docsQosParamSetNomGrantInterval Unsigned32, docsQosParamSetTolGrantJitter Unsigned32, docsQosParamSetGrantsPerInterval Integer32, docsQosParamSetTosAndMask OCTET STRING, docsQosParamSetTosOrMask OCTET STRING, docsQosParamSetMaxLatency Unsigned32, docsQosParamSetType INTEGER, docsQosParamSetRequestPolicyOct OCTET STRING, docsQosParamSetBitMap BITS } docsQosParamSetServiceClassName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "Refers to the Service Class Name that the=20 parameter set values were derived. If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default = value of this object is a zero length string. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.3.4" ::=3D { docsQosParamSetEntry 4 } docsQosParamSetPriority OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS read-only STATUS current DESCRIPTION "The relative priority of a service flow. Higher numbers indicate higher priority. This priority should only be used to differentiate service flow with identical parameter sets. If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default = value of this object is 0. If the parameter is not applicable, the reported value is 0. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.1" ::=3D { docsQosParamSetEntry 5 } docsQosParamSetMaxTrafficRate OBJECT-TYPE SYNTAX BitRate MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum sustained traffic rate allowed for this=20 service flow in bits/sec. Must count all MAC frame=20 data PDU from the bytes following the MAC header = HCS to the end of the CRC. The number of bytes=20 forwarded is limited during any time interval. The value 0 means no maximum traffic rate is=20 enforced. This object applies to both upstream and downstream service flows. If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default value of this object is 0. If the parameter is not applicable, it is reported as 0. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.2" ::=3D { docsQosParamSetEntry 6 } docsQosParamSetMaxTrafficBurst OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the token bucket size in bytes for this parameter set. The value is calculated=20 from the byte following the MAC header HCS to=20 the end of the CRC. This object is applied in=20 conjunction with docsQosParamSetMaxTrafficRate to=20 calculate maximum sustained traffic rate. If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default value of this object for scheduling types bestEffort (2), nonRealTimePollingService(3), and realTimePollingService(4) is 3044.=20 If this parameter is not applicable, it is reported as 0. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.3" ::=3D { docsQosParamSetEntry 7 } docsQosParamSetMinReservedRate OBJECT-TYPE SYNTAX BitRate MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the guaranteed minimum rate in bits/sec for this parameter set. The value is=20 calculated from the byte following the MAC=20 header HCS to the end of the CRC. The default value of 0 has the meaning that no bandwidth=20 is reserved. If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default value of this object is 0. If the parameter is not applicable, it is reported as 0. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.4" ::=3D { docsQosParamSetEntry 8 } docsQosParamSetMinReservedPkt OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies an assumed minimum packet size in=20 bytes for which the docsQosParamSetMinReservedRate=20 will be provided. The value is calculated from the byte following the MAC header HCS to the=20 end of the CRC.=20 =20 If the referenced parameter is omitted from a DOCSIS QOS parameter set, the default value is CMTS implementation dependent. In this case, the CMTS reports the default value it is using and the CM reports a value of 0. If the referenced parameter is not applicable to the direction or scheduling type of the service flow, both CMTS and CM report this object's value as 0. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.5" ::=3D { docsQosParamSetEntry 9 } docsQosParamSetActiveTimeout OBJECT-TYPE SYNTAX Integer32 (0..65535) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum duration in seconds that=20 resources remain unused on an active service flow before CMTS signals that both active and admitted parameters set are null. The default value of 0 signifies an infinite amount of time. =20 If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default value of this object is 0. " =20 REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.6" ::=3D { docsQosParamSetEntry 10 } docsQosParamSetAdmittedTimeout OBJECT-TYPE SYNTAX Integer32 (0..65535) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum duration in seconds that=20 resources remain in admitted state before=20 resources must be released. The value of 0 signifies an infinite amount=20 of time. If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the=20 default value of this object is 200. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.7" DEFVAL { 200 } ::=3D { docsQosParamSetEntry 11 } docsQosParamSetMaxConcatBurst OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum concatenated burst in bytes which an upstream service flow is allowed.=20 The value is calculated from the FC byte of the Concatenation MAC Header to the last CRC byte in=20 of the last concatenated MAC frame, inclusive. The value of 0 specifies no maximum burst. If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set, the default value of this object for scheduling types bestEffort(2), nonRealTimePollingService(3), and realTimePollongSerivce is 1522. If the parameter is not applicable, this object's value is reported as 0. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.1" ::=3D { docsQosParamSetEntry 12 } docsQosParamSetSchedulingType OBJECT-TYPE SYNTAX SchedulingType MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the upstream scheduling service used for=20 upstream service flow.=20 If the referenced parameter is not present in the corresponding DOCSIS QOS Parameter Set of an upstream service flow, the default value of this object is bestEffort(2). For QOS parameter sets of downstream service flows, this object's value is reported as undefined(1). " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.2" ::=3D { docsQosParamSetEntry 13 } docsQosParamSetNomPollInterval OBJECT-TYPE SYNTAX Unsigned32=20 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the nominal interval in microseconds=20 between successive unicast request opportunities on an upstream service flow. This object applies only to upstream service flows with schedulingType of value nonRealTimePollingService(3), realTimePollingService(4), and unsolictedGrantServiceWithAD(5). The parameter is mandatory for realTimePollingService(4). If the parameter is omitted with nonRealTimePollingService(3), the CMTS uses an implementation dependent value. If the parameter is omitted with unsolictedGrantServiceWithAD(5), the CMTS uses as a default value the value of the Nominal Grant Interval parameter. In all cases, the CMTS reports the value it is using when the parameter is applicable. The CM reports the=20 signaled parameter value if it was signaled,=20 and 0 otherwise. =20 If the referenced parameter is not applicable to the direction or scheduling type of the corresponding DOCSIS QOS Parameter Set, both CMTS and CM report this object's value as 0. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.4" ::=3D { docsQosParamSetEntry 15 } docsQosParamSetTolPollJitter OBJECT-TYPE SYNTAX Unsigned32=20 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum amount of time in microseconds that the unicast request interval may be delayed from the nominal periodic schedule on an upstream service flow. This parameter is applicable only to upstream service flows with a Schedulingtype of realTimePollingService(4) or unsolictedGrantServiceWithAD(5). If the referenced parameter is applicable but not present in the corresponding DOCSIS QOS Parameter Set, the CMTS uses an implementation dependent=20 value and reports the value it is using. The CM reports a value of 0 in this case. If the parameter is not applicable to the direction or upstream scheduling type of the service flow, both CMTS and CM report this object's value as 0. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.5" ::=3D { docsQosParamSetEntry 16 } docsQosParamSetUnsolicitGrantSize OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the unsolicited grant size in bytes.=20 The grant size includes the entire MAC frame=20 data PDU from the Frame Control byte to end of the MAC frame. The referenced parameter is applicable only=20 for upstream flows with a SchedulingType of of unsolicitedGrantServicewithAD(5) or unsolicitedGrantService(6), and is mandatory when applicable. Both CMTS and CM report the signaled value of the parameter in this case. =20 If the referenced parameter is not applicable to the direction or scheduling type of the corresponding DOCSIS QOS Parameter Set, both CMTS and CM report this object's value as 0. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.6" ::=3D { docsQosParamSetEntry 17 } docsQosParamSetNomGrantInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the nominal interval in microseconds=20 between successive data grant opportunities=20 on an upstream service flow. The referenced parameter is applicable only=20 for upstream flows with a SchedulingType of of unsolicitedGrantServicewithAD(5) or unsolicitedGrantService(6), and is mandatory when applicable. Both CMTS and CM report the signaled value of the parameter in this case. If the referenced parameter is not applicable to the direction or scheduling type of the corresponding DOCSIS QOS Parameter Set, both CMTS and CM report this object's value as 0. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.7" ::=3D { docsQosParamSetEntry 18 } docsQosParamSetTolGrantJitter OBJECT-TYPE SYNTAX Unsigned32=20 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum amount of time in microseconds that the transmission opportunities may be delayed from the nominal periodic schedule.=20 The referenced parameter is applicable only=20 for upstream flows with a SchedulingType of of unsolicitedGrantServicewithAD(5) or unsolicitedGrantService(6), and is mandatory when applicable. Both CMTS and CM report the signaled value of the parameter in this case. If the referenced parameter is not applicable to the direction or scheduling type of the corresponding DOCSIS QOS Parameter Set, both CMTS and CM report this object's value as 0. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.8" ::=3D { docsQosParamSetEntry 19 } docsQosParamSetGrantsPerInterval OBJECT-TYPE SYNTAX Integer32 (0..127) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the number of data grants per Nominal=20 Grant Interval=20 (docsQosParamSetNomGrantInterval). The referenced parameter is applicable only=20 for upstream flows with a SchedulingType of of unsolicitedGrantServicewithAD(5) or unsolicitedGrantService(6), and is mandatory when applicable. Both CMTS and CM report the signaled value of the parameter in this case. If the referenced parameter is not applicable to the direction or scheduling type of the corresponding DOCSIS QOS Parameter Set, both CMTS and CM report this object's value as 0. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.9" ::=3D { docsQosParamSetEntry 20 } 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=20 bitwise ANDed with docsQosParamSetTosAndMask and=20 result is bitwise ORed with = docsQosParamSetTosORMask and result is written to IP packet TOS byte.=20 A value of 'FF'H for docsQosParamSetTosAndMask and a value of '00'H for docsQosParamSetTosOrMask means = that IP Packet TOS byte is not overwritten. Even though the this object is only enforced by the Cable Modem Termination System (CMTS), Cable Modems must report the value as signaled in=20 the referenced parameter. This combination is reported if the referenced parameter is not present in a QOS Parameter Set." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.10" ::=3D { docsQosParamSetEntry 21 } docsQosParamSetTosOrMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the OR mask for IP TOS byte. See the description of docsQosParamSetTosAndMask for further details." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.10" ::=3D { docsQosParamSetEntry 22 } docsQosParamSetMaxLatency OBJECT-TYPE SYNTAX Unsigned32 UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the maximum latency between the reception of a packet by the CMTS on its NSI=20 and the forwarding of the packet to the RF interface. A value of 0 signifies no maximum latency enforced. This object only applies to downstream service flows. If the referenced parameter is not present in the corresponding downstream DOCSIS QOS Parameter Set,=20 the default value is 0. This parameter is not applicable to upstream DOCSIS QOS Parameter = Sets, and its value is reported as 0 in this case. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.7.1" ::=3D { docsQosParamSetEntry 23 } docsQosParamSetType OBJECT-TYPE SYNTAX INTEGER { active (1),=20 admitted (2), provisioned (3) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines the type of the QOS parameter set defined by this row. active(1) indicates the Active QOS parameter set, describing the service currently being provided by the Docsis MAC domain to the=20 service flow. admitted(2) indicates the Admitted QOS Parameter Set, describing services reserved by by the Docsis MAC domain for use by the service = flow. provisioned (3) describes the QOS Parameter Set defined in the DOCSIS CM Configuration file for the service flow." REFERENCE "SP-RFIv1.1-I09-020830, 8.1.5" ::=3D { docsQosParamSetEntry 24 } docsQosParamSetRequestPolicyOct OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) -- A 32-bit mask represented most significant byte=20 -- first. The 32 bit integer represented in this = manner -- equals the binary value of the referenced = integer -- parameter of the DOCSIS RFI specification. -- The BITS syntax is not used in order to avoid -- the confusion caused by different bit numbering -- conventions. MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies which transmit interval opportunities=20 the CM omits for upstream transmission requests and = packet transmissions. This object takes its default value for downstream service flows. Unless otherwise indicated, a bit value of 1 means that a CM must *not* use that opportunity for=20 upstream transmission. Calling bit 0 the least significant bit of the=20 least significant (4th) octet, and increasing bit number with significance, the bit definitions are as defined below: broadcastReqOpp(0): all CMs broadcast request opportunities priorityReqMulticastReq(1): priority request multicast request = opportunities reqDataForReq(2): request/data opportunities for requests reqDataForData(3): request/data opportunities for data piggybackReqWithData(4): =20 piggyback requests with data =20 concatenateData(5): concatenate data fragmentData(6): fragment data suppresspayloadheaders(7):=20 suppress payload headers dropPktsExceedUGSize(8): A value of 1 mean that service flow must drop packet that do not fit in the Unsolicited=20 Grant size=20 If the referenced parameter is not present in=20 a QOS Parameter Set, the value of this object is reported as '00000000'H. "=20 REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.3" ::=3D { docsQosParamSetEntry 25 } docsQosParamSetBitMap OBJECT-TYPE -- Each bit corresponds to a parameter -- from SP-RFI-v1.1-I07-010829, = Appendix C SYNTAX BITS { -- in the indicated section number. trafficPriority(0), -- C.2.2.5.1 maxTrafficRate(1), -- C.2.2.5.2 maxTrafficBurst(2), -- C.2.2.5.3 minReservedRate(3), -- C.2.2.5.4 minReservedPkt(4), -- C.2.2.5.5 activeTimeout(5), -- C.2.2.5.6 admittedTimeout(6), -- C.2.2.5.7 maxConcatBurst(7), -- C.2.2.6.1 schedulingType(8), -- C.2.2.6.2 requestPolicy(9), -- C.2.2.6.3 nomPollInterval(10), -- C.2.2.6.4 tolPollJitter(11), -- C.2.2.6.5 unsolicitGrantSize(12), -- C.2.2.6.6 nomGrantInterval(13), -- C.2.2.6.7 tolGrantJitter(14), -- C.2.2.6.8 grantsPerInterval(15), -- C.2.2.6.9 tosOverwrite(16), -- C.2.2.6.10 maxLatency(17) -- C.2.2.7.1 } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the set of QOS Parameter Set parameters actually signaled in the=20 DOCSIS registration or dynamic service request message that created or modified the QOS Parameter = Set.=20 A bit is set to 1 when the parameter described by the indicated reference section is present in the original request. =20 =20 Note that when Service Class names are expanded, the registration or dynamic response message may contain parameters as expanded by the CMTS based on a stored service class. These expanded parameters are *not* indicated by a 1 bit in this object. Note that even though some QOS Parameter Set=20 parameters may not be signaled in a message (so that the paramater's bit in this object is 0) the DOCSIS specification calls for default values to be used. These default values are reported as the corresponding object's value in the row.=20 Note that BITS objects are encoded most significant bit first. For example, if bits 1 and 16 are set, the value of this object=20 is the octet string '400080'H. =20 " ::=3D { docsQosParamSetEntry 26 } -- -- Service Flow Table -- docsQosServiceFlowTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsQosServiceFlowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the set of Docsis-QOS=20 Service Flows in a managed device. " ::=3D { docsQosMIBObjects 3 } =20 docsQosServiceFlowEntry OBJECT-TYPE SYNTAX DocsQosServiceFlowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes a service flow. An entry in the table exists for each=20 Service Flow ID. The ifIndex is an =20 ifType of docsCableMaclayer(127)." INDEX {=20 ifIndex,=20 docsQosServiceFlowId=20 } ::=3D { docsQosServiceFlowTable 1 } DocsQosServiceFlowEntry ::=3D SEQUENCE { =20 docsQosServiceFlowId Unsigned32, docsQosServiceFlowSID Unsigned32, docsQosServiceFlowDirection IfDirection, docsQosServiceFlowPrimary TruthValue } docsQosServiceFlowId OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index assigned to a service flow by CMTS." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.3.2" ::=3D { docsQosServiceFlowEntry 1 } docsQosServiceFlowSID OBJECT-TYPE SYNTAX Unsigned32 (0..16383) MAX-ACCESS read-only STATUS current DESCRIPTION "Service Identifier (SID) assigned to an=20 admitted or active service flow. This object reports a value of 0 if a Service Id is not=20 associated with the service flow. Only active=20 or admitted upstream service flows will have a Service Id (SID)." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.3.3" ::=3D { docsQosServiceFlowEntry 2 } docsQosServiceFlowDirection OBJECT-TYPE SYNTAX IfDirection MAX-ACCESS read-only STATUS current DESCRIPTION "The direction of the service flow." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.1/2" ::=3D { docsQosServiceFlowEntry 3 } docsQosServiceFlowPrimary OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Object reflects whether service flow is the primary = or a secondary service flow. A primary service flow is the default service flow for otherwise unclassified traffic and all MAC=20 messages." REFERENCE "SP-RFIv1.1-I09-020830, Section 8.1 " ::=3D { docsQosServiceFlowEntry 4 } -- -- Service Flow Stats Table -- docsQosServiceFlowStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsQosServiceFlowStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes statistics associated with = the =20 Service Flows in a managed device. " ::=3D { docsQosMIBObjects 4 } =20 docsQosServiceFlowStatsEntry OBJECT-TYPE SYNTAX DocsQosServiceFlowStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes a set of service flow statistics. An entry in the table exists for each=20 Service Flow ID. The ifIndex is an =20 ifType of docsCableMaclayer(127)." INDEX {=20 ifIndex,=20 docsQosServiceFlowId=20 } ::=3D { docsQosServiceFlowStatsTable 1 } DocsQosServiceFlowStatsEntry ::=3D SEQUENCE { docsQosServiceFlowPkts Counter64, docsQosServiceFlowOctets Counter64, docsQosServiceFlowTimeCreated TimeStamp, docsQosServiceFlowTimeActive Counter32, docsQosServiceFlowPHSUnknowns Counter32, docsQosServiceFlowPolicedDropPkts Counter32, docsQosServiceFlowPolicedDelayPkts Counter32 } docsQosServiceFlowPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Packet Data PDUs classified to this=20 service flow and forwarded beyond a service flow maximum rate policing function. This object does not count MAC-specific management messages. CMs not classifying downstream packets may report=20 this object's value as 0. =09 Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant=20 size should be counted only on the primary service=20 flow's counters. =09 =20 Unclassified upstream user data packets (i.e. non=20 MAC-management) forwarded to the default upstream service flow should be incremented for this object. This object does include packets counted by=20 docsQosServiceFlowPolicedDelayPkts, but does not = include packets counted by = docsQosServiceFlowPolicedDropPkts." ::=3D { docsQosServiceFlowStatsEntry 1 } docsQosServiceFlowOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets from the byte after the MAC=20 header HCS to the end of the CRC for all packets counted=20 in the docsQosServiceFlowPkts object for this row.=20 Note that this counts the octets after payload = header suppression has been applied. CMs not classifying = to a downstream service flow may report this object's=20 value as 0 for that flow." ::=3D { docsQosServiceFlowStatsEntry 2 } docsQosServiceFlowTimeCreated OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the service flow=20 was created." ::=3D { docsQosServiceFlowStatsEntry 3 } docsQosServiceFlowTimeActive OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The total time that service flow has been active." ::=3D { docsQosServiceFlowStatsEntry 4 } docsQosServiceFlowPHSUnknowns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets received on the service flow with an unknown payload header suppression index." ::=3D { docsQosServiceFlowStatsEntry 5 } docsQosServiceFlowPolicedDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Packet Data PDUs classified to this service flow, but dropped for some reason such as=20 violation of the Maximum Sustained Traffic Rate or UGS packet exceeding the grant size. This object does not count dropped MAC-specific management messages. =20 Dropped unclassified upstream user date packets = (i.e. non MAC-management) forwarded to the default upstream service flow should be incremented for this = object." ::=3D { docsQosServiceFlowStatsEntry 6 } docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts only packets delayed in = violation of=20 the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply."=09 ::=3D { docsQosServiceFlowStatsEntry 7 } -- -- Upstream Service Flow Stats Table (CMTS ONLY) -- docsQosUpstreamStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsQosUpstreamStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes statistics associated with =20 upstream service flows. All counted frames must=20 be received without an FCS error." ::=3D { docsQosMIBObjects 5 } =20 docsQosUpstreamStatsEntry OBJECT-TYPE SYNTAX DocsQosUpstreamStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes a set of upstream service flow = statistics. An entry in the table exists for each=20 upstream Service Flow in a managed device.=20 The ifIndex is an ifType of = docsCableMaclayer(127)." INDEX {=20 ifIndex,=20 docsQosSID=20 } ::=3D { docsQosUpstreamStatsTable 1 } DocsQosUpstreamStatsEntry ::=3D SEQUENCE { docsQosSID Integer32, docsQosUpstreamFragments Counter32, docsQosUpstreamFragDiscards Counter32, docsQosUpstreamConcatBursts Counter32 } docsQosSID OBJECT-TYPE SYNTAX Integer32 (1..16383) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identifies a service id for an admitted or active=20 upstream service flow." ::=3D { docsQosUpstreamStatsEntry 1 } docsQosUpstreamFragments OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of fragmentation headers received on an upstream service flow, regardless of whether the fragment was correctly reassembled into a=20 valid packet. " ::=3D { docsQosUpstreamStatsEntry 2 } docsQosUpstreamFragDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of upstream fragments discarded and not=20 assembled into a valid upstream packet." ::=3D { docsQosUpstreamStatsEntry 3 } docsQosUpstreamConcatBursts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of concatenation headers received on an=20 upstream service flow." ::=3D { docsQosUpstreamStatsEntry 4 } -- -- Dynamic Service Stats Table -- docsQosDynamicServiceStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsQosDynamicServiceStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes statistics associated with = the =20 Dynamic Service Flows in a managed device. " ::=3D { docsQosMIBObjects 6 } =20 docsQosDynamicServiceStatsEntry OBJECT-TYPE SYNTAX DocsQosDynamicServiceStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Describes a set of dynamic service flow = statistics. Two entries exist for each Docsis mac layer=20 interface for the upstream and downstream = direction. On the CMTS, the downstream direction row = indicates messages transmitted or transactions originated by the CMTS. The upstream direction row indicates messages received or transaction originated by the CM. On the CM, the downstream direction row=20 indicates messages received or transactions originated by the CMTS. The upstream direction=20 row indicates messages transmitted by the CM or transactions originated by the CM. The ifIndex is an ifType of = docsCableMaclayer(127)." INDEX {=20 ifIndex,=20 docsQosIfDirection=20 } ::=3D { docsQosDynamicServiceStatsTable 1 } DocsQosDynamicServiceStatsEntry ::=3D SEQUENCE { docsQosIfDirection IfDirection, docsQosDSAReqs Counter32, docsQosDSARsps Counter32, docsQosDSAAcks Counter32, docsQosDSCReqs Counter32, docsQosDSCRsps Counter32, docsQosDSCAcks Counter32, docsQosDSDReqs Counter32, docsQosDSDRsps Counter32, docsQosDynamicAdds Counter32, docsQosDynamicAddFails Counter32, docsQosDynamicChanges Counter32, docsQosDynamicChangeFails Counter32, docsQosDynamicDeletes Counter32, docsQosDynamicDeleteFails Counter32, docsQosDCCReqs Counter32, docsQosDCCRsps Counter32, docsQosDCCAcks Counter32, docsQosDCCs Counter32, docsQosDCCFails Counter32 } docsQosIfDirection OBJECT-TYPE SYNTAX IfDirection MAX-ACCESS not-accessible STATUS current DESCRIPTION "The direction of interface." ::=3D { docsQosDynamicServiceStatsEntry 1 } docsQosDSAReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Service Addition Requests, including retries."=20 ::=3D { docsQosDynamicServiceStatsEntry 2 } docsQosDSARsps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Service Addition Responses, including retries."=20 ::=3D { docsQosDynamicServiceStatsEntry 3 } docsQosDSAAcks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Service Addition = Acknowledgements, including retries."=20 ::=3D { docsQosDynamicServiceStatsEntry 4 } docsQosDSCReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Service Change Requests, including retries."=20 ::=3D { docsQosDynamicServiceStatsEntry 5 } docsQosDSCRsps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Service Change Responses, including retries."=20 ::=3D { docsQosDynamicServiceStatsEntry 6 } docsQosDSCAcks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Service Change = Acknowledgements, including retries." ::=3D { docsQosDynamicServiceStatsEntry 7 } docsQosDSDReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Service Delete Requests, including retries."=20 ::=3D { docsQosDynamicServiceStatsEntry 8 } docsQosDSDRsps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Service Delete Responses, including retries."=20 ::=3D { docsQosDynamicServiceStatsEntry 9 } docsQosDynamicAdds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of successful Dynamic Service Addition transactions." ::=3D { docsQosDynamicServiceStatsEntry 10 } docsQosDynamicAddFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of failed Dynamic Service Addition transactions." ::=3D { docsQosDynamicServiceStatsEntry 11 } docsQosDynamicChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of successful Dynamic Service Change transactions." ::=3D { docsQosDynamicServiceStatsEntry 12 } docsQosDynamicChangeFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of failed Dynamic Service Change transactions." ::=3D { docsQosDynamicServiceStatsEntry 13 } docsQosDynamicDeletes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of successful Dynamic Service Delete transactions."=20 ::=3D { docsQosDynamicServiceStatsEntry 14 } docsQosDynamicDeleteFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of failed Dynamic Service Delete transactions."=20 ::=3D { docsQosDynamicServiceStatsEntry 15 } docsQosDCCReqs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Channel Change Request = messages traversing an interface. This count is nonzero only = on downstream direction rows. This count should=20 include number of retries." ::=3D { docsQosDynamicServiceStatsEntry 16 } docsQosDCCRsps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Channel Change Response = messages traversing an interface. This count is nonzero=20 only on upstream direction rows. This count should=20 include number of retries." =20 ::=3D { docsQosDynamicServiceStatsEntry 17 } docsQosDCCAcks OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Dynamic Channel Change = Acknowledgement messages traversing an interface. This count=20 is nonzero only on downstream direction rows. This count should include number of retries." ::=3D { docsQosDynamicServiceStatsEntry 18 } docsQosDCCs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of successful Dynamic Channel Change transactions. This count is nonzero only on = downstream=20 direction rows." ::=3D { docsQosDynamicServiceStatsEntry 19 } docsQosDCCFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of failed Dynamic Channel Change transactions. This count is nonzero only on=20 downstream direction rows." ::=3D { docsQosDynamicServiceStatsEntry 20 } -- -- Service Flow Log Table (CMTS ONLY) -- docsQosServiceFlowLogTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsQosServiceFlowLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a log of the disconnected Service Flows in a managed device." ::=3D { docsQosMIBObjects 7 } =20 docsQosServiceFlowLogEntry OBJECT-TYPE SYNTAX DocsQosServiceFlowLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The information regarding a single disconnected=20 service flow." INDEX {=20 docsQosServiceFlowLogIndex } ::=3D { docsQosServiceFlowLogTable 1 } DocsQosServiceFlowLogEntry ::=3D SEQUENCE { docsQosServiceFlowLogIndex Unsigned32, docsQosServiceFlowLogIfIndex InterfaceIndex, =20 docsQosServiceFlowLogSFID Unsigned32, docsQosServiceFlowLogCmMac MacAddress, docsQosServiceFlowLogPkts Counter64, docsQosServiceFlowLogOctets Counter64, =20 docsQosServiceFlowLogTimeDeleted TimeStamp, =20 docsQosServiceFlowLogTimeCreated TimeStamp, docsQosServiceFlowLogTimeActive Counter32, docsQosServiceFlowLogDirection IfDirection, docsQosServiceFlowLogPrimary TruthValue, docsQosServiceFlowLogServiceClassName DisplayString, docsQosServiceFlowLogPolicedDropPkts Counter32, docsQosServiceFlowLogPolicedDelayPkts Counter32, docsQosServiceFlowLogControl INTEGER } docsQosServiceFlowLogIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Unique index for a logged service flow." ::=3D { docsQosServiceFlowLogEntry 1 } docsQosServiceFlowLogIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex of ifType docsCableMaclayer(127)=20 on the CMTS where the service flow was present." ::=3D { docsQosServiceFlowLogEntry 2 } docsQosServiceFlowLogSFID OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The index assigned to the service flow by the = CMTS." ::=3D { docsQosServiceFlowLogEntry 3 } docsQosServiceFlowLogCmMac OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The MAC address for the cable modem associated = with=20 the service flow." ::=3D { docsQosServiceFlowLogEntry 4 } docsQosServiceFlowLogPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets counted on this service flow=20 after payload header suppression." ::=3D { docsQosServiceFlowLogEntry 5 } docsQosServiceFlowLogOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets counted on this service flow=20 after payload header suppression." ::=3D { docsQosServiceFlowLogEntry 6 } docsQosServiceFlowLogTimeDeleted OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the service flow=20 was deleted." ::=3D { docsQosServiceFlowLogEntry 7 } docsQosServiceFlowLogTimeCreated OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the service flow=20 was created." ::=3D { docsQosServiceFlowLogEntry 8 } docsQosServiceFlowLogTimeActive OBJECT-TYPE SYNTAX Counter32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The total time that service flow was active." ::=3D { docsQosServiceFlowLogEntry 9 } docsQosServiceFlowLogDirection OBJECT-TYPE SYNTAX IfDirection MAX-ACCESS read-only STATUS current DESCRIPTION "The value of docsQosServiceFlowDirection=20 for the service flow." ::=3D { docsQosServiceFlowLogEntry 10 } docsQosServiceFlowLogPrimary OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The value of docsQosServiceFlowPrimary for the=20 service flow." ::=3D { docsQosServiceFlowLogEntry 11 } docsQosServiceFlowLogServiceClassName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The value of docsQosParamSetServiceClassName for the provisioned QOS Parameter Set of the=20 service flow." ::=3D { docsQosServiceFlowLogEntry 12 } docsQosServiceFlowLogPolicedDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The final value of = docsQosServiceFlowPolicedDropPkts for the service flow." ::=3D { docsQosServiceFlowLogEntry 13 } docsQosServiceFlowLogPolicedDelayPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The final value of = docsQosServiceFlowPolicedDelayPkts for the service flow." ::=3D { docsQosServiceFlowLogEntry 14 } docsQosServiceFlowLogControl OBJECT-TYPE SYNTAX INTEGER { active(1),=20 destroy(6) } MAX-ACCESS read-write STATUS current DESCRIPTION "Setting this object to the value destroy(6) removes this entry from the table.=20 Reading this object return the value active(1)." ::=3D { docsQosServiceFlowLogEntry 15 } -- -- Service Class Table (CMTS ONLY) -- docsQosServiceClassTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsQosServiceClassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the set of Docsis-QOS=20 Service Classes in a CMTS. " ::=3D { docsQosMIBObjects 8 } =20 docsQosServiceClassEntry OBJECT-TYPE SYNTAX DocsQosServiceClassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A provisioned service class on a CMTS.=20 Each entry defines a template for certain=20 DOCSIS QOS Parameter Set values. When a CM=20 creates or modifies an Admitted QOS Parameter Set for a Service Flow, it may reference a Service Class Name instead of providing explicit QOS Parameter Set values. In this case, the CMTS populates the QOS Parameter Set with the applicable=20 corresponding values from the named Service Class. Subsequent changes to a Service Class row do *not*=20 affect the QOS Parameter Set values of any service = flows already admitted. =20 A service class template applies to only a single direction, as indicated in the=20 docsQosServiceClassDirection object. " INDEX {=20 docsQosServiceClassName=20 } ::=3D { docsQosServiceClassTable 1 } DocsQosServiceClassEntry ::=3D SEQUENCE { docsQosServiceClassName DisplayString, docsQosServiceClassStatus RowStatus, docsQosServiceClassPriority Integer32, docsQosServiceClassMaxTrafficRate BitRate, docsQosServiceClassMaxTrafficBurst Unsigned32, docsQosServiceClassMinReservedRate BitRate, docsQosServiceClassMinReservedPkt Integer32, docsQosServiceClassMaxConcatBurst Integer32, docsQosServiceClassNomPollInterval Unsigned32, docsQosServiceClassTolPollJitter Unsigned32, docsQosServiceClassUnsolicitGrantSize Integer32, docsQosServiceClassNomGrantInterval Unsigned32, docsQosServiceClassTolGrantJitter Unsigned32, docsQosServiceClassGrantsPerInterval Integer32, docsQosServiceClassMaxLatency Unsigned32, docsQosServiceClassActiveTimeout Integer32, docsQosServiceClassAdmittedTimeout Integer32, docsQosServiceClassSchedulingType SchedulingType, docsQosServiceClassRequestPolicy OCTET STRING, docsQosServiceClassTosAndMask OCTET STRING, docsQosServiceClassTosOrMask OCTET STRING, docsQosServiceClassDirection IfDirection } docsQosServiceClassName OBJECT-TYPE SYNTAX DisplayString (SIZE(1..15)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Service Class Name. DOCSIS specifies that the maximum size is 15 printable ASCII characters with=20 a terminating zero. The terminating zero is not represented in this DisplayString syntax object. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.3.4" ::=3D { docsQosServiceClassEntry 1 } docsQosServiceClassStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Used to create or delete rows in this table. There is no restriction on the ability=20 to change values in this row while the row is active.=20 Inactive rows need not be timed out." ::=3D { docsQosServiceClassEntry 2 } docsQosServiceClassPriority OBJECT-TYPE SYNTAX Integer32 (0..7) MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsQosParamSetPriority." DEFVAL { 0 } ::=3D { docsQosServiceClassEntry 3 } docsQosServiceClassMaxTrafficRate OBJECT-TYPE SYNTAX BitRate MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsQosParamSetMaxTrafficRate." DEFVAL { 0 } ::=3D { docsQosServiceClassEntry 4 } docsQosServiceClassMaxTrafficBurst OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsQosParamSetMaxTrafficBurst." DEFVAL { 3044 } ::=3D { docsQosServiceClassEntry 5 } docsQosServiceClassMinReservedRate OBJECT-TYPE SYNTAX BitRate MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsQosParamSEtMinReservedRate." DEFVAL { 0 } ::=3D { docsQosServiceClassEntry 6 } docsQosServiceClassMinReservedPkt OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsQosParamSetMinReservedPkt." ::=3D { docsQosServiceClassEntry 7 } docsQosServiceClassMaxConcatBurst OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsQosParamSetMaxConcatBurst." DEFVAL { 1522 } ::=3D { docsQosServiceClassEntry 8 } docsQosServiceClassNomPollInterval OBJECT-TYPE SYNTAX Unsigned32=20 UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsQosParamSetNomPollInterval." DEFVAL { 0 } ::=3D { docsQosServiceClassEntry 9 } docsQosServiceClassTolPollJitter OBJECT-TYPE SYNTAX Unsigned32=20 UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsQosParamSetTolPollJitter." DEFVAL { 0 } ::=3D { docsQosServiceClassEntry 10 } docsQosServiceClassUnsolicitGrantSize OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsQosParamSetUnsolicitGrantSize." DEFVAL { 0 } ::=3D { docsQosServiceClassEntry 11 } docsQosServiceClassNomGrantInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsQosParamSetNomGrantInterval." DEFVAL { 0 } ::=3D { docsQosServiceClassEntry 12 } docsQosServiceClassTolGrantJitter OBJECT-TYPE SYNTAX Unsigned32=20 UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsQosParamSetTolGrantJitter." DEFVAL { 0 } ::=3D { docsQosServiceClassEntry 13 } docsQosServiceClassGrantsPerInterval OBJECT-TYPE SYNTAX Integer32 (0..127) MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsQosParamSetGrantsPerInterval." DEFVAL { 0 } ::=3D { docsQosServiceClassEntry 14 } docsQosServiceClassMaxLatency OBJECT-TYPE SYNTAX Unsigned32 UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsQosParamSetClassMaxLatency." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.7.1" DEFVAL { 0 } ::=3D { docsQosServiceClassEntry 15 } docsQosServiceClassActiveTimeout OBJECT-TYPE SYNTAX Integer32 (0..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsQosParamSetActiveTimeout." DEFVAL { 0 } ::=3D { docsQosServiceClassEntry 16 } docsQosServiceClassAdmittedTimeout OBJECT-TYPE SYNTAX Integer32 (0..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsQosParamSetAdmittedTimeout." DEFVAL { 200 } ::=3D { docsQosServiceClassEntry 17 } docsQosServiceClassSchedulingType OBJECT-TYPE SYNTAX SchedulingType MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsQosParamSetSchedulingType." DEFVAL { bestEffort } ::=3D { docsQosServiceClassEntry 18 } docsQosServiceClassRequestPolicy OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsQosParamSetRequestPolicyOct." DEFVAL { '00000000'H } -- no bits are set ::=3D { docsQosServiceClassEntry 19 } docsQosServiceClassTosAndMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsQosParamSetTosAndMask." DEFVAL { 'FF'H } ::=3D { docsQosServiceClassEntry 20 } docsQosServiceClassTosOrMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-create STATUS current DESCRIPTION "Template for docsQosParamSetTosOrMask." DEFVAL { '00'H } ::=3D { docsQosServiceClassEntry 21 } docsQosServiceClassDirection OBJECT-TYPE SYNTAX IfDirection MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies whether the service class template applies to upstream or downstream service flows." DEFVAL { upstream } ::=3D { docsQosServiceClassEntry 22 } -- -- Service Class PolicyTable -- docsQosServiceClassPolicyTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsQosServiceClassPolicyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes the set of Docsis-QOS=20 Service Class Policies. =20 This table is an adjunct to the docsDevFilterPolicy table. Entries in=20 docsDevFilterPolicy table can point to=20 specific rows in this table. This table permits mapping a packet to a service class name of an active service flow so long as=20 a classifier does not exist at a higher priority. " REFERENCE "SP-RFIv1.1-I09-020830, Appendix E.2.1" ::=3D { docsQosMIBObjects 9 } =20 docsQosServiceClassPolicyEntry OBJECT-TYPE SYNTAX DocsQosServiceClassPolicyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A service class name policy entry." INDEX {=20 docsQosServiceClassPolicyIndex=20 } ::=3D { docsQosServiceClassPolicyTable 1 } DocsQosServiceClassPolicyEntry ::=3D SEQUENCE { docsQosServiceClassPolicyIndex Integer32, =20 docsQosServiceClassPolicyName DisplayString, docsQosServiceClassPolicyRulePriority Integer32, docsQosServiceClassPolicyStatus RowStatus=20 } docsQosServiceClassPolicyIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index value to uniquely identify an entry in this table."=20 ::=3D { docsQosServiceClassPolicyEntry 1 } docsQosServiceClassPolicyName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "Service Class Name to identify the name of the=20 service class flow to which the packet should be directed."=20 REFERENCE "SP-RFIv1.1-I09-020830, Appendix E.2.1" ::=3D { docsQosServiceClassPolicyEntry 2 } docsQosServiceClassPolicyRulePriority OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "Service Class Policy rule priority for the entry." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.3.5" ::=3D { docsQosServiceClassPolicyEntry 3 } docsQosServiceClassPolicyStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Used to create or delete rows in this table. This object should not be deleted if it is reference by an entry in docsDevFilterPolicy. The reference should be deleted first. There is no restriction on the ability=20 to change values in this row while the row is active.=20 Inactive rows need not be timed out." ::=3D { docsQosServiceClassPolicyEntry 4 } -- -- Payload Header Suppression(PHS) Table -- docsQosPHSTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsQosPHSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table describes set of payload header suppression entries." ::=3D { docsQosMIBObjects 10 } =20 docsQosPHSEntry OBJECT-TYPE SYNTAX DocsQosPHSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A payload header suppression entry.=20 The ifIndex is an ifType of = docsCableMaclayer(127). The index docsQosServiceFlowId selects one service flow from the cable MAC layer interface. The docsQosPktClassId index matches an index of the docsQosPktClassTable. "=20 INDEX {=20 ifIndex,=20 docsQosServiceFlowId, docsQosPktClassId } ::=3D { docsQosPHSTable 1 } DocsQosPHSEntry ::=3D SEQUENCE { docsQosPHSField OCTET STRING, docsQosPHSMask OCTET STRING, docsQosPHSSize Integer32, docsQosPHSVerify TruthValue, docsQosPHSIndex Integer32 } -- docsQosPHSIndex { docsQosPHSEntry 1 } was -- moved to docsQosPHSIndex { docsQosPHSEntry 7 } -- in an ealier revisions of the mib.=20 docsQosPHSField OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "Payload header suppression field defines the=20 bytes of the header which must be=20 suppressed/restored by the sending/receiving=20 device. The number of octets in this object should be the same as the value of docsQosPHSSize." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.1" ::=3D { docsQosPHSEntry 2 } docsQosPHSMask OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "Payload header suppression mask defines the=20 bit mask which used in combination with the docsQosPHSField defines which bytes in header must be suppressed/restored by the sending or receiving device. Each bit of this bit mask corresponds to a byte in the docsQosPHSField, with the least=20 significant bit corresponding to first byte of the docsQosPHSField. Each bit of the bit mask specifies whether of not the corresponding byte should be suppressed in the packet. A bit value of '1' indicates that the byte should be suppressed by the sending=20 device and restored by the receiving device.=20 A bit value of '0' indicates that=20 the byte should not be suppressed by the sending device or restored by the receiving device. If the bit mask does not contain a bit for each byte in the docsQosPHSField then the bit mask is extended with bit values of '1' to be the necessary length." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.3" ::=3D { docsQosPHSEntry 3 } docsQosPHSSize OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Payload header suppression size specifies the=20 number of bytes in the header to be suppressed and restored. The value of this object must match the number of bytes in the docsQosPHSField." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.4" ::=3D { docsQosPHSEntry 4 } docsQosPHSVerify OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Payload header suppression verification value of 'true' the sender must verify docsQosPHSField=20 is the same as what is contained in the packet to be suppressed." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.5" ::=3D { docsQosPHSEntry 5 } docsQosPHSIndex OBJECT-TYPE SYNTAX Integer32 (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Payload header suppression index uniquely=20 references the PHS rule for a given service flow." REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.2" ::=3D { docsQosPHSEntry 6 } -- -- docsQosCmtsMacToSrvFlowTable (CMTS Only) -- docsQosCmtsMacToSrvFlowTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsQosCmtsMacToSrvFlowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provide for referencing the service = flows=20 associated with a particular cable modem. This = allows=20 for indexing into other docsQos tables that are=20 indexed by docsQosServiceFlowId and ifIndex." ::=3D { docsQosMIBObjects 11 } =20 docsQosCmtsMacToSrvFlowEntry OBJECT-TYPE SYNTAX DocsQosCmtsMacToSrvFlowEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry is created by CMTS for each service flow=20 connected to this CMTS."=20 INDEX {=20 docsQosCmtsCmMac, docsQosCmtsServiceFlowId } ::=3D { docsQosCmtsMacToSrvFlowTable 1 } DocsQosCmtsMacToSrvFlowEntry ::=3D SEQUENCE { =20 docsQosCmtsCmMac MacAddress, docsQosCmtsServiceFlowId Unsigned32, docsQosCmtsIfIndex InterfaceIndex } docsQosCmtsCmMac OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The MAC address for the referenced CM." ::=3D { docsQosCmtsMacToSrvFlowEntry 1 } docsQosCmtsServiceFlowId OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index assigned to a service flow by CMTS." ::=3D { docsQosCmtsMacToSrvFlowEntry 2 } docsQosCmtsIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex of ifType docsCableMacLayter(127)=20 on the CMTS that is connected to the Cable Modem." ::=3D { docsQosCmtsMacToSrvFlowEntry 3 } -- -- Placeholder for notifications/traps. -- docsQosNotification OBJECT IDENTIFIER ::=3D { docsQosMIB 2 } -- -- Conformance definitions -- docsQosConformance OBJECT IDENTIFIER ::=3D { docsQosMIB 3 } docsQosGroups OBJECT IDENTIFIER ::=3D { docsQosConformance 1 } docsQosCompliances OBJECT IDENTIFIER ::=3D { docsQosConformance 2 } docsQosCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for MCNS Cable Modems and Cable Modem Termination Systems that implement DOCSIS Service Flows." MODULE -- docsQosMIB MANDATORY-GROUPS { docsQosBaseGroup } GROUP docsQosCmtsGroup DESCRIPTION "This group is mandatory for only Cable Modem Termination Systems (CMTS) and not implemented for Cable Modems." GROUP docsQosParamSetGroup DESCRIPTION "This group is mandatory for Cable Modem Termination Systems (CMTS) and Cable Modems. Cable modems only = implement objects in this group as read-only." GROUP docsQosSrvClassPolicyGroup DESCRIPTION "This group is optional for Cable Modem Termination Systems (CMTS) and Cable Modems. This group only needs to=20 be implement if policy based service flow classification is implemented. See docsDevPolicyTable in DOCS-CABLE-DEVICE-MIB for more details. " GROUP docsQosServiceClassGroup DESCRIPTION "The docsQosServiceClassTable group of objects." =20 OBJECT docsQosPktClassPkts DESCRIPTION "This object only needs to be implemented in entries that are classifying packets and not policing packets." OBJECT docsQosPktClassInetSourceAddrType -- SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 address." OBJECT docsQosPktClassInetSourceAddr SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 address." =20 OBJECT docsQosPktClassInetSourceMaskType -- SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 address." OBJECT docsQosPktClassInetSourceMask SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 address."=20 =20 OBJECT docsQosPktClassInetDestAddrType -- SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 address." OBJECT docsQosPktClassInetDestAddr SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 address." =20 OBJECT docsQosPktClassInetDestMaskType -- SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 address." OBJECT docsQosPktClassInetDestMask SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 address." ::=3D { docsQosCompliances 1 } docsQosBaseGroup OBJECT-GROUP OBJECTS { docsQosPktClassDirection, docsQosPktClassPriority, docsQosPktClassIpTosLow, docsQosPktClassIpTosHigh, docsQosPktClassIpTosMask, docsQosPktClassIpProtocol, docsQosPktClassSourcePortStart, docsQosPktClassSourcePortEnd, docsQosPktClassDestPortStart, docsQosPktClassDestPortEnd, docsQosPktClassDestMacAddr, docsQosPktClassDestMacMask, docsQosPktClassSourceMacAddr, docsQosPktClassEnetProtocolType, docsQosPktClassEnetProtocol, docsQosPktClassUserPriLow, docsQosPktClassUserPriHigh, docsQosPktClassVlanId, docsQosPktClassState, docsQosPktClassPkts, docsQosPktClassBitMap, docsQosPktClassInetSourceAddrType, docsQosPktClassInetSourceAddr, docsQosPktClassInetSourceMaskType, docsQosPktClassInetSourceMask, docsQosPktClassInetDestAddrType, docsQosPktClassInetDestAddr, docsQosPktClassInetDestMaskType, docsQosPktClassInetDestMask, docsQosServiceFlowSID, docsQosServiceFlowDirection, docsQosServiceFlowPrimary,=20 docsQosServiceFlowPkts, -- not sure if CM should implement docsQosServiceFlowOctets, docsQosServiceFlowTimeCreated, docsQosServiceFlowTimeActive, docsQosServiceFlowPHSUnknowns, docsQosServiceFlowPolicedDropPkts, docsQosServiceFlowPolicedDelayPkts,=09 docsQosDSAReqs, docsQosDSARsps, docsQosDSAAcks, docsQosDSCReqs, docsQosDSCRsps, docsQosDSCAcks, docsQosDSDReqs, docsQosDSDRsps, docsQosDynamicAdds, docsQosDynamicAddFails, docsQosDynamicChanges, docsQosDynamicChangeFails, docsQosDynamicDeletes, docsQosDynamicDeleteFails, docsQosDCCReqs, docsQosDCCRsps, docsQosDCCAcks, docsQosDCCs, docsQosDCCFails, docsQosPHSField, docsQosPHSMask, docsQosPHSSize, docsQosPHSVerify,=20 docsQosPHSIndex } STATUS current DESCRIPTION "Group of objects implemented in both Cable Modems and=20 Cable Modem Termination Systems." ::=3D { docsQosGroups 1 } docsQosParamSetGroup OBJECT-GROUP OBJECTS { docsQosParamSetServiceClassName, docsQosParamSetPriority, docsQosParamSetMaxTrafficRate, docsQosParamSetMaxTrafficBurst, docsQosParamSetMinReservedRate, docsQosParamSetMinReservedPkt, docsQosParamSetActiveTimeout, docsQosParamSetAdmittedTimeout, docsQosParamSetMaxConcatBurst, docsQosParamSetSchedulingType, docsQosParamSetNomPollInterval, docsQosParamSetTolPollJitter, docsQosParamSetUnsolicitGrantSize, docsQosParamSetNomGrantInterval, docsQosParamSetTolGrantJitter, docsQosParamSetGrantsPerInterval, docsQosParamSetTosAndMask, docsQosParamSetTosOrMask, docsQosParamSetMaxLatency, docsQosParamSetRequestPolicyOct, docsQosParamSetBitMap } STATUS current DESCRIPTION "Group of objects implemenented in both Cable Modems and=20 Cable Modem Termination Systems for QOS parameter sets." ::=3D { docsQosGroups 2 } docsQosCmtsGroup OBJECT-GROUP OBJECTS { docsQosUpstreamFragments, docsQosUpstreamFragDiscards, docsQosUpstreamConcatBursts, docsQosServiceFlowLogIfIndex, =20 docsQosServiceFlowLogSFID, docsQosServiceFlowLogCmMac, docsQosServiceFlowLogPkts, docsQosServiceFlowLogOctets,=20 docsQosServiceFlowLogTimeDeleted, =20 docsQosServiceFlowLogTimeCreated, docsQosServiceFlowLogTimeActive, docsQosServiceFlowLogDirection, docsQosServiceFlowLogPrimary, docsQosServiceFlowLogServiceClassName, docsQosServiceFlowLogPolicedDropPkts, docsQosServiceFlowLogPolicedDelayPkts, docsQosServiceFlowLogControl, docsQosCmtsIfIndex -- docsQosCmtsMacToSrvFlowTable required } STATUS current DESCRIPTION "Mandatory group of objects implemented only in the CMTS." ::=3D { docsQosGroups 3 } docsQosSrvClassPolicyGroup OBJECT-GROUP OBJECTS { docsQosServiceClassPolicyName, docsQosServiceClassPolicyRulePriority, docsQosServiceClassPolicyStatus } STATUS current DESCRIPTION "Group of objects implemented in both Cable Modems and=20 Cable Modem Termination Systems when supporting policy based service flows." ::=3D { docsQosGroups 4 } docsQosServiceClassGroup OBJECT-GROUP OBJECTS { docsQosServiceClassStatus, docsQosServiceClassPriority, docsQosServiceClassMaxTrafficRate, docsQosServiceClassMaxTrafficBurst, docsQosServiceClassMinReservedRate, docsQosServiceClassMinReservedPkt, docsQosServiceClassMaxConcatBurst, docsQosServiceClassNomPollInterval, docsQosServiceClassTolPollJitter, docsQosServiceClassUnsolicitGrantSize, docsQosServiceClassNomGrantInterval, docsQosServiceClassTolGrantJitter, docsQosServiceClassGrantsPerInterval, docsQosServiceClassMaxLatency, docsQosServiceClassActiveTimeout, docsQosServiceClassAdmittedTimeout, docsQosServiceClassSchedulingType, docsQosServiceClassRequestPolicy, docsQosServiceClassTosAndMask, docsQosServiceClassTosOrMask, docsQosServiceClassDirection } STATUS current DESCRIPTION "The docsQosServiceClassTable objects. If a CMTS implements expansion of Service Class Names in a QOS Parameter Set, this group is mandatory on the CMTS. If the CMTS does not support Service Class Names, this group may be unimplemented in the CMTS. This group is not implemented on the CM. " ::=3D { docsQosGroups 5 } END ------_=_NextPart_000_01C2C89C.3EED38A4-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 30 15:25:26 2003 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 PAA09672 for ; Thu, 30 Jan 2003 15:25:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UKSaK27272 for ipcdn-archive@odin.ietf.org; Thu, 30 Jan 2003 15:28:36 -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 h0UKSXJ27265; Thu, 30 Jan 2003 15:28:33 -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 h0UKQKJ27129 for ; Thu, 30 Jan 2003 15:26:20 -0500 Received: from mms3.broadcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09623 for ; Thu, 30 Jan 2003 15:22:37 -0500 (EST) Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom MMS1 SMTP Relay (MMS v5.5.0)); Thu, 30 Jan 2003 12:26:08 -0700 Received: from ltatlamdolas (dhcp-10-24-65-44.atlanta.broadcom.com [10.24.65.44]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with SMTP id MAA08008; Thu, 30 Jan 2003 12:25:57 -0800 (PST) From: "Margo Dolas" To: "Lejeune, Andre" , "Murwin William-LWM008" , "'Pollak, Lucy'" , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Thu, 30 Jan 2003 15:25:56 -0500 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-MIME-Autoconverted: from 8bit to quoted-printable by mon-irva-11.broadcom.com id MAA08008 X-WSS-ID: 122755EA357867-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UKQKJ27130 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit William, I'm OK with Andre's text for docsQosServiceFlowPolicedDropPkts with the following change - "This object counts packets dropped on this Service Flow before transmission. Examples are because of violation of the Maximum Sustained Traffic Rate or, for UGS flows, because the packet exceeds the UGS grant size. This object does not count packets sent on the primary service flow in violation of the UGS grant size." I also want to ensure that the below change is still included in the description of docsQosServiceFlowPkts - "For UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." In response to Andre's last question, I'd be OK with adding some text along the lines of - "CMs not enforcing downstream rate shaping may report zero" for these descriptions. Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Thursday, 30 January, 2003 2:02 PM To: Murwin William-LWM008; Margo Dolas; 'Pollak, Lucy'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Will, Please excuse me for not having sent a rewording proposal initially - I had limited time to write my response. Here is what I would think of: docsQosServiceFlowPolicedDropPkts - "This object counts packets dropped on this Service Flow before transmission. Examples are because of violation of the Maximum Sustained Traffic Rate or, for UGS flows, because the packet exceeds the UGS grant size." docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." BTW, where is it specified that these MIBs report 0 for a DS SF on a CM? Thank you, André -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Thursday, January 30, 2003 12:35 PM To: 'Lejeune, Andre'; Margo Dolas; 'Pollak, Lucy'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 What do you propose then for the description of the docsQosServiceFlowPolicedDropPkts. I am content with the latest change to docsQosServiceFlowPolicedDelayPkts. Will Murwin -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Thursday, January 30, 2003 12:04 PM To: Margo Dolas; Murwin William-LWM008; 'Pollak, Lucy'; 'Lejeune, Andre'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Actually, for delayed packets, I preferred the version that was posted by Margo at some point. It is clear and leaves no ambiguity: For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." The problem with dropped packets is that there are more reasons why a packet may be dropped for a given SID queue, and I thought we were going to cover them all. The current definition does not cover them all. 1-What about packets (UGS BE or others) dropped when they cannot be transmitted because the DS signal was momentarily lost, sufficiently to stop upstream transmissions? 2-What about UGS packets dropped because the arrival rate exceeded the tx rate sufficiently to require cleaning the queue? Other cases may exist... I would like to suggest that we do not try to distinguish the reasons why packets are dropped, and count them all. André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Thursday, January 30, 2003 11:53 AM To: Murwin William-LWM008; 'Pollak, Lucy'; 'Lejeune, Andre'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I think that the description for docsQosServiceFlowPolicedDelayPkts looks good. What do you think of changing the description of docsQosServiceFlowPolicedDropPkts to read - "This object counts packets dropped in violation of the Maximum Sustained Traffic Rate. For UGS flows, this object counts packets dropped because the packet exceeds the UGS grant size." Regards, Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Thursday, 30 January, 2003 9:49 AM To: 'Pollak, Lucy'; 'Margo Dolas'; 'Lejeune, Andre'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Here is the propose text: docsQosServiceFlowPolicedDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object counts packets dropped because because the packet exceeds the UGS grant size." ::= { docsQosServiceFlowStatsEntry 6 } docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not count packets queued awaiting grants." ::= { docsQosServiceFlowStatsEntry 7 } There will be no new object! Please respond ASAP as the MIB gets posted today! Will Murwin -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Thursday, January 30, 2003 5:01 AM To: 'Margo Dolas'; 'Lejeune, Andre'; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Margo, I also do not see a problem if USG and best effort will share the same counter. What do you think about size dropped? I guess, all dropped should be counted together. Do you want to add different detailed counters for size and rate dropped? Personally, I think that existed counter is good enough. I agree, that description should be clarified. William, would you like to propose new text for docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts counters? Regards. Lucy -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Wednesday, January 29, 2003 9:36 PM To: Pollak, Lucy; 'Lejeune, Andre'; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre and Lucy, I believe that the test failures occurred because the spec was unclear in the past. The original understanding was that the docsQosServiceFlowPolicedDropPkts counter include only packets dropped in violation of the Max(T) equation. However, with failures at tComLabs dues to lack of clarity in the spec, many vendors coded to the test. I thought that adding a new counter to count UGS packets dropped because the packet exceeds the UGS grant would add an appropriate place to count these dropped packets. However, having said this, my objective is clarity in the descriptions. If the consensus is to count the dropped UGS packets in the docsQosServiceFlowPolicedDropPkts counter, the description should be changed to explicitly state this. Regards, Margo -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, 29 January, 2003 1:55 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 André. I do not think that to count something twice is so bad. The ifOutDiscard counter is integrated counter which shows the sum of all dropped packets on US. The docsQosServiceFlowPolicedDropPkts is per interface counter and give more detailed information. Again, I do not see a reason to change docsQosServiceFlowPolicedDropPkts definition. Thanks. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 8:43 PM To: Pollak, Lucy; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 In trying to make sure that the text was as clear as possible, I think I lost sight of the general goal, which should be to ensure that each dropped packet is counted somewhere and counted only once. We too implemented the counter to include UGS dropped packets, in particular if the rt policy is set to drop UGS packets that are too large. In reality, there are only 2 counters that count dropped packets: ifOutDiscard and docsQosServiceFlowPolicedDropPkts. So if a UGS packet needs to be dropped, where is it counted if it is not in docsQosServiceFlowPolicedDropPkts? André "does not know what he wants" L. -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, January 29, 2003 12:00 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Margo and André. I want to understand the reason for this change. I also familiar with this discussion and in the beginning understood "especially to limit the maximum rate of the flow" as "only to limit the maximum rate of the flow". But with this understanding we failed tComLabs tests. Now, I guess, most of the CMs already implemented this counter as integrated counter: Max rate + max size + grant size + grant rate dropped packets. And it seems the correct behavior, if somebody wants to compare classified packets against dropped+send. I suppose, for backward compatibility we need to leave docsQosServiceFlowPolicedDropPkts as is or even add the definition that it will count all dropped packets. In addition, I agree, we may add the set of reason's defined packet counters: docsQosServiceFlowSizeDropPkts docsQosServiceFlowRateDropPkts I do not see a reason to differentiate UGS and other SF types. In definition we can tell that MAX rate or grant rate is the reason for the drop. The same about size. I do not see a reason to change delayed packet also. Again, "especially" gives us opportunity to apply it to UGS also. The SF type will not be changed on-the-fly. What is the problem to show the same information for UGS? Regards. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 12:41 AM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Looks much better! I like it. Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 5:19 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, In thinking about it a bit more, I'd prefer to see more explicit text for the policed packets. What do you think of the following text? For the docsQosServiceFlowPolicedDropPkts description - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: owner-docsis-oss@cablelabs.com [mailto:owner-docsis-oss@cablelabs.com]On Behalf Of Margo Dolas Sent: Tuesday, 28 January, 2003 4:18 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, I agree with your simplification. The new text for the docsQosServiceFlowPolicedDropPkts description would then be - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." A similar simplification could be made to the description of docsQosServiceFlowPolicedDelayPkts. The new text would be - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 2:08 PM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I understand why I did not read this text properly then. I took the last sentence out of context. I don't think I had to stretch my imagination that much to take it out of context, it does not make any mention of UGS, and when the Maximum Sustained Traffic Rate is exceeded, the packet arrival rate does exceed the packet transmission rate. Instead of providing a series of examples for UGS flows, would it not be simpler to replace it with a statement that the parameter does not apply to UGS flows, since Max Sustained Rate is not applicable? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 1:14 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, Maximum Sustained Rate is not applicable for UGS flows (per section 8.2.7 and table 8-4 of the RFI I09 spec), so packets cannot violate the Maximum Sustained Rate for an UGS flow. In an UGS flow, you only evaluate the packet size versus the UGS grant size, and then queue the packet until you receive a grant for the flow's SID. If the queue is full (because packets are arriving faster than the grant rate), then the packet is dropped and ifOutDiscards is incremented. Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 11:17 AM To: Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I have a problem with the proposed text because I don't understand how to distinguish packets that are in violation of the Maximum Sustained rate from packets with arrival rate faster than the grant rate. What is the difference? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 4:43 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 30 17:53:07 2003 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 RAA12642 for ; Thu, 30 Jan 2003 17:53:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UMuLu03347 for ipcdn-archive@odin.ietf.org; Thu, 30 Jan 2003 17:56:21 -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 h0UMu6J03308; Thu, 30 Jan 2003 17:56:06 -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 h0UH8HJ15544 for ; Thu, 30 Jan 2003 12:08:17 -0500 Received: from scbh01.terayon.com (desktop.terayon.com [63.201.251.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04398 for ; Thu, 30 Jan 2003 12:04:41 -0500 (EST) Received: by SCBH01 with Internet Mail Service (5.5.2655.55) id ; Thu, 30 Jan 2003 09:06:37 -0800 Message-ID: From: "Lejeune, Andre" To: Margo Dolas , Murwin William-LWM008 , "'Pollak, Lucy'" , "'Lejeune, Andre'" , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Thu, 30 Jan 2003 09:04:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UH8IJ15545 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Actually, for delayed packets, I preferred the version that was posted by Margo at some point. It is clear and leaves no ambiguity: For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." The problem with dropped packets is that there are more reasons why a packet may be dropped for a given SID queue, and I thought we were going to cover them all. The current definition does not cover them all. 1-What about packets (UGS BE or others) dropped when they cannot be transmitted because the DS signal was momentarily lost, sufficiently to stop upstream transmissions? 2-What about UGS packets dropped because the arrival rate exceeded the tx rate sufficiently to require cleaning the queue? Other cases may exist... I would like to suggest that we do not try to distinguish the reasons why packets are dropped, and count them all. André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Thursday, January 30, 2003 11:53 AM To: Murwin William-LWM008; 'Pollak, Lucy'; 'Lejeune, Andre'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I think that the description for docsQosServiceFlowPolicedDelayPkts looks good. What do you think of changing the description of docsQosServiceFlowPolicedDropPkts to read - "This object counts packets dropped in violation of the Maximum Sustained Traffic Rate. For UGS flows, this object counts packets dropped because the packet exceeds the UGS grant size." Regards, Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Thursday, 30 January, 2003 9:49 AM To: 'Pollak, Lucy'; 'Margo Dolas'; 'Lejeune, Andre'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Here is the propose text: docsQosServiceFlowPolicedDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object counts packets dropped because because the packet exceeds the UGS grant size." ::= { docsQosServiceFlowStatsEntry 6 } docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not count packets queued awaiting grants." ::= { docsQosServiceFlowStatsEntry 7 } There will be no new object! Please respond ASAP as the MIB gets posted today! Will Murwin -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Thursday, January 30, 2003 5:01 AM To: 'Margo Dolas'; 'Lejeune, Andre'; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Margo, I also do not see a problem if USG and best effort will share the same counter. What do you think about size dropped? I guess, all dropped should be counted together. Do you want to add different detailed counters for size and rate dropped? Personally, I think that existed counter is good enough. I agree, that description should be clarified. William, would you like to propose new text for docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts counters? Regards. Lucy -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Wednesday, January 29, 2003 9:36 PM To: Pollak, Lucy; 'Lejeune, Andre'; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre and Lucy, I believe that the test failures occurred because the spec was unclear in the past. The original understanding was that the docsQosServiceFlowPolicedDropPkts counter include only packets dropped in violation of the Max(T) equation. However, with failures at tComLabs dues to lack of clarity in the spec, many vendors coded to the test. I thought that adding a new counter to count UGS packets dropped because the packet exceeds the UGS grant would add an appropriate place to count these dropped packets. However, having said this, my objective is clarity in the descriptions. If the consensus is to count the dropped UGS packets in the docsQosServiceFlowPolicedDropPkts counter, the description should be changed to explicitly state this. Regards, Margo -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, 29 January, 2003 1:55 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 André. I do not think that to count something twice is so bad. The ifOutDiscard counter is integrated counter which shows the sum of all dropped packets on US. The docsQosServiceFlowPolicedDropPkts is per interface counter and give more detailed information. Again, I do not see a reason to change docsQosServiceFlowPolicedDropPkts definition. Thanks. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 8:43 PM To: Pollak, Lucy; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 In trying to make sure that the text was as clear as possible, I think I lost sight of the general goal, which should be to ensure that each dropped packet is counted somewhere and counted only once. We too implemented the counter to include UGS dropped packets, in particular if the rt policy is set to drop UGS packets that are too large. In reality, there are only 2 counters that count dropped packets: ifOutDiscard and docsQosServiceFlowPolicedDropPkts. So if a UGS packet needs to be dropped, where is it counted if it is not in docsQosServiceFlowPolicedDropPkts? André "does not know what he wants" L. -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, January 29, 2003 12:00 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Margo and André. I want to understand the reason for this change. I also familiar with this discussion and in the beginning understood "especially to limit the maximum rate of the flow" as "only to limit the maximum rate of the flow". But with this understanding we failed tComLabs tests. Now, I guess, most of the CMs already implemented this counter as integrated counter: Max rate + max size + grant size + grant rate dropped packets. And it seems the correct behavior, if somebody wants to compare classified packets against dropped+send. I suppose, for backward compatibility we need to leave docsQosServiceFlowPolicedDropPkts as is or even add the definition that it will count all dropped packets. In addition, I agree, we may add the set of reason's defined packet counters: docsQosServiceFlowSizeDropPkts docsQosServiceFlowRateDropPkts I do not see a reason to differentiate UGS and other SF types. In definition we can tell that MAX rate or grant rate is the reason for the drop. The same about size. I do not see a reason to change delayed packet also. Again, "especially" gives us opportunity to apply it to UGS also. The SF type will not be changed on-the-fly. What is the problem to show the same information for UGS? Regards. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 12:41 AM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Looks much better! I like it. Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 5:19 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, In thinking about it a bit more, I'd prefer to see more explicit text for the policed packets. What do you think of the following text? For the docsQosServiceFlowPolicedDropPkts description - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: owner-docsis-oss@cablelabs.com [mailto:owner-docsis-oss@cablelabs.com]On Behalf Of Margo Dolas Sent: Tuesday, 28 January, 2003 4:18 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, I agree with your simplification. The new text for the docsQosServiceFlowPolicedDropPkts description would then be - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." A similar simplification could be made to the description of docsQosServiceFlowPolicedDelayPkts. The new text would be - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 2:08 PM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I understand why I did not read this text properly then. I took the last sentence out of context. I don't think I had to stretch my imagination that much to take it out of context, it does not make any mention of UGS, and when the Maximum Sustained Traffic Rate is exceeded, the packet arrival rate does exceed the packet transmission rate. Instead of providing a series of examples for UGS flows, would it not be simpler to replace it with a statement that the parameter does not apply to UGS flows, since Max Sustained Rate is not applicable? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 1:14 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, Maximum Sustained Rate is not applicable for UGS flows (per section 8.2.7 and table 8-4 of the RFI I09 spec), so packets cannot violate the Maximum Sustained Rate for an UGS flow. In an UGS flow, you only evaluate the packet size versus the UGS grant size, and then queue the packet until you receive a grant for the flow's SID. If the queue is full (because packets are arriving faster than the grant rate), then the packet is dropped and ifOutDiscards is incremented. Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 11:17 AM To: Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I have a problem with the proposed text because I don't understand how to distinguish packets that are in violation of the Maximum Sustained rate from packets with arrival rate faster than the grant rate. What is the difference? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 4:43 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 30 17:53:08 2003 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 RAA12652 for ; Thu, 30 Jan 2003 17:53:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UMuLw03361 for ipcdn-archive@odin.ietf.org; Thu, 30 Jan 2003 17:56:21 -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 h0UMu8J03338; Thu, 30 Jan 2003 17:56:08 -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 h0UJEFJ22952 for ; Thu, 30 Jan 2003 14:14:15 -0500 Received: from scbh01.terayon.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07442 for ; Thu, 30 Jan 2003 14:10:34 -0500 (EST) Received: by SCBH01 with Internet Mail Service (5.5.2655.55) id ; Thu, 30 Jan 2003 11:04:00 -0800 Message-ID: From: "Lejeune, Andre" To: Murwin William-LWM008 , Margo Dolas , "'Pollak, Lucy'" , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Thu, 30 Jan 2003 11:01:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UJEFJ22953 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Will, Please excuse me for not having sent a rewording proposal initially - I had limited time to write my response. Here is what I would think of: docsQosServiceFlowPolicedDropPkts - "This object counts packets dropped on this Service Flow before transmission. Examples are because of violation of the Maximum Sustained Traffic Rate or, for UGS flows, because the packet exceeds the UGS grant size." docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." BTW, where is it specified that these MIBs report 0 for a DS SF on a CM? Thank you, André -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Thursday, January 30, 2003 12:35 PM To: 'Lejeune, Andre'; Margo Dolas; 'Pollak, Lucy'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 What do you propose then for the description of the docsQosServiceFlowPolicedDropPkts. I am content with the latest change to docsQosServiceFlowPolicedDelayPkts. Will Murwin -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Thursday, January 30, 2003 12:04 PM To: Margo Dolas; Murwin William-LWM008; 'Pollak, Lucy'; 'Lejeune, Andre'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Actually, for delayed packets, I preferred the version that was posted by Margo at some point. It is clear and leaves no ambiguity: For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." The problem with dropped packets is that there are more reasons why a packet may be dropped for a given SID queue, and I thought we were going to cover them all. The current definition does not cover them all. 1-What about packets (UGS BE or others) dropped when they cannot be transmitted because the DS signal was momentarily lost, sufficiently to stop upstream transmissions? 2-What about UGS packets dropped because the arrival rate exceeded the tx rate sufficiently to require cleaning the queue? Other cases may exist... I would like to suggest that we do not try to distinguish the reasons why packets are dropped, and count them all. André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Thursday, January 30, 2003 11:53 AM To: Murwin William-LWM008; 'Pollak, Lucy'; 'Lejeune, Andre'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I think that the description for docsQosServiceFlowPolicedDelayPkts looks good. What do you think of changing the description of docsQosServiceFlowPolicedDropPkts to read - "This object counts packets dropped in violation of the Maximum Sustained Traffic Rate. For UGS flows, this object counts packets dropped because the packet exceeds the UGS grant size." Regards, Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Thursday, 30 January, 2003 9:49 AM To: 'Pollak, Lucy'; 'Margo Dolas'; 'Lejeune, Andre'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Here is the propose text: docsQosServiceFlowPolicedDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object counts packets dropped because because the packet exceeds the UGS grant size." ::= { docsQosServiceFlowStatsEntry 6 } docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not count packets queued awaiting grants." ::= { docsQosServiceFlowStatsEntry 7 } There will be no new object! Please respond ASAP as the MIB gets posted today! Will Murwin -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Thursday, January 30, 2003 5:01 AM To: 'Margo Dolas'; 'Lejeune, Andre'; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Margo, I also do not see a problem if USG and best effort will share the same counter. What do you think about size dropped? I guess, all dropped should be counted together. Do you want to add different detailed counters for size and rate dropped? Personally, I think that existed counter is good enough. I agree, that description should be clarified. William, would you like to propose new text for docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts counters? Regards. Lucy -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Wednesday, January 29, 2003 9:36 PM To: Pollak, Lucy; 'Lejeune, Andre'; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre and Lucy, I believe that the test failures occurred because the spec was unclear in the past. The original understanding was that the docsQosServiceFlowPolicedDropPkts counter include only packets dropped in violation of the Max(T) equation. However, with failures at tComLabs dues to lack of clarity in the spec, many vendors coded to the test. I thought that adding a new counter to count UGS packets dropped because the packet exceeds the UGS grant would add an appropriate place to count these dropped packets. However, having said this, my objective is clarity in the descriptions. If the consensus is to count the dropped UGS packets in the docsQosServiceFlowPolicedDropPkts counter, the description should be changed to explicitly state this. Regards, Margo -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, 29 January, 2003 1:55 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 André. I do not think that to count something twice is so bad. The ifOutDiscard counter is integrated counter which shows the sum of all dropped packets on US. The docsQosServiceFlowPolicedDropPkts is per interface counter and give more detailed information. Again, I do not see a reason to change docsQosServiceFlowPolicedDropPkts definition. Thanks. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 8:43 PM To: Pollak, Lucy; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 In trying to make sure that the text was as clear as possible, I think I lost sight of the general goal, which should be to ensure that each dropped packet is counted somewhere and counted only once. We too implemented the counter to include UGS dropped packets, in particular if the rt policy is set to drop UGS packets that are too large. In reality, there are only 2 counters that count dropped packets: ifOutDiscard and docsQosServiceFlowPolicedDropPkts. So if a UGS packet needs to be dropped, where is it counted if it is not in docsQosServiceFlowPolicedDropPkts? André "does not know what he wants" L. -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, January 29, 2003 12:00 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Margo and André. I want to understand the reason for this change. I also familiar with this discussion and in the beginning understood "especially to limit the maximum rate of the flow" as "only to limit the maximum rate of the flow". But with this understanding we failed tComLabs tests. Now, I guess, most of the CMs already implemented this counter as integrated counter: Max rate + max size + grant size + grant rate dropped packets. And it seems the correct behavior, if somebody wants to compare classified packets against dropped+send. I suppose, for backward compatibility we need to leave docsQosServiceFlowPolicedDropPkts as is or even add the definition that it will count all dropped packets. In addition, I agree, we may add the set of reason's defined packet counters: docsQosServiceFlowSizeDropPkts docsQosServiceFlowRateDropPkts I do not see a reason to differentiate UGS and other SF types. In definition we can tell that MAX rate or grant rate is the reason for the drop. The same about size. I do not see a reason to change delayed packet also. Again, "especially" gives us opportunity to apply it to UGS also. The SF type will not be changed on-the-fly. What is the problem to show the same information for UGS? Regards. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 12:41 AM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Looks much better! I like it. Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 5:19 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, In thinking about it a bit more, I'd prefer to see more explicit text for the policed packets. What do you think of the following text? For the docsQosServiceFlowPolicedDropPkts description - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: owner-docsis-oss@cablelabs.com [mailto:owner-docsis-oss@cablelabs.com]On Behalf Of Margo Dolas Sent: Tuesday, 28 January, 2003 4:18 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, I agree with your simplification. The new text for the docsQosServiceFlowPolicedDropPkts description would then be - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." A similar simplification could be made to the description of docsQosServiceFlowPolicedDelayPkts. The new text would be - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 2:08 PM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I understand why I did not read this text properly then. I took the last sentence out of context. I don't think I had to stretch my imagination that much to take it out of context, it does not make any mention of UGS, and when the Maximum Sustained Traffic Rate is exceeded, the packet arrival rate does exceed the packet transmission rate. Instead of providing a series of examples for UGS flows, would it not be simpler to replace it with a statement that the parameter does not apply to UGS flows, since Max Sustained Rate is not applicable? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 1:14 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, Maximum Sustained Rate is not applicable for UGS flows (per section 8.2.7 and table 8-4 of the RFI I09 spec), so packets cannot violate the Maximum Sustained Rate for an UGS flow. In an UGS flow, you only evaluate the packet size versus the UGS grant size, and then queue the packet until you receive a grant for the flow's SID. If the queue is full (because packets are arriving faster than the grant rate), then the packet is dropped and ifOutDiscards is incremented. Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 11:17 AM To: Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I have a problem with the proposed text because I don't understand how to distinguish packets that are in violation of the Maximum Sustained rate from packets with arrival rate faster than the grant rate. What is the difference? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 4:43 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Jan 30 17:53:09 2003 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 RAA12657 for ; Thu, 30 Jan 2003 17:53:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UMuN403374 for ipcdn-archive@odin.ietf.org; Thu, 30 Jan 2003 17:56:23 -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 h0UMu7J03323; Thu, 30 Jan 2003 17:56:07 -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 h0UJ90J22795 for ; Thu, 30 Jan 2003 14:09:00 -0500 Received: from go4.ext.ti.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07260 for ; Thu, 30 Jan 2003 14:05:19 -0500 (EST) Received: from dlep52.itg.ti.com ([157.170.134.103]) by go4.ext.ti.com (8.12.6/8.12.6) with ESMTP id h0UJ8mqd015436; Thu, 30 Jan 2003 13:08:48 -0600 (CST) Received: from dlep98.itg.ti.com (localhost [127.0.0.1]) by dlep52.itg.ti.com (8.12.6/8.12.6) with ESMTP id h0UJ8lPW017369; Thu, 30 Jan 2003 13:08:48 -0600 (CST) Received: from dile70.itg.ti.com (dile70.itg.ti.com [137.167.177.22]) by dlep98.itg.ti.com (8.9.3/8.9.3) with ESMTP id NAA14118; Thu, 30 Jan 2003 13:08:46 -0600 (CST) Received: by dile70.itg.ti.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Jan 2003 21:08:44 +0200 Message-ID: <7DF2A1B372BBD611912F00508BDFBA9A9C1879@dile03.itg.ti.com> From: "Pollak, Lucy" To: "'Murwin William-LWM008'" , "'Lejeune, Andre'" , Margo Dolas , "'Docsis-Oss (E-mail)'" , "'IPCDN (E-mail)'" Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Date: Thu, 30 Jan 2003 21:08:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0UJ90J22796 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit William, I think that André is right speaking about docsQosServiceFlowPolicedDropPkts. We need to leave it counting all dropped packets. What about: DESCRIPTION "The number of Packet Data PDUs classified to this service flow, but dropped from some reason. This object does not count dropped MAC-specific management messages. Dropped unclassified upstream user date packets (i.e. non MAC-management) forwarded to the default upstream service flow should be incremented for this object." Regards. Lucy -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Thursday, January 30, 2003 7:35 PM To: 'Lejeune, Andre'; Margo Dolas; Pollak, Lucy; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 What do you propose then for the description of the docsQosServiceFlowPolicedDropPkts. I am content with the latest change to docsQosServiceFlowPolicedDelayPkts. Will Murwin -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Thursday, January 30, 2003 12:04 PM To: Margo Dolas; Murwin William-LWM008; 'Pollak, Lucy'; 'Lejeune, Andre'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Actually, for delayed packets, I preferred the version that was posted by Margo at some point. It is clear and leaves no ambiguity: For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." The problem with dropped packets is that there are more reasons why a packet may be dropped for a given SID queue, and I thought we were going to cover them all. The current definition does not cover them all. 1-What about packets (UGS BE or others) dropped when they cannot be transmitted because the DS signal was momentarily lost, sufficiently to stop upstream transmissions? 2-What about UGS packets dropped because the arrival rate exceeded the tx rate sufficiently to require cleaning the queue? Other cases may exist... I would like to suggest that we do not try to distinguish the reasons why packets are dropped, and count them all. André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Thursday, January 30, 2003 11:53 AM To: Murwin William-LWM008; 'Pollak, Lucy'; 'Lejeune, Andre'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I think that the description for docsQosServiceFlowPolicedDelayPkts looks good. What do you think of changing the description of docsQosServiceFlowPolicedDropPkts to read - "This object counts packets dropped in violation of the Maximum Sustained Traffic Rate. For UGS flows, this object counts packets dropped because the packet exceeds the UGS grant size." Regards, Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Thursday, 30 January, 2003 9:49 AM To: 'Pollak, Lucy'; 'Margo Dolas'; 'Lejeune, Andre'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Here is the propose text: docsQosServiceFlowPolicedDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object counts packets dropped because because the packet exceeds the UGS grant size." ::= { docsQosServiceFlowStatsEntry 6 } docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not count packets queued awaiting grants." ::= { docsQosServiceFlowStatsEntry 7 } There will be no new object! Please respond ASAP as the MIB gets posted today! Will Murwin -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Thursday, January 30, 2003 5:01 AM To: 'Margo Dolas'; 'Lejeune, Andre'; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Margo, I also do not see a problem if USG and best effort will share the same counter. What do you think about size dropped? I guess, all dropped should be counted together. Do you want to add different detailed counters for size and rate dropped? Personally, I think that existed counter is good enough. I agree, that description should be clarified. William, would you like to propose new text for docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts counters? Regards. Lucy -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Wednesday, January 29, 2003 9:36 PM To: Pollak, Lucy; 'Lejeune, Andre'; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre and Lucy, I believe that the test failures occurred because the spec was unclear in the past. The original understanding was that the docsQosServiceFlowPolicedDropPkts counter include only packets dropped in violation of the Max(T) equation. However, with failures at tComLabs dues to lack of clarity in the spec, many vendors coded to the test. I thought that adding a new counter to count UGS packets dropped because the packet exceeds the UGS grant would add an appropriate place to count these dropped packets. However, having said this, my objective is clarity in the descriptions. If the consensus is to count the dropped UGS packets in the docsQosServiceFlowPolicedDropPkts counter, the description should be changed to explicitly state this. Regards, Margo -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, 29 January, 2003 1:55 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 André. I do not think that to count something twice is so bad. The ifOutDiscard counter is integrated counter which shows the sum of all dropped packets on US. The docsQosServiceFlowPolicedDropPkts is per interface counter and give more detailed information. Again, I do not see a reason to change docsQosServiceFlowPolicedDropPkts definition. Thanks. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 8:43 PM To: Pollak, Lucy; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 In trying to make sure that the text was as clear as possible, I think I lost sight of the general goal, which should be to ensure that each dropped packet is counted somewhere and counted only once. We too implemented the counter to include UGS dropped packets, in particular if the rt policy is set to drop UGS packets that are too large. In reality, there are only 2 counters that count dropped packets: ifOutDiscard and docsQosServiceFlowPolicedDropPkts. So if a UGS packet needs to be dropped, where is it counted if it is not in docsQosServiceFlowPolicedDropPkts? André "does not know what he wants" L. -----Original Message----- From: Pollak, Lucy [mailto:Lucy.pollak@ti.com] Sent: Wednesday, January 29, 2003 12:00 PM To: 'Lejeune, Andre'; Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Margo and André. I want to understand the reason for this change. I also familiar with this discussion and in the beginning understood "especially to limit the maximum rate of the flow" as "only to limit the maximum rate of the flow". But with this understanding we failed tComLabs tests. Now, I guess, most of the CMs already implemented this counter as integrated counter: Max rate + max size + grant size + grant rate dropped packets. And it seems the correct behavior, if somebody wants to compare classified packets against dropped+send. I suppose, for backward compatibility we need to leave docsQosServiceFlowPolicedDropPkts as is or even add the definition that it will count all dropped packets. In addition, I agree, we may add the set of reason's defined packet counters: docsQosServiceFlowSizeDropPkts docsQosServiceFlowRateDropPkts I do not see a reason to differentiate UGS and other SF types. In definition we can tell that MAX rate or grant rate is the reason for the drop. The same about size. I do not see a reason to change delayed packet also. Again, "especially" gives us opportunity to apply it to UGS also. The SF type will not be changed on-the-fly. What is the problem to show the same information for UGS? Regards. Lucy -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Wednesday, January 29, 2003 12:41 AM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Looks much better! I like it. Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 5:19 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, In thinking about it a bit more, I'd prefer to see more explicit text for the policed packets. What do you think of the following text? For the docsQosServiceFlowPolicedDropPkts description - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." For the docsQosServiceFlowPolicedDelayPkts description - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: owner-docsis-oss@cablelabs.com [mailto:owner-docsis-oss@cablelabs.com]On Behalf Of Margo Dolas Sent: Tuesday, 28 January, 2003 4:18 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, I agree with your simplification. The new text for the docsQosServiceFlowPolicedDropPkts description would then be - "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." A similar simplification could be made to the description of docsQosServiceFlowPolicedDelayPkts. The new text would be - "This object counts only packets delayed in violation of the Maximum Sustained Traffic Rate. This object does not apply to UGS flows because the Maximum Sustained Traffic Rate does not apply." Regards, Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 2:08 PM To: Margo Dolas; Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I understand why I did not read this text properly then. I took the last sentence out of context. I don't think I had to stretch my imagination that much to take it out of context, it does not make any mention of UGS, and when the Maximum Sustained Traffic Rate is exceeded, the packet arrival rate does exceed the packet transmission rate. Instead of providing a series of examples for UGS flows, would it not be simpler to replace it with a statement that the parameter does not apply to UGS flows, since Max Sustained Rate is not applicable? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Tuesday, January 28, 2003 1:14 PM To: Lejeune, Andre; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Andre, Maximum Sustained Rate is not applicable for UGS flows (per section 8.2.7 and table 8-4 of the RFI I09 spec), so packets cannot violate the Maximum Sustained Rate for an UGS flow. In an UGS flow, you only evaluate the packet size versus the UGS grant size, and then queue the packet until you receive a grant for the flow's SID. If the queue is full (because packets are arriving faster than the grant rate), then the packet is dropped and ifOutDiscards is incremented. Margo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@imedia.com] Sent: Tuesday, 28 January, 2003 11:17 AM To: Margo Dolas; Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 I have a problem with the proposed text because I don't understand how to distinguish packets that are in violation of the Maximum Sustained rate from packets with arrival rate faster than the grant rate. What is the difference? Thanks, André -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 4:43 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I agree with your changes. Margo -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com] Sent: Monday, 27 January, 2003 4:16 PM To: 'Margo Dolas'; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 Responses in-line... -----Original Message----- From: Margo Dolas [mailto:mdolas@broadcom.com] Sent: Monday, January 27, 2003 3:57 PM To: Murwin William-LWM008; 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: RE: [ipcdn] Deadline for Comments of QoS MIB version 7 William, I'd like to clarify the definition of docsQosServiceFlowPolicedDropPkts and docsQosServiceFlowPolicedDelayPkts. These counters have been discussed on the reflector several times, and we have recently had discussions with tComLabs over the ambiguity of the descriptions of these counters. I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDropPkts - "This object counts only packets dropped in violation of the Max(T) equation. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." A new counter should be created to describe packets dropped in violation of the UGS grant size. Packets sent on the primary service flow in violation of the UGS grant size should be counted on the primary service flow's counters. We would like change the above test to be: "This object counts only packets dropped in violation of the Maximum Sustained Traffic Rate. Particularly for UGS flows, this object does not include packets dropped or otherwise not sent on this flow because the packet exceeds the UGS grant size. This object does not count packets dropped because the packet arrival rate is faster than the grant rate (these packets should be counted in the ifOutDiscards counter)." Suggested text for the proposed counter - "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." The new object would be: docsQosServiceUgsDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For UGS flows, the number of packets dropped because the packet exceeds the UGS grant size. This object does not count packets sent on the primary flow based on the request-transmission policy settings. For non-UGS flows, this counter returns zero." ::= { docsQosServiceFlowStatsEntry 10 } I suggest that the following sentences be added to the description of docsQosServiceFlowPolicedDelayPkts - "This object counts only packets delayed in violation of the Max(T) equation. Particularly for UGS flows, this object does not count packets queued awaiting grants." Again just change "Max(T) equation" to "Maximum Sustained Traffic Rate" I suggest that the following sentence be added to the description of docsQosServiceFlowPkts - "Particularly for UGS flows, packets sent on the primary service flow in violation of the UGS grant size should be counted only on the primary service flow's counters." Ok. Regards, Margo Dolas -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Murwin William-LWM008 Sent: Friday, 24 January, 2003 11:29 AM To: 'Docsis-Oss (E-mail)'; 'IPCDN (E-mail)' Subject: [ipcdn] Deadline for Comments of QoS MIB version 7 Monday 1/27 is the Deadline for Comments of version 7 of the QoS MIB. By Wednesday we will be posting version 7 of the QoS MIB on the IETF site. Please review and get your comments in asap. Thanks. Mike Patrick and Will Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Jan 31 17:11:55 2003 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 RAA20368 for ; Fri, 31 Jan 2003 17:11:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VMFbU23485 for ipcdn-archive@odin.ietf.org; Fri, 31 Jan 2003 17:15:37 -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 h0VMFXJ23478; Fri, 31 Jan 2003 17:15:33 -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 h0VMEHJ23438 for ; Fri, 31 Jan 2003 17:14:17 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20349 for ; Fri, 31 Jan 2003 17:10:04 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h0VMECe5023965 for ; Fri, 31 Jan 2003 15:14:12 -0700 (MST) Received: [from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id PAA07353 for ; Fri, 31 Jan 2003 15:13:37 -0700 (MST)] Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59) id ; Fri, 31 Jan 2003 17:12:48 -0500 Message-ID: <19CD0E423FC1D611893500508B6F0B9C08496C@ma07exm01.dma.isg.mot.com> From: Murwin William-LWM008 To: "Docsis-Oss (E-mail) (E-mail)" , "IPCDN (E-mail) (E-mail)" Cc: "Michael W. Patrick (E-mail)" Date: Fri, 31 Jan 2003 17:12:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] docsQosServiceFlowPolicedDropPkts & docsQosServiceFlowPolicedDela yPkts Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , After a discussion with Mike Patrick, docsQosServiceFlowPolicedDropPkts was not meant to count for any reason a packet was dropped after being classified to a service flow. It is meant to count only packets dropped to rate policing. Thus the text has been changed again to meet these original requirements. There was too much ambiguity to the previous description. docsQosServiceFlowPolicedDropPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Packet Data PDUs classified to this service flow dropped due to: (1) implementation-dependent excessive delay while enforcing the Maximum Sustained Traffic Rate; or (2) UGS packets dropped due to exceeding the Unsolicited Grant Size with a Request/Transmission policy that require such packets to be dropped. Classified packets dropped due to other reasons must be counted in ifOutDiscards for interface of this service flow." ::= { docsQosServiceFlowStatsEntry 6 } docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts only packets delayed in order to maintain the Maximum Sustained Traffic Rate. This object will always report a value of 0 for UGS flows because the Maximum Sustained Traffic Rate does not apply." ::= { docsQosServiceFlowStatsEntry 7 } The QoS MIB will be submitted tonight at Midnight i.e. Feb 1, 2003. Any further discussion of this issue can be raised at the interim Working Group Meeting ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn