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 = %<CS/1-X.25 (1)'s Ethernet address>!<rotary
    portid>#<host (1)'s X.25 address>

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 = %<GS/1 (1) Ethernet address>!<rotary
    portid>#<host(3)'s X.25 address>

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 = &<Remote Ethernet Network ID> %<CS/1-X.25 (3)'s
    Ethernet address>!<rotary portid>#<host(4)'s X.25 address>

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 = &<Remote Ethernet Network ID>%<CS/1's Ethernet
    address>!<rotary portid>

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 = %<CS/1-X.25 (1)'s Ethernet address>!<rotary portid>

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 = %<CS/1-X.25 (2)'s Ethernet address>1<rotary portid>

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=&<Local Ethernet Network ID>%<CS/1-X.25 (1)'s Ethernet
    address>!<rotary portid>

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=&<Local Ethernet Network ID>%<GS/1 (1)'s Ethernet
    address>!<rotary portid>

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 = &<Remote Ethernet Network ID>%<GS/1 (2)'s Ethernet
    address>!<rotary portid>
    xxxx2 = &<Local Ethernet Network ID>%<CS/1-X.25 (1)'s
    Ethernet address>!<rotary portid>

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 = &<Remote Ethernet Network ID>%<GS/1 (2)'s Ethernet
    address>!<rotary portid>
    xxxx4 = %<GS/1 (3)'s Ethernet address>!<rotary portid>

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 = &<Local Ethernet Network ID?%<CS/1-X.25 (1)'s
    Ethernet address>!<rotary portid>
    xxxx6 = &<Remote Ethernet Network ID>%<CS/1-X.25 (3)'s
    Ethernet address>!<rotary portid>

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 = %<GS/1 (3)'s Ethernet address>!<rotary portid>
    xxxx8 = &<Remote Ethernet Network ID>%<CS/1-X.25 (3)'s
    Ethernet address?!<rotary portid>

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 <BREAK> 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.





