SAN MATEO (03/23/2000) - Things used to be so simple. Your data network carried data, and the PBX carried voice traffic; if you wanted video at your desktop, you put a Watchman next to your monitor. Today you have to provide streaming video from the Internet to the desktop, and the new CEO wants to know how soon you'll be ready to implement that "voice over IP stuff." By the way, you need to make sure that the paying customers can get to the Web site, while your employees can access your partner's extranet. Finally, your request for another T1 line has been denied. Sound familiar?
Organizations of almost any size face a bandwidth crunch. The common solution is to add a bigger pipe for your network traffic. But that's not always possible. T1 lines aren't cheap, and new DSL offerings suffer from distance limits. Whether the obstacle is financial or physical, the only alternative is to make better use of what you have.
Making do with your current infrastructure forces you to manage traffic efficiently. Overall, you need to make sure that important network traffic gets priority over run-of-the-mill data. To classify traffic and assign relative priorities, you have to know something about the object (usually human) generating the traffic. This in turn requires a directory service, which most organizations have in the form of native LDAP servers, Novell's NDS, or Microsoft Windows 2000's Active Directory. Both NDS and Active Directory use the standards-based LDAP as a building block.
Directories make use of something that is unique to each user -- his or her log-in -- as opposed to solutions tied to a port on a hub or an IP address that might be changed. This allows you to ensure that the traffic is properly prioritized. Directory-enabled tools can also simplify network management by using information and tools from the network operating system. This, in turn, lowers the cost of training and retaining skilled staff. (For a view of what directories mean in the world of e-commerce, see our Special News Report, "Directory redux," on page 34.)Directory-enabled tools offer a solution to the problem of differentiating among the traffic coming from customers, the traffic from your elite workers, and the traffic from rank-and-file users sending around the latest knock-knock joke. With apologies to Orwell, some kinds of traffic are more equal than others. Until recently, making that differentiation was difficult, due mainly to a lack of standards as well as a lack of products capable of managing networks based on policy, compared to the traditional device-based approach.
That's changing for the better, due in no small part to the completion of the DEN (Directory-Enabled Networking) specifications in August 1998. The DMTF (Distributed Management Task Force) sponsors the DEN initiative, which sets standards for improving network management by using a directory service to consistently apply policies for accessing network resources.
The DEN information paradigm adds support for network devices and services to the DMTF's CIM (Common Information Model), a standard for enterprise management that covers everything from hardware and operating systems to applications, security, and almost anything else associated with enterprise systems. One of the main difficulties in implementing DEN is the need to shoehorn the abstract CIM data structure into the more limited LDAP Version 3 framework. This conflict comes about because CIM is an ideal standard that is intended to remain "correct" even at the cost of being abstract; meanwhile, DEN has to work in the real world.
Now a new generation of network management tools based on DEN is poised to allocate network bandwidth according to the needs of the organization instead of following the "I got here first" model. Novell is leveraging its years of experience with directories through its new ZENworks for Networks 1.0 (see review, page 45), which uses NDS as the management repository for Cisco edge, or network-bordering, routers, and 3Com, Cisco, Extreme Networks, and Lucent backbone devices. Although Microsoft may have a tight relationship with Cisco, the delayed shipment of Windows 2000 and its Active Directory means it will be a while before products competing with ZENworks will appear.
The nitty-gritty of policy-based managementYou can get a grip on policy-based network management once you understand "quality of service" (QoS) and "class of service" (CoS) and how these concepts can affect the end-user. I'll focus on implementing QoS/CoS over Ethernet, the environment most familiar to the majority of InfoWorld readers. (For a look at QoS solutions, see our Test Center Comparison at www.infoworld.com/printlinks.)The IEEE's 802.1Q subcommittee, which is responsible for the VLAN (virtual LAN) standard, defined in 1998 a tag that Layer 2 switches, Layer 3 switches (routers), and hosts can add to data packets. Most of the information contained in this tag covers VLAN management, but three bits are set aside for identifying packet priority. The 802.1p specification actually defines the use of these bits, which provide eight priority classes.
As you might expect, traffic types define the eight possible priority classes.
Oddly enough priority-one, not priority-zero traffic, has the lowest priority.
Zero-priority traffic is "best-effort" data, such as vanilla e-mail, and file and print services. Bulk data transfers, such as server backups, are an example of priority-one traffic, which usually takes a backseat.
Higher up the list, IEEE is reserving priority two for future needs, whereas priority three is "extra-effort" traffic that you would set aside for executives or key knowledge workers. Priority four, or "controlled-load" traffic, would be the class you'd assign to your mission-critical applications, and priorities five and six are used for video and voice, respectively.
Finally, the most important traffic, that which supports the network itself, uses priority seven.
Of course, all of this is moot if you're using a low-end network device. If a device is going to support 802.1p priority flags, it must have sufficient queuing capacity to store packets during congested periods. Typically, new Ethernet hardware will have two queues in an edge switch and four queues in a backbone device, yet this capacity may not be enough in some instances. This situation, in which the packet storage proves inadequate, is called queue starvation. In the worst case, packets are never delivered.
Perhaps the most effective queuing scheme is Weighted Fair Queuing, which has the advantages of enabling priority handling while allowing the device to service low-priority queues in such a way that queue starvation never occurs.
Of course, how this actually happens will depend greatly upon the equipment you're using. You may see switches from different vendors varying slightly in their end-to-end priority handling. In other words, your mileage will vary, so test your hardware with your applications to ensure you get the results you expect.
The trick to making Weighted Fair Queuing, and QoS/CoS solutions in general, work is setting the appropriate flags on the packets before they go onto the wire. Possibly the most effective way to do this is to define packet priorities through a directory service, such as NDS or Active Directory. Organizations using an extensible directory system such as one of these to classify traffic can enhance network performance without adding bandwidth.
The policy payoff
One of the big obstacles to deploying a QoS/CoS solution in the traditional network management environment is that the existing solutions manage devices on a one-by-one basis. Sure, you can set up a central repository for router or switch definitions, and do some neat things on a port-by-port basis inside the device. But if you're going to effectively prioritize network traffic, you will need a directory to supply the data that will determine the traffic priorities.
Here's why: The majority of your user base probably rates "best-effort" priority for the bulk of its network traffic. These people are sending e-mails, copying files, printing documents, and the like. Like most organizations, you permit them a certain amount of non-business Internet use, using the analogy of allowing "personal calls" on the PBX.
Some of these "best-effort" users use an application that is your company's lifeblood. A few of these people may be in finance; others are in various departments. Depending on your situation, some of them may be in the next building, the next state, or on the other side of the world.
Then you have executives who are accustomed to using company facilities as if the resources sat in their living rooms. They're probably doing the same things as your "best-effort" users, but the executives want immediate network response, and don't you dare tell them that they can't listen to Internet radio or watch CNN's video feed.
In the bad old days, you'd probably try a variety of things, none of which would work well. You might resegment your networks to keep the custom application traffic separate from ordinary traffic, or set up a VLAN to do the same thing inside of a switch. Unfortunately, when you set up a VLAN inside of a switch, you're usually defining the VLAN on a port-by-port basis. This approach will fail in a "hoteled" network environment (when users don't return to the same piece of furniture every day), or a remote-access scenario, because users will connect to a different port on the hub or switch from one log-in to the next. Trying to define traffic rules based on IP addresses is equally pointless in an environment using DHCP (Dynamic Host Configuration Protocol), because users are unlikely to retain the same address from day to day.
This leaves us with the one unique hook upon which to hang traffic management -- the network log-in, a function of your directory service. This will usually be unique; it will travel from one desktop to the next throughout your organization, and it's something you're already managing from a central repository.
One advantage of leveraging your existing directory is that you may already have some, if not all, of these user types defined in your directory. Although you probably set up these groups for the purpose of controlling access to a server's file system and output devices, many of your organizational units and groups lend themselves to traffic management in much the same fashion. By using a directory-enabled network management solution, you're able to define a traffic policy for your executives that guarantees them throughput above "best-effort" without compromising your accounting department's access to its numbers.
Directory-enabled networking offers the potential to efficiently use your existing network bandwidth, by providing a logical way to classify traffic according to business needs and user expectations. It is certainly more elegant and usually less expensive than simply throwing a bigger pipe at the problem.
Although elegance itself does not make the business case, the ongoing costs of additional T1 lines will likely drive home the point.
Technology analyst P.J. Connolly (email@example.com) covers directory services and networking.
Netware 5.1 adds pieces to the puzzle
Whether you're upgrading from NetWare 5 or installing from scratch, NetWare 5.1, which shipped in January, offers improved networking abilities and a proven infrastructure that won't break when you try to patch the latest security hole in your Web browser. The latest NetWare builds on the foundation of NDS and the core file and print services to present IT departments with a compelling alternative to Microsoft's Windows 2000 Server line. Although NetWare may never reclaim the dominance of the server OS market that it once held, rumors of its demise are greatly exaggerated. International Data Corp. estimates from September 1998 indicated that the number of installed Windows NT Server licenses would not exceed those for NetWare until this year.There's reason to believe that NetWare might retain its lead for at least another year.
We looked at a beta of NetWare 5.1 last year (see "NDS 8 best part of NetWare beta," www.infoworld.com/printlinks), and many of the conclusions drawn from the beta remain valid with the final release. In particular, the product's strongest and weakest points remain unchanged from the beta. If you need a stable directory service, then NDS 8 (which ships with NetWare 5.1) is far ahead of anything Microsoft provides for Windows 2000. On the other hand, Novell's weak track record as an application server and the frustratingly slow management interface detract from NetWare's appeal.
If you've been using NetWare for a while, you're probably used to handling your management tasks with the NetWare Administrator (NWAdmin). NetWare shops that upgraded to Version 5 have had a taste of the future in the new Java-based ConsoleOne, which replaces NWAdmin.
Unfortunately, although workstations can launch NWAdmin from the server without experiencing performance problems, ConsoleOne runs very poorly over a network, even on servers with 500MHz CPUs. ConsoleOne's dismal response times will undoubtedly improve with later releases, although this will be due more to the availability of gigahertz-speed processors and the emerging practice of installing ConsoleOne on local workstations than to any improvements in the underlying ConsoleOne code.
The products bundled with NetWare 5.1 are also noteworthy. The Oracle8i database shipped with the first releases of NetWare 5, and provided Novell's OS with some much-needed support for back-end operations. As part of the NetWare 5.1 release, IBM's WebSphere application server takes things to the next level by providing Web services that take advantage of NDS's proven security features. The addition of WebSphere makes this release the first version of NetWare that customers might seriously consider as an application server.
Novell took almost as long to adopt the challenge of providing application services as it did to adopt IP networking, and that has hurt NetWare's ability to retain customer loyalty; NetWare 5.1 faces an uphill climb.
The days when you ran an "all-Novell" shop have been over for years. Today, smart IT organizations use whatever works best. Nevertheless, NetWare loyalists as well as potential customers will find NetWare 5.1 a solid alternative to the Windows revolution.
THE BOTTOM LINE
Business Case: Directory-enabled networking (DEN) offers the potential to simplify network management while providing a platform for implementing quality-of-service standards on an IP network. With DEN you can more efficiently handle network traffic without investing in ever-larger capacity.
Technology Case: You already have a directory service in place for managing file storage and print services by groups and organizational units; it only makes sense to extend this service to manage network bandwidth and take advantage of the existing structure.
+ Leverages existing infrastructure, including venerable and well-understood SNMP+ Builds on commonly used directory management tools+ Allows networkwide application of bandwidth policies, as opposed to current practice of managing bandwidth on a device-by-device basisCons:
- A substantial investment in NDS for NetWare managers- Immaturity of Microsoft's Active Directory- May require expensive and complicated replacement or upgrade of core network infrastructure, including routers and switches