For network managers to do their jobs at peak efficiency, they need to accumulate as much information as possible about the status of their networks. Traditional network management systems (NMS) or data-center infrastructure management (DCIM) tools provide visibility into the configurations and status of routers, switches, and other equipment, as well as power, cooling, floor space, and rack layouts, but they don’t reveal information about the state of the physical network.
NMS may be linked to OSS/BSS in the telecom space to link circuits and services to customers, and associated billing can be handled upon completion of a work order and commissioning of a new service. By reporting the status of fiber frames, patch panels, and which cable is connected to which port, physical-layer-management (PLM) systems provide the same visibility into Layer 1 of the network as an NMS or DCIM system does for Layers 2-7.
This file type includes high resolution graphics and schematics when applicable.
Ideally, network managers want to see a complete picture of the network from a single management interface. When deploying a PLM system, this means using the PLM system’s own software solution, forcing the network operator to use yet another system. This approach requires them to duplicate certain information, like floorplans and rack and panel positions within the racks, which creates challenges when trying to keep both systems up-to-date and synchronized.
The same is true for work orders. Tracking systems already exist, but they often only address the changes and not the billing. Another approach is to use middleware to integrate that platform’s data with an NMS or DCIM system. In this article, we’ll look at PLM middleware integration.
Physical-Layer Management at a Glance
Physical-layer management systems use intelligent fiber frames, patch panels, and patch cords to collect and report information about the physical state of the network. Unique chips at the ends of patch cords and in the ports of fiber frames and patch panels offer detailed information on what is being connected where, including port number, cable ID number, cable type, length, color, and rating. This information is reported to a database that can be viewed through a web interface.
When a cable is unplugged or plugged in, the system reports this in real time, so that the network documentation is always up-to-date. This saves a lot of network technician labor that would otherwise be spent manually recording changes to the network.
Most PLM systems also include a work-order management system that schedules tasks for network technicians and even guides them through a particular task. For example, an order to connect a circuit might trigger flashing green LEDs on the ports that are to be connected.
The Solution
With middleware integration, the PLM system’s middleware APIs integrate with APIs from the NMS to convey physical-layer information. The integrator will pick and choose the physical-layer information that’s to be integrated via simple GET commands.
One of the benefits of middleware integration is that the user needn’t implement and train people on a new management interface (for the PLM system alone), but can instead obtain the information needed through the management interface that’s already being used. There’s no need to duplicate information and make manual changes to keep separate systems synchronized.
Integrating Middleware
Physical-layer-management middleware is a minor software layer responsible for discovery of PLM hardware that’s able to report any event on port connectivity changes, with all associated details reported in real time to an external software system. Middleware provides physical-layer feedback and data in real time, fed to an existing database that has much more stored than just physical-layer data—it also contains Layer 2-7 information about the network. Middleware connects the PLM system’s database to the NMS or DCIM’s existing database.
Best practices in the software world have moved toward representational state transfer (REST) APIs and using web services languages like XML or HTML, all of which is supported by PLM middleware. Effectively, developers write scripts that connect APIs between the middleware and the target NMS or DCIM application. Middleware companies also work with standards bodies such as ISO and EIA/TIA to develop Automated Infrastructure Management (AIM) standards. These will standardize the data points available in a PLM system, making the APIs become more familiar and simplifying the software’s ability to connect back to a PLM system.
In a script, basic commands like GET PANEL STATUS can get an entire panel’s port status. When SNMP queries the middleware, it will identify the configuration of the PLM equipment through an SNMP Entity management information base (MIB). For example, the MIB will identify that Panel A Port 1 is connected to Panel B Port 12. It will automatically report all of its hardware components, the configuration of those panels, and the configuration of each individual port.
In all, for basic PLM capabilities, only about half a dozen scripts need to be written to make the connection between middleware and an NMS or DCIM. However, the target software must support physical-layer documentation.
For integration with a work-order management system, CONNECT commands tell the middleware which ports are involved, and flash the green LED to tell the technician to connect the two cables. The DISCONNECT command tells the middleware to flash the amber LEDs on the port, which alerts the technician to disconnect the port.
Middleware Integration Use Cases
To make integration successful, network managers should first identify specific use cases. Many data points are available, but the use cases will determine which of these will be integrated into the network management system.
For example, a company may be using an automated work-order platform. In this scenario, the use would be to enable LED guidance on patch connect/disconnect work tasks. A programmer looking only for NMS or DCIM records to be automatically updated wouldn’t need to integrate the work-order steps. In another case, the middleware could be used purely to provide port status information—validating cable lengths, categories, and circuits for a DCIM.
In addition, many network managers seek to improve network security by reporting events such as unauthorized connections and disconnections. Therefore, they’re visible in the same DCIM dashboards where other types of alarms are visible (such as those related to temperature or power conditions in the data center).
Common Questions
Before attempting to integrate middleware, it’s important to understand who pays and who is responsible for the integration work. The integration may be paid for by the PLM vendor, the end customer, a NMS/DCIM vendor, an independent software vendor, a certified integrator of the NMS/DCIM solution, or (if the integration has been done before) the solution may be available “off-the-shelf.”
The responsibility and duration of the integration work will vary depending on the number of parties and the scope of the use cases, or the amount of system functionality slated for everyday business processes. This will take, at minimum, a few months to account for implementation and systems and process validation.
The Future
Physical-layer-management systems help provide a complete, real-time picture of the entire network. Integrating these systems with a NMS or DCIM gives a view of the whole network through a single pane of glass, and by adhering to web-services development models, middleware makes integration easy.
This file type includes high resolution graphics and schematics when applicable.
Today, PLM middleware works only with a handful of NMS and DCIM platforms. However, PLM systems vendors are working with NMS and DCIM vendors to standardize APIs to make middleware integration easier to implement on a wider variety of network-management products.