Management techniques for driving the new network

Emerging IP network-management systems can help service providers harness the network in today's increasingly complex IP environment.

BENEDICT ENWEANI, Orchestream

To generate revenues from their vast capital investments, service providers face an immediate need to provide advanced, value-added services to enterprise customers. Fortunately, with the advancements in networking technology, the world of next-generation services and customer solutions is ripe with opportunity-and expectations.

The challenge for providers is to reduce the inherent complexity involved in configuring and controlling multiple network technologies, poorly adhered-to standards, and myriad products to offer compelling services. How can service providers harness these new networks?

Part of the answer lies in IP, since new networks are primarily IP-centric. Traditionally, IP networks provided best-effort service on relatively slow links to very knowledgeable users. Today, IP is spreading from the edges of the network into the core. It is also evolving to support the diverse range of advanced services that carriers and service providers will need to offer. At the same time, core equipment vendors, responding to the need for ever-greater capacity, have delivered multiwavelength, data-transparent, optical technologies that are compatible with IP network requirements.

Today's networks have grown in all aspects of scale and have become more complex. This complexity is driving the requirement for an IP network-management solution.

The network has grown in size, number of nodes, and traffic capacity. This growth has resulted in the need for managed hierarchical aggregation of Internet Protocol (IP) traffic into pipes and some form of traffic engineering. In the mid-to-late 1990s, these capabilities were provided by the combination of first-generation optical networks using SONET/SDH and IP-over-ATM layered approaches. But there is room for further aggregation, and traffic engineering performed at the IP layer rather than in an overlay model is a much sought-after network service.

Is IP directly over SONET better than IP over ATM over SONET? The reality is that ATM and SONET are just the data link layers as far as IP is concerned. The value of the layered architecture depends on the relative importance given to the capabilities exploited at each level. The requirements for services not currently provided by IP alone, including synchronous voice switching, protection switching, and link-layer-dependent bandwidth capacity, ensure that a layered architecture of some form will remain. Cell tax arguments seem to pale in comparison to the losses that occur when nonresilient networks suffer line cuts.

Proposed changes to IP routing protocols such as open shortest path first optical extensions and specifications for interworking between the routing layer and an underlying private network-to-network-like switching layer are being designed into newer lambda switching networks and second-generation optical-network models. That should allow for network de-layering and may take the form of Multiprotocol Lambda Switching (MPlS)-controlled IP-over-optics architectures.

The number of users purchasing outsourced network services has in-creased dramatically. These customers expect Web-based interfaces to their service profiles, which offer real-time reports on service-level agreements (SLAs). Indeed, the responsiveness of the service provider is a marketable service; interprovider competition places a premium on the ability of the provider to activate service requests such as virtual leased lines in hours rather than weeks.

Finally, the sheer scale of the services offered on outsourced networks has grown in almost every dimension:

• The total bandwidth is far greater.
• The number of concurrent users competing for the backbone network resource is higher.
• Virtual-private-network (VPN) interconnects have increased in complexity, classes of service, and rate of change.
• Proposed billing schemes, the required level of fault correlation, and the network configuration have also become far more complex.

This new IP network complexity calls for a range of network-management functions. The physical size of the network makes the maintenance and delivery of consistent network configurations difficult.

While service providers consider IP-based VPNs, the fundamental IP service offering for enterprise customers, most offer a wider range of services today:

• Highly scalable provider-provisioned VPNs with extranet capability.
• Policy-based Internet access.
• Secure access and confidential data transmission.
• Voice-over-IP (VoIP) and other real-time connection-aware services that require quality of service (QoS).
• Managed and hosted applications.
• Wireless IP connectivity.
• Traffic aggregation and protection services to support peering of high-bandwidth links.

Many services are now possible within the IP realm because of standardized additions to the IP protocol suite. These include Multiprotocol Label Switching (MPLS), differentiated services (DiffServ), secure Internet Protocol (IPSec), real-time protocol (RTP), resource reservation protocol (RSVP), label distribution protocol (LDP), and extensions to routing protocols such as the MPLS-VPN discussed in the IETF RFC 2547bis. Recent drafts even include a protocol for SONET/SDH circuit emulation service over MPLS.

Today, service providers deploy routing and switching equipment from several different vendors in their networks. Vendor selection is often predicated on specific equipment's differentiating features and its requirements in different parts of the overall network. Hence, IP router vendors are often segregated into the various network layers-access, aggregation, or the core. The result is a requirement for multivendor technology management.

Unfortunately, vendors have failed to standardize on a common network control methodology and management protocol. Several standards bodies have proposed management standards: the Internet Engineering Task Force (IETF) and Distributed Management Task Force (DMTF) maintain a policy-based networking common information model, and the IETF common open policy service and simple network-management protocol configuration working groups are developing management protocols. However, these approaches currently lack large-scale support.

It would be convenient if all vendors used the same management transport protocol, but standards-based management protocols are not a panacea. History suggests that vendors will unfailingly provide vendor-specific extensions to their information models and product capabilities. Therefore, mediation between the varying device standards and architectures always will be necessary.

Traditionally, the IP network simply didn't need centralized network management. Basic IP only provides a simple datagram service; there is no inherent concept of a connection. IP net-works therefore distributed the network intelligence in self-healing and organizing routing protocols.

The advantage of using IP lies in its ability to abstract underlying technologies. Service providers can use IP's ubiquity to maintain control of their networks. Whether advanced services are provided over Layer 2, Layer 3, or above, the network must have resilience to be profitable. Network-management software that concentrates all of a network's infrastructure development in one single control domain, or view, enables resilience and flexibility (see Figure 1).

Current IP network-management software typically allows carriers to perform the following functions:

• Automatically provision networks and activate new services on large-scale, multivendor networks.
• Provide configuration-intensive services such as network-based MPLS IP-VPNs in a matter of hours instead of days.
• Implement QoS solutions to improve IP's best-effort delivery and offer a range of premium services that support delay-sensitive traffic and standard service levels.
• Exceed the limitations of shortest path first routing and provide Layer 3 traffic engineering and QoS.
• Define default network services and configuration using pervasive network policies rather than multiple individual component configurations.
• Offload high-volume network-configuration changes to the service client.

Fundamentally, service providers need an activation platform for delivering services, and this platform must share a wealth of network and service information. The network-management system (NMS) should also support the current trend of outsourcing network provisioning to the customer. That implies real-time, transactional, comprehensive network provisioning, or one-touch flow-through activation.

A semantically flexible application programming interface (API) bus structure allows OSS functions such as customer care, billing, fault correlation, and inventory to easily communicate with the NMS (see Figure 2). The API should support configurations for new services without requiring recompilation and extensive re-factoring of the information model and the software components that compose the OSS-NMS interface.

Network-management solutions must also share network fault and alarm information in a service-oriented manner. That enables the network manager to tell at a glance that an offline router means an international banking customer has lost a VPN connection between New York and Boston. Billing systems also require information expressed in this context. The IP NMS should monitor, measure, and report SLA fulfillment and breakdown: tight integration with other service-level management tools is key.

The network object model provides the grounding for the implementation of novel service offerings. If the service activation system allows object model hierarchies and operations to be scripted in an interpreted language, then new, flexible services can be added without requiring upgrades to the system.

Functional network abstraction is achieved via the definition of an abstract object representation. That has been the goal of the DMTF and IETF policy workgroups. Although object model implementations will vary, they must faithfully represent physical and virtual network concepts such as device interfaces, VPNs, and customers. The external object model provides the vocabulary on which an OSS information model can be built.

The IP NMS cannot populate the exposed object model without performing some level of network discovery and maintaining direct communication with the network elements. Intelligent capacity and capability management requires in-depth knowledge of the optical and IP layer topology and composition. When a service provider sets up a VPN connection for three customer sites, such solution software knows whether the network is capable of delivering that service and whether the service provider has any hope of meeting customer requirements in the form of an SLA.

Today's networks are large, both in managed elements and the geographical dispersion of those elements. IP service provisioning often requires near-simultaneous configuration changes to many nodes. The activation of tens of thousands of services running on thousands of interfaces provides a challenge with which few current systems can cope.

Spatially distributing network provisioning makes effective use of parallel processing to complete the repetitive configurations required for large-scale services and reduces the amount of in-band management and traffic monitoring. A recent study showed the average time taken to configure a 10,000-site network is more than 24 months if done manually (and that does not account for errors in configuration and consequent reconfiguration time). A well-designed provisioning tool is able to perform a great deal better.

Is a distributed IP NMS architecture feasible? Yes, several systems have al ready been shown to work in live deployments. These systems use mature technologies such as object brokering to allow for flexibility and location insensitivity.

The IP NMS must also be flexible enough to manage the broadest range of network devices a service provider may choose to use in its network. Even in the best case, it is unlikely both the IP and optical layers will share a management protocol.

Manual control of provider IP networks will become increasingly onerous as more and more organizations outsource their own networks, and as growing volumes of information are transmitted over carrier networks. The complexity of current networks and configurations has already exceeded many of the management techniques previously used in IP networks.

Interestingly, more traditional NMS paradigms, for years used in ATM and SONET networks, are now appearing in the IP domain, lending further evidence of the convergence of IP and optical approaches to deploying network infrastructures.

For the first time, multivendor management solutions are being deployed to configure and provision all layers of the converged data network. This trend is made possible by the ubiquity and abstraction provided by IP and the transparency of the optical layer. The resultant potential to abstract the network itself will likely have an enormous impact on the flexibility and capability of the new multiservice IP-optical network.

Benedict Enweani is chief technology officer at Orchestream (New York City).

Today, Internet Protocol (IP) traffic is widely carried over SONET/SDH lines and through a variety of data link layers such as ATM and packet over SONET. Multiprotocol Label Switching (MPLS) promises to integrate these technologies via a unified control plane to allow new services as well as cost savings.

A powerful tool for control of both the IP and optical-network layers, MPLS has evolved from a label-swapping protocol designed to decrease the time it takes a router to look up packet headers into a full-featured network control plane that separates the packet-forwarding process from the packet-routing paradigm. Packet forwarding is determined by the label header carried by the packet upon ingress to an MPLS node, and in some cases, by the class of service indicated in the MPLS header. Label swapping, based on a label distribution protocol, is used to forward the packet through the network over a label switched path (LSP). The label distribution protocol is controlled by an internal Border Gateway Protocol, another constraint-based routing algorithm, or by an external network modeling system.

With MPLS, a sophisticated IP network-management system essentially can operate as a traffic-engineering tool. It can generate highly optimized, offline LSPs to provide protection switching, higher QoS guarantees, or more sophisticated circuit emulation services (CES). It also can aggregate individual access LSPs onto large core pipes for transparent transport over various media.

IP offers the network layer ubiquity and abstraction that applications and customers need to reduce costs. MPLS, Multiprotocol Lambda Switching (MP(S), and MPLS over ATM offer the control plane ubiquity and abstraction required to extend Layer 3 IP control to the ATM permanent virtual circuit, SONET crossconnect, or DWDM wavelength. MPLS also has the potential to widen the range of end-to-end services available to carriers with multitechnology networks (i.e., IP, ATM, SONET, and DWDM).

From many perspectives, MPLS levels the playing field. It promises a seamless upgrade to second-generation optical-networking equipment by retaining an extensible control plane-one of the most compelling reasons to use MPLS.

Not to oversimplify, the IP network-management system in this scenario is a sophisticated, mature piece of software. Although MPLS may reduce the complexity of service-activation tasks, today's networks still comprise multivendor components with extremely divergent element-management approaches, non-standard router configuration protocols, non-standard router information models, varied device capabilities, and an amusingly random matrix of interoperability issues. A single system needs to manage all of these discrepancies; otherwise, the advantage of a common protocol such as IP is completely lost.