ASYNCHRONOUS PROTOCOL

SPECIFICATION

"APS"

Draft for Implementation

by

The APS Alliance

Copyright 1993, the APS Alliance.

Permission to copy this document is granted provided no omissions or modifications are made.

04 June, 1993

Printed in Canada
Preface
The APS Alliance
The APS Alliance was formed in October of 1992 by a group of email product and service vendors. The motivation was a need for a common asynchronous protocol to provide widespread access to X.400 message handling and X.500 directory services.
Formation Charter
"The APS Alliance aims to facilitate the use of X.400-based messaging by using dial-up connections to dramatically reduce costs and complexity."
Goals of the Alliance
•	To develop and promote a global specification for asynchronous OSI communication over dial-up access networks (e.g. PSTNs, point-to-point and PAD), with a particular focus on X.400/X.500. The resulting specification will cover both client-server and server-server communications.
•	To pursue an aggressive development schedule with the near-term goal of delivering a specification proposal to the Internet community and ISO/CCITT for formalization.
•	To involve users, software developers, systems vendors and service providers to ensure universal acceptance.
About this Document
The status of this document is "Draft for Implementation". It is believed to be correct, although no implementations currently exist. Comments on the document will be accepted until October 1, 1993. Please send comments and implementation experiences to the Technical Editor via one of the methods below:
X.400:		c=CA; A=Telecom.Canada; p=PSC.Group; o=HQ; s=Skovgaard; g=Erik
Internet:	Erik@Wimsey.bc.ca
Fax:		+1 604 270 3644
Post:		Erik Skovgaard
		The PSC Group
		130-10691 Shellbridge Way
		Richmond, B.C.
		Canada V6X 2W8
The document will be submitted to the appropriate standards body for formal ratification no later than December 31, 1993.

Member Organizations

The following organizations participated in developing this specification:
Advantis
Alprange Communications
Apple Computer
AT&T Easylink Services
Australian Telecom
Boldon James Corp.
BT
DanNet
Data Connection Limited (DCL)
Digital Equipment Corp. (DEC)
EICON
ICL
INMARSAT
Intel
ISOCOR
Marben Produit
MaXware/Norwegian Telecom
Microsoft
Net-Tel
Nexor
Olivetti
OSIware
Pacific Bell
Retix
Sequent Computer Systems
Siemens Nixdorf
SITA
SoftSwitch
Steria
Tandem Computers
Transpac (France Telecom Group)
Unisource Business Networks
Technical editor: Erik Skovgaard, The PSC Group.

Table of Contents

Preface	1
The APS Alliance	1
Formation Charter	1
Goals of the Alliance	1
About this Document	1
Member Organizations	2
1.	Terms and Abbreviations	7
2.	Introduction	8
3.	Scope	9
4.	References	10
5.	Service	12
5.1	Modes	13
5.1.1	LAPB Mode	15
5.1.2	V.42-Dependent Mode	15
5.1.3	X.25 Mode	16
5.2	Mode Negotiations	16
5.3	Multiplexing	16
5.4	Conformance	16
6.	Protocols for the Network Layer	18
6.1	Introduction	18
6.2	T.70 Minimal Network Layer Operation	18
6.2.1	Maximum NPDU Size	18
6.3	X.25 PLP Operation	18
6.3.1	Optional and Negotiable Parameters	18
7.	Protocols for the Link Layer	20
7.1	Introduction	20
7.2	Start/Stop LAPB	20
7.3	APS Link Protocol	20
7.3.1	Reception of Incorrect Frames	21
7.3.2	Time-Out	21
7.4	Transparency	21
7.5	Link Layer Operation	21
7.5.1	Point-to-Point Scenario	21
7.5.1.1	Circuit Establishment	21
7.5.1.2	Link Setup	21
7.5.1.3	Addressing	24
7.5.1.4	Time Fill	24
7.5.2	PAD Scenario	25
7.5.2.1	Circuit Establishment	25
7.5.2.2	Link Setup	25
7.5.2.3	Addressing	25
7.5.2.4	Time Fill	25
7.5.2.5	Mapping of Link Layer Frames to Packets	25
7.5.2.6	Exception Conditions	25
7.5.3	Direct Network Scenario	26
7.5.3.1	Circuit Establishment	26
7.5.3.2	Link Setup	26
7.5.3.3	Addressing	26
7.5.3.4	Time Fill	26
Annex A
A.	Transparency	27
A.1 Introduction	27
A.2 APS PAD Transparency	27
A.3 APS Seven-bit Transparency	27
Annex B
B.	APS Protocol Selection String	29
B.1 Introduction	29
B.2 APS Protocol Selection String Format	29
B.3 Use of the Call User Data in X.25 Call Requests	30

Annex C
C.	Timers and Counters	31
C.1 Introduction	31
C.2 APS Protocol Selection Phase	31
Annex D
D.	Recommended Practices	32
D.1 Introduction	32
D.2 Network Protocol	32
D.2.1	Shared Use of the T.70 Minimal Network Layer	32
D.2.2	Possible Transfer Problems for MTAs	32
D.3 Data Link Protocol	32
D.3.1	Link Frame Mapping to X.25 Packets in the PAD Scenario	32
D.3.2	Performance Improvement on Noisy Circuits using LAPB	32
D.3.3	LAPB Retransmission Timer	33
D.4 Start/Stop Framing	34
D.4.1	Flags between Contiguous Frames	34
D.4.2	Parity	34
D.5 Modems	34
D.5.1	V.42 Modems	34
D.5.2	Modems with Automatic Data Rate Switching	35
D.5.3	Modem Flow Control	35
D.6 APS Protocol Selection	35
D.6.1	Characters Preceding the APS Protocol Selection String	35
D.6.2	String Validation	35
D.7 PAD Operation	35
D.7.1	Recommended PAD Parameters	35
D.7.2	Remote PAD Parameters	36
Annex E
E.	User Requirements	37

List of Figures

Figure 3-1 - Scope of this Specification	9
Figure 5.1 - Client-Server Scenarios	12
Figure 5.2 - APS Modes in the Point-To-Point Scenario	13
Figure 5.3 - APS Modes in the PAD Scenario	14
Figure 5.4 - APS Mode in the Direct Network Scenario	15
Figure 5.5 - V.42-Dependent Mode in the PAD Scenario	16
Figure 7.1 - APS Link Frame Layout	20
Figure 7.2 - Normal LAPB Link Setup (no errors)	22
Figure 7.3 - Normal APS Link Setup (no errors)	22
Figure 7.4 - Client Timeout during Link Setup	23
Figure 7.5 - Server Timeout during Link Setup	24
Figure 7.6 - Flags Between Frames	24

List of Tables

Table 5.1  Mandatory and Optional modes for Client and Server	17

1.	Terms and Abbreviations
APS		Asynchronous Protocol Specification.
BCC		Balanced Connectionless Class.
CCITT		The International Telegraph and Telephone Consultative Committee.
CONS		Connection-Oriented Network Service.
CR		Carriage Return.
DAP		Directory Access Protocol (X.500).
DCE		Data Circuit-terminating Equipment (see [X.25]).
DLE		Data Link Escape (control character).
DM		Disconnect Mode (HDLC).
DSA		Directory System Agent (X.500).
DTE		Data Terminal Equipment (see [X.25]).
DUA		Directory User Agent (X.500).
FCS		Frame Control Sequence.
GSTN		General Switched Telephone Network.
HDLC		High-level Data Link Control.
ICRD		Inter-network Call Redirection and Deflection.
ISO		International Organization for Standardization.
LAPB		Link Access Protocol Balanced.
LAPM		Link Access Protocol for Modems (see [V.42]).
LSB		Least Significant Bit.
MS		Message Store (X.400).
MSB		Most Significant Bit.
MTA		Message Transfer Agent (X.400).
NPDU		Network Protocol Data Unit.
NPI		Numbering Plan Identification (see [X.25]).
NSAP		Network Service Access Point.
OSI		Open Systems Interconnection.
P7		Message Store Access Protocol (X.400).
PAD		Packet Assembler-Disassembler.
PDU		Protocol Data Unit.
PSDN		Packet Switched Data Network.
RPOA		Registered Private Operating Agency.
RUA		Remote User Agent.
SABM		Set Asynchronous Balanced Mode (HDLC).
SABME	Set Asynchronous Balanced Mode Extended (HDLC).
SLP		Single Link Procedures.
TOA		Type of Address (see [X.25]).
TPDU		Transport Protocol Data Unit.
UI		Unnumbered Information Frame (HDLC).
XOFF		Device Off (control character).
XON		Device On (control character).
2.	Introduction
This specification aims to facilitate the use of X.400-based messaging and other types of OSI communications by defining asynchronous protocols which can be used in conjunction with widely available asynchronous modems over the General Switched Telephone Network (GSTN). The APS standard makes no modifications to the upper four OSI layers but enables existing applications to operate in a number of scenarios including point-to-point links, connections through PADs and through suitably equipped subnetworks (i.e. asynchronous X.25).
The APS protocols take advantage of existing Link and Network Layer standards, and optimize these for asynchronous operation. To achieve this, the APS protocols can operate in three different modes:
	LAPB mode incorporates error detection and correction protocols, thus allowing the use of existing modems and network infrastructures.
	V.42-dependent mode minimizes protocol overheads by taking advantage of modern error correcting modem technology.
	X.25 mode incorporates a full X.25 Packet Layer and facilitates the migration to public asynchronous dial-up X.25 services as they become available.
This standard specifies conformance requirements for Clients and Servers, thus minimizing interworking problems.
3.	Scope
This specification deals with the lowest three layers of the OSI Reference Model. It specifically does not require any changes to the protocols in Layers 4-7, thus preserving the end-to-end protocols used by a particular application (see figure 3.1). This specification provides a suitable network service that can be used with any class of Transport Protocol.
This specification defines the protocols used in the communications, but specifically does not define the method of establishing telephone and PAD connections since this is normally handled by local means using widely available hardware.
Where an international standard is used as a part of this specification, the international standard is referenced and is not re-stated except where it is modified by this specification.

Figure 3.1 - Scope of this Specification
4.	References
[ISO 3309]	ISO/IEC 3309:1991, High-level Data Link Control - Frame structure.
[ISO 3309/Amd 2]	ISO/IEC 3309:1991/Amd 2:1992, Extended Transparency Options for Start/Stop Transmission.
[ISO 3309/Amd3]	ISO/IEC 3309:1991/Amd 3:1992, Seven bit data path Transparency Option for Start/Stop Transmission.
[ISO 4335]	ISO/IEC 4335:1991, High-level Data Link Control Procedures - Consolidation of Elements of Procedures.
[ISO 7776]	ISO/IEC 7776:1991, High-level Data Link Control Procedures - Description of the X.25 LAPB-compatible DTE Data Link Procedures.
[ISO 7809]	ISO/IEC 7809:1991, High-level Data Link Control Procedures - Classes of Procedures.
[ISO 7809/Amd 5]	ISO/IEC 7809:1991/Amd 5:1991, High-level Data Link Control Procedures - Connectionless Classes of Procedures.
[NBS]	NBS 500/150. Implementation Agreements for Open Systems Interconnection (1987).
[ISP 10609-9]	ISO/IEC 10609:1992, International Standardized Profiles TB, TC, TD and TE - Connection-mode Transport Service over Connection-mode Network Service, Part 9: Subnetwork-type Dependent Requirements for Network Layer, Data Link Layer, and Physical Layer Concerning Permanent Access to a Packet Switched Data Network Using Virtual Call.
[T.70]	CCITT Recommendation T.70:1988, Network-Independent Basic Transport Service for the Telematic Services.
[V.42]	CCITT Recommendation V.42:1988, Error-Correcting Procedures for DCEs Using Asynchronous-to-Synchronous Conversion.
[X.3]	CCITT Recommendation X.3:1988, Packet Assembly Disassembly Facility (PAD) in a Public Data Network.
[X.25]	CCITT Draft Recommendation X.25 (May 1992), Interface Between Data Terminal Equipment (DTE) and Data Circuit-Terminating Equipment (DCE) for Terminals Operating in the Packet Mode and Connected to Public Data Networks by Dedicated Circuit.
[X.28]	CCITT Recommendation X.28:1988, DTE/DCE Interface for a Start/Stop Mode Data Terminal Equipment Accessing the Packet Assembly/Disassembly Facility (PAD) in a Public Data Network Situated in the Same Country.
[X.29]	CCITT Recommendation X.29:1988, Procedures for the Exchange of Control Information and User Data between a Packet Assembly/Disassembly (PAD) Facility and a Packet Mode DTE or another PAD.
[X.32]	CCITT Draft Recommendation X.32 (April 1992), Interface Between Data Terminal Equipment (DTE) and Data Circuit-Terminating Equipment (DCE) for Terminals Operating in the Packet Mode and Accessing a Packet Switched Public Data Network through a Public Switched Telephone Network or a Circuit Switched Public Data Network.
[X.213]	CCITT Recommendation 213:1988, Network Service Definition for Open Systems Interconnection for CCITT Applications.
5.	Service
This specification defines the protocol exchanges between an initiator unit called the Client and a responder unit called the Server. The Client can, for instance, be an X.400 remote User Agent (RUA), a Directory User Agent (DUA) or an X.400 Message Transfer Agent (MTA); the Server can be, for instance, an X.400 Message Store (MS), a Directory System Agent (DSA) or an X.400 MTA. However, this specification is not limited to supporting these objects and related protocols.
Three scenarios for client-server communications are considered in this specification (see figure 5.1):
1.	The Point-to-Point scenario where the Client establishes a connection directly with the Server.
2.	The PAD scenario where the Client establishes a connection with an X.3/X.28 PAD service and subsequently establishes a network connection via the PAD (and underlying network) with the Server.
3.	The Direct Network scenario where the Client establishes a connection with an X.25 network access point and subsequently establishes a connection with the Server.

Figure 5.1 - Client-Server Scenarios
5.1	Modes
The service may operate in one of three modes:
1.	LAPB mode where the protocol provides full error detection and correction. This mode can only be used in the first two scenarios listed above.
2.	V.42-dependent mode where the protocol relies on services provided by a pair of modems operating in error-correcting mode. This mode can only be used in the first two scenarios listed above.
3.	X.25 mode which provides full error detection and correction and additionally, can provide full CONS. This mode can be used in all three scenarios listed above.
Figures 5.2 to 5.4 depict the usage of the modes in the various scenarios.

Figure 5.2 - APS Modes in the Point-To-Point Scenario

Figure 5.3 - APS Modes in the PAD Scenario

Figure 5.4 - APS Modes in the Direct Network Scenario

5.1.1	LAPB Mode
This mode is defined in [T.70] as the network and link level profile for Circuit-Switched Data Networks. It provides a network connection to a single End System. While T.70 restricts this mode to Circuit-Switched Data Networks, this specification extends the use of the T.70 Minimal Network Layer to the APS Point-to-Point and PAD scenarios in conjunction with start/stop LAPB.
5.1.2	V.42-Dependent Mode
This mode uses the T.70 Minimal Network Layer in conjunction with the APS Link Protocol as defined in this specification. Use of the V.42-dependent mode requires both ends of the data link to use modems operating in error-correcting mode (referred to as "V.42 modem" below) as follows:
	In the Point-to-Point scenario the Client and the Server must each use an error-correcting modem.
	In the PAD scenario the Client and the PAD service provider must each use an error-correcting modem.
This mode may not provide adequate reliability in some circumstances. Note specifically that the path between the V.42 modem and the Client is operating without error correction. In the Point-to-Point scenario, the path between the V.42 modem and the Server is also operating without error correction and in the PAD scenario, the path between the V.42 modem and the PAD is again operating without error correction (see figure 5.5). The method for detecting these errors and the action taken are defined in clause 7.3.

Figure 5.5 - V.42-Dependent Mode in the PAD Scenario
5.1.3	X.25 Mode
This mode is defined in [X.25] and [X.32] (both with start/stop transmission). This mode can provide access to several logical channels which allows the Client to maintain concurrent connections with multiple Servers. This specification defines a profile for the Packet and Data Link Layers and extends the asynchronous transparency options.
5.2	Mode Negotiations
The appropriate mode is established by the procedures described in Annex B of this specification. In the Direct Network Scenario procedures as defined in [X.25] and [X.32] shall prevail.
5.3	Multiplexing
Only the X.25 mode provides multiplexing at the Network Layer. Additional Transport connections can be provided by using Transport Protocol classes 2, 3 or 4, however the choice of Transport Protocol class is outside the scope of this specification.
5.4	Conformance
Products which claim conformance to this specification shall implement the required modes for the scenarios as shown in Table 5.1. Note that the V.42-dependent mode can only be used where the appropriate modems are available, see clause 5.1.2.

The service provided by the protocols defined in this specification shall ensure a residual error rate less than or equal to 1:109.

Scenario	Point-to-Point	PAD	Network	
Mode	Client	Server	Client	Server	Client	Server	
LAPB	O1	M	O2	M	-	-	
V.42-dependent	O1	M	O2	M	-	-	
X.25	O	O	O	O	M	M	

	1 At least one of these shall be implemented.
	2 At least one of these shall be implemented.
	Legend:
	O	-	Optional
	M	-	Mandatory
	-	-	Not applicable
Table 5.1 - Mandatory and Optional modes for Client and Server.
6.	Protocols for the Network Layer
6.1	Introduction
The Network Layer Protocols may be either the minimal Network Layer defined in [T.70] (referred to as "T.70 Minimal Network Layer" in this document) or X.25 Packet Layer Protocol (PLP) as described in [X.25] (referred to as "X.25 PLP" in this document).
6.2	T.70 Minimal Network Layer Operation
The procedures defined in [T.70], clause 3.3.3 shall be followed, except clause 3.3.3.1 (Call Control Phase) which does not apply to this specification. The Q and M bits are not used and shall both be set to zero.
6.2.1	Maximum NPDU Size
No segmentation is performed by the Network Layer. Each TPDU shall map to one NPDU. This limits the Network User Data to 2048 octets when Transport class 0 is used and 8192 octets for all other Transport classes.
6.3	X.25 PLP Operation
The procedures are defined in [X.25] and [X.32]. The Client shall implement the DTE side of the protocol. In the Point-to-Point Scenario the Server shall act as the DCE, but shall act as a DTE (to the network) in the Direct Network Scenario. See figures 5.2 and 5.4.
Using the X.25 mode in the PAD Scenario is a little more complex. As indicated in figure 5.3, the Server is a DCE from the point of view of the end-to-end X.25 PLP, but may be the DTE from the point of view of the underlying network protocol (labeled X.25 PLP' in the figure).
6.3.1	Optional and Negotiable Parameters
Implementations that claim conformance to this specification shall be able to work with the following Packet parameters:
1.	At least one logical channel.
2.	A logical channel group number of zero.
3.	A logical channel number starting with one.
4.	No support for Permanent Virtual Calls.
5.	Default packet size of 128 octets. However, the client may propose any packet size up to 8192 octets.
6.	No diagnostic packets.
7.	No support for on-line facility registration.
8.	No D-bit modification.
9.	No throughput negotiation support.
10.	No support for extended packet sequence numbering.
11.	No support for Packet retransmission.
12.	No support for closed user groups.
13.	No support for fast select.
14.	No support for reverse charging.
15.	No support for call redirection.
16.	No support for call deflections.
17.	No support for transit delay selection and indication.
18.	No support for ICRD facilities.
19.	No support for called line address modified notification.
20.	No support for TOA/NPI address subscription.
21.	No support for RPOA Selection.
Address mode is a local matter between the Client and either the Server or the Network administration. However, the Server must be able to accept the NSAP Addresses.
The Client may propose any window size in the range 2 to 7.
Other or additional use of the parameters listed above is allowed by bilateral agreement.
Note that default packet and window sizes are determined by subscription to public networks.

7.	Protocols for the Link Layer
7.1	Introduction
The link layer protocol may be either LAPB (with start/stop transmission) as defined in [X.25] and [ISO 3309] operated as modified in this document (referred to as "start/stop LAPB"), or the APS Link protocol as defined in section 7.3 of this document.
7.2	Start/Stop LAPB
The operation of start/stop LAPB shall be as specified in [ISP 10609-9], clause 6 as amended by clause 7.5.1 or clause 7.5.2 of this document. The following additional restrictions/defaults apply:
	Only Single Link Procedures (SLP) shall be supported.
	Modulo 8 shall be supported.
	16-bit FCS shall be supported.
	The SABME command shall not be supported.
	Default window size of 7.
Use of other options in LAPB is beyond the scope of this specification.
7.3	APS Link Protocol
The APS Link Protocol is defined in [ISO 7809/Amd 5]. Only the BCC repertoire (defined in [ISO 7809/Amd 5], clause 7) is used. This specification extends the use of these procedures to include all scenarios for which the APS Link Protocol is specified with the variations specified below.
This protocol, although it does not recover from link errors, will in conjunction with a reliable circuit (e.g. a V.42 modem in error correcting mode) be considered to provide an error-free Data Link Service.
The APS Link frame is a UI frame where the control field is followed by a sequence octet (see figure 7.1). The value of the sequence octet is a modulo 256 number. The number is incremented by one each time a frame is sent.

Figure 7.1 - APS Link Frame Layout
7.3.1	Reception of Incorrect Frames
Incorrectly received frames shall be treated as per [ISO 7809/Amd 5]. In addition, an implementation receiving an APS Link frame shall ensure that the sequence number of a received frame is one higher than the last received frame (modulo 256). If the sequence number is incorrect, a link error has occurred and a DL-Reset Indication is sent to the Data Link service user. Higher layers can take appropriate action.
Reception of an incorrect sequence number signals that a frame may have been lost. Unless higher layers can recover, the link shall be terminated immediately.
7.3.2	Time-Out
No action is defined upon time-out and no timer value is specified.
7.4	Transparency
APS defines three levels of transparency (see Annex A). Clients and Servers shall implement all three transparency levels. In the Point-to-Point and PAD scenarios, any one of the three transparency levels shall be operated as appropriate. In the case of the Direct Network scenario, the Basic transparency level shall be operated.
7.5	Link Layer Operation
7.5.1	Point-to-Point Scenario
7.5.1.1	Circuit Establishment
The Client establishes the circuit to the Server through the General Switched Telephone Network (GSTN).
The means of establishing the circuit are outside the scope of this specification, being determined by the relevant regulatory and practical considerations applying to the Client's implementation and connection.
7.5.1.2	Link Setup
Once the circuit is established, the Client transmits the appropriate APS Protocol Selection String (see Annex B) to select the mode and transparency level.
If LAPB or X.25 mode was selected, the Client will expect an appropriate LAPB frame (i.e. SABM, DISC or DM); any other response will be considered an error and will be discarded. Receipt of a valid frame will cause the Client to respond as defined in [X.25], clause 2.4.4. The sequence diagram for normal LAPB link setup is shown in figure 7.2.

Figure 7.2 - Normal LAPB Link Setup (no errors)
If V.42-dependent mode was selected, the Client will expect an APS Link frame with a sequence number of zero and no data from the Server; any other response will be considered an error and will be discarded. Receipt of a valid APS Link frame causes the Client to send an APS Link frame with a sequence number of zero (with or without data). The sequence diagram for normal APS link setup is shown in figure 7.3.

Figure 7.3 - Normal APS Link Setup (no errors)
The Client shall retransmit the string after a time-out (APS-Tc), until an appropriate link frame is received, or the retry limit (APS-N) is exceeded. The sequence diagram for Client Timeout is shown in figure 7.4.

Figure 7.4 - Client Timeout during Link Setup
On receipt of a valid APS Protocol Selection String, the Server shall send the appropriate link frame dependent upon the mode selected as defined below. The link frame sent shall have the transparency level requested by the Client applied prior to transmission. If the Server responds using a different transparency level to that requested, the circuit shall be terminated. Any data subsequently received by the Server which is not recognized as a link frame will be discarded.
If V.42-dependent mode was selected by the Client, the Server shall transmit an APS Link frame with a sequence number of zero and no data, and expect an APS Link frame with a sequence number of zero (with or without data) in response. Receipt of this APS Link frame by the Server completes the link setup.
If LAPB or X.25 mode was selected by the Client, the Server will assume that LAPB data link set-up can commence and shall follow the procedures defined in [X.25], clause 2.4.4.
The Server may terminate the link if the appropriate response frame has not been received before time-out (APS-Ts). The sequence diagram for Server Timeout is shown in figure 7.5.

Figure 7.5 - Server Timeout during Link Setup
7.5.1.3	Addressing
The Client is assigned the address "A" and the Server the address "B".
7.5.1.4	Time Fill
No flags or other characters shall be transmitted between frames. However, implementations shall be capable of receiving any characters between frames. Such characters shall for the purpose of the link protocol be ignored. Where a frame is immediately followed by another both the terminating flag of the first frame and the start flag of the second frame must be present (see figure 7.6).

Figure 7.6 - Flags Between Frames

7.5.2	PAD Scenario
7.5.2.1	Circuit Establishment
The Client establishes the circuit to the Server. The circuit is a concatenation of GSTN and one or more PSDNs, where a PAD is provided at the initial PSDN boundary.
The functions of the PSDN, including the three layers of X.25 and the X.29 protocol, are regarded as providing part of the Physical Layer, i.e. comprise part of the circuit over which the Link Layer protocol is run.
The means of establishing the circuit, and particularly in the case of PAD communication, the means of setting PAD parameters and bringing the PAD into the data transfer state are outside the scope of this specification (this is determined by the relevant regulatory and practical considerations applying to the Client's installation, connection and the PAD characteristics). Recommended PAD parameter settings are included in Annex D.
7.5.2.2	Link Setup
Link setup proceeds as described in section 7.5.1.2, except that the first transmission of the APS Protocol Selection String may be sent in a data packet or in the User Data of the X.25 Call Request issued by the PAD. If Call User Data was used to transmit the first instance of the APS Protocol Selection String any subsequently retransmitted strings shall be sent as regular data packets (i.e. after the PAD call is connected).
7.5.2.3	Addressing
The Client is assigned the address "A" and the Server the address "B".
7.5.2.4	Time Fill
No flags or other characters shall be transmitted between frames. However, implementations shall be capable of receiving any characters between frames. Such characters shall for the purpose of the link protocol be ignored (but may be used by an implementation to indicate circuit disconnect). Where a frame is immediately followed by another, both the terminating flag of the first frame and the start flag of the second frame must be sent (see figure 7.6).
7.5.2.5	Mapping of Link Layer Frames to Packets
Servers that are connected directly to a PSDN shall transmit (and may expect) link layer frames in the user data of the underlying X.25 data packets without the Q-bit set.
7.5.2.6	Exception Conditions
X.28 PAD messages may be ignored by the Client, X.25 interrupts and resets may be ignored by the Link Layer at the Server unless the underlying X.25 service terminates the circuit (for example as the result of analysis of the cause code of a reset). Clearing of the X.25 virtual call causes the Link Layer implementation to immediately enter the disconnected phase.
7.5.3	Direct Network Scenario
7.5.3.1	Circuit Establishment
The Client establishes the circuit to the network access point as specified by the service provider.
The means of establishing the circuit are outside the scope of this specification, since it is determined by the relevant regulatory and practical considerations applying to the Client's installation and connection.
7.5.3.2	Link Setup
Link Setup is as per [X.25].
Note that the APS Protocol Selection String is not required in this scenario.
7.5.3.3	Addressing
Addressing is as per [X.25].
7.5.3.4	Time Fill
Time Fill is as per [X.25].

Annex A
A.	Transparency
A.1	Introduction
APS defines three levels of transparency processing for use with start/stop mode transmission. These are Basic transparency, specified in [ISO 3309/Amd 2], subclause 4.5.2; APS PAD transparency, specified in subclause A.2 below; and APS seven-bit transparency, specified in subclause A.3 below.
Note:	Character encoding shown below is represented with the most significant bit first. Base standards may use the reverse order. Bit position convention used below shows the least significant bit as number 1.
A.2	APS PAD Transparency
The transparency procedure defined in [ISO 3309/Amd 2], subclause 4.5.2 is applied to the FE5/CR, TC7/DLE, DC1/XON and DC3/XOFF control characters (i.e. x0001101, x001000, x0010001 and x0010011, respectively, where "x" may be either "0" or "1"), in addition to the flag and control escape octets. This has the effect of assuring that the octet stream does not contain values which could be interpreted by a PAD as control characters (regardless of parity).
A.3	APS Seven-bit Transparency
In APS seven-bit transparency the content of each frame - from address field to FCS field inclusive - shall be transferred between sender and receiver as a frame-image derived from the original frame by applying a two stage procedure as follows.
In the first stage, the sequence of octets making up the frame content is considered as divided into a sequence of contiguous seven-octet segments, with a final segment having length of between one and six octets inclusive. These segments are referred to as "original segments".
The frame-image consists of a sequence of image segments defined, in one-to-one correspondence with the original segments, as follows:
a.	image segments occur in the same order as the corresponding original segments.
b.	each image segment is one octet longer than its original segment.
c.	the first part of each image segment is a copy of its original segment, but with the most significant bit (MSB) of each octet set to zero.
d.	the remaining, final, octet of each image segment has its least significant bit (LSB) set to the value of the MSB of the last octet of the original segment, its next to least significant bit set to the value of the MSB of the next to last octet (if any) of the original segment, and so on.
e.	in the final octet of each image segment, all higher order bits for which no corresponding octet exists in the original segment are set to zero.
In the second stage, the transparency procedure defined in [ISO 3309], subclause 4.5.2 is applied to all octets in the frame-image in which both the 6th and 7th bits are "0" (i.e. x00xxxxx, where "x" may be either "0" or "1") as well as for the DEL character octet (i.e. x1111111, where "x" may be either "0" or "1"), in addition to the flag and control escape octets. This has the effect of assuring that the octet stream does not contain values which could be interpreted by intermediate equipment as the control characters or DEL character (regardless of parity).
Note:	At the transmitter, the final octet of each image segment can be generated by shifting right the MSB of each octet in the original segment, in sequence, into an initially zero octet: this achieves the correct bit-positioning both for complete seven-octet segments and any short segment at the end of the frame.
Note:	The MSB of each image-segment octet is defined as zero only for uniqueness of the mapping: because its value is known and plays no part in the reconstruction of the original segment at the receiver, it need not actually be transferred across data paths that, for example, force parity setting of the MSB of each octet.
Annex B
B.	APS Protocol Selection String
B.1	Introduction
As part of the APS link setup procedures the Client informs the Server of the mode and the transparency level to be used. The selection information is transmitted as a character string either as the first data transmitted by the Client following establishment of a circuit, or, in the case of communication via a PAD, optionally also in the User Data field of the X.25 Call Request issued by the PAD.
B.2	APS Protocol Selection String Format
The selection string shall be in the format APSptpt, where:
	APS is the introduction string.
	p is the mode selector character. The following characters are defined:
	H	-	LAPB mode
	A	-	V.42-dependent mode
	X	-	X.25 mode.
	t is the transparency level selector character. The following characters are defined:
	B	-	Basic transparency
	8	-	APS PAD transparency
	7	-	APS seven-bit transparency.
The APS Protocol Selection String may be terminated by one or more carriage return characters, for example to trigger packet forwarding by a PAD. Trailing carriage return characters will be ignored by the Server.
All alphabetic characters in the APS Protocol Selection String shall be upper case. The most significant bit of each character shall be set to zero when characters are sent, however the most significant bit of each character is ignored on reception.
As an example,
	APSHBHB<cr>
specifies LAPB mode/Basic transparency.
B.3	Use of the Call User Data in X.25 Call Requests
When using an X.25 virtual call via a PAD, the X.25 Call User Data may be used to carry the APS Protocol Selection String. The first 4 octets of the User Data field of a Call Request are dictated by the PAD according to [X.29], but the remaining octets are available for use. (Note the first 4 octets of the User Data field are normally generated by the PAD; i.e. the Client has no direct control over these octets).
One or more carriage return characters are allowed in the Call User Data after the APS Protocol Selection String, but are not required. A Server shall ignore any characters following the APS Protocol Selection String.
Annex C
C.	Timers and Counters
C.1	Introduction
This annex contains recommended values for the parameters defined in the body of the specification. This annex is not a formal part of this specification.
C.2	APS Protocol Selection Phase
	APS-Tc	5 seconds	(Client retransmit time).
	APS-Ts	15 seconds	(Server disconnection time).
	APS-N	4		(Number of re-tries).
Annex D
D.	Recommended Practices
D.1	Introduction
The recommended practices below are provided as guidelines to implementers. This annex is not part of this specification.
D.2	Network Protocol
D.2.1	Shared Use of the T.70 Minimal Network Layer
As specified, no provision is made for selecting a specific Transport Service when using the T.70 Minimal Network Layer. This problem is for further study.
D.2.2	Possible Transfer Problems for MTAs
The T.70 Minimal Network Layer allows only a single data stream. This can cause problems for MTAs engaged in the MTS-Transfer Service in which one or both do not support the RTS Two-Way Alternate dialog mode. Message transfers may only be possible in one direction if Transport Class 0 or 1 are used. This problem is for further study.
D.3	Data Link Protocol
D.3.1	Link Frame Mapping to X.25 Packets in the PAD Scenario
The boundaries of a link frame are recognized by the start and end flags. Implementations are recommended not to split a frame across a complete packet sequence, but shall not rely on received frames corresponding to complete packet sequences.
D.3.2	Performance Improvement on Noisy Circuits using LAPB
A corrupted frame is normally discarded and recovered by a combination of timers and sequence numbers, however, in some circumstances, this could result in long delays. Rather than waiting for timeout to occur at the remote end, an implementation detecting a corrupt frame may choose to send an RNR acknowledging the last successfully received I-frame immediately followed by an RR frame acknowledging the same frame. An implementation receiving this protocol sequence should resume transmission commencing with the first unacknowledged I-frame.
D.3.3	LAPB Retransmission Timer
It is recommended that the value used for the retransmission timer be based upon the round-trip delay experienced on the link. The implementation should maintain, and continually update, an estimate of the round-trip delay for the link. From this estimate, a value for the retransmission timer (T1) is calculated each time it is started. Example techniques for maintaining the estimate and calculating the retransmission timer are described below (adapted from [NBS], section 4.5.2.3).
As network load increases, the variability of round-trip delay also increases. In environments where load fluctuates widely, it is therefore useful to estimate the variability of round-trip delay measurements and use this estimate in the calculation of retransmission timer values. An estimate of the variability of round-trip delay measurements can be efficiently calculated as an exponentially weighted average of the differences between round-trip delay measurements and the average round-trip delay. This represents the mean deviation of the round-trip delays, which is a useful approximation of the standard deviation and can be much more efficiently computed. The formula is:
	D <--- D + (1 - a) (|S - E| - D)
where	D is the estimate of variability in round-trip delays.
	S is the new sample.
	E is the current estimate of the round-trip delay as defined below.
	a is a locally administered factor which can be set to some value between 0 and 1.
The value of E may be calculated using an exponentially weighted average based upon regular sampling of the interval between transmitting a frame and receiving the corresponding acknowledgment. Samples are taken by recording the time of day when a frame requiring acknowledgment is transmitted and calculating the difference between this and the time of day when the corresponding acknowledgment is received. New samples are incorporated with the existing average according to the following formula:
	E <--- E + (1 - a) (S - E).
A value for a should be chosen to keep the retransmission timer sufficiently small such that lost frames will be detected quickly, but not so small that false alarms are generated causing unnecessary retransmission.
As before the value of a must be between 0 and 1 and the choice of a value of (1 - 2-n) allows for efficient update of the average. The value of a for the variability estimation, however, does not need to be the same as that used for the round-trip delay estimate. A smaller value for a is useful in the variability estimation to cause a more rapid response to changes in round-trip delays. D can then be used to calculate retransmission timer values according to the formula:
	T1 <--- E + kD
Where	T1 is the retransmission timer value
	E is the estimated average round-trip delay.
	k is a locally administered factor.
Since D approximates the standard deviation of the round-trip delays, but is greater than or equal to the standard deviation, round-trip delays within k standard deviations of the mean would be accounted for by the retransmission timer value (e.g. k = 2, if round-trip delays were normally distributed, would account for 95% of the variability).
Round-trip time measurements based on acknowledgment of any retransmitted data should not be used to update the round-trip delay estimate or the estimate of variability. Such measurements are not reliable since it is ambiguous which transmission of the data is being acknowledged.
One strategy for handling a retransmission timeout is to retransmit the frame and reset the timer with a value that is twice the previous value. In this case, a new round-trip delay estimate and estimate of variability should be calculated only when an acknowledgment of data is received where none of the acknowledged data has been retransmitted. This calculation uses the new round-trip delay measurement and the last estimate before the retransmission timeout(s).
D.4	Start/Stop Framing
D.4.1	Flags between Contiguous Frames
[X.25] mandates flags as inter-frame fill. Implementations should be configurable to generate inter-frame flags in the Direct Network scenario.
However, inter-frame fill in the case of the Point-to-Point and PAD scenarios may cause unnecessary traffic, hence flags must not be used as time fill (as specified in section 7.5). In addition, flags may not be shared between contiguous frames. However, it is recommended that implementations are capable of receiving frames with shared flags.
D.4.2	Parity
No parity bit should be generated in Basic transparency and APS PAD transparency. Parity may be generated in APS seven-bit transparency, but should be ignored by the receiver.
D.5	Modems
D.5.1	V.42 Modems
V.42 modems can operate in three modes:
1.	LAPM, which provides full error correction.
2.	MNP (referred to as "Alternative Procedure" in [V.42]), which provides full error correction.
3.	Non-error correcting mode.
Since V.42-dependent mode relies on either of the error correcting modes, it is recommended that implementations ensure proper operation of the modem after the circuit has been established. Failure to do so may cause the link to be disconnected.
D.5.2	Modems with Automatic Data Rate Switching
Modems that adapt transmitted data rates to link conditions may cause problems in conjunction with adjustable timers. Implementers are warned about this problem.
D.5.3	Modem Flow Control
It is recommended that implementations are able to support modem hardware flow control.
D.6	APS Protocol Selection
D.6.1	Characters Preceding the APS Protocol Selection String
It is recommended that the APS Protocol Selection String (as defined in Annex B) is preceded by two or more CR characters. Note that this may not be possible in the PAD scenario since the CR character is often used as a command delimiter by the PAD.
D.6.2	String Validation
The Server should validate the APS Protocol Selection String as follows:
1.	All alphabetic characters must be upper case.
2.	The first three characters must be "APS" (hex 41, 50 and 53).
3.	The first and third characters (mode selector) after "APS" must be identical.
4.	The second and fourth characters (transparency level selector) after "APS" must be identical.
5.	The mode selector and transparency level selector must be valid (see Annex B).
D.7	PAD Operation
D.7.1	Recommended PAD Parameters
If the operation of the PAD permits, it is recommended that the Client sets the PAD parameters to the relevant values before the X.25 virtual call is set up. [X.28] envisages the possibility of PADs which automatically initiate the connection process without giving an opportunity for the PAD parameters to be altered, on the assumption that the PAD has a priori knowledge of the values required. Such PADs can be used provided that the a priori parameter settings are compatible with the provisions in this specification).
The following suggestions apply to PAD parameter settings and associated operations.
a.	PAD Parameter 3 is set to the value 2.
	This value should cause the PAD to forward data when it gets a CR character. (Note that the transparency algorithms specified in Annex A for use with PADs ensure that any CR character in the data to be transmitted will be hidden). It is recommended that the Client should normally add an un-escaped carriage return after each frame. The exception to this is if there is an immediately following frame, in which case the carriage return may be omitted provided that delay in delivery of the first frame until the second frame can be delivered will not cause expiry of any retransmission timer, e.g. the LAPB timer T1, at either system.
b.	PAD parameter 5 is set either to the value 1 or to the value 2.
	This ensures that the PAD can use XON/XOFF signaling to control the flow of data from the Client. (Note that the transparency algorithms specified in Annex A for use with PADs ensure that any XON or XOFF character in the data to be transmitted will be hidden). The Client shall act on any received XOFF and XON characters and cease and restart transmission accordingly.
c.	PAD parameter 1 is set to 0 or 1
	If set to 1 this allows the Client to force the PAD into the PAD command state from the data transfer state by transmitting a DLE character. (Note that the transparency algorithms specified in Annex A for use with PADs ensure that any DLE character in the data to be transmitted will be hidden).
d.	The remainder of parameters 2, 4, 6 to 10, 12 to 15, and 21 to 22 are normally set to zero. However, when APS seven-bit transparency is operated, parameter 21 can be adjusted to meet the parity requirements of the system, the PAD or intermediate equipment.
e.	A product may be capable of using different PAD parameter values from those given above if there is a requirement to work with non-standard PADs which do not support the above values. In particular, the APS seven-bit transparency mechanism would make it possible to work with PADs which do not support the zero values of parameters relating to the insertion of padding. With either the APS PAD transparency or APS seven-bit transparency level it would also be possible to operate with parameter 4 set to a small non-zero value, so that the PAD forwards data from the Client across the network whenever there is a delay in receiving more incoming data; this would make it possible to operate (although less efficiently) without the use of the CR character to indicate forwarding.
D.7.2	Remote PAD Parameters
The Server should not modify the remote PAD parameters after a client has established a circuit. Any changes in the PAD parameters could adversely affect the operation of the circuit.
Annex E
E.	User Requirements

This annex is included for information only, and does not form a part of this specification.

The User Requirements set forth by the APS Alliance are stated below:
1.	Provide a reliable means for running OSI applications in general and X.400/X.500 in particular over dial-up telephone networks.
2.	The solution should be operating system and hardware platform independent.
3.	Support for multiple associations over the same dial-up connection (e.g. P7 and DAP).
4.	Efficiency and simplicity (minimal overhead, high throughput, low resource/memory consumption, allowing for compression, easy to implement).
5.	Require minimal changes to existing standards.
6.	Provide support for both point-to-point connections, access via PAD and data networks.
7.	Must be modem and PAD independent, and must be able to work with or without XON/XOFF flow control.
8.	Include place holders for security features (which may be added as "phase two"). The specification should not preclude security features such as authentication, dial-back, encryption, etc.