Let us look at why OSS Network discovery systems came into existence, how they evolved over years and in our opinion the areas in which it would play a critical role going forward.
Most Tier-1 and Tier-2 service providers have at some point in time invested in building one or more inventory system which would work as a central repository for functions like Planning, Design, Fulfillment and Assurance. For these functions to have a reliable and up-to-date view of the network, it is important that depth and breadth of information is captured by the inventory. By breadth, I mean the ability to store information from multiple device types from multiple device vendors. And by depth I mean the ability to store physical inventory and also logical inventory for multiple technologies like PDH, SDH/Sonet, DWDM, Ethernet, ATM, FR, IP, MPLS, xDSL, FTTx, 2G, 3G, LTE etc. These Inventories have largely been maintained/updated by manual data entry and in the event of weak process or lack of discipline in following processes; these systems would very quickly go out of synch with the network. And hence OSS Network discovery systems first came into existence in order to help keep inventories up-to-date with the real world. Towards this intent, OSS Discovery systems needed to take care of the following requirements.
1) Data that needs to be acquired from the network
- Ability to perform shallow discovery i.e. discovery of physical fabric (Physical inventory like Racks, Shelves, Cards, Ports) from most leading-class networking equipment vendors based on standards like SNMP Entity Mib-2, TMF 814 etc.
- Ability to discover deep logical information like vlans, ip interfaces, ip subnets etc again using standard mibs (like RFC 2233, RFC 2674), MTNM etc.
- Ability to discover inter-connectivity (PTOPO) between devices wherever possible
2) How data needs to be acquired from the network
- A lot of device vendors equipment cannot be discovered using standard SNMP interfaces and hence the need to be able to discover using other network management protocols like TL1, MML, CMIP, Corba, WebServices.
- Many a times Network operations teams are not comfortable with multiple IT systems (N/EMS, Discovery, Fulfillment, Assurance etc) connecting directly to the devices for multiple reasons like worried about resource consumption on devices which may affect revenue generating traffic and access control list and login configurations on all devices need to be modified for discovery servers to access the device. This may seem like a trivial one time activity, but a few large Tier 1 operators which have strong process in place; this activity can run into a few months.
And hence discovery systems were forced to interface with north bound interfaces of N/EMS systems or gateways in order to perform discovery. These NBI APIs on a lot of occasions end up being propriety or customizations done on standard specifications.
For reasons mentioned above, discovery systems with ability in capturing breadth and depth in discovery have had to build a lot of device vendor specific adaptors instead of standards based adaptors.
“Avinash is a seasoned professional with over 13 years of experience in the Telecommunication B/OSS space. Avinash is a graduate from Illinois Institute of Technology with a masters in Telecommunications and Software engineering. He currently heads Product Management for the Network Analytics suit of Products at Subex. Avinash has experience defining strategy and roadmap for products ranging from products which have been in the market for over a decade to launching a brand new product to the Market. Prior to moving into the Product ownership role, Avinash has played multiple roles within the product engineering, delivery and pre-sales organizations like Product Architect, Solutions Architect, Technical Sales etc. An active member of TM Forum, he is working closely with the Asset Management group of TM Forum in defining business process standards for Asset Management and assurance practices of Telecom Service Providers.”