Netwatcher (ISSN 0890-5800) is a monthly publication of CIMI Corporation. Subscription information is available here . Copyright © 1998, CIMI Corporation. All rights reserved. No publication or reproduction of this document is permitted without the express written consent of CIMI Corporation.

The mega-PR-blitz associated with the BANC ONE outsourcing announcement is sure to raise corporate interest in outsourcing. Few organizations today outsource as large a portion of there IS/networking activity as this, but there is some indication the trend to do so is accelerating.

Business users of networking have had problems with acquiring and retaining skilled labor for years, but the problem is becoming more acute as more business activities are becoming techno-centric. The spread of low-cost PCs and servers, and the recent growth in the deployment of low-cost LAN switches, has combined with aggressive development of shrink-wrapped network-enabled applications to create a host of new activities that depend on networks and computers. With this new wave has come a new wave of support discontent.

CIMI Corporation research has documented a shift in attitudes toward large-scale outsourcing that began a decade ago. This attitude shift, however, has not driven a corresponding shift in technology commitment. The average business user may be considerably more favorably disposed toward outsourcing, but that same user isn’t much more likely to execute a large-scale outsource agreement today than they were ten years ago.

The problem is one of transition, according to most users. New technology activities are launched as projects, which have a specific business goal, a specific benefit case, and a limited cost tolerance. In most cases, project activity cannot influence broad technology policy because there isn’t enough money in the benefit piggy-bank to fund a major change. In addition, limited-benefit projects usually don’t have the breadth of political support needed to change everyone’s technology support paradigm, as a large-scale outsource project would.

Why not limited-scope outsourcing, or "project outsourcing", then? The reason most users give is that projects usually combine a few new resources with existing resources (networks or computers) to fulfill their mission. It is very difficult for an outsource firm to take responsibility for technology elements that have multiple uses, without taking over all of the elements that those multiple uses happen to touch. Thus, only a project with a very isolated set of resources could be readily outsourced.

The first outsourcing decision a company must make is how much of their information systems activity to outsource. Some organizations have elected to outsource networking only, some computing only, and some both. While it’s hard to generalize about how organizations might want to provide their internal technology projects and activities with support, we believe that most outsourcing of computing activities will inevitably lead to outsourcing networking as well. The reverse is true nearly as often.

If both types of outsourcing draw the other in, does it matter which is considered first, or should both always be considered together? In our analysis of successful and unsuccessful outsourcing projects, there appears to be a clear indicator that the best outsourcing projects are ones where network resources and performance issues were outsourced first. We thus come to our first recommendation; network outsourcing should be the primary planning focus for any organization reviewing outsourcing at all.

Outsourcing a network activity can be done in one (or more) of three ways:

1. An outsourcing contract where a provider "buys back" existing network equipment and absorbs existing responsibilities, in return for a fee. What the customer has, in effect, is an externally supported version of their previous network.
2. Managed services, where a service provider offers a user a new network service and CPE bundle to augment or displace private networking.
3. Virtual Private Networks (VPNs), which absorb more (if not all) of the traditional network devices and facilities into a carrier-owned-and-managed service network, one that requires the user simply to attach to it.

In the long run, most outsource firms will expect to make money on their customers by providing the services of the customers’ networks more efficiently. One way that may be done is to convert leased-line private networks to some form of public data service like frame relay or VPNs, to reduce network service cost.

When this happens, the savings are at least as likely to fatten the profits of the outsource firm as to control the cost to the buyers. Thus, any consideration of network outsourcing of the first type mentioned above should take place only after other options have been considered, and perhaps implemented.

Now for the "types" of outsourcing.

Project outsourcing, in a network sense, is most readily accommodated through the use of VPNs or managed services. When a new project requires the consumption of new network services, the user may acquire those services in outsourced form rather than enhance the private network to support them. The key here is to be sure that the traffic for the new project can be conveniently isolated from other traffic, so the outsource network is not burdened by applications that were never supposed to consume it.

The question of whether to buy a VPN or a managed service to support project outsourcing must be decided on the basis of relative cost, and the scope of the project involved. If a project will consume existing premises networks (LANs) and simply require new WAN bandwidth, VPNs are the best approach. If the project will require augmenting the LAN as well, and if those LAN enhancements can be isolated from the rest of the LAN traffic and user base, it may be wise to consider managed services. This is particularly true if one of the following conditions is expected:

1. The LAN and WAN elements involved will have to work closely together to provide the support needed for the project. This might be the case if the application required special QoS, involved video, etc.
2. There was little or no technical support available internally for the LAN activity. In this case, problems with the LAN might impact the application and be beyond the scope of the organization to solve.
3. The interaction between LAN and WAN might influence a service parameter the WAN outsource provider (the managed service carrier) would be asked to guarantee. For example, if the carrier is asked to guarantee application-level network availability, control over both LAN and WAN would be required.

Often, buyers who look at managed services or VPNs like the long-term benefits of the concept, but can’t seem to figure out how to get there. That’s where transitional outsourcing comes in. The goal of this type of outsourcing is to fulfill a temporary requirement for skills during a phased migration from private to outsourced technology.

Why not consider transitional outsourcing a part of project or total outsourcing, if it’s likely to be the first phase of such an activity? Because the ideal transitional outsource provider may not be the provider of the project or total outsource solution. Typically, a network outsource vendor will be a service provider or the primary computer vendor. The transitional outsource provider may be an equipment vendor or a management consulting firm.

Even if the transitional provider is the same firm that will provide long-term project or total outsourcing, it’s a good idea to plan the transition project as though it will be executed by a separate firm. This will insure that there’s a clean demarcation between the transition phase and the ultimate outsourcing activity. It will also allow the buyer to bail out of the activity under certain conditions during the transition—like specific objectives for performance can’t be met.

Where there’s any chance new applications will come along, it’s important to be sure the network outsource strategy will accommodate them. This is most easily done by negotiating a cost escalation rate based on traffic levels, new sites, etc., as a part of the initial contract. That way, the price for change is readily predicted, and can be factored into the business planning process.

It’s difficult to provide this kind of simple expansion clause if the new applications might present totally different requirements than the old. If this is the case, there are a number of options:

1. Try to converge the applications already running, and future applications, in a single network architecture. That’s the appeal of IP VPNs; IP is a logical protocol to make the "standard" for future applications, and IP networks can be made to support most current applications, even those involving other protocols (like SNA, as our Strategies section below will show).
2. Look to VPNs rather than to managed services if there is likely to be a lot of new application growth. Each new application can be considered a "VPN" of its own, and the terms and conditions for securing these new VPNs can be developed in the initial contract, based on traffic levels, QoS requirements, and sites served.
3. Employ transitional outsourcing to assist in developing a network service set on which all future applications must be based, and be sure that the service terms for all these services are called out in the outsource contract.

In our last issue, we talked a bit about the applications of SS7 and the value of SS7 technology to companies like Ascend and Cisco (important because both just acquired an SS7 player).

This issue, we’d like to talk about the way that the evolving intelligent network standards (IN internationally, and AIN here) might be used by a data player to enter the voice marketplace.

There is probably no more perplexing problem for the organization seeking a single and unified network strategy than that of SNA. As the premier network architecture for IBM mainframes, SNA became a networking fixture for all of the mission-critical applications run on early data center systems.

While other applications using other protocols have grown faster than these core applications, the amount of traffic carried by SNA networks today, measured in bits per year, is higher today than ever before, and will continue to grow for some years to come. These incumbent SNA applications, because they are mission-critical, are the most difficult of all to change.

On the other hand, they aren’t making more of them—the users, that is. Most new applications today use TCP/IP for their protocol, and the percentage that do is increasing yearly. By about 2001, new SNA applications will largely have ceased to develop, so future networks will contend with traffic that is shifting more and more to TCP/IP.

1. Encapsulate TCP/IP in SNA and continue with SNA networks.
2. Encapsulate SNA in TCP/IP and build TCP/IP networks.
3. Use a lower-level protocol like frame relay to create multiple virtual networks—one for SNA and one for TCP/IP.
4. Outsource TCP/IP traffic to a new network (a VPN, for example) and let that grow, while maintaining SNA as a private network.
5. Outsource both SNA and TCP/IP to VPN providers.

Paramount among the issues in evaluating these choices is stability of the existing SNA applications. Many users who have undertaken SNA network migrations have learned to their dismay that business units don’t have much tolerance for network problems associated with conversion activities. Since these activities are perceived to have no business benefit, the line departments don’t cut network guys any slack when something breaks—as it inevitably does.

If you examine the approaches in the list above, it’s clear that all of them must come down to a question of encapsulation. You either encapsulate SNA, IP, or both protocols. The question, then, about SNA migration comes down to a question of the stability of the applications under the various encapsulation options.

With due apologies to some within IBM, we must rule out the option of encapsulating IP in SNA. In truth, this option has a lot of technical merit to it—perhaps more than the opposite approach that has gotten a lot better press. The problem is that SNA routing nodes, whether they’re APPN Network Nodes or subarea PU4s, are more expensive to buy and support than routers, and most organizations are not going to deploy them in large numbers.

The value of virtual circuit segregation of traffic by protocol is clear. SNA applications could continue to develop, or sustain themselves, or shrink. IP could do likewise. Resource balances between the two protocols could be controlled by allocating virtual circuit resources according to the current priorities of the business. Public frame/cell services could be integrated with private services fairly easily.

The biggest advantage of this approach is the fact that both SNA and TCP/IP would continue to be operated and managed largely independently, meaning that the support and planning skills, performance levels, and other attributes of existing network architectures would be sustained.

Making SNA work in this environment is fairly simple. Modern SNA devices support frame relay interfaces directly, and research by CIMI Corporation indicates that this type of network connection is almost completely trouble-free. Where there is no direct frame relay support, FRADs can be used to adapt SNA devices to frame relay. This tends to give buyers somewhat more trouble than the direct interface approach, but once the early problems are resolved, acceptance of the FRAD strategy by users is nearly 100% as well.

Why, then, has this concept not caught on?

One big reason is lack of press validation. The media has never been kind to IBM, for one thing, and so IBM’s approaches were rarely given a fair shake. Another problem is that the SNA buyer is only a small part of the readership of most magazines, and so is unlikely to be catered to in terms of content. This meant that many SNA issues were simply never covered. Finally, IBM’s own presentation of its story has been almost universally crummy, and often so complex that even SNA analysts were hard-pressed to understand it.

But another problem at least equal in weight is the cost of the equipment. Frame relay or ATM switches must underlay IP routers and SNA routing nodes, which means that both sets of devices must be provided. In addition, alternate routing capability for either IP or SNA must either be provided at the frame level in some way supported by the protocol’s network layer, or provided in routing nodes at the network layer. Subarea SNA routing nodes are expensive.

IBM recognized some of this, and proposed first to address it by migrating subarea SNA to APPN, and then by providing High-Performance Routing (HPR) as a kind adaptive Level 2 protocol. Both measures were technically sound (perhaps, again, superior), but both probably came too late and were not given proper press validation.

A final problem with the virtual network approach was the lack of understanding of the SNA user by the frame relay service providers. The media may have played a role in this as well, by offering a distorted view of the market, but that doesn’t absolve the carriers. Few did any realistic research to gather information on what SNA users needed in order to support a frame relay commitment. Had they done so, a very large percentage of SNA might now be converted from private line to frame relay, and the concept of virtual parallel SNA and IP networks would be awaiting only a similar commitment of IP traffic to frame relay. The carriers didn’t plan correctly, and so multiple virtual networks haven’t happened.

Early SNA-over-IP was an unmitigated disaster. IP encapsulation was done at Level 2, which made the IP path appear as a virtual wire to the SNA protocol (SDLC for WANs, or LLC2 for LANs). This exposed applications to link-layer timeouts, and attempts to recover from lost IP packets often resulted in SNA messages appearing out of context or sequence. This almost always caused the session to fail.

Two strategies were added to basic IP encapsulation to solve the problems. First was local session termination, or "spoofing" of the LLC2 or SDLC layer. This stopped the link-level timers and created a more stable environment. It also eliminated link-layer error recovery, because the local termination point acknowledged the data and thus made it impossible for the source to re-send if it were lost. To resolve this, error recovery had to be added over the internal IP path.

Three approaches to IP error recovery have been deployed:

1. Use of TCP between the session termination points—the strategy employed in Data Link Switching (DLSw).
2. Use of a "new" LLC2 session between session termination points, something 3Com used in its Boundary Routing approach. For this, LLC2 is encapsulated in IP, however.
3. HPR encapsulation over IP, something that IBM introduced with its Branch Extender concept last year.

Each of these approaches has its plusses and minuses.

The use of LLC2 to encapsulate and provide error correction for SNA maintains one of SNA’s standard link layer protocols. As an alternative to SDLC, LLC2 provides longer timeout intervals and larger window sizes, both of which make it more tolerant of network delay. It’s also a relatively simple protocol to implement, which means it probably won’t have a major impact on the performance of the nodes that connect SNA devices to the network.

The problem with LLC2 encapsulation is that the window mechanism for acknowledgement of transmission means that a relatively large amount of data might have to be retransmitted to recover from a single lost packet. The amount of "extra" data retransmitted depends on the round-trip delay of the network and the speed of the SNA devices—something called the "delay-bandwidth product". In the face of a high error rate, LLC2 tends to become inefficient in a hurry.

LLC2 also doesn’t protect against out-of-sequence arrivals. Because it was designed for an environment where data could not pass earlier packets, there is no provision for reordering of information. Thus, a packet out of order creates the impression of a packet loss of everything from the last correct reception to the first higher sequence number.

The TCP encapsulation approach seems the most logical, because TCP is the protocol that is usually added to IP to provide it with flow control and error recovery. TCP is a Level 4 protocol, and it is designed for connectionless networks and so recovers from out-of-sequence arrivals.

The ability of TCP to recover from out-of-sequence arrivals makes it possible for TCP to support something close to selective retransmission. If a packet is lost, the higher-numbered packets that are received don’t have to be discarded as they would with LLC2, but instead can be saved while the receiver requests the retransmission (implicitly, not explicitly).

The problem with TCP comes from the fact that its flow control strategy was designed in part to deal with problems of congestion in IP networks. TCP senders have a maximum window size assigned to them by their receivers, often based on buffer limits. When sending begins, the process "slow-starts", building up from a minimum window size to this upper limit over time. This process of starting off at a low window size and building is also invoked when packets are lost (under various conditions, the process of building to the maximum window size can be geometric or algebraic).

All these slow start strategies mean that the optimum window setting for TCP may not be achieved, even if the receiver will support it. Remember that to sustain maximum throughput, the window size must be greater than or equal to the product of the round-trip delay and the incoming data source’s speed. Smaller windows will close prematurely and throttle flow.

IBM’s HPR deals with this by providing both flexible flow control and true selective reject. The latter concept is pretty much unique to HPR from a commercial protocol perspective, and thus requires explanation.

With selective reject, a receiver who loses a particular packet simply sends a request for the missing sequence number, and the sender responds by providing the packet again. This process is very efficient, requiring little delay and no transmission of additional (non-errored) packets, as a window protocol would.

The problem with HPR has been that it was initially a low-level protocol for APPN, and thus required full APPN features to invoke. While HPR devices could be confined to the edges of a network, HPR’s rerouting features operate between HPR nodes, and this would be less effective if no internal network devices were HPR-aware.

HPR runs now over IP, as well as over frame relay, leased lines, ATM, and a bunch of other transport network protocols. This feature can make it possible to establish HPR routes across multiple service networks.

What’s the best approach? HPR is unquestionably the best in an efficiency and availability sense, assuming that the underlying IP network is somewhat unreliable. As the capabilities of the IP network improve, the benefit of HPR over other approaches begins to decline. This is particularly true if the improvement in IP performance is an improvement in the packet loss rate. HPR’s special benefit lies in its ability to recover from errors, so if there aren’t any, the benefit is minimal (HPR is required in some high-availability SNA applications, if IP is to be used, no matter what the low-level network performance is).

SNA applications using 3270 protocols can be made to run on IP by using TN3270, a client/server terminal emulation architecture that converts an SNA/3270 data stream to an IP-encapsulated TN3270 stream at the boundary between the SNA and IP networks. IP users then run the client TN3270 product to pair with the server over IP and deliver the 3270 presentation stream. A similar approach could be built using Java applets.

One problem with this approach is that too many people think it’s a cure-all. Performance issues are not addressed in a TN3270 application; IP network design must assure the IP portion of the flow is regulated and stable. Since there are, at present, no standard ways of doing that, this may be a tall order.

Vendors and service providers understand this. Nortel, in its recent SNA/IP announcement, indicated it would have RSVP support to allow SNA session paths to be prioritized. That’s a good approach if the whole network is made up of RSVP-capable routers that support RSVP in a compatible way, but that happy situation won’t prevail in many places today.

In truth, IBM had it right from the start. The best way to support IP/SNA evolution is the virtual circuit route. This would allow buyers to sustain current practices in both the SNA and IP areas, or evolve new practices for either, without regard for the impact on the other technology. That could be a major benefit in an age where the predicted rate of migration to IP (or to anything else) has tended to be faster than the rate eventually experienced.

Certainly the option of SNA over IP has its challenges—far more than any analyst or media article or white paper would suggest. We’ve seen many indications that users can, with diligent effort, tune SNA/IP applications to perform with a very high degree of reliability and efficiency, but we’ve also seen many situations where the user lacked the skills needed, and the vendors or service providers couldn’t provide any useful guidance.

Our next issue will offer an overview of the new Global Information Infrastructure (GII), an initiative of the ITU that seems to have the same goals as many pundits would assign to the Internet. Are we looking at a standards-worlds-in-collision scenario? We’ll see.

Access the index of CIMI Corporation's recent newsletters.