As long as there has been public networking, there has been network management, and that's the good, the bad, and the good news again. The first piece of good news is that in 2008 and beyond, that will still be the case. The bad news is that network management is going to change radically in that same period. The second piece of good news, however, is that these changes can be managed if they're addressed correctly. Just as there are three distinct pieces of "news" there are also three major drivers of change.
First driver: Consumerisation. The first major change in network management is driven by a major change in network mission. Network operators have tended to focus on "convergence" as the driver for change, but the real driver is a different "c" word: "consumerisation." Ten years ago, enterprises purchased the only broadband connections, where today the number of consumer broadband connections is 10-to-40 times the number of enterprise connections, depending on the market area.
Consumerisation creates a management problem for two reasons -- scale and literacy. Obviously, multiplying the number of broadband users by a factor of 10 or more would likely multiply management demands similarly. That increase would threaten to explode operations and administration costs that for most operators are already three to four times capex as a percent of sales. When the increase in the number of connections is due to the introduction of broadband services to users with low technology literacy-which certainly describes the consumer-you create an even more alarming level of cost risk.
The only solution to controlling operations costs is to automate more operations. That requirement has created the largest challenge for the network management world, because in order to automate consumer broadband operations, you must take an outside-in view of network management. Why? No network operator would ever accept a service architecture that maintained individual consumer awareness (what network practitioners would call "state") inside the network. Consumers are managed in aggregate on the network, but they must be supported as individuals when they call for service.
The consumerisation shift demands that network management be linked to a service management process that maintains customer-specific information and also provides a link between the customer process and the network resources that are linked to fulfilling the customer's services. Consumer broadband services, whether Internet, VoIP or IPTV, generate more customer care events than PSTN services, and so it is critical that customer care provide direct links to not only billing data for inquiries and subscription data for service information, but also network data.
Some might call this requirement an example of customer-focused service monitoring, but the issue is much more complex. Service automation cannot be performed unless there is a machine-readable template to describe the service and to control how the service experience is created from network resources. A service management linkage to network management can, in effect, stand in for craft personnel making manual changes, and provides the most reliable form of automated provisioning/commissioning of services, modifications to existing services, and processing terminations.
Management vendors and standards groups, including IBM and Oracle in the former group, and the Telemanagement Forum and DSL Forum in the latter, have been working to develop this new service-to-network relationship, and most of the pieces are already in place. They will come together convincingly in 2008.
Second driver: Increased computer technology use. A second issue for service provider network management is the increased use of computer technology to host service features, content and applications used in service delivery. The most familiar architecture to support this transition from network-based to hosted features is the IP Multimedia Subsystem (IMS) of the 3GPP, ETSI and ITU. IMS creates a service layer that controls the network through a Resource Access and Control System/Facility (RACS/F). Not only does this create a break between the customer experience and the network by creating an abstraction layer, it also creates a new set of session and application resources that have to be managed. The network management system of the future will be increasingly a computer, software, and network management system and not just an NMS.
The introduction of servers, software, content and applications into networks creates a need for a more flexible model of network components and services. Work in this area is just beginning in the ITU and the TMF. The modelling process in TMF comes under the heading of the Service Delivery Framework team and is likely to produce its first results in 2008. Since a flexible management model for a complex service-driven network is critical for any management system to be effective, management buyers will want to watch this activity and the progress of their vendors in supporting the outcome.
Third driver: The rise of Ethernet convergence. The third key issue in network management also involves abstraction, but this time it's network technology and not services that are the target. The view that "convergence" always meant "on IP" is becoming less universally held as Ethernet technology (via PBB-TE or PBT, as it is more commonly known) makes headway as the framework for network traffic management and the basis for legacy converged services like frame relay and ATM.
Vendors are also beginning to converge metro optics and Ethernet onto a multi-layer flexible infrastructure. All of this means that network traffic management will benefit from an abstract view (establishing point-to-point connections at the traffic management level and then impressing those connections downward onto whatever infrastructure is present). That same abstract view is encouraged by the emergence of independent control planes such as GMPLS, which allow management systems to create routes independent of what kind of equipment might ultimately create the network representation of the route.
Abstraction as common thread
The common theme in all of the drivers mentioned here is the need for abstraction, and even though that might be comforting on the surface, it's actually potentially a problem. All three of these drivers are operating independently and at different levels of the network process. I've presented them from the top or business-process level to the bottom or network-hardware level. A common mechanism for modelling all of this could prevent wasted effort harmonising multi-layer models later on, but this doesn't seem to be likely to happen out of the current standards processes. The management systems vendors themselves may be the drivers of "abstraction/modelling convergence," and that may be the differentiator of the greatest value in 2008 and beyond.
About the Author: Tom Nolle is president of CIMI Corporation, a strategic consulting firm specialising in telecommunications and data communications since 1982.