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