Subject: [Adslmib] VDSL MIB proposed updates

From: "Bob Ray" <[email-masked]>
Date: 12 Jun 2002 17:46:46 -0000

Hi.  I've received email from various people about the next VDSL MIB update.
Summarized below are the changes I've begun making, updated draft to be
submitted before the Yokohama cutoff date.  Most of these are based upon
suggestions from Randy Presuhn, Moti Morgenstern and Rajesh Abbi.

Speak up if you agree or disagree with any of these...

Regards,
Bob Ray

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

Proposed VDSL MIB updates

1.  Add a comment into the MIB to state that when implementing SCM, the 
minimum and 

the maximum data rates is the same.

2.  Add references to ETSI and ITU standards (in addition to ANSI 
standards).

3.  Add objects for 24 hour performance monitoring (as done with ADSL and 

HDSL2/SHDSL).

4.  Specify LOF defect as a source for Errored Seconds (ES) (in addition to 
LOS).

5.  Change line attenuation and SNR Margin to use units of 0.25dB. 

6.  Add objects to count Severely Errored Seconds (SES) and Unavailable 
Seconds (UAS) 

as performed in ADSL and SDSL.

7.  Add a table, vdslLinkConfProfileTable, with the objects below, indexed 
by 

vdslLineConfProfileIndex.

	vdslLinkConfDownstreamTxSpeed OBJECT-TYPE
		SYNTAX       INTEGER 
		UNITS        "bits per second"
		MAX-ACCESS   read-create
		STATUS       current
		DESCRIPTION
		"Downstream transmit speed for this link."
		::= { vdslLinkConfProfileEntry xxxx }

	vdslLinkConfUpstreamTxSpeed OBJECT-TYPE
		SYNTAX       INTEGER 
		UNITS        "bits per second"
		MAX-ACCESS   read-create
		STATUS       current
		DESCRIPTION
		"Upstream transmit speed for this link."
		::= { vdslLinkConfProfileEntry xxxx }

	vdslLinkConfDeploymentScenario OBJECT-TYPE 
		SYNTAX  INTEGER { 
			fttCab(1), 
			fttEx(2)
		} 
		MAX-ACCESS  read-create
		STATUS  current 
		DESCRIPTION 
		"The VDSL link deployment scenario. When using 
		'FttCab' scenario, the VTU-C is located at a 
		street cabinet. When using 'FttEx' scenario, 
		the VTU-C is located at the central office." 
	::= { vdslLinkConfProfileEntry xxxx } 

	vdslLinkConfAdslOccuopy OBJECT-TYPE 
		SYNTAX  TruthValue
		MAX-ACCESS  read-write 
		STATUS  current 
		DESCRIPTION 
		"May the VDSL occupy the ADSL frequency range." 
	::= { vdslLinkConfProfileEntry xxxx }

	vdslLinkConfApplicStandard OBJECT-TYPE 
		SYNTAX  INTEGER { 
			ansi(1), 
			etsi(2), 
			itu(3)
		} 
		MAX-ACCESS  read-create
		STATUS  current 
		DESCRIPTION 
		"The VDSL standard to be used for the respective line." 
	::= { vdslLinkConfProfileEntry xxxx }

	vdslLinkConfBandPlan OBJECT-TYPE 
		SYNTAX  INTEGER { 
			ansi(1),
			bandPlan997(2), 
			bandPlan998(3), 
			bandPlanFx(4)
		} 
		MAX-ACCESS  read-create
		STATUS  current 
		DESCRIPTION 
			"The VDSL Band Plan.” 
	::= { vdslLinkConfProfileEntry xxxx }

	// and row-status

8.  Add an object to vdslLineConfProfileTable:

    vdslLineConfPsdTemplate OBJECT-TYPE 
          SYNTAX  INTEGER { 
                     templateMask1(1), 
                     templateMask2(2)
                 } 
          MAX-ACCESS  read-create
          STATUS  current 
          DESCRIPTION 
            "The transmit PSD template for the respective unit." 
          ::= { vdslLineConfProfileEntry xxxx } 

9.  Remove the Tx and Rx Speed objects from the VdslLineConfProfileEntry.

10. Any suggestions for specifying Upstream Power Back Off (UPBO) control???
(just in case ANYONE reads this far)

11. Add an object to vdslLineSCMConfProfileTable to specify the number of 
bands used 

by the VTU transmitter:

	vdslLineSCMConfBands OBJECT-TYPE 
		SYNTAX  INTEGER { 
			SingleBand(1), 
			TwoBands(2)
		} 
		MAX-ACCESS  read-write 
		STATUS  current 
		DESCRIPTION 
		"Number of bands on Tx direction." 
		::= { vdslLineSCMConfProfileEntry xxxx } 

12. Add a new table, vdslLineSCMConfProfileTxBandTable, indexed by
{ vdslLineConfProfileIndex, vdslPhysSide, vdslSCMConfProfileTxBandNumber}
with the following objects:

	vdslSCMConfProfileTxBandNumber OBJECT-TYPE
		SYNTAX	INTEGER {
                     band1(1), 
                     band2(2)
		} 
		MAX-ACCESS  read-create
		STATUS  current 
		DESCRIPTION 
			"The SCN transmit band number for this entry."
		::= { vdslLineSCMConfProfileTxBandEntry xxxx } 

	vdslSCMConfProfileTxBandTransmitPSDLevel OBJECT-TYPE
		SYNTAX       INTEGER
		UNITS        "dBm/Hz"
		MAX-ACCESS   read-create
		STATUS       current
		DESCRIPTION
			"The transmit power spectral density for the VDSL 
modem."
		REFERENCE    "T1E1.4/2000-011R3"    -- Part 2, SCM
		::= { vdslLineSCMConfProfileTxBandEntry xxxx  }

	vdslSCMConfProfileTxBandSymbolRateProfile OBJECT-TYPE
		SYNTAX       INTEGER
		UNITS        "kbaud"
		MAX-ACCESS   read-create
		STATUS       current
		DESCRIPTION
			"The symbol rate profile calculated as S = SR/BSR, 
where
			SR is the required symbol rate in kbaud, BSR  = 
67.5."
		REFERENCE    "T1E1.4/2000-011R3"    -- Part 2, SCM
		::= { vdslLineSCMConfProfileTxBandEntry xxxx }

	vdslSCMConfProfileTxBandConstellationSize OBJECT-TYPE
		SYNTAX       INTEGER(0..15)
		UNITS        "log2"
		MAX-ACCESS   read-create
		STATUS       current
		DESCRIPTION
			"Specifies the constellation size."
		REFERENCE    "T1E1.4/2000-011R3"    -- Part 2, SCM
		::= { vdslLineSCMConfProfileTxBandEntry xxxx }

	vdslSCMConfProfileTxBandCenterFrequency OBJECT-TYPE
		SYNTAX       INTEGER(0..511)
		UNITS        "kHz"
		MAX-ACCESS   read-create
		STATUS       current
		DESCRIPTION
		"Specifies the center frequency profile K."
		REFERENCE    "T1E1.4/2000-011R3"    -- Part 2, SCM
		::= { vdslLineSCMConfProfileTxBandEntry xxxx  }

13.  Remove the following objects from vdslLineSCMConfProfileTable:

	vdslLineSCMConfProfileTransmitPSDLevel,
	vdslLineSCMConfProfileSymbolRateProfile,
	vdslLineSCMConfProfileConstellationSize, 
	vdslLineSCMConfProfileCenterFrequency

14.  Add the following object to vdslLineSCMConfProfileTable

	vdslLineSCMConfProfileFastFecSize OBJECT-TYPE 
		SYNTAX  INTEGER { 
			noFEC(1),
			fecSize2(2),
			fecSize4(3),
			fecSize16(4)
		}
		MAX-ACCESS  read-write 
		STATUS  current 
		DESCRIPTION 
			"When fast channel is being used, this object 
specifies 
			the size of FEC in the codeword." 
          ::= { vdslLineSCMConfProfileEntry xxxx } 

15.  Add a new table, vdslSCMPhysBandTable, indexed by
	{ IfIndex, vdslPhysSide, vdslSCMTxBandNumber }
    with the following objects:

	vdslSCMTxBandNumber OBJECT-TYPE
		SYNTAX	INTEGER {
                     band1(1), 
                     band2(2)
		} 
		MAX-ACCESS  read-only
		STATUS  current 
		DESCRIPTION 
			"The SCN transmit band number for this entry."
		::= { vdslSCMPhysBandEntry xxxx } 

	vdslSCMPhysBandSnrMgn OBJECT-TYPE 
		SYNTAX  INTEGER {-127..127) 
		UNITS      “0.25 dB” 
		MAX-ACCESS  read-only 
		STATUS  current 
		DESCRIPTION 
		"Noise margin as seen by this Vtu and band with respect 
		to its received signal in 0.25 dB." 
		::= { vdslSCMPhysBandEntry xxxx } 

	vdslSCMPhysBandAtn OBJECT-TYPE 
		SYNTAX  INTEGER {0..255) 
		UNITS      “0.25 dB” 
		MAX-ACCESS  read-only 
		STATUS  current 
		DESCRIPTION 
		"Measured difference in the total power transmitted by the 
peer
		Vtu on this band and the total power received by this Vtu 
on this 
		band in 0.25 dB." 
		::= { vdslSCMPhysBandEntry xxxx } 

16.  Fix double reference in paragraph 4.3.

17.  Fix description of vendor ID and version number (remove references to
     "Phy[10]").

18.  Rewrite paragraph 4.6 to reflect the following:

	"In paragraph 4.6 of the MIB the reader may, by mistake, understand 
that
	there is a threshold-crossing event for the LOL defect (which is 
not a
	formal VDSL defect). The paragraph should be modified to reflect 
the 
	actual PM counters"

19.  Add the following to the references section (and refer to these in
     the object definitions):

	[x]	ANSI T1E1.4/2001-311 “Very-high-bit-rate Digital Subscriber 
Line 
		(VDSL) Metallic Interface, Part 1: Functional Requirements 
and 
		Common Specification”, February 2001
	[x]	ANSI T1E1.4/2001-011R3 “VDSL Technical Specification, Part 
2: 
		Technical Specification for a Single-Carrier Modulation 
(SCM) 
		Transceiver”, November 2001
	[x]	ETSI TS 101 270-1 V1.2.1 “Transmission and Multiplexing 
(TM); Access 
		transmission systems on metallic access cables; Very high 
speed 
		Digital Subscriber Line (VDSL); Part 1: Functional 
requirements” , 
		October 1999
	[x]	ETSI TS 101 270-2 V1.1.1 “Transmission and Multiplexing 
(TM); Access 
		transmission systems on metallic access cables; Very high 
speed 
		Digital Subscriber Line (VDSL); Part 1: Transceiver 
specification” , 
		February 2001
	[x]	ITU-T G.993.1 “Very-high-speed digital subscriber line 
foundation” 
		(11/2001) 

20.  Change the contact information for one of the authors to reflect his 
new
     employer (!)

21.  Add Integer32 to the IMPORTS list

22.  Fix index definition of vdslLineConfProfileTable...

23.  Fix the DESCRIPTION of vdslLineMCMConfProfileMaxTxPSDEntry

24.  Fix Reference [22] (should have an "and" in place of the comma after 
the "G.")

25.  Fix other references to use current fashion espoused by
     <draft-rfc-editor-rfc2223bis-02.txt>.

26.  In section 1, strike the words "portion of the".

27.  Fix section 3.1 such that it suggests transmission tree instead of 
snmpModules
     subtree.

28.  Fix section 4.1, fix item "T" (problem repeated on page 11)

29.  Rewrite section 4.3 to reflect the following (brilliant) observation:

	In describing the tables in the various groups in section 4.3,
	it might be helpful to separate them into those that are only
	permitted for ifType vdsl(97), i.e.,

       - vdslLineTable 
       - vdslPhysTable 
       - vdslPerfDataTable
       - vdslPerfIntervalTable
       - vdslLineConfProfileTable
       - vdslLineAlarmConfProfileTable 

	and those that are only permitted for ifTypes 124 and 125:

       - vdslChanTable 
       - vdslChanPerfDataTable
       - vdslChanPerfIntervalTable

	A diagram showing the relationships would be *really* nice.
	I *think* the document is saying this about the vdslGroup:

		        1:(0..1)       1:(0..2)       1:1           1:n
	ifEntry --------> Line --------> Phys ---> PerfData ---> 
PerfInterval
	
        		               N:(0..1)
	                       --------> ConfProfile

		                       N:(0..1)
	                       --------> AlarmConfProfile

		        1:(0..2)       1:1               1:n
	ifEntry --------> Chan ---> ChanPerfData ----> ChanPerfInterval

30.  Extend description of vdslLineConfProfile to:

	"be a lot clearer about its relationship to
       - vdslLineMCMConfProfileTable 
       - vdslLineMCMConfProfileTxBandTable
       - vdslLineMCMConfProfileRxBandTable
       - vdslLineMCMConfProfileTxPSDTable 
       - vdslLineMCMConfProfileMaxTxPSDTable 
       - vdslLineMCMConfProfileMaxRxPSDTable 
       as well as 
       - vdslLineSCMConfProfileTable

	On first glance, it looked like it was meant just for
	vdslLineConfProfileTable, rather than the entire crew of
	tables.  In any case, it would be helpful to figure out
	what it means for vdslLineConfProfile to refer to a 
	non-existant or incomplete profile."

	Hopefully.

31.  page 27, change "the system will always provide a default" to
     "the system MUSTprovide a default"

32.  Explicitly identify all objects that must survive reboots.

33.  Attempt to achieve closer alignment in the security considerations 
     section with http://www.ops.ietf.org/security.html.

34.  Attempt to add "a few words about access control and this MIB's 
notifications"
     concerning "information revealed by notifications on the wire."

This should keep me busy for a while :))))

Regards,
Bob Ray

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

---

From: [email-masked]
Date: Thu, 13 Jun 2002 10:04:00 +0300

Hi Bob,

I wish to add the following, mainly based on DSLF discussion in Chicago:

In the new vdslLinkConfProfileTable we should also have an object for band
U0. I suggest the following syntax:
             vdslLinkConfBandU0Usage OBJECT-TYPE
                         SYNTAX  INTEGER {
                                     Unused(1),
                                     Upstream(2),
                                     Downstream(3)
                         }
                         MAX-ACCESS  read-create
                         STATUS  current
                         DESCRIPTION
                         "Defines whether or not the VDSL link uses the
                          frequency range [25Khz-138Khz] and does it serve
                          for upstream or downstream traffic."
             ::= { vdslLinkConfProfileEntry xxxx }

When U0 is being used for downstream then D1 band is simply wider. However,
when it is being used for upstream, it is possible to serve as a 3rd
upstream band. Hence, there is an influence on the number of entries to the
SCM specific vdslLineSCMConfProfileTable (item 11 in your mail). The
correct specification should be:
             vdslSCMConfProfileTxBandNumber OBJECT-TYPE
                         SYNTAX            INTEGER {
                     band1(1),
                     band2(2),
                     UpstreamU0(3)
                         }
                         MAX-ACCESS  read-create
                         STATUS  current
                         DESCRIPTION
                                     "The SCM transmit band number for this
entry."
                         ::= { vdslLineSCMConfProfileTxBandEntry xxxx }

The same applies for vdslSCMTxBandNumber object in vdslSCMPhysBandTable.

When the profile defines 'bandPlanFx', it should also define the limit
between bands D2 and U2.
             vdslLinkConfBandPlanFx OBJECT-TYPE
                         SYNTAX       INTEGER
                         UNITS        "Khz"
                         MAX-ACCESS   read-create
                         STATUS       current
                         DESCRIPTION
                         "The frequency limit between bands D2 and U2 when
                          vdslLinkConfBandPlan is set to 'bandPlanFx'."
                         ::= { vdslLinkConfProfileEntry xxxx }

By the Way, the value 'ansi' for vdslLinkConfBandPlan means the same as
'bandPlan998'!!!!

We agreed that having separate Row Status object per each table that
belongs to the profile may lead to problems. An alternative approach, to
have a single Row Status object in one of the (common) tables that controls
all components of the profile, was proposed.

I'm in favor of adding PBO Control object (yes, I read even beyond item
10). I also believe this can be added to a per unit table and be called
xxxxPboControl. This will allow supporting Downstream PBO in the future,
while setting the Downstream PBO by default to 'Disable' until then.

The units of vdslSCMConfProfileTxBandTransmitPSDLevel should be "-dBm/Hz"
rather than "dBm/Hz" in order to use positive object values.

The range of vdslSCMConfProfileTxBandConstellationSize is 0..8 rather than
0..15

The units of vdslSCMConfProfileTxBandCenterFrequency should be "33.75kHz".

That's all for now,
Moti Morgenstern

Senior System Engineer
Inovia Telecoms Ltd.
Member of the ECI Telecom group
30 Hasivim St.
Petach Tikva, Israel 49133
Tel.: +972-3-9266258 Fax: +972-3-9268182
e-mail: [email-masked]