SX.25 is a STREAMS implementation of the X.25 network standard recommended by the CCITT. Silicon Graphics workstations and servers running SX.25 can establish virtual circuit connections to other hosts in X.25 wide area networks (WANs) or local area networks (LANs) that operate by CCITT standards. In addition to this basic connection service, SX.25 also supports PAD, Transmission Control Protocol/Internet Protocol (TCP/IP), the UNIX®-to-UNIX Copy Program (UUCP), and a network layer interface for developing custom applications.
SX.25 implements these CCITT recommendations:
X.3/X.28/X.29 packet assembler/disassembler program (pad).
X.25 Level III, `80, `84, and `88 versions. The `84 and `88 versions support basic (modulo 8) and extended (modulo 128) packet sequence numbering.
X.25 Level II LAPB, `80, `84, and `88 versions. The `84 and `88 versions support basic and extended packet sequence numbering.
SX.25 also supports the following functions:
X.25 is a communication protocol for LANs and WANs that comprises a series of functional layers. Each layer operates in a prescribed way, implementing its own protocol. Because layer functions are standardized, equivalent layers of other protocols can be substituted for X.25 layers, increasing the services that the network offers (see Figure 1-1 for an illustration of the protocol layers as implemented by SX.25). The combination of protocol layers implementing a particular network function is referred to as a protocol stack.
Data is exchanged across an X.25 LAN or WAN by means of packet switching. Networks that implement the X.25 protocol are referred to as packet-switched data networks (PSDNs), or more generally as public data networks (PDNs). Although many widely known PDNs are public networks, such as the European telephone and telegraph agencies, many PDNs are private service providers, such as Tymnet in the United States. PDNs offer a commercial service to the organizations or individuals who subscribe to them.
The CCITT published a series of technical specification for packet switching (the X series) in 1976, 1980, 1984, and 1988. These specifications came to be known as the X.25 recommendations. Most public and private X.25 network service providers conform to the 1980, 1984, or 1988 X.25 recommendations. The International Organization for Standards (ISO) has also published X.25 protocol standards: ISO 8208 specifies the standard for packet-level functions, and ISO 7776 specifies the standard for link-level functions (see Figure 1-1).
On packet-switched networks, transactions in which users on one host obtain services on another host are known as calls. During a call, the local and remote hosts operate as data terminal equipment (DTEs): each DTE performs the functions required to send and receive data. Data circuit-terminating equipment (a DCE), to which each DTE is attached, performs the network interface functions that are required, such as establishing and maintaining connections and performing signal conversions (modem functions).
The line connecting an X.25 host to the network is assigned a network user address (NUA) that is used to direct call packets to the host. Hosts with more than one line connected to a network (or multiple networks) require an address for each line. The X.121 standard defines X.25 address formats and is used by the majority of PDNs (see Appendix A for format information).
A connection between a calling DTE and a responding DTE is known as a virtual circuit. One or more virtual circuits can be sustained on a channel, and several channels may be allocated to each physical line on a host. Switched virtual circuits (SVCs) handle calls to an address that the user specifies; SVCs terminate when the call is complete, freeing the channel capacity for other calls. Permanent virtual circuits (PVCs) are dedicated to calls between two designated addresses. PVCs do not use DCE services, but they require the exclusive use of a dedicated channel.
When a user initiates a call to a remote X.25 host, the DTE assigns the call a logical channel, identified by a logical channel number, over which the call is conducted. The responding DTE also assigns a logical channel number for the call, which might be different from that on the calling DTE. Because each DTE includes the call's logical channel number in all packets that it sends, the DCE is able to route the data to its correct destination.
Two-way channels support the flow of data in the inbound and the outbound direction. X.25 networks also support permanent channels for PVCs and one-way channels that allow data flow in a single direction: permanent incoming channels and permanent outgoing channels. The rate at which DTE channels transmit data determines their throughput class.
The function that a packet performs determines the format and contents of the packet. In general, X.25 communications require three types of packets: call request packets, data packets, and call termination packets. The calling DTE and responding DTE have their own version of each packet type. For example, the equivalent of a call request packet (on the calling DTE) is a call accept packet (on the responding DTE).
When the calling DTE sends a call request packet to initiate a call, the responding DTE sends a call accept packet to agree to the connection; the virtual circuit is established at this time. If the call request packet contains a set D-bit (delivery confirmation bit), the responding DTE acknowledges each data packet that it receives. When the D-bit is not used, the window size determines the number of packets that can be sent without a confirmation. When a call is complete, the calling and responding DTE exchange clear-request packets to terminate the virtual circuit.
Either DTE may send interrupt packets to transmit urgent information. The data flow is normally resumed after the interrupt sequence is processed. By contrast, reset packets, which reset the virtual circuit, sometimes clear all data and interrupt packets from the circuit. For this reason, DTEs transmit reset packets only in unusual circumstances.
The maximum size of network packets is set by the X.25 version that a network uses: the 1980 recommendation sets the maximum packet size to 1024 bytes, and the 1984 recommendation sets maximum packet size to 4096. Generally, the size of packets that are actually used on a network is fixed and understood by the DTEs. However, some networks offer an option that allows the DTE and DCE to negotiate the size of packets when the call is placed.
Figure 1-1 illustrates the X.25 protocol layers as implemented in the SX.25 application. Notice from Figure 1-1 that the Internet Protocol (IP) is substituted for upper X.25 layers, and that each application layer is supported by a different combination of layers below it.
Level 1 of the X.25 protocol is the physical layer that governs the transmission of electrical signals on the network. Level 1 comprises the hardware itself, which is referred to as the link, and the device driver that interfaces to the hardware, which is referred to as the port. Figure 1-1 represents the physical level as a LAN and WAN port on the SX.25 host.
Level 2, the data link level, manages access to the hardware channel and the sequencing of data over the channel. The link level prepares information for transmission in units known as a frames. In Figure 1-1, the link-level function is represented by LLC-2, which performs link-level functions in LANs, and LAPB, which performs link-level functions for WAN connections.
Level 3, the packet level, establishes the logical connection between the communicating hosts and controls the flow of information between them. Level 3 transmits information in packets, which contain addressing and control information in addition to data. Figure 1-1 refers to level 3 as the packet level protocol, or PLP, layer.
The application level, (level 7 in the OSI model), supports user and administrative services. Figure 1-1 indicates that SX.25 offers PAD (X.25 user services) and PADD (the PAD daemon), TCP/IP, UUCP, and locally developed user applications at this level. The interface between the application level and the lower level protocols is provided by the IRIX operating system and IRIX networking services.
Each WAN and LAN port on a Silicon Graphics host operates as a DTE. Every port is assigned its own DTE address, which uniquely identifies the port to the network. To SX.25 software, however, the port is considered a subnetwork. SX.25 uses a subnet ID to direct incoming packets internally after the packets arrive. For this reason, every SX.25 port must be assigned both a DTE address and a subnet ID when you configure it for network operation.
The SX.25 configuration file defines the operation of all X.25 network connections on a Silicon Graphics host. The default SX.25 configuration file is /etc/config/snetd.options. You can specify an alternate filename for snetd.options, and you can create multiple configuration files with unique filenames if you choose to.
The SX.25 configuration file contains a record for each configured port on the system. The record contains a subnetwork ID, a network address, and the names of the parameter files to be used to configure the port's protocol stack.
The protocol stack for an X.25 port contains dozens of adjustable parameters that must be set to coincide with the operating parameters of the network to which the port is connected. To make port configuration more efficient, SX.25 provides parameter files that contain the parameter settings used by the vast majority of PDNs. These factory-shipped files make it unnecessary to specify protocol parameters individually, in most cases.
Two files configure the protocol stack for a given port: a packet-level parameter file and a link-level parameter file. When the host's networking applications start, the snetd daemon builds the protocol stack for a port using the parameter files that are specified in the configuration file.
Notice from Figure 1-1 that the LAPB protocol defines link-level functions on WAN ports, and LLC2 defines link-level functions on LAN ports. To accommodate all port configuration possibilities, SX.25 provides three types of protocol parameter files: X.25 parameter files, a LAPB parameter file, and LLC2 parameter files.
An X.25 parameter file specifies the packet-level functions for WAN and LAN ports. These specifications include logical channel assignments, packet and window sizes, timers, and other transmission specifications. Factory-shipped X.25 parameter files implement 1980, 1984, and 1988 X.25 recommendations for DTEs and DCEs. Because the packet-level parameter settings in these files are compatible with the requirements of most PSNs, it is usually not necessary to specify packet-level parameters individually.
To configure a port with a factory-shipped file, you select the file from the X.25 Parameter File list during the port configuration procedure (see Figure 4-7). You can check the settings in any file on this list by opening it with gx25adm (see “The Open Button” in Chapter 4).
If you determine that factory-shipped files are not suitable, you can create custom X.25 parameter files (this process is described in “Creating an X.25 Parameter File” in Chapter 7). Any custom parameter file that you create is added to the X.25 Parameter File list so that you can select it during subsequent port configuration procedures.
A LAPB parameter specifies link-level functions for WAN ports. These specifications include timer settings, window and frame sizes, and other WAN transmission parameters. Information in the LAPB parameter file is passed to LAPB, the IRIX LAP multiplexor that manages port I/O. One factory-shipped LAPB file is included in the SX.25 application. Because the parameter settings in this file comply with link-level requirements of most PSNs, it is usually not necessary to specify link-level parameters individually.
To configure a port with the factory-shipped file, you select the file from the LAPB Parameter File list during the port configuration procedure (see Figure 4-7). You can check the settings in this file by opening it with gx25adm (see “The Open Button” in Chapter 4).
If you determine that the factory-shipped file is not suitable, you can create a custom LAPB parameter file (this process is described in “Creating a LAPB Parameter File” in Chapter 7). Any custom parameter file that you create is added to the LAPB Parameter File list so that you can select it during subsequent port configuration procedures.
An LLC2 parameter file specifies link-level functions for LAN ports. These specifications include timer settings, window sizes, P-bit acknowledgment, and other LAN transmission parameters. Information in the LLC2 parameter file is passed to LLC2, the IRIX LAP multiplexer that manages port I/O. Parameter settings for link-level functions are defined by network media, so the SX.25 application provides a factory-shipped LLC2 parameter file for Ethernet, FDDI, and Token Ring LANs. Because the settings in this file comply with industry standards, it is usually not necessary to specify LLC2 parameters individually.
To configure a port with a factory-shipped file, you select the file from the LLC2 Parameter File list during the port configuration procedure (see Figure 4-10). You can check the settings this file by opening it with gx25adm (see “The Open Button” in Chapter 4).
If you determine that the factory-shipped file is not suitable, you can create a custom LLC2 parameter file (this process is described in “Creating an LLC2 Parameter File” in Chapter 7). Any custom parameter file that you create is added to the LLC2 Parameter File list so that you can select it during subsequent port configuration procedures.
SX.25 supports connections to Internet Protocol (IP) networks, allowing users on the SX.25 host to use TCP/IP network services. It also supports an IP host map, which allows users to enter hostnames rather than addresses in their connection requests. The SX.25 implementation complies with RFC 877.
In IP/X.25 internetworks, X.25 networks function as subnetworks of the IP network. X.25 connections to IP networks are implemented by means of the IP to X.25 encapsulation driver (IXE), which links IP networks with the X.25 stack (see Figure 1-1). IXE transmits IP datagrams between X.25 nodes over an X.25 virtual circuit. The remote X.25 node may be on the same network or on a different one.
SX.25 maintains an internal address table called the IXE map. The IXE map holds address pairs that associate the IP address with the X.25 address of a node. The IXE database is consulted when an outgoing IP packet requires a new connection and when incoming X.25 connections contain IP packets. Requests to send IP packets to X.25 nodes for which there is no IXE map record result in an error.
When an incoming connection arrives at the X.25 layer and is destined for the IXE driver, the X.25 address must match an entry in the IXE map. If no matching entry is located, the connection is refused. In general, if an incoming connection has been established, the same connection is used for outgoing datagrams to the calling party.
For each name and address pair, you can specify the packet and window sizes to be requested on connections and the number of concurrent virtual circuits that are allowed. The default maximum number of entries in the IXE map is 100.
When operating in DDN mode, IP to X.25 address mappings are not normally obtained from the internal address table. This means that in normal operation, only the default X.25 facilities are available. It is possible, however, to use different facilities, packet and window sizes, and so on. To do this, you must enter the information into the internal address table yourself. This means entering the correct X.25 address, derived from the DDN address; refer to the Defense Data Network X.25 Host Interface Specification.
The basic connection service on an SX.25 host allows its users to run PAD applications. To simplify the connection process for users, you can create a PAD map. This map is a database of X.25 hostnames, addresses, and connection parameters that automatically supplies addresses and connection parameters in PAD connection requests; users supply only the remote hostname in their pad commands. The PAD map can also contain host aliases for situations in which a host is known by multiple names.
SX.25 hosts offer PAD services to network users by means of PADD, the PAD daemon service. The PADD server listens for incoming requests from PAD users and creates a login process that supports the virtual terminal connection. If you wish, you can restrict the X.25 hosts to which the SX.25 host can supply PAD services by creating a list of listen strings. The listen strings list contains the hosts addresses from which PADD accepts connection requests.
When the gx25adm utility starts, the primary window is displayed (shown in Figure 3-1). The menus offered on the primary window provide access to all SX.25 configuration functions and the files that store configuration information.
Figure 1-2 illustrates how gx25adm menus are used to access configuration functions and the files that support them.
WAN and LAN ports are configured using the WAN and LAN port configuration windows (see Figure 4-7 and Figure 4-10). These windows provide access to the SX.25 configuration file, which contains a record for each configured port on the host (see “The SX.25 Configuration File” for details). You open the configuration file using options on the File menu (shown in Figure 3-2), then you select a port to configure. Selecting a port displays the WAN or LAN port configuration window and opens the configuration file record for the port.
The WAN and LAN port configuration windows also provide access to the protocol parameter files for a given port (see “Protocol Parameter Files”), but these files are not normally opened during a configuration session. You open protocol parameter files only if you plan to create customized versions of these files (see “Evaluating SX.25 Parameter Files” in Chapter 2).
The Edit menu (shown Figure 3-3) provides access to the optional features that you can add to an SX.25 host or to individual ports on the host. SX.25 host options include IP and X.25 host maps, lists of the PADD services and subnetworks on the host, and IRIX kernel parameters for the SX.25 application. This information is stored in database files that are accessed when you choose an Edit menu option.
Individual port options include adding IP network connections and PVCs to the port. When you configure an individual port option, the configuration information is recorded in the SX.25 configuration file. For this reason, you must open the configuration file from the File menu before you use these Edit menu features.
The gx25adm utility provides two support functions: a network function that stops and starts IRIX network services on the host, and a kernel function that rebuilds the IRIX operating system kernel. Support functions are accessed from the Action menu (shown in Figure 3-4).