If you've been watching the trade press recently, you know that VPNs are becoming a major issue with equipment vendors and carriers alike. There's been a rush of new announcements for VPN services and for products that will build them.

What is a VPN anyway? Why would anyone want to buy one, versus a private network, or a managed service, or some other service offering? Is there any value to these things? What is that value? Those issues are the subject of this month's briefing.

The first question may be the hardest for many, because the term "virtual private network" or VPN was launched with voice networking back in the late 1980s. The idea then was to allow users to build PBX voice networks over public switched telephone facilities to save money and create more opportunity for carriers. With the advent of voice VPNs, voice traffic on T1 networks fell sharply, and these networks started a transition to "primarily data" status, a translation that has been widely (and inaccurately) interpreted as an indication that voice traffic was declining overall in favor of data.

Data VPNs, which is what the current craze is about, are private data networks overlaid on a public IP network structure. Just as voice VPNs were designed to attract users back to the public network, so data VPNs are designed to displace private data networking in favor of public network services. They could, in this mission, be compared with things like managed services or connect services.

In fact, VPNs will probably force us to get systematic with the classification of value-added services overall. We can consider services to be based on an OSI model; levels 1 through 3 can exist in a network according to that model. A "basic" service is one that provides Level 1 connectivity – physical digital transport without any real "protocols". Frame and cell services are higher on the stack – Level "1-point-something" – so they provide a value-added service. VPNs operate at Level 3 and so provide value-added services as well.

What differentiates the VPN from the other value-added services is the idea that it is laid over a public IP network, and that kind of network is intrinsically connective, meaning that it provides any-to-any data delivery. In that respect, IP networks are like the public switched telephone network. Like voice VPNs, therefore, the data VPNs have to be somehow isolated from the other users on the foundation network. In effect, we have to formulate a closed user group.

Meeting this objective resulted in early VPNs created in one of two ways: segregated facilities or filtering. The former means giving each VPN its own routers and circuits, which pretty obviously means that the "VPN" is really only a private data network that the carrier builds and owns; no facilities are shared. The latter means that router policy statements prevent traffic from the foundation public IP network from mingling with the VPN traffic. That's a slow and often wasteful process.

As VPN popularity increased, it became obvious that we needed a more effective strategy for creating VPNs, one that actually shared facilities. Two options have emerged: logical network segmentation and tunneling.

Logical network segmentation means partitioning the address space of a public IP network in some way, so that the routing decisions made for VPN users consider only destinations and paths that are also part of the VPN. We could envision this as adding a "VPN code" to the router table lookup, so that VPNs could be routed independently.

To make this work, we'd need to add a VPN code to the datagrams associated with a given VPN user when the datagrams arrived at the network, and then carry that code with the datagram thereafter. There are no direct standards for this, but it would be possible to adapt something like IEEE 802.1q, designed for VLAN tagging, to work.

Standards aside, the problem with router-based segmentation like this is that it requires multiple routing tables, in a logical sense, and multiple sets of topology updates in the public IP network to maintain those tables. Fortunately, there are some new developments that might be useful in making segmentation practical for most networks.

One development is "tag switching", which is officially now called "multiprotocol label switching" or MPLS. With MPLS, routing table entries are linked from end to end through the exchange of table indexes or tags which identify the handling that a datagram is expected to have. An originating router passes a tag to its downstream partner, and that tag allows the partner to quickly locate the entry associated with the tagged datagram and process the data through.

Since a tag's linkage with handling instructions is arbitrary, a tag could represent not only a routing table entry, but a VPN-segmented routing table entry. By having the initiating router link the packet with a VPN tag, the packet would stay in the VPN unless some downstream process merged it into a common flow (which, presumably, it wouldn't do). The MPLS header, in effect, allows us to identify VPN.

Another development is similar: the use of spanning-tree virtual circuit networks inside a router ring to create an efficient packet-handling mechanism. This concept is the basis for IBM's ARIS proposal in the IETF, which is also now part of the MPLS working group, and of Ascend/Cascade's IP Navigator. With this proposal, each IP destination in a frame/cell network spawns a spanning tree to touch all partner destinations. The assumption is that "all" means "all IP-compatible attachments in a public network service", but "all" could just as easily mean "all VPN members".

Switched virtual circuits make up the third approach, recently showcased by Newbridge in an announcement for Interop under the tag line "Carrier-Scale Internetworking". With CSI, Newbridge relies on the route-server architecture of MPOA. Edge ATM devices or proxy agents for MPOA send route resolution requests to a route server (or servers), and receive the ATM address of the destination proxy (or, in theory, the final ATM end-point). By segmenting the route server database by VPN, Newbridge can partition the addressing and eliminate both security problems and problems with QoS control, given ATM's intrinsic QoS management.

The MPOA approach to VPNs is elegant, but it is not clear just how far we could expect MPOA to penetrate. ATM, after all, has proven best consumed under cover of darkness, given recent press turnarounds on its future. MPLS-related approaches are viable in concept, but nobody has stepped forward yet to claim either, so we're left with the other approach, the one most vendors and carriers claim: tunneling.

A "tunnel" is created by encapsulating a stream of data between two points, using some sort of session or datagram flow. The key thing is that everything is encapsulated, including the protocol headers and control messages of the source. In theory, you can tunnel anything and in theory you can use anything that can carry data as a tunneling protocol. You can encrypt the data being carried in a tunnel, because the tunnel protocol headers and control isn't impacted and the intervening nodes can still handle it. You must, of course, decrypt the stuff at the destination.

Tunneling protocols are designed to make the process standardized enough to work between arbitrary sources and destinations. Examples of tunneling protocols are the "Microsoft-certified" PPTP and the newer and more flexible L2TP.

Most vendors and most network providers rely on tunneling to create a VPN. Each VPN station can connect with a "tunnel agent" that encapsulates the information and passes it through on the designated tunnel. The tunneling protocol must use the transport protocol of the native network – IP in the case of public IP networks like the Internet – and must use addresses that can be properly routed in that network space. For the stuff in the tunnel, anything goes.

Tunneling has two problems, one obvious and one not so obvious. The obvious one is that there's an overhead associated with its use. The non-obvious one is that the tunnel can provide only such service level guarantees as can be provided natively in the host network, and that are not compromised by the tunneling protocol.

The overhead issue is often overplayed in the media. If your data packet sizes are large enough, the overhead you'll see in tunneling isn't much more than you'd see for a protocol like TCP – usually, it's less. It is true that TCP/IP encapsulated in a tunneling protocol has a redundant IP header and a tunnel header, but header compression can keep that waste to a minimum. If your packets are small, however, you may find that header traffic outnumbers data traffic, and a better strategy might be in order.

The problem with service assurance isn't as easy to dismiss. Most VPNs based on public IP services cannot provide any real service quality assurance because IP itself, being connectionless, doesn't have a delivery guarantee. It may be possible to secure some QoS specificity if the carrier can provide RSVP support or if there is some policy-based QoS management in the network – a premium grade of service or something similar. Neither of these are likely to work if the VPN transits more than one ISP, however, so you'll want to be sure that doesn't happen.

When requesting QoS, you should be wary not to fall into the "trap of technicality". Your network provider may want you to describe your QoS needs in some abstract terms like those used for frame relay – committed burst size or something like that. Flee from those people! Insist on providing a simple service-level agreement that specifies peak and average throughput, delay and delay jitter, discard/loss rate, and overall availability. If you try to get into technical parameters, you'll assume the very risk of performance you're trying to offload, because you'll have to understand those technical parameters well enough to be sure they really state your applications' needs.

You'll also need to decide just how you'll know whether a carrier is meeting a QoS commitment for VPNs. Remember, you can't monitor the carrier network internally, and you probably will have your own devices feeding the carrier's VPN. If you plan to take measurements to keep the carrier honest, you'll need to take them at the boundary with the carrier's network, as close to the VPN tunnel as you can. You'll also need to be sure that the carrier and you can agree on just how measurements will be taken and how differences of opinion (sure to come) are to be resolved.

This isn't as easy as it sounds, we'd point out. Most VPNs, like most frame relay services, can't report on SLA parameters out of their management systems, so you should assume that you'll have to have some form of special management tool at the boundary of the VPN to look for SLA violations. In some cases, your own LAN or application management systems will provide some help. In most cases, you probably will have to do something semi-customized for the protocols in use. Discarded data, in particular, is hard to detect directly, so you should assume that you'll probably have to rely on error recovery statistics from your own applications or management systems.

How do you decide what VPN to buy, then? There are some simple tests you can apply to your providers to be sure they can meet your needs:

1. Will they guarantee service levels? If not, you can't be sure that your network will carry any traffic at all.
2. Will they guarantee security? The best VPNs will have an option to encrypt at a tunnel agent boundary so that your data will be protected internally.
3. Are they cheap? Remember, all networking service buys reduce to bits for bucks, and there's no point in picking a service that's more costly than alternatives.
4. How stable is the provider? Network performance is guaranteed based on a contract. Contracts are enforced in law, and founded on a principle of a payment of damages for non-performance. Can your carrier pay if you get a judgement? If not, your contract is baseless (and so is your network).

There is also a question of core technology, though it's a difficult one to apply. We can hardly recommend that the buyer, who is moving to VPNs to avoid a technical or financial commitment in the networking space, spend money to research the details of carrier infrastructure, but the truth is that it may be necessary to at least categorize carrier implementations of VPNs to be sure that claims made for their value could be met in the long run.

We believe that tunneling, in and of itself, is not going to be a satisfactory solution to VPN requirements. The tunneling capabilities of the network would have to be augmented by something to insure security and QoS of the data stream. Virtual circuit augmentation of tunneling, or pure virtual circuit implementations, would work. So would policy management of tunneled flows, if the network had the necessary policy and flow awareness at the router level. Moral: Beware.

In truth, VPNs may form the majority of carrier data transport services by the second decade of the 21^st century. In the current year, they're small potatoes. You'll need to look carefully at your VPN providers, their costs, and their guarantees, to be sure you get the best service for your money.

Intranets, to recap briefly, are corporate information applications that rely on Web technology to distribute a combination of corporate data and ease-of-use enhancements and instructions. The foundation element of an intranet is a browser, where this data combination is integrated for presentation.

Most corporate data today is not formatted for intranet presentation. To make it possible for host or other data to be incorporated in an intranet screen, users must develop a strategy for merging data from today's MIS applications with new data in both HTML and other form. How that might be done is the subject of this month's In the Know.

The basic options we have to work with in information integration are:

1. Client-level integration, meaning that the workstation or PC will receive the data as independent streams and integrate it locally.
2. Host integration, meaning that the data will be sourced by a single system in integrated format.
3. Web server integration or "intermediary" integration, where a system stands between host and client and assembles the streams on the client's behalf.

Each of these options must be examined based on their impact on the application's goals, the difficulty of execution, and the impact on the network.

Client integration can be the easiest way to accomplish information integration between web tools and host data. Most host vendors and many third-party vendors provide PC software that can emulate a popular host terminal type like the IBM 3270. This software also usually supports a "hot-key" function to switch between terminal emulation mode and local PC mode for application access. In many cases, this hot-key function can be used to switch from an emulator to a browser. Some vendors (such as IBM, with its PCCOMM software) provide specific, tight, browser integration to facilitate this kind of context swapping.

In simple hot-key integration, the user performs an explicit role in the information integration process. The easiest way to understand this is to postulate an application and trace it; we'll use a customer inquiry example here.

Suppose a support person gets a call from a customer asking for information on order status. The support person is running a PC with both a 3270 emulation connection and a browser, and starts the call with the browser in control. The "home screen" or HTML page is one that provides the worker with a list of things that the call might be about, and when the caller says they have a question on an order, the worker clicks on the icon or URL that indicates "order status inquiry". This brings up a page telling the worker to hot-key to the emulator and enter the customer number into the CICS screen, then read the resulting information to the user. If there are follow-up questions, the worker is to hot-key back to the browser to pick up additional support or instructions.

The advantage of this over a standard CICS interaction should be clear: instructions and policies can be provided in HTML form, even to the point where the worker gets his or her own special instructions to handle problems. That's an asset in itself, but exception conditions and problems can also be put into HTML instruction form so that the worker is largely self-supporting in each dialog.

There are also some limitations. The most obvious is that the worker has to key between the screens. Some products allow tiling of windows or other display-management practices, but these will generally limit the extent to which either screen is visible, owing to limits in the display size.

This simple client-side procedure could be enhanced if we could somehow get programmatic control over the operation of the two windows – browser and terminal emulator. If that happened, we could in effect have a composite "screen view" that the operator saw, but could derive that view by intermingling elements from both data spaces. That goal could be met either by having the terminal emulator support integration, or by having the browser do so.

Terminal emulator flexibility is now being explored by people like IBM, Novell, and Attachmate. These include the ability to write scripts that control execution, draw data from various sources, and include buttons, menus and other types of controls. Most rely on operating system hooks that process URLs when clicked or invoked, something like the way a "mailto" works. All of these strategies are good for an organization more terminal-oriented than web-oriented.

For most users, the preferred approach to integration would involve enhancing the browser in some way. The following options could be considered:

1. We could use a scripting language or toolkit to integrate the information from the streams into a single display. This would not only facilitate the movement of the worker from step to step in the flow, it would (in theory, at least) permit the application to use data the worker enters (like customer number) to make an inquiry into multiple hosts or into a host and a web server system to get status or instructional information.
2. We could write an application for the browser using ActiveX or Java to accomplish the same thing.
3. We could write an application to the browser's API (the Plug-In API), using any standard programming language, with the same purpose.

Scripting languages like VBScript and JavaScript may seem an attractive option here. The problem is that both these languages manipulate browser objects and don't really provide much flexibility in leaving the browser world to fiddle with other data streams, unless those other streams are "objectized" by the terminal server, or unless a Java/ActiveX component is used for linkage.

Writing an applet in Java or ActiveX opens a number of doors, depending on just how elegant your programming skills happen to be and how your other data streams are formatted. First, Java or ActiveX can create a second communication pipe to the browser, over which alternative host data can be transported. Here, you may be limited because standard Java recognizes only IP-based information, but some tools may be available from host vendors (like IBM) to overcome this.

Writing directly to a plug-in or browser API is no small undertaking. You may be able to find tools from software developers (Borland, for one) that will include facilities to write to browser APIs, and this will give you complete flexibility. The number of errors and disasters you can cause with this kind of work is almost unlimited, though, so you'd better be a good development organization if you want to consider it.

Probably the biggest problem with client-side integration is the difficulty in making it pretty from a features perspective. Tight integration of the HTML and host streams will probably take you into features and tools that are not portable across different operating systems, and definitely not workable on network computers or simple browser platforms with no intrinsic programmability. This is particularly true of Microsoft's suite, which integrates well as long as you're running Win95 or NT, but doesn't work well even on 16-bit Windows.

Another problem with the client integration option is the potential impact on the network. The problem is that multiple data feeds must be presented to each client system, and presumably the clients will extract relevant data. The rest is bandwidth-wasting crud. Furthermore, the host presentation is often in a protocol other than IP, which means the client has to be bilingual in protocol sense, which is likely to increase network and adapter costs.

If we can't stick things together at the client end of the connection, how about using the host system? IBM and other host vendors have moved quickly to support both the IP protocol and HTML hosting in general. This means that it would be possible to develop an application to integrate HTML material and host database contents on the host itself.

Possible, but it would require development. Most host applications today are transactional in nature, and programming them is a specialized skill. Furthermore, they don't map well into following hyperlink trails of the type used for HTML decoding.

A better host strategy would be to rely on the current applications for traditional transaction processing but a new set of applications to drive the HTML. The two would link together through application pipelines on the host itself. IBM's Message Queue (MQSeries) software is designed to do this very thing (among others).

An example is in order here, and we'll use the same one as before. This time our worker is equipped with an integrated client based on a browser, but with no host terminal emulation link. When the call comes in, the worker has a base screen as before, with the same list of application options, and selects the same "order status inquiry" URL to click. The host would present an HTML form with a space for the customer number, and when that form was returned would pipeline the customer number to a simple DB2 query. The return data would be formatted into an HTML table or other convenient form.

Hey, that works! In fact, it would. It works on nearly every popular database engine host, from DB2 through Oracle and Informix. Most database vendors have facilities to make this integration easier, in fact.

There are advantages to this approach beyond the obvious one of simplicity. First, the approach is client-independent – all you need is a browser. That means that any desktop system will serve, and thin clients like NCs will also work. Second, the only thing that moves over the network is the IP-based browser stream; superfluous data is contained to the host, and only one protocol type emerges. Third, data security and integrity can be maintained on the host as before.

Disadvantages? Yep, we've got them too. First, the process will require host programming support, to develop the applications and maintain them. Second, it may be necessary to have professional assistance in developing and maintaining the HTML ease-of-use material, stuff that any good word processor could create on another system. Third, the host may be an awfully expensive resource to use for storing and delivering HTML. Finally, the HTML material, probably the most voluminous of all the material in the application, will have to flow from the host, over the network.

This last issue can be dealt with. If an intermediary set of HTML page servers are introduced in the network, the host can provide the "foundation" pages, and subsidiary references can be resolved on these intermediate servers. In our example, the main screen our worker sees can be host-generated, and the form screens can all be host-handled, but any help files or procedures can be accessed via URL links to the secondary servers elsewhere.

In for a penny, in for a pound, so they say. If we're going to have intermediate web servers in the application, why not explore some added features to them that would eliminate some of the other disadvantages of the host-centric approach?

Using a web server to integrate information streams has considerable emotional appeal. First, the web server is where the HTML pages that constitute the value-add of intranets are found. Yes, we know that MIS data is critical to intranets (and we've said so), but we already have MIS data in dumb terminal applications. The goal of intranets is to supplement that data, and HTML pages are what it gets supplemented with. Second, it happens that the focus of tool-building is the web server.

There are a number of approaches that can be taken in integrating data flows via a web server:

1. The Common Gateway Interface can be used. CGI is a URL-invoked link that runs a program on the server and returns results to the executing browser.
2. Server scripting languages can be used. These scripting languages control the way that the server processes HTML; they operate through the CGI interface but are simpler to use.
3. Server applications can link to a client-side applet written in Java or ActiveX, and the linkage can present a composite data stream.
4. An integrated groupware product can provide a composite display using some proprietary technology or a mixture of proprietary technology and standards.

CGI and server-side scripting languages like Perl are probably the most-used strategies for enhancing information integration. The combination would allow a web server to spawn a query into a host database and retrieve the result. That result would then be presented in either the context of an HTML display (a table, for example) or sent to a client-side applet for custom presentation.

The choice of a scripting language is usually made on the basis of the client and server platform choices. If the platform is absolutely going to be 32-bit Windows, then VBScript and ActiveX are the combination of choice. For flexible client support off a standard NT server, VBScript as a server language can be combined with ActiveX server components and other applications and projected to an unaugmented client or to a client running a Java applet. For applications where both client and server have to be platform-independent, Java, JavaScript, and Perl are probably the best choices.

The decision to use a proprietary product (from IBM, IBM/Lotus, or Novell) is often a troubling one for users. Often these products have considerable benefit beyond the intranet application, in the areas of message handling, schedule management, and even database integration for PC data. The extension of these platforms to serve intranet goals is often fairly simple.

In the end, it is probably a question of how much flexibility you'll need. The integrated groupware products are the simplest to use if your applications are minimally complex. The more sophisticated you plan on getting, the more likely it is that you'll want a broader range of capabilities. That will usually mean going the standards route. Another factor is that unless you already have considerable development and administrative skills in the groupware product you're considering, adding an intranet mission to its standard mission will probably put you over the top in terms of skill set requirements. That may mean expensive outside resources.

Let's use our example to consider the server approach. Remember, we're starting with a customer call into a support worker, whose initial screen is a simple list of the kind of calls that might be processed. Our customer is making a call to check order status.

The worker, selecting the "order status inquiry" URL tag, will cause a specific page to be loaded. Since the worker's home page can be customized by the worker, the links to handling instructions can also be customized, and the pages can reside anywhere (including on the hard drive of the worker's own system).

The instructions for order status handling will eventually present a form to the worker for entry of relevant account information. This form will presumably originate from the integrating web server. It could be presented as a real HTML form or as a Java or ActiveX applet doing screen I/O.

The output of the account-data-gathering process would be returned to the integrating server. There, the data would be used to generate a database inquiry. The results, a record, would be formatted into an HTML table or sent to a display applet.

If the CGI/scripting option is used at the server level, the entire integrated access-and-response is handled out of the web server. If the applet option is used, the applet in the client can, in theory, initiate a dialog with any addressable system resource. If the applet can speak a protocol other than TCP/IP, it can initiate a dialog in other protocols as well.

The beauty of this approach is that it can be as client-independent as you'd like it to be. A pure HTML-and-script-and-CGI integration can be used to drive any client device, even an NC. If applets are to be used, a selection of Java will assure multi-platform support.

The same host feed can theoretically drive a number of different client approaches, in fact. We think that the ideal "back-end database application" for this type of integration would be one that responds to a query with an entire record in "undigested" form. That response could now be routed in a number of ways, depending on exactly how the intranet flows were to be managed:

1. The record could be processed by an application (hard-coded or host-scripted) that would format the data into an HTML-visible format for delivery. This would satisfy requirements to support browsers or terminals that lacked applet support.
2. The record could be sent to a client intact, where a generalized reformatting applet could be used to create a visible display form of the fields, and a specialized application applet could format those onto a display.
3. The record could be sent to a server applet for processing as in the second point above, for delivery to a limited-function browser.

Overall, this is the most flexible of all strategies, and the one we recommend to intranet-building organizations.

OK, it's time to dive into the non-politically-correct issue. Topping the list of ugly questions is the "Microsoft-versus-anybody-but-Microsoft" question: ActiveX and VBScript versus Java and JavaScript.

If you are a UNIX organization, if you have to support diverse clients such as the population of the real Internet, and if you have no intention of migrating to any other posture, then Java and its associated scripting language are the best bet. There are companies out there in Silicon Valley that meet this description, but the population elsewhere is low and we think it's getting lower.

If you are anything else, we'd recommend that you strongly consider the Microsoft approach. As long as your browsers are based on 32-bit clients, you can buy in to the whole Microsoft Common Object Model (COM), the foundation for both ActiveX and VBScript, and also for OLE and other Office 97 features.

The benefit in tools alone will be compelling. We believe that there are nearly 2,000 independent ActiveX components already available, and new ones are being added at the rate of about 150 per month. The release of Windows 9x (where x is some number greater than the current year) will surely kick off a substantial increase in this, as will the broader acceptance of Internet Explorer 4.x for the extant 32-bit platforms.

Another plus is that ActiveX and VBScript programming work pretty much like the Visual Basic development process or the use of the VB-based scripting languages built into the Office 97 components (sometimes called "VB-lite"). That means that there are literally hundreds of thousands of qualified programmers, where Java can claim probably an order of magnitude fewer.

Embracing Microsoft doesn't mean that you have to abandon Java completely. The Microsoft COM encapsulates Java applets to let them play in the overall ActiveX architecture, so you could do easy-and-sleazy portable work in Java and refine it for the 32-bit clients in ActiveX and VBScript.

There are many tools for intranet-building today, and more are developed daily. Many corporate buyers could deploy a good intranet based on these tools, using only a little client and/or server scripting to augment them. Those willing to do a little applet programming could probably make their dreams come true, intranet-wise.

A lot of the success of your intranet is going to depend on your selection of the correct information relationship management approach. A lot is also going to depend on your making a decision to adopt IP to the desktop as the standard information distribution platform. Not multi-protocol, not transient IP stacks, but real, permanent, IP.

Moving a big company to a full IP delivery system is complex. It involves changes in host protocols (through host software changes, gateways, etc.) and to network devices. It involves address space management, rethinking carrier services and service relationships, changing network management and help desk procedures, and more.

Despite these burdens, we think it can be worth it. The ultimate goal of any information system is the delivery, to each worker, the information set needed for the worker to be optimally productive. In this individualistic world, we can hardly expect a "groupthink" one-kind-fits-all information system will meet this goal. With intranets, properly designed and systematically implemented, workers can be given exactly what they need.

Our view that future network services will be dominated by value-added data and multimedia services is well-known to you, our subscribers. From that, it follows that the creation of these services is going to be a key issue for carriers, and thus for their vendors.

In the public voice network, we have an Advanced Intelligent Network (AIN) architecture standards set that defines how network elements interact to create a service. In the classical Telecommunications Management Network (TMN) standards, we have a description of service management and service creation. These are all voice standards, however, and there is no clear analog in the data space.

Vendors are now starting to address this, and we've made support for service provisioning of this type a requirement in our evaluation of ATM WAN products, so we're now going to take a look at the issues associated with service provisioning in the data space.

The creation of a "service" requires, in buyer terms, the establishment of a set of network resource associations that will produce the features for which the buyer is paying. In connection-oriented networks, this translates cleanly into a set of real or virtual circuits with specific properties. In connectionless networks, where circuit knowledge is lacking, the problem is more difficult, but we'll deal with that in a moment.

The mapping of services to connections is "clean" but not necessarily a slam dunk. The problem is that modern frame and cell services have parameters to describe their operation, and these parameters aren't necessarily the ones the buyer would use to describe their needs. The most egregious example comes from frame relay, where the classical parameters of committed information rate and committed and excess burst size have no association whatever to anything the buyer would use in specifying application needs.

Buyer needs eventually end up being codified in service-level agreements (SLAs), and so carriers must address them. To date, that is done by having carrier engineers tweak networks to try to meet SLA parameters when the parameters that really define network operation don't relate. That often results in "overprovisioning" or supplying the buyer with more resources than they've paid for, simply to insure SLAs are met.

To provide the correct resource levels in provisioning a service, a network management system must be able to take responsibility for mapping SLA parameters into terms that can be used to set device parameters in the network. This requires that the management system have two things; knowledge of the service as an entity with specific properties, and knowledge of the topology of the network to the level required to associate a "service" with specific network elements and the settings thereof.

Today's network devices are clearly not service-aware, because it is a common practice of vendors and designers to limit device management awareness to the device itself, for the obvious reason that device relationship management has to be a kind of "uber-function" that is applied by a central agent. The question, then, is what that agent might be.

Two approaches to creating service agents have been suggested:

1. The network management system itself can include tasks or MIBs that represent service objects (the definitions of each type of service the network can provide) and service instances (the individual subscriber commitments to a service object that represent the thing the buyer bought).
2. The network can contain a service agent processor where service objects reside, and these objects can be manipulated by the management system in a way consistent with the management system's use of "real" device objects.

In the first approach, the information needed to create a service object MIB and populate it is assumed to reside in the collection of management information at the management center. The process of management information collection is thus largely unaffected; service object design is a management system application.

In the second approach, a service object is a proxy agent that collects management data directly from devices and stores it in MIBs. These MIBs are then made visible to the management system, which must in some way continue to associate the MIBs from services to the MIBs from devices in some logical way.

The question of how to organize the service objects is, in today's networks, being answered by the fact that management systems are already being used. These management systems collect management data centrally for display and processing, and the management system thus has a topology view of the network. This view is a convenient jumping-off place for service definition and provisioning.

We can thus define a modern service management and provisioning system as a set of management tasks that build out of the current network management repository. The service objects, in this view, are a set of rules that cover how the parameters that the user would assert to define what they buy ("Frame relay connection from A to B with a peak throughput of T₁, and an average of T₂…") would be associated to the control of network devices along the path to meet the user's conditions.

The process starts with a topology map of the network, of the type often built in management systems anyway. This map would show the network access points (where users attach) and the network trunks and nodes. The map would also have to reflect, for each network resource, the state of resource commitments made by the network operator and the maximum resource complement or level.

Provisioning in this scenario would consist of getting from the user a description of the access points where service is required, and the level of service between access points, then commanding the network to meet these conditions.

We could define the service as a series of vectors (simplex to reflect the probability that flows would be asymmetric) of the form Service=(source, destination, parameters) where parameter values described the QoS and the traffic to be expected. To provision each vector, the management system would examine the topology map to locate the best path between the specified source and destination that could meet the QoS requirements for the traffic level specified. This would create a second vector Service-Path=(Parameter, Node₁…Node_n) which would describe the service parameters from the first vector and the node path selected.

Now, to actually create the service, the management system would translate, for each Node in the path vector, the user service parameter into a local set of commands. This would rely on what we could call effectors in the nodes, things that could be made to cause the conditions that the management system deems necessary to assure the buyer's service parameters are met. These effectors might be nothing more than virtual circuit pipes with appropriate traffic management, or they might be RSVP commitments in that node.

Given this structure, a network owner could create a set of service objects whose MIB contained the variables specified in the Service vector above. These objects could be instanced by an object-oriented drag-and-drop provisioning system to create a combined set of Service-Path vectors that represented the total service. The application would then map these to the nodes. Overall, we'd have a simple and reliable service creation interface.

To date, nobody has completely bought in to this structure – that's the bad news. The good news is that it's pretty clear that everybody will have to. Lucent's OneVision network management announcement of mid-September includes the ability of the management system to support derived objects, meaning that it can support the concept of a service object. That's an important step.

Ascend, at about the same time, took a bigger one and bought in to the concept of object provisioning with a set of "canned" service objects that can be assembled into something the user would consider a "network service". These service objects can then be used to create a set of commands to enforce service conditions on the devices that must support the flows in a given network.

In early October, Newbridge took a similar step (though its architecture for supporting these service objects is less clear than Ascend's and we can't tell just how far they really have to go in their approach). Newbridge added a program to interwork the carrier-side service creation process with an extension process internal to the customer network, so that the Service vector can actually pass over the DMARK and end up on the LAN, where it would be used to create an extension of the carrier logical service all the way to the desktop consumers.

The Newbridge initiative is interesting in that the company is planning to push for standardization of critical service coordination elements that would be needed to extend a carrier service virtual pipe onto the premises. This is not only helpful to the buyer (who believes that all services are end-to-end no matter what their purchase jurisdiction may be), it's also helpful to the broad issue of how multi-vendor networks would be provisioned using the object model even at the carrier level.

One major player that has still not weighed in with its own offering is Cisco. Because of the StrataCom acquisition, Cisco is faced with a dualistic challenge: making object provisioning work in a general management sense, and making effectors for the connectionless router implementation of specific services work, too. The latter challenge probably involves specification or endorsement of standards, since multi-vendor router networks are common.

Policy management is the key to the connectionless part of object provisioning. A connectionless network is a blank slate onto which policy management tools write services, as CIMI Corporation is wont to say. Those tools must write to compatible effectors, proprietary or otherwise. How MPLS, NetFlow, or other concepts that Cisco might embrace will combine with ATM and virtual circuits to bring this about is far from clear, but we can expect that Cisco will move quickly to rectify that problem now that so many competitors have moved.

It is clear that a lot more is going to be done in this space, and we'll cover the details of each vendor's implementation in our infrastructure switching vendor review. As needed, we'll also include comments on approaches or general technology trends.

We expect to start our per-vendor infrastructure switch review either in the November or January issues, depending on the pace of vendor response. So far, we've got Ascend, Cisco, Lucent, and Newbridge nominated. December is the Annual Technology Forecast Issue. Remember, that issue is for subscribers only and will not be posted to the Internet.

Access the index of CIMI Corporation's recent newsletters.