Subject: [Adslmib] VDSL MIB and TR-057

From: Flemisch Felix <[email-masked]>
Date: Thu, 13 Mar 2003 12:12:29 +0100

Hi Rajesh and Moti,

I have a couple of comments on your e-mails of 27th February resp. 2nd March
regarding alignment of the VDSL MIB with TR-057.

Find a copy of the e-mails below with my comments inserted and marked [Felix].

Best regards,

Felix Flemisch
--------------------------------------
SIEMENS AG
Information and Communication Networks
Carrier Products Systems Engineering
Hofmannstr. 51
D-81359 Munich
Tel     +49 89 722 62175
e-Mail  [email-masked] 
--------------------------------------

[Felix] I propose to generally align VDSL-LINE-MIB not only fully with TR-057
        but also with RFC 2662 (and RFC 3440, if applicable).

Moti Morgenstern wrote on Sunday 02 March 2003:

For the VDSL, the DSLF decided to extract the line code specific parameters
from the basic MIB only after the members reviewed a contribution from NLC
(dsl2002.298) claiming that SCM specific parameters can be determined
according to other, generic type, parameters.  The problem is that the DSLF
discovered only recently that few of those generic parameters are not
present in the MIB so configuring a SCM line is impossible without
additional parameters.

So, I suggest adding the two generic parameters Overhead (%) and Burst
Protection (ms) to the MIB, in order to allow determining the Fast Codeword
Size and FEC Size for SCM links.

[Felix] If I understand you and Sabit of NLC right, you are proposing to add the
        parameters vdslChanOverhead (UNITS "%") and vdslChanBurstProtection
        (UNITS "ms") to VdslChanEntry, which shall be not valid for ifType
        interleave(124).  Please provide a formal DESCRIPTION and how they are used
        for SCM lines.  Since these extensions are compatible with TR-057 and
        RFC 2662, I agree and don't see any reason why anybody should not agree.
        After adding these two parameters, is it then clear that basic configuration
        of SCM lines is possible, or might something else be needed or useful?

Rajesh Abbi wrote on Thursday 27 February 2003:

-----------------------------------------------------------------------------------
 Differences between IETF (draft-ietf-adslmib-vdsl-07.txt) and DSLF (TR-057)
-----------------------------------------------------------------------------------

    - vdslLineTable:
            - vdslLineCoding and vdslLineType are not addressed by DSLF.
            ** Propose to leave in - useful.
            [Felix] I agree, they are even very useful, but propose to use for the
                    values of vdslLineType the values of adslLineType of RFC 2662,
                    e.g. interleavedOnly instead of slowOnly.  Note that also the
                    ifType is interleave(124) and not slow.

    - vdslPhysTable:
            - IETF: has Current Channel Rates only
            - DSLF: has Current Line Rates only
            ** Propose to add Curr Line Rate to vdslPhysTable
            [Felix] You don't need this, and it's also not in RFC 2662.  In fact,
                    the ifSpeed should be the current line rate.  So to stay
                    compatible with RFC 2662 I propose to use ifSpeed if the
                    current line rate is needed.  When latency paths exist,
                    the current line rate should be the sum (aggregation) of
                    vdslChanCurrTxRate for these paths (see also your own
                    remarks below regarding 'Configured Line Rate').

    - vdslChanTable:
            - vdslChanCrcBlockLength:  DSLF does not have this.
            ** Propose to leave in - useful.

    - vdslSCMPhysBandTable:
            - TR-057 does not address line-code-specific (LCS) elements.
            ** Propose moving to a separate line-code-specific MIB Group/Sub-tree
               (similar to what was done for ADSL MIB - RFC 2662)
            [Felix] I agree.  Is IETF's adslmib working group then preparing
                    a separate RFC with an LCS MIB for SCM lines?

    - vdslLineConfProfileTable:
            - vdslLineConfDownstreamMaxPwr and vdslLineConfUpstreamMaxPwr are
              not addressed by DSLF.
            ** Propose to leave in - useful.

            - Data Rate configuration is different for IETF and DSLF:
                - IETF defines following per direction (Downstream/Upstream):
                    - Configured Line Rate
                    - Max Fast Chn Rate
                    - Min Fast Chn Rate
                    - Max Slow Chn Rate
                    - Min Slow Chn Rate
                  + vdslLineConfRateAdaptationRatio (common)
                - DSLF defines following per direction (Downstream/Upstream):
                    - Max Fast Chn Rate
                    - Min Fast Chn Rate
                    - Max Slow Chn Rate
                    - Min Slow Chn Rate
                    - Rate Selection Mode (Manual / Adapt at Init)
                    - Rate Adaption Ratio
            ** Proposal:
              * There is no need for 'Configured Line Rate' since rate is derived
                from the sum of Fast and Slow channel rates.  Moreover, specifying
                both can result in potential conflict.
                Suggest removing it.
              [Felix] Do you derive from the Max channel rates or from the Min
                      channel rates?  I suppose from the Max.
                      As a matter of fact, only in dual latency mode (i.e.,
                      vdslLineType is fastAndInterleaved) all the doubling
                      of parameters in fast and interleaved variants makes
                      sense.  But there is no way to define conditional
                      parameters, and so one has to stick to this doubling.
                      Normally there will be only one latency path whose type
                      can be seen from vdslLineType, and one should need only
                      UpstreamMaxDataRate and DownstreamMaxDataRate instead of
                      UpstreamFastMaxDataRate, UpstreamSlowMaxDataRate,
                      DownstreamFastMaxDataRate, and DownstreamSlowMaxDataRate.
              * DSLF wants explicit configuration of 'Rate Selection Mode'
                Suggest adding this.
              [Felix] For both, upstream and downstream.
              * 'Rate Adaption Ratio' can be different upstream/downstream.
                Suggest separating into up/down parameters.

            - Power Backoff configuration is different for IETF and DSLF:
                - IETF only defines xxxPboControl (enabled/disabled) for up/downstream.
                - DSLF defines following for up/downstream:
                    - Power Backoff Mode (Auto/Manual/Disabled)
                    - Manual Power Backoff Level (dB) (in case of Manual mode)
            ** Propose to use the more complete DSLF model.

            - vdslLineConfAdslOccupy:
                - Current IETF uses this to configure if VDSL line can 'occupy' the ADSL
                  spectrum.
                - DSLF does not support this configuration.  Instead it has a parameter to
                  indicate if ADSL is present in the VDSL binder.  This has spectral
                  compatibility impact for ETSI VDSL.  The parameter has three options:
                    - No ADSL Present
                    - ADSL over POTS present
                    - ADSL over ISDN present
            ** These two parameters do different things.  Perhaps we need both.  Folks
               at DSL Forum were not in favor of having the 'occupy' parameter.  I had
               proposed combining the two into one by adding two more options to the above
               "ADSL over POTS present in the loop" and "ADSL over ISDN present in loop".
            [Felix] I propose to REPLACE vdslLineCnfAdslOccupy by vdslLineAdslService.
                    The same line, i.e. twisted pair, is EITHER a VDSL line OR an ADSL
                    and therefore there is nothing to occupy.  But ADSL may be present
                    in the neighbourhood, and this is what the TR-057 parameter is saying.

            [Felix]
            - vdslLineConfU0Usage:
             I propose to change it to vdslLineConfOptUsage (also in the DESCRIPTION),
             since U0 is called Opt in G.993.1 (see also TR-057, Section 2.3.3).

    o MCM Specific:
            - vdslLineMCMConfProfileTable
            - vdslLineMCMConfProfileTxBandTable
            - vdslLineMCMConfProfileRxBandTable
            - vdslLineMCMConfProfileTxPSDTable
            - vdslLineMCMConfProfileMaxTxPSDTable
            - vdslLineMCMConfProfileMaxRxPSDTable

            - TR-057 does not address line-code-specific (LCS) elements.
            ** There is no need for these MCM specific profiles.  The high-level parameters
               configured in vdslLineConfProfileTable already determine the value of these
               low-level parameters.
               Suggest removing them altogether.  This will greatly simplify the MIB.
            [Felix] I agree.  Is IETF's adslmib working group then preparing
                    a separate RFC with an LCS MIB for MCM lines?

    o SCM Specific:
            - vdslLineSCMConfProfileTable
            - vdslLineSCMConfProfileTxBandTable

            - TR-057 does not address line-code-specific (LCS) elements.
            ** Propose moving to a separate line-code-specific MIB Group/Sub-tree
               (similar to what was done for ADSL MIB - RFC 2662)
            [Felix] I agree.  Is IETF's adslmib working group then preparing
                    a separate RFC with an LCS MIB for SCM lines?

            - TR-057 supports configuration of Ham Band Masks (standard + custom)
            ** Suggest moving vdslSCMConfProfileTransmitPSDMask and Notch
               parameters to the common vdslLineConfProfileTable since PSD Masks are applicable
               to both MCM/SCM.  Also suggest renaming as follows:
                    - vdslSCMConfProfileTransmitPSDMask     -> vdslLineConfHamBandMask
                    - vdslSCMConfProfileVendorNotch1Start   -> vdlsLineConfCustomNotch1Start
                        ...
               (Note: The notches are not 'vendor-specific' but region/operator-specific.)
            [Felix] TR-057 refers to four standard HAM bands only since it assumes (according
                    to G.993.1) that the VDSL spectrum ends at 12 MHz.  But ANSI T1.424 and ETSI
                    TS 101 270 go as far as 30 MHz and therefore have additional five HAM bands
                    (see normative Annex 1 of T1.424-1 and Section 9.3.3.6.1 of TS 101 270-1).
                    Also, one should just number the HAM bands, i.e. hamBand1 instead of
                    amateurBand30m, hamBand2 instead of amateurBand40m, etc., and I would prefer
                    to start the bit assignment of vdslLineConfHamBandMask with the HAM bands,
                    i.e. hamBand1(0), ..., hamBand4(3), [hamBand5(4), ..., hamBand9(8),]
                    customNotch1(9), customNotch2(10).  One could then easily add additional
                    notches at the end when needed.

    o PM:
            - DSLF has LOLS included - not in IETF.
            ** LOLS were included in ADSL MIB - RFC 2662.  Suggest including for consistency.

            - IETF has "Uncorrected Blocks" DSLF has "Uncorrectable Blocks"
            ** I believe the same thing is implied.  "Uncorrectable" seems to better reflect the
               situation since it excludes corrected-blocks.

-----------------------------------------------------------------------------------
 <<vdsl-mib-update.doc>>