Policy-Based Networking and Legacy Devices
Without doubt, policy-based networking (PBN) is going to revolutionize the way we view networks. At some time in the future, networking devices will be able to access their configuration information from a directory service and then immediately go online.
The tedious chore of configuring networking equipment via command line interfaces will be gone forever. Better yet, networking devices spread across an enterprise will be able to set up and tear down resources according to policies established to meet business objectives. RealPlayer listeners on one day will find little bandwidth available to listen to their favorite radio station, but on the next will be told to listen away between 10 and 12 o'clock as their CEO reports the latest financial results. Policy-based networking will make RealPlayer a villain one day and a business-application hero the next, all due to the different policies written for its use.
So much for five plus years down the road. But what about the present, or at least the short-term future?
Policy-based networking is obviously desirable, but will it demand forklift upgrades to get the equipment infrastructure to support its marvelous capabilities? Or worse yet, will buyers have to pay for policy-based networking features in their new equipment and then bemoan the fact that it doesn't work with their legacy gear, some of which won't be deinstalled for years? The good news is that some equipment manufacturers have taken this problem into account and are beginning to articulate their approach to solving the legacy equipment migration problem in policy-based networks.
One approach to solving this problem begins with classifying all the devices in a network. Fundamentally, there are four categories of equipment in a hybrid legacy/PBN network.
Very dumb devices are at the bottom of the category list. These devices are limited in two ways. First, they lack the ability to contact a policy server to inquire about a particular policy for a user or an application. Second, they do not understand the protocol that a policy server would use to tell them that it is okay to set up resources for an approved user or application.
For these very dumb devices, a policy proxy is needed to push policy information into them and to convert this information to a protocol they understand -- something like SNMP or RADIUS. Through this technique of "push and convert," even dumb devices in a network can be forced to set up quality of service features to support a particular policy established for a user or application.
Somewhat smarter devices are at the next level in the hierarchy. Equipment in this category can't ask a server about a policy for a particular user or application, but they do understand the protocol a policy server uses when it sends out its approval to allocate the resources specified in the policy. At first, this "half-step" approach may seem odd: the device can't ask a policy question, but it understands the "pushed" answer related to the policy on the server.
The rationalization for this approach, however, is quite simple. Devices in this category probably will be extremely cost constrained. As a result, it would be prohibitively expensive to install a policy client (the questioner) in them. Another reason relates to performance. Since this is a low-cost device, there is a fear that throughput would suffer if the device spent too much time asking questions of the policy server. Thus the half step approach. In operation, these devices go their merry way forwarding traffic as needed until they are commanded by the policy server to change their resource allocations.
The next tier up contains devices that support a policy client, therefore they can interrogate a policy server, but do not support the protocol in a way that they can understand the response from the server regarding its interpretation of the policy. Once again, the approval -- or disapproval -- concerning setting up or denying resources must be translated into something like SNMP or RADIUS so these devices can understand it.
Again, this ability of a device to ask a question but not understand the answer may seem odd, but this explanation, too, is quite simple. These devices probably have an intermediary market quality about them. They are likely to be purchased after standards are set for policy inquiries, but before standards are set for the policy client/server protocol exchange.
Finally, at the top of the hierarchy are devices that support all the features needed to enable policy-based networking. In effect, these are the dream machines -- networking devices that support both policy-client capability as well as the ability to understand policy protocols.
Over all, the message is clear. The PBN endpoint in network design is still in the distance, but equipment manufactures have thought out the game plan to get there in a way that takes into account legacy equipment inadequacies. -- Sam Alunni is vice president of networking at Sterling Research (Sterling, Mass.). Contact him at [email protected].