Subject: [ipcdn] rf mib draft v6 to draft v7 suggestions

From: "Raftus, David" <[email-masked]>
Date: Tue, 17 Jun 2003 08:36:33 -0700

Hi everyone,
 
Since RF mib v2 draft 6 was released in March, I have received publicly or
privately 17 requests for updates/changes to appear in draft v7. The people
on the To: list have participated in either initiating or commenting on the
suggestions. 
 
Could I ask these people to please verify their suggestions as they are
listed below? This mib update from v6 to v7 is extensive - want to ensure
data is accurate before undertaking. The wider communities are also welcome
to comment.
 
Thanks for your time,
Dave

1) Return name to pre draft v6 DOCS-IF-MIB from draft v6 DOCS-IETF-RFI-MIB. 

Contributors - Rich Woundy IPCDN/Comcast, Minnie Lu Cisco, Steve Malenfant
Com21

2) docsIfCmtsChannelUtUtilization formula - remove line (100 * ((raw bytes -
stuffed bytes) / raw bytes))
since it assumes that MPEG payload consists only DOC MAC payload. As we 
know, MPEG could consist video payload and NULL packets. Suggest to remove 
this line since the first 2 lines in the formula are good enough.

Contributor - Minnie Lu    Cisco

3) Add discontinuity descriptions to all counters related to an interface.

Contributor - Minnie Lu    Cisco

4) docsIfCmtsInsertInterval - For the docsIfCmtsInsertInterval object, there
is no such thing as a 
"broadcast station maintenance" interval for new modems joining the network.
Station should be 
changed to initial to make the text read - "The amount of time to elapse
between each broadcast 
initial maintenance grant.  Broadcast initial maintenance grants are used to
allow new cable modems 
to join the network.  Zero indicates that a vendor-specific algorithm is
used instead of a fixed time.  
Maximum amount of time permitted by the specification is 2 seconds."

Contributor - Margo Dolas Broadcom

5) docsIfCmtsModPreambleType - (Joel) In docsIfCmtsModulationTable, the
docsIfCmtsModPreambleType object has 
2 possible values qpsk0(1) and qpsk1(2). It seems like it's the only object
in this table without a 
meaningful default value when this parameter does not make sense. For
instance, for a TDMA modulation 
profile using QAM16, the actual preamble type is indeed not QPSK0 but
something else. Does it make sense 
to have a value of 0 in this case, like
docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA profiles?

(Eduardo) for the benefit of clarifications wouldn't be good to have a
enumeration unknown(0) for this 
object when not a 2.0 burst ?
Also a note in the DESCRIPTION like "if docsIfCmtsModChannelType is tdma(1)
a value unknown(0) is used for this object" 
I would say unknown(0) rather than unknown(3) since it looks like the
possible current implementation may be reporting  
'0' , and defendable in IETF since RFC 3291 uses '0' for inetAddressType

Contributors - Joel Demarty Juniper, Eduardo Cardona Cablelabs

6) docsIfUpstreamChannelTable clone mechanism - improve descriptive wording.
The spec is vague about the minimum set of parameters 
that the 
CMTS must transfer during a clone operation to be DOCSIS 2.0 compliant. Only
those starting with docsIfUpChannelScdma or 
all parameters defining an SCDMA channel, like the channel width? Then what
about the frequency? 
Definitely, this clone mechanism is sophisticated enough that it would
deserve a more detailed specification 
(and testing) and, as a consequence, an ECR.

Contributor - Joel Demarty Juniper

7) docsIfUpChannelPreEqEnable - add DEFVAL clause.

Contributor - John Gillis ADC

8) docsIfCmtsUpChnlCtrUcastGrantedMslots - In Cisco CMTS, we use IUC14
(reserved) and SID (HEX): 1FFF (max. of 
unicast sid number) for quite some time.
Q: Should it be counted in docsIfCmtsUpChnlCtrUcastGrantedMslots ?
My personal think that this objects seems to mean the 
meaningful  UNICAST SID, so user could get a good idea about the how many 
minislots really assigned to some meaningful CM.  So, the reserved IUCs 
should be excluded from this object though minislots for reserved IUCs are 
still be counted into docsIfCmtsUpChnlCtrTotalMslots.
Minnie,
I agree, I think IUC14 grants to SID 1FFF (assuming the CMTS reserves
that SID to mean no CM) should not be counted in UcastGrantedMslots.
I also think (and maybe this case is more obvious) than grants to SID 0
should not be counted in UcastGrantedMslots.
This brings up a question that I've had for some time.  Why does the
Cisco CMTS use IUC14 and SID 1FFF????  The use of IUC14 is prohibited by
the spec, since it is labeled as "Reserved", and SID 0 is already
defined to mean "no CM".
-Greg

Contributors - Minnie Lu Cisco, Greg White Cablelabs

9) docsIfCmStatusTable - possibly add new objects for successful/failed ucc
transactions. 
Hi, Alex,
I do not think that this is good idea. What will you count into
docsQosDCCAcks? The relationships between DCC Req/Rsp/Ack is important and
should not be lost because of UCC additions. I guess, the better place for
this counters is RFI MIB docsIfCmStatusTable. It may be extended in future
versions.
Regards.
Lucy
Hello all,
A question about counting successful and failed UCC transactions.
It seems like there is no counters dedicated for UCC failed or
succeeded operation as it is for DCC transactions.
The question is, since UCC is a subset of DCC operation for 1.1 modem,
should the modem count UCC transactions in DCC counters (docsQosDCCs,
docsQosDCCFails) ?
Thank you in advance.

Contributors - Lucy Pollak TI, Alex Betis Coresma

10) docsIfUpChannelPreEqEnable, docsIfCmStatusEqualizationData - clarify
descriptions.
Lucy,
Sorry for the delay in responding.  I don't have an objection to your
proposal, as long as the 
format of the object is clear.
To summarize, the object docsIfCmStatusEqualizationData will only include
the "value" from figure 8-23.  
In other words, the first byte reported in the MIB object will be the main
tap location.  A clarification 
should also be made to the description of docsIfUpChannelPreEqEnable to
indicate your interpretation (b). 
Regarding the question about reverse taps, figure 8-23 is a simplification
of figure 6-23 from the 1.1 RFI 
spec (which includes a format to encode reverse taps).  It seems to make
sense to me to use the format 
shown in that figure.  Perhaps this MIB object could be clarified to
reference both figures.
-Greg

Greg,
to summarize our objections:
1. MIB requires equalization data, then type/length is irrelevant.
2. There are 2 possible types 4 (Transmit Equalization Adjust) or 9
(Transmit Equalization Set), which is 
irrelevant after convolution.
3. To be consistent with DS equa data, some TLV should be added also into
it. What?
We propose to use only value from referenced figure without type/length to
avoid questions in the future. If not, 
(2) and (3) should be clarified. I guess, that it will be also very helpful
if clarification (b) will be entered into MIB. 
Best Regards.
Lucy

Contributors - Lucy Pollak TI, Greg White Cablelabs

11) docsIfSignalQualityEntry - clarify wording for back compatibility.
In draft -03 the description of  docsIfSignalQualityEntry was changed 
from : 
docsIfSignalQualityEntry OBJECT-TYPE 
           SYNTAX      DocsIfSignalQualityEntry 
           MAX-ACCESS  not-accessible 
           STATUS      current 
           DESCRIPTION 
               "At the CM, describes the PHY characteristics of a 
                downstream channel. At the CMTS, describes the PHY 
signal 
                quality of an upstream channel. 
                An entry in this table exists for each ifEntry with an 
                ifType of docsCableUpstream(129) for Cable Modem 
Termination 
                Systems and docsCableDownstream(128) for Cable Modems." 
           INDEX { ifIndex } 
           ::= { docsIfSignalQualityTable 1 } 
to : 
docsIfSignalQualityEntry OBJECT-TYPE 
        SYNTAX      DocsIfSignalQualityEntry 
        MAX-ACCESS  not-accessible 
        STATUS      current 
        DESCRIPTION 
            "At the CM, describes the PHY characteristics of a 
             downstream channel. At the CMTS, describes the PHY signal 
             quality of an upstream channel. 
             An entry in this table exists for each ifEntry with an 
             ifType of docsCableUpstreamChannel(205) for Cable Modem 
Termination 
             Systems and docsCableDownstream(128) for Cable Modems." 
        INDEX { ifIndex } 
        ::= { docsIfSignalQualityTable 1 } 
But now RFI mib also apply to 1.1 CMTSes with no concept of ifType 205 
but 129 

Contributor - Eduardo Cardona Cablelabs

12) docsIfCmtsCmStatusValue - add new defined value
registeredBPIInitializing(9),
deprecate former value operational(8).

Contributors - Eduardo Cardona Cablelabs, Lucy Pollak TI, Minnie Lu Cisco,
David White Arris,
Matt Schmitt Arris, Kirk Friedman Correlant, Fred Oko Stargus, Joe Godas
Kar-el, Steve Malenfant Com21

13) Adjust compliance statements for objects designated optional. Add
separate augmentation table for 
optional objects in docsIfCmtsUpChannelCounterTable.

Contributors - Will Murwin Motorola, Rich Woundy IPCDN/Comcast, Mike StJohns
Mindspring, Eduardo Cardona Cablelabs

14) Add section explaining counter interaction between Docsis 1.0/1.1/2.0.
The QOS MIB tried to handle
DOCSIS 1.1 changes to RFC2670. Now that rfc2670 is being obsoleted, the
rf-mib v2 and the DOCSIS OSS Specs is the place
that should clearly state how these counters and other tables interact in
DOCSIS 1.0, DOCSIS 1.1, and DOCSIS 2.0.
I would even hope to see a section in the rf-mib v2, "Interoperation with
the version of DOCSIS" like or to replace
what the DOCSIS QOS MIB has. This is the place to describe what table are
populated under the docsIfMib when the
the modems are registering.
This way this issue can be re-discussed and whatever conculsion is reached,
can be document in the description of those
objects.

Contributor - Will Murwin Motorola, Minnie Lu Cisco

15) Change docsIfCmtsServiceTable to count packets for both upstream and
downstream flows. 
One of the things that has long been an issue with the RF MIB is that the
docsIfCmtsServiceTable only counts 
InOctets and InPackets (i.e. upstream packets only). If the reason for
keeping this table is to support DOCSIS 
1.0 modems would it also make sense to add downstream packet counts to this
table, too? Many CMTS'es already 
count this information and store it in a proprietary MIB. It would be nice
to standardize this as a requirement 
so that NMS such as usage monitoring systems could (a) count on it existing
and (b) find it in a standard location.

Contributor - Andrew Sundelin Stargus

16) Add 4 objects to docsIfCmtsCmStatusTable
While writing DOCS-IETF-QOS-MIB version 9, I find myself still thinking
about Minnie suggestion of having  
docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets count for DOCSIS
1.1 and 2.0. Even though the QOS 
MIB has pawned off this discussion, I have had some thoughts on the subject.
(1) If these counters where used to count the DOCSIS 1.1 and 2.0, than this
would the best place in all 
of the mibs to
    get a quick summary of the upstream data received by a particular modem,
no matter the version.
(2) At the same time, The rest of the docsIfCmtsCmServiceTable might not
make sense for DOCSIS 1.1 or 2.0
However the more I looked around at the different counters that existed in
all of MIB required by DOCSIS, 
the more I kept looking for an overall counter on the CMTS to count data
packet received and transmitted 
for a particular CM. 
I would like to start a discussion on about adding 4 new object to the
docsIfCmtsCmStatusTable:
docsIfCmtsCmStatusInPackets 
docsIfCmtsCmStatusInOctets
docsIfCmtsCmStatusOutPackets
docsIfCmtsCmStatusOutoctets
While I understand that these counts can be gathered by via numerous objects
on both the CMTS and CM 
and then just appling simple math. However I want to query only one agent
and just get a quick summary 
without have to determine which version of DOCSIS the modem is, which will
determine which mibs I look etc.
and objects I query.

For example if I want query only one agent(i.e. the CMTS) and get the number
of transmitted and received 
data for each CM, then 
       (1) GET-NEXT the docsIfCmtsCmStatusRegMode to see what version of
DOCSIS this modem is operting 

       if 'docsis10(1)' then 
                     (2) WALK the entire docsIfCmtsServiceTable for ifIndex
and SID that
                       have docsIfCmtsServiceNewCmStatusIndex that matches
the index for step (1).
       
                     (3) Add the all the instances of
docsIfCmtsServiceInPacket for the
                       ifIndex and SIDs that match from step(2) to get the
total Received packets from a CM.

                     NOTE: Not sure it is possible to get from a CMTS agent
from the Standard MIBs the number of 
                         of packets transmitted to a single docsis 1.0 cable
modem.

       else if 'docsis11(2)' or 'docsis20()' then
                     (2) WALK the docsQosCmtsMacToSrvFlowTable all for the
instances of that contain the
                       same mac address.
                     (3) Then GET the docQosServiceFlowPkts using the
ifIndex and
                      service flow id from step(2). Add this to the total of
received or transmitted for this CM.
                         To determine the direction of the flow use the same
index and query the docsQosServiceFlowDirection.
This seems very complicated for something so simple. This is just a
suggestion of simple way the RF MIB v2 can correct the 
mistakes of the past.  

Contributors - Will Murwin Motorola, Minnie Lu Cisco

17) docsIfCmtsCmStatusTimingOffset - possibly change decription of existing
object or
add new object to reconcile unit differences between 1.1/2.0. Still under
discussion.

Contributors - Victor Hou Juniper, Rich Woundy IPCDN/Comcast, Kirk Friedman
Correlant.

 
************************************
David Raftus
Terayon Canada Ltd
340 Terry Fox Drive, Suite 202
Ottawa Canada  K2K 3A2
 
[email-masked]           
613.592.1052  ext 222
************************************

---

From: Azlina Ahmad <[email-masked]>
Date: Tue, 17 Jun 2003 11:25:05 -0700

Another way of disabling the HSD access is to disabled (down)
the ifAdminStatus of the Ethernet interface on the modem itself.
In this case, the CMTS will not know this status.

But again, this really depends on how customers 
operate/provision/disabled their users :)  If the assumption that
the modem will get reset, then below would work fine.

Thanks,
Azlina

Minnie Lu wrote:
> Hi, Joe,
> 
> Good suggestion.  Maybe in more general, no matter the BPI is enabled or 
> not, a new state for the case that CM is registrationComplete but 
> network access has being disabled by operator/system administrator.
> 
> Thanks!
> Minnie
> 
> At 01:14 PM 6/17/2003 -0400, Joe Godas wrote:
> 
>> "urn:schemas-microsoft-com:office:office" xmlns:w = 
>> "urn:schemas-microsoft-com:office:word">
>> Hi,
>> <I hope I'm not missing something obvious ;>
>>
>> Regarding Item 12 (docsIfCmtsCmStatusValue)and its relation to BPI 
>> state....I am concerned that we haven't captured the case where a 
>> modem has successfully negotiated BPI but it's network access has been 
>> disabled.
>>
>> Implementation example: on a Cisco CMTS a BPI enabled voice product 
>> would look like this:
>> ubr110.cmts.hcvlny#scm | inc pt
>> <snip>
>> MAC Address    IP Address      I/F       MAC         Prim RxPwr  
>> Timing  Num BPI
>>                                          State       Sid  (db)   
>> Offset CPE Enb
>> 0008.0e72.1e30 10.13.18.73     C3/0/U0   online(pt)  6899 0.75   
>> 1946    0   Y
>>
>> This modem is showing as online (with BPI) whether or not it's network 
>> access has been disabled due to customer not paying their bill.
>>
>> Is there a response code in the Mib that reflects this BPI negotiated 
>> (with data disabled) state or do we have to rely on querying the 
>> forwarding state of the actual CM?
>>
>> Thanks,
>> Joe Godas
>> Cablevision
>>
>>
>> ----- Original Message -----
>> From: <mailto:[email-masked]>Raftus, David
>> To: <mailto:[email-masked]>Rich Woundy (Work) 
>> (E-mail) ; <mailto:[email-masked]'>[email-masked]' ; 
>> <mailto:[email-masked]'>[email-masked]' ; 
>> <mailto:[email-masked]'>[email-masked]' ; 
>> <mailto:[email-masked]'>[email-masked]' ; 
>> <mailto:[email-masked]'>[email-masked]' ; 
>> <mailto:[email-masked]'>[email-masked]' ; 
>> <mailto:[email-masked]'>[email-masked]' ; 
>> <mailto:[email-masked]'>[email-masked]' ; 
>> <mailto:[email-masked]'>[email-masked]' ; 
>> <mailto:[email-masked]'>[email-masked]' ; 
>> <mailto:[email-masked]'>[email-masked]' ; 
>> <mailto:[email-masked]'>[email-masked]' ; 
>> <mailto:[email-masked]'>[email-masked]' ; 
>> <mailto:[email-masked]'>[email-masked]' ; 
>> <mailto:[email-masked]'>[email-masked]' ; 
>> <mailto:[email-masked]'>[email-masked]' ; 
>> <mailto:[email-masked]'>[email-masked]'
>> Cc: <mailto:[email-masked]>Docsis 20 Reflector (E-mail) ; 
>> <mailto:[email-masked]>Docsis Oss Reflector (E-mail) ; 
>> <mailto:[email-masked]>Ipcdn List (E-mail) ; 
>> <mailto:[email-masked]>Raftus, David
>> Sent: Tuesday, June 17, 2003 11:36 AM
>> Subject: rf mib draft v6 to draft v7 suggestions
>>
>> Hi everyone,
>>
>> Since RF mib v2 draft 6 was released in March, I have received 
>> publicly or privately 17 requests for updates/changes to appear in 
>> draft v7. The people on the To: list have participated in either 
>> initiating or commenting on the suggestions.
>>
>> Could I ask these people to please verify their suggestions as they 
>> are listed below? This mib update from v6 to v7 is extensive - want to 
>> ensure data is accurate before undertaking. The wider communities are 
>> also welcome to comment.
>>
>> Thanks for your time,
>> Dave
>>
>>
>> Contributors - Rich Woundy IPCDN/Comcast, Minnie Lu Cisco, Steve 
>> Malenfant Com21
>>
>>
>>
>> 2) docsIfCmtsChannelUtUtilization formula - remove line (100 * ((raw 
>> bytes - stuffed bytes) / raw bytes))
>> 4) docsIfCmtsInsertInterval - For the docsIfCmtsInsertInterval object, 
>> there is no such thing as a
>> "broadcast station maintenance" interval for new modems joining the 
>> network.   Station should be
>> changed to initial to make the text read - "The amount of time to 
>> elapse between each broadcast
>> initial maintenance grant.  Broadcast initial maintenance grants are 
>> used to allow new cable modems
>> to join the network.  Zero indicates that a vendor-specific algorithm 
>> is used instead of a fixed time.
>> 5) docsIfCmtsModPreambleType - (Joel) In docsIfCmtsModulationTable, 
>> the docsIfCmtsModPreambleType object has
>> 2 possible values qpsk0(1) and qpsk1(2). It seems like it's the only 
>> object in this table without a
>> Also a note in the DESCRIPTION like "if docsIfCmtsModChannelType is 
>> tdma(1) a value unknown(0) is used for this object"
>> 6) docsIfUpstreamChannelTable clone mechanism - improve descriptive 
>> wording. The spec is vague about the minimum set of parameters
>> that the
>> CMTS must transfer during a clone operation to be DOCSIS 2.0 
>> compliant. Only those starting with docsIfUpChannelScdma or
>> all parameters defining an SCDMA channel, like the channel width? Then 
>> what about the frequency?
>> 9) docsIfCmStatusTable - possibly add new objects for 
>> successful/failed ucc transactions.
>> Hi, Alex,
>> 10) docsIfUpChannelPreEqEnable, docsIfCmStatusEqualizationData - 
>> clarify descriptions.
>> Lucy,
>> To summarize, the object docsIfCmStatusEqualizationData will only 
>> include the "value" from figure 8-23.
>> In other words, the first byte reported in the MIB object will be the 
>> main tap location.  A clarification
>> should also be made to the description of docsIfUpChannelPreEqEnable 
>> to indicate your interpretation (b).
>> Regarding the question about reverse taps, figure 8-23 is a 
>> simplification of figure 6-23 from the 1.1 RFI
>> spec (which includes a format to encode reverse taps).  It seems to 
>> make sense to me to use the format
>> 3. To be consistent with DS equa data, some TLV should be added also 
>> into it. What?
>> We propose to use only value from referenced figure without 
>> type/length to avoid questions in the future. If not,
>> (2) and (3) should be clarified. I guess, that it will be also very 
>> helpful if clarification (b) will be entered into MIB.
>> Best Regards.
>> Lucy
>>
>> Contributors - Eduardo Cardona Cablelabs, Lucy Pollak TI, Minnie Lu 
>> Cisco, David White Arris,
>> Matt Schmitt Arris, Kirk Friedman Correlant, Fred Oko Stargus, Joe 
>> Godas Kar-el, Steve Malenfant Com21
>>
>>
>>
>> Contributors - Will Murwin Motorola, Rich Woundy IPCDN/Comcast, Mike 
>> StJohns Mindspring, Eduardo Cardona Cablelabs
>>
>>
>>
>> DOCSIS 1.1 changes to RFC2670. Now that rfc2670 is being obsoleted, 
>> the rf-mib v2 and the DOCSIS OSS Specs is the place
>> that should clearly state how these counters and other tables interact 
>> in DOCSIS 1.0, DOCSIS 1.1, and DOCSIS 2.0.
>> I would even hope to see a section in the rf-mib v2, "Interoperation 
>> with the version of DOCSIS" like or to replace
>> what the DOCSIS QOS MIB has. This is the place to describe what table 
>> are populated under the docsIfMib when the
>> This way this issue can be re-discussed and whatever conculsion is 
>> reached, can be document in the description of those
>> objects.
>>
>> 15) Change docsIfCmtsServiceTable to count packets for both upstream 
>> and downstream flows.
>> One of the things that has long been an issue with the RF MIB is that 
>> the docsIfCmtsServiceTable only counts
>> 1.0 modems would it also make sense to add downstream packet counts to 
>> this table, too? Many CMTS'es already
>> count this information and store it in a proprietary MIB. It would be 
>> nice to standardize this as a requirement
>> so that NMS such as usage monitoring systems could (a) count on it 
>> existing and (b) find it in a standard location.
>>
>> While writing DOCS-IETF-QOS-MIB version 9, I find myself still 
>> thinking about Minnie suggestion of having
>> docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets count for 
>> DOCSIS 1.1 and 2.0. Even though the QOS
>> (1) If these counters where used to count the DOCSIS 1.1 and 2.0, than 
>> this would the best place in all
>> of the mibs to
>>     get a quick summary of the upstream data received by a particular 
>> modem, no matter the version.
>> (2) At the same time, The rest of the docsIfCmtsCmServiceTable might 
>> not make sense for DOCSIS 1.1 or 2.0
>> However the more I looked around at the different counters that 
>> existed in all of MIB required by DOCSIS,
>> the more I kept looking for an overall counter on the CMTS to count 
>> data packet received and transmitted
>> for a particular CM.
>> While I understand that these counts can be gathered by via numerous 
>> objects on both the CMTS and CM
>> and then just appling simple math. However I want to query only one 
>> agent and just get a quick summary
>> without have to determine which version of DOCSIS the modem is, which 
>> will determine which mibs I look etc.
>> and objects I query.
>>
>> For example if I want query only one agent(i.e. the CMTS) and get the 
>> number of transmitted and received
>> data for each CM, then
>>        (1) GET-NEXT the docsIfCmtsCmStatusRegMode to see what version 
>> of DOCSIS this modem is operting
>>
>>        if 'docsis10(1)' then
>>                      (2) WALK the entire docsIfCmtsServiceTable for 
>> ifIndex and SID that
>>                        have docsIfCmtsServiceNewCmStatusIndex that 
>> matches the index for step (1).
>>
>>                        ifIndex and SIDs that match from step(2) to get 
>> the total Received packets from a CM.
>>
>>                      NOTE: Not sure it is possible to get from a CMTS 
>> agent from the Standard MIBs the number of
>>                          of packets transmitted to a single docsis 1.0 
>> cable modem.
>>
>>                      (2) WALK the docsQosCmtsMacToSrvFlowTable all for 
>> the instances of that contain the
>>                        same mac address.
>>                       service flow id from step(2). Add this to the 
>> total of received or transmitted for this CM.
>>                          To determine the direction of the flow use 
>> the same index and query the docsQosServiceFlowDirection.
>> 17) docsIfCmtsCmStatusTimingOffset - possibly change decription of 
>> existing object or
>> add new object to reconcile unit differences between 1.1/2.0. Still 
>> under discussion.
>>
>> Contributors - Victor Hou Juniper, Rich Woundy IPCDN/Comcast, Kirk 
>> Friedman Correlant.
>>
>>
>>
>>
>>
>>
>>
>>
>>

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: Joe Godas <[email-masked]>
Date: Tue, 17 Jun 2003 14:34:24 -0400

Minnie,
I think you are right, this way we can avoid conflicts associated to a
single table and finding a result code for the different combinations.
We've had to make the uncomfortable change of relying on the CM to tell us
it's data forwarding status due to this and would like to go back to asking
the CMTS about the status for each CM for the obvious reason that the CMTS
is/should be the only thing we trust to identify "state."

Ie (vendor specific example again): Online(d) indicates network access
disabled but querying the "unregistered" table will not show the CMs who are
BPI enabled <with network access turned off> because Online(pt) represents
BPI successful and as such overrides the Online(d) status.

ubr110.cmts.hcvlny#scm unregistered  (this table will not yield BPI enabled,
data disabled modems)

Interface Prim Online      Timing Rec     QoS CPE IP address      MAC
address
          Sid  State       Offset Power
C3/0/U0   295  online(d)    4056   -0.50  8   0   10.10.82.90
0020.40c0.1cb2

Thanks,
-Joe
----- Original Message -----
From: "Minnie Lu" <[email-masked]>
To: "Joe Godas" <[email-masked]>
Cc: "Raftus, David" <[email-masked]>; "Rich Woundy (Work)
(E-mail)" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
"Docsis 20 Reflector (E-mail)" <[email-masked]>; "Docsis Oss
Reflector (E-mail)" <[email-masked]>; "Ipcdn List (E-mail)"
<[email-masked]>; "Raftus, David" <[email-masked]>
Sent: Tuesday, June 17, 2003 1:49 PM
Subject: Re: rf mib draft v6 to draft v7 suggestions

> not, a new state for the case that CM is registrationComplete but network
> access has being disabled by operator/system administrator.
>
> Thanks!
> Minnie
>
> >state....I am concerned that we haven't captured the case where a modem
> >has successfully negotiated BPI but it's network access has been
disabled.
> >
> >Implementation example: on a Cisco CMTS a BPI enabled voice product would
> >look like this:
> >MAC Address    IP Address      I/F       MAC         Prim
> >RxPwr  Timing  Num BPI
> >                                          State       Sid  (db)   Offset
> > CPE Enb
> >0008.0e72.1e30 10.13.18.73     C3/0/U0   online(pt)  6899
> >0.75   1946    0   Y
> >
> >To: <mailto:[email-masked]>Rich Woundy (Work) (E-mail)
;
> ><mailto:[email-masked]'>[email-masked]' ;
> >privately 17 requests for updates/changes to appear in draft v7. The
> >people on the To: list have participated in either initiating or
> >commenting on the suggestions.
> >
> >data is accurate before undertaking. The wider communities are also
> >welcome to comment.
> >
> >Thanks for your time,
> >Dave
> >
> >
Malenfant
> >2) docsIfCmtsChannelUtUtilization formula - remove line (100 * ((raw
bytes
> >- stuffed bytes) / raw bytes))
> >initial maintenance grant.  Broadcast initial maintenance grants are used
> >to allow new cable modems
> >CMTS must transfer during a clone operation to be DOCSIS 2.0 compliant.
> >Only those starting with docsIfUpChannelScdma or
> >9) docsIfCmStatusTable - possibly add new objects for successful/failed
> >ucc transactions.
> >Hi, Alex,
main
> >Regarding the question about reverse taps, figure 8-23 is a
simplification
> >Contributors - Eduardo Cardona Cablelabs, Lucy Pollak TI, Minnie Lu
Cisco,
> >count this information and store it in a proprietary MIB. It would be
nice
> >without have to determine which version of DOCSIS the modem is, which
will
> >                       service flow id from step(2). Add this to the
total
> > of received or transmitted for this CM.
> >                          To determine the direction of the flow use the
> > same index and query the docsQosServiceFlowDirection.

---

From: Minnie Lu <[email-masked]>
Date: Tue, 17 Jun 2003 10:49:22 -0700

Hi, Joe,

Thanks!
Minnie

At 01:14 PM 6/17/2003 -0400, Joe Godas wrote:
>has successfully negotiated BPI but it's network access has been disabled.
>
>To: <mailto:[email-masked]>Rich Woundy (Work) (E-mail) ; 
>2) docsIfCmtsChannelUtUtilization formula - remove line (100 * ((raw bytes 
>                       service flow id from step(2). Add this to the total

---

From: Joe Godas <[email-masked]>
Date: Tue, 17 Jun 2003 13:14:46 -0400

Hi,

Regarding Item 12 (docsIfCmtsCmStatusValue)and its relation to BPI state....I am concerned that we haven't captured the case where a modem has successfully negotiated BPI but it's network access has been disabled. 

Implementation example: on a Cisco CMTS a BPI enabled voice product would look like this:
ubr110.cmts.hcvlny#scm | inc pt
<snip>
MAC Address    IP Address      I/F       MAC         Prim RxPwr  Timing  Num BPI
                                         State       Sid  (db)   Offset  CPE Enb
0008.0e72.1e30 10.13.18.73     C3/0/U0   online(pt)  6899 0.75   1946    0   Y 

This modem is showing as online (with BPI) whether or not it's network access has been disabled due to customer not paying their bill.

Is there a response code in the Mib that reflects this BPI negotiated (with data disabled) state or do we have to rely on querying the forwarding state of the actual CM?

Thanks,
Joe Godas
Cablevision

  ----- Original Message ----- 
  From: Raftus, David 
  To: Rich Woundy (Work) (E-mail) ; [email-masked]' ; [email-masked]' ; [email-masked]' ; [email-masked]' ; [email-masked]' ; [email-masked]' ; [email-masked]' ; [email-masked]' ; [email-masked]' ; [email-masked]' ; [email-masked]' ; [email-masked]' ; [email-masked]' ; [email-masked]' ; [email-masked]' ; [email-masked]' ; [email-masked]' 
  Cc: Docsis 20 Reflector (E-mail) ; Docsis Oss Reflector (E-mail) ; Ipcdn List (E-mail) ; Raftus, David 
  Sent: Tuesday, June 17, 2003 11:36 AM
  Subject: rf mib draft v6 to draft v7 suggestions

  Hi everyone,

  Since RF mib v2 draft 6 was released in March, I have received publicly or privately 17 requests for updates/changes to appear in draft v7. The people on the To: list have participated in either initiating or commenting on the suggestions. 

  Could I ask these people to please verify their suggestions as they are listed below? This mib update from v6 to v7 is extensive - want to ensure data is accurate before undertaking. The wider communities are also welcome to comment.

  Thanks for your time,

  Dave

  Contributors - Rich Woundy IPCDN/Comcast, Minnie Lu Cisco, Steve Malenfant Com21

  2) docsIfCmtsChannelUtUtilization formula - remove line (100 * ((raw bytes - stuffed bytes) / raw bytes))
  since it assumes that MPEG payload consists only DOC MAC payload. As we 
  know, MPEG could consist video payload and NULL packets. Suggest to remove 
  this line since the first 2 lines in the formula are good enough.

  4) docsIfCmtsInsertInterval - For the docsIfCmtsInsertInterval object, there is no such thing as a 
  "broadcast station maintenance" interval for new modems joining the network.   Station should be 
  changed to initial to make the text read - "The amount of time to elapse between each broadcast 
  initial maintenance grant.  Broadcast initial maintenance grants are used to allow new cable modems 
  to join the network.  Zero indicates that a vendor-specific algorithm is used instead of a fixed time.  
  Maximum amount of time permitted by the specification is 2 seconds."

  5) docsIfCmtsModPreambleType - (Joel) In docsIfCmtsModulationTable, the docsIfCmtsModPreambleType object has 
  2 possible values qpsk0(1) and qpsk1(2). It seems like it's the only object in this table without a 
  meaningful default value when this parameter does not make sense. For instance, for a TDMA modulation 
  profile using QAM16, the actual preamble type is indeed not QPSK0 but something else. Does it make sense 
  to have a value of 0 in this case, like docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA profiles?

  (Eduardo) for the benefit of clarifications wouldn't be good to have a enumeration unknown(0) for this 
  object when not a 2.0 burst ?
  Also a note in the DESCRIPTION like "if docsIfCmtsModChannelType is tdma(1) a value unknown(0) is used for this object" 
  I would say unknown(0) rather than unknown(3) since it looks like the possible current implementation may be reporting  
  '0' , and defendable in IETF since RFC 3291 uses '0' for inetAddressType

  6) docsIfUpstreamChannelTable clone mechanism - improve descriptive wording. The spec is vague about the minimum set of parameters 
  that the 
  CMTS must transfer during a clone operation to be DOCSIS 2.0 compliant. Only those starting with docsIfUpChannelScdma or 
  all parameters defining an SCDMA channel, like the channel width? Then what about the frequency? 
  Definitely, this clone mechanism is sophisticated enough that it would deserve a more detailed specification 
  (and testing) and, as a consequence, an ECR.

  8) docsIfCmtsUpChnlCtrUcastGrantedMslots - In Cisco CMTS, we use IUC14 (reserved) and SID (HEX): 1FFF (max. of 

  9) docsIfCmStatusTable - possibly add new objects for successful/failed ucc transactions. 
  Hi, Alex,

  10) docsIfUpChannelPreEqEnable, docsIfCmStatusEqualizationData - clarify descriptions.
  Lucy,
  Sorry for the delay in responding.  I don't have an objection to your proposal, as long as the 
  format of the object is clear.
  To summarize, the object docsIfCmStatusEqualizationData will only include the "value" from figure 8-23.  
  In other words, the first byte reported in the MIB object will be the main tap location.  A clarification 
  should also be made to the description of docsIfUpChannelPreEqEnable to indicate your interpretation (b). 
  Regarding the question about reverse taps, figure 8-23 is a simplification of figure 6-23 from the 1.1 RFI 
  spec (which includes a format to encode reverse taps).  It seems to make sense to me to use the format 
  shown in that figure.  Perhaps this MIB object could be clarified to reference both figures.
  -Greg

  Greg,
  to summarize our objections:
  1. MIB requires equalization data, then type/length is irrelevant.
  2. There are 2 possible types 4 (Transmit Equalization Adjust) or 9 (Transmit Equalization Set), which is 
  irrelevant after convolution.
  3. To be consistent with DS equa data, some TLV should be added also into it. What?
  We propose to use only value from referenced figure without type/length to avoid questions in the future. If not, 
  (2) and (3) should be clarified. I guess, that it will be also very helpful if clarification (b) will be entered into MIB. 
  Best Regards.
  Lucy

  12) docsIfCmtsCmStatusValue - add new defined value registeredBPIInitializing(9),
  deprecate former value operational(8).

  Contributors - Eduardo Cardona Cablelabs, Lucy Pollak TI, Minnie Lu Cisco, David White Arris,
  Matt Schmitt Arris, Kirk Friedman Correlant, Fred Oko Stargus, Joe Godas Kar-el, Steve Malenfant Com21

  13) Adjust compliance statements for objects designated optional. Add separate augmentation table for 
  optional objects in docsIfCmtsUpChannelCounterTable.

  Contributors - Will Murwin Motorola, Rich Woundy IPCDN/Comcast, Mike StJohns Mindspring, Eduardo Cardona Cablelabs

  14) Add section explaining counter interaction between Docsis 1.0/1.1/2.0.
  The QOS MIB tried to handle
  DOCSIS 1.1 changes to RFC2670. Now that rfc2670 is being obsoleted, the rf-mib v2 and the DOCSIS OSS Specs is the place
  that should clearly state how these counters and other tables interact in DOCSIS 1.0, DOCSIS 1.1, and DOCSIS 2.0.
  I would even hope to see a section in the rf-mib v2, "Interoperation with the version of DOCSIS" like or to replace
  what the DOCSIS QOS MIB has. This is the place to describe what table are populated under the docsIfMib when the
  the modems are registering.
  This way this issue can be re-discussed and whatever conculsion is reached, can be document in the description of those
  objects.

  15) Change docsIfCmtsServiceTable to count packets for both upstream and downstream flows. 
  One of the things that has long been an issue with the RF MIB is that the docsIfCmtsServiceTable only counts 
  InOctets and InPackets (i.e. upstream packets only). If the reason for keeping this table is to support DOCSIS 
  1.0 modems would it also make sense to add downstream packet counts to this table, too? Many CMTS'es already 
  count this information and store it in a proprietary MIB. It would be nice to standardize this as a requirement 
  so that NMS such as usage monitoring systems could (a) count on it existing and (b) find it in a standard location.

  16) Add 4 objects to docsIfCmtsCmStatusTable
  While writing DOCS-IETF-QOS-MIB version 9, I find myself still thinking about Minnie suggestion of having  
  docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets count for DOCSIS 1.1 and 2.0. Even though the QOS 
  MIB has pawned off this discussion, I have had some thoughts on the subject.
  (1) If these counters where used to count the DOCSIS 1.1 and 2.0, than this would the best place in all 
  of the mibs to
      get a quick summary of the upstream data received by a particular modem, no matter the version.
  (2) At the same time, The rest of the docsIfCmtsCmServiceTable might not make sense for DOCSIS 1.1 or 2.0
  However the more I looked around at the different counters that existed in all of MIB required by DOCSIS, 
  the more I kept looking for an overall counter on the CMTS to count data packet received and transmitted 
  for a particular CM. 
  I would like to start a discussion on about adding 4 new object to the docsIfCmtsCmStatusTable:
  docsIfCmtsCmStatusInPackets 
  docsIfCmtsCmStatusInOctets
  docsIfCmtsCmStatusOutPackets
  docsIfCmtsCmStatusOutoctets
  While I understand that these counts can be gathered by via numerous objects on both the CMTS and CM 
  and then just appling simple math. However I want to query only one agent and just get a quick summary 
  without have to determine which version of DOCSIS the modem is, which will determine which mibs I look etc.
  and objects I query.

  For example if I want query only one agent(i.e. the CMTS) and get the number of transmitted and received 
  data for each CM, then 
         (1) GET-NEXT the docsIfCmtsCmStatusRegMode to see what version of DOCSIS this modem is operting 

         if 'docsis10(1)' then 
                       (2) WALK the entire docsIfCmtsServiceTable for ifIndex and SID that
                         have docsIfCmtsServiceNewCmStatusIndex that matches the index for step (1).
         
                       (3) Add the all the instances of docsIfCmtsServiceInPacket for the
                         ifIndex and SIDs that match from step(2) to get the total Received packets from a CM.

                       NOTE: Not sure it is possible to get from a CMTS agent from the Standard MIBs the number of 
                           of packets transmitted to a single docsis 1.0 cable modem.

         else if 'docsis11(2)' or 'docsis20()' then
                       (2) WALK the docsQosCmtsMacToSrvFlowTable all for the instances of that contain the
                         same mac address.
                       (3) Then GET the docQosServiceFlowPkts using the ifIndex and
                        service flow id from step(2). Add this to the total of received or transmitted for this CM.
                           To determine the direction of the flow use the same index and query the docsQosServiceFlowDirection.
  This seems very complicated for something so simple. This is just a suggestion of simple way the RF MIB v2 can correct the 
  mistakes of the past.  

  17) docsIfCmtsCmStatusTimingOffset - possibly change decription of existing object or
  add new object to reconcile unit differences between 1.1/2.0. Still under discussion.

  Contributors - Victor Hou Juniper, Rich Woundy IPCDN/Comcast, Kirk Friedman Correlant.

  David Raftus

  Terayon Canada Ltd

  Ottawa Canada  K2K 3A2

  [email-masked]           

  613.592.1052  ext 222