A Point of Integration in PBNs
During the recent blizzard of Comnet press releases, one in particular might have escaped general notice. It had to do with a major networking equipment manufacturer who struck a deal with Microsoft to integrate Windows NT into its product line. Although full details are yet to be announced, the technical concept behind this arrangement bears a striking similarity to an idea that was created by a venture-capital-class company, which has since been acquired, more than eighteen months ago. Now that a major equipment manufacturer has endorsed this concept, it is worth going back to take a look at just what this startup company had in mind so many months ago.
First off, the firm had a brilliant idea: If policy-based networks are the future of networking, and directory services are the keystone enabler of this capability, why not bring the directory service right into the networking device? Those of you following policy and directory developments know that most suppliers describe their policy-based networks as a place where the directory service lives outside of the networking device. When information is needed from the directory service -- to make a policy decision, for example -- their solutions call for a policy server that extracts the necessary data from the directory via the mediating services of LDAP's access and retrieval protocol.
The startup company's idea of integrating NT into a networking device such as a router, for example, eliminates this several step process. With the directory service inside the router, all of the additive protocol and equipment latency gets squeezed out of the process of obtaining directory information. Reliability and availability were expected to increase as well, a fact based on networking's traditional inverse rule -- reliability is inversely proportional to the number of elements in the system. In short, put the directory service inside the router and you have just eliminated numerous elements that can fail when trying to get at a directory that is stored on another device.
The startup company expected other benefits as well. Although there is a strong suggestion that using NT implies using Active Directory, this is not necessarily the case. NT, in fact, opens the door for any other directory service that has been built for use in NT environments. Novell's NDS, for example, can be used as easily as Active Directory, plus NDS is a more mature directory service than Active Directory.
Many months ago, the idea of running NT inside a router was fraught with misconceptions. One of the most common was that NT would replace the core operating system, or the routing code as it is generically known. This misconception filled networking folk with concern about performance. In fact, NT does not replace the routing code at all. NT's role -- along with providing support for directory service -- is to work alongside the native routing code and to maximize router performance.
In the case of the aforementioned startup integrating NT into a router, NT plays no role in the packet forwarding process. There is a clear line of demarcation between NT and the routing code that is responsible for this critical function. NT does take over the load of recalculating routes based on updates received via RIP or OSPF. But once the route recalculation process is completed, NT sends the updated routing information down to the board level where it is stored in the forwarding tables.
Now that a major equipment manufacturer has endorsed the idea of using NT inside their products, it remains to be seen just how it will work with the other elements of their policy-based networking solution. --Sam Alunni is vice president of networking at Sterling Research (Sterling, Mass.). Contact him at alunni@sterlingresearch.com.