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

Greg, 

some comments

In my email, my conclusions were

Summary of possible edits:

No RowStatus for 'real' ifIndex associated entries (see below)

Explicitly say cloneFrom update values in  created entry from pointed
entry
 -> Agree with you to Clean the CloneFrom Definition, as "cloning :
transfer values from active to cloned" 
    Not changing current "cloneFrom object.
    
    from Dan's comments, that's the Mngmt system approach
(deterministic) 
    The cloneFrom is more as you said experiments, lab testing, vendor
testing, ( human friendly, if a,b,c 
    needs to be replaced for a,b1,c, then update only b1)
    Mngmt systems should imply that first object to set is CloneFrom
Implicitly. And Dan is comfortable with that, other vendors might chime
on that. 

 


Edo wrote:
To avoid that, I would think that RowStatus object is not instantiated
for "real" mapped entries by ifIndex.
Leaving ifAdminStatus the complete activation/de-activation of entries.
Or 'always' report 'active' regardless of the IfOperStatus, Would be
good to clear that.

<GW> Isn't the description text for UpChannelStatus clear enough on
this? 

RowStatus Says 

             The following restrictions apply to this object:
             1) This object must contain a value of active(1) for
                active rows.

"active rows" is in-service? In other words ifOperStatus = 'up'? Or
non-cloning rows? ifOperstatus = any value- (all ifindex associated
UpChannel)
Specially active(1) for active rows, is a loos definition I believe.


What I was looking at  was to separate in clear  any possible dependency
of ifOperStatus 
I will think 'real' regardless of the ifOperStatus, 
I believe would make sense to set the "Update" object and reject the set
regardless if the interface is up/down (CMTS rules based on templates of
UpCh/Prof capabilities) that way if set 'up' later it won't fail start
again

Text could be clarify as :  
docsIfUpChannelStatus 
.....
             The following restrictions apply to this object:
             1) This object must contain a value of active(1) for
                active rows regardless of its ifOperStatus.
 
Implementers will understand that there is no link in a UPChannel
'active' row with the current operational status 
Cloned entries ( not associated with ifIndex value ) have no
ifOperStatus.
Will imply all verifications are done regardless of the up/down state of
the interface.



-----Original Message-----
From: Dan Rice @ Stargus 
Sent: Friday, October 10, 2003 11:47 AM
To: Greg White; Eduardo Cardona; Minnie Lu; [email protected]
Cc: DOCSIS OSS Majordomo List; [email protected]; [email protected];
[email protected]; 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)


Agreements and my preferences below

-----Original Message-----
From: Greg White [mailto:[email protected]] 
Sent: Friday, October 10, 2003 12:48 PM
To: Eduardo Cardona; Dan Rice; Minnie Lu; [email protected]
Cc: DOCSIS OSS Majordomo List; [email protected]; [email protected];
[email protected]; 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)

3 comments in-line.

-----Original Message-----
From: Eduardo Cardona 
Sent: Friday, October 10, 2003 9:33 AM
To: Dan Rice @ Stargus; Greg White; Minnie Lu; [email protected]
Cc: DOCSIS OSS Majordomo List; [email protected]; [email protected];
[email protected]; 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)


Dan, 

That's a very good point, Currently is up to de Vendor for non-SCDMA, I
think we did not finish the discussion about that last time.


<GW>  I have always been uncomfortable with the descriptions referring
to SCDMA only.  I don't see any real benefit for the vendor in only
supporting this feature for rows that have a channel type of SCDMA, and
even if they did, how would they handle changes to/from SCDMA mode?  I
would very much be in favor of cleaning up those definitions to remove
the references to SCDMA and the text making support optional for
non-SCDMA rows.

[DJR] Great this was issue 6, may need an ecr also?


Also, The "active" (a mix with RowStatus 'active' but not necessarily
linked to ifAdmin/OperStatus) was initially though to be the entries
associated to real physical US ports.

The row Status was intended for Clonning process, 
as we know RFC 2670 did not have RowStatus; and for "active", now
RowStatus may have ramifications with RowStatus values not really
defined, like 'notReady' and the connotations of ifAdminStatus,
ifOperStatus that are the currently used, 

To avoid that, I would think that RowStatus object is not instantiated
for "real" mapped entries by ifIndex. Leaving ifAdminStatus the complete
activation/de-activation of entries. Or 'always' report 'active'
regardless of the IfOperStatus, Would be good to clear that.


<GW> Isn't the description text for UpChannelStatus clear enough on
this? 
[DJR] I believe this was clear.



The clonning entry, will be the simulation bench to tuning the values,
Will explode the Whole range of RowStatus 'notReady' After creation will
indicates the US Channel/Mod profile setup is not right. 'notInService'
all parameters are consistent and can be turn via Update object to the
cloned interface.

 
Also one thing that could be sticky 
"CloneFrom" object is the pointer to later transfer the values. Alas
"CopyTo"

I may be wrong but just by name references when CloneFrom is set, (as a
clonning process) will copy values of pointed entry to created entry, 

Currently CloneFrom object does not say that. But I believe it does not
limit implementers to think on that,


<GW>  I agree, I was surprised to see that there is no mention of what
operation takes place upon setting CloneFrom.  The name certainly
implies (and was the intention I believe) that setting CloneFrom copied
all of the entries from the referenced 'active' row, which implies that
it is the first object to set after row creation.  I'd rather clean up
the description to match that intent, rather than change the object to
'CopyTo'.  I don't think 'CopyTo' would really be more efficient than
'CloneFrom' for an automated NMS.  The only efficiency lost would be
having the CMTS copy 60-odd bytes from one memory location to another
only to potentially have them overwritten by the NMS.  If these
operations were happening on millisecond timescales I would be
concerned, but this is more like a once-a-day, once-a-month, once-a-year
type operation.  Let's keep the changes simple and just update the
description to match the object name and the original intent.

[DJR] I am not sure that this entry is super useful for most
applications besides experimenting in the lab.  I think if this entry
just identified the active row you would be changing as opposed to
creating a template for one to tweak that would be more effective. I
think a management system would first create a new mod profile, then
create a clone row including all relevant entries from upstream channel
table, enter the upstream index it is intended to change and then commit
it with UpChannelUpdate assuming all columns in the upstream channel
would be applied in a single commit.  I think it is a little waste of
time to copy the current values when you are going to overwrite them all
anyway.  In addition it makes this 3 transactions instead of 2.  I could
live with it, but not sure I need it



Just to make sure the object does always the same think

A) Clonning process semantics 
- after createAndWait the first object to set is CloneFrom (copy
parameters into clonning entry)
   - It Might be clarified in the object -
- Adjust objects values
- Set update object to 'true' will success if:  
     before set, RowStatus was 'notInService', 
     and no other error condition is raised by CMTS for the set 


B) Copy Process (CopyTo)
- After createAndWait set arbitrary objects , setting object CloneFrom
does NOT transfer 
  parameters from pointed entry to created entry
- Set update object to 'true' will success if:  
     before set, RowStatus was 'notInService', 
     and no other error condition is raised by CMTS for the set

Being specific will clear a little bit the process in the user/system
thinking doing B) - CMTS does A) - and loosing previous sets if object
"CloneFrom" is set after some others. 

A) is User friendly ( few Sets)
B) is autonomous system efficient, -algorithms always calculates all
'optimal' parameters, so might not need to initialize previous setups
but should be aware of setting first 

For the object Name ( something we might not want to change at this
state) I believe A) is the precisely even though I would prefer 1 but
the correct name should be "CopyTo"


Summary of possible edits:

No RowStatus for 'real' ifIndex associated entries
Explicitly say cloneFrom update values in  created entry from pointed
entry

Let me know any comments

 Eduardo




-----Original Message-----
From: Dan Rice @ Stargus 
Sent: Friday, October 10, 2003 8:17 AM
To: Eduardo Cardona; Greg White; Minnie Lu; [email protected]
Cc: DOCSIS OSS Majordomo List; [email protected]; [email protected];
[email protected]; 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)


For my $0.02 I would prefer just having the clone mechanism.  Even
within the upstream channel parameters you must change things in the
right order for them to be correct if you do it while row is active.
This is not just an UpChannelType issue.  For example setting a minislot
size before changing the symbol rate can result in some situations that
CMTSs today will reject. If you reduce the minislot size before
increasing symbol rate, you could no longer send a max packet.

I think if we made the clone method mandatory for both TDMA and SCDMA
and changed the descriptions to be this way than I would be happy
because there is now a deterministic way to make changes and commit
them.  Today in most deployed CMTSs its hard to know how many UCD
changes occur when you make changes to upstream channel today.  It seems
to depend on vendor.  When all you are really shooting for is an end
result this seems the safest and most deterministic route to me.  

I think that many of the cases of making changes to active modulation
profiles and upstream channel settings can make things a little funny if
the commit isn't very defined.  If there are requirements for support of
enough modulation table entries and enough clone rows to accommodate an
active and notInService for each upstream interface this could be a lot
cleaner. Any change that is made is done by creating a new complete
modulation profile (even if its just changing one value, I imagine most
of this will done through software as opposed to hand editing) then
creating a clone upstream channel table entry with pointer to this new
mod profile and associated upstream channel settings, then commit the
changes.

Additionally it would be nice to have the same functionality in the
downstream channel table to be consistent. For example it would be nice
to commit modulation and interleave settings at the same time.

-----Original Message-----
From: Eduardo Cardona [mailto:[email protected]] 
Sent: Thursday, October 09, 2003 8:37 PM
To: Greg White; Minnie Lu; [email protected]
Cc: DOCSIS OSS Majordomo List; [email protected]; [email protected];
[email protected]; Owner DOCSIS OSS Majordomo List
Subject: [ipcdn] RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 :
rules for assigning modulation profiles to upstream channels)


I agree that turning off is not desired for in-service if the changes
are not incremental or very drastic changes, I did not enforce the "at
maximum" word in both cases (actually I only used that in the second
example). It might be some cases where the interface or implementations
definitely have to be turn off, but will be on maintenance windows,
(season changes -?- school calendar, long weekend?, maintenance
measurements.) very uncommon or at knowledge of consequences by MSOs.

I agree that the primarily intention is minimum service disruption
primarily for spectrum management when changes might be incremental in
robustness parameters or phy channel parameters. 

And as Greg said, one shot change if moving channel from profile A to B.
and seems to me that changes in profile should be compatible to the
current channel PHY and ulterior modification of the channel will be
also, the only problem as today is the double location of ChannelType 

Eduardo

-----Original Message-----
From: Greg White 
Sent: Thursday, October 09, 2003 4:31 PM
To: Eduardo Cardona; 'Minnie Lu'; '[email protected]'
Cc: DOCSIS OSS Majordomo List; '[email protected]';
'[email protected]'; '[email protected]'; Owner DOCSIS OSS Majordomo
List
Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for
assigning modulation profiles to upstream channels)


So, first off, there are a number of parameters that must be consistent
across the two tables for the configuration to be valid, and the active
rows in the UpChannelTable *always* have to be valid.  The only possible
exception to this would be if the interface were turned down before the
changes were made, but I don't think that is an operationally useful
scenario to consider, and some (all?) vendors might want to enforce
validity even in that case.

Any active row in the UpChannelTable will be populated by consistent
defaults or stored values when the CMTS is booted, so we only need to
consider *changes* to those rows (i.e. they can't be created from
scratch and so would never have to be populated one-object-at-a-time).
Any change to an active row can be done by two methods: direct change &
cloning.

When a change is made directly, the validation occurs immediately upon
receiving the snmp set.  When using the cloning mechanism, the
validation only occurs when the ChannelUpdate object is set true.  This
proposal does not change either of those aspects.  It only enforces that
UpChannelModulationProfile and UpChannelType are guaranteed to be
consistent with each other.

The whole point of the cloning mechanism was to have a temporary
"scratch" area where an operator could manipulate the values without
having the constraint that they are consistent at every step.  Thus the
consistency verification is only done upon ChannelUpdate.

I don't think that the steps Eduardo suggested are valid, setting
ModulationProfile to '0' on an active row would seem to make the channel
unusable, no?  Setting ModulationProfile to '0' on an inactive row
wouldn't be necessary since there is no consistency checking.

Let me know if I'm completely missing the boat here....

-Greg



-----Original Message-----
From: Eduardo Cardona 
Sent: Thursday, October 09, 2003 1:38 PM
To: 'Minnie Lu'; [email protected]
Cc: Greg White; DOCSIS OSS Majordomo List; [email protected];
[email protected]; [email protected]; Owner DOCSIS OSS Majordomo List
Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for
assigning modulation profiles to upstream channels)


Hi David, Minnie, 

Greg may have other comments.
I think the idea was to define one clear way of configuration rather
than finding possible broken paths

The idea was to pass the role of The UpChannel parameters vs ChannelType
verification to one trigger, the docsIfUpChannelModulationProfile so it
verifies that all the channelTypes are the same (in the mod profile) All
Modulation Parameters are consistent in into their own IUC [ can be done
also as user change an IUC itself -invalid value for that particulat
CMTS-, etc] Then as the Type is knew from the profile verifies that the
ChannelType is compatible with the UpChannel parameters, if fails
nothing haven change or undo-commit. 

The point is that UpChannel to ModulationProfile is one-to-many so going
in that path eventually the user won't break the Profile that works for
other UpChannels and instead maybe create a one-to-one
UpChannel-to-ModulationProfile  ( by creating a new Profile)

In the current UpChannelChanelType read-create we have, implies
UpChannelModProfile and ChannelType might need to be modified
simultaneously or:

1  UpChannelModProfile to '0'   then 
2  (updates UpChannel Parameters) then 
3  UpChannelType to 'x' and 
  -verify Chnnl-
4  UpChannelModulationProfile to 'y'
  -verify Chnnl UpCh/ModProfile- 
   if failed start again from 1


With the proposal at maximum ( channelType RO) would be  
1  UpChannelModProfile to '0'   then 
2  (updates UpChannel Parameters) then 
3  UpChannelModulationProfile to 'y'
   - do all verifications chnnl/ModProf-  
     if failed redo 2, maybe adjust ModulationProfileTable and 3)

Are there any other updated paths to consider for simplified setup,
other sequence? 
Or maybe be more details in the sequence for the objects ?

Eduardo


-----Original Message-----
From: Minnie Lu [mailto:[email protected]] 
Sent: Thursday, October 09, 2003 12:25 PM
To: [email protected]
Cc: Greg White; DOCSIS OSS Majordomo List; [email protected];
[email protected]; [email protected]; Minnie Lu; Owner DOCSIS OSS
Majordomo List
Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for
assigning modulation profiles to upstream channels)


Hi, David,

  Your concern sounds very valid. Then it seems to me that

1. either have docsIfUpChannelType is read-only and ask the 
docsIfUpChannelModulationProfile must be assigned first before setting 
other upstream attributes.  For this is one, I don't know user would
like 
it or not.

2. or we still need to keep the  docsIfUpChannelType is read-create, so
it 
can be used to check other upstream attributes consistence without
having 
an modulation profile assigned. The user must make sure both 
docsIfUpChannelModulationProfile and docsIfUpChannelType are the same
when 
trying to set either one of them if docsIfUpChannelModulationProfile is
not 
value 0. If they are not consistent, the set will fail.

Any more possible solution ?

Just some more thoughts.

Thanks a lot !
Minnie

At 11:35 AM 10/9/2003 -0400, [email protected] wrote:

>Greg,
>         The main problem I have with this is that it forces the CMTS 
>to  postpone data checking until possibly the very end when the 
>modulation  profile is finally assigned. That is, the user may get a 
>wrongValue or  inconsistentValue while attempting to set the modulation

>profile because  one or more already-set parameters do not agree with 
>the ModChannelType.  What I liked about having the UpChannelType being 
>a configurable and  "active" (rather than passive) object is that the 
>CMTS verify things like  ChannelWidth, SlotSize, and the Scdma 
>parameters as they are being set.  Thus, the error is immediate and 
>pertitent.
>
>However, what I like about your proposal is that it makes it easier to
>transition an upstream channel from tdma, atdma, and tdmaAndAtdma 
>without having to change both the modulation profile and UpChannelType 
>at the same time.
>
>I'm not rejecting your proposal, but just wanted to voice my concerns.
>
>Thanks,
>David
>
>
>
>"Greg White" <[email protected]>
>Sent by: [email protected]
>
>10/08/2003 07:35 PM
>
>         To:        <[email protected]>
>         cc:        "DOCSIS OSS Majordomo List" 
> <[email protected]>, <[email protected]>, 
> <[email protected]>, <[email protected]>, "Minnie Lu" 
> <[email protected]>
>         Fax to:
>         Subject:        RE: Channel Types in RFMIBv2  (was RE: DOCSIS
2.0 
> : rules for  assigning modulation profiles to upstream channels)
>
>
>David,
>
>According to the proposed text, docsIfUpChannelType would be read-only 
>for ALL rows.
>
>For "active" rows (docsIfUpChannelStatus = active(1)) setting
>UpChannelModulationProfile would return an error if the channel type of

>the profile does not work with the other parameters in the row.
>
>For "cloned" rows (docsIfUpChannelStatus = notInService(2)) no
>verification is done on consistency of parameters until 
>docsIfUpChannelUpdate is set to true.
>
>The verification for active rows is indicated in the proposed text for
>UpChannelModulationProfile, although it looks like it could be
>clarified:
>
>              Setting this object on an "active" row MUST return an 
> error if the following
>             conditions are not satisfied:
>             1. All the IUC entries in the selected modulation profile
>             MUST have the same value of docsIfCmtsModChannelType.
>             2. All of the modulation parameters in the selected
>             modulation profile MUST be consistent with the other
>             parameters in this docsIfUpChannelEntry.
>
>Does that address your concern?
>
>-Greg
>
>-----Original Message-----
>From: [email protected] [mailto:[email protected]]
>Sent: Wednesday, October 08, 2003 3:11 PM
>To: Greg White
>Cc: DOCSIS OSS Majordomo List; [email protected]; [email protected];
>[email protected]; Minnie Lu
>Subject: RE: Channel Types in RFMIBv2 (was RE: DOCSIS 2.0 : rules for 
>assigning modulation profiles to upstream channels)
>
>
>Greg,
>        Per your earlier e-mail on this thread:
>
>"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."
>
>I'm assuming "active" mean in-service. Otherwise, we have to be careful

>with this because the channelType is used to verify things like
>channelWidth and whether or not setting of the scdma-specific 
>parameters is allowed. Along the same lines, if setting the upstream 
>modulation profile index implies that the SNMP agent changes the 
>upChannelType to match the modProfChannelType, then the agent must also

>verify that all of the other parameters in the upstream channel are 
>compatible with the possibly new channel type.
>
>David
>
>
>"Greg White" <[email protected]>
>
>10/08/2003 04:12 PM
>        To:        "Minnie Lu" <[email protected]>
>        cc:        <[email protected]>, "DOCSIS OSS Majordomo
List" 
> <[email protected]>, <[email protected]>,
><[email protected]>, <[email protected]>
>        Fax to:
>        Subject:        RE: Channel Types in RFMIBv2  (was RE: DOCSIS
2.0 
> : rules for  assigning modulation profiles to upstream channels)
>
>
>
>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 protected]]
>Sent: Wednesday, October 08, 2003 12:48 PM
>To: Greg White
>Cc: [email protected]; Minnie Lu; DOCSIS OSS Majordomo List;
>[email protected]; [email protected]; [email protected]
>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 protected] [mailto:[email protected]]
> >Sent: Monday, August 25, 2003 5:59 PM
> >To: Minnie Lu
> >Cc: DOCSIS OSS Majordomo List; [email protected]; Greg White;
> >[email protected]; 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 protected]>
> >
> >08/25/2003 07:01 PM
> >
> >         To:        "Greg White" <[email protected]>
> >         cc:        <[email protected]>, "Minnie Lu"
> > <[email protected]>, <[email protected]>,
> > <[email protected]>,
>
> > "DOCSIS OSS Majordomo List" <[email protected]>, "Owner
> > DOCSIS
>OSS
> > Majordomo List" <[email protected]>
> >         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 protected] [mailto:[email protected]]
> > >Sent: Monday, August 25, 2003 11:07 AM
> > >To: Minnie Lu; [email protected]; [email protected]
> > >Cc: DOCSIS OSS Majordomo List; Greg White; [email protected]; 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 protected]
> > >
> > >
> > >
> > >
> > >
> > >-----Original Message-----
> > >From: Steve Malenfant [mailto:[email protected]]
> > >Sent: Monday, September 30, 2002 9:39 AM
> > >To: '[email protected]'
> > >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 protected]>
> > >Sent by: [email protected]
> > >
> > >08/21/2003 07:15 PM
> > >
> > >         To:        [email protected], "Greg White"
> > > <[email protected]>
> > >         cc:        "DOCSIS OSS Majordomo List"
> > > <[email protected]>, [email protected]
> > >         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 protected] 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 protected]>
> > > >Sent by: [email protected]
> > > >
> > > >08/20/2003 07:35 PM
> > > >
> > > >         To:        <[email protected]>, "DOCSIS OSS
Majordomo
>List"
> > > > <[email protected]>
> > > >         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 protected] [mailto:[email protected]]
> > > >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 protected]
https://www1.ietf.org/mailman/listinfo/ipcdn