Re: [Adslmib] Vector of Profiles MIB

[Menachem Dodge <[e-mail]>]

Hello, 

So far only a small number of WG members have offered their opinion as to whether or not the TR-165 management model should be developed.

A suggestion has been proposed such that an optional extension to RFC 5650 be developed that would contain a switch allowing either the current TR-129 model or the TR-165 model to be supported.

The opinions thus far have been divided, even regarding this optional extension.

I would appreciate additional members of the WG to come forward and voice their view.

Thank you kindly,
Menachem Dodge



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Tuesday, November 17, 2009 11:05 AM
To: [e-mail]
Cc: Menachem Dodge; [e-mail]; [e-mail]; Moti Morgenstern; [e-mail]; [e-mail]
Subject: AW: Vector of Profiles MIB

Hello Scott,

I understand your proposal but it does not address the complete issue. 
Operators need more flexibility of configuring their network. The approach of TR-129 does not scale from the OSS point view as it multiplies the amount of different xDSL profiles/templates. In practice, the MIB from the DSLAM (In this case represeting the TR-129 object model) is usually mapped 1:1 into the EMS and its data model. In FTTx deployment scenarios with specific requirements depending on the PSD shaping on the remote DSLAM, noise margins, specific OLR features and INP configurations, TR-129 causes a multiplication of templates as every single parameter variation ends up in a new template and/or channel or line profile.

Therefore TR-165 needs to be implemented at the SNMP management interface and in the associated EMS to take full effect.

Be aware that only the profile configurtion of RFC5650 is affected, all other parts are untouched and can stay as they are today. In order to not skip the template approach from TR-129 completely, a switch, as proposed by Peidaoyu from Huawei, might be a good solution.

Regards
Markus

    
-----Ursprüngliche Nachricht-----
Von: Scott Baillie [mailto:[e-mail]] 
Gesendet: Sonntag, 15. November 2009 13:00
An: Menachem Dodge; [e-mail]; [e-mail]; Moti Morgenstern; Freudenberger, Markus; [e-mail]; [e-mail]
Betreff: Re: Vector of Profiles MIB

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.