Hi Dojo,
Long story short: I have the same device type that has been integrated in two different DMS clusters with two different protocols - I've sent a few questions around, via private channels, and apparently there isn't any good or wrong choice: it seems to just sit with the history of the different DMS clusters and protocols, and with different requirements at different moments - so I’m just posting here now, hoping the community can pull together some answers I’m looking for, scenario by scenario.
Short-term
Having 2 protocols for the same device is not an issue at present, yet our engineering teams (and different deploy squads) need to detail different procedures for different protocols (no mediation layer), at times for the same action via CUBE (e.g. retrieving the trend of the output bitrate), as the element tables have different names and are implemented with a slightly different logic, so even the alarm and trend templates can be quite different.
What are my options now that I've noticed this?
Besides, when updating a protocol to cope with a newer software release of the device, in which integration are we adding new features?
In this specific case, both are SL drivers with a recent release:
-----------------------
-----------------------
Mid-Term
For more context, I'm talking about the VIRTUOSO FA media node: historically, this was a rebrand of the NX4600 unit, that later evolved into a newer appliance running different media accelerators (see Thomas' feedback here), but also still able to offer all the software-defined redundancy switches that were previously running in the NX4600 models.
Apparently, when the manufacturer released the newer series of appliances, API compatibility was preserved, so that the DataMiner protocol for TNS4200 probes could also be used for Virtuoso FA nodes: the TNS4200 is indeed what's used in the second cluster (Element Type “Analyzer”), vs the NX4600 protocol in the first DataMiner System (Element type “Video Gateway”).
Adding some visual reference in the following picture:
----------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------
From a commercial point of view, both protocols were bought for different devices in the first cluster, so I guess both seemed a viable option for the implementation at the time of the deployment in the second DMS. For simplicity, I’m omitting details about our VIRTUOSO MI units, as these are present only in the second cluster and have their own protocol, as shown above.
We're evaluating new DVEs and we have to build service templates too, so I'm keen to understand which protocol would best fit our use cases: NX46 or TNS42?
Is there a central log for features available in one protocol that are not implemented in the other?
Is switching and seamless switching supported in both protocols as long as it's licensed on the device? Can both protocols be used also for control purposes? If not, what parameter can be used in TNS42 to trend which input feed is selected as the output of the redundancy switch?
Long-Term
Alternatively, should we just consider a "North-bound" integration with the iPath manager, where this is viable? Or could the SL drivers evolve into some sort of “General Virtuoso Platform” that can export different Child Elements, depending on the equipment that is polled? In case some bookings have to be added later on, what's the current state of virtual functions with the current protocols?
EDIT: SONY/Nevion and Skyline are both AMWA members - so it might be worth considering the long term scenario in the context of NMOS (IS06).
Thanks,
A.
Alberto,
The situation you explain is very common for connectors that target a specific product line. The bottom line is that as vendors evolve their offerings, APIs, MIBs, etc., also evolve to accommodate for new features.
Oftentimes, a connector that was developed for an older product continues to work overtime with the newer flavors of the product. This is because vendors typically keep backwards compatibility of their interfaces. Having said this, if the interface changes dramatically to a point where an existing connector can no longer meet monitoring requirements or if simply too many new features are added, a new range of the connector or a complete different one is developed in order to integrate the new capabilities.
My advice here is that you keep runing the elements with the current connectors given that they provide you with the necessary monitoring capabilities. If you need to decide which connector to use in future deployments, I'd advise to use the connector targeting the latest product, following the same requirement-based criteria.
When it comes to adding elements to services, you could use two types of templates for the various connector ranges.
Thank you,
Thanks for your insight, Rene
I had thought the same – just trying to understand which connector is targeting the latest product in this case.
So, given that NX46 is no longer exisisting as a product, what’s the strategy around SL protocols for VIRTUOSO FA vs VIRTUOSO MI?
Can the “Virtuso MI” protocol be used for both FA & MI?
My understanding is that the REST API has got the same structure, yet the MI can export up to 8 media accelarators rather than just 4 (for the FA).
I seem to recall that the MI appliance can also allow to manage each different accelarator with a different polling IP, but where DVEs are available this might be not necessary.
In this case, having DVEs for the “redundancy swith” function is something that would be useful for both the newer connector and for the original protocol, as this important separation was not considered as an acceptance requirement for the previous integration.
More details about the DVE function for these media nodes is in:
https://community.dataminer.services/question/dve-creation-for-protocols-when-how-can-we-determine-if-a-protocol-needs-this-feature/