Design Considerations for Edge Routers: Part 2

In Part One, we discussed design considerations for service-edge routing platforms, and the importance of network management was highlighted. Now, in part 2, we'll examine how designers can better marry a router with a next-generation EMS.

Why it Matters
Service provider networks have become increasingly complex. The number of connected users continues to increase along with the diversity of vendor equipment. Carriers are offering a wide array of services at ever-increasing speeds.

In response to challenging market conditions, service providers have decreased capital expenditures and are now turning their attention to reducing operational costs. As a result, efficient service provisioning and management is receiving close scrutiny.

The conflicting goals of reducing costs while enhancing service offerings are difficult to achieve without sophisticated element management software that effectively integrates into an overall management infrastructure. Today's element management software plays a crucial role in the successful management of complex, multi-vendor carrier networks.

OSS software is required for service providers to manage and support daily operations. OSS software manages a range of devices, and each device may have a corresponding element management system that extracts and provides information to the OSS. To help carriers and service providers tie together their business process and management systems, the International Telecommunications Union (ITU) developed a management architecture model, the telecommunications management network (TMN), which breaks down the activities associated with managing a telecommunications network and defines a set of associated interfaces and functional blocks (Figure 1).

The TMN model initially attempted to define the protocols used by each of these layers. These protocols became complex and expensive to implement and have been mostly abandoned by management systems. However, the TMN is still an effective conceptual model for designing management systems. By implementing management systems that comply with the concepts of the TMN model, carriers can more easily integrate new products within their OSS.

The State of Carrier Network Management
Current OSS technology cannot cope with the rapidly increasing scale of networks, the diversity of communications technology, a shortened time to market for new services and heightened expectations for availability and reliability.

Service provisioning is today a highly manual, labor-intensive process with the expected associated high costs. Provisioning is often time consuming for service providers and frustrating for customers who wait for their order to be fulfilled. When executing an order to provision a new service, a carrier involves multiple departments and support systems spanning a range of management layers. This complexity requires costly training and increases the potential for errors.

With the introduction of new optical transport technologies, provisioning times for capacity have been dramatically reduced from months to days. The challenge that remains for both service providers and equipment vendors is how to bring the same rapid provisioning model to the networking services layer.

Another key driver in the need for a new approach to network management is a dramatic change in the way customers manage and access service information. Customers are increasingly demanding the ability to manage services via the Web. Over time, carriers must support the ability for customers to order and maintain their carrier services online, and request immediate service changes to accommodate ongoing business demand.

Customers also expect to receive the level of service they are paying for. Carriers enter into service level agreements (SLAs) with customers to promise certain levels of availability, latency and loss. Accurate SLA reporting requires a dependable mechanism to collect and store the necessary statistics. This data must be reliably collected for each managed element within the EMS domain, and be made accessible to external reporting and billing applications.

The increasing complexity of network elements amplifies the importance of having robust element management systems at the core of an overall management platform. To enable integration into the higher management software layers, an element management system provided by equipment vendors must implement an open northbound application programming interface (API) that allows the service provisioning, fault and performance monitoring functions to be accessed from a carrier's network and service management applications. This northbound API helps carriers reduce the number of different user interfaces that operators must learn to manage the network. For example, a customized application can be developed to provision end-to-end services through a multi-vendor network using a unified look and feel.

Past and Future
Before reviewing the latest trends in element and network management, it's helpful to look at the past. Network management has often been an afterthought by router vendors--from the enterprise through the service provider core. As computer networks became more complex, they became harder to manage. Devices became increasingly interconnected within LANs and across WANs.

Some vendors (most notably those developing Layer 2 devices such as ATM and frame relay switches that were designed to deliver guaranteed levels of service) developed element managers for device-level management and to ensure that SLAs were met. Other software vendors began offering OSS applications that used standard protocols to manage multi-vendor networks. Router vendors often left device management to carriers by providing SNMP or command line interface (CLI) based access to their devices for this purpose.

The complexity of legacy systems and lack of element management support has led many carriers to develop proprietary internal systems that are based on CLI scripting to tie together a range of devices. Unfortunately, these "home-grown systems" are hard to manage, have difficulty keeping pace with new requirements and are prone to errors.

The task of managing performance, alarms, and state changes in carrier networks that can contain millions of distinct elements is a complex undertaking that requires a new approach. The next-generation approach that is typically being offered includes an object-oriented, distributed system comprised of specialized servers consisting of element management servers, database servers and potentially accounting servers coupled with GUIs designed for access by both network operators as well as service provider customers (Figure 2).

Service provider network management is a complex undertaking, and there are a number of reasons why this is the case. Reasons for complexity include:

1. Simultaneous processing: There are a large number of user requests and network events occurring at the same time in both directions.
2. Scale: These service provider networks are extremely large (and global in many cases) and may contain millions of distinct elements.
3. Device and service diversity: Service provider networks contain many types of vendor equipment. At the same time, they're supporting and provisioning a highly diverse range of services--using different protocols, access speeds and technologies.

Redeploying Web Technology for Network Element Management
Standards-based distributed component technology that is successfully being used for large, distributed Web applications is increasingly finding a place at the core of next-generation network management architectures. Distributed Web application technology enables the rapid development of new managed services that are complex, multi-component, robust and transactional.

Large-scale, distributed Web applications and service provider networks share similar characteristics including support for large numbers of interfaces, the requirement to process large numbers of transactions or activities and the need to provide indications of the success of activities as well as failure notification. An important component is the ability to intelligently "back out" of failed transactions.

The technical underpinnings of application server technology came from the distributed transaction world, which is characterized by highly concurrent, high throughput applications that must be robust and fault tolerant. Web applications are built on standards-based application server technology, and were developed to support applications that needed to share data with other systems and tie that data to dynamic Web applications.

These products, such as such as BEA Weblogic server or IBM Websphere, provide a highly scalable foundation for developing custom network management and element management applications. They are based upon emerging standards--in particular Sun's Java 2 Platform, Enterprise Edition (J2EE), which includes the elements required to build a robust, secure, distributed environment that works equally well on various OS platforms.

Details on J2EE
J2EE defines an architecture for building distributed, multi-platform object-oriented business applications in Java. J2EE enables transaction processing and control transactions across multi-platform enterprise systems and database servers.

Element management systems are ideal J2EE applications. A device's hardware and software configuration can easily be modeled and managed through a J2EE application such that provisioning new interfaces and services can be easily achieved.

When interoperability is required with legacy devices and OSS software is not developed using Java, northbound CORBA/XML APIs can be used, which are evolving to become de facto standards.

The common object request broker architecture (CORBA) is middleware focused on the exchange of information, and it is increasingly gaining acceptance in the area of network management. CORBA uses TCP/IP, is widely available, and may be used to implement tailored interfaces that are ideal for network management systems. For example, what would take multiple SNMP sets can be done with a single CORBA call on a well-defined interface. Through transaction support, the system under call may provide failure atomicity semantics whereby if a component of the operation fails any partial changes will be undone.

Some design engineers are also looking at the use of XML in element applications. The use of XML is still in the early stages of acceptance but there is increasing activity and interest in using this technology.

XML employs a simple object access protocol (SOAP) framework, which supports the implementation of well-defined interfaces with similar semantics to the CORBA-based interfaces mentioned above. The use of XML as a replacement for the CLI is also appearing. However, this approach is a poor substitute for a well-defined interface and does not aid OSS integration.

The OSS/J Extension
To date, standards for interfaces that enable OSS integration are sorely lacking. Likewise, there are no de facto standards that the industry can clearly back. The best current approach is one being developed under the Java community process called OSS through Java (OSS/J).

The goal of OSS/J is to move service provider vendors onto a multi-tier architecture, based on reusable components and container technology, with client access either by tightly or loosely coupled mechanisms. The interfaces/implementation are all based on the use of J2EE services.

Other Things to Consider
In addition to the points above, here are four other elements that designers need to consider during the design/development of network management systems.

1. Scalability and Reliability: Just as scalable, reliable hardware devices are required in carrier networks, the same is true of the element management systems. Given the large number of devices managed at the edge, robustness and fault tolerance is a must. An EMS must include redundant servers so that if one fails, a hot standby takes over so that load may be spread across the server.

As with the EMS, next-generation service-edge routers must have support beyond the norm that allows them to be controlled by multiple EMS instances and updated/read concurrently, while ensuring the transactional integrity of the router's configuration. Since edge router configurations can be enormous (many thousands of interfaces, QoS attributes, etc.), the configuration database must be optimized to enable incremental updates while ensuring consistency in the presence of concurrent updates.

2. Security: Application server technology provides the security required in service provider networks and also off-loads portions of security management from the device. For example, customers can access their own services via authentication.

3. Device-Level Support: Successful element management requires support in the native device and often must be designed into the device from inception. No matter how intelligent an EMS is, if corresponding support is not provided in the hardware device, the functionality is useless. For example, devices should support concurrent sessions. Transactional access to the device database as well as a distributed device architecture is a must.

4. Efficient Communication: Application server technology supports the ability to cache information off the device to enhance efficiency by reducing the number of queries to the device. Provisioning services can do a fair amount of validation, gather queries together and efficiently pass as one call to device. If the transaction fails, the EMS can quickly back out of entire session.

Future Trends
The distributed model described above, which is increasingly being adopted by vendors supplying service provider equipment, highlights the fundamental shift to a standards-based, distributed approach to service provider network management. Other trends of note include:

1. A continued migration to application server technology. Carriers and network management systems are all moving to this next-generation approach. The initial adopters of this approach are new equipment vendors without legacy equipment. Carriers are also moving to this approach in their overall network architecture migration plans.
2. Increasing adoption of standards by vendors: Clearly, standardized interfaces reduce the amount of work needed to integrate new devices (and their element management systems) into an OSS. Rather than having to tailor support for each new edge router, a common interface both reduces the integration effort as well as speeds up the adoption of a new device.
3. Providing more control to end customers: Edge services should be customizable by the customers of those services. Providing support to do so requires a flexible security model and appropriate infrastructure to allow customer-specific views to be generated by the OSS. Web-based technology is ideally placed to meet these requirements.
4. Integration/synergy between EMS and device in earliest stages of design: From a device's point of view, management should be a "first-class citizen" and not an afterthought. For example, the success of VPNs is tied to their ability to be managed. This is a necessity as devices and services become more complex.

Final Thoughts
Network and element management is becoming a key component in service provider networks. Both carriers and equipment vendors are increasingly turning their attention to the ability of management systems to increase efficiency and service delivery while reducing costs. The service provider equipment industry is adopting the best practices successfully deployed by the Web application server market to take a distributed, standards-based approach and apply it to the service provider market.

That wraps up our two-part series on service-edge router design. To view part 1 of this article, Click Here.

About the Author
Graeme Dixon is a chief architect for service provider edge platforms at Laurel Networks. Prior to joining Laurel Networks' team, he was the lead architect for IBM's WebSphere Advanced product and an elected member of the IBM Academy. Graeme received a Ph.D. in Computer Science from the University of Newcastle in Tyne, UK and a B.Sc in Polymer Science and Technology from Manchester Polytechnic in the UK. He can be reached at graeme@laurelnetworks.com.