Subject: Re: [Adslmib] Re: DSL Forum TR57 approved - "VDSL Network Element Management Requirement"

From: [email-masked]
Date: Sun, 2 Mar 2003 11:22:13 +0200

Hi Rajesh and all,

Basically I think we're in a good position as the number of remaining
differences between the DSLF and IETF model is not so high.

One comment (and a proposal) is anyhow required.

While creating the MIB, which was the basis for rfc2662, the DSLF invested
efforts in order to ensure that the MIB enables configuring links of both
ADSL line codes. The fact is that there's no line-code specific MIB,
because no one really needs it (except for, say, retrieving the SNR margin
per bin).

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.

Best regards,
Moti Morgenstern

Senior System Engineer
ECI Telecoms Ltd.
Inovia Broadband Access Division
30 Hasivim St.
Petach Tikva, Israel 49133
Tel.: +972-3-9266258
Fax: +972-3-9268182
Cell: +972-55-786258
e-mail: [email-masked]
www.ecitele.com

                      Rajesh Abbi                                                                                                      
                      <Rajesh.Abbi@            To:      [email-masked], [email-masked], [email-masked], Bob Ray      
                      alcatel.com>             <[email-masked]>                                                                         
                      Sent by:                 cc:                                                                                     
                      adslmib-admin@           Subject: [Adslmib] Re: DSL Forum TR57 approved -  "VDSL Network Element Management      
                      ietf.org                 Requirement"                                                                            

                      27/02/03 19:00                                                                                                   

Hi Greg and All,

I have compared DSL Forum's TR-057 with the current IETF VDSL MIB draft
(draft-ietf-adslmib-vdsl-07.txt) and compiled a list of differences.  The
list
is included below along with my proposals for updates to the IETF draft for
better
alignment between the two specifications.

Regards,

Rajesh

-----------------------------------------------------------------------------------

 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.

    - vdslPhysTable:
            - IETF: has Current Channel Rates only
            - DSLF: has Current Line Rates only
              ** Propose to add Curr Line Rate to vdslPhysTable

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

    - 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.
                * DSLF want's explicit configuration of 'Rate Selection
Mode'
                  Suggest adding this.
                * '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".

    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.

    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)

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

    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.

-----------------------------------------------------------------------------------

[email-masked] wrote:

> From: Gavin Young, DSL Forum Technical Committee Chair
> To: Mike Sneed, IETF ADSLMIB Chair
> Subject: Communication regarding VDSL network element management.
>
> The DSL Forum would like to continue to work with the IETF to develop a
comprehensive set of management specifications for VDSL.  In this plan, the
DSL Forum has documented and approved a set of objects for VDSL management
(TR-57) for incorporation into your VDSL Management Internet Draft.
>
> Sincerely,
> Gavin Young
> DSL Forum Technical Chair
>
> Cc:
> Greg Bathrick, DSL Forum to IETF Liaison
> Peter Adams, DSL Forum Ops and Net Mgt WG Co-Chairman
> Greg Bathrick, DSL Forum Ops and Net Mgt WG Co-Chairman
>
> Attachment:
> DSL Forum TR-057 - VDSL Network Element Management
>
>
----------------------------------------------------------------------------------------------------

>                     Name: TR-057.pdf
>    TR-057.pdf       Type: Portable Document Format (application/pdf)
>                 Encoding: base64
>              Description: TR-057.pdf

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

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