Beyond Layer 3: Delivering Differentiated IP Services

Nowhere is the need for OSS automation felt more keenly than in the rollout of enhanced IP-based services, where both the obstacles to service fulfillment and the potential rewards of timely delivery are greatest. With broadband access becoming more of a commodity and profit margins for these services narrowing, providers must look beyond basic high-speed access to the enhanced IP and bundled services that it enables: quality of service (QoS)-aware IP VPNs, application hosting, voice and data over broadband, distributed video and virtual LANs (VLANs).

The Fulfillment Challenge

Whether in response to industry buzz, high-octane applications or a competitive marketplace, customers now demand differentiated services that match their specific needs. They want different QoS levels for different applications, user groups, business locations, or times of the day, week or month. They want customer self-care and on-demand fulfillment of service changes and service requests. They want new voice and data service bundles. And they want it now.

Even though there is a strong demand for these value-added IP services, defining, delivering and maintaining them is no easy task. Providing them ultimately means greater revenue opportunities, but also greater service fulfillment headaches. Today’s IP services networks are an amalgam of equipment types and technologies, spanning various network layers and vast geographies. Provisioning services across such networks requires careful mapping of network and service policies across diverse elements that are, in many cases, managed by different departments within the service provider organization.

Today designing and activating IP-based services (implementing those network and service policies) frequently rely on a combination of manual device configuration, multiple element management systems (EMSs) and often static inventories of network assets—all of which significantly delay time-to-service and introduce considerable risk of provisioning errors and activation failures. Adding a new member site to a VPN, for instance, can require manually configuring customer edge (CE) and provider edge (PE) routers (including VPN associations, routing protocols, address filters and address allocation), as well as provisioning the access and transport networks between these routers (which itself can require knowledge of multiple protocols—Ethernet, DSL, ATM, Frame Relay, SONET—and the use of multiple EMSs). And then there’s updating the various spreadsheets and databases that track IP address assignments, virtual path identifier/virtual channel identifier allocation, available assets and the like. Or consider the provisioning of a VLAN between geographically dispersed locations, where VLAN tags must be established on every node within every ring between the service endpoints. In each case, discrete management systems and manual provisioning processes prohibit rapid, accurate and consistent service delivery.

Difficult and time-consuming as the provisioning and activation of IP services can be, these tasks are often just the beginning. Service providers face equal challenges maintaining established services as their networks, service offerings and customer base evolve. And interruptions from routine network maintenance (for load balancing, network re-grooming, service upgrades, bulk service moves around failures) become even more problematic when customers are paying a premium for differentiated services and the service level agreements (SLAs) that guarantee them.

In addition, the complexity of today’s IP service networks, the terms for offering value-added IP services and the importance of these services to a carrier’s viability all place even greater requirements on how these services are designed, delivered and supported.

But what precisely does all of this mean for independent software vendors (ISVs) or equipment vendors attempting to offer end-to-end systems for IP service fulfillment? It almost goes without saying that their fulfillment applications must be scalable, support multivendor networks and offer off-the-shelf support for at least the most common IP services (e.g., MPLS-based IP-VPNs). They should accommodate the introduction of new technologies and new equipment without disrupting existing services and operations. And they should integrate easily with other components of the service provider’s OSS.

Building Differentiated Services

Historically the most significant obstacle to mass-market adoption of IP services has been the lack of guaranteed QoS in best-effort IP networks. This was demonstrated most palpably in the hesitation among Fortune 500 companies to move away from private line and Frame Relay services to IP VPNs. Providers have since learned that their ability to offer differentiated services, guarantee QoS and establish SLAs for emerging IP-based services could likely determine their future profitability and success.

Various efforts have been made to resolve the IP service QoS issue at Layer 3, introducing into IP assorted mechanisms for reserving resources and prioritizing traffic flow—differentiated service (DiffServ), per-flow queuing and Resource Reservation Protocol (RSVP), to name a few. Several ISVs and equipment vendors have proposed provisioning systems based on these mechanisms. Yet tackling QoS and IP provisioning strictly at Layer 3 does not entirely address the dilemma.

IP service fulfillment must facilitate the definition, provisioning and activation of QoS-aware IP services end-to-end by integrating otherwise distinctly managed policies and by automating and leveraging the various control mechanisms available from the network—whether they be the product of IP or the underlying Layer 1 and Layer 2 technologies.

Defining Services and Service Levels

IP fulfillment systems must speed order entry and simplify service differentiation. That means presenting network and application services—whether through a GUI or API—from the subscriber’s point of view, shielding operators from the complex object and policy associations required to enable those services end-to-end, across a variety of technologies and vendor equipment. It also means enabling carriers to predefine policy-based service profiles that can improve order consistency, expedite service delivery and provide a basis for differentiated service levels and their tiered pricing.

With subscriber requirements in continual flux, providers also need a means to create new services and service bundles virtually on the fly. An IP fulfillment application, therefore, must enable network operators themselves to define how higher-level service objects (the service model) map to lower-level constituent elements—the technology and vendor-specific attributes recognized by the fulfillment application’s core engine and object models or by the individual network devices. With such an application, providers can swiftly respond to changes in customer demands, roll out high-margin services and bundles, and penetrate new markets.

End-to-End Also Means Top-to-Bottom

Simplifying service definitions certainly improves IP service fulfillment, but it’s the automated provisioning and activation of those services that introduce substantial operational savings and ensure customer satisfaction.

Service provisioning has traditionally been cumbersome, time-consuming and error-prone. Provisioning IP services is no exception, particularly given the variety of topologies and technologies supporting these services (Ethernet, Gigabit Ethernet, DSL, ATM/Frame Relay at the access; ATM at the edge; SONET/SDH, DWDM, MPLS in the core). Things get even tougher when end-to-end service level requirements are thrown into the mix, bringing with them a potential host of attributes for defining performance at Layers 1, 2 and 3.

Regardless of the infrastructure and the performance criteria, however, what carriers are providing when they deliver IP-based services is, quite simply, connectivity between routers. Whether that connectivity is over ATM, Ethernet, DSL, optical or some combination of these, and whether that connectivity is controlled by rigid QoS and security parameters, it’s the job of the service fulfillment system to automate provisioning of the path between routers, integrating policy across multiple network layers.

To do this, the system must be able to select least-cost routes that span technologies and vendors and that adhere to the specific policies for the subscriber’s service, end-to-end. The system needs to automate both the router configuration (routing protocol, address management, VPN membership, user access rights, packet and route filters, DiffServ, traffic shaping) and the design and activation of lower layer circuits—all in accordance with service level expectations. To give providers greater control over network performance and resource utilization, the system should also offer flexible routing options, automatically threading services end-to-end, utilizing underlying protocols for routing decisions across portions of the service path or allowing operators to route services manually.

Garbage In, Garbage Out

Even the most efficient and sophisticated provisioning system in the world has limited value if its decisions are based on inaccurate network and service information. Obsolete or incomplete inventory data translates into high rates of order fallout and increasing volumes of stranded assets. Therefore, an IP service fulfillment system must be able to discover and regularly upload network and service information from the network, including nodes, physical and logical ports, IP interfaces, Layer 2 circuits, IP addresses and communities. With an accurate view of the network’s in-service inventory, the provisioning system can then confirm resource availability before services are designed, resources are assigned and service transactions are applied to the network. These reality checks minimize order fallout and significantly increase service provider efficiency. They also enable customer care personnel to verify the availability of network resources before making delivery commitments to customers.

Automated and regular synchronization with the network also facilitates recovering stranded assets by isolating resources not associated with existing services. This capability becomes particularly critical at a time when network build-outs have been put on hold and service providers need to utilize all available resources for revenue-generating services. Visibility into the accurate state of the network also enables more effective network planning, whether that entails defining future expansions or more immediate load-balancing strategies.

The Provider’s Job Is Never Done

Still, delivering a service quickly, efficiently, and accurately represents only part of service fulfillment, significant though it may be. Maintaining that service—continuing to deliver on service objectives—can prove equally critical and challenging. Routing around link failures, performing routine network upgrades, even making carefully timed service migration efforts can all threaten service integrity.

As providers evolve their IP-based portfolios from best-effort to differentiated, minimizing service disruption and degradation will be critical to meeting SLA requirements. To limit interruptions, providers must automate the numerous, otherwise manual and time-consuming delete-create operations required for service moves. And they must be able to correlate subscriber, service and network information to minimize interruptions for premium customers.

Looking Ahead

Well aware of subscribers’ desire for service level guarantees and providers’ interest in network optimization, the Internet Engineering Task Force has been working to standardize constraint-based routing and traffic engineering for differentiated services. Key among the approaches is defining explicit routes across MPLS. The theory goes like this: Providers will control the behavior of aggregate traffic flows (or traffic trunks) across label-switched paths by using forward equivalency classes and attributes for priority, preemption, resilience and policing. Thus they will be able to optimize network performance, resulting in more consistent, end-to-end QoS and greater network efficiency.

Central to the success of delivering IP services over traffic-engineered MPLS-based networks are many of the same elements that facilitate the delivery of IP-based services over today’s multivendor, multitechnology networks. These include:
· Knowledge of the physical and logical networks and their available resources, critical for both path selection and network planning
· Mapping service-level behaviors to device-specific attributes
· Designing service paths between routers, possibly across multiple networks (separate MPLS networks, for instance, or Layer 2 access networks and the MPLS cores they feed), all in accordance with network and service policies
· Taking advantage of embedded routing intelligence where appropriate and explicit routing where more practical
· Modifying the parameters of existing services on demand and end to end.

Automated IP service fulfillment applications will play a key role in defining, implementing and supporting enhanced IP services as industry standards continue to evolve. And as networks themselves evolve—whether through expansion, provider consolidation or technology migration—automated fulfillment applications will continue to bridge the inevitable gaps between technologies, vendors and once-disparate operations.

Douglas Chapman is co-founder and chief technology officer of Syndesis, which provides automated service fulfillment systems. He has over 22 years of experience in network and systems design and holds a B.Sc. in Chemistry and a M.Sc. in Computer Science from Queens University. He can be reached at chapman@syndesis.com.