Subject: [Adslmib] (no subject)

From: "Bob Ray" <[email-masked]>
Date: 23 Sep 2002 19:27:17 -0000

Hi.

I've just sent in revised drafts of the vdsl and hc-tc mibs 
to the internet drafts editor.  To avoid sending the entire
thing to the list, here is a summary of the changes I made.

1.  changed "x.x dB" to "x.x dBm" in UNITS clauses per Mike 
    Heard's comments.

2.  created a new object vdslSCMConfProfileTxBandSide and made
    it part of the index for the vdslSCMConfProfileTxBandTable
    per comments from Travis Levin and Moti Morgenstern.

3.  per input from DSL Forum Working Text WT-068, I made the
    following changes:

3a. per section 2.3.1, I augmented the description for 
    vdslLineConfBandPlan

3b. per section 2.3.2, I added a range to vdslLineConfBandPlanFx

3c. per sections 2.5.1 and 2.5.2, I added two objects
    vdslLineConfDownstreamMaxPwr and vdslLineConfUpstreamMaxPwr

3d. per section 2.7.1, I augmented the description for the
    amateur radio band mask and added 4 objects to set the
    start and stop frequencies for the two optional vendor-specific
    (custom) notches.

3e. per section 2.8, I removed 1 object and added 6 objects to
    define minimum, maximum, and target noise margins in both
    downstream and upstream directions.  I also added 4 notifications
    for these (up/down max/min).

3f. also per section 2.8, I corrected the ranges I'd had on the snr
    margins.

3g. per section 2.9, I added 9 objects to specify fast and slow
    channel minimum and maximum data rates for both downstream
    and upstream as well as a rate adaptation ratio.

3h. per section 2.10, I added 2 objects to specify maximum interleave
    delay for downstream and upstream.

3i. per section 3.2, changed curr table to distinguish between downstream
    and upstream.

3j. per section 4.1, changed the scm profile to support upstream and
    downstream objects for codeword size, fec size, block size, depth,
    and number of carriers.

4.  per earlier email, I added definitions for the following textual
    conventions to the hc-tc mib: HCPerfValidIntervals, 
    HCPerfInvalidIntervals, HCPerfTimeElapsed, and 
    HCPerfIntervalThreshold.  The descriptions in these probably need a 
    little more work, but cannot update one without the other.  I then 
    used these textual conventions in the vdsl mib.

5.  added a sentence stating that slow and interleave are the same channel
    in vdslLineType.

6.  changed the range on vdslCurrSnrMgn.

7.  changed the range on vdslCurrAtn.

8.  changed the units and range on vdslCurrOutputPwr.

Hope this is a move forward!

Regards,
Bob Ray
_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

---

From: [email-masked]
Date: Tue, 24 Sep 2002 11:19:00 +0300

Hi Bob,

In 3j, did you add "side" as part of the index for the
vdslLineSCMConfProfileTable or do you have downstream objects and upstream
objects in the same entry?

Best regards,
Moti

                      "Bob Ray"                                                                                                        
                      <bob.ray@                To:      [email-masked]                                                               
                      knology.net>             cc:                                                                                     
                      Sent by:                 Subject: [Adslmib] (no subject)                                                         
                      adslmib-admin@                                                                                                   
                      ietf.org                                                                                                         

                      23/09/02 22:27                                                                                                   

Hi.

Regards,
Bob Ray

---

From: "Bob Ray" <[email-masked]>
Date: 24 Sep 2002 09:54:24 -0000

> vdslLineSCMConfProfileTable or do you have downstream 
> objects and upstream objects in the same entry?
> 
> Best regards,
> Moti
> 

I added it as part of the index to vdslLineSCMConfProfileTxBandEntry.
To accomplish this, I had to add an object to the TxBandEntry
denoting the physical side (vtu-r or vtu-c).  This is because 
vdslPhysSide and vdslLineConfProfileIndex reside in distinct tables,
and for indices one can only use objects from the entry being
defined or one other table.  

I believe this is per the recent email exchange between you
and Travis/Paradyne.  A more orthogonal approach would be to
have separate tx and rx band tables as with MCM, but I believe
this accomplishes the same result.  That is,

    -- combined with side as partial index

    prof = 1
    side = 1
    band = 0
    while (prof = 1) and (side = 1)
         band = entry.getNext(prof, side, band)
    while (prof = 1) and (side = 2)
         band = entry.getNext(prof, side, band)

    -- separate tables

    prof = 1
    band = 0
    while (prof = 1) and (eot(rxentry) = false)
          band = rxentry.getNext(prof,band)
    prof = 1
    band = 0
    while (prof = 1) and (eot(txentry) = false)
          band = txentry.getNext(prof,band)

Personally, I don't see much difference, although purists would
argue one way or the other.  For example, having separate tables 
reduces network traffic (smaller objects on the wire).  Having
separate tables potentially increases agent complexity (on the
sophomoric notion that more objects implies a larger agent).

Bob

---

From: "Travis Levin" <[email-masked]>
Date: Wed, 25 Sep 2002 15:40:18 -0500

Bob,

From reviewing the new VdslLineSCMConfProfileTable, it may have been a
little bit cleaner and matched the other tables better, by adding an
additional index for each side similar to the new
vdslLineSCMConfProfileTxBandTable.  That way, instead of having a
DownInterleaveDepth and UpInterleaveDepth, etc..; you would just have a
single object for each side.  Also, to keep with the current format, a
upTransmitPSDMask and downTransmitPSDMask may be nessecary along with
separate ones for the vendor notch objects.

I am confused by some of the objects recommended by the DSL Forum.  In
looking at document WT-068, section 2.9, they say that there is no dynamic
rate adaptation in the VDSL specification, but then they recommend a rate
adaptation ratio object.  Is this sort of functionality in one of the VDSL
specifications, and if so ,can someone tell me which one to look at?

Just one more thing before I go, and I apologize for joining the group
pretty late in the game.  I was just wondering why
vdslLineSCMConfProfileTxBandEntry had to be indexed by
vdslLineConfProfileIndex at all.  Why not have it as a separate table, then
have objects in vdslLineConfProfileEntry pointing to the corresponding index
for their upstream and downstream configurations.  That way you could create
the Tx Bands independently of the profile, and then  the administrator could
mix and match the entries to create the desired profile.  Also, that way,
the administrator does not have to worry about the details of the symbol
rates and constellations, they just pick the speed and frequency range they
want, and create their profile.  Just a thought.

Thanks for your time,
Travis

> Bob,
>
> Thanks for explaining what you did with the
> vdslLineSCMConfProfileTxBandEntry, but my question referred to
> vdslLineSCMConfProfileTable.
>
> Did you add an index there too?
>
> Best regards,
> Moti

No.  Looks like I should have, though.  When they get the draft posted,
please review it carefully, as I would like to wrap it up before Atlanta.
Perhaps I'm being optimistic, but maybe we can finish the thing with
one more round.

Thanks,
Bob Ray