Network Computingwww.networkcomputing.com

If device management is scary, user and resource integration is the real heart-stopper. Within a year, most of you will be up to your nostrils rolling out Active Directory-enabled networks based on Microsoft Windows 2000, and the last thing you'll need is to be jumping through hoops to reconcile the user and resource information in AD with the more-or-less same information in your PBNM. This is one area where the vendors are way behind. The policy working group is bogged down and being pulled in different directions by different factions: the DMTF (Desktop Management Task Force), the DEN (Directory-Enabled Networking) group, Microsoft and a handful of other vendors all have their own ideas about how the directory schema should look, and a parochial interest in pushing their own particular plans. The short story is this: There is nothing even close to a directory standard yet, and no one really knows how Microsoft AD and Novell NDS are going to couple with policy. So cool your heels, sit back and watch the party rage--there won't be an answer to this one for a while.

Many Products, Definitions
Beyond a few basic "must-have" components, PBNM solutions tend to vary from one vendor to the next. For switch makers such as Cabletron or Extreme Networks, policy management encompasses VLAN (virtual LAN) membership and Layer 2 network security. Lucent and Nortel, among others, lump in IP address and DNS management as part of policy management.

Most players see a directory-enabled policy-management solution in their futures, but how the vendors will use the directory differs greatly. Extreme Networks sees the directory as a way for policy servers to share information, allowing scalability and third-party interoperability. For Allot, using a directory enables its customers to insert new policies without having to develop a special API. Lucent sees the directory as a giant storehouse of information, where each user has a private subtree. If an employee leaves the company, the network administrator can disable that user's Windows NT account, voice mailbox, telephone extension, network access privileges, DHCP and DNS information, and any other companywide resources that user might have been able to access, all at the click of a button. For Lucent, the directory is the single sign-on for complete network resource management, both voice and data services. The vendor plans to accomplish this via a directory-independent LDAP schema.

There are other roles for PBNM, too: For example, while most vendors consider policy management a means to manage device configuration, there are others, such as HP, that see PBNM as an end-to-end tool for COPS-enabled desktops as well as network hardware. By pushing policy to the desktop, the network administrator can control applications and set up differentiated services at their source.

Regardless of the vendor's long-term strategy, one thing is clear: PBNM will change the way you manage your network. In fact, these systems probably represent the first instance of managing a network in any real sense. But it's a double-edged sword; because all management is done in-band, there is an inherent risk in heading down the PBNM path.

Requisite Features
Policy-based network management rules can be broadly grouped into three categories: conditions, actions and roles. Conditions are events that cause a certain policy to take effect. They're the "if" half of an "if-then" statement. Actions--the "then" half--define what is done when a condition is met, and roles define how a device or interface implements an action when a condition is met (see table below).

Policy conditions can be defined at almost any layer of the OSI model. The amount of functionality is limited only by the software implementation and the capability of the hardware. Most vendors concentrate their software on the IP layer and above. Notable exceptions are Extreme, HP, Nortel and Spectrum. Spectrum has the widest range of condition support, including some very specific IPX network QoS features unique to its product.

Support for Layer 3 DiffServ is an important feature that is relegated primarily to traditional software-based routers. HP and Cabletron are the only vendors with Layer 3-aware switches capable of operating based on information in the IP ToS (Type of Service) field during our tests. DiffServ is a critical part of policy management, as it enables end-to-end IP-based QoS. You need to be fully aware of your hardware capabilities. If your edge devices don't offer Layer 3/Layer 4 intelligence, your policies will be relegated to the WAN and the core of your infrastructure.

Acting Out the Role
Once a traffic flow has been defined in the policy server and identified by the switching or routing hardware, a number of actions can be applied to that flow (see table on Actions).

The role of a particular router interface describes how that router interface will enforce a particular action. For some vendors, such as Extreme and Lucent, the role applies to the entire device. For others, such as HP, Spectrum and, to a lesser degree, Nortel, roles cannot be configured in their current software release. Roles affect traffic only when the network is congested. These parameters are the most important for defining your network application behavior, but their effects are the most difficult to measure.

Roles were best supported by Cisco, IPHighway and Orchestream. Support for these different mechanisms really separated these products from the pack during our lab testing. Every vendor whose products we tested is planning to roll out support for these features in a future release.