Subject: [MIB-DOCTORS] The measurement tables in the VDSL2 MIB

From: Scott Baillie <[email-masked]>
Date: Tue, 24 Feb 2009 03:15:10 +1100

Hi All,

There has been some confusion surrounding the measurement
tables in the VDSL2 MIB.
The tables that I am refering to are xdsl2LineSegmentTable and
the SCStatus tables xdsl2SCStatusTable, xdsl2SCStatusBandTable
and xdsl2SCStatusSegmentTable.

I would like to explain the intended purpose of these tables
and how they relate to each other.
After I have explained these tables, I am hoping the WG
will have a better understanding and will help me to
revise the deficencies in the descriptions that have
been pointed out.

SCStatus tables ( xdsl2SCStatus*Table )
---------------------------------------
The SCStatus tables hold the results of a line diagnostic test.
The line diagnostic test is initiated using the
xdsl2LineCmndConfLdsf object.
The XDSL line undergoing the test must first be placed
into the no power state ( L3 state ) prior to initiating
the test.

Dynamic measurement table (xdsl2LineSegmentTable)
-------------------------------------------------
The xdsl2LineSegmentTable holds the results of a
bits-per-subcarrier measurement.
The measurement is initiated using the xdsl2LineCmndConfBpsc
object.
The XDSL line undergoing the measurement must be in
the full power state ( L0 state ) prior to initiating
the test.

Relationship between measurement tables
---------------------------------------
The dynamic measurement table and the SCStatus tables are
independent.
The dynamic measurement is performed when the modems are in
sync ( showtime ) and customer data is being transmitted by
the modems.
The line diagnostic test is performed when the modems are in
no power mode ( L3 ) and no customer data is being transmitted.
These two measurement types are performed at different times
and each measurement type has its own results table and its
own initiation variable.
The thing that is in common with these tables is that both
measurement types will measure the bits-per-subcarrier value
but there is no "overloading" of meaning.

Request Counter (xdsl2LineCmndConfBpscReqCount)
-----------------------------------------------
There have been some question regarding the request
counter and what it is supposed to do so I would like
to explain the purpose of this object.
The purpose of the request counter is to protect the
integrity of the results table ( xdsl2LineSegmentTable )
in the presence of two SNMP managers.
We cannot guarantee that the measurement results can
be fetched atomically because fetching the results may
involve multiple SNMP GET requests ( see below for reason ).
If manager 1 fetches the results using multiple GET
requests then manager 2 can issue a SET request in the
middle of the GET requests.
The implication of this is that manager 1 has no guarantee
that the results fetched using multiple GET requests
belong to the same measurement event.
The request counter solves this problem by giving the
manager a guarantee that no new measurements were
initiated while reading back the measurement results.
The request counter starts at zero and counts up by one
every time a measurement request is initiated,
eventually it overflows to zero and then continues
counting up.

Multiple PDU's are required to fetch the results
------------------------------------------------
The results from the measurement can be very large
and dont fit into a single SNMP PDU. Given that
the MTU for ethernet is 1500, we have ensured that
no single MIB object is larger than 1024 octets.
Note that the measurement tables all have a 'segment'
index which allow the MIB to store data objects
that are larger than 1024 octets.

Any comments or suggestions would be most helpful
as I am in the process of revising the MIB text.

Regards,

Scott.