X.25 SVCs and PVCs


The X.25 specification allows for two types of connections, or circuits:

  • PVCs are Permanent Virtual Circuits. These connections are always open, ready for data to be sent and/or received.
  • SVCs are Switched Virtual Circuits. These connections must be re-established every time a new session of data exchange is to take place, and the connections are broken at the end of the session.

An easy way to imagine this distinction is to think of your telephone.

Every time you want to exchange data (i.e., the sound of your voice), you make a call by dialing a number.

When someone answers the phone on the other end of the line, the connection is established, and you can talk to each other.

When you are finished talking, you hang up and break the connection. This is an SVC connection.

SVC connections

Imagine, however, that you have a special phone line that goes directly to one other phone and is always connected.

You don't need to dial a number to reach the party at the other end of the line. You simply pick up the phone and talk, and your message is received immediately on the other end of the connection.

It's kind of like the old "hotline" phones between the leaders of Russia and the US: the phone is always "off the hook" and ready for communication. This is a PVC connection.

PVC connections are less flexible, in that only one endpoint at a time can be connected with another on a given LCN. SVC connections are very flexible in that it is possible for multiple callers to call the same number.

PVC connections

Of course, in an X.25 network, the phones are replaced by synchronous adapters and modems, and the people talking are replaced by computer applications that know how to place and receive calls. Otherwise, the situation is very similar.

Just as every phone has a number that causes it to ring, every X.25 node has a number (or address) you can use to call it.

In the case of a PVC, there is no initial call. When the computer application starts up, the "phone" is taken off the hook, but no ring signal is sent. The connection is left open permanently.

Telephone analogy

DCEs and DTEs

There are two kinds of hosts in an X.25 network:

  • DCEs
  • DTEs

DCE stands for Data Communications Equipment. DCEs include modems, PADs and other devices that enable access to the network.

DCEs typically connect locally to a DTE, and provide the DTE with clock signals for the purpose of synchronizing communications.

DCEs and DTEs

The DCE also usually sends the DTE other modem signals, such as DSR and CTS, which help manage the flow and timing of data transmission.

DTE stands for Data Terminal Equipment. DTEs include pretty much everything that engages in synchronous communication but doesn't perform the functions of a DCE.

While DCEs send special modem and clock signals, DTEs are configured to receive these signals. DTEs also send their own modem signals to the DCE, such as RTS and DTR.

DTEs and DCEs each have their own particular electrical cable interface. It stands to reason that these interfaces are different. After all, if DCE clock signals are sent out on one set of pins in the DCE's cable, the DTE must be wired to receive those signals on the appropriate pins on its end of the connection, and vice versa.

X.25 Addresses and LCNs

The X.25 address is the equivalent of a phone number. The LCN is an index number that identifies a circuit between endpoints on an X.25 network.

For SVCs, this number is dynamically generated each time a call is placed.

For PVCs, this number is generated at initalization time and, as long as the connection is not disrupted or broken, the LCN remains constant.

You can understand the relationship between addresses and LCNs by looking at a simple SVC example. This example assumes an X.25 network with threehosts: A, B, and C. Host C has an address of 98. The addresses of A and B are unimportant for this example.

Since the called address is like a phone number, Host A places a call to address 98 in the same sort of way you and I dial a phone number.

The initial call (in our telephone analogy, this is the request for a ringtone) includes the called address, and is sent over one of many logical channels that can be created virtually as part of the available bandwidth between Host A and its local DCE. Each of these logical channels is identified by its Logical Channel Number (LCN).

In this specific example, the call goes out on LCN 16. The call arrives at the DCE, which terminates the circuit locally and relays the call to the appropriate remote DCE, using a routing table for guidance. The call is then forwarded to Host C by that DCE.

Note: Host C's DCE uses a different number LCN to send the call. In our example, this is LCN 1. The point here is that X.25 DTEs select different LCNs for outgoing calls than DCEs.

Host A places a call to Host C

When the call is received by Host C, this completes the SVC. The call is then acknowledged, and data transfer between host applications may begin.

During the exchange of data, the logical channels are held open and data transfer takes place via those LCNs.

To continue our phone analogy, this is like someone you call saying "Hello" upon answering the phone. This confirms to you that the person you're calling is there and you may then start the conversation.

Host A and Host C transfer data

X.25 SVC networking allows for multiple simultaneous connections to the same host - from any number of other hosts.

Imagine, therefore, that during the exchange between Hosts A and C, the application on Host B places a call to Host C. This is perfectly acceptable, and Host B need only place its call to address 98, just as Host A did before.

The LCN is dynamically chosen and assigned for the purposes of making the call.

Host B places call to Host C

Configuring SVCs and PVCs

To properly configure a Gcom X.25 SVC protocol stack, you must answer the following questions:

  • What is the maximum number of simultaneous SVC connections desired?
  • Is the Gcom unit a DTE or DCE?
  • Who provides the clock and modem signals?
  • What LCNs must be configured as PVCs?

Configuring the LCN ranges for SVCs and PVCs (ASCII config files)

This number is limited by the X.25 specification to 16,384 per X.25 line. To define the maximum number of SVCs, set a range of available LCNs by providing values for the lo_svc and hi_svc parameters in the Gcom configuration file.

Likewise, to define the maximum number of PVCs, set a range of dedicated LCNs by providing values for the lo_pvc and hi_pvc parameters in the Gcom configuration file.


  • Make sure that the ranges specified for SVCs and PVCs do not overlap.
  • In the example shown here, lo_pvc and hi_pvc are both "00". This means no PVCs are configured. If you want to reserve a range of LCNs for PVCs to use, set the range.
Configuring the LCN ranges for SVCs and PVCs (ASCII config files)

Configuring the Gcom unit as a DTE or DCE (ASCII config files)

Note that Gcom's X.25 "role adapt" capability automatically determines the proper setting for this parameter.

If you are configured as an DTE, LCNs for outgoing calls are allocated by number, starting with the high end of the lo_svc/hi_svc range.

If you are configured as an DCE, LCNs for outgoing calls are allocated by number, starting with the low end of the lo_svc/hi_svc range.

Configuring the Gcom unit as a DTE or DCE (ASCII config files)

Configuring the clock signals (ASCII config files)

In the vast majority of cases, Gcom is configured as an electrical DTE connected to a modem. In this case, the modem provides the clock signals, and the Gcom unit does not. In such a situation, the parameter ix25_clks should be set to zero.

If you want the Gcom unit to emulate a DCE interface (i.e., like a modem), you need to use the Gcom DTEDCE cable, and set ix25_clks = 2. This causes the Gcom unit to generate both transmit clock signals (TxC) and receive clock signals (RxC) for the device to which it connected. In this situation, the Gcom unit appears to be a modem from the perspective of the connected device.

ix25_clks = 1 is a setting reserved primarily for use with the Gcom back-to-back cable. This is typically used only for testing. In a real-world deployment, you almost always use ix25_clks = 0 or 2.

Configuring the clock signals (ASCII config files)

Configuring the modem signals (ASCII config files)

The typical configuration of 0x03 causes the Gcom unit to assert modem signals appropriate for a DTE (i.e., DTR and RTS).


Configuring the routing table

When an application sends a call, the Gcom software tries to match the called address to an entry in the Routing Table.

For PVCs, specify a partcular LCN using the npi_lcn parameter. This LCN must be within the lo_pvc:hi_pvc range specified for that port.

In the example shown here, the address "931" matches the entry for the PVC defined for port 1. Note that the parameter mn_upa reveals the port number. In the example shown here, mn_upa = -1. This corresponds to port 1.

The parameter npi_lcn specifies LCN 31 in the PVC range for port 1. Any outgoing call to address 931 tries to link to LCN 31. Any subsequent attempt to call address 931 is rejected because that PVC is now in use.

For SVCs, it is not necessary to specify a particular LCN for outgoing calls. The actual LCN is assigned dynamically according to the X.25 CCITT specification. The LCNs fall in the range specified by the lo_svc:hi_svc parameters for that port.

Configuring the routing table

In the example shown here, a call to any address other than "931" matches the wildcard address ("*") specified by the npi_route_addr parameter in the first Routing Table entry. So, a call to "88," for example, is handled by the X.25 protocol stack on port 1. In accordance with the X.25 specification, the next available LCN in the lo_svc:hi_svc range is used.

Another subsequent call to "88" is assigned a different LCN in that range. In other words, multiple calls to the same address are accepted.

Gcom_ssd SVC and PVC configuration

Begin with one of the sample configuration files included in /usr/lib/gcom/ssd/x25test

You may determine whether a particular X.25 connection is for outgoing calls or incoming calls by using the listen parameter. The listen parameter is set to 0 (default) for an outgoing connection. Set it to 1 for a listening connection.

To configure an X.25 connection for outgoing calls, set the remote_address parameter. For outgoing calls, it specifies the address used in the outgoing call and is therefore the address used to select the proper Routing Table entry.

To configure an X.25 connection for incoming calls, use the listen_address parameter to limit the calls to be accepted to a specific address or set of addresses. You may use the wildcard character (*) to define a range or set of acceptable addresses.

The line_number parameter lets you restrict accepted calls to a particular port.

Gcom_ssd SVC and PVC configuration