Skip to content
DataMiner DoJo

More results...

Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors
Search in posts
Search in pages
Search in posts
Search in pages
Log in
Menu
  • Blog
  • Questions
  • Learning
    • E-learning Courses
    • Open Classroom Training
    • Certification
      • DataMiner Fundamentals
      • DataMiner Configurator
      • DataMiner Automation
      • Scripts & Connectors Developer: HTTP Basics
      • Scripts & Connectors Developer: SNMP Basics
      • Visual Overview – Level 1
      • Verify a certificate
    • Tutorials
    • Video Library
    • Books We Like
    • >> Go to DataMiner Docs
  • Expert Center
    • Solutions & Use Cases
      • Solutions
      • Use Case Library
    • Markets & Industries
      • Media production
      • Government & defense
      • Content distribution
      • Service providers
      • Partners
      • OSS/BSS
    • DataMiner Insights
      • Security
      • Integration Studio
      • System Architecture
      • DataMiner Releases & Updates
      • DataMiner Apps
    • Agile
      • Agile Webspace
      • Everything Agile
        • The Agile Manifesto
        • Best Practices
        • Retro Recipes
      • Methodologies
        • The Scrum Framework
        • Kanban
        • Extreme Programming
      • Roles
        • The Product Owner
        • The Agile Coach
        • The Quality & UX Coach (QX)
    • DataMiner DevOps Professional Program
  • Downloads
  • More
    • Feature Suggestions
    • Climb the leaderboard!
    • Swag Shop
    • Contact
      • General Inquiries
      • DataMiner DevOps Support
      • Commercial Requests
    • Global Feedback Survey
  • PARTNERS
    • All Partners
    • Technology Partners
    • Strategic Partner Program
    • Deal Registration
  • >> Go to dataminer.services

Same device: different element types – what to choose?

Solved1.56K views9th December 2021Nevion VIRTUOSO NX4600 protocols TNS4200
1
Alberto De Luca [DevOps Enabler]4.58K 9th November 2021 0 Comments

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.

Srikanth Mandava [SLC] [DevOps Member] Answered question 16th November 2021

2 Answers

  • Active
  • Voted
  • Newest
  • Oldest
1
Srikanth Mandava [SLC] [DevOps Member]912 Posted 16th November 2021 0 Comments

Some essential background information before we tackle your questions. Details of the Nevion products you mentioned from what we understand.

TNS4200 https://nevion.com/wp-content/uploads/2015/11/Nevion_TNS4200_data_sheet_R1730-1.pdf
NX4600 https://nevion.com/wp-content/uploads/2015/11/Nevion_NX4600_data_sheet_R2107.pdf
Virtuoso Platform https://nevion.com/wp-content/uploads/2016/08/Nevion_Virtuoso_Platform_R2051.pdf

Below is the summary status of our protocols from the catalog (courtesy of DataMiner services)

NX4600 https://catalog.dataminer.services/result/driver/4250 since 2016, firmware version supporting up to 2.8.3, last change 2021
TNS4200 https://catalog.dataminer.services/result/driver/3366 since 2015, firmware version supporting up to 2.0.0.7, last change 2019
Virtuoso MI https://catalog.dataminer.services/result/driver/6708 since 2020, firmware version supporting up to 1.2.14, last change 2021

These are all different product offerings from Nevion; hence Skyline provides separate drivers for these products. Maybe the underlying API interface and technology are the same. As Skyline provides the drivers catering different
customer needs, we have developed the features customers requested rather than unifying the features in all drivers.

Short Term:
As detailed in the old thread, Skyline doesn't provide the driver for Virtuoso FA driver. We can develop a new driver based on the requirements you have. Features are added as the customer's request for the TNS4200 and NX4600 drivers; hence they are not consistent. These protocols may be working for you, but they are not designed in the way they are currently getting utilised.

Mid Term:
Our understanding is that Virtuoso FA, NX4600 are separate devices and offerings; it would be great to collaborate with you and Nevion to understand the rebranding part of the devices. Virtuoso MI driver is also designed to support
the newer virtual platform, which has many media functions, so we do see a possibility to merge media functions into this driver. Whether that would be DVE's or some other mechanism will depend on the features users are requesting.

Long Term:
We need to work with the users and Nevion to streamline some of these services and clarify future development.

Srikanth Mandava [SLC] [DevOps Member] Answered question 16th November 2021
1
Rene De Posada [SLC] [DevOps Advocate]1.89K Posted 12th November 2021 1 Comment

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,

Rene De Posada [SLC] [DevOps Advocate] Answered question 12th November 2021
Alberto De Luca commented 15th November 2021

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/

Please login to be able to comment or post an answer.

My DevOps rank

DevOps Members get more insights on their profile page.

My user earnings

0 Dojo credits

Spend your credits in our swag shop.

0 Reputation points

Boost your reputation, climb the leaderboard.

Promo banner DataMiner DevOps Professiona Program
DataMiner Integration Studio (DIS)
Empower Katas

Recent questions

Alarm Dashboard PDF/CSV Export 0 Answers | 0 Votes
Is the Microsoft SharePoint Connector Still Usable 0 Answers | 0 Votes
Is the Microsoft SharePoint Connector Still Usable 0 Answers | 0 Votes

Question Tags

adl2099 (115) alarm (62) Alarm Console (82) alarms (100) alarm template (83) Automation (223) automation scipt (111) Automation script (167) backup (71) Cassandra (180) Connector (108) Correlation (68) Cube (150) Dashboard (194) Dashboards (188) database (83) DataMiner Cube (57) DIS (81) DMS (71) DOM (139) driver (65) DVE (55) Elastic (83) Elasticsearch (115) elements (80) Failover (104) GQI (159) HTTP (76) IDP (74) LCA (151) low code app (166) low code apps (93) lowcodeapps (75) MySQL (53) protocol (203) QAction (83) security (88) services (51) SNMP (86) SRM (337) table (54) trending (87) upgrade (62) Visio (539) Visual Overview (345)
Privacy Policy • Terms & Conditions • Contact

© 2025 Skyline Communications. All rights reserved.

DOJO Q&A widget

Can't find what you need?

? Explore the Q&A DataMiner Docs

[ Placeholder content for popup link ] WordPress Download Manager - Best Download Management Plugin