There's no question that frame relay is getting more popular, but there is also no question that the pace of growth for the service is slower than many had hoped. In this issue dedicated to frame relay topics, we're going to examine the service from all its angles, and try to deal with the most compelling frame relay question you could ask: "Is the service right for my network?".

From a high-level planning perspective, frame relay offers a number of benefits over private networking:

1. Frame relay, as a public network service, can combine the traffic of many users to create bandwidth economy of scale and utilization optimization. This will generally reduce public frame relay service costs below the levels attainable through simple private networking.
2. As a network protocol that operates below OSI Level 2, frame relay is compatible with virtually all the data protocols in use today. Frame relay virtual circuits can be interchanged for leased lines on almost all the data switch products made, no matter what the application. Thus, frame relay may help to harmonize disparate network architectures in a business.
3. Public frame relay services shift the burden of nodal networking to the carrier. In a private network, each trunk must terminate in a node, and routing nodes located within a network account for almost two-thirds of all the network support problems. They also account for almost two-thirds the capital cost. Public frame relay shifts all of that to someone else.
4. Because frame relay is based on a virtual circuit paradigm, the topology of a network is dependent only on how the virtual circuits are routed. This allows a buyer to create a network topology that matches the high-level protocol's needs – a star for SNA, a mesh for TCP/IP.

All of these are good reasons to get a frame relay service.

Why, then, don't all users shift their private networks to frame relay? Clearly, some are simply squatting down on a comfortable position, but that can't explain why something so obviously attractive from a technical perspective can't penetrate more than about 15% of the data market.

The biggest problem with public frame relay is that it's public. In a private network, a business can make all the decisions on the price/performance trade-offs themselves. Want faster lines? Buy them. Want faster response times? You can buy them, too. In a public network, a buyer is limited in the scope of exercising network prerogatives to the boundaries of the defined services. Go to a frame relay carrier and ask for a faster trunk between two of their nodes and see what happens.

The public nature of frame relay has some specific issues related to it, primarily in the area of quality of service. In any network that shares bandwidth on a statistical multiplexing basis, the combined network users have the capacity to send more information into the network than the network has guaranteed to carry (and, in general, is provisioned to carry). This "overload" or "oversubscription" is crucial to the economics of the service. If traffic peaks set network resource limits, then most of the time the network would be under-utilized, and we'd end up with something no more economical than TDM.

But the fact that the network can't carry everything makes users wary of just what it will carry at any given point in time. This worry is exacerbated by the fact that what is likely to impact the "carriage quantity of the moment" is someone else's traffic. If User A squirts a bit too much data into the network, will other users suffer some of the consequences? That's a good, hard, question.

The fear of cross-user performance impact isn't helped by the way that carriers have elected to price frame relay services. Frame relay standards provide a fairly detailed set of parameters that are designed to let users share a network with some confidence that the performance cross-talk won't be objectionable. Central to this assurance is the idea that the network will police users to a very specific level of traffic.

Policing is a polite term for discarding data, and that isn't the sort of thing that makes carriers popular with their buyers. With frame relay, as with other services, carriers have tended to underplay the policing aspects of frame relay and thus provide services in a way that may defeat the standard facilities to isolate users from one another.

The market response to this problem is the service-level agreement. With an SLA in place, a buyer has an assurance that the carrier will make the network work according to specification, and doesn't know or even care how that happens. That lack of knowing and caring isn't a typical 1990's shirking of responsibility, it's essential. The buyer, having no control over the nodes and trunks, can't do anything directly about performance or performance trade-offs. The only recourse is to use indirect leverage – make somebody (the carrier) responsible in law for something, and let nature and lawyers take their course.

But users can't completely cleanse themselves from risk with SLAs, in most cases. Frame relay traffic passes through user network equipment on the way to the carrier cloud. The way the data is handled there is often as important in setting the performance levels applications will see, as the way data is handled inside the frame relay network.

Frame relay provides congestion notification to connected devices, and also warnings that the traffic is exceeding the limits agreed upon by the carrier. If the devices don't heed these warnings, the result can be network discarding under terms that the SLA will force buyers to accept. Play by the rules, or suffer the consequences, is a good condensation of SLA goals, and it works against the user as well as the carrier. You have to promise traffic limits to get an SLA, and if you break the limits, your carrier can throw your stuff away.

But keeping the rules in the devices handling the interface to a frame relay service isn't a slam dunk. Suppose the network signals the user to throttle back because congestion is occurring. What happens? The router (let's say) at the edge obligingly reduces its output by 15% or so. The input traffic to the router continues unabated, and the buffers start to fill up. Network delay mounts. Eventually, the router discards the traffic. Some help that was.

The need to have the edge devices work effectively with the service is one of the motivations behind the adopting of managed services in frame relay networking. With a managed service, the network user shifts responsibility for the access device to the carrier, so the "virtual DMARK" is now on the port side of the device, toward the desktop or LAN. The operation of the edge device, and its inter-operation with the network, is now in the hands of the network operator, and the SLA can be measured outside that edge device. Router discards, network discards – same issue now, because the carrier has adopted the router.

Remember the old "bear goes over the mountain" story? Every time the poor bear got to the top of a hill, there was another one looming right next door. So it is with premises devices. Pull the access router into the carrier cloud and the next router down the line becomes the battleground of user-versus-carrier jurisdiction. That is what has prompted some users to ask for carrier management extension far inside the premises network.

What's the best answer? There is no question that future networks will be dominated by services like frame relay, services that require users to peacefully coexist on a shared infrastructure. There is no question that a large part of this peaceful coexisting will depend on SLAs, but there is also no question that some form of traffic control on the premises will be a requirement, or conditions at the DMARK will be difficult to manage and the interaction of the premises and carrier networks will create holes that will generate endless finger-pointing.

One thing that buyers must plan to do is to increase the capacity of their premises and campus networks as far as reasonable capital-cost-of-bandwidth limits will permit. If the premises network doesn't congest, then its congestion cannot impact the carrier service in any way.

A second thing to consider is increasing the buffer capacity in the boundary devices. Congestion is caused by capacity limits, and if the wide-area service will occasionally be taxed in capacity then congestion is inevitable. What a buffer will do for you is allow you to trade delay for discarding. Whether you really want to exercise this right for all your applications is something we'll cover later on, but having large buffers at the edge will at least give you an option.

The third thing to consider is proactive monitoring of the parameters that signal network congestion or performance problems. Like symptoms of a disease, these values will help you find problems before they get to the stage where catastrophic reaction is likely.

A final point is to watch the progress in the end-to-end traffic management or policy management area. Traffic shaping with buffers in an edge device is a nice stopgap measure, but all flow control reduces to shutting up the sender – do less than that and you'll only move around the place where traffic is discarded. There are some vendors now working to improve the way that congestion is communicated back over the LAN to the application, and those strategies, if effective, will allow traffic sources to respond directly to congestion.

Another thing that users worry about with frame relay is security. There is a network planner right now, somewhere, agonizing over the question of whether some critical piece of corporate intelligence hasn't been misdirected to arrive at a competitor's site instead. With all that stuff whizzing around on virtual circuits, why couldn't something short-circuit, virtual-wise?

There are probably thousands of vendors and consultants who will tell you this can happen, but it's not really true. The chances of something short-circuiting in a virtual circuit network aren't really much greater than that the same thing would happen in a leased-line network. Do you think "leased line" means a private, continuous, copper wire from source to destination? Most of the leased line is a time-slot in a TDM multiplexer, and just as subject to accidental routing errors as a frame would be.

Let's suppose you hit the jackpot and get a frame delivered to the wrong destination. What do they do with it? Even if the frame contains something useful in theory, what is the chance that it contains a full message whose meaning can be determined?

Speaking of context, how about protocol context. Suppose key formulas for a competitor's secret product were to be switched into an SNA data stream in your network. Windfall? No, context error, rejected message. You'd never see the message at all, because it would have zero chance of having the proper protocol headers for the context in which it was received. It might take the link down, but it wouldn't be deliverable.

In truth, leased lines are probably easier to tap than virtual circuits, because there is a specific physical place where they go, and their routes can be easily traced. Where does a virtual circuit go? Virtually anywhere.

This doesn't mean that you can just abrogate responsibility for data security. Data line analyzers and RMON probes can read data, and as carriers become management partners, they also become theoretical security risks. Handle this through the service contract. While SLAs won't generally be approved if they contain terms like consequential damages, you can certainly expect to collect big time if a carrier employee steals your trade secrets and sells them to a competitor. If the carrier is comfortable with your legal remedy should this occur, without special technical provisions like encryption, let them be so.

There are issues in frame relay service, issues that could impact the service value you receive as a buyer. What is probably true is that the marketplace has exaggerated the relatively simple problems (as it often does) to create a major perception of risk. That just isn't warranted. Frame relay is a concept with five years of happy history behind it, and you are undermining your network if you don't give it serious consideration.

The burning question in the minds of many users today is whether services like frame relay can be pulled out of their strictly data context and moved into the world of voice or video.

There are two basic ways of developing frame relay's multimedia potential. The first, and perhaps most versatile, is the H.323 architecture. Designed for generalized packet voice and video applications, H.323 has the virtue of being adaptable to any combination of transport facilities, because it can be used at the IP level.

The specific architecture for voice over frame relay is defined in the Frame Relay Forum's FRF.11 standard, available on the Internet. FRF.11 will attempt to harmonize the somewhat disorderly and proprietary processes now supporting the voice-over-frame application set.

Technology notwithstanding, though, is any of this a good idea? The answer to that lays in the two specific applications for voice or multimedia over frame. They are:

1. The creation of collaborative networks to support data-voice or data-voice-video real-time relationships that create a virtual presence to substitute for real meetings.
2. The transport of voice or video over frame as a simple economically driven alternative to traditional voice or video networking.

The value of voice over frame in the context of collaborative applications is actually the most problematic of the two. Frame relay is a sub-Level-2 technology, and as such is not suitable for direct exploitation by applications. In simple terms, this is because there are no frame relay services to the desktop. In order to create a collaborative application, we first must link the collaborators. If a logical protocol choice is made in this area (IP, for example), the collaborative focus becomes multimedia over IP and not over whatever happens to be the carrier transport mechanism. Voice would first be IP-encapsulated, and then carried in frames for part of the trip to the destination.

The complicating factor here is the indirectness of the frame participation. The issue of collaboration-over-frame is really a frame issue only to the extent that it impacts service quality. If multimedia applications have a different QoS requirement, we must consider how to achieve it in our frame network. Beyond that, multimedia in H.323 form is really just another application.

The second issue of value for voice over frame is controversial, because it can be interpreted in two ways. First, the "simple economically driven alternative" created by some hard technical mechanism that implies a real benefit to voice over frame exists. Second, it can be created by pricing factors in voice and frame relay services, and thus be more arbitrage- than utility-driven.

Voice compression is at the heart of any assertion that voice over anything other than voice networks is more economical. Since the early 1980s, vendors and standards bodies have groped with the issues of economical voice transport. Standard voice coding, called Pulse Code Modulation or PCM, samples voice 8,000 times a second and generates an 8-bit value for each sample. The result is a 64 Kbps bit stream, continuous and synchronized. Reducing sample size to 4 bits by doing adaptive differential coding (measuring change and not absolute value) resulted in (not surprisingly) Adaptive Differential PCM, or ADPCM, but this still required 32 Kbps, though new improvements have reduced the ADPCM requirements to 16 Kbps.

Newer compression-based voice systems rely on a form of linear predictive code (LPC), which offers higher voice transport efficiency and a collateral benefit of easier encapsulation in data packets. LPC standards vary considerably in performance and somewhat in technology, but they offer speech quality as good as high-bit-rate ADPCM at rates as low as 8 Kbps. The FRF.11 standard calls out standard PCM and ADPCM coding payloads, and also G.728 and G.723 compressed payloads.

The edge of an FRF.11 network is a voice FRAD or VFRAD. This device is responsible for doing whatever must be done to speech signaling and coding to make it frame relay compatible (in fact, transparent). To the frame relay network, the VFRAD is simply an edge device, and there is no awareness of voice over frame other than the special QoS, if any.

The duties (potentially) of a VFRAD are:

1. Signal conversion between the voice signaling system and the frame relay call setup process.
2. Address conversion between the public voice space and the frame relay space.
3. Local termination, optionally, of modem and fax streams to convert them back to digital data format for more efficient transport.
4. Compression/decompression of the voice traffic itself.

In the current FRF.11 standard, many of these functions are conveniently offloaded onto the VFRAD or the end systems. This becomes clear when you take the potential features one at a time.

Signaling is required if you are going to translate between voice switched calls and SVCs, but FRF.11 assumes static PVCs linking VFRADs. Thus, the VFRAD does not set up a call at all, but simply allocates one to an existing "tie line" circuit. Future standards will surely address the call mapping process, however.

The address conversion process is unclear, or at least ambiguous in FRF.11. The standard assumes that there is an external voice source that selects a trunk line on which to route a call. The frame relay network provides a simple extension of that trunk line, and thus is not a participant in call routing. This makes it address-independent as well.

The process of data/fax termination is standardized in that it is a signaled service, but it is not a mandatory feature of the standard. The theory is that if the voice modulation of a modem is terminated at the VFRAD and the data recovered, there is less chance the frame transport process will contaminate the transmission.

It is in the voice compression and transport area that FRF.11 spends most of its time. The operation of a VFRAD is similar to that of a subchannel multiplexer. Each voice input channel is associated with a VOFR subchannel, and each subchannel with a PVC to a fixed partner VFRAD that serves partner voice sites. The frame payload of each PVC is made up of subchannel payloads for each of the supported subchannels. Some subchannels may support a fax or data modem stream.

Subchannel payloads contain a payload type code that distinguishes between the traffic itself, and signaling and management traffic. Encoded voice, encoded fax, and data may be carried in the primary payload type. Secondary types are used for channel-associated signaling and DTMF digits, certain fax relay functions, and end-to-end fault notifications.

Signal coding is managed by the VFRADs. Each must translate any inband (or, in theory, common channel) signaling to a digit-coding system based on the DTMF keypad. These signals are carried on their own payload type to the destination, which regenerates the original signaling from the data. There is no mechanism for determining what the signaling capability of an endpoint is, because it is assumed that the relationship between VFRADs is based on PVCs, and thus is administratively known. To maintain signaling timing, signal payloads are generated at 20 mSec intervals.

The robbed-bit signaling of a T1 trunk is also carried in a packet. Signal bit values are carried in current, recent (20 mSec ago) and previous (40 mSec ago) form to help detect transitions in the bit state.

Data, fax, and voice payloads are sequence numbered. For data and fax, frames are accumulated to a maximum size dependent on the frame size limits, but the VFRAD can break off the generation at convenient points. Fax payloads have sizes based on the modulation rate, from 72 bytes for 14.4 Kbps down to 12 bytes for a 2400 bps connection.

Voice information is packaged dependent on the type of information:

1. G.729 CS-ACELP compressed voice generates an 80-bit code packet for each 10 mSec of speech. This can be packed into frames to a maximum of six frames of 80 bits, or 60 bytes.
2. PCM coded under G.711, G.726, or G.727 is coded using the recommendations of G.764. This arcane standard allows for the separation of the coded traffic so that the least significant bits can be transported with DE set so that they can be discarded in case of congestion. Since the loss of the least significant bits poses less risk to speech quality, this is better than dropping entire packets of coded speech. The coding interval is 5 mSec, and packet length depends on the ADPCM scheme used. Sequence numbers are provided to form a 5 mSec clock that can be used to recover speech timing at the other end.
3. G.728 creates 10-bit code packets for each five consecutive samples of speech (625 microseconds). Eight code packets (5 mSec worth) combine to create a block. This complex relationship was selected to make the block interval the same for this coding system as for ADPCM.

The applications for which FRF.11 are targeted are voice transport rather than voice calling. Front-ending the VFRAD is probably a PBX or key telephone system, and the VFRAD emulates a number of voice tie trunks. The same configuration exists at the other end. When a call is placed, the PBX determines that the destination is on the VFRAD virtual tie-line and routes the call onto what is probably a DS0 on a T1 trunk to that device.

The VFRAD translates the signaling on the incoming call, but not to process it. Instead, it packetizes the signal digits and communicates them to the other side, which then out-calls to the PBX. If the call completes, the speech from both sides is packetized according to whatever its format happens to be, and shipped out over the frame relay network.

This process pretty clearly doesn't add much value to the frame relay side of the picture. The standard is really intended only to insure that the interpretation of the signaling and data packets is consistent throughout. The reason for the limited utility is the mission itself; voice over frame will probably be an application that the carrier won't knowingly support, and thus won't contribute to in a feature sense.

The problem with voice over frame is the duty cycle of the information. An FRF.11 trunk, active and supporting a conversation, will consume anywhere from about 11 Kbps to 40 Kbps of bandwidth per DS0 of voice. The same DS0 of voice used in a data application, would consume between 6 and 16 Kbps of bandwidth. The voice will probably generate complaints on delay and delay jitter, where the same delay and jitter might go unnoticed in a data conversation.

The nature of FRF.11 and of voice over frame relay in general could be expected to change to the extent that frame relay itself changed. The change most likely to impact voice over frame is the widespread support of SVCs.

SVCs would allow VFRADs to actually create a virtual circuit to a destination location instead of using a static one. This would reduce the cost of supporting frame voice connections to sites with relatively little mutual traffic; today, with FRF.11, there has to be a PVC in place for each voice relationship – each virtual tie-line.

SVCs create problems for FRF.11, however. The obvious one is that the standard would have to include the ability to decode addresses rather than simply pass them, and to use these addresses to signal a call over the frame relay network. If you make calls, you also have to translate call progress signals. If you decode addresses, you have to look like a tandem switch or a public switched network to subscribers. So on it goes, and each change adds to cost.

Another problem created by SVCs is that the whole packaging of information in FRF.11 is based on the assumption that there are a bunch of voice channels sharing a PVC. The efficiency of transport would fall off if only one subchannel payload was available to form into frames, yet one would have to assume that with SVC-based frame voice, calls might be placed to a destination that was previously idle.

That assumption may be the saving grace of the whole concept. Frame relay – even switched frame relay – may become widely used, but switched frame relay services probably won't become inter-company channels. Even if SVCs were offered to users and they accepted them, the likely mission would be to augment existing leased-line networks. The SVCs would be treated as ad hoc leased lines, with some form of carrier protection like closed user groups preventing others from just calling in.

In this mode of frame relay use, SVCs might not have value to the frame relay voice user. Most intra-company calling would be handled by the current PVC FRF.11 standards, and no inter-company calling could be expected to be practical.

Where SVCs might be useful is in applications where a public carrier decided to use a frame relay network as a long-distance network instead of leasing lines from a facility-based carrier. That might be a good think for the lessor, but the carrier providing the service is unlikely to find this a good business, and would probably not support its parasitic partner for long.

Given the fact that a standards body (of sorts – the Frame Relay Forum is really an industry consortium) has bothered to publish a standard in the voice-over-frame area, is there any validity to the concept? That's really two questions: is voice over frame realistic, and is FRF.11 a worthy effort to stabilize the technology?

With respect to the first question, there is no doubt that frame relay cannot displace voice networking at large. There is ubiquitous public voice connectivity, and there will probably never be anything like that for frame relay. Thus, people using voice over frame will always have to consider the frame relay domain a closed and limited community – a special delivery option to a small percentage of their voice partners.

Even if we consider the question of whether voice over frame is technically superior to analog voice as we know it today, we'd really have to assume that the compression strategies we'd need to apply to voice over frame would be applied to TDM voice as well. Sure, G.729 can support 8 Kbps voice, but it doesn't need frame relay to do it. We could re-architect our TDM voice networks to support compressed 8 Kbps audio channels. We could add fax and data recognition and local termination to make these two types of calls work on compressed channels. Would that cost money? You bet, but no more than it would cost for voice over frame to provide the same capabilities.

In truth, voice over frame is arbitrage today. Our current frame relay pricing policies create an artificial economy for voice over frame in some applications, and users there are eager to exploit it. If they can get a return on investment large enough to make the risk of tariff changes bearable, then go for it.

The question of the value of FRF.11 is related to the assumption that voice over frame is a tariff game, not a public telephony alternative. If we assume that the average user of voice over frame cannot (now or ever) make it a substitute for general telephone services, then we must recoup our investment in it by insuring that the limited applications where it pays back are fully exploited. One voice line over frame is not exactly full exploitation, so the Forum has developed a standard that works best with T1-level voice traffic – a lot of calls. There, economy of scale in the VFRAD would reduce capital costs, and the savings per call would be multiplied by a lot of calls. Result: payback is achieved.

There is a hole in the middle of this, obviously. There are users who are more interested in tagging voice tie line calls along with data on a long-haul PVC. Remote branch office applications abound in a country with about 22,000 main sites and 1.5 million branches. There, FRF.11 fails the test. The complexity of the standard is such that it is unlikely implementations at the one-line level would be cost-effective.

Is the answer an improved FRF.11? Probably not. What is more likely to happen is a flocking to voice over IP, with IP over frame. In other words, the H.323 model will probably win out in the end.

As we indicated at the beginning of this issue, buyers are probably more likely to reject frame relay services out of lack of comfort with the new technology than for lack of hardware or service availability. The classical solution to "fear limited markets" is to divide the fears into the "grounded" and "groundless" categories. The former is addressed by substantive changes in the products or services, and the latter by education.

The fact that there is so much hype in the market today, and no real way to determine what's true or objective, makes education difficult. You've got to learn from somebody who knows to start with, and who might that be?

The alternative approach is one validated by our consumer markets every day. We "insure" against risk, rather than work to reduce it, when the strategies for risk reduction are beyond our skill to implement.

In carrier services, this is the classical argument for managed service. A "managed service" is a carrier service where the carrier absorbs some of the technology risk of networking from the buyer – more than would be absorbed in traditional TDM-based private networking. Because the buyer is expected to know and do less, and the carrier essentially indemnifies the buyer against the consequences of ignorance, the two parties can come together.

From the start, we have to say that the idea that the network buyer is ignorant of network technology issues is a tough one for some to swallow. Obviously, there are many network operations personnel who are quite competent. But the real question is not whether we can find skilled people, but whether we can find enough.

In 1982, when CIMI Corporation first surveyed network "literacy" among users, there were about 14,000 points of significant network purchase activity in the US. Of these, about 12,000 were staffed with sufficient technology-literate personnel to perform their planning and operations functions effectively. In 1996, the points of purchase had grown to over 275,000, and the "points of literacy" to about 39,000. That about says it all.

Since skill levels vary, it would follow that to be effective managed service offerings would also have to vary. In fact, that's true, and they do. We can define managed services as consisting of three essential categories: connect services, integrated services, and outsourced services.

The first tier, connect services, is a set of carrier services that exist at a higher OSI layer than leased lines. These services include nodes, concentration facilities, and shared trunk resources that the network users consume. Because the nodes and trunks are managed by the carriers, the nodal problems (about two-thirds of all problems) become someone else's problem.

Frame relay is an example of a connect service, one operating at what we could call OSI Level 1a. ATM and SMDS are similarly managed services of the "connect" variety.

Connect services need not be frame/cell services, however. One of the most popular connect services today is "transparent LAN", an OSI Level 2 service that provides LAN-to-LAN internetworking, and is usually offered by local exchange providers. In fact, the biggest virtue of "transparent LAN" is the simplicity that the name connotes: you have a LAN, you know how to do this.

IP-based VPNs are also a form of connect service, this time operating at Level 3 of the OSI model. Many vendors and analysts (including CIMI Corporation) believe that as businesses converge on IP as the universal data protocol, they'll also become consumers of IP VPNs to the general exclusion of other connect services.

Whatever the OSI layer, connect services all provide something other than a digital bit pipe. The internal infrastructure of the network is outside the buyer's area of concern in a direct sense, but the operation of that infrastructure is crucial to the service's being available.

Service level agreements are the logical companion of any connect service, and no organization should consider using one without such an agreement (despite the fact that over 80% do just that). An SLA provides both buyer and seller the assurance that the other will play the role the network planning process envisioned. The buyer guarantees traffic levels, and the seller guarantees network service levels.

It is in the arbitration of these guarantees that problems often occur. Data protocols are highly interdependent in a device function sense: what happens to Router A can impact Router B. This cross-impact can result in somebody being perceived to have broken their service promises, when in fact the other party forced them to do so by contaminating their part of the network.

Even if this cross-impact doesn't occur in a particular network incident, the fact that it might creates all the ambiguity needed to start a fervent finger-pointing contest. Usually, the fingers are pointing in the area of the boundary device between the network service and the customer – the DMARK CPE.

The second tier of managed service is the integrated service. It attempts to resolve most of the network finger-pointing by extending the jurisdiction of the carrier one box further into the enterprise network. The carrier provides, configures, and manages the access device, and this eliminates the risk that interaction between this device and the service will result in a failure that nobody will own up to.

About half the new frame relay service sold today is sold as an integrated service, with the carrier providing the CPE. About 23% of all "managed services" are integrated services.

SLAs are just as critical to integrated services as they are to connect services. In fact, nobody should buy a connect service except in the context of an augmentation to a properly defined SLA, and nobody should buy an integrated service except as an extension to a connect service.

Basic SLAs define data transport characteristics, but SLAs for integrated services have to provide a bit more. First, they have to define the extent to which control/topology traffic will move between the two network jurisdictions, and who is responsible to block what in this area. Second, they have to define what management variables in the access device are visible to whom; in most cases, both user and network operator will need to see enough to confirm the SLA parameters are being met. Finally, they will have to define maintenance responsibility, availability, and response time, for the access CPE being integrated with the service.

About a third of today's integrated service customers believe that the carrier does a better job with its part of the network responsibility pie than the customer does internally. This is the foundation for the last tier of managed services: the "outsourced" service.

In an outsourced managed service, the carrier absorbs not only the responsibility for the access CPE, but also for CPE inside the premises network and not connected to the carrier service at all. In effect, the carrier is extending management agency beyond the virtual DMARK that the integrated service creates.

The biggest problem with an outsourced managed service is creating the SLA to define it. All SLAs are exchanges of promises, and the complexity of monitoring just who exchanged what and who's conforming to what they committed is daunting. The problem is that conditions on the LAN impact flows to the DMARK, and flows to the DMARK obviously impact services. The carrier can hardly promise to maintain a given set of performance parameters in the face of a 50% LAN traffic increase caused by a department deciding to get sports news via push technology from the Internet. Even if the Internet connection is made via a completely different service interface, such an increase in traffic would logically impact the performance of the network overall. Who then is responsible?

This, then, is the truth of managed services. The higher you go up the managed service ladder, the more the buyer shifts risk to the carrier. The more risk is shifted, the more precisely the promises of both parties must be defined, and the more meticulously the parameters must be monitored for compliance.

Consuming a high-level managed service is a technical challenge itself, and one that some organizations will be very hard pressed to meet. After all, the whole purpose of managed services was to reduce buyer technology involvement, so as to reduce risk or perceived risk.

This doesn't say that the benefits of managed services can't be realized, but it does say that the price of that realization may be a fairly complex project to define just what conditions the SLA will enforce, on both the buyer and the seller. If that can be done effectively, and monitored successfully, managed services will certainly be far less risky than traditional networking.

In the future, as managed services become the rule rather than the exception, we'll probably see reference SLAs that define both buyer and seller commitments based on user experience. This will make the purchase of managed services fairly simple. In the meantime, an element of any managed service project is the legal and technical task of providing the SLA.

The next issue (December) is our Annual Technology Forecast issue. No new subscriptions will be accepted starting with the December issue, and that issue will not be posted on the Internet.

Access the index of CIMI Corporation's recent newsletters.