Policy-Based Networking: Working Hand in Hand with DEN
Directory-enabled and policy-based networking will provide network managers and administrators with a powerful new way to both configure and control large enterprise networks. By now, most networking personnel have at least heard about directory-enabled networking (DEN) and its benefits. Policy-based networking (PBN), on the other hand, is still a little bit arcane and obscure. Over the next 12 months, however, DEN and PBN will quickly come to the forefront of the networking industry, and, in tandem, offer an entirely new way to run large, complex networks.
The "directory" in directory-enabled networking is simply a database that is designed to hold information about networking devices. Its value lies in the fact that the information in the directory can be used to automate many of the tasks involved in operating an enterprise network.
Imagine a network administrator tasked with the job of adding five routers to the enterprise network. Without DEN, the administrator would be forced to connect to and set up each router's configuration parameters, one after the other. This would be a complex and time-consuming task that no one would describe as a pleasant experience. But with DEN, this entire process can be automated. In a directory-enabled network, configuration information for each manufacturer's router is prestored in the directory. When the time comes to add routers to the network, each router simply retrieves its configuration parameters from the directory, configures itself, and finally goes online. This is certainly a better way to add and configure devices in a large, complex enterprise network.
When used this way -- to configure networking devices -- DEN's benefits are obvious. If fact, it parallels the experience of NOS administrators who learned the value of directory services when they began to use NDS to configure and manage NetWare networks. But DEN's power doesn't stop there. When directory services are combined with policy-based networking, an entirely new level of control is brought into the network.
Imagine a senior sales executive who uses NetMeeting to videoconference with regional sales managers each Friday afternoon. Obviously, there must be sufficient bandwidth in the network so these videoconference meetings can take place. In the past, manual intervention would have been used to set up the required bandwidth on the specified date and time. But with a PBN, this process can be automated. To do so, a network administrator creates a policy beforehand that specifies the bandwidth requirement, the time of day and date when it is needed, and then associates this policy with the name of the sales executive who is authorized to use the network for videoconferencing purposes. And there is one final point: The executive's name and the policy are both stored in the directory service.
When Friday afternoon arrives and the executive launches NetMeeting, a series of protocol exchanges are fired across the network. These exchanges occur between two logical entities -- a policy enforcer and a policy interpreter -- that most likely reside in two different places. The policy enforcer is located in a networking device very near the sales executive -- a router, for example -- while the policy interpreter is located in a policy server device.
Procedurally, the process works like this: First, the policy enforcer in the router detects that someone is attempting to use videoconferencing. Before setting up resources for this purpose, the enforcer contacts the policy server to check if the user is authorized to use videoconferencing and to determine if the person is allowed to use videoconferencing at this particular time and on this particular date. The policy server, in turn, contacts the directory service to retrieve the policy information stored there for the sales executive. Since it also needs to know the date and time, it also contacts a timing service in the network. After combining these pieces of information, the policy interpreter makes a judgement -- based on the policy from the directory and the time/date from the timing service -- on whether or not to allow the videoconference to proceed. If its decision is affirmative, it returns a response to the policy enforcer in the router telling it to set up the videoconference for the sales executive. Significantly, this process can be repeated each Friday, endlessly, until the policy for the sales executive is changed. And no manual intervention, with the exception of creating the policy for the executive, is needed.
In tandem, directory-enabled and policy-based networks will automate both aspects of network management and administration: device configuration as well as network resource allocation. --Sam Alunni is vice president of networking at Sterling Research (Sterling, Mass.). Contact him at firstname.lastname@example.org.