Eventually, vendors will develop networking hardware that takes advantage of DEN specifications. This hardware will receive configuration information or other event-driven notifications directly from the policy objects stored in the directory. This level of integration will enable Quality of Service (QoS) policies to be enforced dynamically based on user logon, bandwidth saturation, or other events. (For more information about QoS, see Tao Zhou, "Build a Better Network with QoS," November 1998.) This capability will also allow for end-to-end bandwidth provisioning and security based on application or user policies.
Although implementing DEN will be beneficial, you will need to conduct much research and planning to reap the rewards of successfully combining directory services and network management applications. The base schema are fairly straightforward to implement, but the concept of modeling network elements to fit into a hierarchy isn't. In general, directories are repositories for nonvolatile information with many reads and few writes. Network elements, however, sometimes don't fit into this category. Network elements exist in a dynamic, event-driven environment and constantly change their state to adapt. Thus, you will need to maintain many configuration attributes outside the directory to maintain responsiveness. You will need to determine through trial and error how much configuration state information to store in the directory to provide meaningful analysis without creating synchronization difficulties.
Another consideration is that the directory you use will also likely replicate across your WAN. You will need to balance the additional bandwidth requirement for replication against the manageability that DEN provides. Another area of consideration is access to information. Although LDAP is the most common method for accessing directory data (and the method that DEN specifies), LDAP is not a panacea and will not solve all of your object query woes.
The key to a successful implementation will be collaboration between your network designers and directory designers. Initially, understanding the directory concepts will be critical to take advantage of DEN. However, as vendors make more network devices LDAP-enabled and store and configure more network elements via the directory, you will need a better understanding of the underlying networking infrastructure to provide appropriate functionality and responsiveness. (For more information about vendors' proposed offerings, see the sidebar "Many Vendors Getting on the Bandwagon," page 103.)
DEN and AD
DEN will work with any directory that supports LDAP 3.0 and has an extensible schema, including the Windows 2000 (Win2K—formerly NT 5.0) Active Directory. AD contains the DEN-specified classes and attributes as part of its default schema. In addition, many of Win2K's networking services use AD's policy inheritence information. For example, packet-level encryption (IP Security--IPSec) uses AD's user and group policy information. In fact, the user attributes store the x.509 certificate that IPSec uses. (For more information about IPSec, see Tao Zhou, "Internet Protocol Security in NT 5.0," August 1998.)
Another networking service that uses policy information stored in AD is the QoS protocol Resource Reservation Setup Protocol (RSVP). By exposing network element attributes and user policy information through component object model (COM) objects, developers can write directory-enabled applications that can provision their bandwidth and encryption based on internal events. Such applications will conserve resources on network devices because resource provisioning will no longer need to take place at the IP address or subnet level.
For example, developers could write a directory-enabled application for a brokerage house that provisions bandwidth and encryption based on the type of user request. If Web users request research information from the company's Web site, the application provisions only enough bandwidth (low-priority packets) to guarantee a response within a few moments. However, for a trade execution, the same application uses the same infrastructure to provision appropriate bandwidth (highest-priority packets) to guarantee instant response while also encrypting the session to secure the transaction. The packets for the trading transaction go through first, and the packets for the information request must wait. Developers could also write an application that performs more detailed provisioning by having the application examine the Web user's profile or analyze the content of the trade execution before it provisions packets. The key is that the application dictates the behavior of the network devices over which its transactions travel. The application treats the network as an integral part of the system. This behavior is similar to capabilities that have previously existed only in the mainframe world through message queueing and transaction monitoring.
Figure 2 illustrates RSVP in a directory-enabled network. The figure depicts the flow of low-priority traffic (from an FTP stream) interacting with high-priority traffic (from streaming video) across a directory-enabled network using RSVP to provision resources appropriately for each application.
Add DEN to Your List
Can you take advantage of DEN today? No, but you need to add DEN to the list of tools to consider as you plan for Win2K. You also need to consider DEN if you are planning to purchase hardware, such as routers and bridges.
As you plan for AD, start thinking about groups of users and applications that can benefit from consistent policies and profiles. Ask networking vendors what they intend to do about DEN and have them explain how DEN might benefit your network. Whether or not DEN makes sense for your network, you need to understand this draft specification and its implications because directory services and network management applications are converging. Directory-enabled networks will do for applications what the LAN did for PCs.