From:                              Nursimulu, Khenaidoo <knursimu@ciena.com>

Sent:                               Monday, July 17, 2017 11:56 AM

To:                                   Chidrawar, Niren R. (Nokia - US/Raleigh); Titov, Nikolay (Nokia - US/Raleigh); Kora, Sireesha (Nokia - US/Raleigh)

Cc:                                   Slobodrian, Sergio

Subject:                          Re: Ponsim_ONU device type changed to PSMO

 

Yes, that’s alright.  If later on, we find a use case where it won’t work then we will make the necessary adjustments.

 

Hello Khen

 

Thanks, is it OK to proceed for below solution of 1:1 mapping between device type & vendor_code by extending “DeviceType” message.

 

Niren

 

Niren,

 

There is no check at this time for unique device types.  One should be created – a duplicate device_type should stop Voltha, otherwise, an incorrect adapter could “highjack” a device_type.    Note that the Iadapter code needs to be changed to allow for multiple device_types.

 

Khen

 

Hello Khen

 

I did not look current “core” source code that loads adapters. I hope loader do check device_type to get unique device type with in voltha.

 

Regarding vendor prefer one to one static mapping, as explain below

e.g.

     Adapter         Device Type     Vendor Code

     ===========================================

     nokia_onu       nokia_onu       ALCL

                     bradcomm_onu    BCMM

     ponsim_onu      ponsim_onu      PSMO

 

It means “DeviceType” message definition contains new “vendor_code”. When adapters are loaded; loaders are required to check they are unique in voltha. This iway can keep “vendor_code” inline with with current device_type mechanics.

 

Is that ok?

 

Niren

 

Niren,

 

Vendor_code is a new attribute you are adding, as such there won’t be any existing check for “device_type” with regard to vendor_code.   Since you are extracting the vendor_code during ONU discovery then it would make sense to have a config file per adapter (or a similar mechanism) to explicitly provide a set of vendor_codes it supports.   This way when an adapter is loaded we can guarantee that the vendor code is not used by multiple adapters.

 

Thoughts?

Khen

 

Hello Khen

 

“vendor_code” have to be unique in entire voltha meaning multiple adapters can not use same vendor code for their device types as expected. I hope such a check already exists for “device_type”.

 

Niren

 

Hi Niren,

 

This strategy will work.  Thanks for revisiting it.

 

Khen

 

 

 

Hello Khen

 

Sorry for late reply. I don’t think I need to change OLT device. To keep consistent behavior prefer

• vendor_code : manufacturer code, for ONU follow standard definition of 4 bytes of ASCII
• 1:1 mapping between device_type to vendor_code

 

e.g.

     Adapter         Device Type     Vendor Code

     =======================================

     nokia_onu       nokia_onu       ALCL

                     bradcomm_onu    BCMM

     ponsim_onu      ponsim_onu      PSMO

 

This way can keep your device_type as is without any impact to “persistency”. As explain below single onu adapter can have multiple device types of different manufacturers. It is required to learn ONU capabilities before knowing onu type which has to be completed by onu adapters only. OLT adapters cannot identify ONU type info from ONU serial number.

 

Please let me know I am working on delivering above change; I want to check with you before I deliver the change.

 

Niren

 

Niren,

 

With the strategy of using vendor id to map to an adapter, we are putting a constraint where a vendor can only have one adapter.  I guess for now that’s ok.   Will you be using the same strategy for OLT devices? 

 

Khen

 

Hello Khen

 

Yes we want to use serial number to identify device type / adapter.

 

Regarding multiple versions of devices of same vendor: It has to be handled by single adapter implementation rather multiple implementations. ONU capabilities are part of mibupload process it means ONU adapter has to retrieve these capabilities before taking different actions depending on onu device versions. In order to start learning process over omci ONU should be handled by correct onu adapter. So it is not required to have different implementations of onu adapter for same vendor.

 

Niren

 

Niren,

 

If I understand your explanation correctly then you need to identify a device adapter given a serial number.  Correct?  Using the vendor id as a device type may be ok in this case, although is ambiguous.  How would you tackle the case where different adapters can support the same Vendor id?  For instance, a vendor may have several versions of devices with various capabilities/interfaces and require different adapters to handle them?

 

For now, you can create a “type” field to differentiate between OLT and ONT and make the relevant changes.     Please make sure you run the test_persistence integration test after your change.

 

Khen

 

 

Hello Khen

 

If I revert how do I get the device type associated to “VENDOR ID” from serial number e.g. device type of ALCL? The only way is to hard code ALCL to NOKIA, BCM to Broadcomm. I don’t think that is correct way it requires changing VOLTHA core for introduction of new ONU manufacturer in VOLTHA.

 

When adapters are registered with VOLTHA they use device types that they handle so it would be perfectly fine to use VENDOR ID as device type when adapters are registered e.g. single onu adapter can register for multiple device types like ALCL, BCM. Also listing device types would show device type to VENDOR ID relation.

 

For your concern on identifying olt & onu; we can either define another field “type” or have another way of identifying adapter from VENDOR ID.

 

Niren

 

Thanks, Niren.

 

The extracted vendor id (‘ALCL’ in your example) is a vendor id, not a device type.  When a device is created the adapter knows whether it is an OLT or an ONU.  It should set the type of that device accordingly.   This data is specially required after a voltha restart where device agents need to be re-created in a given order.   Please change the device type.

 

Khen  

 

ALCL