Inside X.25: A Manager's Guide [1 ed.] 0076070077, 0070553270

Citation preview

Sherman K. Schlar

A Manager’s Guide

Digitized by the Internet Archive in 2018 with funding from Kahle/Austin Foundation

https://archive.org/details/insidex25manager0000schl

A Manager’s Guide

The Data Communications Book Series Basic Guide to Data Communications, Edition 2 Cases in Network Design Connectivity and Standards, Volume 3 Data Communications: A Comprehensive Approach, Edition II Data Communications: Beyond the Basics Data Network Design Strategies, Volume 4 Inside X.25 A Manager’s Guide Integrating Voice and Data, Volume 3 Linking Microcomputers The Local Area Network Handbook, Volume 3 Network Management and Maintenance, Volume 4 Networking Software Telecommunications and Data Communications Factbook

Sherman K. Schlar

A Manager's Guide

McGraw-Hill, Inc. 1221 Avenue of the Americas New York, NY 10020

ACKNOWLEDGMENTS To my children, Jared and Devra, for patiently awaiting an answer to the question, “How many pages are left?” I’d like to extend my warmest appreciation to three close associates and good friends: Dave Gladwin, for his suggestions (both technical and grammatical) and protocol expertise; Jeffrey Miller, for his inspiration, exuberance, and steadfast encouragement; and Michael Strieker, for his boundless energy and engineering savvy. Also special thanks to Bill Bieganek, Tom Carey, and John Derewonko, for their solid technical advice, good-natured support, and constructive criticism. Lastly, thanks to my editors Ray Sarch and Don Martin. Their professionalism and attention to detail have certainly made a vast difference in both the clarity and quality of the final product.

Copyright 1990 by McGraw-Hill, Inc. All rights reserved. Printed in the United States of America. Except as permitted under the United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a data base or retrieval system, without the prior written permission of the publisher.

Library of Congress Cataloging-in-Publication Data Schlar, Sherman K., 1953Inside X.25 : a manager’s guide / Sherman K. Schlar. p. cm. Includes bibliographical references (p. ). ISBN 0-07-607007-7 - ISBN 0-07-055327-0 1. Computer networks — Standards — United States. 2. Data transmission systems —Standards —United States. 3. Packet switching (Data transmission) —Standards —United States. I. Title. TK5105.5.S34 1990 004.6-dc20

90-5505 CIP

DEDICATION To my loving wife, Nancy, without whom this would never have been possible.

CONTENTS

FOREWORD

ix

INTRODUCTION

xi

1

Evolution of Data Networks

1

2

Data Communications Standards

12

3

The Open Systems Interconnection Reference Model

20

4

Both Sides of the Cloud

35

5

The X.25 Physical Layer

53

6

The X.25 Data Link Layer

61

7

The Network Layer

72

8

Related CCITT Standards

97

9

Facilities and Features of X.25

123

10

Packet Switched Public Data Networks

139

11

Private Packet Networks

163

12

Cost Saving Strategies Using Packet-Switched Networks

193

13

Packet-Network Case Studies

210

14

X.25 Host Interfaces & Other Gateways

220

15

Using PCs and Macintoshes on Packet-Switched Networks

237

16

The Promise of ISDN

251

17

New Directions in Packet-Switching Technology

263

APPENDICES

271

GLOSSARY

289

INDEX

293 vii

v r -

FOREWORD

Increasingly, well-tuned, flexible and cost-effective data networks are viewed as valuable strategic assets, offering competitive advantages not only to corporations but also to nations. So it is not surprising that, since subcommittee X.25 of the In¬ ternational Telegraph & Telephone Consultative Committee (CCITT) first pub¬ lished its recommendation for a packet-switched network interface in 1976, packet switching has evolved into a robust technology deployed in hundreds of public and private data-communications networks. What is surprising, especially in light of the anticipated spread of the technology over the next five years, is the dearth of information on how network planners and information managers can best apply this technology to meet the needs of businesses in today’s markets and, perhaps more importantly, tomorrow’s. Today, most industrialized nations offer at least one public data network based on packet-switching technology. In the U.S. alone, the market for packet networks topped the billion-dollar mark in 1987, and it is not going to recede; industry analysts predict 20 to 30 percent growth in the use of packet networks over the next five years, most of it in the private sector. (Some $360-million was spent on private packet networks in 1987.) Furthermore, recent federal court decisions will allow new and more competitive public data network offerings by the Regional Bell Operating Companies, while costs of analog leased lines are expected to rise dramatically, further increasing the appeal of packet networks. So this book is about how the X.25 standard can be lifted off the engineer’s bookshelf and successfully applied in solving the business problems common to many of today’s networks. The book is intended not for the software engineer or programmer faced with the challenge of deciphering the CCITT’s lexicon and de¬ veloping programs and products that adhere to the X.25 Recommendation. Rather, ix

X

FOREWORD

it is for the network planner and information-systems manager faced with intercon¬ necting dissimilar and incompatible mainframes and minicomputers across a corpo¬ rate network. For those readers, the book provides an historical perspective and introduction to the basics of packet switching, Open Systems Interconnection and the X.25 stand¬ ard, along with comprehensive and detailed assessments of packet technologies, equipment and networks of today and tomorrow. The emphasis throughout is less on theory than on such practical matters as selection of vendors and software. Ap¬ pendices are intended to reinforce this pragmatic approach and make this an indis¬ pensable handbook for data networkers of the 1990s.

INTRODUCTION

Thanks to increasing corporate and government demands, the benefits of using packet switching are even more significant today than when the X.25 Recommen¬ dation was first published. To prepare managers and network planners to reap those benefits, this book’s focus is on the practical considerations and implications of packet switching: How does X.25 work? What vendor products are offered? How do they function? How do all the pieces fit together? Chapter one traces the evolution of data networks from dedicated to shared resources. The fundamental concepts behind —as well as the fundamental strengths and weakness of—private line, circuit-switched, and packet-switched networks are discussed, and a brief history of packet networks is provided. The concept of a layered network architecture and the evolution of the Open Sys¬ tems Interconnection or OSI reference model are introduced in chapter two. Also covered are the processes of developing standards and the organizations, both U.S. and international, that play the major roles in those processes. Chapter three provides a general discussion of network architectures and the con¬ cept of layered architectures, as well as in-depth description of the OSI reference model, a functional description of that model’s layers, and a discussion of the aims and benefits of OSI. Leading contributors to the OSI model and the hierarchy of worldwide standards organizations also are covered. Chapter four introduces the CCITT’s X.25 Recommendation, its practical inter¬ pretation and its terminology. Chapter five covers the X.25 Physical Layer, its pur¬ pose and functions, mechanical and electrical specifications, supported standards and performance characteristics. Chapter six covers the Data Link Layer, its func¬ tional characteristics, frame format structure and elements, framing techniques, transparency, controls and error detection, as well as commands and single- and multilink procedures. Chapter seven covers the X.25 Network Layer, including XI

Xii

INTRODUCTION

functional characteristics, multiplexing, packet formats and types, and phases of operation. Chapter eight summarizes the CCITT standards most closely related to X.25, in¬ cluding international addressing conventions, packet assembly and disassembly standards, and those for dial-up service and packet-network gateways. Chapter nine covers standard and optional features available under X.25 and their practical applications. Also discussed are vendor-proprietary features and X.25 variations. Chapter 10 covers public data networks using X.25, their origins, charges, to¬ pologies, services and value-added features. Also covered are protocols, security, testing, accounting and billing, international networks and calling procedures and equipment vendor conformance testing and certification. Chapter 11 deals with private packet switched networks. Included is a discussion of their topologies and design considerations, as well as issues of network manage¬ ment, security, and accounting. Merger of public and private networks also is covered. Chapter 12 presents strategies for cutting costs. Included is a discussion of the public network tariff structure and how to use the public networks for what they do best. Choosing between buying your own or using public network hardware is cov¬ ered, as is the trade-off between in-house and outside network management. Other opportunities for cutting costs are covered, as are compression software and tuning for performance. Chapter 13 presents case studies of packet networking: on an engineering college campus; in an international multivendor environment; in a credit card authorization system; and in an asynchronous, dial-up link to IBM hosts through a value-added network. Chapter 14 covers other packet mode devices and strategies, including IBM and its Systems Network Architecture protocols, host-resident X.25 interfaces, gate¬ ways, integral X.25 modem support, and hybrid packet and nonpacket networks. As in the next chapter, criteria are included for evaluating equipment vendors as well as the software and hardware available in the marketplace today. Chapter 15 addresses the uses of PCs and Macintoshes on packet networks. Em¬ phasis on vendor and product evaluation continues in coverage of value-added net¬ work PC services, PC to VAN access methods, gateways between local-area and X.25 networks, and the Macintosh environment. Chapter 16 deals with Integrated Services Digital Networks and the integration of circuit and packet switching. Covered are analog voice transmission, digital voice transmission and networks, and ISDN and its providers. Chapter 17 concludes the main text with a look at the future of packet-switching technology, including T1 integration, high-speed packet networking, packetizing voice, and Frame Relay. The appendices catalog leading packet-network equipment vendors, reference sources and organizations, U.S. and international public network contacts, and the CCITT X.25 diagnostic and clearing codes.

CHAPTER

EVOLUTION OF DATA NETWORKS

As computers themselves have evolved from specialized machines, dedicated to performing only a handful of repetitive tasks, to fast, general-purpose processors able to handle hundreds of concurrent users, so too have computer networks evolved. Early computer networks, like the computers attached to them, were dedicated to performing limited numbers of tasks and to making connections in limited numbers of ways. Those networks were inflexible and static for good reasons. Before the ad¬ vent of microprocessors and inexpensive memory, it was prohibitively expensive to put intelligent functions, such as routing and switching, out into the network itself. Early networks were primarily mainframe-based, with on-line users inputting data to large, centralized databases. And network access for minicomputers was less im¬ portant then than today because early minicomputers were designed to be stand¬ alone processors. Also, the cost of computing power was high relative to the cost of communica¬ tions. So purchasing dedicated circuits to connect users to a large mainframe was cheaper than buying even a small departmental computer. Thus, what little peripheral equipment was attached to the early computers was within a few feet of the central processor and hard-wired to some specific function, such as punch-card input. Over time, however, the cables connecting these devices were extended, first across the data center floor to another corner of the room, and later to other rooms and floors in the same building. Though these early wiring schemes would be considered primitive by today's standards, they soon brought engineers to the realization that the binary digital data used by computers could be modulated with analog waveforms, transported across great distances through the public analog telephone network, then demodulated for 1

2

INSIDE X.25: A MANAGER’S GUIDE

further digital processing. Since then, the computer network has undergone a fun¬ damental evolutionary change, from a dedicated to a shared resource.

Network topologies As shared resources, modern wide-area networks must meet diverse objectives of numerous users at acceptable costs. In making the trade-offs that diversity entails, network topology is a fundamental consideration. Network topologies fall broadly into three categories: private line, circuit switched, and message switched, though any network may selectively employ a combination of these topologies to meet a particular business or technical requirement. Early networks employing private, leased-line connections from terminal to host equipment represent a prime example of dedicated transmission facilities. Each physical device attached to the network required its own separate leased line to connect to the host. In the message-switched, or store-and-forward, network data is transmitted in blocks. Each block of data is stored by the first downstream switching node it en¬ counters, then forwarded shortly thereafter to the next downstream node, and so on until it reaches its destination. Message switching places no restrictions on block size. Packet switching, on the other hand, is actually a subset of message switching, but with well-defined limits to the maximum size of a block. By limiting block sizes to 128 or 256 bytes, this approach reduces node buffering, or storage, requirements as well as the delay at each node. Packet switching is especially well suited to interactive traffic, because no single user or large block can indefinitely tie up nodal or transmission-line resources. But each topology has its advantages and disadvantages.

Private-line networks Early private networks had a number of desirable characteristics: Data-grade leased-line circuits were specially ordered and did not take the same path through the central office switching equipment used by “normal” voice lines. Because the facilities were fixed (dedicated to one user), their electrical transmission charac¬ teristics showed less variation over time. Accessibility was generally high because devices could transmit and receive data immediately, that is, without the call setup delay inherent in a dial-up connection. And the performance of these lines was relatively good for their era, limited perhaps more by modem (modulator/demodu¬ lator) technology and by primitive modulation techniques than by actual line characteristics. A modern network based on private lines offers several other advantages that might not be obvious. One is that the amount of available bandwidth on a private line is known and fixed in advance. Bandwidth, or the range of frequencies a line

CHAPTER 1: EVOLUTION OF DATA NETWORKS

3

will carry without unacceptable attenuation, determines the rate at which data can move on the circuit. Another is tightened network security; hackers can’t use public lines to gain access. Another important characteristic of private line is that it provides transparency to the data stream being sent over it. To a private line with a modem attached at each end, the protocol under which data is transmitted doesn’t matter. In simplest terms, a private line is a pipe that may be purchased in various lengths and sizes. In terms of a layered network architecture, a concept we’ll treat in some detail in chapter three, the line operates at the lowest physical level, pro¬ viding a “bit pipe” for data. If the communications protocol used with this bit pipe calls for simple, unsophis¬ ticated asynchronous (or stop-start) transmission, uncorrected errors and garbled data may well occur. Private lines have other disadvantages as well, although in the early stages of teleprocessing, these disadvantages were not as significant as they are today. The fixed bandwidth, for example, is a two-edged sword. The speed of a private line is limited by the speed of the modems used. Any unused bandwidth on this circuit is not available to another user somewhere else on the network. Multiplexing may split up the circuit’s total bandwidth into narrow bands but cannot alter it. Furthermore, in a point-to-point leased-line connection, network re¬ routing is impossible. Between the two end points over a private-line network, user 1 must always be connected to user 2, as illustrated in Figure 1.1. If user 1 has a new requirement to communicate with user 3, user 1 is simply out of luck. One solution is to run a new line to another terminal on user l’s desk out to user 3. But as the number of computers and their applications increase, this solu¬ tion becomes wildly impractical. This lack of alternate routing capabilities has serious consequences during line failures. Although private-line failures are infrequent, in such critical applications as, for example, electronic funds transfer, a four-hour outage during peak banking hours may be disastrous. Backup is required for such applications. What is perhaps the major constraint upon use of private lines in data networks stems from the fact that, as the cost of computing power has steadily decreased, the relative cost of transmission facilities has risen. With a private line, the user pays the line charges each month, regardless of how much or how little the line was ac¬ tually used. So the user must pay for the network resources that are always in place, whether they are used or not. During idle times the resources — and the money —are simply wasted. For continuous high-volume, high-speed data trans-

FIGURE 1.1

Private Line Channel A always dedicated to Channel B

User A

MULTIPLEXER

MULTIPLEXER

User B

4

INSIDE X.25: A MANAGER’S GUIDE

FIGURE 1.2

Circuit Switching Relationship Between Number of Connections and Devices

DEVICE 2

DEVICE 1

DEVICE 2

Number of Connections = N (N-1) 2

fers, these charges are rarely a problem. But for less frequent usage, a leased line can be costly indeed.

Circuit switched-networks For less frequent usage, circuit switching shares telephone network resources among many users, thus distributing costs. Circuit switching is normal telephone operation. Connections are made upon users’ requests, and any link so established

CHAPTER 1: EVOLUTION OF DATA NETWORKS

5

operates as a dedicated circuit for the duration of the call (see Figure 1.3). Rather than a fixed monthly charge, the user is here billed for the connect time at a rate determined by distance. (A connection on the switched telephone network is called a dial-up connection.) While dial-up connections free users from high monthly line charges, they re¬ quire that users pay close attention to call timing. A telephone call across the switched network, whether for voice or data, goes through a series of well-defined time phases. These phases are call setup (establishment), information or data trans¬ fer (conversation), and disconnect (see Figure 1.4). Call-setup time is that required to establish communications between the two users. If a call lasts for 20 minutes, 10 seconds may be acceptable for call setup. For a transaction-oriented credit-card authorization, 10 or 15 seconds may be the goal for the entire transaction, not just call setup. The useful portion of the call occurs during the data-transfer, or conversation phase. This phase may be as brief as 10 seconds or as long as several hours. The average connection time during the data transfer phase of a data call in the U.S. is less than one minute. Voice calls last considerably longer, with five minutes as U.S. average. The disconnect phase extends from termination of the call by either party until the circuit is released and able to handle a new call. When the calling device is “hung up” and its modem goes “on-hook,” the disconnect signal must propagate across any number of hops (network segments between nodes) to the remote end. When measured against an average connection time of less than a minute, even a two-second disconnect phase is significant. Most of the disadvantages of using the switched telephone network for data com¬ munications stem from the fact that the phone network is optimized for voice com¬ munications. The human voice ranges in frequency between 300 and 3,000 hertz. Thus, low-bandwidth copper wire is adequate for the transmission of intelligible voice. It considerably limits the bandwidth (or pipe diameter) available for data, however. The maximum usable data rate attainable with a dial-up line is generally lower than that with a private line. Whereas a conditioned analog private line can run as high as 19.2 thousand bits of information per second (kbit/s), most dial-up modems are limited to 9.6 kbit/s or lower. (For comparison, digital private lines using cop-

FIGURE 1.3

Circuit-Switched Connection

6

INSIDE X.25: A MANAGER’S GUIDE

FIGURE 1.4

Telephone Call Phases

Caller

Telephone Network

Receiver

per wires or high-bandwidth optical fibers run at speeds of 56 kbit/s or even 1.544 megabits per second (Mbit/s).) Because circuit-switched connections pass through more switching equipment over lower-quality lines than private-line connections, the quality of the circuitswitched line may vary more than an equivalent private line. Noise and echo, in¬ herent in telephone-switching equipment, may introduce higher levels of bit errors. As with voice transmission, the quality of the service may also degrade over greater distances. If the trunk circuits that interconnect primary telephone-switching cen¬ ters are busy, “blocking" may temporarily prevent connections. There are other disadvantages to circuit switching. For computers with dial-in ports, special security precautions must be taken. The switched network does not screen calls for the destination host computer. Programs are available from some telephone companies that will allow hosts to identify callers, and even to return calls before completing connections, thus confirming the callers’ identities. But these screening programs, of course, add to the costs of circuit-switched calls.

CHAPTER 1: EVOLUTION OF DATA NETWORKS

7

With all of these costly limitations, circuit switching alone is rarely adequate as the basis or backbone of large, high-usage networks. Higher-level protocols, which provide additional capabilities such as routing, error correction, and flow control, are essential network components. It was an effort to distribute these components throughout a network that prompted development of packet switching.

Packet-switched networks In the early 1960s, Paul Baran of the Rand Corporation published an 11-volume re¬ port “On Distributed Communications” and introduced the concept of packetswitched communications. The Rand Corporation had been commissioned by the U.S. Air Force to study requirements for a secure and fault-tolerant military com¬ munications network for both voice and data. The Air Force’s primary objective was to devise a distributed network that would be immune to central-component failures while providing enhanced levels of data integrity and security. Baran’s proposal took advantage of the facts that voice transmission is in¬ terspersed with spaces and pauses (see Figure 1.4), and that these pauses could separate the audible content of voice into packets. Baran’s concept was simple. Each packet could be given a destination address and sequence number, sent out into the network across diverse paths or routes, and reassembled into the original sequence by the destination node. Should one route or node be disrupted, each node would have enough buffering and intelligence to dynamically reroute packets along a new route, without loss of data. The throughput of this packet-switched network was dramatically higher than that of a message-switched approach. Each nodal switch treated incoming packets like a proverbial “hot potato.” The first packet of a long, multipacket message could be alreadv “out the door” before the next one would arrive. Another benefit of this approach was greatly improved security, a concern of prime importance to the military. Tapping into any single path would reveal only a small portion of the original data stream, making decryption of an entire encrypted message extremely difficult (see Figure 1.5). At about the same time as Baran’s report, the Defense Department’s Advanced Research Projects Agency (ARPA) began its own research into the feasibility of packet switching pursuant to developing a wide-area network for the department. Much of the work on what was to later become the Arpanet was done by a group of visionary researchers at MIT. By 1967, ARPA published its design plans, which outlined a packet network using minicomputers as packet switches at each nodal site. These minicomputers, which were to be interconnected by leased lines, would present a standardized interface into the network. In Arpanet terminology, these packet switches were called interface message processors, or IMPs. About a year later, ARPA requested bids for supplying packet-switching and net¬ work-management equipment. Bolt, Beranek, and Newman (BBN) of Cambridge, Massachusetts was awarded the contract for the development, manufacture, and in¬ ternal operation of the network. Arpanet is still used by the military and its related

8

INSIDE X.25: A MANAGER’S GUIDE

FIGURE 1.5

Packet Switched Voice

research community, and has grown from the four original network nodes to more than 100. Another experimental packet network was developed at about the same time by England’s National Physical Laboratory. It was there that the term “packet” was first used —by Donald Davies of the NPL to describe the 128-byte blocks sent across the network. Each of the early experimental packet networks took its own approach to net¬ work interface protocols. This was to later become a strong argument for the accep¬ tance of the CCITT X.25 standard as a basic interface to a public packet network. The rapid progress and performance improvements demonstrated by these early packet networks was not lost upon the commercial computer and telecommunica¬ tions manufacturers. IBM, for example, announced in 1974 its long-awaited “Sys¬ tems Network Architecture” (SNA), which incorporated many of principles of packet switching into the lower layers of its architectural model. Unlike the decen¬ tralized Arpanet, however, SNA was hierarchical in structure, with all network connections managed by a central processor. The first commercial public packet networks began to appear in the U.S. in the early 1970s. Tymshare, later to become the McDonnell Douglas Tymnet network, employed a centralized routing policy under the control of a network supervisory computer. This computer maintained a map of the global network topology and net¬ work routing delays in its database. Multiple supervisory computers were provided for fault tolerance, although only one supervisor was active at a time. Initially, Tymnet was designed to support low-speed asynchronous terminals via

CHAPTER 1: EVOLUTION OF DATA NETWORKS

9

dial-in connections to nodes located in major metropolitan areas. Later, support was extended to X.25 and synchronous terminal interfaces. (In asynchronous, or stop-start, transmission, data is sent character-by-character. In a typical code, for example, the basic unit of data transmission contains: a start bit; seven information bits representing a character; a parity bit inserted or omitted to make the total number of bits per character odd or even, as desired; and one or two stop bits. A parity check is the only error control in async operations. In synchronous transmission, on the other hand, characters are grouped in blocks, and a variety of error-checking techniques, such as appending a check character to each block, is available. A combination of the two techniques, the XModem pro¬ tocol, is used to transmit blocks of asynchronous data.) Tymnet employed a routing technique based on “virtual circuits,” whereby a fixed path through the network was defined at the beginning of each session or call, and the path through the network remained unchanged for the duration of the con¬ nection. The concept of a virtual circuit was destined to become an integral part of the X.25 standard. Begun in 1974, the Telenet Public Data Network started out as an enhanced ver¬ sion of Arpanet. Telenet adopted yet another approach to the issue of network rout¬ ing, employing a combination of distributed (as in Arpanet) and centralized (as in SNA) techniques. The distributed or isolated approach offered the advantages of a rapid response to nodal congestion and the ability to recover from a nodal failure. Centralized network management promised overall network efficiency and flow control, but at the cost of higher overhead and vulnerability. Telenet chose to let individual nodes handle routing decisions, but observed and modified these local routing decisions from a control center.

Packet-switching concepts Using a packet network in many ways parallels using the switched telephone net¬ work to make a conventional call. Even similar terminology is used. As on its circuit-switched counterpart, establishing a call on a packet network entails a number of steps or phases (see Figure 1.6). To place a phone call, the caller must dial the telephone number of the called party; the telephone number dialed is the equivalent of the destination’s address in a packet network. To begin the call-establishment phase on a packet network, the caller on an in¬ teractive terminal typically enters a command like CON (for CONnect), followed by the numeric network address of the destination. When the caller hits his carriage return or enter key, a specially formatted “call-request” packet is generated and sent across the network. This packet contains, among other things, the network ad¬ dress of both the source and destination. If the destination host computer accepts the call, it returns a “call-connected” packet. Again, as in a telephone call, the destination party or host computer may decide to reject this call and hang up. If the call request is acceptable to the host, the originator gets back a “call-connected” packet, signaling that an end-to-end

10

INSIDE X.25: A MANAGER’S GUIDE

FIGURE 1.6

Packet-Switched Network Call Phases

Source

Packet-Switched

Destination

“switched virtual circuit” (SVC) has been established for the duration of the call. To both the terminal and host, this virtual circuit has all the appearances of an actual circuit-switched connection. Because packets may travel any routes in the network, however, call-establishment time is lower. While a circuit-switched net¬ work may typically take up to 10 seconds to establish a connection, on a packetswitched network this phase may be measured in tenths of a second. Even interna¬ tional connections can be established in as little as two seconds. Once the connection is made, the second major phase of the call begins: the data transfer. This phase consists of common session activities. These may include in¬ quiries, updates to databases, electronic-mail transfers, or even bulk-data transfers. The network, with its established virtual circuit, is now concerned with the rapid and error-free delivery of the data. During the data-transfer phase, the network’s main task is to figuratively “get out of the way” and provide a transparent path be¬ tween the two end points. The major network operations in this phase include packet sequencing at the des¬ tination, flow control, and signaling. Sequence numbers assigned to each packet when the data stream is first packetized are used to order data streams in both direc¬ tions. Flow control is a matter of ensuring network-input data rates match delivery

CHAPTER 1: EVOLUTION OF DATA NETWORKS

11

rates. And signaling is used to notify either the source or destination of some un¬ usual network event. Examples of signaling may be the resetting of an individual virtual circuit or, less frequently, the restart of an entire link. The last phase of a packet call is call clearing or disconnection. A call may be cleared by either the source or destination, just as either party on a telephone call may hang up the receiver. A unique packet is used to notify the opposite end and the network that the call is to be cleared and the switched virtual circuit released. Packet switching differs from circuit switching in some critical areas. Using a form of statistical multiplexing or interleaving, for example, many switched virtual circuits can be active on a single physical link (see Figure 1.7). As does statistical multiplexing, this represents an efficient use of a line’s available bandwidth. Ex¬ tending this concept beyond the statistical multiplexer, each terminal in a group of terminals sharing the same physical link may be connected to a completely differ¬ ent destination. With the equivalent of a minicomputer serving as each packet-switching node, packet-network designers and manufacturers found that they had ample processing power available to incorporate additional functionality into their basic products. The resulting features have emerged over time into an array of services that support an extremely wide variety of terminal and host protocols. Standardization of the packet-network interface, meanwhile, has relieved designers of the responsibility for inventing their own network interfaces. The absence of these proprietary net¬ work interfaces has broadened the appeal and usefulness of public packet networks. The next several chapters will explore how the X.25 interface became a univer¬ sally accepted standard and will explain how this interface functions. FIGURE 1.7

Virtual-Circuit Multiplexing

Virtual Circuits

CHAPTER

DATA COMMUNICATIONS STANDARDS

Standards affect our daily lives in countless unseen ways. Many of the com¬ monplace products and services we use quite routinely owe their success and longevity to their conformance to standards. Telephone service is an example. Standards for services and access procedures allow us to make international calls as easily as local ones. Conformance to line- and transmission-quality standards, and with stringent standards for telephone-company equipment, ensures high reliability of service and, generally, high quality of sound. Other industries also depend heavily on standards. Yet until the 1970s, the datacommunications industry had largely lagged other industries in adopting standards. Till then, in a market where the ground rules were handed down by computer giants like IBM, Sperry Univac, the Digital Equipment Corporation (DEC) and Bur¬ roughs, the data-communications industry was geared to provide connectivity within single-vendor installations, nothing more. Under those ground rules, each primary computer vendor developed its own set of proprietary protocols governing such higher-level network functions as interac¬ tive sessions, file transfers, and remote job entries. Through the 1950s, under those ground rules, the making of standards for data communications was a contest for market share; in time that contest produced a few winners, a few proprietary protocols that gained such widespread acceptance that they became de facto or marketplace standards. Developed in the early 1960s and still in widespread use, IBM’s binary synchronous protocol for data transfer is a good example of how pervasive, and entrenched a de facto standard can become. DEC’S VT-100 terminal protocol is another. Despite these de facto standards — which stood as strong barriers to the entry of new firms and products to their markets —the number and variety of computer 12

CHAPTER 2: DATA COMMUNICATIONS STANDARDS

13

manufacturers grew, and with them the number of incompatible network-control protocols. Differences arose in a variety of areas as diverse as character codes and data-link-control protocols. As a result, the strategy of adopting or emulating de facto standards did not work for all networks. For example, the emerging minicom¬ puter networks needed a “flatter” architecture, lacking the centralization and resources found in a mainframe-based hierarchical network. As the development of the “information society” continued to accelerate into the 1970s, a clamor for development of universally supported, multivendor, networkinterface protocols was heard from users in government, academia and commerce worldwide. This pressure prompted national and international standards organiza¬ tions to began looking at ways to develop a unified response to the need for com¬ mon standards. The requirement was simple: Do for data what the public switched telephone network did for voice. Meeting that requirement would not be simple, since it would entail development of de jure standards, each representing a consen¬ sus achieved by all interested parties. Among the results of the effort that followed was the publication in 1976 by the International Telegraph & Telephone Consultative Committee (CCITT) of its Recommendation X.25 for a packet-switched network interface. Because that recom¬ mendation and the standards and technology that flow from it continue to evolve (The recommendation has been amended three times, most recently in 1988.), a detailed look at the CCITT and related standards organizations is necessary.

International standards organizations With input from a variety of sources, the CCITT, headquartered in Geneva, took the lead responsibility in developing standards for data networks in 1972 when it formed Study Group VII to pursue and develop standards for the newly emerging public data networks. The CCITT operates on four-year cycles or study periods, and issues new stan¬ dards in the form of “recommendations” at a plenary assembly at the end of each study period. Study Group VII first issued its “Recommendation X.25” covering packet-switched networks in 1976, with amendments following in 1980, 1984, and 1988. It isn’t necessary to wait for a plenary, however; timely or pressing standards may bypass the normal cycle and be published as provisional recommendations be¬ tween assemblies.. CCITT recommendations are developed in technical Study Groups, currently numbering 17. Each Study Group is tasked with a specific aspect of telecommuni¬ cations. The current Study Groups and their responsibilities are listed in Table 2.1. The CCITT reports to the International Telecommunications Union, a United Nations treaty organization formed in 1865. The ITU consists of 161 participating member nations and is responsible for the planning and standardizing of all forms of international telecommunications, including radio, telephony, and telegraphy (interpreted in the broader sense to include data communications). The purposes of the ITU as defined in its “Convention” are: to maintain and ex-

14

INSIDE X.25: A MANAGER’S GUIDE

TABLE 2.1

I. II. III. IV. V. VI. VII. VIII. IX. X. XI. XII. XIV. XV. XVI. XVII. XVIII.

CCITT Study Groups

Telegraph operation and quality of service Telephone operation and quality of service General tariff principles Transmission maintenance of international lines, circuits, and chains of circuits; maintenance of automatic and semiautomatic networks Protection against dangers and disturbances of electromagnetic origin Protection and specification of cable sheaths and poles Data communications networks Telegraph and terminal equipment (telematic services) Telegraph transmission quality Telegraph switching Telegraph switching and signaling Telephone transmission performance and local area networks Facsimile telegraph transmission and equipment Transmission systems Telephone circuits Data transmission Digital networks

tend international cooperation for the improvement and rational use of telecom¬ munications; to promote the development of technical facilities and their most efficient operation with a view to improving the efficiency of telecommunications services, increasing their usefulness, and making them, so far as possible, gener¬ ally available to the public; and to harmonize the actions of nations in the attain¬ ment of those common ends. CCITT recommendations are often the results of collaborative efforts with other international standards organizations (see Figure 2.1). Where relevant, transferable standards from other bodies already exist, the CCITT may incorporate portions or all of these standards into its own recommendations, as in the case of X.25. For example, the first drafts of the International Organization for Standardization’s (ISO’s) high-level data-link-control protocol appeared in 1974. Shortly thereafter, the protocol was adopted, largely intact, by the CCITT as its own “link-access pro¬ cedure” (LAP). On top of existing physical layer specifications and the newly bor¬ rowed LAP protocol, the CCITT then added another layer: its own level three or packet-level protocol. Collectively, the specifications for these three layers evolved into CCITT Recommendation X.25. Also active members of the CCITT are Recognized Private Operating Agencies. These nongovernmental public-network service providers are found in those coun¬ tries whose telecommunications infrastructures have been deregulated. Examples include AT&T, ITT, and GTE in the U.S., and British Telecom in the UK. Simi¬ larly, to influence the development of standards as well as to improve their own technical expertise, private companies may participate in the CCITT as Scientific and Industrial Organizations. Notable SIOs include IBM and Omnicom. Another contributor to development of standards is the Conference of European Postal and Telecommunications Administrations (CEPT). Chartered to facilitate

CHAPTER 2: DATA COMMUNICATIONS STANDARDS

FIGURE 2.1

15

U.S. & International Standards Organization

cooperation among its 26 national Postal Telegraph and Telephone Administrations (PTTs), CEPT has undertaken on behalf of the European Economic Community the formidable task of harmonizing existing technical standards in telecommunica¬ tions, particularly with respect to terminals and other equipment connected to pub¬ lic networks. It has been most prominent recently in developing standards for the Integrated Services Digital Network (ISDN). Another prominent player is the European Computer Manufacturers Association. Formed in 1961 and comprised of major European computer manufacturers such as Honeywell Bull, IBM of Europe, and International Computers Ltd., the ECMA is

16

INSIDE X.25: A MANAGER’S GUIDE

a member of the CCITT, and an observer member of and active contributor to the International Organization for Standardization (ISO). The ISO is one of the world’s pre-eminent standards agencies. It was founded in 1946 as a voluntary treaty organization, and now includes some 2,000 technical committees, subcommittees, and working groups involved in a broad range of ac¬ tivities. Members include the national standards organizations of more than 90 countries. (The U.S. representative is the American National Standards Institute.) Like the CCITT, the ISO is headquartered in Geneva and draws heavily from the European Community for its leadership. Unlike the CCITT, the ISO does not produce its recommendations on a four-year cycle, but uses a more open-ended and dynamic process. The typical sequence is from working draft to draft proposal to draft international standard and finally to balloting for adoption as an international standard; that process may take as little as eighteen months, although typically it takes longer. In 1977, the ISO began to establish a set of standards to improve the compatibil¬ ity of communications products from different vendors. This set of standards has evolved into a universal network architecture, the Open Systems Interconnection or OSI Reference Model. The model was approved by the ISO in 1984 under the designation of ISO 7498. Four years later, the CCITT adopted this same document as its X.200 Recommendation. The OSI Reference Model and its relationship to X.25 will be explored in chapter three.

United States standards organizations The American National Standards Institute participates in an uncommonly large variety of standards activities. Although not strictly a standards developer, ANSI plays a crucial role in the coordination and approval process of voluntary American national standards. ANSI has approved domestic standards in such diverse areas as the Cobol and Fortran programming languages, safety glass, screw-thread dimen¬ sions, and bicycle helmets. Internationally, ANSI serves as the sole U.S. represen¬ tative to the ISO. Membership in ANSI consists of over 250 standards organizations, professional societies and government agencies, and more than 1,000 private companies. In the arena of information systems, ANSI’s work is under the domain of its Standards Committee X3, established in 1960 to study all computer-related stand¬ ards. Following the break-up of AT&T in 1983, a new Accredited Standards Com¬ mittee, entitled simply ASC Tl, was formed to set standards for the telecommuni¬ cations industry. Issues related to domestic telephone carriers represent the bulk of Tl activities. ISDN architecture, services, and switching and signaling protocols have been among Tl’s more recent endeavors. Other significant ANSI committees are ASC X12, which deals with business and electronic data interchange (EDI), and X3.139, which promulgated the Fiber Dis¬ tributed Data Interface (FDDI) specification for a high-speed (100-Mbit/s) token¬ ring LAN.

CHAPTER 2: DATA COMMUNICATIONS STANDARDS

17

Among the prominent contributors to U.S. standards development is the Elec¬ tronic Industries Association, a national trade association founded in 1924 as the Radio Manufacturers Association. Its 4,000+ industry and government members participate on behalf of a broad range of constituents, including semiconductor manufacturers and large-scale network integrators. Oriented toward electronic hardware, the EIA has been active for over 20 years in data-transmission standards; perhaps its best known and most enduring is its RS-232 physical interface standard. EIA has been a contributor to the OSI Reference Model and —at this writing —is working toward a universal computer-to-modem interface that can function as a computer-to-ISDN interface when ISDN arrives. The EIA is also a major U.S. con¬ tributor to the CCITT on digital interfaces, signaling, and digital transmission. Another major contributor is the Institute of Electrical and Electronics En¬ gineers, founded in 1884 and now one of the largest professional societies in the world. Perhaps best known in communications for its development of the 802.X series of standards for local-area networks, the IEEE is especially noted for the technical elegance of its work. The IEEE is increasing its involvement in OSI-related standards. Its 802.3 CSMA/CD and 802.5 Token Ring LAN standards have become well accepted in the marketplace and have been adopted with little modification by the ISO as ISO’s 8802-3 and 8802-5 standards. As a contributor to ANSI, the IEEE is recognized as an Accredited Standards Organization. Two of the most recent extensions of its work on LANs include the IEEE 802.6 Metropolitan Area Network (MAN) and IEEE 802. ID MAC Bridge (inter-LAN bridge) standards. Another U.S. standards developer is the Manufacturing Automation Protocol (MAP) and Technical Office Protocol (TOP) Users Group, established in Sep¬ tember 1984 to address issues of communications integration in multivendor envi¬ ronments. Its focus areas are engineering, office, and manufacturing. Work on MAP has been spearheaded by General Motors, while Boeing has championed TOP. Realizing that common communications is essential for integrating these pro¬ cesses, the MAP/TOP Users Group focuses on existing and emerging international communications standards and accepted industry practices. One of its major ongo¬ ing activities is to develop and publish a generic, nonproprietary set of communi¬ cations specifications; its TOP specifications, for example, are based on OSI standards. The National Institute of Standards and Technology (formerly the National Bureau of Standards) coordinates all standards activity for the U.S. government. Within the NIST is the Institute for Computer Sciences, an activist agency with close ties to both vendors and government agencies. In 1979, the agency estab¬ lished a program to create a set of standards for communicating information be¬ tween computers manufactured by different vendors. One result was establishment of the Government Open Systems Interconnection Profile (GOSIP), a technical specification defining a set of protocols needed to support OSI applications. The NIST also sponsors “OSI Implementor’s” workshops, which are open to

18

INSIDE X.25: A MANAGER’S GUIDE

both the government and commercial sectors. Compliance with GOSIP has been mandated for all computer and network purchases by the government after 1990. The NIST also created and manages the OSINet, an international research network instituted as a means of promoting the development of OSI. Some participants in the OSINet include Boeing Computer Services, Digital Equipment Corp., General Motors, Hewlett Packard, IBM, and NASA.

Conformance-testing organizations and the role of the user Despite the best efforts of the authors to be precise, differences in interpretations of a standard inevitably arise. Also, rapid changes and subtle revisions in standards can introduce incompatibilities between “compatible” products offered by two dif¬ ferent manufacturers, thus defeating the original purpose of standards. Adherence to a specific standards profile such as in GOSIP can alleviate this problem, as can vendor-to-vendor testing over networks such as the OSINet. In addition, indepen¬ dent conformance-testing corporations have been formed to address the need for true compatibility. While no complete assurances of compatibility are possible, stringent confor¬ mance testing against a well-written test suite helps to screen out inconsistencies and “bugs” before products ever reach the market. The concept is simple: If Vendor A’s products work with Conformance Tester B, and Vendor C’s products work with B, then A should work with C. In the U.S., the Corporation for Open Systems (COS) was founded in 1986 as an independent, nonprofit consortium of vendors and users committed to the develop¬ ment of consistent, OSI-based conformance tests. Member organizations in COS total over 65 and are drawn from a variety of industry sectors, including communi¬ cations, computers and software technology, engineering, finance, government, and manufacturing. COS has developed conformance test suites for message hand¬ ling systems and for File Transfer, Access and Management (FTAM), with other OSI test suites to follow. COS issues a “seal of approval” or “COS-mark” to those products that have passed its conformance tests. A similar approach to assuring compatibility is taken by the Standards Promotion and Application Group (SPAG) is COS’s counterpart in Europe. The ultimate test of any standard is its acceptance, or rejection, by the user com¬ munity. Some carefully conceived and well-written standards have never been ac¬ cepted, in some cases because they were simply technically unrealistic or prohibi¬ tively expensive to implement, in others because de facto standards were widely adopted before the de jure proposals were aired. In this atmosphere, the MAP/TOP Users Group and other user advocacy groups have assumed a new, pivotal role in the standards process. User groups serve as the liaison between users faced with problems to solve and those in the vendor community tasked with constructing standards-based products. With the active participation of these groups, standards have been produced that are

CHAPTER 2: DATA COMMUNICATIONS STANDARDS

19

better focused, with fewer ambiguities and a better chance at success in the market¬ place. And clearer, more-direct feedback to the standards developers, especially in the form of requirements, will produce better and more timely standards in the future. FIGURE 2.2

Standards Implementation Process r

ik

STANDARDS DEVELOPERS

*

ISO, CCITT. . . .

k REQUIREMENTS

_) STANDARDS, RECOMMENDATIONS

f

/

\ \

IMPLEMENTATION GROUPS

A

CONFORMANCE TESTING ORGANIZATIONS

w

NIST, MAPCTOP, . . . v

COS, SPAG, . . . J

7

"

REQUIREMENTS

FUNCTIONAL STDS. PROFILES

TEST SUITES

PRODUCT SUBMISSION

/

A VENDORS

V

r

_)

1 USER COMMUNITY v

CONFORMANCE CERTIFICATION I

INTEROPERABLE PRODUCTS

REQUIREMENTS

r

>

CHAPTER

THE OPEN SYSTEMS INTERCONNECTION REFERENCE MODEL

The OSI Reference Model prescribes a “layered” network architecture, a com¬ prehensive set of rules or blueprints that precisely define the entire set of communi¬ cations functions and services between users or processes. The layering evolved in response to a burgeoning variety of user needs. As networking requirements have increased in complexity and sophistication, the disparity among user needs has sent designers of networking protocols looking hard for common grounds. Host-to-host electronic funds transfer of 10-megabyte files, for example, cannot be accomplished with the same techniques used for lowspeed interactive transactions. The profusion of such diverse applications forced those designers away from a rather haphazard, case-by-case approach to meeting users’ needs. Clearly, a more complete, open-ended and standard approach was needed. So despite the increasing variety of user requirements, a number of elements common to any communications process were identified by these designers. These elements included interfacing to physical media, data link integrity control, addressing and routing, dialogue management, and protocol conversion. Meanwhile, by the mid-1960s, many of the concepts used successfully by pro¬ grammers to divide large, complex programs into series of smaller and more man¬ ageable routines began to be applied to data communications. The technique of modular or structured programming was interpreted by network architects as a par¬ titioning or layering of communications elements or functions. Monolithic tele¬ communications programs began to be subdivided into discrete components, the better to adapt to both planned and unplanned network changes. Using this approach, a number of significant benefits were realized. Besides bringing improved control and reliability to complex telecommunications pro20

CHAPTER 3: THE OPEN SYSTEMS INTERCONNECTION REFERENCE MODEL

21

grams, these benefits included better adaptation to change, and better peer-layer to peer-layer interaction across the network. The principles of the design of layered protocols, from the perspective of a net¬ work architecture, are (Fig. 3.1): • Each layer should be assigned a distinct and different function. • Multiple implementation choices may exist for any given layer. • The number of layers should be kept to a minimum to simplify integration. • Layers should be isolated from one another; changes to one layer should not affect others. • Layers should communicate only with adjacent layers in the same node or peer layers on other nodes. • The interfaces between adjacent layers should be well-defined. • Layers should utilize the services of adjacent underlying layers and support adjacent overhead layers. • A layer should communicate to other layers via interfaces and to peer layers via protocols. • The local application process should not be part of the architecture.

FIGURE 3.1

NODE A

Layer Interfaces/Protocols

NODE B

22

INSIDE X.25: A MANAGER’S GUIDE

IBM’s Systems Network Architecture In an attempt to correct many of the deficiencies found in its earlier protocols, IBM introduced the first version of its Systems Network Architecture (SNA) in 1974. Before SNA, the telecommunications environment for IBM users was characterized by incompatibility of host processors and of telecommunications access methods. IBM had to support several hundred communications products that used dozens of specialized access methods, data link control protocols, and even character code sets. The net results of this duplication and variation were isolated, single-function networks with no shareability or internetworking across multiple applications or hosts. The designers of SNA faced the challenge of maintaining compatibility with a large current software and hardware base while providing a more comprehensive, feature-rich, and consistent networking architecture. In the end, these designers agreed on a seven-layered model to modularize the functions of SNA. From the outset, SNA has been hierarchical or tree-structured, with all sessions or “conversations” usually under tight host control. SNA in 1974 was applied to a single host and its associated terminals. Over time, the architecture has proven flexible and dynamic. Today SNA readily supports multiple hosts, X.25 communi¬ cations, SNA network interconnections, LAN connectivity, and even nonhierarchical workstation-to-workstation communications. SNA networks comprise about 70% of all private data networks worldwide. They are, however, seldom used as public data networks, and remain poorly equip¬ ped to handle nonIBM or multivendor traffic. So in September 1988, IBM made a series of sweeping announcements of OSI-related products. In IBM's view, SNA will remain the preferred method for IBM-to-IBM communications, while IBM’s

FIGURE 3.2

OSI

Layered Network Architectures

SNA

DNA

CHAPTER 3: THE OPEN SYSTEMS INTERCONNECTION REFERENCE MODEL

23

OSI products and services will address the needs of customers requiring IBM-tononlBM communications.

DECnet and the development of Open Systems Interconnection Another well known, albeit proprietary, network architecture is DNA, the Digital Network Architecture developed by the Digital Equipment Corp. DECnet is the framework for linking a wide array of DEC mini- and super minicomputers. The DNA architectural model interprets layering requirements slightly differently than SNA, using eight rather than seven layers. DNA was introduced in 1975 and is supported on all of DEC’s products. Like SNA, DNA has progressed over time to offer enhanced functionality and connec¬ tivity options. Unlike SNA, it more closely resembles the OSI peer-oriented struc¬ ture. As a result of increased demand for better multi vendor communications and openness, DNA is being released in its fifth incarnation. DECnet/OSI Phase V, an¬ nounced in 1987, promises to integrate the dual architectures of DNA and OSI. Two years after DEC introduced DNA, it became clear to the International Or¬ ganization for Standardization (ISO) that there was an urgent need to create a standardized and open network architecture that would support multivendor or heterogeneous communications. ISO established a new subcommittee, SC 16, to develop a comprehensive set of standards for Open Systems Interconnection. By 1978, productive working group meetings on OSI had been held in London, Paris, and Washington. Initial attention was focused on design of an overall ar¬ chitecture that could meet both current and future requirements. It was decided that a seven-layered architecture was the best approach. The seven, which will be de¬ scribed in detail later, are, from the bottom up: the Physical Layer, the Data Link Layer, the Network Layer, the Transport Layer, the Session Layer, the Presenta¬ tion Layer and the Application Layer. Work progressed rapidly, and by 1979 the basic “Reference Model of Open Sys¬ tems Interconnection” was adopted by ISO’s Technical Committee 97. After the normal gestation period of compromise and revision, this model reached the status of International Standard (ISO 7498) in 1983. Here is how the U.S. National Bureau of Standards summarized the benefits of OSI: “Both the government and the private sector recognize the need to develop a set of common data communications protocols based on the International Organiza¬ tion for Standardization’s (ISO’s) seven-layer Open Systems Interconnection (OSI) Basic Reference Model. In the past, vendor-specific implementations of data com¬ munications protocols led to isolated domains of information, very difficult and ex¬ pensive to bridge. Recent advances in communications technology based on the OSI model offer alternatives to vendor-specific network solutions. Most signifi¬ cantly, advances in open systems allow the interoperation of end systems of differ¬ ent manufacture, when required. By implementing open systems, the government expects to realize significant savings through reducing duplicate circuits and wir¬ ing, training, custom software, workstations, and custom hardware interfaces.”1

24

INSIDE X.25: A MANAGER’S GUIDE

Concurrent with ISO’s efforts, the CCITT also began developing its own vari¬ ation of an open systems reference model. Rather than coming up with a similar but incompatible architecture, the CCITT adopted ISO’s definition. This document was published by the CCITT as Recommendation X.200. Either variant is com¬ monly referred to as the OSI Reference Model. As with most other ISO and CCITT documents, the terminology of OSI is rather abstruse and impenetrable. Any practical application-related or implementationspecific references are intentionally absent in this and all other CCITT documents. The author assumes that the objective is to produce standards whose interpretation is uncolored by association with real-world design, manufacturing, or implementa¬ tion issues. In the abstract, any individual layer in the OSI model can be designated as the N-layer. The adjacent layer above the N-layer is referred to as the N+l; the layer below, N-l (Fig. 3.3). Much like the foundation and floors of a multistory build¬ ing, each new layer depends upon the layers beneath it for support. Each new layer, in turn, provides a new set of services to the layers below it. The boundary (“mor¬ tar”) between layers is termed an interface. Since each interface is well defined, software developers may more easily reuse portions of existing products, rather than having to develop every new OSI product from scratch. The lower four layers of the OSI Reference Model —the Physical, Data Link, Network and Transport Layers —are collectively called the data transport layers. They combined to move data reliably across any OSI network on an end-to-end basis. In practice, these four layers are closest to actual network hardware.

FIGURE 3.3

Layering Principles

LAYER N + 1

PROTOCOLS

ADJACENT LAYER

PROTOCOLS

PEER LAYER

SERVICES ••

PROTOCOLS

NODE A

ADJACENT LAYER

NODE B

CHAPTER 3: THE OPEN SYSTEMS INTERCONNECTION REFERENCE MODEL

LAM STACK

25

WAN STACK (X.25 SHADED)

JTMP = Job Transfer & Manipulation Protocol MHS = Message Handling System TP = Transaction Protocol FTAM = File Transfer and Access Management VTP = Virtual Terminal Protocol ASN = Abstract Syntax Notation PLP = Packet Layer Protocol MAC = Media Access Control LAPB = Link Access Procedure-Balanced HDLC = High-Level Data Link Control

At the lower levels of OSI, a variety of physical network connectivity options present themselves to network planners (Fig. 3.4). For example, is Flost A to be at¬ tached to a local or wide-area network? If LAN, several options are currently avail¬ able, with newer choices forthcoming. Based on performance, loading, and other considerations, LAN designers may choose to implement either ISO 8802-3 or 8802-5 at Layer Two. These OSI choices are equivalent to the better known IEEE 802.3 and 802.5 standards. If the choice for Host A is a WAN, then X.25 is the OSI standard to be used. The X.25 Recommendation contains specifications for all three of the lower OSI layers.

26

INSIDE X.25: A MANAGER’S GUIDE

LAN and WAN connectivity are not mutually exclusive options within a single end-system. An immediate and practical benefit of having multiple options at the lower levels is internetworking, the ability to interconnect networks. Geographi¬ cally scattered standalone LANs can be interconnected to form a single logical LAN by using X.25 over WAN links. LAN/WAN installations, running under the OSI framework, can be upgraded to take advantage of newer technologies as they emerge, without changing upper-layer software. OSI networking may be applied with equally good results to private or public networks. In the example above of LAN-to-LAN interconnection using X.25, the WAN transport service could be provided by a private leased line, a private packetswitched network, or a public packet-switched network (a VAN or value-added network). Even combined private/public networks are possible.

X.25 and Open Systems Interconnection The first X.25 Recommendation issued by the CCITT in 1976 predates the ap¬ proval of the OSI Reference Model by several years. Fortunately, due to its modu¬ larity and adherence to the principles of layering, the work done by the CCITT on X.25 was easily incorporated into OSI. As a standard, it is significant that X.25 works equally well when applied in two distinctly different ways. On its own and not in the context of any OSI upper layer protocols, X.25 has functioned well as a shareable, protocol-independent data transport mechanism. This use of X.25 could be considered its “first wave” and is marked by the years 1976 through 1988. The second wave of X.25 began in 1988 with the first commer¬ cial availability of upper layer OSI products. A full OSI protocol stack for WANs was finally available, with X.25 firmly anchored at the bottom. The distinction between the first and second X.25 waves is significant. In the first case, X.25 provided interconnectivity between “like” end-systems on the net¬ work. These end-systems used the same higher level protocols, whether they were asynchronous or synchronous. Applied in this way, X.25 provided an economical method of sharing a common packet-switched backbone network. A notable exception is the Transmission Control Protocol/Internet Protocol (TCP/IP) over X.25. TCP/IP is the predecessor of OSI and roughly equivalent in function to the OSI middle layer protocols. Its impact in the commercial and public sectors has been limited, so far. Operators of Arpanet, the Department of Defense Data Network (DDN), and the university research networks have been its primary advocates (although interest in TCP/IP has spread to engineering organizations as well). In contrast to the first X.25 wave, the second wave has taken a broader perspec¬ tive, viewing X.25 as a means of achieving the larger goal of true interoperability. The interconnectivity equated with the first X.25 wave provided benefits and draw¬ backs similar to those of the telephone. The international public switched telephone network allows a caller in France to easily dial and speak with someone in Japan. But because of acute differences in language, the parties in France and Japan can

CHAPTER 3: THE OPEN SYSTEMS INTERCONNECTION REFERENCE MODEL

27

talk to one another, but they cannot communicate. For meaningful communication to occur, some method of translation is required. To go beyond connectivity, this translation may take the form of an intermediate language agreed to by both partici¬ pants. It is this function that is provided by the upper layer protocols of OSI, and the second wave of X.25.

What Open Systems Interconnection is not The OSI Reference Model intentionally leaves certain communications aspects to the discretion of the user. These aspects are generally described as “Local Matters” in the standards documents. For example, below the Physical Level, the ISO does not always specify the type of media or cabling to be used. In the case of X.25, some Study Group members argued that modems should be considered as part of the Physical Layer. This notion was rejected, however, as the modem was viewed simply as a relay device that happened to perform a digital-to-analog conversion. Within each layer, software developers are free to use whatever algorithms and coding techniques are appropriate, as long as the final result meets specifications. Beyond the Application Layer is the application program itself. OSI says nothing about the user interface characteristics (if any) of programs offering X.400 elec¬ tronic mail or FTAM (File Transfer, Access, and Management) capabilities, as these, too, are purely local matters. OSI protocols are also independent of the computer’s operating systems. How¬ ever, certain vendors may choose to implement selected subsets of OSI protocol stacks. Well-defined profiles, such as GOSIP and MAP/TOP, are attempts at re¬ ducing the variation among OSI choices. Ultimately, however, the responsibility is with end-users to either adopt existing profiles for their own use or to clearly under¬ stand their own needs and articulate them to vendors. Vendors will undoubtedly try to develop their own proprietary or value-added extensions to the base level of functions provided by OSI. In many cases, OSI will augment, but not displace, the proprietary telecommunications methods already up and running on a production network. For example, gateway products are emerging that link native E-mail programs, like IBM’s PROFS and DEC’S ALLIN1, to X.400 (discussed later with Figure 3.9). Other vendors may second guess the standards process, choosing to beat their competitors to market with an early-interpreted standard, perhaps released when the ink on the ISO Draft Proposal was still wet. The current crop of quasi-OSI net¬ work management products fall into this category. Yet another strategy is to mask as much of the OSI network as possible from the user, making it almost disappear into the backdrop of the native network architecture.

A brief tour of the layers of OSI The Physical Layer provides the electrical, mechanical, and functional interface to the communications media. The procedures defined in the Physical Layer establish.

28

INSIDE X.25: A MANAGER’S GUIDE

maintain, and release the physical connections or data circuits between network end-points. The Physical Layer is described in greater detail in Chapter Five. Using the services provided by the Physical Layer, the Data Link Layer is re¬ sponsible for the synchronization of data and the error-free integrity of that data be¬ tween end- systems. In X.25, the Data Link Layer operates in a point-to-point mode between these end-systems or network entities. In a LAN, a shared data link protocol may service dozens of hosts or workstations. As specifically related to X.25, the Data Link Layer is covered in Chapter Six. The establishment, maintenance, and disconnection of end-to-end logical calls or connections are the responsibility of the Network Layer. Network addressing, rout¬ ing, and multiplexing are also handled by this layer. Because of the variety of ser¬ vices and facilities required, the Network Layer is the most complex layer of X.25. For OSI, two very different Network Layer protocol types are possible. The X.25 packet layer protocol uses a somewhat older, but effective, technique de¬ scribed as a connection-oriented protocol. In this method, a virtual circuit or trans¬ mission path is created through the network for each call and held until the commu¬ nication is finished. A newer development is the connectionless mode, where each packet of data is addressed and sent through the network separately. Each packet is free to take the best available path. This is sometimes referred to as “send and pray,” since no assurances of data receipt are given. These functions may be han¬ dled by a higher-level protocol. As a protocol, the connectionless mode requires less overhead and eliminates the call set-up time of X.25. It is widely used in LANs where all devices share the same physical media and transmission error rates are generally lower than with their WAN counterparts. Chapter Seven describes the Network Layer of X.25 in depth.

FIGURE

3.5

OSI Layer Functions

END-USER PROCESS INTERFACE & ACCESS POINT

INFORMATION ENCODING, TRANSLATION

DIALOG ORGANIZATION & SYNCHRONIZATION

END-TO-END DATA TRANSPARENCY, RELIABILITY

RELAY, ROUTING, & SWITCHING POINT-TO-POINT SYNCHRONIZATION, ERROR DETECTION/CORRECTION BIT TRANSMISSION, MEDIA INTERFACE

CHAPTER 3: THE OPEN SYSTEMS INTERCONNECTION REFERENCE MODEL

29

At level four, the Transport Layer serves as an intermediate or boundary layer between the lower and upper layers of OSI. Transport Layer protocols are implemented solely in network end-systems and are not required in intermediate network nodes. The Transport protocol provides for the transparent transfer of data between end-systems and relieves these entities of responsibility for selecting paths through the network. If requested, the Transport Layer may also provide an additional, end-to-end guarantee of reliability, beyond the point-to-point method used by the Data Link Layer. Flow control on an end-to-end basis is also handled by the Transport Layer. Five different protocol, or quality-of-service, classes exist within this layer. They range from Class 0, which adds little in functionality beyond that of the Network Layer, up to Class 4, the error detection and recovery class. Class 4 as¬ sumes that it can’t trust the lower three layers and adds its own checksum as well as some additional timers to every packet. Class 2 is a multiplexing class, where several transport sessions can be multiplexed over the same Network Layer virtual circuit. Classes 1 and 3 are not in common use. Further parameters within the Transport Layer allow the user to determine the quality of service desired. This service is negotiated between end-systems and remains in effect for the duration of the connection. Thus, the trade-off between performance (as expressed in throughput, error rate and transit delay) and cost and overhead is put under direct user control. Dialogue management, binding (establishment of a session between two points), and synchronization are the functions performed by the Session Layer. Dialogue management decides whether sessions operate in full- or half-duplex mode, and how each end-system or network entity takes turns sending and receiving. Al¬ though the Transport Layer operates in full-duplex mode, many applications and most terminal sessions are inherently half-duplex. As with IBM 3270 terminal ses¬ sions, the session layer controls the “locking” and “unlocking” of the keyboard. In half-duplex mode, a data token is passed back and forth between network entities. Whichever end is in possession of the token gets to transmit. Optionally, tokens can also be used to establish both minor and major synchroni¬ zation points during data transfer. This is particularly important as a recovery mechanism during transient network interruptions. The synchronization point es¬ tablishes a well-defined and mutually known reference point during file transfer or when updating a distributed database. By allowing the application process to re¬ cover from temporary outages without aborting the entire transfer, the usefulness of the data already received is preserved. The Presentation Layer’s role is to provide syntax management services to the Application Layer above it. Syntax management pertains to the format and lan¬ guage of the data, rather than its actual meaning. It is at the Presentation Layer that language or code-set translation occurs. The Presentation Layer communicates with the Application Layer using a Pascal-like set of rules known as the Abstract Syntax Notation or ASN.l. Horizontally across the reference model, peer entities in the Presentation Layer use a common protocol that encodes the data in a hexadecimal

30

INSIDE X.25: A MANAGER’S GUIDE

format. However, if the application entities at either end use the same syntax, the translation performed by the Presentation Layer becomes minimal or nonexistent. A number of significant OSI protocols have already been developed or are near¬ ing completion that rely heavily upon the services of this layer. The Virtual Termi¬ nal Protocol or VTP is a software-defined and hardware-independent “universal” terminal protocol that provides terminal emulation capabilities between dissimilar end-systems. The Basic Class of VTP specifies a terminal whose virtual charac¬ teristics include scrolling or paging. The task of creating a full-featured virtual ter¬ minal protocol supporting different modes of operation, such as line and block modes, is likely to require several more years of development. Also using the services of the Presentation Layer is the Job Transfer and Manipu¬ lation Protocol (JTMP). JTMP allows an open system to transfer or submit “jobs” for execution on a remote system. JTMP is similar in concept to IBM’s JES2 or Job Entry Subsystem. In addition to actual job submission, JTMP provides for operator manipulation and job-status inquiries. Atop of the OSI stack is the Application Layer, the only layer that is in direct contact with end-users or applications. The Application Layer is not the application process, which is considered to be outside of the OSI Reference Model. Rather, the Application Layer is the broker or liaison between the application and the entire OSI protocol stack. Its functions include the uniform initiation, maintenance, and release of network connections for the application process. Upper-layer application protocols provide the needed functionality within OSI to achieve interoperability between dissimilar end-systems. The first two Application Layer protocols to gain wide acceptance are the CCITT X.400 and the ISO FTAM recommendations. X.400, or the Message Handling Sys¬ tem (MHS), is a group of related recommendations that support electronic message exchange over a variety of configurations. Often referred to as electronic mail, X.400 allows document mailing to any subscriber on an OSI network. X.400 has been embraced as a service by the VANs in the U.S. and the PTT-operated public data networks. Private implementations of X.400 with gateways to public X.400 facilities will permit the exchange of electronic mail between business and trading partners. Among the X.400 service providers, alliances are being forged that will eventu¬ ally allow electronic mail to be carried from any public X.400 installation to any other in the world. X.400-formatted documents may also be used to carry attached text or binary files, if desired. FTAM is a comprehensive set of services for file transfer and control between networks. FTAM supports both text and binary files. In addition to full file trans¬ fer, it includes facilities for record-level access, remote file creation and deletion, and file-attribute modification. Record-level access means that a user with the proper level of authorization can add, change, or remove data anywhere within an existing file on a local or remote end-system. Figure 3.6 is the entire layer-by-layer process of frame construction/reduction used in moving data from sender to receiver.

CHAPTER 3: THE OPEN SYSTEMS INTERCONNECTION REFERENCE MODEL

FIGURE 3.6

Frame Construction/Reduction SENDER

FRAME CONSTRUCTION

DATA APPLICATION

AH

PRESENTATION

PH

SESSION TRANSPORT

DATA LINK

DATA

SH

DATA

TH

NETWORK

DATA

DATA

NH

DATA

DLH

DATA

PHYSICAL

DLT

BITS SERIAL TRANSMISSION

MEDIA

FRAME REDUCTION BITS

PHYSICAL DATA LINK NETWORK TRANSPORT SESSION

DLT

DATA

DLH

DATA

NH

DATA

TH

DATA

SH

DATA

PH

PRESENTATION

AH

APPLICATION

DATA

DATA RECEIVER H = Header

31

32

INSIDE X.25: A MANAGER’S GUIDE

The hardware of OSI: bridges, routers and gateways The hardware found at the intermediate nodes within an OSI network operates at different levels within the OSI Reference Model. Unfortunately, the terminology used to describe these devices has been widely misinterpreted and misused over the years. There are three general categories of hardware devices: bridges, routers, and gateways. Providing the least complexity and functionality, bridges operate at layers one and two of OSI (Fig. 3.7). Bridges are commonly used to either segment or extend LANs running the same type of Logical Link Control, typically IEEE 802.2. The Logical Link Control layer is a sublayer within a LAN Data Link Layer. Because bridges operate solely at the lowest two layers, they are closest to being pure hard¬ ware devices and offer an excellent price/performance ratio. Bridges straddle two LANs. Their job is to “listen” to both LANs and forward only those packets ad¬ dressed to the opposite LAN. Bridges cannot support direct X.25 links since they employ no Network Layer protocol. Routers (Fig. 3.8) are also widely used in LANs, but they must be compatible with OSI layers one, two, and three. Unlike a bridge, a router supports at least three — typically more — physical links. For incoming packets, the router makes a determination as to which is the appropriate output link. If a connection-oriented protocol like X.25 is used, this decision is only made once at the call-establishment period. A router then establishes its internal path for the duration of the call. If a connectionless protocol is used, however, the address of every incoming packet must be examined and a routing determination made. This increases the router’s processing overhead and decreases performance. Historically, the terms “switch” or “packet switch,” rather than router, have been used in conjunction with X.25 networks. (Packet switches for X.25 will be covered in more detail in later chapters.) The last major category of interconnection device is the gateway (Fig. 3.9). Gateways implement all seven layers for two entirely different protocol stacks. In an OSI gateway, OSI is used for one of these stacks, while proprietary network protocols are used in the other. The gateway then becomes a sophisticated, mul¬ tilayered protocol converter, allowing bidirectional access between open and

FIGURE 3.7

Bridge 802.2 LOGICAL LINK CONTROL

LLC SUBLAYER

DATA LINK LAYER

PHYSICAL LAYER MEDIA

802.5 TOKEN RING

802.3 CSMA/CD

TOKEN RING PHYSICAL

BASEBAND

SHIELDED TWISTED PAIR

MAC = Media Access Control

COAXIAL CABLE

MAC SUBLAYER

CHAPTER 3: THE OPEN SYSTEMS INTERCONNECTION REFERENCE MODEL

FIGURE

3.8

Router

LINK 3

LINK 2

FIGURE

3.9

OSI/SNA Gateway

OSI STACK

SNA STACK

33

34

INSIDE X.25: A MANAGER’S GUIDE

closed systems. This approach is well suited to existing nonOSI networks that only need secondary access to OSI applications or end-systems. A single centralized OSI gateway could appear as an addressable node on the proprietary network and service the entire host or terminal population. Full OSI gateways come at steep costs in both price and performance, however. Also, the number of concurrent sessions supported by a gateway is restricted, since simultaneous protocol conversion occurs at multiple levels. In X.25 references, the term gateway is sometimes misused to indicate an interconnection point between two packet switched networks, whether they be private or public. In this context, an X.25 “gateway” only operates on the three lower OSI layers.

Note 'Government Open Systems Interconnection Profile, FIPS PUB 146, Federal Information Processing Standards Publication, U.S. Department of Commerce/National Bureau of Standards, August 24, 1988.

CHAPTER

BOTH SIDES OF THE CLOUD

Cloud

‘klaud n, 1 a: a visible mass of particles of water or ice in the form of fog, mist, or haze suspended usu. at a considerable height in the air 2 : a usu. visible mass of minute particles suspended in the air or in a gas; also : one of the masses of obscur¬ ing matter in interstellar space 3 : a great crowd or multitude1

To Webster’s definitions of cloud might be added yet another: in data communica¬ tions, the symbol of a packet-switched network. To fully understand X.25 and packet switching, it is important to look at that cloud from both sides. While thoroughly describing the interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for packet-mode devices, the X.25 Recommendation has nothing to say about the internal protocols and al¬ gorithms needed to operate a packet-switched network. This chapter covers both sides of the cloud, the outside as specified by X.25 and other CCITT Recommenda¬ tions, and the less frequently described inside, encompassing a mass of circuits and switches.

The external view: X.25 terminology, the DTE/DCE interface and access methods In the strict sense of OSI, X.25 is not really a data-communications protocol. Rather, it is a specification for a network interface that uses individual protocols at each of its three levels —the Physical Layer, the Data-Link Layer and the Network Layer. The CCITT’s title for its Recommendation X.25 is deceptively simple: “In¬ terface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for terminals operating in the packet mode on public data networks." To better interpret this title, a brief explanation of some basic CCITT terminol¬ ogy is essential. In the X.25 context, DTE is a generic term for any network35

36

INSIDE X.25: A MANAGER’S GUIDE

ttached, customer-premises or end-user equipment that operates in the packet mode. DTEs come in a variety of forms and packages. A standalone minicomputer running X.25 communications software is a DTE. A front-end processor loaded with X.25 code is also a DTE. A flourishing industry has been developed around another variety of X.25 DTE, the Packet Assembler/Disassembler or PAD. The PAD converts data between X.25 and other communications protocols. This permits a user with an installed base of older, nonX.25 equipment to operate on a public or private packet-switched net¬ work. PADs are most commonly used for display terminals but may also accommo¬ date printers, computers, Teletype machines, and even terminal servers. They are purchased according to the specific processing protocol required. Versions cur¬ rently available, for examples, support asynchronous, IBM Bisynchronous, IBM SNA, Hewlett Packard, and Burroughs Poll/Select protocols. Except for asynchronous communications, using the X.25 interface generally requires a PAD of the same protocol type on each end of the network. A common misconception is that PADs can magically provide protocol conversion between dissimilar end-system devices, such as asynchronous terminals to SNA hosts. Such is not the case, as X.25 is provides only connectivity and not interoperability. A second common type of DTE is the start-stop mode DTE, typified by our familiar display or “dumb” terminal. The term start-stop is derived from the asyn¬ chronous protocol used by these terminals. Unlike packet-mode devices, which transmit blocks of data or packets to the network, the async terminal transmits a single character at a time. Since asynchronous data uses no clocking signals, each seven-bit ASCII character requires an additional start bit and one or more stop bits to achieve synchronization between sender and receiver. A set of separate, nonX.25 network interface specifications have been developed by the CCITT for start-stop DTEs, and will be described in a later section of this chapter. In the X.25 interface, every device that is not a DTE is almost always a DCE. The logical outward appearance of a public data network is that of one colossal, distributed DCE. In reality, each X.25 port in the network is a DCE. The DCE is the summation of all the devices associated with that single network port. Because each network port’s modems, cables, and packet-switch interface are hidden from the user and exist inside the cloud, they can be conveniently grouped together as one DCE. X.25 requires a DTE/DCE pair to operate. No CCITT specification yet exists for a DTE/DTE or DCE/DCE interface. The DTE/DCE interface is shown in Figure 4.1. The protocols underlying the X.25 interface, however, go well beyond simple physical connectivity to the network. At each of the three lower levels of the OSI model, customer premises and network equipment must share a compatible set of interfaces and signaling conventions. Separate protocol conventions exist for X.25’s Physical, Data-Link, and Network Layers. When constructing an X.25 link, these layers are established in sequence from the bottom up. The Carrier Detect signal on the modem indicates that the physical circuit to the network is

CHAPTER 4: BOTH SIDES OF THE CLOUD

FIGURE 4.1

37

X.25 Interface Location

operational and able to transport the bitstream. The Data-Link Layer provides the assurance that DTE and DCE recognize each other and can send error-free frames back and forth. The Network Layer specifies the procedures for setting up calls and for sending packets of information over the network.

Network access over leased lines Most public data networks (PDNs) today support a variety of access or attachment methods (Fig. 4.2). These fall in two major categories, leased-line and dial-up connections.

38

INSIDE X.25: A MANAGER’S GUIDE

FIGURE 4.2

PDN Access Methods

At the physical level, the first X.25 Recommendation specified a dedicated or leased-line connection between customer equipment and the network. Since 1976, the X.25 Recommendation has undergone several significant revisions in response to user feedback and demand. For a direct X.25 interface to a public data network, however, the predominant attachment method today still remains a leased-line connection. Leased lines are purchased on a monthly basis from the PDN or value-added net¬ work. X.25 uses a synchronous protocol for layer one, with current synchronous modem technology permitting data rates up to 19.2 kbit/s over analog lines. Digital leased lines in the U.S. are available at speeds up to 56 kbit/s and 1.544 Mbit/s (T1 service). In addition to the error detection/correction inherent in X.25, a major advantage is its ability to statistically multiplex or interleave many calls over a single physical

CHAPTER 4: BOTH SIDES OF THE CLOUD

39

line (Fig. 4.3). Statistical multiplexing takes advantage of the inherent “bursty” na¬ ture of data communications — particularly the interactive type —to utilize expen¬ sive bandwidth more efficiently. Six terminal users at 1.2 kbit/s can share a single 4.8-kbit/s physical leased line using X.25, while dozens can use a 56-kbit/s circuit. Leased-line connections to the network terminate at the DCE, which is usually integrated into a packet-switching node. The hierarchy used is similar to that of the telephone network, where individual telephone lines terminate at the switch of the nearest central office. In either case, the lines operate bidirectionally, allowing both inbound and outbound calling. Each device on the network gets its own unique number or address. On a PDN, incoming calls to a host computer are possible because each port on the packet switch is assigned its own unique address or range of addresses on the network. Some PDNs support synchronous leased-line connections to nonX.25 devices, such as IBM cluster control units or front-end processors. Generally, this requires that the PAD used for conversion from SNA to X.25 remain within the network rather than at the customer’s site. These nonX.25 leased lines may be either point-to-point or multidropped.

Access by dial-up connection A more recent innovation of the PDNs is the availability of dial-up X.25 services. X.25 over a synchronous dial-up connection is officially entitled X.32 and was first issued by the CCITT in 1984. X.32 shares most of the X.25 capabilities and is appropriate for low- to medium-volume usage. The majority of calls placed over the network originate from dial-up users. This is as true today as it was in the earlier days of packet switched networks. Typically, these calls are made with low-speed asynchronous terminal or PC connections, ranging in speed from 300 to 2,400 bit/s. Advances in modulation techniques have boosted the upper limit of this to 9.6 kbit/s, although this service is not yet univer¬ sally available. Keep in mind that each public network node must be equipped with a pool of dial-in modems to support these users. Also, compatibility must be main¬ tained between the modems at both ends of the dial-up connection. Unlike the X.25 leased line that terminates in the DCE, these asynchronous

FIGURE 4.3 X3 Y3 Z3

X2 Y2 Z2 DATA

Packet Interleaving

xT) PACKET DEVICE

Yl]

XI

X2

X3

Yl

Y2

Y3 Z2

Z1

ZlJ

X3

X2

XI

Y —• Y3

Y2

Yl

z

Z2

Z1

X'^ PACKET DEVICE

USERS

USERS PHYSICAL CIRCUIT

^ Z3

DATA

40

INSIDE X.25: A MANAGER’S GUIDE

terminals, or start-stop DTEs, dial directly into a ports on PADs (Fig. 4.4). Dumb async terminals have seemingly been around forever, and there are countless vari¬ eties of terminal types, each with its own idiosyncrasies. Likewise, there are wide variations in the async line protocol itself — ranging from seven data bits, even par¬ ity, and 1.5 stop bits, to eight bits, no parity, and 1 stop bit —with a dozen other permutations in between. Although there are some de facto terminal-emulation standards and line protocols in widespread use, it is the job of the PDN to be com¬ patible with as many strains of the async protocol as possible. Once again, international standards have been developed to address this need, easing, but not entirely solving, the problem. Asynchronous PADs, whether lo-

FIGURE 4.4

Internal Network Pad

DTE

START/STOP DTE

CHAPTER 4: BOTH SIDES OF THE CLOUD

41

cated within the network or at the customer site, invariably support three CCITT standards: X.3, X.28, and X.29. These standards serve two primary functions. They permit the configurability of each PAD port to match incoming terminals and remote-host-computer requirements. They also provide a high-level, English-like command language, so that the dial-up user can tell the network to set up a data call to some remote host computer or database. The net effect is to provide some simple yet flexible features to the dial-up com¬ munity, with the goal to make the PDN nearly as easy to use as making a phone call. Examples of these features include indications when the remote host is busy or out of service, or when the network could not complete the call. If the user wants to briefly put the host computer on hold, to enable communications directly to the PAD, these parameters allow that as well.

The user’s network requirements From the user’s perspective, the most basic task of any PDN is to interconnect a pair of DTEs by building an end-to-end path through the network. The level of ser¬ vice expected from this network path is common to all attached DTEs, whether they be PCs or mainframes. Taken in total, the characteristics of this service must be an improvement on those offered by traditional ones — such as direct distance dialing or circuit-switched services-—to attract and keep users. The general attri¬ butes of packet switched PDN services fall into the following five major categories: • Consistency and reliability • Data integrity • Cost reduction • Efficient performance • Versatility Given the variable quality of dial-up connections through the Public Switched Telephone Network (PSTN), a higher grade of service is provided by PDNs. Con¬ ventional dial-up circuits are subject to all the inherent limitations of circuitswitched analog lines, such as noise, echo, attenuation, and call blocking. The effect of line impairments is cumulative. As with voice connections, the quality of dial-up connections often degrades with increasing distance. International dial-ups offer the poorest consistency and reliability. If the connection is temporarily inter¬ rupted or broken, the call often gets dropped. Once a packet is inside the packet-switched network, it is the network’s respon¬ sibility to transparently detect and correct packet errors at every hop across the net¬ work. What comes out of the network at the remote end should exactly match what entered the network. If an internal circuit or node along the path established by the network fails, this should be self-correcting without any user intervention or even knowledge of the event. Cost reduction is another primary concern to most users. PSTNs charge for calls by connect time, with rates increasing with distance. With connection quality fac¬ tored in, you often end up paying more to get less. PDNs traditionally bill on a flat

42

INSIDE X.25: A MANAGER’S GUIDE

connect time and data traffic basis. Charges are insensitive to the distance of the established connection. Since the bandwidth on a packet network is shared among a number of users, the raw performance of any given connection is something less than an equivalent cir¬ cuit-switched connection. The inherent efficiency of X.25, coupled with its own low protocol overhead and advances in packet-switch technology, have reduced this performance gap substantially, however. In many cases, given host processing time, the difference between the two in network delay and response time is im¬ perceptible to the end user. Other applications, such as file transfer, are largely immune to network transit delays but more sensitive to limitations in throughput. One of packet switching's major strengths has always been its versatility. An X.25 network connection over a single physical link can support dozens of simul¬ taneous calls, all going to different points on the network. New calls can be added and old ones disconnected without affecting other users. Using the proper combi¬ nation of multiprotocol PADs, a single X.25 link can multiplex many dissimilar protocols over one circuit. This characteristic, along with X.25's almost universal support among computer equipment manufacturers, makes it ideally suited as the interface to a shareable packet-switched backbone network. A network of this type delivers any-to-any connectivity: it is the responsibility of end-system upper layer protocols, such as OSI, to deliver any-to-any interoperability.

The view from inside: what X.25 does not define In its infinite wisdom, the CCITT decided for the most part that it had no business inside the cloud and left that up to the hardware vendors and large-scale packetswitch manufacturers. In other words, don’t expect to find X.25 used inside the network because it isn’t there. In practice, a PDN’s internal protocol usually resembles X.25, but with mod¬ ifications to handle special accounting, network management, or flow control pro¬ cedures. Small, private, packet-switched networks sometimes use X.25 as their internal network protocol. The inside of any given public packet-switched data network, hereafter abbreviated as just PDN, is highly homogeneous, because all the packet-switching equipment is usually from a single source; lack of standard interswitch protocols, not to mention network management facilities, usually eliminates any possibility of multiple vendors on the inside of a PDN. Fortunately, this internal network uniformity simplifies troubleshooting and has little if any visible impact on the end-user. As mentioned earlier, there is no specification for DCE-to-DCE communica¬ tions. DCE-to-DCE communications must pass through an intermediate device, a DSE or data-switching exchange. The DSE is sometimes also known as a PSE or packet-switching exchange and can be viewed as either an intermediate- or end¬ switching node in the network. DSEs may be connected to DCEs or to other DSEs. DSEs are generally connected in a mesh topology (Fig. 4.5). The internal net¬ work circuits for this interconnection are purchased for their bandwidth and

CHAPTER 4: BOTH SIDES OF THE CLOUD

FIGURE 4.5

43

Conceptual Packet Switched Network Model

DSE = Data Switching Exchange

throughput characteristics. Lightly loaded network nodes may only need 9.6-kbit/s analog circuits to meet packet data-traffic demands. For purposes of redundancy, it is standard network engineering practice in most PDNs to have at least two circuits going to every node. Nodes located in major metropolitan locations may utilize multiple 56-kbit/s digital links, with the trend today toward even higher speeds, such as T1 (1.544 Mbit/s). Often, PDN providers are associated with common carriers, operated either by the government or private sector, that are in the business of selling circuits. Packet data may economically ride on the common carrier’s backbone, which in many cases today means optical fiber. PDNs also use satellite links, although somewhat

44

INSIDE X.25: A MANAGER’S GUIDE

more judiciously due to their higher inherent propagation delay. End-to-end satel¬ lite link transit delay ranges from 250 to 300 milliseconds. Single satellite hops are tolerable; with multiple hops, the delay becomes perceptible and annoying, par¬ ticularly to the interactive-terminal user. Another potential problem area when satellites are used is computer time-outs. They must be adjusted to the expected propagation delay; otherwise, sessions will terminate prematurely.

The PDN’s internal requirements To deliver the service level expected by its thousands of users, the PDN’s internal design must be consistent with the major user requirements discussed above. PDNs are designed and engineered with the objectives of reliability, data integrity, and efficient performance as essential requirements. To this list, PDNs add several additional conditions of their own, which may or may not be directly apparent to the user community. Overall, a PDN’s ongoing objective can be stated simply: to enhance its level of service beyond that offered by circuit switching. In the mid-1970s, this was no small task, since the telephone companies had had one hundred years or so to hone and perfect their circuit-switched networks. Until very recently, fortunately or un¬ fortunately, the PSTNs have optimized their networks for only one application, voice. Unlike those for data, which comes in many shapes and sizes, network requirements for voice transmission are relatively uniform and predictable. Voicenetwork designers can more readily predict the network bandwidth, throughput, and routing requirements for any type of voice call.

Virtual circuits Routing may be defined as the establishment of an end-to-end connection or data path through the network. At the time of Call Setup over an X.25 link, the calling or source DTE inserts the called or destination DTE’s address in the Call Request packet. This information is passed over the local DTE/DCE interface. The network address is in decimal format and may be up to 14 digits long, although many PDNs support shorthand addressing schemes as well. Actual packet routing is a DSE function. Typically, the first DSE in the chain determines to which particular link to forward the Call Request packet, and passes it to the next DSE en route. This process is repeated by every DSE in the path until the Call Request packet reaches the destination DTE and the call gets accepted. At this point, the network has created a logical end-to-end association between source and destination DTEs, known as a virtual circuit or VC. Each user-originated call over the network requires its own separate VC (Fig. 4.6). Two VC varieties are available. The more common, the switched virtual circuit or SVC, emulates a circuit-switched connection through the PSTN. The second variety, the permanent virtual circuit or PVC, emulates a leased or private line.

CHAPTER 4: BOTH SIDES OF THE CLOUD

FIGURE 4.6

45

Virtual Circuits

There is no Call Setup phase associated with PVCs; both DTEs are always connected. Virtual Circuits have no real identities of their own. They are just collections of individual logical DTE/DCE and DSE/DSE connections or channels. Each logical DTE/DCE and DSE/DSE association is a point-to-point connection, and identified by a unique logical channel number or LCN. Within a VC, each hop’s assigned LCNs are independent of every other hop’s. Since each LCN is independent, no effort is required to maintain the same LCN all the way across the network. After Call Setup, packets flowing over the X.25 DTE/DCE interface do not con¬ tain any network addresses. For both transmitted and received packets, only the assigned LCN for that particular interface is needed to preserve communications.

46

INSIDE X.25: A MANAGER’S GUIDE

Within the network, each DSE or packet switch only has to remember, for exam¬ ple, that LCN 26 on Link 2 is connected to LCN 79 on Link 5 (Lig. 4.7). Over a single physical circuit, the X.25 DTE/DCE interface supports a theoreti¬ cal maximum of 4,096 logical channels. Once the call is disconnected, the logical channel assignments are released and those LCNs are available for the next call.

Datagrams and connectionless protocols In contrast to the virtual circuit for internal network connectivity stands the data¬ gram, the classic example of the connectionless protocol discussed in chapter three. Datagrams shift the burden of responsibility for certain requirements — such as error correction, delivered-packet resequencing, and lost packets —from the net¬ work to the end-node or the end-user equipment. Described in OSI terminology, these responsibilities become implemented as functions of the Transport Layer. Datagrams afford a “lean-and-mean” method of moving data, potentially requir¬ ing less protocol overhead and less intermediate-node software for processing. A datagram packet is self-reliant; each contains a source and destination address. There is no need for a datagram to contain a logical channel number as they are simply “sprayed” into the network (Fig. 4.8). One interesting advantage of the datagram protocol is the elimination of call phases. Unlike the Call Setup, data transfer, and disconnection phases of X.25, datagrams have only a single phase: data transfer. This can be particularly useful when sending small amounts of timecritical information. Considerable controversy still surrounds use of connection-oriented rather than connectionless protocols. The original version of X.25 did not support datagrams.

FIGURE 4.7

Switching Node Logical Channel Assignments PACKET SWITCHING NODE (DSE)

TO DTE

DCE

DCE

TO DTE

CHAPTER 4: BOTH SIDES OF THE CLOUD

FIGURE 4.8

47

Conceptual Datagram Model

By 1980, datagram support crept into the X.25 Recommendation as a means of augmenting conventional virtual circuit connections. This concession did not end the battle, however, and the pro connection-oriented contingent won its final vic¬ tory in 1984, when datagrams were excised completely from the Recommendation. Lack of X.25 support does not prohibit the use of datagrams as effective internal network protocols, however. The outside of the cloud can be connection-oriented: inside can be connectionless. Such is the case with Arpanet. From a PDN’s standpoint, the disadvantages of a datagram network usually out¬ weigh its advantages. PDNs depend upon per-call accounting records to generate customer billing information. With a datagram network, it would be extremely dif¬ ficult to construct and reconcile a per-user accounting record with entries generated

48

INSIDE X.25: A MANAGER’S GUIDE

by every packet flowing across the network. Also, the routing time of a datagram within a packet switch may actually take longer than that of a virtual circuit con¬ nection, since a look-up in the routing table has to be performed for every packet. The datagram’s lack of guaranteed packet delivery and error control also poses a marketing problem for PDNs, especially those trying to emphasize the high quality and reliability of their service. Lastly, datagrams offer no mechanism for flow con¬ trol, either on an end-to-end or node-to-node basis. This can lead to the depletion of buffers and subsequent congestion of intermediate nodes.

Centralized versus distributed routing From the previous simplified description of virtual circuit routing, little imagina¬ tion is required to realize that a PDN must manage on the order of thousands of active Logical Channels at any given instant. In practice, there are wide variations among PDNs and packet-switch manufacturers as to the most efficient and reliable method of accomplishing this. The simple routing techniques that may be effective for small, private, packet-switched networks often do not succeed in meeting the demands of a large-scale PDN. Several basic philosophies on routing have been developed over time. Research¬ ers and scientists have dreamt up literally dozens of routing algorithms, often with creative names like the “hot potato algorithm,” “selective flooding,” and “delaybased single-path distributed adaptive per-packet routing”3. The term routing algorithm is not as threatening as it might sound. All packet switches input packets and direct them to an output link. The routing algorithm is nothing more than the decision process used to determine which of several output links is best. Routing control may be centralized or distributed. In centralized routing, all nodes periodically report on network conditions to a central processor. This lets the central processor see the entire network and compute the best path from any node to every other node. Tymnet uses a centralized processor, called a Supervisor, for both security and routing. The actual route of a call in Tymnet is established by a special packet, called a Needle, which is created by the Supervisor. The needle contains a network map in the form of a node list. Beginning at the source node, it threads its way through the network following this map. Data packets follow the virtual circuit “groove” left by the Needle. . In distributed routing, each node has its own routing table and decision-making authority. This distribution of intelligence eliminates the possibility that any sin¬ gle-point failure could bring down the whole network.

Static versus dynamic routing Virtual circuit routing may be either static or dynamic. Also known as fixed or di¬ rectory routing, static routing establishes a predetermined route for every possible

CHAPTER 4: BOTH SIDES OF THE CLOUD

FIGURE 4.9

49

Fixed Routing from DTE A to DTE B Using Destination Address

Destination Address = 123

A’s ROUTING TABLE

D’s ROUTING TABLE

LINK #

ADDRESSES

LINK #

ADDRESSES

1

110-119

3

110-119

2

120-129

5

130-139

3

130-139

6

140-149

4

140-149

9

120-129

C’s ROUTING TABLE

E’s ROUTING TABLE

LINK #

ADDRESSES

LINK #

ADDRESSES

2

110-119

7

140-149

5

120-129

8

130-139

8

130-139

9

110-119

10

120-129

DTE-to-DTE call through the network. In the event of a disruption or failure at some point in that route, a predefined secondary or alternate route is also available. Static routing is usually the simplest and least expensive approach. Each network switching node contains its own independent set of routing tables. When it receives a Call Request packet, each node checks the called address and does a simple lookup in its tables to select the proper route (Fig. 4.9). In the case of a small net¬ work, these tables may be built and loaded manually. Larger networks may create and load these tables from a centralized database. Static routing tends to neglect the important considerations of bandwidth, throughput, and transit-delay management. Switches that use static routing algo-

50

INSIDE X.25: A MANAGER’S GUIDE

rithms do not ‘learn” about changes to the network. However, they can perform simple load balancing over multiple lines. Dynamic routing algorithms recognize that the conditions within a network are in a state of constant change. Some of these changes are predictable; others are not. Predictable network events include time-of-day variations in network traffic, such as when the work force arrives and logs on in the morning. Other changes affect overall network throughput requirements, as when traffic shifts modes from in¬ teractive during the day to batch file transfer at night. Unpredictable events include intermittent circuit problems, total link failures, power outages, and switch conges¬ tion. Due to these constant changes, the best path through a network may vary even over a relatively short time period. Dynamic routing can adapt “on the fly” to all those changes, among others. One version of dynamic routing could assign a cost value based on circuit bandwidth, link loading, delay, or throughput to every link in the network (Fig. 4.10). The number of hops from node to node is also given a weighted value. The optimum path is the one with the overall lowest cost between end-points. Other variations on this method could set a cost for each node as well. If a node be¬ comes congested, its cost could be increased, thereby forcing a new route. A variation of dynamic routing is distributed adaptive routing. Each node in the network regularly exchanges route-status information with its adjacent nodes. A node can time-stamp link delays by sending “Ping” packets to its neighbors and measuring the time required for the Ping to complete the round trip. This method is adapts relatively quickly to changing conditions.

Internetworking, gateways and Recommendation X.75 Connecting discrete packet-switched networks is called internetworking. The importance of internetworking has steadily increased in recent years, with requirements originating from both private and public sectors. Most private packet-switched networks maintain gateway connections to PDNs as a means of eco¬ nomically extending their presence to the network’s “thin” parts. Internetworking gateways provide connectivity between networks through the use of virtual circuits. Depending on capacity needs, gateways may employ multi¬ ple physical circuits and support hundreds of concurrent calls. X.25 is the most frequent internetworking mechanism used when connecting pri¬ vate and public packet switched networks. For large-scale applications, as when internetworking PDNs, X.25 has a number of deficiencies, however. So the CCITT has developed Recommendation X.75 as a companion to X.25 to support PDN in¬ ternetworking. The X.75 protocol is implemented in a special gateway node known as signaling terminal equipment or STE (Fig. 4.11). Currently, there are more than 70 PDNs in operation around the world. The use of either X.25 or X.75 gateways permits calls to go beyond the national boundaries of a PTT's own network, effectively creating a single global public data network. The topic of X.75 will be covered at greater length in chapter eight.

CHAPTER 4: BOTH SIDES OF THE CLOUD

FIGURE 4.10

51

Cost-based Routing

DTE B

OO

PATH

= Single hop

PATH LENGTH

PATH COST

A to B, B to D, D to E

3 hops

8

A to B, B to D, D to C, C to E

4 hops

8

A to B, B to E

2 hops

7

A to C, C to D, D to E

3 hops

12

A to C, C to E

2 hops

6

A to D, D to B, B to E

3 hops

11

A to D, D to C, C to E

3 hops

8

A to D, D to E

2 hops

8

4- LEAST COST PATH

The term gateway is a frequent source of confusion. When used in the context of PDNs and X.75, a gateway provides connectivity services and operates only on the lower three OSI layers. This is in contrast to the true OSI gateway that utilizes all seven OSI layers. With our look at the packet-switching the cloud completed, the next several chapters analyze the individual layers within the X.25 Recommendation and dis¬ cuss the protocol operating at each layer.

52

INSIDE X.25: A MANAGER’S GUIDE

FIGURE 4.11

Internetworking

STE = Signaling Terminal Equipment

Notes 'Webster’s Ninth New Collegiate Dictionary, G. & C. Merriam Company, Publishers, Springfield, Mass. 2CCITT, VUIth Plenary Assembly, Malaga-Torremolinos, 1984 3“A Robust Implementation of Routing for X.25 Packet Networks,” Gilbert Falk, BBN Communications Corp., Cambridge, Mass. 02238

CHAPTER

THE X.25 PHYSICAL LAYER

Physical Layer

“The mechanical, electrical, functional, and procedural charac¬

teristics to activate, maintain, and deactivate the physical link between the DTE and the DCE. ”l

In simplest terms, the Physical Layer (Figure 5.1) is responsible for the transmis¬ sion of raw bits of data across some physical medium. The X.25 Physical Layer does not specify which medium to use, but only establishes a set of rules governing the interface between the DTE and DCE. Most commonly, this X.25 interface is over a copper, leased-line connection using the Public Switched Telephone Net¬ work (PSTN) to connect to a Public Data Network. But it’s not necessarily so. For higher speeds, for example, AT&T’s Dataphone Digital Service (DDS) — and similar services from other common carriers — provide point-to-point fullduplex transmission at data rates of 2.4, 4.8, 9.6, and 56 kbit/s through copper or optical fiber or the atmosphere. And as optical fiber cable becomes more eco¬ nomical and readily available, its use for X.25 will undoubtedly increase. The physical interface familiar to most users is prescribed in the Electronic Industries Association’s standard RS-232 for computer-modem connections. Al¬ though each layer of the three-layer X.25 standard is based on international CCITT standards, rather than the more provincial EIA standards, the characteristics of RS-232 will serve to illustrate those common to all Physical Layers. These characteristics may be divided into four distinct categories; physical (or mechanical), electrical, functional, and procedural. The physical specification of RS-232 assigns signals or circuits to connector pins, recommends cable lengths, and prescribes which equipment uses the female connector (the DCE). (A common misconception also is that RS-232 prescribes a physical connector type and dimen53

54

INSIDE X.25: A MANAGER’S GUIDE

FIGURE 5.1

PHYSICAL LAYER INERFACE

TRANSMISSION MEDIA

sions. It does not. The misconception arises from the fact that the DB-25 connector (see Fig. 5.2), because it is rugged and compact, has won near universal accep¬ tance in the marketplace for use with RS-232. Unlike its mechanical specification, the electrical characteristics of RS-232 are well defined. RS-232 is an unbalanced electrical interface using a single line, refer¬ enced to a shared electrical ground, for each signal. Unbalanced interfaces are effective for only short distances and relatively slow data rates because the electrical waveform for each signal deteriorates rapidly at higher speeds and longer dis¬ tances. The normal distance limit for RS-232 is 50 feet, with speed restricted to under 20 kbit/s; use of shielded, low-capacitance cable can extend this distance comfortably to several hundred feet, however. Unbalanced electrical interfaces are also more susceptible to ground shifts and electrical noise which can impair data accuracy. However, the accuracy of data transmission is the function not of the Physical Layer but of Layer 2, the Data-Link Layer.

FIGURE 5.2

RS-232C Female Connector (DB25) X.21 bis

o—

SECONDARY TRANSMITTED DATA

—o 14

TRANSMIT CLOCK

r\

pppciwc pi npu' I1NASSIGNFD SFCONDARY RFOIJFST TO SFNO DATA TFRMINAL RFADY SIONAI

ODAI ITY DFTFCTOR

RFCFIVFD DATA

r\

3

16

r\

r\

4

17

r\

rs

5

18

r\

rs

6

19

r\

n\

7

20

r\

rs

8 9

22 rs

23 EXTERNAL Cl OCK

r\

24 unassigned

RFOIIFST TO SFNO Cl FAR TO SFND DATA SFT RFADY SIGNAI

GROUND

DATA CARRIFR DFTFCT RFSFRVFD

21 RING INDICATOR DATA RATF SFI FCT

TRANSMITTED DATA

2 15

SECONDARY RFCFIVFD DATA

PROTECTIVE GROUND

1

r\

Rccppwpn

10 r\

IINASSIGNFD

11

rs

SFCONDARY DATA CARRIFR DFTFCT

12 25

r\

13

SFCONDARY Cl FAR TO SFND

CHAPTER 5: THE X.25 PHYSICAL LAYER

55

The logical state of each signal in RS-232 is represented by a voltage transition in either the positive or negative direction. A voltage from +3 to +15 volts is regarded as a binary 0. This is the SPACE state, with logical CONTROL ON. Con¬ versely, levels of -3 to -15 volts are in the MARK or binary-1 state, with logical CONTROL OLE (Pig. 5.3). Voltage levels in the transition region between +3 and -3 volts are regarded as undefined. This 6 volt boundary region or buffer zone may diminish even more as cable length and/or ground potential increases, resulting in the possible misin¬ terpretation of signals. Each circuit or individual wire in an RS-232 interface performs a specific func¬ tion. As related to the requirements of X.25, these functions may be grouped into four distinct categories: Ground, Data, Control, and Timing. RS-232 also describes a Secondary channel, often used to pass low-speed modem-diagnostic information, but this capability is not directly related to the X.25 Recommendation. Table 5.1 shows the functional grouping of all 25 pins and their EIA-circuit abbreviations, as well as the equivalent CCITT circuit designations (also refer to Fig. 5.2). Although a DB-25 connector may have 25 pins, not all of these pins are used or even defined in the RS-232 specification. Pins 11,18, and 25 are unassigned, while pins 9 and 10 are reserved. (In RS-232-D, Pin 18 is for Local Loopback and Pin 25 is for Test Mode; Pins 9 and 10 are reserved specifically for testing.) A pin-by-pin description of RS-232 would lead the unsuspecting to believe that this interface is used by every equipment vendor in the same way. But time and experience have proven that RS-232 interface compatibility between manufacturers is still a major problem area. While RS-232 does address the need for DTE to DCE communications, the many DTE to DTE needs, such as computer to terminal com¬ munications, are left for each manufacturer to meet as it sees fit. Flow control, or the throttling of data between the receiver and the sender, is another somewhat contentious issue. There are two types of flow control; in-band or software flow control and out-of-band or hardware flow control. In-band flow

FIGURE 5.3

RS-232 Voltage Transition Levels

CONTROL ON, “SPACE STATE”, LOGICAL 0 —... . ..*---+ 15V

----- r . . . .

: rrrrr

+ 3V

-15V CONTROL OFF, “MARK” STATE, LOGICAL 1

56

INSIDE X.25: A MANAGER’S GUIDE

TABLE 5.1 FUNCTION

RS-232C Primary Pin Designations PIN#

CCITT

EIA

ABBREV

DESCRIPTION

DIRECTION

1

101

AA

GND

PROTECTIVE GROUND

BOTH

7

102

AB

SG

SIGNAL GROUND

BOTH

2

103

BA

TD

TRANSMITTED DATA

TO DCE

3

104

BB

RD

RECEIVED DATA

TO DTE

4

105

CA

RTS

REQUEST TO SEND

TO DCE

5

106

CB

CTS

CLEAR TO SEND

TO DTE

6

107

CC

DSR

DATA SET READY

TO DTE

20

108.2

CD

DTR

DATA TERMINAL READY

TO DCE

8

109

CF

DCD

DATA CARRIER DETECT

TO DTE

15

114

DB

TX CLK

TRANSMIT CLOCK

TO DTE

17

115

DD

RX CLK

RECEIVE CLOCK

TO DTE

GND

DATA

CONTROL

TIMING

Ground

Pin 1 is Protective, Chassis, or Shield Ground and, when present, is used to minimize electrical noise by connecting to one end of the shield on a shielded cable. Pin 7 is Signal Ground, and serves as the common electrical ground or reference point for all other signals. Pin 7 completes the electrical path for the other signals and must be connected at both ends.

Data

The serial-binary-data bit stream is sent on Pin 2 (Transmitted Data or TD) and received on Pin 3 (Received Data or RD). The di¬ rection of data flow on these pins is always from the perspective of the DTE. Data leads on DCEs are reversed, transmitting on Pin 3 and receiving on Pin 2. Pins 2 and 3 form the primary com¬ ponent of the physical layer and the only circuits that normally convey actual information data. The role of all other signals is in support of the bit stream transmitted on this pair of circuits.

Control

There are five control circuits. They function only when in the log¬ ical ON state and serve to pass control states or status conditions between DTE and DCE. Data Set Ready (DSR, Pin 6) originates at the DCE and tells the DTE that the modem is powered on, not in test mode, and connected to a communications channel. DSR’s counterpart, Data Terminal Ready (DTR, Pin 20), conveys a simi¬ lar powered-up and ready status to the DCE. Request to Send (RTS, Pin 4) is raised when the terminal (DTE) operator wants to send data. The DCE responds affirmatively to this request by rais¬ ing Clear to Send (CTS, Pin 5). Received Line Signal Detector, usually referred to as Data Carrier Detect or just CD (Pin 8), indi¬ cates that the modem is receiving a good carrier tone on the trans¬ mission line. In the case of synchronous modems, having CD ON also means that the local modem is synchronized with its counter¬ part at the far end of the circuit.

Timing

Pins 15 and 17 are used by synchronous modems to convey tim¬ ing information. These modems have internal clock generators

CHAPTER 5: THE X.25 PHYSICAL LAYER

57

that output a highly stable square wave or clock signal on Pins 15 and 17, Transmit Clock and Receive Clock, respectively. The syn¬ chronous DTE uses these clock signals to ensure that the sam¬ pling of each bit occurs at the proper instant to determine whether that bit is a binary 1 or 0. A synchronous data stream, such as X.25’s level-2 protocol, does not require individual start and stop framing bits around each character for synchronization, as in an asynchronous protocol.

control uses special control characters or bit patterns sent by the receiver and im¬ bedded in the normal data stream to notify the transmitter to slow down. Out-ofband flow control uses hardware-control leads to the same purpose. X.25 places the primary responsibility for flow control in the software of Layers 2 and 3. The final aspect of the physical layer deals with establishing a set of procedures for orderly circuit use. Such procedures may, for example, describe the sequence of events, on a pin-by-pin basis, necessary to begin passing data between a pair of modems. The actions taken by the RS-232 interface upon the loss and reestablishment of the Carrier Detect signal illustrate one such procedure. In effect, the Physical Layer is continuously monitoring the physical circuit for failures. Should a failure occur, as in a loss of carrier, the appropriate DCE and/or DTE is notified by the control signals. Once a solid basis for bit transmission on the physical level is established, the higher-level functions can occur.

X.21 versus RS-232 versus X.21 bis In its X.25 Recommendation, the CCITT describes the Physical Layer in two brief pages. And, surprisingly, the CCITT’s first choice for a physical interface is not the EIA’s RS-232 recommendation, but rather its own X.21 specification. That’s surprising because X.21 is neither well-known nor popular; in the United States, the use of X.21 is virtually nil. X.21 anticipates the day when our analog, circuitswitched telephone network will be replaced by a fully digital circuit-switched net¬ work. X.21 is intended to deliver a “digital” dial tone to customer premises, and with the advent of the Integrated Services Digital Network, that delivery day may never arrive (see Chapter 16). Recommendation X.21 is titled: “Interface Between Data Terminal Equipment (DTE) and Data Circuit-Terminating Equipment (DCE) for Synchronous Operation on Public Data Networks.”2 X.21 has several notable characteristics, and its specifications actually describe circuit-switching functions all the way to the Net¬ work Layer, but X.25 only uses the physical-interface specifications. Rather than using the 25-pin connector commonly associated with RS-232, X.21 calls for a compact 15-pin connector (Fig. 5.4). Only six signals plus ground are

58

INSIDE X.25: A MANAGER’S GUIDE

FIGURE 5.4

15 PIN Connector Used For X.21 ISO 4903

normally used: Signal Ground (DTE common return), Transmit, Receive, Control, Indication, Signal Element Timing, and Byte Timing (optional). In unbalanced form, X.21 supports data rates up to 9.6 kbit/s. When used as a balanced electrical interface, with a separate pair of wires for each signal, data rates up to 64 kbit/s are possible. This is in sharp contrast to RS-232’s 19.2-kbit/s limit. At 64 kbit/s, uncompressed digitized-voice transmission becomes an option.

Call Control Procedures under X.21 The procedures behind X.21 are referred to as a “finite-state machine.” Applying the telephone-call analogy, X.21 is used between DTE and DCE to take the phone off-hook, give dial tone, dial the phone number, etc. Each one of these events is considered to be a single state. There are a total of 24 of these states, ranging from a DTE or DCE Ready state to Call Request and Call Accept states and, finally, to the Call Collision state. Also incorporated into X.21 are sophisticated automatic calling and call progress fea¬ tures. The writers of RS-232 never aspired to this degree of sophistication; it has no equivalent functionality. Control of these X.21 states is achieved with only four signals; Transmit (T), Control (C), Receive (R), and Indication (I). These signals work in pairs, so that T and C act in one direction and R and I handle the other. Leads T and R pass serial data, while leads C and I are binary levels, either On or Off (Fig. 5.5).

FIGURE

5.5

X.21 DTE/DCE Interface

SIGNAL GROUND —

TRANSMIT (T) V

CONTROL (C) _w

RECEIVE (R) INDICATION (1) SIGNAL ELEMENT TIMING hit

BYE TIMING (OPTIONAL) 4—