Shahram Esfahani | 4 Dec 17:14 2003

Update to RFC2669 (Resend)

Hi folks,

I never got a response for anyone so I am resending my question/comments.

In light of the recent virus/worm attacks on cable subscribers, has the
IETF considered updating RFC2669 to include rate-limiting?  Many MSOs
combated the network impacts of the virus/worm infections by configuring
ACLs on their CMTS.  However, the traffic characteristics of these
infected users reveled numerous ICMP echo requests being sent upstream --
in the magnitude of hundreds per second.  Having just a few infected users
in a MAC domain can put unnecessary stress on the CMTS to issue grants and
flood the domain with ARP requests.

A better solution to these CMTS-centric ACLs would be to rate-limit this
type of traffic on the cable modem.  Rate-limiting can also be applied to
other traffic besides ICMP.  For example, some MSOs have expressed
concerns about very aggressive IP stacks sending DHCP packets too
quickly causing server strain.

Your thoughts about this?

Thanks and regards,
Shahram
Jean-Francois Mule | 4 Dec 22:47 2003

RE: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels)

Thanks David for your comments. Up to the author/editor (David Raftus/Eduardo) to decide what to do and whether to incorporate in draft 09.
 
Note well:
You all realize that we cannot move the IPCDN DOCSIS MIB drafts along the IETF process if we keep getting more and more *technical* comments, even after the WG last calls and other comment deadlines...
 
Jean-Francois.
 
 
 
 
-----Original Message-----
From: David.White <at> arrisi.com [mailto:David.White <at> arrisi.com]
Sent: Thursday, December 04, 2003 2:21 PM
To: Greg White
Cc: Dan Rice <at> Stargus; DOCSIS OSS Majordomo List; Greg.Gohman <at> arrisi.com; ipcdn <at> ietf.org; Larry.Spaete <at> arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List
Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels)


A few points that I hope are not too late:

docsIfCmtsModControl
It might be acceptable to delay enforcing the same channel type across all IUCs until the modulation profile gets assigned to an upstream. That is, one could freely modify the mod prof channel types as long as the modulation profile is assigned to an upstream. This would remove any requirements on the RowStatus being notInService(2). I'm bringing this up now because I'm looking at the command line implementation of this logic and taking individual IUCs out of service is more cumbersome than just de-assigning the modulation profile from the upstream, especially since the modulation profile will have to be de-assigned or the upstream taken out of service anyways since individual (and probably required IUCs) are being taken out of service, thus preventing proper operation of the upstream channel.

docsIfCmtsModChannelType
It might not be necessary or desirable to force all IUCs within a modulation profile to have the same channel type. I believe I have a clearer understanding of the way the mixed-mode tdmaAndAtdma upstream channel type works. I believe the reason for using such an upstream channel would be to allow both DOCSIS 1.x tdma-only and DOCSIS 2.0 atdma-capable modems of operation on the same upstream. As such, IUCs 1, 3-6, and possibly 2 would need to be eiher tdma or tdmaAndAtdma. Otherwise, tdma-only modems would not be able to operate. Likewise, it would seem that IUCs 9, 10, and possibly 11 would be required and would need to be atdma or tdmaAndAtdma, but following the rules for atdma.

Going further, it seems that IUCs 1-6, when set to tdmaAndAtdma, should follow the rules for tdma. Otherwise, if they follow the atdma rules, then tdmaAndAtdma for IUCs 1-6 is pointless, since tdma-only modems will not be able to operate. Likewise, if IUCs 9-11 are set to tdmaAndAtdma, then they should follow the rules for atdma.

To illustrate, I believe that the following modulation profile sets, one for each channel type, should be allowed:

1) tdma upstream channel
IUC chanType
  1 tdma or tdmaAndAtdma (must follow tdma rules)
  2 tdma or tdmaAndAtdma (must follow tdma rules) - this IUC is optional
  3 tdma or tdmaAndAtdma (must follow tdma rules)
  4 tdma or tdmaAndAtdma (must follow tdma rules)
  5 tdma or tdmaAndAtdma (must follow tdma rules)
  6 tdma or tdmaAndAtdma (must follow tdma rules)
  9 ignored - IUC not used
 10 ignored - IUC not used
 11 ignored - IUC not used

2) atdma upstream channel
IUC chanType
  1 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules)
  2 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules) - this IUC is optional
  3 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules)
  4 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules)
  5 ignored - IUC not used
  6 ignored - IUC not used
  9 atdma or tdmaAndAtdma (must follow atdma rules)
 10 atdma or tdmaAndAtdma (must follow atdma rules)
 11 atdma or tdmaAndAtdma (must follow atdma rules) - this IUC is optional

3) tdmaAndAtdma upstream channel
IUC chanType
  1  tdma or tdmaAndAtdma (must follow  tdma rules)
  2  tdma or tdmaAndAtdma (must follow  tdma rules) - this IUC is optional
  3  tdma or tdmaAndAtdma (must follow  tdma rules)
  4  tdma or tdmaAndAtdma (must follow  tdma rules)
  5  tdma or tdmaAndAtdma (must follow  tdma rules)
  6  tdma or tdmaAndAtdma (must follow  tdma rules)
  9 atdma or tdmaAndAtdma (must follow atdma rules)
 10 atdma or tdmaAndAtdma (must follow atdma rules)
 11 atdma or tdmaAndAtdma (must follow atdma rules) - this IUC is optional

4) scdma upstream channel
IUC chanType
  1 scdma
  2 scdma - this IUC is optional
  3 scdma
  4 scdma
  5 ignored - IUC not used
  6 ignored - IUC not used
  9 scdma
 10 scdma
 11 scdma - this IUC is optional

I have included modulation profile channel type tdmaAndAtdma for completeness' sake only. Note that the same results can be achieved without the tdmaAndAtdma modulation profile channel type, even though an usptream channel type of tdmaAndAtmda is still desirable. Thus, we could reduce the complexity and confusion of the modulation profile table by removing the tdmaAndAtdma modulation profile channel type altogether.  Also note that modulation profile 3 (for the tdmaAndAtdma upstream channel) could be used on a tdma-only upstream channel, assuming the UCD and mapper algorithms on the CMTS ignore IUCs 9-11.

What do you think ?

Thanks,
David White
ARRIS Cadant C4 CMTS
Software Engineer




"Greg White" <g.white <at> cablelabs.com>
Sent by: owner-docsis-oss <at> cablelabs.com

10/10/2003 12:56 PM

       
        To:        "Dan Rice <at> Stargus" <dan <at> stargus.com>, "Minnie Lu" <milu <at> cisco.com>
        cc:        <David.White <at> arrisi.com>, "DOCSIS OSS Majordomo List" <docsis-oss <at> cablelabs.com>, <Greg.Gohman <at> arrisi.com>, <Larry.Spaete <at> arrisi.com>, <ipcdn <at> ietf.org>
        Fax to:        
        Subject:        RE: [ipcdn] RE: Channel Types in RFMIBv2  (was RE: DOCSIS 2.0 : rules for   assigning modulation profiles to upstream channels)



What I had interpreted Minnie's suggestion to be was that ChannelType
consistency was enforced across all modulation profile rows with a
Status of 'active', regardless of whether they were assigned to an
upstream channel or not.  Setting Status to 'notInService' is not
allowed for propfiles assigned to an upstream channel, nor is changing
ChannelType.

So, the operation Minnie suggested only applies to profiles that have
been created and set 'active', but are not assigned to any upstream
channel.

Does that clarify?

-Greg


-----Original Message-----
From: Dan Rice <at> Stargus
Sent: Friday, October 10, 2003 7:59 AM
To: Greg White; Minnie Lu
Cc: David.White <at> arrisi.com; DOCSIS OSS Majordomo List;
Greg.Gohman <at> arrisi.com; Larry.Spaete <at> arrisi.com; ipcdn <at> ietf.org
Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 :
rules for assigning modulation profiles to upstream channels)


Sorry for chiming in 11th hour, but want to make sure I understand
minnie's suggestion for active entries.  I believe the suggestion is
that for active entries you change the row status to not in service.
What would we expect to happen to the upstream currently assigned this
modulation profile while it is notInService?  Would the existing active
assignment continue to be valid for the upstream using it until all IUC
rows became active again with the changes in them?

Also if the changes are to docsIfCmtsModChannelType wouldn't you have to
edit all IUC rows before checking to see if this is valid?  I guess when
you started going in and making each IUC active that would be the point
to check it?  Could you guarantee that all IUCs are committed at the
same time since they would "immediately" be committed to the active
upstream channel entries with pointers to the docsIfCmtsModIndex?

Thanks for the clarifications. - Dan

-----Original Message-----
From: Greg White [mailto:g.white <at> CableLabs.com]
Sent: Wednesday, October 08, 2003 7:20 PM
To: Minnie Lu
Cc: David.White <at> arrisi.com; DOCSIS OSS Majordomo List;
Greg.Gohman <at> arrisi.com; Larry.Spaete <at> arrisi.com; ipcdn <at> ietf.org
Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 :
rules for assigning modulation profiles to upstream channels)

That sounds like a workable alternative.  If no one disagrees, I will
make that change to the proposal.

-Greg


-----Original Message-----
From: Minnie Lu [mailto:milu <at> cisco.com]
Sent: Wednesday, October 08, 2003 3:09 PM
To: Greg White
Cc: Minnie Lu; David.White <at> arrisi.com; DOCSIS OSS Majordomo List;
Greg.Gohman <at> arrisi.com; Larry.Spaete <at> arrisi.com; ipcdn <at> ietf.org
Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for
assigning modulation profiles to upstream channels)


Hi, Greg,

Then how about enforce this rule for "active" entries ? So in the case
you
mentioned, user can change the row status to notInService first or at
the
same time changing the channel type.  When user changed all the entries'

channel type to be the same, use can put the entries in active again.  I

personally think it affects a lot when the channel type is changed, so a

little more steps should be ok.  To me, if there is an error, better
catch
it as earlier as possible.

"All the active entries in a modulation profile (i.e. all active entries

that share a
common docsIfCmtsModIndex) MUST have the same value of
docsIfCmtsModChannelType."

Thanks a lot !
Minnie

At 02:12 PM 10/8/2003 -0600, Greg White wrote:
>Minnie,
>
>I didn't want to prevent a user from changing their mind regarding
>channel type when creating a new modulation profile.  Suppose you
>started out setting channel type to atdma and, after completing a few
>IUCs, realized that you really wanted tdmaAndAtdma.  Rather than make
>you start from scratch (or do a simultaneous set across all IUCs), you
>could just update the channel type on each row.
>
>I understand your view as well.
>
>If there is a consensus to change the text, I am not strongly opposed.
>
>-Greg
>
>-----Original Message-----
>From: Minnie Lu [mailto:milu <at> cisco.com]
>Sent: Wednesday, October 08, 2003 12:48 PM
>To: Greg White
>Cc: David.White <at> arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List;
>Greg.Gohman <at> arrisi.com; Larry.Spaete <at> arrisi.com; ipcdn <at> ietf.org
>Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for
>assigning modulation profiles to upstream channels)
>
>
>Hi, Greg,
>
>   Thanks a lot to you and Eduardo for this proposal !
>
>docsIfCmtsModChannelType :
>    "...
>      In order to be considered a valid modulation profile for
>      assignment to an upstream channel, all entries (IUCs) in
>        the modulation profile must have the same channel type."
>
>    In addition to do the checking at the time the modulation profile
is
>assigned to some upstream, I think that the checking could also be done
>when user create/modify an entry of docsIfCmtsModulationEntry even the
>modulation profile is not assigned to any upstreams.  So the error
could
>be
>caught earlier.   So I would suggest to enhance the description as the
>ECO
>(OSS2-O-03092)
>
>"All the entries in a modulation profile (i.e. all entries that share a
>common docsIfCmtsModIndex) MUST have the same value of
>docsIfCmtsModChannelType."
>
>If I miss anything, please let me know.
>Thanks a lot!
>Minnie
>
>At 04:22 PM 10/7/2003 -0600, Greg White wrote:
> >All,
> >
> >As a final issue to resolve in the RFMIBv2 before draft-08, I would
>like
> >to propose that we complete the clarification of the relationship
>between
> >the ChannelType parameters in modulation profiles and upstream
>channels.
> >
> >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which
> >clarifies part of the relationship by adding requirements to the OSSI
> >spec.  I would like to suggest that we propagate those requirements
to
>the
> >MIB descriptions.
> >
> >Also, I would like to propose that we make docsIfUpChannelType a
>read-only
> >object for active rows in the Upstream Channel Table.  The value
>reported
> >would be taken from the modulation profile pointed to by
> >docsIfUpChannelModulationProfile.
> >
> >Attached is a detailed proposal that Eduardo and I wrote to frame the
>issue.
> >
> >In order not to delay draft-08, we would like to have consensus from
>the
> >community and working group by this Friday, October 10.  Please
review
>the
> >attached proposal and provide comments.
> >
> >Many thanks,
> >Greg
> >-----Original Message-----
> >From: David.White <at> arrisi.com [mailto:David.White <at> arrisi.com]
> >Sent: Monday, August 25, 2003 5:59 PM
> >To: Minnie Lu
> >Cc: DOCSIS OSS Majordomo List; Greg.Gohman <at> arrisi.com; Greg White;
> >Larry.Spaete <at> arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List
> >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to
> >upstream channels
> >
> >Minnie,
> >         I am emphathetic to your concerns. I ran across the same
issue
>
> > while implementing cross-checks for the 2.0 modulation and upstream
>data.
> > I found it made the code far simpler to lead the user down the path
of
>
> > "define the channel type first, then build everything around that"
>kind
> > of configuration model. I am then able to check the settings of the
>other
> > parameters against the channel type. After a modulation profile or
> > upstream channel has already been provisioned, changing just the
>channel
> > type becomes difficult, as many parameters are incompatible with
other
>
> > channel types. I allow it, but don't recommend it.
> >
> >My 2 cents,
> >David
> >
> >
> >
> >
> >
> >Minnie Lu <milu <at> cisco.com>
> >
> >08/25/2003 07:01 PM
> >
> >         To:        "Greg White" <g.white <at> CableLabs.com>
> >         cc:        <David.White <at> arrisi.com>, "Minnie Lu"
> > <milu <at> cisco.com>, <Greg.Gohman <at> arrisi.com>,
<Larry.Spaete <at> arrisi.com>,
>
> > "DOCSIS OSS Majordomo List" <docsis-oss <at> CableLabs.com>, "Owner
DOCSIS
>OSS
> > Majordomo List" <owner-docsis-oss <at> CableLabs.com>
> >         Fax to:
> >         Subject:        RE: DOCSIS 2.0 : rules for assigning
>modulation
> > profiles to   upstream channels
> >
> >
> >
> >
> >
> >Hi, Greg,
> >
> >  Please see my response inline.
> >  Thanks a lot !
> >  Minnie
> >At 02:29 PM 8/25/2003 -0600, Greg White wrote:
> > >The email exchange between Steve and Alberto notwithstanding, I
think
>it
> > >does make sense to enforce that all entries in a modulation profile
>(i.e.
> > >all entries that share a common docsIfCmtsModIndex) have the same
> > >ModChannelType.  Also, based on the exchange here it seems that
there
>is
> > >some support for the additional restriction that UpChannelType and
> > >ModChannelType always match.  With those two restrictions, there
>clearly
> > >is a need for all defined values of ModChannelType.
> > >
> > >Since this has been a point of confusion at least twice now, does
>anyone
> > >have a concern with making these two items part of the
specification?
> > >
> >
> >[milu]: I agree with you.
> >
> > >A further point, how does the CMTS enforce the match between
>UpChannelType
> > >and ModChannelType?  One implementation may automatically change
> > >UpChannelType to match ModChannelType whenever
> > >docsIfUpChannelModulationProfile is set.  Another might reject the
>change
> > >if the two don't already match, and require the use of the
> > >docsIfUpChannelCloneFrom mechanism to change the channel type.  I'd
>argue
> > >that the first implementation makes more sense, and ought to be
made
>a
> > >SHOULD in the spec, but I'd like to hear other views.
> > >
> >
> >[milu]: I think this needs to be thought over carefully.  How about
the
> >case that some modulation profile is used by some upstream channel,
and
> >user change the modulation profile channel type ?  Does it mean that
>the
> >upstream channel type would be changed automatically, too ?  If yes,
I
>am
> >afraid that there might be some user who forget the modulation
profile
>is
> >being used and change the channel type without knowing the upstream
>channel
> >type for some upstream channels are changed at the same time.  The
> >modulation profile channel type and upstream channel type are in two
> >different MIB tables.
> >
> >   Actually, I am always puzzled when the modulation profile is being
>used
> >by some upstream channels, could the modulation profile channel type
be
> >changed ?  Maybe this is a confusing point which needs to be
clarified,
>too.
> >
> >   Thanks a lot for your help !
> >   Minnie
> >
> >
> >
> >
> >
> > >-Greg
> > >-----Original Message-----
> > >From: David.White <at> arrisi.com [mailto:David.White <at> arrisi.com]
> > >Sent: Monday, August 25, 2003 11:07 AM
> > >To: Minnie Lu; Greg.Gohman <at> arrisi.com; Larry.Spaete <at> arrisi.com
> > >Cc: DOCSIS OSS Majordomo List; Greg White; milu <at> cisco.com; Owner
>DOCSIS
> > >OSS Majordomo List
> > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles
to
> > >upstream channels
> > >
> > >Minnie,
> > >         Sounds good to me. This would make verifying the
consistency
>of
> > > the data in the modulation profiles and the upstream channels far
>easier.
> > >So, if I understand correctly, this means that all modulation
profile
> > >entries with the same docsIfCmtsModIndex will have to have the same
> > >docsIfCmtsModChannelType. Otherwise, you would not be able to use
>that
> > >modulation profile set on any upstream channel. So, this modulation
> > >profile set with different docsIfCmtsModChannelTypes from an e-mail
>thread
> > >between Alberto and Steve from almost a year ago would be invalid,
no
>?
> > >The way to patch it up would be to make all of the IUCs
tdmaAndAtdma,
> > >correct ?
> > >
> > >Thanks,
> > >David
> > >
> > >--- end David's e-mail ---
> > >--- start e-mail exchange between Alberto and Steve ---
> > >
> > >Hi Steve
> > >
> > >Sorry for the delay in responding
> > >
> > >Your configuration settings for operation in multiple mode is
correct
>and
> > >will support tdma, tdmaAndAtdma and Atdma.
> > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used
with
>UCD
> > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29
and
>IUCs
> > >5&6 are not used. Your interpretation of the spec in the example
>described
> > >is accurate.
> > >
> > >Alberto Campos
> > >a.campos <at> cablelabs.com
> > >
> > >
> > >
> > >
> > >
> > >-----Original Message-----
> > >From: Steve Malenfant [mailto:smalenfant <at> com21.com]
> > >Sent: Monday, September 30, 2002 9:39 AM
> > >To: 'docsis-20 <at> cablelabs.com'
> > >Subject: Correlation between docsIfUpChannelType and
> > >docsIfCmtsModChannelT ype
> > >
> > >
> > >
> > >We are having some discussion internally here, and would like to
>clarify
> > >things about the modulation profile.
> > >Let's take an example, expecting all parameters are good :
> > >
> > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma.
> > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma.
> > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma.
> > >set IUC 5 docsIfCmtsModChannelType to tdma.
> > >set IUC 6 docsIfCmtsModChannelType to tdma.
> > >set IUC 9 docsIfCmtsModChannelType to Atdma.
> > >set IUC 10 docsIfCmtsModChannelType to Atdma.
> > >
> > >Would this burst profile be good for docsIfUpChannelType tdma,
>tdmaAndAtdma
> > >and Atdma?
> > >
> > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2.
> > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV
5
>inside
> > >UCD type 2.
> > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type
29.
> > >
> > >
> > >
> > >
> > >
> > >Minnie Lu <milu <at> cisco.com>
> > >Sent by: owner-docsis-oss <at> cablelabs.com
> > >
> > >08/21/2003 07:15 PM
> > >
> > >         To:        David.White <at> arrisi.com, "Greg White"
> > > <g.white <at> cablelabs.com>
> > >         cc:        "DOCSIS OSS Majordomo List"
> > > <docsis-oss <at> cablelabs.com>, milu <at> cisco.com
> > >         Fax to:
> > >         Subject:        RE: DOCSIS 2.0 : rules for assigning
>modulation
> > > profiles to  upstream channels
> > >
> > >
> > >
> > >
> > >
> > >Hi, David and Greg,
> > >
> > >  I like Greg's "Perhaps it is simpler just to require that
>ModChannelType
> > >match UpChannelType.".
> > >
> > >  I don't think that "we could just drop tdmaAndAtdma for
> > >ModChannelType".  Please keep in mind that when assigning the
>modulation
> > >profile to some upstream via SNMP docsIfUpChannelModulationProfile,
>it uses
> > >only the docsIfModIndex and only one docsIfModIndex can be assigned
>to some
> > >upstream channel.
> > >
> > >  If I miss anything, please correct me.
> > >  Thanks!
> > >  Minnie
> > >
> > >At 10:53 AM 8/21/2003 -0400, David.White <at> arrisi.com wrote:
> > >
> > > >Greg,
> > > >         IUCs 1, 2, 3, and 4 are used for both tdma and atdma
>channels.
> > > > However, the modulation profiles objects
> > > > docsIfCmtsModByteInterleaverBlockSize and
> > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma
>channels. So,
> > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these
>objects
> > set,
> > > > it assumably could not be used on a tdma-only upstream channel.
>Hence,
> > > > the whole purpose of even having ModChannelType - to verify
>consistency
> > > > within the modulation profile - is weakened. This has the
>unintended
> > side
> > > > effect of requiring any assignment of modulation profiles with
>IUCs
> > 1, 2,
> > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to
see
>if the
> > > > Interleaver parameters have been set before assigning it to a
>tdma-only
> > > > upstream channel. Hence, my gripe with tdmaAndAtdma for
modulation
> > > profiles.
> > > >         I can't think of any need/requirement for tdmaAndAtdma
for
> > > > modulation profiles that could not be met with a pair of tdma
and
>atdma
> > > > modulation profile. In other words, I don't think allowing
>tdmaAndAtdma
> > > > for ModChannelType really buys us anything. I'm thinking we
could
>just
> > > > drop tdmaAndAtdma for ModChannelType (making it a
> > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of
>confusion.
> > > >         For the mixed-mode channels, where UpChannelType is
> > tdmaAndAtdma,
> > > > the modulation profile set could look like so:
> > > >
> > > >IUC  1  tdma
> > > >IUC  2  tdma
> > > >IUC  3  tdma
> > > >IUC  4  tdma
> > > >IUC  5  tdma
> > > >IUC  6  tdma
> > > >IUC  9 atdma
> > > >IUC 10 atdma
> > > >IUC 11 atdma
> > > >
> > > >For tdma-only upstream channels, the modulation profile set could
>be:
> > > >
> > > >IUC 1 tdma
> > > >IUC 2 tdma
> > > >IUC 3 tdma
> > > >IUC 4 tdma
> > > >IUC 5 tdma
> > > >IUC 6 tdma
> > > >
> > > >Likewise, for atdma-only upstream channel, the modulation profile
>set
> > > >could be:
> > > >
> > > >IUC  1 atdma
> > > >IUC  2 atdma
> > > >IUC  3 atdma
> > > >IUC  4 atdma
> > > >IUC  9 atdma
> > > >IUC 10 atdma
> > > >IUC 11 atdma
> > > >
> > > >As far as I know, there is no hard limit on the number of the
>modulation
> > > >profile sets that the CMTS and CM can support. I'm really liking
>your
> > "not
> > > >sure the benefits of flexibility outweigh disadvantages..." line
of
> > > >thinking. tdmaAndAtdma for modulation profiles has my head
>spinning.
> > > >
> > > >Thanks,
> > > >David
> > > >
> > > >
> > > >
> > > >"Greg White" <g.white <at> cablelabs.com>
> > > >Sent by: owner-docsis-oss <at> cablelabs.com
> > > >
> > > >08/20/2003 07:35 PM
> > > >
> > > >         To:        <David.White <at> arrisi.com>, "DOCSIS OSS
Majordomo
>List"
> > > > <docsis-oss <at> cablelabs.com>
> > > >         cc:
> > > >         Fax to:
> > > >         Subject:        RE: DOCSIS 2.0 : rules for assigning
>modulation
> > > > profiles to upstream channels
> > > >
> > > >
> > > >David,
> > > >
> > > >I agree with all of your clearly legal/illegal combinations.
Among
>the
> > > >four that cause you consternation, I would break them done like
>this:
> > > >
> > > >illegal:
> > > >tdma, atdma
> > > >atdma, tdma
> > > >
> > > >potentially legal:
> > > >tdma, tdmaAndAtdma
> > > >atdma, tdmaAndAtdma
> > > >
> > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and
>possibly
> > 11,
> > > >so cannot be used for a tdma channel. Similarly a tdma modulation
>profile
> > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma
>channel.
> > > >
> > > >A tdmaAndAtdma modulation profile will include IUCs
1,3,4,5,6,9,10,
>and
> > > >possibly 11, so could potentially be used for a tdma or an atdma
>channel
> > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS
>ignored the
> > > >IUCs that don't apply to the channel type.  I'm not sure that the
> > > >advantages of that flexibility outweigh the disadvantages of
having
>the
> > > >MIB reporting something that doesn't exactly reflect what is
> > > >configured.  Perhaps it is simpler just to require that
>ModChannelType
> > > >match UpChannelType.
> > > >
> > > >-Greg
> > > >
> > > >
> > > >  ----Original Message-----
> > > >From: David.White <at> arrisi.com [mailto:David.White <at> arrisi.com]
> > > >Sent: Tuesday, August 19, 2003 9:37 AM
> > > >To: DOCSIS OSS Majordomo List
> > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to
>upstream
> > > >channels
> > > >
> > > >
> > > >DOCSIS 2.0 Community,
> > > >        It seems that the DocsisUpstreamType objects in both the
> > > > modulation profile table and the upstream channel table exist,
in
>part,
> > > > to provide the equipment vendor a way to cross-check the data
for
> > > > consistency. Furthermore, it would seem possible to compare the
>two
> > > > DocsisUpstreamType objects when assigning an upstream to a
>modulation
> > > > profile to make sure the assignment is compatible. For instance,
>the
> > > > following combination of docsIfUpChannelType,
>docsIfCmtsModChannelType
> > > > would clearly be illegal:
> > > >
> > > >scdma, tdma
> > > >scdma, atdma
> > > >scdma, tdmaAndAtdma
> > > >
> > > >tdma, scdma
> > > >atdma, scdma
> > > >tdmaAndAtdma, scdma
> > > >
> > > >
> > > >It is also pretty clear the following are legal:
> > > >
> > > >tdma, tdma
> > > >atdma, atdma
> > > >scdma, scdma
> > > >tdmaAndAtdma, tdmaAndAtdma
> > > >
> > > >
> > > >However, it is the following cases that are causing me
>consternation:
> > > >
> > > >tdma, atdma
> > > >tdma, tdmaAndAtdma
> > > >atdma, tdma
> > > >atdma, tdmaAndAtdma
> > > >
> > > >
> > > >If ALL of these are legal, then I do not understand the point of
> > > >tdmaAndAtdma, other than to cause confusion, especially for
>modulation
> > > >profiles.
> > > >
> > > >Thanks,
> > > >David White
> > > >ARRIS Cadant C4 CMTS
> > >
> >
> >
> >


_______________________________________________
IPCDN mailing list
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn




Jean-Francois Mule | 4 Dec 23:11 2003

RFMIBv2 ID-nits: references


Check ID nits and other comments made by mib doctors in other drafts.
   http://www.ietf.org/ID-nits.html

There are normative references that are not even mentioned once and not used as IMPORTs in the document:
   [1] Woundy, R., "Baseline Privacy Interface Management
       Information Base for DOCSIS Compliant Cable Modems
       and Cable Modem Termination Systems", RFC3083, March 2001.
   [9] "Adapted MIB-definitions and a clarification for MPEG-related 
       issues for EuroDOCSIS cable modem systems v1.01", tComLabs, 
       May 2000., available at http://www.tcomlabs.com. 
Suggestions:
  - call this reference in the text or just remove it;
  - I cannot find the named reference under http://www.tcomlabs.com ; if you keep it, then we need a better
link, especially if it remains normative.

Also, should [6] be made informative instead of normative?
(a) it's a book 
(b) the DOCSIS specs are referenced normatively and that's where a normative reference on QPSK should be.
   [6] Proakis, John G., "Digital Communications, 3rd Edition", 
       McGraw-Hill, New York, New York, 1995, ISBN 0-07-051726-6 

Thanks,
Jean-François
PS: also, CableLabs is working on a stable HTTP URL for our specifications so the
http://www.cablemodem.com URL will most likely have to be updated. More on the actual URL soon.
Greg White | 4 Dec 23:26 2003

RE: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels)

David,
 
Thanks for taking the time to detail your thoughts on this.  Here is what I think:
 
docsIfCmtsModControl
Your suggestion is a valid one, matches the original proposal, and is arguably simpler. However, I don't believe that the current method is broken, and it has some benefits.  For one, it allows for consistency checking while the profile is being built, where ModControl would not be allowed to become "Active" if the ChannelType did not match that of other active rows.  This helps limit the amount of debugging the operator needs to go through to find the invalid parameter.  If the consistency check is only done when the profile is assigned to an upstream channel, the operator has to comb through all (potentially 9) rows to find out what parameter(s) are in error.
 
docsIfCmtsModChannelType
I have to admit that this seems like deja vu.  Is this not exactly the same point you raised in your email on Aug 21?  I think the argument then was that it was just simpler conceptually to have modulation profiles created specifically for the channel type, hence all rows in a profile have matching ModChannelType, and ModChannelType has to match UpChannelType.
 
-Greg
 
 
 
 
-----Original Message-----
From: Jean-Francois Mule
Sent: Thursday, December 04, 2003 2:48 PM
To: David.White <at> arrisi.com; Greg White
Cc: Dan Rice <at> Stargus; DOCSIS OSS Majordomo List; Greg.Gohman <at> arrisi.com; ipcdn <at> ietf.org; Larry.Spaete <at> arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List
Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels)

Thanks David for your comments. Up to the author/editor (David Raftus/Eduardo) to decide what to do and whether to incorporate in draft 09.
 
Note well:
You all realize that we cannot move the IPCDN DOCSIS MIB drafts along the IETF process if we keep getting more and more *technical* comments, even after the WG last calls and other comment deadlines...
 
Jean-Francois.
 
 
 
 
-----Original Message-----
From: David.White <at> arrisi.com [mailto:David.White <at> arrisi.com]
Sent: Thursday, December 04, 2003 2:21 PM
To: Greg White
Cc: Dan Rice <at> Stargus; DOCSIS OSS Majordomo List; Greg.Gohman <at> arrisi.com; ipcdn <at> ietf.org; Larry.Spaete <at> arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List
Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels)


A few points that I hope are not too late:

docsIfCmtsModControl
It might be acceptable to delay enforcing the same channel type across all IUCs until the modulation profile gets assigned to an upstream. That is, one could freely modify the mod prof channel types as long as the modulation profile is assigned to an upstream. This would remove any requirements on the RowStatus being notInService(2). I'm bringing this up now because I'm looking at the command line implementation of this logic and taking individual IUCs out of service is more cumbersome than just de-assigning the modulation profile from the upstream, especially since the modulation profile will have to be de-assigned or the upstream taken out of service anyways since individual (and probably required IUCs) are being taken out of service, thus preventing proper operation of the upstream channel.

docsIfCmtsModChannelType
It might not be necessary or desirable to force all IUCs within a modulation profile to have the same channel type. I believe I have a clearer understanding of the way the mixed-mode tdmaAndAtdma upstream channel type works. I believe the reason for using such an upstream channel would be to allow both DOCSIS 1.x tdma-only and DOCSIS 2.0 atdma-capable modems of operation on the same upstream. As such, IUCs 1, 3-6, and possibly 2 would need to be eiher tdma or tdmaAndAtdma. Otherwise, tdma-only modems would not be able to operate. Likewise, it would seem that IUCs 9, 10, and possibly 11 would be required and would need to be atdma or tdmaAndAtdma, but following the rules for atdma.

Going further, it seems that IUCs 1-6, when set to tdmaAndAtdma, should follow the rules for tdma. Otherwise, if they follow the atdma rules, then tdmaAndAtdma for IUCs 1-6 is pointless, since tdma-only modems will not be able to operate. Likewise, if IUCs 9-11 are set to tdmaAndAtdma, then they should follow the rules for atdma.

To illustrate, I believe that the following modulation profile sets, one for each channel type, should be allowed:

1) tdma upstream channel
IUC chanType
  1 tdma or tdmaAndAtdma (must follow tdma rules)
  2 tdma or tdmaAndAtdma (must follow tdma rules) - this IUC is optional
  3 tdma or tdmaAndAtdma (must follow tdma rules)
  4 tdma or tdmaAndAtdma (must follow tdma rules)
  5 tdma or tdmaAndAtdma (must follow tdma rules)
  6 tdma or tdmaAndAtdma (must follow tdma rules)
  9 ignored - IUC not used
 10 ignored - IUC not used
 11 ignored - IUC not used

2) atdma upstream channel
IUC chanType
  1 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules)
  2 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules) - this IUC is optional
  3 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules)
  4 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules)
  5 ignored - IUC not used
  6 ignored - IUC not used
  9 atdma or tdmaAndAtdma (must follow atdma rules)
 10 atdma or tdmaAndAtdma (must follow atdma rules)
 11 atdma or tdmaAndAtdma (must follow atdma rules) - this IUC is optional

3) tdmaAndAtdma upstream channel
IUC chanType
  1  tdma or tdmaAndAtdma (must follow  tdma rules)
  2  tdma or tdmaAndAtdma (must follow  tdma rules) - this IUC is optional
  3  tdma or tdmaAndAtdma (must follow  tdma rules)
  4  tdma or tdmaAndAtdma (must follow  tdma rules)
  5  tdma or tdmaAndAtdma (must follow  tdma rules)
  6  tdma or tdmaAndAtdma (must follow  tdma rules)
  9 atdma or tdmaAndAtdma (must follow atdma rules)
 10 atdma or tdmaAndAtdma (must follow atdma rules)
 11 atdma or tdmaAndAtdma (must follow atdma rules) - this IUC is optional

4) scdma upstream channel
IUC chanType
  1 scdma
  2 scdma - this IUC is optional
  3 scdma
  4 scdma
  5 ignored - IUC not used
  6 ignored - IUC not used
  9 scdma
 10 scdma
 11 scdma - this IUC is optional

I have included modulation profile channel type tdmaAndAtdma for completeness' sake only. Note that the same results can be achieved without the tdmaAndAtdma modulation profile channel type, even though an usptream channel type of tdmaAndAtmda is still desirable. Thus, we could reduce the complexity and confusion of the modulation profile table by removing the tdmaAndAtdma modulation profile channel type altogether.  Also note that modulation profile 3 (for the tdmaAndAtdma upstream channel) could be used on a tdma-only upstream channel, assuming the UCD and mapper algorithms on the CMTS ignore IUCs 9-11.

What do you think ?

Thanks,
David White
ARRIS Cadant C4 CMTS
Software Engineer




"Greg White" <g.white <at> cablelabs.com>
Sent by: owner-docsis-oss <at> cablelabs.com

10/10/2003 12:56 PM

       
        To:        "Dan Rice <at> Stargus" <dan <at> stargus.com>, "Minnie Lu" <milu <at> cisco.com>
        cc:        <David.White <at> arrisi.com>, "DOCSIS OSS Majordomo List" <docsis-oss <at> cablelabs.com>, <Greg.Gohman <at> arrisi.com>, <Larry.Spaete <at> arrisi.com>, <ipcdn <at> ietf.org>
        Fax to:        
        Subject:        RE: [ipcdn] RE: Channel Types in RFMIBv2  (was RE: DOCSIS 2.0 : rules for   assigning modulation profiles to upstream channels)



What I had interpreted Minnie's suggestion to be was that ChannelType
consistency was enforced across all modulation profile rows with a
Status of 'active', regardless of whether they were assigned to an
upstream channel or not.  Setting Status to 'notInService' is not
allowed for propfiles assigned to an upstream channel, nor is changing
ChannelType.

So, the operation Minnie suggested only applies to profiles that have
been created and set 'active', but are not assigned to any upstream
channel.

Does that clarify?

-Greg


-----Original Message-----
From: Dan Rice <at> Stargus
Sent: Friday, October 10, 2003 7:59 AM
To: Greg White; Minnie Lu
Cc: David.White <at> arrisi.com; DOCSIS OSS Majordomo List;
Greg.Gohman <at> arrisi.com; Larry.Spaete <at> arrisi.com; ipcdn <at> ietf.org
Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 :
rules for assigning modulation profiles to upstream channels)


Sorry for chiming in 11th hour, but want to make sure I understand
minnie's suggestion for active entries.  I believe the suggestion is
that for active entries you change the row status to not in service.
What would we expect to happen to the upstream currently assigned this
modulation profile while it is notInService?  Would the existing active
assignment continue to be valid for the upstream using it until all IUC
rows became active again with the changes in them?

Also if the changes are to docsIfCmtsModChannelType wouldn't you have to
edit all IUC rows before checking to see if this is valid?  I guess when
you started going in and making each IUC active that would be the point
to check it?  Could you guarantee that all IUCs are committed at the
same time since they would "immediately" be committed to the active
upstream channel entries with pointers to the docsIfCmtsModIndex?

Thanks for the clarifications. - Dan

-----Original Message-----
From: Greg White [mailto:g.white <at> CableLabs.com]
Sent: Wednesday, October 08, 2003 7:20 PM
To: Minnie Lu
Cc: David.White <at> arrisi.com; DOCSIS OSS Majordomo List;
Greg.Gohman <at> arrisi.com; Larry.Spaete <at> arrisi.com; ipcdn <at> ietf.org
Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 :
rules for assigning modulation profiles to upstream channels)

That sounds like a workable alternative.  If no one disagrees, I will
make that change to the proposal.

-Greg


-----Original Message-----
From: Minnie Lu [mailto:milu <at> cisco.com]
Sent: Wednesday, October 08, 2003 3:09 PM
To: Greg White
Cc: Minnie Lu; David.White <at> arrisi.com; DOCSIS OSS Majordomo List;
Greg.Gohman <at> arrisi.com; Larry.Spaete <at> arrisi.com; ipcdn <at> ietf.org
Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for
assigning modulation profiles to upstream channels)


Hi, Greg,

Then how about enforce this rule for "active" entries ? So in the case
you
mentioned, user can change the row status to notInService first or at
the
same time changing the channel type.  When user changed all the entries'

channel type to be the same, use can put the entries in active again.  I

personally think it affects a lot when the channel type is changed, so a

little more steps should be ok.  To me, if there is an error, better
catch
it as earlier as possible.

"All the active entries in a modulation profile (i.e. all active entries

that share a
common docsIfCmtsModIndex) MUST have the same value of
docsIfCmtsModChannelType."

Thanks a lot !
Minnie

At 02:12 PM 10/8/2003 -0600, Greg White wrote:
>Minnie,
>
>I didn't want to prevent a user from changing their mind regarding
>channel type when creating a new modulation profile.  Suppose you
>started out setting channel type to atdma and, after completing a few
>IUCs, realized that you really wanted tdmaAndAtdma.  Rather than make
>you start from scratch (or do a simultaneous set across all IUCs), you
>could just update the channel type on each row.
>
>I understand your view as well.
>
>If there is a consensus to change the text, I am not strongly opposed.
>
>-Greg
>
>-----Original Message-----
>From: Minnie Lu [mailto:milu <at> cisco.com]
>Sent: Wednesday, October 08, 2003 12:48 PM
>To: Greg White
>Cc: David.White <at> arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List;
>Greg.Gohman <at> arrisi.com; Larry.Spaete <at> arrisi.com; ipcdn <at> ietf.org
>Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for
>assigning modulation profiles to upstream channels)
>
>
>Hi, Greg,
>
>   Thanks a lot to you and Eduardo for this proposal !
>
>docsIfCmtsModChannelType :
>    "...
>      In order to be considered a valid modulation profile for
>      assignment to an upstream channel, all entries (IUCs) in
>        the modulation profile must have the same channel type."
>
>    In addition to do the checking at the time the modulation profile
is
>assigned to some upstream, I think that the checking could also be done
>when user create/modify an entry of docsIfCmtsModulationEntry even the
>modulation profile is not assigned to any upstreams.  So the error
could
>be
>caught earlier.   So I would suggest to enhance the description as the
>ECO
>(OSS2-O-03092)
>
>"All the entries in a modulation profile (i.e. all entries that share a
>common docsIfCmtsModIndex) MUST have the same value of
>docsIfCmtsModChannelType."
>
>If I miss anything, please let me know.
>Thanks a lot!
>Minnie
>
>At 04:22 PM 10/7/2003 -0600, Greg White wrote:
> >All,
> >
> >As a final issue to resolve in the RFMIBv2 before draft-08, I would
>like
> >to propose that we complete the clarification of the relationship
>between
> >the ChannelType parameters in modulation profiles and upstream
>channels.
> >
> >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which
> >clarifies part of the relationship by adding requirements to the OSSI
> >spec.  I would like to suggest that we propagate those requirements
to
>the
> >MIB descriptions.
> >
> >Also, I would like to propose that we make docsIfUpChannelType a
>read-only
> >object for active rows in the Upstream Channel Table.  The value
>reported
> >would be taken from the modulation profile pointed to by
> >docsIfUpChannelModulationProfile.
> >
> >Attached is a detailed proposal that Eduardo and I wrote to frame the
>issue.
> >
> >In order not to delay draft-08, we would like to have consensus from
>the
> >community and working group by this Friday, October 10.  Please
review
>the
> >attached proposal and provide comments.
> >
> >Many thanks,
> >Greg
> >-----Original Message-----
> >From: David.White <at> arrisi.com [mailto:David.White <at> arrisi.com]
> >Sent: Monday, August 25, 2003 5:59 PM
> >To: Minnie Lu
> >Cc: DOCSIS OSS Majordomo List; Greg.Gohman <at> arrisi.com; Greg White;
> >Larry.Spaete <at> arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List
> >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to
> >upstream channels
> >
> >Minnie,
> >         I am emphathetic to your concerns. I ran across the same
issue
>
> > while implementing cross-checks for the 2.0 modulation and upstream
>data.
> > I found it made the code far simpler to lead the user down the path
of
>
> > "define the channel type first, then build everything around that"
>kind
> > of configuration model. I am then able to check the settings of the
>other
> > parameters against the channel type. After a modulation profile or
> > upstream channel has already been provisioned, changing just the
>channel
> > type becomes difficult, as many parameters are incompatible with
other
>
> > channel types. I allow it, but don't recommend it.
> >
> >My 2 cents,
> >David
> >
> >
> >
> >
> >
> >Minnie Lu <milu <at> cisco.com>
> >
> >08/25/2003 07:01 PM
> >
> >         To:        "Greg White" <g.white <at> CableLabs.com>
> >         cc:        <David.White <at> arrisi.com>, "Minnie Lu"
> > <milu <at> cisco.com>, <Greg.Gohman <at> arrisi.com>,
<Larry.Spaete <at> arrisi.com>,
>
> > "DOCSIS OSS Majordomo List" <docsis-oss <at> CableLabs.com>, "Owner
DOCSIS
>OSS
> > Majordomo List" <owner-docsis-oss <at> CableLabs.com>
> >         Fax to:
> >         Subject:        RE: DOCSIS 2.0 : rules for assigning
>modulation
> > profiles to   upstream channels
> >
> >
> >
> >
> >
> >Hi, Greg,
> >
> >  Please see my response inline.
> >  Thanks a lot !
> >  Minnie
> >At 02:29 PM 8/25/2003 -0600, Greg White wrote:
> > >The email exchange between Steve and Alberto notwithstanding, I
think
>it
> > >does make sense to enforce that all entries in a modulation profile
>(i.e.
> > >all entries that share a common docsIfCmtsModIndex) have the same
> > >ModChannelType.  Also, based on the exchange here it seems that
there
>is
> > >some support for the additional restriction that UpChannelType and
> > >ModChannelType always match.  With those two restrictions, there
>clearly
> > >is a need for all defined values of ModChannelType.
> > >
> > >Since this has been a point of confusion at least twice now, does
>anyone
> > >have a concern with making these two items part of the
specification?
> > >
> >
> >[milu]: I agree with you.
> >
> > >A further point, how does the CMTS enforce the match between
>UpChannelType
> > >and ModChannelType?  One implementation may automatically change
> > >UpChannelType to match ModChannelType whenever
> > >docsIfUpChannelModulationProfile is set.  Another might reject the
>change
> > >if the two don't already match, and require the use of the
> > >docsIfUpChannelCloneFrom mechanism to change the channel type.  I'd
>argue
> > >that the first implementation makes more sense, and ought to be
made
>a
> > >SHOULD in the spec, but I'd like to hear other views.
> > >
> >
> >[milu]: I think this needs to be thought over carefully.  How about
the
> >case that some modulation profile is used by some upstream channel,
and
> >user change the modulation profile channel type ?  Does it mean that
>the
> >upstream channel type would be changed automatically, too ?  If yes,
I
>am
> >afraid that there might be some user who forget the modulation
profile
>is
> >being used and change the channel type without knowing the upstream
>channel
> >type for some upstream channels are changed at the same time.  The
> >modulation profile channel type and upstream channel type are in two
> >different MIB tables.
> >
> >   Actually, I am always puzzled when the modulation profile is being
>used
> >by some upstream channels, could the modulation profile channel type
be
> >changed ?  Maybe this is a confusing point which needs to be
clarified,
>too.
> >
> >   Thanks a lot for your help !
> >   Minnie
> >
> >
> >
> >
> >
> > >-Greg
> > >-----Original Message-----
> > >From: David.White <at> arrisi.com [mailto:David.White <at> arrisi.com]
> > >Sent: Monday, August 25, 2003 11:07 AM
> > >To: Minnie Lu; Greg.Gohman <at> arrisi.com; Larry.Spaete <at> arrisi.com
> > >Cc: DOCSIS OSS Majordomo List; Greg White; milu <at> cisco.com; Owner
>DOCSIS
> > >OSS Majordomo List
> > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles
to
> > >upstream channels
> > >
> > >Minnie,
> > >         Sounds good to me. This would make verifying the
consistency
>of
> > > the data in the modulation profiles and the upstream channels far
>easier.
> > >So, if I understand correctly, this means that all modulation
profile
> > >entries with the same docsIfCmtsModIndex will have to have the same
> > >docsIfCmtsModChannelType. Otherwise, you would not be able to use
>that
> > >modulation profile set on any upstream channel. So, this modulation
> > >profile set with different docsIfCmtsModChannelTypes from an e-mail
>thread
> > >between Alberto and Steve from almost a year ago would be invalid,
no
>?
> > >The way to patch it up would be to make all of the IUCs
tdmaAndAtdma,
> > >correct ?
> > >
> > >Thanks,
> > >David
> > >
> > >--- end David's e-mail ---
> > >--- start e-mail exchange between Alberto and Steve ---
> > >
> > >Hi Steve
> > >
> > >Sorry for the delay in responding
> > >
> > >Your configuration settings for operation in multiple mode is
correct
>and
> > >will support tdma, tdmaAndAtdma and Atdma.
> > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used
with
>UCD
> > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29
and
>IUCs
> > >5&6 are not used. Your interpretation of the spec in the example
>described
> > >is accurate.
> > >
> > >Alberto Campos
> > >a.campos <at> cablelabs.com
> > >
> > >
> > >
> > >
> > >
> > >-----Original Message-----
> > >From: Steve Malenfant [mailto:smalenfant <at> com21.com]
> > >Sent: Monday, September 30, 2002 9:39 AM
> > >To: 'docsis-20 <at> cablelabs.com'
> > >Subject: Correlation between docsIfUpChannelType and
> > >docsIfCmtsModChannelT ype
> > >
> > >
> > >
> > >We are having some discussion internally here, and would like to
>clarify
> > >things about the modulation profile.
> > >Let's take an example, expecting all parameters are good :
> > >
> > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma.
> > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma.
> > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma.
> > >set IUC 5 docsIfCmtsModChannelType to tdma.
> > >set IUC 6 docsIfCmtsModChannelType to tdma.
> > >set IUC 9 docsIfCmtsModChannelType to Atdma.
> > >set IUC 10 docsIfCmtsModChannelType to Atdma.
> > >
> > >Would this burst profile be good for docsIfUpChannelType tdma,
>tdmaAndAtdma
> > >and Atdma?
> > >
> > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2.
> > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV
5
>inside
> > >UCD type 2.
> > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type
29.
> > >
> > >
> > >
> > >
> > >
> > >Minnie Lu <milu <at> cisco.com>
> > >Sent by: owner-docsis-oss <at> cablelabs.com
> > >
> > >08/21/2003 07:15 PM
> > >
> > >         To:        David.White <at> arrisi.com, "Greg White"
> > > <g.white <at> cablelabs.com>
> > >         cc:        "DOCSIS OSS Majordomo List"
> > > <docsis-oss <at> cablelabs.com>, milu <at> cisco.com
> > >         Fax to:
> > >         Subject:        RE: DOCSIS 2.0 : rules for assigning
>modulation
> > > profiles to  upstream channels
> > >
> > >
> > >
> > >
> > >
> > >Hi, David and Greg,
> > >
> > >  I like Greg's "Perhaps it is simpler just to require that
>ModChannelType
> > >match UpChannelType.".
> > >
> > >  I don't think that "we could just drop tdmaAndAtdma for
> > >ModChannelType".  Please keep in mind that when assigning the
>modulation
> > >profile to some upstream via SNMP docsIfUpChannelModulationProfile,
>it uses
> > >only the docsIfModIndex and only one docsIfModIndex can be assigned
>to some
> > >upstream channel.
> > >
> > >  If I miss anything, please correct me.
> > >  Thanks!
> > >  Minnie
> > >
> > >At 10:53 AM 8/21/2003 -0400, David.White <at> arrisi.com wrote:
> > >
> > > >Greg,
> > > >         IUCs 1, 2, 3, and 4 are used for both tdma and atdma
>channels.
> > > > However, the modulation profiles objects
> > > > docsIfCmtsModByteInterleaverBlockSize and
> > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma
>channels. So,
> > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these
>objects
> > set,
> > > > it assumably could not be used on a tdma-only upstream channel.
>Hence,
> > > > the whole purpose of even having ModChannelType - to verify
>consistency
> > > > within the modulation profile - is weakened. This has the
>unintended
> > side
> > > > effect of requiring any assignment of modulation profiles with
>IUCs
> > 1, 2,
> > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to
see
>if the
> > > > Interleaver parameters have been set before assigning it to a
>tdma-only
> > > > upstream channel. Hence, my gripe with tdmaAndAtdma for
modulation
> > > profiles.
> > > >         I can't think of any need/requirement for tdmaAndAtdma
for
> > > > modulation profiles that could not be met with a pair of tdma
and
>atdma
> > > > modulation profile. In other words, I don't think allowing
>tdmaAndAtdma
> > > > for ModChannelType really buys us anything. I'm thinking we
could
>just
> > > > drop tdmaAndAtdma for ModChannelType (making it a
> > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of
>confusion.
> > > >         For the mixed-mode channels, where UpChannelType is
> > tdmaAndAtdma,
> > > > the modulation profile set could look like so:
> > > >
> > > >IUC  1  tdma
> > > >IUC  2  tdma
> > > >IUC  3  tdma
> > > >IUC  4  tdma
> > > >IUC  5  tdma
> > > >IUC  6  tdma
> > > >IUC  9 atdma
> > > >IUC 10 atdma
> > > >IUC 11 atdma
> > > >
> > > >For tdma-only upstream channels, the modulation profile set could
>be:
> > > >
> > > >IUC 1 tdma
> > > >IUC 2 tdma
> > > >IUC 3 tdma
> > > >IUC 4 tdma
> > > >IUC 5 tdma
> > > >IUC 6 tdma
> > > >
> > > >Likewise, for atdma-only upstream channel, the modulation profile
>set
> > > >could be:
> > > >
> > > >IUC  1 atdma
> > > >IUC  2 atdma
> > > >IUC  3 atdma
> > > >IUC  4 atdma
> > > >IUC  9 atdma
> > > >IUC 10 atdma
> > > >IUC 11 atdma
> > > >
> > > >As far as I know, there is no hard limit on the number of the
>modulation
> > > >profile sets that the CMTS and CM can support. I'm really liking
>your
> > "not
> > > >sure the benefits of flexibility outweigh disadvantages..." line
of
> > > >thinking. tdmaAndAtdma for modulation profiles has my head
>spinning.
> > > >
> > > >Thanks,
> > > >David
> > > >
> > > >
> > > >
> > > >"Greg White" <g.white <at> cablelabs.com>
> > > >Sent by: owner-docsis-oss <at> cablelabs.com
> > > >
> > > >08/20/2003 07:35 PM
> > > >
> > > >         To:        <David.White <at> arrisi.com>, "DOCSIS OSS
Majordomo
>List"
> > > > <docsis-oss <at> cablelabs.com>
> > > >         cc:
> > > >         Fax to:
> > > >         Subject:        RE: DOCSIS 2.0 : rules for assigning
>modulation
> > > > profiles to upstream channels
> > > >
> > > >
> > > >David,
> > > >
> > > >I agree with all of your clearly legal/illegal combinations.
Among
>the
> > > >four that cause you consternation, I would break them done like
>this:
> > > >
> > > >illegal:
> > > >tdma, atdma
> > > >atdma, tdma
> > > >
> > > >potentially legal:
> > > >tdma, tdmaAndAtdma
> > > >atdma, tdmaAndAtdma
> > > >
> > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and
>possibly
> > 11,
> > > >so cannot be used for a tdma channel. Similarly a tdma modulation
>profile
> > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma
>channel.
> > > >
> > > >A tdmaAndAtdma modulation profile will include IUCs
1,3,4,5,6,9,10,
>and
> > > >possibly 11, so could potentially be used for a tdma or an atdma
>channel
> > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS
>ignored the
> > > >IUCs that don't apply to the channel type.  I'm not sure that the
> > > >advantages of that flexibility outweigh the disadvantages of
having
>the
> > > >MIB reporting something that doesn't exactly reflect what is
> > > >configured.  Perhaps it is simpler just to require that
>ModChannelType
> > > >match UpChannelType.
> > > >
> > > >-Greg
> > > >
> > > >
> > > >  ----Original Message-----
> > > >From: David.White <at> arrisi.com [mailto:David.White <at> arrisi.com]
> > > >Sent: Tuesday, August 19, 2003 9:37 AM
> > > >To: DOCSIS OSS Majordomo List
> > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to
>upstream
> > > >channels
> > > >
> > > >
> > > >DOCSIS 2.0 Community,
> > > >        It seems that the DocsisUpstreamType objects in both the
> > > > modulation profile table and the upstream channel table exist,
in
>part,
> > > > to provide the equipment vendor a way to cross-check the data
for
> > > > consistency. Furthermore, it would seem possible to compare the
>two
> > > > DocsisUpstreamType objects when assigning an upstream to a
>modulation
> > > > profile to make sure the assignment is compatible. For instance,
>the
> > > > following combination of docsIfUpChannelType,
>docsIfCmtsModChannelType
> > > > would clearly be illegal:
> > > >
> > > >scdma, tdma
> > > >scdma, atdma
> > > >scdma, tdmaAndAtdma
> > > >
> > > >tdma, scdma
> > > >atdma, scdma
> > > >tdmaAndAtdma, scdma
> > > >
> > > >
> > > >It is also pretty clear the following are legal:
> > > >
> > > >tdma, tdma
> > > >atdma, atdma
> > > >scdma, scdma
> > > >tdmaAndAtdma, tdmaAndAtdma
> > > >
> > > >
> > > >However, it is the following cases that are causing me
>consternation:
> > > >
> > > >tdma, atdma
> > > >tdma, tdmaAndAtdma
> > > >atdma, tdma
> > > >atdma, tdmaAndAtdma
> > > >
> > > >
> > > >If ALL of these are legal, then I do not understand the point of
> > > >tdmaAndAtdma, other than to cause confusion, especially for
>modulation
> > > >profiles.
> > > >
> > > >Thanks,
> > > >David White
> > > >ARRIS Cadant C4 CMTS
> > >
> >
> >
> >


_______________________________________________
IPCDN mailing list
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn




David.White | 4 Dec 22:21 2003

RE: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for assigning modulation profiles to upstream channels)


A few points that I hope are not too late:

docsIfCmtsModControl
It might be acceptable to delay enforcing the same channel type across all IUCs until the modulation profile gets assigned to an upstream. That is, one could freely modify the mod prof channel types as long as the modulation profile is assigned to an upstream. This would remove any requirements on the RowStatus being notInService(2). I'm bringing this up now because I'm looking at the command line implementation of this logic and taking individual IUCs out of service is more cumbersome than just de-assigning the modulation profile from the upstream, especially since the modulation profile will have to be de-assigned or the upstream taken out of service anyways since individual (and probably required IUCs) are being taken out of service, thus preventing proper operation of the upstream channel.

docsIfCmtsModChannelType
It might not be necessary or desirable to force all IUCs within a modulation profile to have the same channel type. I believe I have a clearer understanding of the way the mixed-mode tdmaAndAtdma upstream channel type works. I believe the reason for using such an upstream channel would be to allow both DOCSIS 1.x tdma-only and DOCSIS 2.0 atdma-capable modems of operation on the same upstream. As such, IUCs 1, 3-6, and possibly 2 would need to be eiher tdma or tdmaAndAtdma. Otherwise, tdma-only modems would not be able to operate. Likewise, it would seem that IUCs 9, 10, and possibly 11 would be required and would need to be atdma or tdmaAndAtdma, but following the rules for atdma.

Going further, it seems that IUCs 1-6, when set to tdmaAndAtdma, should follow the rules for tdma. Otherwise, if they follow the atdma rules, then tdmaAndAtdma for IUCs 1-6 is pointless, since tdma-only modems will not be able to operate. Likewise, if IUCs 9-11 are set to tdmaAndAtdma, then they should follow the rules for atdma.

To illustrate, I believe that the following modulation profile sets, one for each channel type, should be allowed:

1) tdma upstream channel
IUC chanType
  1 tdma or tdmaAndAtdma (must follow tdma rules)
  2 tdma or tdmaAndAtdma (must follow tdma rules) - this IUC is optional
  3 tdma or tdmaAndAtdma (must follow tdma rules)
  4 tdma or tdmaAndAtdma (must follow tdma rules)
  5 tdma or tdmaAndAtdma (must follow tdma rules)
  6 tdma or tdmaAndAtdma (must follow tdma rules)
  9 ignored - IUC not used
 10 ignored - IUC not used
 11 ignored - IUC not used

2) atdma upstream channel
IUC chanType
  1 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules)
  2 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules) - this IUC is optional
  3 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules)
  4 atdma or tdmaAndAtdma (if tdmaAndAtdma, must follow tdma rules)
  5 ignored - IUC not used
  6 ignored - IUC not used
  9 atdma or tdmaAndAtdma (must follow atdma rules)
 10 atdma or tdmaAndAtdma (must follow atdma rules)
 11 atdma or tdmaAndAtdma (must follow atdma rules) - this IUC is optional

3) tdmaAndAtdma upstream channel
IUC chanType
  1  tdma or tdmaAndAtdma (must follow  tdma rules)
  2  tdma or tdmaAndAtdma (must follow  tdma rules) - this IUC is optional
  3  tdma or tdmaAndAtdma (must follow  tdma rules)
  4  tdma or tdmaAndAtdma (must follow  tdma rules)
  5  tdma or tdmaAndAtdma (must follow  tdma rules)
  6  tdma or tdmaAndAtdma (must follow  tdma rules)
  9 atdma or tdmaAndAtdma (must follow atdma rules)
 10 atdma or tdmaAndAtdma (must follow atdma rules)
 11 atdma or tdmaAndAtdma (must follow atdma rules) - this IUC is optional

4) scdma upstream channel
IUC chanType
  1 scdma
  2 scdma - this IUC is optional
  3 scdma
  4 scdma
  5 ignored - IUC not used
  6 ignored - IUC not used
  9 scdma
 10 scdma
 11 scdma - this IUC is optional

I have included modulation profile channel type tdmaAndAtdma for completeness' sake only. Note that the same results can be achieved without the tdmaAndAtdma modulation profile channel type, even though an usptream channel type of tdmaAndAtmda is still desirable. Thus, we could reduce the complexity and confusion of the modulation profile table by removing the tdmaAndAtdma modulation profile channel type altogether.  Also note that modulation profile 3 (for the tdmaAndAtdma upstream channel) could be used on a tdma-only upstream channel, assuming the UCD and mapper algorithms on the CMTS ignore IUCs 9-11.

What do you think ?

Thanks,
David White
ARRIS Cadant C4 CMTS
Software Engineer




"Greg White" <g.white <at> cablelabs.com>
Sent by: owner-docsis-oss <at> cablelabs.com

10/10/2003 12:56 PM

       
        To:        "Dan Rice <at> Stargus" <dan <at> stargus.com>, "Minnie Lu" <milu <at> cisco.com>
        cc:        <David.White <at> arrisi.com>, "DOCSIS OSS Majordomo List" <docsis-oss <at> cablelabs.com>, <Greg.Gohman <at> arrisi.com>, <Larry.Spaete <at> arrisi.com>, <ipcdn <at> ietf.org>
        Fax to:        
        Subject:        RE: [ipcdn] RE: Channel Types in RFMIBv2  (was RE: DOCSIS 2.0 : rules for   assigning modulation profiles to upstream channels)



What I had interpreted Minnie's suggestion to be was that ChannelType
consistency was enforced across all modulation profile rows with a
Status of 'active', regardless of whether they were assigned to an
upstream channel or not.  Setting Status to 'notInService' is not
allowed for propfiles assigned to an upstream channel, nor is changing
ChannelType.

So, the operation Minnie suggested only applies to profiles that have
been created and set 'active', but are not assigned to any upstream
channel.

Does that clarify?

-Greg


-----Original Message-----
From: Dan Rice <at> Stargus
Sent: Friday, October 10, 2003 7:59 AM
To: Greg White; Minnie Lu
Cc: David.White <at> arrisi.com; DOCSIS OSS Majordomo List;
Greg.Gohman <at> arrisi.com; Larry.Spaete <at> arrisi.com; ipcdn <at> ietf.org
Subject: RE: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 :
rules for assigning modulation profiles to upstream channels)


Sorry for chiming in 11th hour, but want to make sure I understand
minnie's suggestion for active entries.  I believe the suggestion is
that for active entries you change the row status to not in service.
What would we expect to happen to the upstream currently assigned this
modulation profile while it is notInService?  Would the existing active
assignment continue to be valid for the upstream using it until all IUC
rows became active again with the changes in them?

Also if the changes are to docsIfCmtsModChannelType wouldn't you have to
edit all IUC rows before checking to see if this is valid?  I guess when
you started going in and making each IUC active that would be the point
to check it?  Could you guarantee that all IUCs are committed at the
same time since they would "immediately" be committed to the active
upstream channel entries with pointers to the docsIfCmtsModIndex?

Thanks for the clarifications. - Dan

-----Original Message-----
From: Greg White [mailto:g.white <at> CableLabs.com]
Sent: Wednesday, October 08, 2003 7:20 PM
To: Minnie Lu
Cc: David.White <at> arrisi.com; DOCSIS OSS Majordomo List;
Greg.Gohman <at> arrisi.com; Larry.Spaete <at> arrisi.com; ipcdn <at> ietf.org
Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 :
rules for assigning modulation profiles to upstream channels)

That sounds like a workable alternative.  If no one disagrees, I will
make that change to the proposal.

-Greg


-----Original Message-----
From: Minnie Lu [mailto:milu <at> cisco.com]
Sent: Wednesday, October 08, 2003 3:09 PM
To: Greg White
Cc: Minnie Lu; David.White <at> arrisi.com; DOCSIS OSS Majordomo List;
Greg.Gohman <at> arrisi.com; Larry.Spaete <at> arrisi.com; ipcdn <at> ietf.org
Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for
assigning modulation profiles to upstream channels)


Hi, Greg,

Then how about enforce this rule for "active" entries ? So in the case
you
mentioned, user can change the row status to notInService first or at
the
same time changing the channel type.  When user changed all the entries'

channel type to be the same, use can put the entries in active again.  I

personally think it affects a lot when the channel type is changed, so a

little more steps should be ok.  To me, if there is an error, better
catch
it as earlier as possible.

"All the active entries in a modulation profile (i.e. all active entries

that share a
common docsIfCmtsModIndex) MUST have the same value of
docsIfCmtsModChannelType."

Thanks a lot !
Minnie

At 02:12 PM 10/8/2003 -0600, Greg White wrote:
>Minnie,
>
>I didn't want to prevent a user from changing their mind regarding
>channel type when creating a new modulation profile.  Suppose you
>started out setting channel type to atdma and, after completing a few
>IUCs, realized that you really wanted tdmaAndAtdma.  Rather than make
>you start from scratch (or do a simultaneous set across all IUCs), you
>could just update the channel type on each row.
>
>I understand your view as well.
>
>If there is a consensus to change the text, I am not strongly opposed.
>
>-Greg
>
>-----Original Message-----
>From: Minnie Lu [mailto:milu <at> cisco.com]
>Sent: Wednesday, October 08, 2003 12:48 PM
>To: Greg White
>Cc: David.White <at> arrisi.com; Minnie Lu; DOCSIS OSS Majordomo List;
>Greg.Gohman <at> arrisi.com; Larry.Spaete <at> arrisi.com; ipcdn <at> ietf.org
>Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for
>assigning modulation profiles to upstream channels)
>
>
>Hi, Greg,
>
>   Thanks a lot to you and Eduardo for this proposal !
>
>docsIfCmtsModChannelType :
>    "...
>      In order to be considered a valid modulation profile for
>      assignment to an upstream channel, all entries (IUCs) in
>        the modulation profile must have the same channel type."
>
>    In addition to do the checking at the time the modulation profile
is
>assigned to some upstream, I think that the checking could also be done
>when user create/modify an entry of docsIfCmtsModulationEntry even the
>modulation profile is not assigned to any upstreams.  So the error
could
>be
>caught earlier.   So I would suggest to enhance the description as the
>ECO
>(OSS2-O-03092)
>
>"All the entries in a modulation profile (i.e. all entries that share a
>common docsIfCmtsModIndex) MUST have the same value of
>docsIfCmtsModChannelType."
>
>If I miss anything, please let me know.
>Thanks a lot!
>Minnie
>
>At 04:22 PM 10/7/2003 -0600, Greg White wrote:
> >All,
> >
> >As a final issue to resolve in the RFMIBv2 before draft-08, I would
>like
> >to propose that we complete the clarification of the relationship
>between
> >the ChannelType parameters in modulation profiles and upstream
>channels.
> >
> >There is currently an ECO (OSS2-O-03092) written by Minnie Lu which
> >clarifies part of the relationship by adding requirements to the OSSI
> >spec.  I would like to suggest that we propagate those requirements
to
>the
> >MIB descriptions.
> >
> >Also, I would like to propose that we make docsIfUpChannelType a
>read-only
> >object for active rows in the Upstream Channel Table.  The value
>reported
> >would be taken from the modulation profile pointed to by
> >docsIfUpChannelModulationProfile.
> >
> >Attached is a detailed proposal that Eduardo and I wrote to frame the
>issue.
> >
> >In order not to delay draft-08, we would like to have consensus from
>the
> >community and working group by this Friday, October 10.  Please
review
>the
> >attached proposal and provide comments.
> >
> >Many thanks,
> >Greg
> >-----Original Message-----
> >From: David.White <at> arrisi.com [mailto:David.White <at> arrisi.com]
> >Sent: Monday, August 25, 2003 5:59 PM
> >To: Minnie Lu
> >Cc: DOCSIS OSS Majordomo List; Greg.Gohman <at> arrisi.com; Greg White;
> >Larry.Spaete <at> arrisi.com; Minnie Lu; Owner DOCSIS OSS Majordomo List
> >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles to
> >upstream channels
> >
> >Minnie,
> >         I am emphathetic to your concerns. I ran across the same
issue
>
> > while implementing cross-checks for the 2.0 modulation and upstream
>data.
> > I found it made the code far simpler to lead the user down the path
of
>
> > "define the channel type first, then build everything around that"
>kind
> > of configuration model. I am then able to check the settings of the
>other
> > parameters against the channel type. After a modulation profile or
> > upstream channel has already been provisioned, changing just the
>channel
> > type becomes difficult, as many parameters are incompatible with
other
>
> > channel types. I allow it, but don't recommend it.
> >
> >My 2 cents,
> >David
> >
> >
> >
> >
> >
> >Minnie Lu <milu <at> cisco.com>
> >
> >08/25/2003 07:01 PM
> >
> >         To:        "Greg White" <g.white <at> CableLabs.com>
> >         cc:        <David.White <at> arrisi.com>, "Minnie Lu"
> > <milu <at> cisco.com>, <Greg.Gohman <at> arrisi.com>,
<Larry.Spaete <at> arrisi.com>,
>
> > "DOCSIS OSS Majordomo List" <docsis-oss <at> CableLabs.com>, "Owner
DOCSIS
>OSS
> > Majordomo List" <owner-docsis-oss <at> CableLabs.com>
> >         Fax to:
> >         Subject:        RE: DOCSIS 2.0 : rules for assigning
>modulation
> > profiles to   upstream channels
> >
> >
> >
> >
> >
> >Hi, Greg,
> >
> >  Please see my response inline.
> >  Thanks a lot !
> >  Minnie
> >At 02:29 PM 8/25/2003 -0600, Greg White wrote:
> > >The email exchange between Steve and Alberto notwithstanding, I
think
>it
> > >does make sense to enforce that all entries in a modulation profile
>(i.e.
> > >all entries that share a common docsIfCmtsModIndex) have the same
> > >ModChannelType.  Also, based on the exchange here it seems that
there
>is
> > >some support for the additional restriction that UpChannelType and
> > >ModChannelType always match.  With those two restrictions, there
>clearly
> > >is a need for all defined values of ModChannelType.
> > >
> > >Since this has been a point of confusion at least twice now, does
>anyone
> > >have a concern with making these two items part of the
specification?
> > >
> >
> >[milu]: I agree with you.
> >
> > >A further point, how does the CMTS enforce the match between
>UpChannelType
> > >and ModChannelType?  One implementation may automatically change
> > >UpChannelType to match ModChannelType whenever
> > >docsIfUpChannelModulationProfile is set.  Another might reject the
>change
> > >if the two don't already match, and require the use of the
> > >docsIfUpChannelCloneFrom mechanism to change the channel type.  I'd
>argue
> > >that the first implementation makes more sense, and ought to be
made
>a
> > >SHOULD in the spec, but I'd like to hear other views.
> > >
> >
> >[milu]: I think this needs to be thought over carefully.  How about
the
> >case that some modulation profile is used by some upstream channel,
and
> >user change the modulation profile channel type ?  Does it mean that
>the
> >upstream channel type would be changed automatically, too ?  If yes,
I
>am
> >afraid that there might be some user who forget the modulation
profile
>is
> >being used and change the channel type without knowing the upstream
>channel
> >type for some upstream channels are changed at the same time.  The
> >modulation profile channel type and upstream channel type are in two
> >different MIB tables.
> >
> >   Actually, I am always puzzled when the modulation profile is being
>used
> >by some upstream channels, could the modulation profile channel type
be
> >changed ?  Maybe this is a confusing point which needs to be
clarified,
>too.
> >
> >   Thanks a lot for your help !
> >   Minnie
> >
> >
> >
> >
> >
> > >-Greg
> > >-----Original Message-----
> > >From: David.White <at> arrisi.com [mailto:David.White <at> arrisi.com]
> > >Sent: Monday, August 25, 2003 11:07 AM
> > >To: Minnie Lu; Greg.Gohman <at> arrisi.com; Larry.Spaete <at> arrisi.com
> > >Cc: DOCSIS OSS Majordomo List; Greg White; milu <at> cisco.com; Owner
>DOCSIS
> > >OSS Majordomo List
> > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles
to
> > >upstream channels
> > >
> > >Minnie,
> > >         Sounds good to me. This would make verifying the
consistency
>of
> > > the data in the modulation profiles and the upstream channels far
>easier.
> > >So, if I understand correctly, this means that all modulation
profile
> > >entries with the same docsIfCmtsModIndex will have to have the same
> > >docsIfCmtsModChannelType. Otherwise, you would not be able to use
>that
> > >modulation profile set on any upstream channel. So, this modulation
> > >profile set with different docsIfCmtsModChannelTypes from an e-mail
>thread
> > >between Alberto and Steve from almost a year ago would be invalid,
no
>?
> > >The way to patch it up would be to make all of the IUCs
tdmaAndAtdma,
> > >correct ?
> > >
> > >Thanks,
> > >David
> > >
> > >--- end David's e-mail ---
> > >--- start e-mail exchange between Alberto and Steve ---
> > >
> > >Hi Steve
> > >
> > >Sorry for the delay in responding
> > >
> > >Your configuration settings for operation in multiple mode is
correct
>and
> > >will support tdma, tdmaAndAtdma and Atdma.
> > >In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used
with
>UCD
> > >type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29
and
>IUCs
> > >5&6 are not used. Your interpretation of the spec in the example
>described
> > >is accurate.
> > >
> > >Alberto Campos
> > >a.campos <at> cablelabs.com
> > >
> > >
> > >
> > >
> > >
> > >-----Original Message-----
> > >From: Steve Malenfant [mailto:smalenfant <at> com21.com]
> > >Sent: Monday, September 30, 2002 9:39 AM
> > >To: 'docsis-20 <at> cablelabs.com'
> > >Subject: Correlation between docsIfUpChannelType and
> > >docsIfCmtsModChannelT ype
> > >
> > >
> > >
> > >We are having some discussion internally here, and would like to
>clarify
> > >things about the modulation profile.
> > >Let's take an example, expecting all parameters are good :
> > >
> > >set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma.
> > >set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma.
> > >set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma.
> > >set IUC 5 docsIfCmtsModChannelType to tdma.
> > >set IUC 6 docsIfCmtsModChannelType to tdma.
> > >set IUC 9 docsIfCmtsModChannelType to Atdma.
> > >set IUC 10 docsIfCmtsModChannelType to Atdma.
> > >
> > >Would this burst profile be good for docsIfUpChannelType tdma,
>tdmaAndAtdma
> > >and Atdma?
> > >
> > >tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2.
> > >mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV
5
>inside
> > >UCD type 2.
> > >Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type
29.
> > >
> > >
> > >
> > >
> > >
> > >Minnie Lu <milu <at> cisco.com>
> > >Sent by: owner-docsis-oss <at> cablelabs.com
> > >
> > >08/21/2003 07:15 PM
> > >
> > >         To:        David.White <at> arrisi.com, "Greg White"
> > > <g.white <at> cablelabs.com>
> > >         cc:        "DOCSIS OSS Majordomo List"
> > > <docsis-oss <at> cablelabs.com>, milu <at> cisco.com
> > >         Fax to:
> > >         Subject:        RE: DOCSIS 2.0 : rules for assigning
>modulation
> > > profiles to  upstream channels
> > >
> > >
> > >
> > >
> > >
> > >Hi, David and Greg,
> > >
> > >  I like Greg's "Perhaps it is simpler just to require that
>ModChannelType
> > >match UpChannelType.".
> > >
> > >  I don't think that "we could just drop tdmaAndAtdma for
> > >ModChannelType".  Please keep in mind that when assigning the
>modulation
> > >profile to some upstream via SNMP docsIfUpChannelModulationProfile,
>it uses
> > >only the docsIfModIndex and only one docsIfModIndex can be assigned
>to some
> > >upstream channel.
> > >
> > >  If I miss anything, please correct me.
> > >  Thanks!
> > >  Minnie
> > >
> > >At 10:53 AM 8/21/2003 -0400, David.White <at> arrisi.com wrote:
> > >
> > > >Greg,
> > > >         IUCs 1, 2, 3, and 4 are used for both tdma and atdma
>channels.
> > > > However, the modulation profiles objects
> > > > docsIfCmtsModByteInterleaverBlockSize and
> > > > docsIfCmtsModByteInterleaverDepth are only valid for atdma
>channels. So,
> > > > if a modulation profile with IUCs 1, 2, 3 and/or 4 had these
>objects
> > set,
> > > > it assumably could not be used on a tdma-only upstream channel.
>Hence,
> > > > the whole purpose of even having ModChannelType - to verify
>consistency
> > > > within the modulation profile - is weakened. This has the
>unintended
> > side
> > > > effect of requiring any assignment of modulation profiles with
>IUCs
> > 1, 2,
> > > > 3, and 4 and ModChannelType equal to tdmaAndAtdma to check to
see
>if the
> > > > Interleaver parameters have been set before assigning it to a
>tdma-only
> > > > upstream channel. Hence, my gripe with tdmaAndAtdma for
modulation
> > > profiles.
> > > >         I can't think of any need/requirement for tdmaAndAtdma
for
> > > > modulation profiles that could not be met with a pair of tdma
and
>atdma
> > > > modulation profile. In other words, I don't think allowing
>tdmaAndAtdma
> > > > for ModChannelType really buys us anything. I'm thinking we
could
>just
> > > > drop tdmaAndAtdma for ModChannelType (making it a
> > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of
>confusion.
> > > >         For the mixed-mode channels, where UpChannelType is
> > tdmaAndAtdma,
> > > > the modulation profile set could look like so:
> > > >
> > > >IUC  1  tdma
> > > >IUC  2  tdma
> > > >IUC  3  tdma
> > > >IUC  4  tdma
> > > >IUC  5  tdma
> > > >IUC  6  tdma
> > > >IUC  9 atdma
> > > >IUC 10 atdma
> > > >IUC 11 atdma
> > > >
> > > >For tdma-only upstream channels, the modulation profile set could
>be:
> > > >
> > > >IUC 1 tdma
> > > >IUC 2 tdma
> > > >IUC 3 tdma
> > > >IUC 4 tdma
> > > >IUC 5 tdma
> > > >IUC 6 tdma
> > > >
> > > >Likewise, for atdma-only upstream channel, the modulation profile
>set
> > > >could be:
> > > >
> > > >IUC  1 atdma
> > > >IUC  2 atdma
> > > >IUC  3 atdma
> > > >IUC  4 atdma
> > > >IUC  9 atdma
> > > >IUC 10 atdma
> > > >IUC 11 atdma
> > > >
> > > >As far as I know, there is no hard limit on the number of the
>modulation
> > > >profile sets that the CMTS and CM can support. I'm really liking
>your
> > "not
> > > >sure the benefits of flexibility outweigh disadvantages..." line
of
> > > >thinking. tdmaAndAtdma for modulation profiles has my head
>spinning.
> > > >
> > > >Thanks,
> > > >David
> > > >
> > > >
> > > >
> > > >"Greg White" <g.white <at> cablelabs.com>
> > > >Sent by: owner-docsis-oss <at> cablelabs.com
> > > >
> > > >08/20/2003 07:35 PM
> > > >
> > > >         To:        <David.White <at> arrisi.com>, "DOCSIS OSS
Majordomo
>List"
> > > > <docsis-oss <at> cablelabs.com>
> > > >         cc:
> > > >         Fax to:
> > > >         Subject:        RE: DOCSIS 2.0 : rules for assigning
>modulation
> > > > profiles to upstream channels
> > > >
> > > >
> > > >David,
> > > >
> > > >I agree with all of your clearly legal/illegal combinations.
Among
>the
> > > >four that cause you consternation, I would break them done like
>this:
> > > >
> > > >illegal:
> > > >tdma, atdma
> > > >atdma, tdma
> > > >
> > > >potentially legal:
> > > >tdma, tdmaAndAtdma
> > > >atdma, tdmaAndAtdma
> > > >
> > > >An atdma modulation profile will include IUCs 1,3,4,9,10, and
>possibly
> > 11,
> > > >so cannot be used for a tdma channel. Similarly a tdma modulation
>profile
> > > >will include IUCs 1,3,4,5,6, so cannot be used for an atdma
>channel.
> > > >
> > > >A tdmaAndAtdma modulation profile will include IUCs
1,3,4,5,6,9,10,
>and
> > > >possibly 11, so could potentially be used for a tdma or an atdma
>channel
> > > >(in addition to a tdmaAndAtdma channel), as long as the CMTS
>ignored the
> > > >IUCs that don't apply to the channel type.  I'm not sure that the
> > > >advantages of that flexibility outweigh the disadvantages of
having
>the
> > > >MIB reporting something that doesn't exactly reflect what is
> > > >configured.  Perhaps it is simpler just to require that
>ModChannelType
> > > >match UpChannelType.
> > > >
> > > >-Greg
> > > >
> > > >
> > > >  ----Original Message-----
> > > >From: David.White <at> arrisi.com [mailto:David.White <at> arrisi.com]
> > > >Sent: Tuesday, August 19, 2003 9:37 AM
> > > >To: DOCSIS OSS Majordomo List
> > > >Subject: DOCSIS 2.0 : rules for assigning modulation profiles to
>upstream
> > > >channels
> > > >
> > > >
> > > >DOCSIS 2.0 Community,
> > > >        It seems that the DocsisUpstreamType objects in both the
> > > > modulation profile table and the upstream channel table exist,
in
>part,
> > > > to provide the equipment vendor a way to cross-check the data
for
> > > > consistency. Furthermore, it would seem possible to compare the
>two
> > > > DocsisUpstreamType objects when assigning an upstream to a
>modulation
> > > > profile to make sure the assignment is compatible. For instance,
>the
> > > > following combination of docsIfUpChannelType,
>docsIfCmtsModChannelType
> > > > would clearly be illegal:
> > > >
> > > >scdma, tdma
> > > >scdma, atdma
> > > >scdma, tdmaAndAtdma
> > > >
> > > >tdma, scdma
> > > >atdma, scdma
> > > >tdmaAndAtdma, scdma
> > > >
> > > >
> > > >It is also pretty clear the following are legal:
> > > >
> > > >tdma, tdma
> > > >atdma, atdma
> > > >scdma, scdma
> > > >tdmaAndAtdma, tdmaAndAtdma
> > > >
> > > >
> > > >However, it is the following cases that are causing me
>consternation:
> > > >
> > > >tdma, atdma
> > > >tdma, tdmaAndAtdma
> > > >atdma, tdma
> > > >atdma, tdmaAndAtdma
> > > >
> > > >
> > > >If ALL of these are legal, then I do not understand the point of
> > > >tdmaAndAtdma, other than to cause confusion, especially for
>modulation
> > > >profiles.
> > > >
> > > >Thanks,
> > > >David White
> > > >ARRIS Cadant C4 CMTS
> > >
> >
> >
> >


_______________________________________________
IPCDN mailing list
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn




Matthew Schmitt | 4 Dec 23:40 2003

RE: RFMIBv2 ID-nits: references

FYI, I did manage to locate the referenced document on www.tcomlabs.com.  The direct link is
http://www.tcomlabs.com/Euro-DOCSIS/Documents/Add-Euro-DOCSIS_spec.pdf.  Via their website,
you can get to the file by first clicking on the Euro-DOCSIS link, then clicking on the Euro-DOCSIS 1.0 link
(the link to that page is www.tcomlabs.com/Euro-DOCSIS/Euro-DOCSIS1.0.htm).  On that page, it's the
document listed as "Additional document: .pdf".

Matt

-----Original Message-----
From: Jean-Francois Mule 
Sent: Thursday, December 04, 2003 3:12 PM
To: david.raftus <at> Terayon.com; Eduardo Cardona; deketelaere <at> tComLabs.com
Cc: ipcdn <at> ietf.org
Subject: [ipcdn] RFMIBv2 ID-nits: references

Check ID nits and other comments made by mib doctors in other drafts.
   http://www.ietf.org/ID-nits.html

There are normative references that are not even mentioned once and not used as IMPORTs in the document:
   [1] Woundy, R., "Baseline Privacy Interface Management
       Information Base for DOCSIS Compliant Cable Modems
       and Cable Modem Termination Systems", RFC3083, March 2001.
   [9] "Adapted MIB-definitions and a clarification for MPEG-related 
       issues for EuroDOCSIS cable modem systems v1.01", tComLabs, 
       May 2000., available at http://www.tcomlabs.com. 
Suggestions:
  - call this reference in the text or just remove it;
  - I cannot find the named reference under http://www.tcomlabs.com ; if you keep it, then we need a better
link, especially if it remains normative.

Also, should [6] be made informative instead of normative?
(a) it's a book 
(b) the DOCSIS specs are referenced normatively and that's where a normative reference on QPSK should be.
   [6] Proakis, John G., "Digital Communications, 3rd Edition", 
       McGraw-Hill, New York, New York, 1995, ISBN 0-07-051726-6 

Thanks,
Jean-François
PS: also, CableLabs is working on a stable HTTP URL for our specifications so the
http://www.cablemodem.com URL will most likely have to be updated. More on the actual URL soon.

_______________________________________________
IPCDN mailing list
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn
Jean-Francois Mule | 5 Dec 00:49 2003

RE: RFMIBv2 ID-nits: references

Ok thanks Matt.

But now that I read the tComLabs document, I still have a pb with keeping this reference (and by now, I have
found it in the text in the REFERENCE clause of some objects).

When you look at the document, it overwrites mib definitions for rfc2670.docsIfDownChannelInterleave
and rfc2670.docsIfDownChannelAnnex (2 object defs from the old RFC 2670). The object definitions
contained in RF MIB v2 draft 08 are correct.

=> so what we need in the RF MIB v2 is actually a normative reference to the Euro-DOCSIS specification that
mandates the interleaving formats or ITU-T J83.

Comments?

Jean-François 

> -----Original Message-----
> From: Matthew Schmitt 
> Sent: Thursday, December 04, 2003 3:40 PM
> To: Jean-Francois Mule; david.raftus <at> Terayon.com; Eduardo 
> Cardona; deketelaere <at> tComLabs.com
> Cc: ipcdn <at> ietf.org
> Subject: RE: [ipcdn] RFMIBv2 ID-nits: references
> 
> 
> FYI, I did manage to locate the referenced document on 
> www.tcomlabs.com.  The direct link is 
> http://www.tcomlabs.com/Euro-DOCSIS/Documents/Add-Euro-DOCSIS_
> spec.pdf.  Via their website, you can get to the file by 
> first clicking on the Euro-DOCSIS link, then clicking on the 
> Euro-DOCSIS 1.0 link (the link to that page is 
> www.tcomlabs.com/Euro-DOCSIS/Euro-DOCSIS1.0.htm).  On that 
> page, it's the document listed as "Additional document: .pdf".
> 
> Matt
> 
> -----Original Message-----
> From: Jean-Francois Mule 
> Sent: Thursday, December 04, 2003 3:12 PM
> To: david.raftus <at> Terayon.com; Eduardo Cardona; 
> deketelaere <at> tComLabs.com
> Cc: ipcdn <at> ietf.org
> Subject: [ipcdn] RFMIBv2 ID-nits: references
> 
> 
> 
> Check ID nits and other comments made by mib doctors in other drafts.
>    http://www.ietf.org/ID-nits.html
> 
> There are normative references that are not even mentioned 
> once and not used as IMPORTs in the document:
>    [1] Woundy, R., "Baseline Privacy Interface Management
>        Information Base for DOCSIS Compliant Cable Modems
>        and Cable Modem Termination Systems", RFC3083, March 2001.
>    [9] "Adapted MIB-definitions and a clarification for MPEG-related 
>        issues for EuroDOCSIS cable modem systems v1.01", tComLabs, 
>        May 2000., available at http://www.tcomlabs.com. 
> Suggestions:
>   - call this reference in the text or just remove it;
>   - I cannot find the named reference under 
> http://www.tcomlabs.com ; if you keep it, then > we need a 
> better link, especially if it remains normative.
> 
> 
> Also, should [6] be made informative instead of normative?
> (a) it's a book 
> (b) the DOCSIS specs are referenced normatively and that's 
> where a normative reference on QPSK should be.
>    [6] Proakis, John G., "Digital Communications, 3rd Edition", 
>        McGraw-Hill, New York, New York, 1995, ISBN 0-07-051726-6 
> 
> Thanks,
> Jean-François
> PS: also, CableLabs is working on a stable HTTP URL for our 
> specifications so the http://www.cablemodem.com URL will most 
> likely have to be updated. More on the actual URL soon.
> 
> 
> _______________________________________________
> IPCDN mailing list
> IPCDN <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 
Wim De Ketelaere | 5 Dec 08:12 2003

Re: RFMIBv2 ID-nits: references

Hi all,

I have no problem removing the MIBs from the document on our website if the
final Euro-DOCSIS specifics
are present in the MIB-RFC !

I believe you can reference to appendix N (1.0/1.1) and F (2.0), or just
reference to the "European Specific Implementation"
(cfr. language used in beginning 1.1 RFI-specification).

Just let me know !

Thanks,
  Best regards,
    Wim

----- Original Message -----
From: "Jean-Francois Mule" <jf.mule <at> cablelabs.com>
To: "Matthew Schmitt" <m.schmitt <at> cablelabs.com>; <david.raftus <at> Terayon.com>;
"Eduardo Cardona" <e.cardona <at> cablelabs.com>; <deketelaere <at> tComLabs.com>
Cc: <ipcdn <at> ietf.org>
Sent: Friday, December 05, 2003 12:49 AM
Subject: RE: [ipcdn] RFMIBv2 ID-nits: references

Ok thanks Matt.

But now that I read the tComLabs document, I still have a pb with keeping
this reference (and by now, I have found it in the text in the REFERENCE
clause of some objects).

When you look at the document, it overwrites mib definitions for
rfc2670.docsIfDownChannelInterleave and rfc2670.docsIfDownChannelAnnex (2
object defs from the old RFC 2670). The object definitions contained in RF
MIB v2 draft 08 are correct.

=> so what we need in the RF MIB v2 is actually a normative reference to the
Euro-DOCSIS specification that mandates the interleaving formats or ITU-T
J83.

Comments?

Jean-François

> -----Original Message-----
> From: Matthew Schmitt
> Sent: Thursday, December 04, 2003 3:40 PM
> To: Jean-Francois Mule; david.raftus <at> Terayon.com; Eduardo
> Cardona; deketelaere <at> tComLabs.com
> Cc: ipcdn <at> ietf.org
> Subject: RE: [ipcdn] RFMIBv2 ID-nits: references
>
>
> FYI, I did manage to locate the referenced document on
> www.tcomlabs.com.  The direct link is
> http://www.tcomlabs.com/Euro-DOCSIS/Documents/Add-Euro-DOCSIS_
> spec.pdf.  Via their website, you can get to the file by
> first clicking on the Euro-DOCSIS link, then clicking on the
> Euro-DOCSIS 1.0 link (the link to that page is
> www.tcomlabs.com/Euro-DOCSIS/Euro-DOCSIS1.0.htm).  On that
> page, it's the document listed as "Additional document: .pdf".
>
> Matt
>
> -----Original Message-----
> From: Jean-Francois Mule
> Sent: Thursday, December 04, 2003 3:12 PM
> To: david.raftus <at> Terayon.com; Eduardo Cardona;
> deketelaere <at> tComLabs.com
> Cc: ipcdn <at> ietf.org
> Subject: [ipcdn] RFMIBv2 ID-nits: references
>
>
>
> Check ID nits and other comments made by mib doctors in other drafts.
>    http://www.ietf.org/ID-nits.html
>
> There are normative references that are not even mentioned
> once and not used as IMPORTs in the document:
>    [1] Woundy, R., "Baseline Privacy Interface Management
>        Information Base for DOCSIS Compliant Cable Modems
>        and Cable Modem Termination Systems", RFC3083, March 2001.
>    [9] "Adapted MIB-definitions and a clarification for MPEG-related
>        issues for EuroDOCSIS cable modem systems v1.01", tComLabs,
>        May 2000., available at http://www.tcomlabs.com.
> Suggestions:
>   - call this reference in the text or just remove it;
>   - I cannot find the named reference under
> http://www.tcomlabs.com ; if you keep it, then > we need a
> better link, especially if it remains normative.
>
>
> Also, should [6] be made informative instead of normative?
> (a) it's a book
> (b) the DOCSIS specs are referenced normatively and that's
> where a normative reference on QPSK should be.
>    [6] Proakis, John G., "Digital Communications, 3rd Edition",
>        McGraw-Hill, New York, New York, 1995, ISBN 0-07-051726-6
>
> Thanks,
> Jean-François
> PS: also, CableLabs is working on a stable HTTP URL for our
> specifications so the http://www.cablemodem.com URL will most
> likely have to be updated. More on the actual URL soon.
>
>
> _______________________________________________
> IPCDN mailing list
> IPCDN <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ipcdn
>
Eduardo Cardona | 5 Dec 18:50 2003

RE: RFMIBv2 ID-nits: references

Hi all, 
I am agree with Wim, 

Moreover, the current pre-draft 9 ( not available publicly yet) includes "EuroDOCSIS" in the glossary and
references Annex F of DOCSIS 2.0 RFI spec. (back as originally in RFIv2 MIB early drafts 00 and 01). 

The reference [9] was before (since draft 02 which rferences DOCSIS 2.0 RFI W04 to hold the requirement of
docsIfDownChannelInterleave and docsIfDownChannelAnnex, 
At that time Annex F did not have those requirements.

As Wim said, with pretty much all EuroDocsis requirements in RFI spec, the EuroDOCSIS keyword would be
enough to refer to the European requirements.

Following all your suggestions would remove reference [9]  and put to the ipcdn consideration 

- Redefines docsIfDownChannelInterleave  definition as :

Original (draft 02-08):
docsIfDownChannelInterleave OBJECT-TYPE
        SYNTAX      INTEGER {
            unknown(1),
            other(2),
            taps8Increment16(3),
            taps16Increment8(4),
            taps32Increment4(5),
            taps64Increment2(6),
            taps128Increment1(7),
            taps12increment17(8)
        }
        MAX-ACCESS  read-write
        STATUS      current
        DESCRIPTION
            "The Forward Error Correction (FEC) interleaving used
             for this downstream channel.
             Values are defined as follows:
             taps8Increment16(3):   protection 5.9/4.1 usec,
                                    latency .22/.15 msec
             taps16Increment8(4):   protection 12/8.2 usec,
                                    latency .48/.33 msec
             taps32Increment4(5):   protection 24/16 usec,
                                    latency .98/.68 msec
             taps64Increment2(6):   protection 47/33 usec,
                                    latency 2/1.4 msec
             taps128Increment1(7):  protection 95/66 usec,
                                    latency 4/2.8 msec
             taps12increment17(8):  protection 18/14 usec,
                                    latency 0.43/0.32 msec
                                    taps12increment17 is implemented in
                                    conformance with EuroDOCSIS
                                    document 'Adapted MIB-definitions -
                                    and a clarification for
                                    MPEG-related issues - for
                                    EuroDOCSIS cable modem systems' by
                                    tComLabs and should only be used
                                    for a EuroDOCSIS MAC interface.

             If the interface is down, this object either returns
             the configured value (CMTS), the most current value (CM),
             or the value of unknown(1).
             The value of other(2) is returned if the interleave
             is known but not defined in the above list.
             See the associated conformance object for write
             conditions and limitations. See the reference for the FEC
             configuration described by the setting of this object."
        REFERENCE
            "Data-Over-Cable Service Interface Specifications: Radio
             Frequency Interface Specification SP-RFIv2.0-I04-030730,
             Table 6-13."
        ::= { docsIfDownstreamChannelEntry 5 } 

Proposed for draft 09
docsIfDownChannelInterleave OBJECT-TYPE
        SYNTAX      INTEGER {
            unknown(1),
            other(2),
            taps8Increment16(3),
            taps16Increment8(4),
            taps32Increment4(5),
            taps64Increment2(6),
            taps128Increment1(7),
            taps12increment17(8)
        }
        MAX-ACCESS  read-write
        STATUS      current
        DESCRIPTION
            "The Forward Error Correction (FEC) interleaving used
             for this downstream channel.
             Values are defined as follows:
             taps8Increment16(3):   protection 5.9/4.1 usec,
                                    latency .22/.15 msec
             taps16Increment8(4):   protection 12/8.2 usec,
                                    latency .48/.33 msec
             taps32Increment4(5):   protection 24/16 usec,
                                    latency .98/.68 msec
             taps64Increment2(6):   protection 47/33 usec,
                                    latency 2/1.4 msec
             taps128Increment1(7):  protection 95/66 usec,
                                    latency 4/2.8 msec
             taps12increment17(8):  protection 18/14 usec,
                                    latency 0.43/0.32 msec

             The value 'taps12increment17' is supported by EuroDOCSIS
             cable systems only and the others by DOCSIS cable systems.

             If the interface is down, this object either returns
             the configured value (CMTS), the most current value (CM),
             or the value of unknown(1).
             The value of other(2) is returned if the interleave
             is known but not defined in the above list.
             See the associated conformance object for write
             conditions and limitations. See the reference for the FEC
             configuration described by the setting of this object."
        REFERENCE
            "Data-Over-Cable Service Interface Specifications: Radio
             Frequency Interface Specification SP-RFIv2.0-I04-030730,
             Table 6-15."
        ::= { docsIfDownstreamChannelEntry 5 } 

Note in the coming draft 09 references will be updated to the current RFIv2.0 I04 spec 
e.g 6-13 in previous drafts is now 6-15.

In this particular case the Annex F table F-11 is the equivalent to table 6-15 but in the references I am
inclined to leave only the DOCSIS references.  The RFI spec is clear in how to implement euroDOCSIS based on
the DOCSIS spec and Annex F "overrides".

For docsIfDownChannelAnnex, I got input from greg White and the propose text would be :
Plass adding normative references to ITU-J83 and EN 300 429

OLD:
docsIfDownChannelAnnex OBJECT-TYPE
        SYNTAX      INTEGER {
            unknown(1),
            other(2),
            annexA(3),
            annexB(4),
            annexC(5)
        }
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The value of this object indicates the conformance of
             the implementation to important regional cable standards.
             annexA : Annex A from ITU-J83 is used, 
             annexB : Annex B from ITU-J83 is used.
             annexC : Annex C from ITU-J83 is used. 
             AnnexB is used for DOCSIS implementations"
        REFERENCE
            "Document Adapted MIB-definitions and a clarification for
             MPEG-related issues for EuroDOCSIS cable modem systems
             v1.01, tComLabs, May 2000, Section 2.2"
        ::= { docsIfDownstreamChannelEntry 7 }

NEW:

docsIfDownChannelAnnex OBJECT-TYPE
        SYNTAX      INTEGER {
            unknown(1),
            other(2),
            annexA(3),
            annexB(4),
            annexC(5)
        }
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The value of this object indicates the conformance of
             the implementation to important regional cable standards.
             annexA : Annex A from ITU-J83 is used.
                      equivalent to EN 300 429
             annexB : Annex B from ITU-J83 is used.
             annexC : Annex C from ITU-J83 is used." 
        REFERENCE
            "Data-Over-Cable Service Interface Specifications: Radio
             Frequency Interface Specification SP-RFIv2.0-I04-030730,
             Sections 6.3.1, H.3.1."
        ::= { docsIfDownstreamChannelEntry 7 }

New References:

[EN 300 429] ETSI Standard EN 300 429, Version 1.2.1: Digital Video Broadcasting (DVB),
Framing structure, channel coding and modulation for cable systems, April 1998.

[ITU-T J.83] ITU-T Recommendation J.83 (4/97), Digital multi-programme systems for
television sound and data services for cable distribution.

Let me know any comments

Eduardo

Below are the section texts for convenience:

------------
H.3.1 Downstream Data
The Downstream Data Interface carries data from the MAC to the PHY for transmission on the Downstream. All
signals on the interface are synchronous with respect to a clock driven by the PHY and received by the MAC.
Four bits of data are transferred on each clock. The frequency of this clock is proportional to the
Downstream bit
rate. Its precise frequency is a function of the Downstream Symbol Rate, the modulation type (64QAM or
256QAM), and the physical layer framing in use (ITU-T Recommendations J.83 Annex A or ITU-T
Recommendations J.83 Annex B).

--------------
6.3.1 Downstream Protocol
The downstream PMD sublayer MUST conform to ITU-T Recommendations J.83, Annex B for Low-Delay
Video Applications [ITU-T J.83-B], with the exceptions called out in Section 6.3.2.

Note: Any reference in this document to the transmission of television in the forward channel that is not
consistent with [EN 300 429] is outside the normative scope as only [EN 300 429] is used for digital
multi-program TV distribution by cable in European applications. See Section 1 (1.1 Scope).

---------------
F.6.3.1 Downstream protocol
The downstream PMD sublayer MUST conform to [EN 300 429].

-----Original Message-----
From: Wim De Ketelaere [mailto:deketelaere <at> tcomlabs.com] 
Sent: Friday, December 05, 2003 12:12 AM
To: Jean-Francois Mule; Matthew Schmitt; david.raftus <at> Terayon.com; Eduardo Cardona
Cc: ipcdn <at> ietf.org
Subject: Re: [ipcdn] RFMIBv2 ID-nits: references

Hi all,

I have no problem removing the MIBs from the document on our website if the final Euro-DOCSIS specifics are
present in the MIB-RFC !

I believe you can reference to appendix N (1.0/1.1) and F (2.0), or just reference to the "European Specific
Implementation" (cfr. language used in beginning 1.1 RFI-specification).

Just let me know !

Thanks,
  Best regards,
    Wim

----- Original Message -----
From: "Jean-Francois Mule" <jf.mule <at> cablelabs.com>
To: "Matthew Schmitt" <m.schmitt <at> cablelabs.com>; <david.raftus <at> Terayon.com>; "Eduardo Cardona"
<e.cardona <at> cablelabs.com>; <deketelaere <at> tComLabs.com>
Cc: <ipcdn <at> ietf.org>
Sent: Friday, December 05, 2003 12:49 AM
Subject: RE: [ipcdn] RFMIBv2 ID-nits: references

Ok thanks Matt.

But now that I read the tComLabs document, I still have a pb with keeping this reference (and by now, I have
found it in the text in the REFERENCE clause of some objects).

When you look at the document, it overwrites mib definitions for rfc2670.docsIfDownChannelInterleave
and rfc2670.docsIfDownChannelAnnex (2 object defs from the old RFC 2670). The object definitions
contained in RF MIB v2 draft 08 are correct.

=> so what we need in the RF MIB v2 is actually a normative reference to the Euro-DOCSIS specification that
mandates the interleaving formats or ITU-T J83.

Comments?

Jean-François

> -----Original Message-----
> From: Matthew Schmitt
> Sent: Thursday, December 04, 2003 3:40 PM
> To: Jean-Francois Mule; david.raftus <at> Terayon.com; Eduardo Cardona; 
> deketelaere <at> tComLabs.com
> Cc: ipcdn <at> ietf.org
> Subject: RE: [ipcdn] RFMIBv2 ID-nits: references
>
>
> FYI, I did manage to locate the referenced document on 
> www.tcomlabs.com.  The direct link is 
> http://www.tcomlabs.com/Euro-DOCSIS/Documents/Add-Euro-DOCSIS_
> spec.pdf.  Via their website, you can get to the file by first 
> clicking on the Euro-DOCSIS link, then clicking on the Euro-DOCSIS 1.0 
> link (the link to that page is 
> www.tcomlabs.com/Euro-DOCSIS/Euro-DOCSIS1.0.htm).  On that page, it's 
> the document listed as "Additional document: .pdf".
>
> Matt
>
> -----Original Message-----
> From: Jean-Francois Mule
> Sent: Thursday, December 04, 2003 3:12 PM
> To: david.raftus <at> Terayon.com; Eduardo Cardona; 
> deketelaere <at> tComLabs.com
> Cc: ipcdn <at> ietf.org
> Subject: [ipcdn] RFMIBv2 ID-nits: references
>
>
>
> Check ID nits and other comments made by mib doctors in other drafts.
>    http://www.ietf.org/ID-nits.html
>
> There are normative references that are not even mentioned once and 
> not used as IMPORTs in the document:
>    [1] Woundy, R., "Baseline Privacy Interface Management
>        Information Base for DOCSIS Compliant Cable Modems
>        and Cable Modem Termination Systems", RFC3083, March 2001.
>    [9] "Adapted MIB-definitions and a clarification for MPEG-related
>        issues for EuroDOCSIS cable modem systems v1.01", tComLabs,
>        May 2000., available at http://www.tcomlabs.com.
> Suggestions:
>   - call this reference in the text or just remove it;
>   - I cannot find the named reference under http://www.tcomlabs.com ; 
> if you keep it, then > we need a better link, especially if it remains 
> normative.
>
>
> Also, should [6] be made informative instead of normative?
> (a) it's a book
> (b) the DOCSIS specs are referenced normatively and that's where a 
> normative reference on QPSK should be.
>    [6] Proakis, John G., "Digital Communications, 3rd Edition",
>        McGraw-Hill, New York, New York, 1995, ISBN 0-07-051726-6
>
> Thanks,
> Jean-François
> PS: also, CableLabs is working on a stable HTTP URL for our 
> specifications so the http://www.cablemodem.com URL will most likely 
> have to be updated. More on the actual URL soon.
>
>
> _______________________________________________
> IPCDN mailing list
> IPCDN <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ipcdn
>
Jean-Francois Mule | 5 Dec 19:43 2003

RE: RFMIBv2 ID-nits: references

Your proposal works for me, thank you all for addressing this nit.
Jean-François 

Gmane