X.25 can be a bit confusing, as different terms are used for what is effectively the same packet type; it’s just that some packets from the DTE to the network have different names to the equivalent packet from the DCE to the DTE.
| Packet type | DTE to DCE | DCE to DTE |
|---|---|---|
| Link set-up | Restart Request | Restart Indication |
| Call set-up | Call Request | Incoming Call |
| Call acknowledgement | Call Accept | Call Connect |
| Clearing | Clear Request | Clear Indication |
| Resetting | Reset Request | Reset Indication |
Other packet types have the same name, regardless of the direction.
Call Request and Incoming Call
A Call Request is transmitted by a DTE to initiate an X.25 Switched Virtual Circuit.
An Incoming Call is identical to a Call Request, other than the direction of travel, except for the X.25 Facilities field – facilities are used to communicate with the network itself, and thus certain facilities only make sense (and are only allowed) in Call Request packets, and other facilities can only appear in Incoming Call packets.
Call packets contain the following parameters in the packet body:
- Called (i.e. destination) Address
- Calling (i.e. origination) Address
- X.25 Facilities
- Call User Data
All of these parameters are optional, although sending a Call Request packet without a Destination Address would only make sense on a Point-to-Point link, as a Network would not know where to route the call!
The Call User Data (CUD) field is normally up to 16-octets – it can be longer when using Fast Selects, but these are rarely used in practice. The CUD is typically used to hold a Protocol Identifier – for example, calls from a Triple-X PAD contain 01000000 (in hex), and RFC-1356 IP/X.25 calls use 0xCC in the CUD field. CUD can also be used to select between applications at the Called DTE – in a similar way to using a subaddress.
Call Accept and Call Connect
A DTE transmits the Call Accept packet in response to an Incoming Call Packet, and the network translates that into a Call Connect packet delivered to the Calling DTE.
Clear Request and Clear Indication
Clear packets are used to disconnect a connected SVC, and also to refuse an Incoming Call.
Clear Confirmation
Clear confirmation packets are sent in response to Clear Requests/Indications. Once a clear Confirmation packet has been received, the logical channel is then available for a new virtual circuit.
Reset Request and Reset Indication
Reset packets are used to reset the virtual circuit data transfer states; all the sequence numbers for the virtual circuit and set back to zero.
Reset Confirmation
Reset Confirmation packets complete the channel reset condition, allowing data transfer to recommence.
Interrupt Packets & Interrupt Confirmation
Interrupt Packets can be used to alert the peer of some urgent event; once transmitted, it’s necessary for the sender to wait for an Interrupt Confirmation packet before sending another Interrupt Packet.
Interrupt Packets are rarely used.
Supervisory Packets: RR, RNR and REJECT
RR and RNR packets are similar to their counterparts in Layer 2; they are used to carry acknowledgements when Data Packets are not being transmitted. In addition, RNR packets are used to indicate to the peer that further Data packets should not be transmitted.
In practice, RNR packets are rarely used, as there’s always the chance that a Data Packet might be sent by the peer before it’s had a chance to receive the RNR. Instead, flow control is maintained if necessary by closing the window – that is, not acknowledging all the received packets.
Reject packets should not are very rarely used – unlike at Layer 2, normally there’s no reason why a Data Packet should go missing at Layer 3.
Restart Packets
Restarts have significance for the entire link – if a Restart Indication packet is received, it will cause all the virtual circuits on the link to be Cleared (or Reset in the case of PVCs). The DTE can also cause the link to be restarted by transmitting a Restart Request.
It’s common for Restarts to be exchanged when a link starts up, just in case the link hadn’t actually gone down at the other end.