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

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 4 Dec 2003 14:47:51 -0700

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: [email-masked] [mailto:[email-masked]] 
	Sent: Thursday, December 04, 2003 2:21 PM
	To: Greg White
	Cc: Dan Rice @ Stargus; DOCSIS OSS Majordomo List;
[email-masked]; [email-masked]; [email-masked]; 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" <[email-masked]> 
Sent by: [email-masked] 

10/10/2003 12:56 PM 

        To:        "Dan Rice @ Stargus" <[email-masked]>, "Minnie Lu"
<[email-masked]> 
        cc:        <[email-masked]>, "DOCSIS OSS Majordomo List"
<[email-masked]>, <[email-masked]>,
<[email-masked]>, <[email-masked]> 
        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 @ Stargus 
	Sent: Friday, October 10, 2003 7:59 AM
	To: Greg White; Minnie Lu
	Cc: [email-masked]; DOCSIS OSS Majordomo List;
	[email-masked]; [email-masked]; [email-masked]
	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:[email-masked]] 
	Sent: Wednesday, October 08, 2003 7:20 PM
	To: Minnie Lu
	Cc: [email-masked]; DOCSIS OSS Majordomo List;
	[email-masked]; [email-masked]; [email-masked]
	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:[email-masked]] 
	Sent: Wednesday, October 08, 2003 3:09 PM
	To: Greg White
	Cc: Minnie Lu; [email-masked]; DOCSIS OSS Majordomo
List; 
	[email-masked]; [email-masked]; [email-masked]
	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:[email-masked]]
	>Sent: Wednesday, October 08, 2003 12:48 PM
	>To: Greg White
	>Cc: [email-masked]; Minnie Lu; DOCSIS OSS Majordomo
List;
	>[email-masked]; [email-masked]; [email-masked]
	>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: [email-masked] [mailto:[email-masked]]
	> >Sent: Monday, August 25, 2003 5:59 PM
	> >To: Minnie Lu
	> >Cc: DOCSIS OSS Majordomo List; [email-masked]; Greg
White;
	> >[email-masked]; 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 <[email-masked]>
	> >
	> >08/25/2003 07:01 PM
	> >
	> >         To:        "Greg White" <[email-masked]>
	> >         cc:        <[email-masked]>, "Minnie Lu"
	> > <[email-masked]>, <[email-masked]>,
	<[email-masked]>,
	>
	> > "DOCSIS OSS Majordomo List" <[email-masked]>,
"Owner
	DOCSIS
	>OSS
	> > Majordomo List" <[email-masked]>
	> >         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: [email-masked]
[mailto:[email-masked]]
	> > >Sent: Monday, August 25, 2003 11:07 AM
	> > >To: Minnie Lu; [email-masked];
[email-masked]
	> > >Cc: DOCSIS OSS Majordomo List; Greg White; [email-masked];
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
	> > >[email-masked]
	> > >
	> > >
	> > >
	> > >
	> > >
	> > >-----Original Message-----
	> > >From: Steve Malenfant [mailto:[email-masked]]
	> > >Sent: Monday, September 30, 2002 9:39 AM
	> > >To: [email-masked]'
	> > >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 <[email-masked]>
	> > >Sent by: [email-masked]
	> > >
	> > >08/21/2003 07:15 PM
	> > >
	> > >         To:        [email-masked], "Greg White"
	> > > <[email-masked]>
	> > >         cc:        "DOCSIS OSS Majordomo List" 
	> > > <[email-masked]>, [email-masked]
	> > >         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, [email-masked] 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" <[email-masked]>
	> > > >Sent by: [email-masked]
	> > > >
	> > > >08/20/2003 07:35 PM
	> > > >
	> > > >         To:        <[email-masked]>, "DOCSIS OSS

	Majordomo
	>List"
	> > > > <[email-masked]>
	> > > >         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: [email-masked]
[mailto:[email-masked]]
	> > > >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
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: [email-masked]
Date: Thu, 4 Dec 2003 16:21:20 -0500

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 

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
  2 tdma or tdmaAndAtdma (must follow tdma rules) - this IUC is optional

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

  2  tdma or tdmaAndAtdma (must follow  tdma rules) - this IUC is optional
 11 atdma or tdmaAndAtdma (must follow atdma rules) - 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

        To:     "Dan Rice @ Stargus" <[email-masked]>, "Minnie Lu" <[email-masked]>
        cc:     <[email-masked]>, "DOCSIS OSS Majordomo List" 
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>
        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 @ Stargus 
Sent: Friday, October 10, 2003 7:59 AM
To: Greg White; Minnie Lu
Cc: [email-masked]; DOCSIS OSS Majordomo List;
[email-masked]; [email-masked]; [email-masked]
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?

-----Original Message-----
From: Greg White [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 7:20 PM
To: Minnie Lu
Cc: [email-masked]; DOCSIS OSS Majordomo List;
[email-masked]; [email-masked]; [email-masked]
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:[email-masked]] 
Sent: Wednesday, October 08, 2003 3:09 PM
To: Greg White
Cc: Minnie Lu; [email-masked]; DOCSIS OSS Majordomo List;
[email-masked]; [email-masked]; [email-masked]
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

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
>If there is a consensus to change the text, I am not strongly opposed.
>
>-Greg
>
>Cc: [email-masked]; Minnie Lu; DOCSIS OSS Majordomo List;
>Subject: Re: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for
>        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
> >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
> >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
> >Cc: DOCSIS OSS Majordomo List; [email-masked]; Greg White;
> >[email-masked]; 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
>
> > "DOCSIS OSS Majordomo List" <[email-masked]>, "Owner
DOCSIS
> > >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
> > >Since this has been a point of confusion at least twice now, does
>anyone
specification?
> > >A further point, how does the CMTS enforce the match between
>UpChannelType
> > >and ModChannelType?  One implementation may automatically change
> > >docsIfUpChannelModulationProfile is set.  Another might reject the
>change
> > >docsIfUpChannelCloneFrom mechanism to change the channel type.  I'd
>argue
> > >that the first implementation makes more sense, and ought to be
made
> >[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
clarified,
> > >To: Minnie Lu; [email-masked]; [email-masked]
> > >Cc: DOCSIS OSS Majordomo List; Greg White; [email-masked]; Owner
>DOCSIS
> > >OSS Majordomo List
> > >Subject: RE: DOCSIS 2.0 : rules for assigning modulation profiles
to
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
tdmaAndAtdma,
> > >Your configuration settings for operation in multiple mode is
correct
> > >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
> > >[email-masked]
> > >
> > >
> > >
> > >
> > >
> > >We are having some discussion internally here, and would like to
>clarify
> > >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.
> > >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.
> > >
> > > >         IUCs 1, 2, 3, and 4 are used for both tdma and atdma
>channels.
> > > > 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
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
> > > > DocsisUpstreamTypeStatus object, perhaps ?) to avoid a lot of
>confusion.
> > > >         For the mixed-mode channels, where UpChannelType is
> > tdmaAndAtdma,
> > > >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
> > > >
> > > >
> > > >
Majordomo
> > > >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.
> > > >
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
> > > >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
> > > >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
> > >
> >
> >
> >

---

From: "Greg White" <[email-masked]>
Date: Thu, 4 Dec 2003 15:26:24 -0700

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: [email-masked]; Greg White
	Cc: Dan Rice @ Stargus; DOCSIS OSS Majordomo List;

	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-----

		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 
		  2 tdma or tdmaAndAtdma (must follow tdma rules) - this
IUC is optional 
		
		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 
		
		  2  tdma or tdmaAndAtdma (must follow  tdma rules) -
this IUC is optional 
		 11 atdma or tdmaAndAtdma (must follow atdma rules) -
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 

10/10/2003 12:56 PM 

		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 @ Stargus 
		Sent: Friday, October 10, 2003 7:59 AM
		To: Greg White; Minnie Lu
		Cc: [email-masked]; DOCSIS OSS Majordomo List;
		[email-masked]; [email-masked];
[email-masked]
		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?

		-----Original Message-----
		From: Greg White [mailto:[email-masked]] 
		Sent: Wednesday, October 08, 2003 7:20 PM
		To: Minnie Lu
		Cc: [email-masked]; DOCSIS OSS Majordomo List;
		[email-masked]; [email-masked];
[email-masked]
		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:[email-masked]] 
		Sent: Wednesday, October 08, 2003 3:09 PM
		To: Greg White
		Cc: Minnie Lu; [email-masked]; DOCSIS OSS
Majordomo List; 
		[email-masked]; [email-masked];
[email-masked]
		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
		
		Thanks a lot !
		Minnie
		
		is
		could
relationship
upstream
		to
docsIfUpChannelType a
consensus from
		review
Majordomo List
		> >Subject: RE: DOCSIS 2.0 : rules for assigning
modulation profiles to
		issue
		of
		other
		DOCSIS
assigning
notwithstanding, I
		think
		there
UpChannelType and
		specification?
		made
		the
		and
		I
modulation
		profile
		be
		clarified,
[email-masked]
		> > >Subject: RE: DOCSIS 2.0 : rules for assigning
modulation profiles
		to
		consistency
modulation
		profile
		no
		tdmaAndAtdma,
		correct
		with
		and
		5
		29.
assigning
profiles with
		see
		modulation
		for
		and
		could
disadvantages..." line
		of
		Majordomo
combinations.
		Among
		1,3,4,5,6,9,10,
		having
		in
		for