Re: [Adslmib] Vector of Profiles MIB

[Scott Baillie <[e-mail]>]

Hi all,

As you may know from my previous messages on the subject
of the Vector of Profiles MIB proposal, I do not believe
that it is a good idea to introduce another VDSL2 management
interface which is not compatible with the existing management
interface ( RFC5650 ) unless there are compelling and
significant reasons to do so.

Introducing an incompatible VDSL2 management interface
does not benefit the xDSL industry, it causes harm
because NMS/EMS applications will now have to support
two interfaces instead of one.

I consider the Vector of Profiles scheme to be an
implementation decision which should be considered
by firmware developers in order to minimise the storage
requirements for xDSL configuration in the Access Node.
But this implementation decision is a low level detail
and should not affect the VDSL2 management interface.

A firmware developer can implement the VoP scheme
inside the Access Node while remaining 100% compatible
with the RFC5650 management interface. What is
required is to provide a mapping between the template
name and the vector, and this mapping can be kept
hidden so that the operator has no knowledge of
the internal implementation details.

Let me state my proposal in a different way in case
what I said was not very clear.

1. Internally, the xDSL configuration is stored using
   the efficient VoP scheme.
2. In the firmware, a mapping exists between the RFC5650
   template name and the internal vector that stores the
   configuration for that template. This mapping may take
   the form of a hash map for example.
3. When a SNMP request arrives to read a row from the
   line profile or channel profile tables
   ( xdsl2LineConfProfTable,
     xdsl2LineConfProfModeSpecTable
     xdsl2LineConfProfModeSpecBandUsTable,
     xdsl2ChConfProfileTable )
   the access node will consult its hash map and find
   the corresponding vector. The access node will then
   retrieve the data from the vector and return it in
   the form of a SNMP row.
   What this means is that storage of the xDSL
   configuration data is decoupled from the MIB
   representation of the data. Most modern SNMP agent's
   ( such as the Net SNMP agent ) supports decoupling
   of the underlying storage as I have described.
4. When a SNMP request arrives to write a row into
   the line profile or channel profile tables, the
   access node must either create a new vector to
   store the data of reference an existing vector
   which already contains that data.

Using this approach, the access node gains the
advantage of storing the xDSL configuration data 
efficiently while remaining compatible with the
existing SNMP management interface.

The algorithm that I have described above would
need to be specified in more detail, but I am
sure that every one here is an engineer and at least
understands the concept that I am proposing.

In conclusion, I think that the broad band forum
should create a companion document that goes together
with TR165 which specifies an algorithm ( similar
to what I have proposed above ) that firmware
developers can use to map between 5650 templates
and VoP vectors instead of specifying a new VDSL2
management interface at the IETF.

Regards,

Scott.