Ref: 99980059 Title: Bridge Implementation of X.25 Date: 2/1/86 Copyright 3Com Corporation, 1991. All rights reserved. In the Bridge X.25 implementation, each X.25 virtual circuit is mapped into a virtual port. A virtual port is a network addressable unit and thus visable to the network users. Each GS/1 or CS/1-X.25 can support up to 48 virtual ports. Since each GS/1 or CS/1-X.25 may have up to eight physical lines, these 48 virtual ports will be dynamically distributed among all lines. If the connection request is initiated from the X.25 interface, the selection of either X.25 service or X.29 PAD service is accomplished depending on the packet type. If the connection request is initiated from the Ethernet interface, the selection of X.25 service or PAD service depends on the type of initiator. If the initiator is a CS/1-X.25, the X.25 service is selected for host-to-host communication. Otherwise, the PAD service is provided for terminal-to-host communication. A case-by-case explanation of different possible combinations of connections for Terminal-to-Host and Host-to-Host communications is described in the following sections. .h1;Terminal-to-Host Communication The following examples illustrate the call establishment from a terminal to an X.25 host. Example 1: A user at terminal (1) on the local Ethernet can use the Connect command of the CS/100 user interface to connect to X.25 host (1) on the same LAN using the following command: Connect host1 where host1 is a clearinghouse name defined on the CS/100 as follows: host1 = %!# Example 2: This example uses the Connection Service of the GS/1. A user at terminal (1) on the local Ethernet can connect to X.25 host (3) across a PDN in a way similar to example 1 by using the following command: Connect host3 where host3 is a clearinghouse name defined on the CS/100 as follows: host3 = %!# Example 3: This example uses the Interconnection Service of two GS/1s. A user at terminal (1) on the local Ethernet can establish a connection to X.25 host (4) on the remote Ethernet using the following command: Connect host4 where host4 is a clearinghouse name defined on the CS/100 as follows: host4 = & %!# In this case, the connection request is passed transparently to the user through two GS/1s. Example 4: A user at terminal (1) can establish a connection to host (5) on the remote Ethernet using the following command: Connect host5 where host5 is a clearinghouse name defined on the CS/100 as follows: host5 = &%! Example 5: A user at terminal (2) connected to a PAD can access X.25 host (1) using a connection pass-through by defining a clearinghouse as follows: xxxx = %! where xxxx is an X.25 address of the GS/1 (1). This clearinghouse can reside on either CS/1-X.25 (1) or GS/1 (1). In this example, the terminal user initiates the call to the GS/1 through its PAD by specifying GS/1 (1)'s X.25 address. In addition, a user at terminal (2) can connect to GS/1 (1) to access the Bridge User Interface and select the destination resource. .h1;Host-to-Host Communication The following examples illustrate a call establishment from one host to another host. In some applications, in order to use host- to-host communication between hosts not connected to the same LAN, the host applications must properly format the CUDA (call user data area) in the call packet. Most Honeywell hosts require no modifications; other systems may require modification. Example 1: To establish a connection between X.25 host (1) and X.25 host (2), a clearinghouse name must be defined as follows: xxx = %1 where xxxx is host (2)'s X.25 address. This clearinghouse name must reside on CS/1-X.25 (1). This example indicates a turnkey service; therefore, no host modifications are required. Example 2: To establish a connection between X.25 host (3) and X.25 host (1), a connection must first be made with GS/1 (1)'s X.25 address. The X.25 call user data area is used to specify the final destination address of host (1)'s X.25 address. Therefore, the destination X.25 address in the cal request packet from X.25 host (3) will have GS/1 (1)'s X.25 address in it. In order for GS/1 (1) to connect X.25 host (1), a clearinghouse name must be defined as follows: xxxx=&%! where xxxx is host (1)'s X.25 address (xxx must be in the X.25 call user data area). This clearinghouse name must reside on the GS/1 (1). Example 3: To establish a connection between X.25 host (1) and X.25 host (3), the internet address scheme in the call user data area mentioned above should be used. The source X.25 address in the call request packet to X.25 host (3) will have GS/1 (1)'s X.25 address in it, with host (1)'s X.25 address as the source extension in the call user data area. The destination address in the call request packet from host (1)'s X.25 address will have host (3)'s X.25 address in it. In order for the CS/1-X.25 (1) to connect to X.25 host (3), a clearinghouse name must be defined as follows: xxxx=&%! where xxxx is host (3)'s X.25 address. This clearinghouse name must reside on CS/1-X.25 (1). Example 4: To establish a connection from X.25 host (4) to X.25 host (1), one of two approaches can be used. The first approach uses the call user data area and the following clearinghouse names must be defined: xxxx1 = &%! xxxx2 = &%! where xxxx1 is GS/1 (1)'s X.25 address and xxxx2 is host (1)'s X.25 address. The X.25 source address in the call request packet from host (4)'s X.25 address should be host (4)'s X.25 address and the destination address in the call request packet should be GS/1 (1)'s X.25 address. The internet source extension in the use data area should be host (4)'s X.25 address and the destination extension in the user data area should be host (1)'s X.25 address. The X.25 source address in the call request packet should be replaced with GS/1 (2)'s X.25 address when GS/1 (2)'s X.25 address is trying to call GS/1 (1)'s X.25 address. Similarly, to establish a connection from X.25 host (4) to X.25 host (6), the following clearinghouse name must be defined: xxxx3 = &%! xxxx4 = %! where xxx3 is GS/1 (1)'s X.25 address and xxxx4 is host (6)'s X.25 address. These four clearinghouse names must be accessible to local as well as remote Ethernet networks. Alternatively by using the GS/1 Interconnection Service, X.25 host (4) can connect to X.25 host (1) without using the extension addressing. It can directly address host (1)'s X.25 address in the X.25 call packet as it it was on the same Ethernet if the following clearinghouse names are defined: xxxx5 = &! xxxx6 = &%! where xxxx5 is host (1)'s X.25 address and xxxx6 is host (4)'s X.25 address. Similarly, X.25 host (4) can connect to X.25 host (6) using the following clearinghouse names: xxxx7 = %! xxxx8 = &% where xxxx7 is host (6)'s X>25 address and xxxx8 is host (4)'s X.25 address. These four clearinghouse names must be accessible to local as well as remote Ethernet networks. This second approach requires that all hosts on both LANs have unique X.25 addresses. .h2;Bridge User Interface to Support X.3 Parameters X.3 is a set of 18 parameters that provide basic functions performed by the Packet Assembly/Disassembly (PAD) to control an asynchronous terminal. When a connection is established to the host, the host may modify some of the X.3 parameters via the X.29 protocol to the CS/1- X.25. The CS/1-X.25 then modifies the parameters in the Bridge terminal server where the connection is orginally initiated. When a connection is established from the PDN to the Bridge GS/1, the GS/1 will set any necesaary X.3 parameters via X.29 over the PDN. The following X.3 table is divided in four columns. The first column lists the eighteen X.3 parameters, the second column lists the standard CCITT X.3 names, the third column lists the Bridge names that correspond to the CCITT standard, and the fourth column indicates whether or not these parameters are converted by the Bridge X.25 products. TABLE 1 ------------------------------------------------------------------ Para- CCITT Name Bridge Name Bridge X.25 Conversion meter Number 1 Escape to Command ECM Character X.3 value 1 is converted to "CNTL>P"; no conversion for other values. 2 Echo Echo Data None 3 Data Forward Data Forward If parameter 15 (Local Editing) = 1, then value 8 (Editing) is turned on locally and is transparent to the host. As a result, value 8 does not appear in the parameter list when the host performs a "read parameters". 4 Idle Timer Idle Timer Since Bridge's idle timer is based on 1/60 second and X.3 is based on 1/20 second, the Bridge value = X.3 value *3, and X.3 values from 85 to 255 are converted to 255 in Bridge values. 5 Ancillary Flow Control None Device Control From 6 Supression of Inter Action Since prompt service Service Signals signal cannot be suprressed separately from PAD service signal in Bridge environments, X.3 value 5 (4 + 1) is converted to 1 in Bridge values. Bridge uses value 4 to indicate "command Echo/NoEcho". 7 Break Options Break Action Bridge does not support value 2 (RESET). Value 16 is used to indicate FlushVC by Bridge. Output data will be flushed upon detection of a break signal in this case. 8 Discard Output (Data Delivery) None 9 Carriage Return Carriage Return Bridge allows a wider range than the X.3 definition. No conversion. 10 Line Folding (Line Folding) Bridge accepts this parameter but performs no action with it. 11 Binary Speed Baud This is a read only parameter and the host should not try to set this parameter. If a host performs a "read parameter", the Bridge values are converted to X.3 values. 12 Flow Control Flow Control To None PAD by Terminal 13 Line Feed after Line Feed X.3 value 3 (LineFeed CR Insertion insertion after CR from DTE) is not supported by Bridge. 14 Line Feed Line Feed Pad Bridge allows a wider Padding range than the X.3 definition. No conversion. 15 Editing Local Editing No conversion. The Bridge parameter "command editing" is turned on when this parameter is set. 16 Character Delete Erase Character None. 17 Line Delete Line Erase None. 18 Line Display Reprint Line None. Parameters 6, 9, and 14 are defined as port parameters rather than session parameters in the Bridge implementation. After a session is disconnected, these parameters may be different from their default values. If all parameters are exchanged between a Bridge PAD and X.25 hosts, proper conversion is done so that the host will notice any inconsistency. The GS/1 performs the conversion and retains the X.3 value locally in case the host needs to recapture these X.3 parameters. However, any manual manipulation of parameters 6, 7, and 13 after a session has been established with an X.25 host may cause problems when the host tries to recapture these X.3 parameters. In order for parameter 15 (Local Editing) to function properly, the Bridge parameter EOMChar has to be disabled by the user. For the DataForward parameter, parameter 8 (Editing bit) is turned on automatically. This functionality is handled by the conversion routing residing in the GS/1. For communication with non-X.25 hosts, the user should ensure that the Editing bit is turned on in the default DataForward parameter. If parameter 1 (ECMChar) is disabled, users can still return to command mode by pressing the key. Since the BReakAction parameter includes this ECMChar option, the BReakAction parameter should be set up properly to disable the ECMChar. .h1;X.28 and X.29 Support X.28 is a protocol that enables the terminal user to control X.3 functions in a PAD. X.29 is a protocol that enables a remote X.25 host to control X.3 functions. The Bridge Virtual Terminal for X.25 products supports all seven types of PAD messages defined in the X.29 CCITT standard as follows: - Set PAD message (host to PAD) .br;- Read PAD message (host to PAD) .br;- Set and read PAD messages (host to PAD) .br;- Parameter indication PAD message (PAD to host) .br;- Invitation to clear PAD message (host to PAD) .br;- Indication of break PAD message (both directions) .br;- Error PAD message (PAD to host) .h1;Logical Channels Bridge X.25 products support 48 logical channels. Logical channel 0 is mainly used to restart packets. When the GS/1 establishes an outgoing call to the PDN, logical channel assignments start from 47 and go down to 1. When an incoming call is made from the PDN to the GS/1, the logical channel begins at 1 and goes up to 47 in order for the GS/1 to accept this call. Since each logical channel in the Bridge X.25 implementation is mapped into a virtual port, the default mapping between virtual ports and physical lines is assigned as follows: 0 - 5 line 0 6 - 11 line 1 12 - 17 line 2 18 - 23 line 3 24 - 29 line 4 30 - 35 line 5 36 - 41 line 6 42 - 47 line 7 .h1;Facilities The following X.25 facilities are supported by Bridge X.25 products: .br;- All level 2 timers. .br;- All level 3 timers. .br;- Q-bit for transfer of control data at higher level. .br;- M-bit as a continuation mark when a data stream is .br; fragmented in the network. .br;- More-bit for fragmentation. .br;- Accept reverse and initiate reverse charged calls. .br;- Clear request retries. .br;- Reset request retries. .h1;Bridge X.25 Certified Networks Bridge X.25 products have been certified with the following Public and Private Data Networks: .br;- Telenet (U.S. PDN) .br;- Tymnet (U.S. PDN) .br;- Uninet (U.S. PDN) .br;- Datex-P (German PDN) .br;- PSS (English PDN) .br;- Accunet (AT & T Private Data Network) .br;- Other PDN certifications including TRANSPAC (French PDN) .br; are in progress.