Ethernet and IP are now ubiquitous in telecom networks following the introduction of 4G LTE. Even though these protocols have been in use in telecom networks for several decades, there is still a lot of misunderstanding associated with how these technologies work and how they are different from traditional telecom protocols.
This is especially the case in network management. Ethernet and IP have always presented a bit of a management headache, as they are completely different in their behavior and do not provide the same level of management information as other protocols commonly in use.
Understanding how Ethernet and IP behave will be crucial to the success of implementing an effective, scalable, high-performance management solution for SDN and NFV networks. In the previous installment, we established the need for real-time insight to support agile reaction to changes in network traffic patterns. However, understanding Ethernet and IP behavior is also important in determining how to virtualize management functions and appliances and assure high-performance. (See Managing OTT Traffic in the SDN/NFV Future.)
Managing SDN and NFV is a headache for most carriers given the fact that a considerable investment has been made in OSS/BSS systems and infrastructure that now must be adapted to the SDN/NFV future. This is therefore an opportune time to also introduce the necessary changes in OSS/BSS implementations to accommodate the behavior of Ethernet and IP networks and enable real-time insight.
Most of the OSS/BSS systems installed have their grounding in the FCAPS model of management first introduced by ITU-T in 1996 in M.3010. FCAPS stands for Fault, Configuration, Accounting, Performance and Security, indicating the five areas of focus for management of networks and services. This concept was simplified in the Enhanced Telecom Operations Map (eTOM) to Fault, Assurance and Billing (FAB). Management systems tend to focus on one of these areas and often do so in relation to a specific part of the network or technology, such as optical access fault management.
One of the issues with using FCAPS and FAB in relation to Ethernet and IP is that the conceptual underpinnings of these models were traditional, voice-centric networks based on PDH and SDH. In other words, static, engineered, centrally controlled and planned networks where the protocols involved provided rich management information. This made centralized management possible.
Ethernet and IP are the complete opposite. The basic idea of Ethernet and IP is that instead of planning and engineering the network with static routes, Ethernet switches and IP routers could "learn" the best routes in the network and (re)direct traffic accordingly. In other words, the network would have the intelligence to take care of itself. Ethernet switches and routers provided Command Line Interfaces (CLIs) for configuration, but also supported SNMP interfaces to support fault management and polling. Since the intention was not to centrally manage networks, but to let these networks manage themselves, the conceptual underpinning of Ethernet and IP ran at odds with telecom management principles.
Nevertheless, there have been various attempts to "shoe-horn" Ethernet and IP into management concepts. For example, Call Detail Records (CDRs) have been used for billing of voice services, so the natural extension of this concept is to use IP Detail Records (IPDRs) for billing of IP services. xDRs are typically collected in 15-minute intervals and that is fine for billing, which does not, in most cases, need to be real-time. However, xDRs are also used by other management systems and solutions as a source of information to make decisions.
The issue with this is that while traditional telecom networks do not change in a 15-minute interval, since they are centrally controlled and engineered, Ethernet and IP networks will be completely different. Ethernet and IP are dynamic and bursty by nature, and since the idea is that the network makes autonomous routing decisions, the traffic patterns on a given connection can change in a matter of nanoseconds. So, relying on information collected every 15 minutes to make decisions in an Ethernet and IP network is probably not a good idea.
Another issue with Ethernet and IP is that they do not provide a lot of management information. If you want to manage a service provided over Ethernet and IP, you need to collect all the Ethernet frames and IP packets related to that service and reassemble the information to get the full picture. While switches and routers could be used to provide this kind of information, it quickly becomes obvious that continuous monitoring of traffic in this fashion would affect switching and routing performance. Hence the introduction of dedicated network appliances that could continuously monitor, collect and analyze network traffic for management and security purposes.
Network appliances have the added advantage that they can provide this functionality in real-time. It is now possible, even at speeds of 100 Gbit/s, to collect all the data, analyze it and trigger an action in real-time without losing any information.
For effective, high-performance management and security of Ethernet and IP networks, network appliances are now broadly used. However, the taxonomy of network appliances has grown outside of the FCAPS and FAB nomenclature. The first appliances were used for troubleshooting performance and security issues, but have gradually become more proactive, predictive and preventive in their functionality. It can therefore be difficult to map available commercial appliances neatly into telecom management frameworks, but the basic real-time capabilities that all appliances provide make them essential to effective management of Ethernet and IP networks. For this reason, network appliances need to be encompassed in frameworks for managing and securing SDN and NFV.
In the next installment, we will take a closer look at network appliances, the challenges they address and how they can be used to provide the real-time insight that SDN and NFV networks will need in the future.
— Dan Joe Barry, VP, Marketing, Napatech