52-10-21 Open Networking Transition Strategies Previous screen

Howard C. Berkowitz Payoff The economic and flexibility advantages of such open network architectures as Transmission Control Protocol/Internet Protocol (TCP/IP) and Open Systems Interconnection (OSI) are becoming apparent, but basic strategies for transition from existing proprietary architectures to the new open ones are not as clear. Practical experience gained in developing such strategies suggests, however, that there is no single overall transition strategy but rather individual tactical solutions for several important problems. Solutions involve long-term coexistence of TCP/IP and OSI architectures and possibly a gradual merging of technologies from both architectures.

Introduction This article examines transition strategies from several viewpoints, including the short- and long-term role of open networking protocols in user environments, potential interfaces between proprietary and open networking environments, and differences between and complementary features of open network architectures. Different transition strategies are appropriate for data-level interoperability and for cooperation between host- and workstation-resident applications. Cabling and intelligent transmission networks are also outside the scope of this article.

Architectural Concepts Key ideas in understanding transition strategies include the basic configurations of networking components, the several differing roles of open networking standards, and the major architectures available. If two applications can effectively exchange data over physical media such as disks and tapes, interoperability between the two is at the data level—the level of interchange formats. Examples of interchange formats in wide use include Electronic Document Interchange and Electronic Funds Transfer. Interworking defines a model in which two (or more) applications interact. This interaction may be limited to providing feedback on exceptional conditions. There are three basic models of interworking: ·

The messaging model.

·

The interactive or peer-to-peer model.

·

The request-response model. The messaging model is close to the interchange format model but permits some level of exceptional-condition handling. For example, a messaging application supporting electronic mail knows where to send a notification that a message could not be delivered but does not routinely notify the sender that messages were received. The interactive model is implemented in basic timesharing, as well as in such more sophisticated computer-to-computer models as the TCP/IP protocol suite or Open Systems Interconnection. Conceptually, either participant in the interaction can send at any time, independent of the state of communications in the other direction.

Previous screen

In the request-response model, there is a definite hierarchy among the participants in the interaction: those participants whose role is responder never initiate communications but only respond to requests from other participants. The request-response model is the basis of multipoint polling (e.g., System Network Architecture 3270 multidrop),as well as the model used for client/server computing. At a basic level, networks can be broken into end systems (e.g., hosts and terminal equipment) and intermediate systems (e.g., routers and front-end processors). True user applications run on end systems; people interface either to terminal equipment or to displays integrated into end systems. Intermediate systems are concerned with transmission, not applications. Backbones are built from intermediate systems and the physical transmission facilities that interconnect them and furnish end systems with access to the backbone. Backbones can be single-protocol or multiprotocol; the general trend is for them to be multiprotocol.

Transition Models There is no single correct or most expeditious transition path, but managers can fill their toolboxes with several basic mechanisms. In moving to open systems, the ideal is creation: building a self-consistent open system without immediate concern for integrating it with other systems. A special case of creation is exchange, whereby the old system function can be replaced by a new one transparently providing the same services. Coexistence strategies are much more mundane. In a coexistence strategy, new and old implementations do not directly cooperate but do not interfere with one another in the context they share. This context could be a host, a common network, or a programming interface. The conversion strategy is an intuitive approach to transition between old and new: insertion of a black box between the open and the closed environment. Such a black converter box makes one technology appear to be the native technology seen on the other side. Convergence is a special case of conversion in which changes are made in both old and new so they naturally resemble one another. For example, a common transport-service interface such as the X/Open Transport Interface (XTI), which can run over both Open Systems Interconnection and TCP/IP's lower layers, can help converge upper layers to a common definition of the transport service.

Protocol Transition Strategies for interfacing protocols to a backbone are defined by the design of the backbone network—for example, whether it is a single or multiple protocol architecture. If the new protocol is different from the native protocols of a single network architecture, or if it is one not included in the supported multiple architectures, a decision has to be made as to whether transition is the responsibility of the backbone user or the backbone provider. Exhibit 1 illustrates the relative positions of different conversion techniques.

Previous screen

Transition Strategies Previous screen

Networking Standards In practice, there are several types of open networking standards, each with a legitimate role. They may be grouped into upper-layer functions that provide services meaningful to applications and lower-layer functions more concerned with the movement of bits and bytes. Upper-layer functions can be further divided into data and process levels. The data level is represented by interchange formats; the process level can have global or local functions, as follows: ·

Global functions emphasize flexibility in interconnecting networks under different system administrators and control policies. The major examples of these are the TCP/IP and Open Systems Interconnection protocol suites.

·

Local (also known as cell) functions emphasize performance in a well-defined management domain. Examples include the Open Software Foundation(OSF) Distributed Computing Environment (DCE),and the Manufacturing Automation Protocol (MAP)User Group Enhanced Performance Architecture (EPA).

At the lower layers , functions can be divided into those concerned with intelligent networks and those concerned with transmission networks. As with the upper layers, they can be optimized globally or locally. ·

Internetworking functions are global, dealing with the movement of bytes and datagram among potentially autonomous intelligent networks.

·

Transmission functions are local, involving the actual movement of bits and bytes in physical facilities. These include the IEEE 802 LAN and X.25, Integrated Services Digital Network, and digital transmission standards.

Interworking Transition Interworking strategies differ depending on their application to interchange formats or to true upper-layer protocols. Interchange format interworking is usually accommodated with off-line conversion utilities. For true upper-layer protocols, coexistence strategies are more common. One simple example of upper-layer coexistence is exemplified by what the US Department of Defense (DoD) transition strategy calls dual host (illustrated in Exhibit 2). In the dual-host approach, a user logs on to one protocol stack, logs off, and then uses another. The two stacks do not interfere and do not otherwise cooperate. For example, there is no need for interaction among a real-time data acquisition application using proprietary protocols and an Message Handling Service electronic application, when the only relationship between the two is that they share a time-sharing host. Application gateways (a mail gateway is shown in Exhibit 3) are popular for interactive and messaging services; through the DoD, gateways above the application layer have been implemented for Message Handling Service and File-Transfer Access Management service.

Previous screen

Previous screen

Dual-Host Transition Previous screen

An Application Gateway for Electronic Mail Certain conversion strategies cause underlying protocols to merge. When RFC 974 defined a mapping between TCP/IP and Open Systems Interconnection messagi ng formats, it became apparent that some MHS functions were not defined in the TCP/IP. This triggered the development of new TCP/IP headers to give TCP/IP those OSI capabilities.

Generalized Services Most useful protocol stacks are defined by a functional standard (e.g.,for file transfer, access, and management; for MHS; for teletex; for manufacturing messaging services; for office document architecture; and for virtual terminal protocol). International standardized profiles (ISP) constrain the options and parameter values appropriate to a stack of protocols and define a mix-and-match method for operating application substacks (e.g., X.400 and its associated session and presentation services), that connect, through transport services, to a variety of WAN and LAN substacks (i.e., layers 1 to 3). The profiles describe protocols for interchange (F-profiles), upper-layer services (A- and B-profiles), transport service (Tand U-profiles), and subnetwork transmission technologies. Other profile types describe relays rather than end systems. Exhibit 4 illustrates the types of interconnection needed to provide communication at the various layers.

Profile Levels and Conversion Needs ISP use allows anticipatory creation—that is, the introduction of some OSI solutions— with the confidence that future OSI applications will be compatible with the existing environment. If, for example, a user first ventures into OSI with an Information Strategic Planning-compliant version of X.400 MHS for communications over X.25, that user could be confident that MHS would continue to work if an International Standards Organization 8802.3 LAN substack is added. Further, that user could have confidence that a future virtual terminal protocol applications substack would not interfere with any existing upperor lower-layer substacks. Functional standards are not formally defined for the TCP/IP suite, but the mixand-match method remains useful for configuring systems. Individual RFCs define specific configurations of mixed Open Systems Interconnection and TCP/IP suites.

Mixed Stacks and End-To-End Services An end system must either be converted completely to the protocols that are used by the internetwork, or at a minimum be able to convert protocol elements seen by the backbone. Protocol conversion can be done by a separate converter, owned by the user, or within the end computing system. Mixed stacks (illustrated in Exhibit 5) combine protocol entities from more than one architecture (e.g., Open Systems Interconnection and TCP/IP),most commonly by mapping new upper-layer protocols (e.g., X.400)on top of an existing backbone (e.g., TCP/IP). One representative implementation is described by RFC 1006; this maps OSI protocols onto TCP/IP by mapping an OSI transport service interface onto a lower-layer TCP/IP substack.

Previous screen

Previous screen

Previous screen

Mixed Stacks Many vendors are using the mixed-stack approach to integrate OSI with their proprietary architectures, using various mixed stacks. For example, Digital Equipment's Digital Network Architecture, Phase V, uses OSI lower layers to support both OSI upper layers and Digital's proprietary applications services.

Special Issues in Local Optimization Network architectures balance (and may trade off) efficiency against general applicability. Much of OSI's complexity is attributable to its designers'intention that it function in many different computing environments. A less complex, more efficient approach is for the network manager to stress protocol and transmission medium consistency within the department or organization. The local system is then not necessarily open, but it is optimized for its purpose and can work with an open system for communications outside the department or organization. A technical approach that is not part of OSI's architecture but that is widely used is to employ the features of a local area network operating system(NOS) for open network coexistence. The major subcomponents of a network operating systems are services for file sharing, interactive support (e.g., terminal emulation), and device (e.g., printer) sharing. The unofficial industry standard for network operating systems is Novell's NetWare, but Banyan's VINES, Microsoft's LAN Manager and others have significant market share. The major open specification is the Distributed Computing Environment (DCE) of the Open Software Foundation. Another specialized but open specification is the Enhanced Performance Architecture (EPA) in the Manufacturing User Group specification for the Manufacturing Automation Protocol. The unofficial industry standard for file sharing is the Network File System (NFS), developed by Sun Microsystems and defined in Regional Financial Center 1094. NFS is based on a Remote Procedure Call interaction model.

Client/Server A client/server architecture requires an remote procedure call (RPC) mechanism. Many commercially available client/server applications—for example NFS—run over the RFC 1057 remote procedure call (RPC). Open Systems Interconnection upper-layer applications, (e.g., X.400 messaging and X.500Directory Services) run over a different remote procedure call (RPC) mechanism, the Remote Operations Service Element. TCP/IP's remote procedure call (RPC) can be mapped to remote operations service element (ROSE). Efforts are underway in international standards bodies to harmonize or merge remote procedure call (RPC) and Remote Operations Service Element.

Device Sharing NFS does not offer services for sharing devices such as printers. In the short term, a proprietary printer-sharing mechanism should be used. In the longer term, an open solution is emerging: the International Standards Organization distributed printing architecture, supported as part of the Operations Systems Functions Distributed Management Environment.

Directory Services Previous screen

The user interface to directory services generally is outside the scope of open sytems. It is implemented as part of an office automation package or as a network operating system utility. But excluding the user interface, there are two main open directory solutions: OSI X.500 and the Internet Domain Naming Service (DNS). X.500 appears to be the preferred method for new environments, and it is indeed supported in the Internet. Data Circuitterminating Equipment provides a cell directory service for the local environment and interfaces to both X.500 and DNS. Internally, the DCE directory services are built on X.500. Network managers should be aware that not all X.500 implementations automatically transfer complex X.400 addresses found in the directory to the header of the message for which the address was obtained. Human intervention, with possible typing errors, may be required to transfer this address. Such limited directory service functional capability is tolerable only as an interim solution.

Network Management Network management remains a challenging problem. There are two open architectures for network management, one from TCP/IP and one from OSI. The TCP/IP approach is the Simple Network Management Protocol (SNMP) and the OSI approach is the Common Management Information Protocol (CMIP). Associated with Common Management Information Protocol and SNMP are implementation-independent approaches for structuring management information, called the Management Information Base in OSI architecture and management information base (MIB)-II in TCP/IP. SNMP implementations are much more widely available than CMIP. They may transition to CMIP, using an interim architecture called CMIP over TCP/IP (CMOT). Whatever the management protocol and management information base (MIB) used, additional pieces are necessary to build a complete management solution. An interface to the human or automated operator is needed, as well as an interface to the real resources being managed. Operators access real management applications, such as user administration and alarm reporting, through operator interfaces. Management applications use management protocols to manipulate real resources in the managed systems.

Short-Term Tactics To create a local computing environment that will be suitable for any future open systems initiatives, a network manager should adhere to the following suggestions: ·

All new messaging gateways should connect the proprietary system to either X.400 (OSI) or Simple Mail Transfer Protocol (TCP/IP). If both X.400 and SMTP are needed, mapping functions should be defined in the network.

·

NFS should be the basic transparent file access mode; use of proprietary TFA protocols should be restricted to those that can interoperate with NFS. A transition to OSF DFS should be planned.

·

SQL should be used for data base service requests and a client/server paradigm followed to organize data base work, regardless of the underlying data base model.

Internetworking Transition Previous screen

The industry trend appears to be to build multiprotocol internetworking backbones—single transmission facilities that carry whatever protocols are necessary—and to connect these with backbones for application services, such as messaging. Open networking really means using new tools to perform the same operations that networks have been performing all along. Exhibit 6 shows how the lower-layer end system protocols for the TCP/IP environment are essentially identical to those specified by Open Systems Interconnection. Although there have been many comparisons of the layers in different architectures to suggest an unrealized level of compatibility, comparisons between the four layer groups is meaningful between OSI and TCP/IP.

Correspondence Between Lower-Layer Protocols in TCP/IP and OSI Before developing a transition strategy for any upper-layer protocol stack, it is essential to know whether those upper layers assume the existence of an intelligent subnetwork. Important industry protocols, such as Novell Internetwork Packet eXchange and Digital Equipment Corporation Local Area Transport, are optimized for a connected LAN environment. To optimize their local performance, these protocols do not include the overhead required to function in an internet.

Coexistence in Internetworks Coexistence between TCP/IP and Open Systems Interconnection is entirely practical, and they indeed may be converging on a common set of functions. One coexistence approach is using intelligent network elements, such as routers and packet switches, that recognize different protocols and respond to them in a manner appropriate to the protocol. This approach is implemented commercially for the network layer protocols of the TCP/IP and OSI:IP and ConnectionLess Network Protocol. On mixed networks, the protocols of different architectures coexist by entering the network as encapsulated Protocol Data Unit. They are placed in a capsule that is consistent with the backbone's native protocol, then traverse the backbone network, and on delivery to the destination network are converted into the protocol of that network. A backbone network can also function with a single internal protocol, with the network providing the gateways that show each supported user protocol the interface it expects. A special case of the gateway approach deals with nonroutable protocols, (e.g., Novell Internetwork Packet eXchange, Digital Equipment Corporation Local Area Transport). These protocols were not designed for movement through any network except the proprietary LANs for which they were created.

Subnetwork Convergence An understanding of Open Systems Interconnection network layer design concepts is useful is understanding transition issues. The network layers has three functions, not all of which need be present in a specific implementation: ·

The subnetwork-independent view presents an interface to the network layers that is consistent with the network layers architecture, whatever the architecture of the subnetwork.

Previous screen

· Previous screen

Subnetwork access provides the interface to a real-world subnetwork that need not be OSI.

·

Subnetwork-dependent convergence maps between the subnetwork independent and subnetwork-dependent views. Many vendors offer two types of X.25 interface: one runs the vendor's proprietary upper layer protocols over X.25, and another provides an X.25 interface to proprietary lower layers (Exhibit 7).

Two Strategies for X.25 Interfacing X.25 preceded the introduction of OSI protocols, and X.25 networks have been operational for some time. For these reasons, most vendors can run their proprietary technologies above X.25. Many can also provide X.25 interfaces to backbone networks built from their proprietary technology. Emerging transmission technologies (e.g., Integrated Services Digital Network and frame relay) are often treated by vendors the same as X.25, with interfaces for their own proprietary protocols.

Protocol Conversion and Encapsulation An internetwork may use but a single internal protocol, and the internetwork provider may not provide conversion services. In such environments, the responsibility for internetwork compatibility passes to the end system's owner. Packet assemblers-disassemblers (PADs) for X.25 are a venerable example. PADs take data from non-X.25 terminals and packetize it (i.e., put it in X.25 packets) for transmission over the X.25 network. At the destination, a reverse Packet Assembler/Disassembler removes the X.25 encapsulation and leaves the data in the form of its original protocol. Encapsulation, as illustrated in the PAD example, is a viable method for moving locally optimized, nonroutable protocols across intelligent internetworks, as described previously in this chapter.

Short-Term Tactics Tactics for subnetwork conversion should in the short term require the following: ·

All routers should be capable of handling ConnectionLess Network Protocol (OSI) and IP. An address space capacity planning effort should be undertaken.

·

Nonroutable protocols should be encapsulated for open-system transport Protocol Data Unit (over Transmission Control Protocol or Open Systems Interconnection).

Case Study The DoD has developed a transition strategy from TCP/IP to Open Systems Interconnection transport that is consistent wi th the OSI architecture (illustrated in Exhibit 8). All the components of the strategy are supported on currently available commercial products.

Previous screen

Previous screen

Department of Defense's TCP/IP to OSI Transition Strategies Previous screen

This strategy emphasizes a long period of protocol coexistence and does not include solutions for network-level and application-level interoperability problems. The approved methods are the dual-host method, use of application-layer gateways, and network relay. A dual host contains full OSI and TCP/IP protocol stacks, each stack having a separate network interface. The user selects one stack at a time. Application gateways service the application layer, but their operation is more automated than that of dual hosts. The mail gateway application between OSI's Message Handling Service and TCP/IP's Simple Mail Transfer Protocol is one of the application gateways. Mixed stacks, which contain TCP/IP and OSI protocols, are not used in the DoD transition plan. Their use was discouraged to avoid complexity in interoperation and conformance testing; it was feared that mixing stacks could lead to an explosion of combinations of protocol entities. In practice, however, only one mixed configuration is popular and gaining acceptance. The mixed-stack configuration described in RFC 1006 maps the OSI transport service on top of a reliable end-to-end connection provided by Transmission Control Protocol. The network relay solution is interesting both in its available implementations and as the forerunner of the possible merger between the network layer of OSI and TCP. Most commercial routers now support both IP and OSI's ConnectionLess Network Protocol. Because the Internet address space is becoming depleted, there is significant interest in running TCP and User Datagram Protocol (UDP)over ConnectionLess Network Protocol. One method of running an Internet transport is called TUBA: TCP and UDP over bigger addresses. In TUBA, CLNP performs the functions of IP, but with larger Open Systems Interconnection addresses . Obviously, conversion mechanisms are needed between systems running CLNP and systems running IP. TUBA is not the only method under consideration for enlarging the depleting Internet address space, and users should check the most recent Internet recommendations before selecting a strategy.

Conclusion There is no one best way to move into standards-based open networking. Users can move from proprietary protocols to Open Systems Interconnection or TCP/IP protocols, or as is becoming much more likely, to a hybrid of these two architectures. Experience with implementations and delays in solving some problems of standardization have resulted in a series of practical steps for evolution to open networking.

Author Biographies Howard C. Berkowitz Howard C. Berkowitz is Manager of Open Systems Technology for PSC International, McLean VA. His experience includes serving as the first technical staff member at the Corporation for Open Systems, codeveloping national performance standards, developing advanced networking systems for many user organizations, and developing network management architecture for GTE Telenet. He is the author of numerous articles as well as of the networking chapter of H.M. Deitel's An Introduction to Operating Systems (Addison-Wesley, 1990) and is preparing books on general open systems and standardsbased networking. Berkowitz has been nominated as vice-chair of ANSI X3S35, the digital communications performance subcommittee.