Network Management and MPLS
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Introduction
Multiprotocol label switching (MPLS) continues to grow in popularity with global service providers (SPs), particularly in Europe [1]. At the same time, the deployment of MPLS-based services—for example, RFC 2547 Internet Protocol (IP) VPN—is proving to be something of a challenge [2] to those SPs for the following reasons:
Cost and difficulty of deploying and operating MPLS network management
MPLS competes with and may potentially replace existing technologies
Deployment of MPLS technology
Legacy technology support
This article focuses on the first of these problems, that of managing MPLS technologies.
In many ways, MPLS provides the best of both IP and asynchronous transfer mode (ATM) by combining traffic engineering, subnetwork connections, and different quality of service (QoS) models. IP, on the other hand, provides just a best-effort datagram service. Bringing together these two domains (IP and the ATM-connection-oriented telecoms world) requires an integrated approach to network management. In this article, we'll look at some of the reasons why this process may be more difficult than expected. The benefits of effective MPLS network management can be realized if the technology is integrated into the SP workflows and business processes.
MPLS provides the possibility of a unified core network for both SPs and enterprises. In this scheme, legacy technologies such as ATM, frame relay, and Ethernet can be pushed out of the core network to the edges. The resulting core network is then packet-based using MPLS and some specified QoS mechanism such as DiffServ, IntServ, and so on. Having a single connection-oriented, QoS-based core technology provides a foundation for standard signaling protocols such as Resource Reservation Protocol with traffic engineering extensions (RSVP-TE) and Label Distribution Protocol (LDP). This can then facilitate rapid service deployment, improving the SP's return on investment (ROI). The deployed network management system (NMS) is a critical element in realizing ROI and is used to support the five major network management functional areas. In many cases, more than one system is needed to realize the overall NMS capability.
The five functional areas of network management for MPLS are known by the acronym FCAPS:
Fault. Network devices generate data indicating problems or matters of interest to a network manager.
Configuration. Modifies the network in some fashion, such as creating a label-switched path (LSP). Often called provisioning in the telecoms world.
Accounting (or billing). Enables an operator to determine usage of network resources. End users may be billed or the data may be used for accounting analysis, such as ROI calculation.
Performance. Determines whether the network is operating within required limits. This factor is increasingly critical as service-level agreements (SLAs) are used by SPs to differentiate their services. SLAs are being used within enterprise networks in the form of contracts between IT and the various departments. Performance analysis may also be used by network planners to decide whether infrastructure upgrades are required.
Security. This area is increasingly critical with the growing number and level of sophistication of network attacks. The focus here is ensuring that network resources are protected from unauthorized access.
FCAPS can be seen as baseline capability, and deployed NMS products may well exceed this level. Many NMS offerings don't offer configuration capabilities, however; the network operator must use the individual device's element management system (EMS)—often a Telnet-based menu program that runs on devices such as routers, switches, hubs, etc. Where NMS products offer less than the full FCAPS, the end user may need to provide proprietary software to fill out the NMS capability. Many SPs employ large teams of technicians to carry out base-level device configuration; these tasks may arguably be better handled by software in the NMS/OSS layer. The Operations Support System layer (OSS) resides above the NMS and provides business management capabilities such as those described in the following table.
|
Process |
Example |
|
Workflow management |
Creating/modifying/deleting virtual circuits. |
|
Trouble ticketing |
"Router 10, interface 3 in Chicago has gone down." The problem is recorded and the operator may choose to create a specific workflow item to resolve the matter. |
|
Network planning |
"Is the fiber optic link between New York and Denver in need of replacement?" |
NMS products may provide application programming interfaces (APIs)—often based on CORBA—for use by OSS components. OSS applications can then call into the NMS via the API to handle situations such as these:
Retrieving all alarms on a given device
Creating a virtual circuit (for example, an LSP) between two nodes
Modifying the reserved bandwidth on a selected LSP because the associated enterprise customer has increased its subscription
Increasing the bandwidth allocated to an LSP
The OSS exists to support the SP workflows and business processes. The required OSS capabilities may be fulfilled by the NMS, or the OSS can even directly use the underlying devices via SNMP, XML mechanisms, and so forth. The OSS has a higher-level view than the NMS of the managed objects deployed in the network.