Although proprietary protocols and arcane service-ordering procedures still stand in ISDN's way, there are promising signs of progress
Jeffrey Fritz
One of the biggest obstacles to WAN interoperability has been the U.S. government. A decade ago, it broke up AT&T's Bell System to create the seven RBOCs (Regional Bell Operating Companies). At the time, the Bell System was a model of interoperability. Had the government not intervened, using ISDN equipment and services might be equally straightforward today.
The diversity that was the aim of the AT&T breakup hasn't been a totally bad thing; telephone devices are now available from many sources at competitive prices. But with that diversity comes a loss of i
nteroperability. No longer is there a single, unified telephone network; now there are seven large networks and thousands of small- and medium-size telephone operations. These diverse networks offer radically different data services at widely varying prices with limited interconnection. Some carriers offer digital services now, but others haven't a clue as to when they will be able to provide such services.
Pity the poor administrator of an enterprise network who must deal with a plethora of state tariffs; widely varying carrier capabilities; and a myriad of different local telephone companies, regional operating carriers, and interexchange carriers. Providing ubiquitous communications in such an environment is a nightmare.
Too Many Flavors
This confusing array of choices comes just as telephone carriers are deploying digital services such as ISDN, a telecommunications technology able to provide video, high-speed data, and voice communications simultaneously over a single telephone line.
Given that national and international standards bodies spent years developing ISDN, users might reasonably expect consistent and interoperable deployment. However, that's not the case.
The problems are many. There are too many flavors of ISDN. Users buying ISDN equipment and services face an intimidating array of options, and poorly trained telephone sales representatives can make matters worse. Bridges and terminal adapters often don't interoperate, telephone central-office switches are complex to configure, and digital services are difficult to order.
Moreover, if you decide to move your ISDN equipment to a new location, the ISDN line has to be configured in advance. It typically takes days for a carrier to process such an order. The ability to take an ISDN bridge on a trip, connect it to the local hotel phone system, and access your corporate network is a long, long way off. But network users need that kind of functionality now.
The Secret Words
To set up a line for your ISDN ne
twork device, you need to know telco-speak, including terms such as terminal type, SPID (Service Profile Identifer), and bearer service. Users are expected to understand highly technical issues that, for the most part, even telephone-company technicians don't fully grasp. This intimidates the user who just wants to hook up to the network and use it.
Before any ISDN devices can be used, the telephone line must be preconfigured by the carrier for each specific ISDN device. This process is called translation. Translations are much like network configuration files, but they are even more complex and cumbersome (see the table on page 207). Get just one translational entry wrong, and the ISDN line likely won't work. The end user is expected to tell the telephone companies how to translate the central-office telephone switch for each device. Moreover, ISDN vendors expect users to know what kind of switch their local operating company uses in the local exchange.
A Simpler Way to Order ISDN Service
The NIU-F (North American ISDN User's Forum) and the COS (Corporation for Open Systems) are both working to simplify the ISDN ordering process. Both organizations have proposed, and are now working on, standardized phrases that can be used to order common translation schemes.
When a user purchases an ISDN device, he or she is provided with a phrase that must be reported to the telephone-company order taker. The intent is that the user will request translations based on terms such as Intel Blue and Nynex A. These code words are supposed to make translations easier for end users. Unfortunately, unless local telephone carriers can effectively train their business-office personnel in the use of these terms, a user's request for Byte Yellow could be met by a deafening silence.
A better way to configure lines is to let computers do what they do best and avoid the telephone-company translation process altogether. In computer networking, it's common for devices to bootstrap themselves into operation.
A new router, for example, may boot with a standard configuration that allows a minimal amount of communication with a configuration server. Once basic communications have started, the server downloads the specific configuration parameters into the network device.
In an ideal world, your new ISDN Ethernet bridge would come with an EPROM that stores the ISDN line translations for that
device. When you connect the bridge to an ISDN line, it would come up in a low-level signaling mode that allows configuration communications between the central-office ISDN switch and the bridge. Once the communications link was established, the bridge would begin to send translation information to the switch, which would use the information to configure the ISDN line to the specific translation parameters that the device required. Other than plugging the bridge into the ISDN line, the user and the local carrier wouldn't be involved in the translation process.
This scenario is entirely feasible today. Indeed,
some switch vendors have built this capability into their ISDN switches. But don't expect your local carrier to tell you about this feature. Because they must pay an extra charge to activate it, thus far they have tended not to advertise its existence.
The ISDN Archipelago
Until recently, data calls worked only within the local switch. Data couldn't travel between different vendors' switches, or even between similar switches in different locations. These islands of data connectivity presented a terrible problem for corporations trying to use ISDN for enterprise WAN connectivity.
Fortunately, Bellcore, the research arm of the seven RBOCs, created a standard called N-ISDN (National ISDN). This standard addresses interswitch compatibility issues well. For instance, it is now possible to place circuit-switched data calls between different vendors' switches, and many ISDN devices can easily be moved from one switch to another with minimal reconfiguration. Telephone carriers still must deploy
the signaling standards necessary to connect the various ISDN switches together.
While recent progress on this front has been encouraging, one big problem remains unsolved. Vendors have deployed ISDN network devices using proprietary communications protocols. That makes it impossible for, say, vendor A's ISDN bridge to connect to vendor B's ISDN bridge. A similar problem exists with routers. Network users are forced to stay within one vendor's product line; WAN interconnection involving heterogeneous networks can be very problematic. As a result, strict corporate purchasing requirements are necessary to ensure that a remote user's network device will work with an enterprise network device.
PPP to the Rescue
Fortunately, a white knight has appeared, in the form of the Point-to-Point Protocol, or PPP. The IETF (Internet Engineering Task Force) has issued a series of RFCs (requests for comment) governing PPP. One of these, RFC 1618, describes PPP over ISDN.
While the IETF continues to
work on the PPP RFCs, the NIU-F's ENDIF (Enterprise Network Data Interconnectivity Family) has been working on an implementation agreement for PPP over ISDN. ENDIF has provided major networking vendors with the opportunity to work together to produce agreements for core WAN ISDN technology. The ENDIF's work closely mirrors the IETF's PPP RFCs.
A major breakthrough occurred last June at the National Institute for Standards and Technology in Gaithersburg, Maryland. Seven major network vendors, all ENDIF participants, came together to demonstrate interoperability between ISDN devices using MAC (media access control) layer bridging and IP routing. For the first time, each vendor was able to connect and pass real user data to each other and to an internet. This is an encouraging development that--along with automatic line configuration and interswitch, intercarrier compatibility--will help usher in the era of plug-and-play interoperability for ISDN network devices.
Indications are that installing an
d making ISDN WAN connections will, in a few years, be as easy as picking up the telephone. Network users and managers require, and expect, no less.
Typical ISDN Translations Table
Settings shown are examples for AT&T 5ESS Custom and National-1 ISDN.
AT&T FUJITSU COMBINET
7506 SRS-410 CB-400
ISDN TERMINAL ETHERNET
DEVICE TYPE PHONE ADAPTER BRIDGE
DSL TN Digital subscriber-line
phone number 5551234 5555678 5559123
D service Type of service on D channel SX S S
B1 service CSV, CSD, or DMD? DMD CSD CSD
B2 service CSV, CSD, or DMD? DMD CSD CSD
NT1 type Network-terminator type AULC AULC AULC
USPID User-service profile
identifier 0155512340 0155556780 0155591230
MAXB CHL Maximum number of B channels 2 2 2
CKT TN Circuit telephone number 5551234 5555678 5559123
TERMTYP Terminal type TYPEC TYPEE TYPEC
DISPLAY Is there an LCD display
on device? Yes No No
CSV Circuit-switched voice
on device? 1
CSV CHL Circuit-switched voice
channel(s) Any
CSD Circuit-switched data
on device? 2 2 2
CSD CHL Circuit-switched data
channel(s) Any Any Any
CSD LIMIT Circuit-switch
data-channel limit 1 2 2
SEND PKTSZ Send packet size 128
SEND PKTWD Send packet window 3
RCV PKTSZ Receive packet size 128
RCV PKTWD Receive packet window 3
DSL TN: Actual telephone number of the device. Some switches support one number for both voice and data. Other switches require separate numbers for voice and data channels.
SX: S stands for Q.931 signaling, and X stands for X.25 packet service.
B1, B2 SERVICE: Indicate if the device supports CSV , CSD , or DMD services. This allows the user to specify which service should be on which channel. DMD tells the switch to be prepared to offer either voice or data on the channel, depending on what the user device requests when it sets up the call.
DMD: Stands for circuit-switch service on (user) demand.
AULC: ULC stands for universal line card. AULC is a 2B1Q ULC.
TERMINAL TYPE: Terminal type varies by device type and central-office switch. It tells the switch about the internal ``smarts'' of the device.
USPID: A unique identifier assigned to the ISDN device. This setting is important when several devices are connecte
d to the same ISDN line in a passive-bus (or multipoint) configuration.
TYPEC: TYPEA services are dumb and depend on the central-office switch for most processing of user events. TYPEC and TYPEE are smarter devices that are capable of handling call forwarding, automatic callback, and other features.
CSD CHL: Indicates which B channel can accept circuit-switched data. Notice that most devices indicate Any, meaning that it doesn't matter to the user device.
SEND PKTSZ: SEND PKTSZ sets the transmit-packet size for D packet service.
SEND PKTWD: SEND PKTWD sets the transmit-window size for D packet service.
Notice that there are also related settings for receive-packet size and window as well. These configurations are usually set to the default values and are not changed unless there is some obvious reason for doing so.
SEND PKTSZ These devices don't
SEND PKTWD offer packet
RCV PKTSZ service on the
RCV PKTW
D D channel.
Jeffrey Fritz is a telecommunications engineer responsible for the design and management of data communications for West Virginia University, including its ISDN applications lab. He is also the author of Sensible ISDN Data Networks (WVU Press, 1992). You can contact him on the Internet at
jfritz@wvnvm.wvnet.edu
or on BIX c/o ``editors.''
Clearing Away the ISDN Roadblocks
