Directory-Enabled Networks: Developing a Model for Information Management

Efficiently managing subscriber account and provisioning information is critical in today’s carrier and provider support systems - where considerable volumes of data identify both the customer and the relationships between various network systems. Directory-enabled networks (DEN) hold promise to greatly improve the distribution of customer information, and has gained considerable attention by service providers. , who are currently weighing the pros and cons of this technology and considering whether or not the DEN architecture makes a viable business case.

The need for directory-enabled networks is extremely strong, says Larry Gauthier, senior analyst The Burton Group. In the past, IP-based network elements offered a single class of service, known as best-effort networking,, which meant that every user and application shares the “pipe” equally. This approach offers affordable connectivity and a compromise between dedicated bandwidth and cost. However, as services expand, IP-based applications are going to require increasing amounts of bandwidth, low latency, and low drop rate. Best-effort networking over IP infrastructure (i.e., the Internet), Gauthier says, is not going to cut it.

To address the needs for advanced services, networks must adapt in two ways. First, routers, switches and hubs need to accommodate efforts to improve QoS, delivering differentiated services to different applications and users. Second, the network needs to identify the user, time and application used. A directory is the ideal mechanism to identify user profiles and to determine the QoS level assigned (i.e. paid for) by that customer.

“The fact that we can get all that information into a single repository is really where the significant benefit is,” says Mike Marshall, senior product manager at Unisphere. The alternative to providing automatic end-to-end provisioning of these services is often problematic, with many operations centers across the country, each provisioning a different level of the service. In a cable or digital subscriber line (DSL) environment, there may be hundreds, thousands, even millions of users across the breadth of the physical network. Distributed management at the network level is needed, while subscriber management needs to be centralized. Storing all subscriber information in a central directory—name, address, contact details, rating and usage information—enables providers to effectively manage such information.

Today, vertical segments of information often plague enterprise networks. In the same system, silos of information pertain to a certain product in respect to billing, provisioning, fault or performance monitoring as well as element management. Information silos also tend to exist within specific service or technology domains as well. For example, any information about dial services might be integrated only within the scope of dial services, while the same might be true for DSL, virtual private networks (VPNs), or any other specific technology.

“That is really the crux of the operational problem for service providers,” says David DiGirolamo, manager of product marketing, Network Service Management Business Unit, Cisco Systems.

The “D” in DEN

Directories contain large volumes of relatively static customer information that must be durable in nature, rather than transaction focused. The purpose of a directory is to address the way users relate to network services. Directories can also house policy information about applications, QoS or security, and are also useful for storing long-term information such as user or service profiles. Although writing to a directory is often less efficient than writing to a database, the information can be read in an extremely efficient manner, as a directory allows quick access to specific, relatively unchanging information.

“Directory-enabled networking is really about a new marriage between policy-based networking services and the operating environments—the applications, the users, the servers up in the applications layer of the world,” notes Jim Turner, director of marketing, enterprise management for Cisco Systems. Turner explains that the real promise of DEN lies in the model of a common repository of information shared by the network infrastructure and the policy servers within the network as well as the applications environment accessing that network.

In a directory-enabled network, users are associated with services and network elements, such that all of that information necessary for a particular function by a given service provider actually becomes resident in the directory. Typically, this information would include the user identification, a billing code and a service code that delineates what types of services are provisioned for that user. This information is handed down from the directory throughout the rest of the information environment.

The Lightweight Directory Access Protocol (LDAP) has been adopted for directories as a common access protocol to provide fine-grain resolution, through security access control services that allows sharing of information between applications on a very selective basis. Key to expanding use of the directory technology is the adoption of an information model that is based on object-oriented technology (OOT). The model’s schema defines objects and their relationships with one another. The model for directory-enabled networks is repository independent meaning it can be implemented via a directory or as a directory on top of a database.

With OOT, hierarchies must be defined so that any changes to the data are relayed down throughout a system. The DEN initiative involves the creation of the schema for directories (see sidebar, page 74). To date, vendors have been creating mainly proprietary versions of directory technology. Now they will be tasked with integrating the standards into their products as they are further developed. As well, companies implementing directories face integration challenges as OOT must interface with legacy systems (see “Fusion: A Look at Objects as a Solution for Telecom Service and Operational Requirements,” TelOSSource University, volume 2).

The Big Daddy of Directories

A metadirectory involves federating multiple directories that share disparate sets of information. If a company has 10 million subscribers spread across the country, a single customer service center could not handle all of this information, though it might need access to all of it. A DEN would allow a company to federate those directories and distribute them; the network could be split up into regions on a state-by-state basis, with a customer support center responsible for each one of those regions. Logically, the directories would be in sync, so if a particular user were to want service in a different part of the directory they could access it. An example might be a business user in New York who is traveling in California and who wants to be able to access his VPN. A subscriber could access a local point of presence and gain authentication locally without having to get authenticated through a directory in New York. This location independence is a plus for subscribers who need to operate from multiple sites.

According to Turner, a metadirectory could have mapping capabilities that can take information available from any kind of repository, such as a relational database or a private flat file. Information about a user could be changed across an enterprise when an administrator makes a change in the enterprise’s directory service. Changes would propagate out from the metadirectory into directories hierarchically below it. This allows companies to conduct business on a global scale. “You want the same access policies applied whether they are in New York or Kuwala Lampur,” Turner says. Directory-enabled networks are going to be “the glue that allows you to authenticate yourself and authorize you to do things on the network,” Gauthier believes.

When a subscriber accesses a service, authentication can verify that the subscriber is allowed use of particular services. If multiple directories are synchronized, there is no need for a manual authentication. Marshall explains that directories can allow a subscriber to customize services to which he already has access. In addition, the concept of a traditional portal can be applied to a directory-based network from a services perspective.

“I can customize my own portal to the types of services I want to subscribe to. That may include a list of voice over Internet protocol destinations I want to call frequently. It may include video on demand or audio download. The next time I go into my service provider, I am going to be presented with exactly the same set of preferences that I already have, so then I simply have to click on an icon on my Web page and I’m automatically connected—all the authentication is dealt with from the first time I access this,” Marshall says.

Implementation Pains

While carriers could see many benefits to implementing directory-enabled networks, the cost involved in establishing a directory can be high. “The incremental costs of the network side is relatively low compared to the relatively high cost of the initial installation,” Turner says. He believes companies must determine whether the pains of designing and installing a directory are justifiable. They are not going to create a directory to handle QoS, rather, Turner says companies will implement directories primarily to manage multiple services where improperly administering the user identity across the enterprise could mean high administration costs, security problems, loss of business services or poor customer service. “What we see is people implementing the directory service to manage user identity and then once they have made that investment, they extend the value by incrementally adding in directory-enabled networking functions.”

Tying it All Together

Because billing systems deal with transactional data, billing information is not housed in the directory. Interfacing billing and the directory can be done in two ways, according to Gauthier:

??The DEN forwards the transactional information into the directory, and that information is passed onto the billing application through synchronization. The directory updates the billing application regularly concerning transactions.

??Real-time processing would be enabled by database triggers. Every time a change occurs in the database the directory is running on, that database triggers an event that sends transaction information to the billing application.

Billing systems have service catalog information, as well as information about the network services where it will decompose. Yet, the same billing systems may not have an understanding of the network devices provisioned to deliver that service, DiGirolamo says. With an industry-standard information model those services can be decomposed into actual network-level services and decomposed further into specific devices or device interfaces that have been provisioned.

The QoS must be determined before billing occurs, so that the bill can be prorated if necessary. To do this, the QoS for a particular user, customer or application needs to be understood. A common repository or virtual repository could store that information, providing an ability to reference that gives a billing-mediation or billing vendor the opportunity to perform these measurements. The common repository and information model provides information about devices and the QoS or SLA. While a monitoring tool may be required to actually measure the latency between two points, the billing system would have the information it needs about those two points.

Or Your Money Back

Policy-driven networks provide a way to deliver QoS for various users and applications. The policy engine needs to know the level of service the customer expects to receive and, in a directory-enabled network, this information is stored as part of the users’ profile. A policy engine uses the directory information to track the level of QoS the subscriber receives.

The directory does not actually do the monitoring. This work is done by the billing, mediation or monitoring systems, which need that information to be able to provision themselves to be able to do their work. That is where the information model comes in.

A billing mediation tool might only be a toolkit to instrument the network to aggregate, to correlate and to push up. But for this application to do its job—whether it is the billing system itself or whether that is delegated to a billing mediation layer— the customers, the QoS level, and network elements involved must be defined. An information model that describes these policies is necessary to relate that information to the specific devices on the network. A typical exception would be a certain rate of packet loss. Although the directory does not get involved in the actual process of monitoring a packet count, it stores the static information that allows the policy engine to understand the level of QoS for a specific customer. By monitoring the policies against the level of QoS in real time, service can be modified so traffic can be redirected through a higher quality local exchange carrier. Parameters would determine the level of rebate the subscriber would be eligible for based on a violation of that QoS. Thus, using the directory to store profile information that is matched to the work of a policy engine, allows measurement for QoS that can be rated by the billing system. Scalability and Beyond

If, every time a new component is added, translation and integration layers must be created between the product and every other existing OSS system, that quickly becomes a lot of work, DiGirolamo says. “If, on the other hand, we share a common information model … I’m taking every new service or every new component, and I’m integrating it into the overall OSS architecture. I’m doing a single integration rather than a point-to-point integration with every other piece that exists.”

In addition, typically a service or component is really a closed system. In the directory-enabled networking world, an existing service can be extended from its original information model and customized accordingly. For example, a VPN service purchased from a particular vendor could be deployed, customized and upgraded.

“I’m enabled to do that and it’s not a fork-lift upgrade where I have to throw out the old service to roll in the new service. I can take what I’ve got where it sits and easily extend it,” DiGirolamo says. “Every time there’s a new service, one of the gaining factors as to whether I succeed or not in this environment is how quickly I can roll out my new service, how quickly I can add features to my existing service to match those of my competition. If I’m late to market, it’s typically winner take all, so being late is a very bad thing,” DiGirolamo adds.

Thus, directory-enabled networking can give a carrier an edge, since each product does not have to be integrated.

Migrating to DEN

“It took them many years to build these [systems] and to perform all the laborious integration to get them to where they are today,” DiGirolamo says, explaining that service providers are not going to throw out existing OSS/BSS systems. Instead, DiGirolamo suggests migration will take a phased approach.

Costs will be incurred in two places: first, building an enterprise directory that allows for the delivery of a variety of services; and second, existing hardware must be replaced with directory-enabling hardware and new generations of routers and switches that are compliant to these protocols.

“This isn’t stuff that comes from Radio Shack,” Gauthier says to illustrate the cost involved. “Companies are going to have to make some rational decisions about who needs the technology, where they need it the most, or even who can afford to pay for it.”

Legacy Issues

Legacy systems—which may or may not have APIs—have their own concept of what a user is and what a service is. These legacy systems will not have a common understanding of a directory-enabled network. If a wrapper is placed around legacy products, products need only to be integrated with the architecture, rather than every product. If a translation layer is written that translates from one product’s information model to the common information model, it that development will only need to take place once, and can then be leveraged for every other service rollout, DiGirolamo explains. Also, a provider could build directories on top of existing database platforms.

“We probably are going to see a number of database vendors who, for example, will put … an LDAP interface on top of their existing database,” DiGirolamo says. Since CIM/DEN is repository independent, it is not necessary to take a database and make it into a directory or vice versa.

Taking it on

“I think the adoption rate up until now has been relatively slow just because of the lack of understanding of the technology and the way that it can be applied,” Marshall portends. Gauthier explains that the fact that the standards for directory-enabled networks are still being developed is one reason why this model has yet to be deployed on a wide-scale basis. Products that are just starting to emerge on the market are highly proprietary, and a company that goes with such a product early on could face pains down the road, he adds. Yet, a number of vendors have been building products around the emerging standards. Microsoft’s Active Directory, Novell’s NDS eDirectory, Sun/Netscape’s iPlanet, IBM’s SecureWay Software and Oracle’s directory service all incorporate the directory philosophy to network information management.

As the standards for directory-enabled networks are further developed, vendors will likely adapt their existing technology for wide-scale industry use.

AT&T: Sold on Directories

AT&T began using proprietary directories in the mid-1990s. The company’s major requirement was that the directory would have to scale to tens of millions of entries. AT&T formed a partnership with Novell to jointly offer service with Novell’s directory technology and has been a strong supporter of the Directory Enabled Networks Initiative (see sidebar, page) . Today, AT&T is using large-scale high-performance Lightweight Directory Access Protocol (LDAP) directories to deliver some of its newer services. “We see it as a way for helping us deal in a single place with what otherwise would be overwhelming complexity in provisioning our services,” says Frank Field, IP platform planning and development vice president at AT&T Labs. He believes there is a tremendous advantage for carriers who use directories as a single point in which to keep customer information. AT&T must be able to understand all the places where customer information is kept in order for their services to work, Field explains. Likewise, the carrier must have customer authentication to give access to the appropriate services. “Absent a directory, we would have to go and make separate entries into databases, in our authentication system, in our service selection system and in our billing system,” Field explains. “With a directory in place, we can make a single entry and we can then feed that information to our billing system or we can look the information up dynamically as it is needed. So we provision things in one place instead of three.”

Because data is entered only once, fewer mistakes are made, which translates into better service for customers and lower costs for the carrier, Field maintains. He adds that a carrier could improve time-to-market for new services because integrating those new services in with LDAP is easier, and customer information is already contained in the directory. These factors contribute to a cost savings as well. AT&T links customer registration information from the directory to the billing system. Once a day, the carrier spins off all the changes to its billing system. AT&T developed an interface to one of its legacy billing systems to do this. Field says this method improves accuracy.

AT&T has plans to extend the use of directories to address differentiated services, according to Field. “In the future, as we begin to make some of our networks policy-based, supporting things like different QoS grades on our IP networks, we’ll store that information right in the same directory where we keep the customers credentials today: their ID and password.” While many people say that cost will be a barrier for many carriers in developing directory-enabled networks, Field says AT&T did not find this to be a problem. “We saw it as an investment that is going to enable us to operate networks with improved performance, lower cost and improved billing accuracy.

The DEN Initiative

The DEN initiative to drive directory technologies was born in the late 1990s out of a partnership between Microsoft and Cisco Systems, and about 180 companies joined effort to promote standards for directory-enabled networks.

A draft of the DEN specification, agreed upon in 1998, was handed off to the Distributed Management Task Force (DMTF) to be developed into a formal standard. The DMTF had previously developed a broader common information model (CIM) focusing on the problem of the management information exchange between management environments. In June of 1999, DEN was incorporated into CIM.

Implementing CIM and a common directory schema provides multiple vendors’ applications with the ability to read whatever information is published in a directory service using the DEN standard. The standard uses object-oriented technology to create relationships between user, facility and service information, for example, allowing for an end-to-end view.

According to DiGirolamo, CIM 2.3 will include some extensions in the area of policy. In March, the DMTF ratified DEN, which delineated the way DEN is mapped into an LDAP-accessible directory schema.

Ray Williams, vice president of technology for the DMTF, believes the DEN model will be a common underlying technology in network systems in the future. It is a methodology that will allow companies to build integrated data networks. “It will just be inherent,” Williams says, much like TCP/IP is today. “It’s something that you’ll take for granted.”