Wayne Cannon began his stint at Cerent on August 31, 1998 as a software engineer. He worked for Dave Smith, who developed the original Web-based management software for Cerent’s optical transport product [1]. Wayne collaborated with Chris Eich, specifically on the Cerent 454 graphical user interface (GUI) that accompanied the initial release of the product.
The Cerent 454 was first put into operation in a customer’s network on November 19, 1998.
Like Bob Bortolotto (hardware design) and Rex Pugh (product management), Wayne left Hewlett-Packard (HP) for a more free-wheeling startup environment. His contributions at HP included firmware development for “microwave network analyzers, microwave CAD software, and optical spectrum analyzers.” Wayne adds, “So I have a strong background in instrumentation and firmware, as well as networking and user-interface software.”
This background proved invaluable in developing Cerent’s operational support interface. The Cerent 454 GUI, which became part of the overall Cerent Management System, or CMS, would raise the bar for craft management of telecommunication network elements, a testament to the vision and perseverance of Wayne, Chris, and Dave.
By the time Wayne joined Cerent, the basic architecture of the ‘454’ had been defined for the first release of the product. This was not constraining to a software programmer like Wayne. He enjoyed the benefit of a dedicated processor (on the TCC module) that supported data collection related to the status of each card in the shelf and across the entire network of optically connected Cerent 454s (using IP-based communications within each shelf and across optical overhead bytes).
At the time Wayne and Chris joined Cerent, the ‘454’ network elements (NEs) were being managed by webpages served by small web servers for each of the individual NEs. Wayne adds, “While we could manage multiple network elements, each NE had to be configured individually (i.e., one-at-a-time) into the system, which would then allow the user to select specific NEs from a list in order to view them graphically on a map.
Coupled with exciting new languages – Java and JavaScript – Wayne innovated like he never did before, and never would again. He recalls, “We changed the management software architecture very significantly [from one-at-a-time NE selection] to that of the Cerent Management System (CMS).”
Wayne listed a number of the CMS capabilities delivered with the second release of the Cerent 454 and beyond:
The Cerent 454 was first put into operation in a customer’s network on November 19, 1998.
Like Bob Bortolotto (hardware design) and Rex Pugh (product management), Wayne left Hewlett-Packard (HP) for a more free-wheeling startup environment. His contributions at HP included firmware development for “microwave network analyzers, microwave CAD software, and optical spectrum analyzers.” Wayne adds, “So I have a strong background in instrumentation and firmware, as well as networking and user-interface software.”
This background proved invaluable in developing Cerent’s operational support interface. The Cerent 454 GUI, which became part of the overall Cerent Management System, or CMS, would raise the bar for craft management of telecommunication network elements, a testament to the vision and perseverance of Wayne, Chris, and Dave.
By the time Wayne joined Cerent, the basic architecture of the ‘454’ had been defined for the first release of the product. This was not constraining to a software programmer like Wayne. He enjoyed the benefit of a dedicated processor (on the TCC module) that supported data collection related to the status of each card in the shelf and across the entire network of optically connected Cerent 454s (using IP-based communications within each shelf and across optical overhead bytes).
At the time Wayne and Chris joined Cerent, the ‘454’ network elements (NEs) were being managed by webpages served by small web servers for each of the individual NEs. Wayne adds, “While we could manage multiple network elements, each NE had to be configured individually (i.e., one-at-a-time) into the system, which would then allow the user to select specific NEs from a list in order to view them graphically on a map.
Coupled with exciting new languages – Java and JavaScript – Wayne innovated like he never did before, and never would again. He recalls, “We changed the management software architecture very significantly [from one-at-a-time NE selection] to that of the Cerent Management System (CMS).”
Wayne listed a number of the CMS capabilities delivered with the second release of the Cerent 454 and beyond:
- Become a stand-alone software program running on the users' PC or UNIX workstation and managing an entire network of ‘454’ (and later ‘327’) NEs
- Automatically download the CMS software from any NE [2]
- Automatically upgrade the CMS software to the latest version discovered on any NE in the network
- Automatically discover the network topology and connectivity of all interconnected NEs (if there were clusters of NEs that were not interconnected, then the IP address of one NE in each cluster was sufficient to discover all of the remaining NEs)
- Automatically discover and display newly added NEs in the networks, and newly added plug-in modules in existing NEs; including the configuration and status of the NEs and their population of plug-ins
- Automatically discover and display connection changes and circuit status of all physical and logical circuits
- Automatically discover possible routes and select an optimal route for automatic, A-to-Z (end-to-end) circuit configuration across multiple NEs (including across clusters of third-party NEs in a “foreign” network)
- Support multiple simultaneously-running instances of the CMS management software, each of which maintained and displayed the current status of everything. (Competitive NMS software, on the other hand, only supported a single active software load and rarely more than one backup copy, the latter not able to be kept current until control was transferred from the primary system to the backup system).
“Our CMS management software contained almost all of the functionality expected by the industry of a Network Management System (NMS),” Wayne proudly recounts. A couple of exceptions to having a full-blown NMS were that our CMS did not support pre-configuring changes to services scheduled for some subsequent maintenance window and the lack of automated diagnostics.
Chris agrees, “What was exciting about Cerent was having the ability to have a network element that could pop up and not only be an element management system but be a network management system, to a certain extent.”
“We also had some limitations in CMS’s ability to seamlessly interact with traditional BellCore NMSs, [at first],” Wayne adds. “The distributed nature of CMS resulted in its inability to reconstruct some configuration changes in a format that could be repeated from a single BellCore NMS. Such a capability was easy for the BellCore NMS because that management system only had a single NMS active at any one time.”
“We also had some limitations in CMS’s ability to seamlessly interact with traditional BellCore NMSs, [at first],” Wayne adds. “The distributed nature of CMS resulted in its inability to reconstruct some configuration changes in a format that could be repeated from a single BellCore NMS. Such a capability was easy for the BellCore NMS because that management system only had a single NMS active at any one time.”
In looking back on that hectic year, leading up to the Cerent acquisition by Cisco in August 1999, Wayne says he loved “the wonderful working and management environment at Cerent-Cisco.” He never cared for the politics that played out strongly at the other companies he worked for.
Wayne subsequently worked for Turin (a late Cerent-Cisco competitor) and then Cyan (one of the packet-optical transport companies featuring technology that replaced SONET a decade later). So he is one of the few qualified to comment on their solutions too.
Wayne says, “Turin and Cyan were basically nice IP extensions to the ‘454’ technology,” which is, for a life-long engineer, high praise for the Cerent optical transport solution.
[1] According to Wayne Cannon, “The original management software that Dave started and on which Chris and I worked was a true Web page served up from a simple Web server on the NE -- an approach still used for management of individual nodes by most small routers, etc., today. While the subsequent CMS software was initiated similarly by browsing to a NE, the software actually resided on the user's PC or UNIX workstation, and that initial NE was only used to check for the latest software version and as a file server from which to automatically download a newer version to the workstation when a newer version existed. In keeping with the "Zero Administration" mantra, this approach looked almost identical to the user, but allowed the CMS to better accommodate management of multiple NEs in a network and to be significantly larger without incurring a performance penalty.
[2] Wayne Cannon recalls, “Although generally invisible and probably too esoteric for most readers, a significant aspect of the underlying CMS architecture was the ability to seamlessly manage NEs of differing models (e.g., 327s and 454s) and their associated software versions, independent of the overall CMS software version. In addition to containing a copy of the CMS software for downloading to the user's workstation, each NE contained a copy of the "driver" software that knew how to interact with that NE, including the user-interface software for that NE. As each NE was "discovered", a cache of driver software was kept in the CMS for each driver version encountered. If the NE was of a version not yet in the cache, the new version of driver software was downloaded from that NE into the cache. The CMS used the appropriate version of driver software for each NE, allowing a mix of old and new NE models and versions to coexist on the network, including models and versions never encountered before and potentially newer than the CMS software itself, and for software versions of individual NEs to be easily updated at any time. A side benefit was allowing bug fixes to older NEs without requiring an update of the CMS or of other NEs in the network.
Wayne subsequently worked for Turin (a late Cerent-Cisco competitor) and then Cyan (one of the packet-optical transport companies featuring technology that replaced SONET a decade later). So he is one of the few qualified to comment on their solutions too.
Wayne says, “Turin and Cyan were basically nice IP extensions to the ‘454’ technology,” which is, for a life-long engineer, high praise for the Cerent optical transport solution.
[1] According to Wayne Cannon, “The original management software that Dave started and on which Chris and I worked was a true Web page served up from a simple Web server on the NE -- an approach still used for management of individual nodes by most small routers, etc., today. While the subsequent CMS software was initiated similarly by browsing to a NE, the software actually resided on the user's PC or UNIX workstation, and that initial NE was only used to check for the latest software version and as a file server from which to automatically download a newer version to the workstation when a newer version existed. In keeping with the "Zero Administration" mantra, this approach looked almost identical to the user, but allowed the CMS to better accommodate management of multiple NEs in a network and to be significantly larger without incurring a performance penalty.
[2] Wayne Cannon recalls, “Although generally invisible and probably too esoteric for most readers, a significant aspect of the underlying CMS architecture was the ability to seamlessly manage NEs of differing models (e.g., 327s and 454s) and their associated software versions, independent of the overall CMS software version. In addition to containing a copy of the CMS software for downloading to the user's workstation, each NE contained a copy of the "driver" software that knew how to interact with that NE, including the user-interface software for that NE. As each NE was "discovered", a cache of driver software was kept in the CMS for each driver version encountered. If the NE was of a version not yet in the cache, the new version of driver software was downloaded from that NE into the cache. The CMS used the appropriate version of driver software for each NE, allowing a mix of old and new NE models and versions to coexist on the network, including models and versions never encountered before and potentially newer than the CMS software itself, and for software versions of individual NEs to be easily updated at any time. A side benefit was allowing bug fixes to older NEs without requiring an update of the CMS or of other NEs in the network.