ISO/IEC 8878:1992

Information technology — Telecommunications and information exchange between systems — Use of X.25 to provide the OSI Connection-mode Network Service

For a protocol to support the CONS, there must be a mapping between the abstract primitives and parameters of the CONS and the real elements of the protocol. For the X.25 Packet Layer Protocol (PLP), the main body of this standard provides such a mapping for the X.25/PLP-1984 using Virtual Calls. Also provides a mapping of the CONS primitives and parameters to the X.25/PLP-1980 plus an SNDCP. These mappings apply to the X.25 VC service. Specifies two sets of procedures from which three classes of implementation are described.

Technologies de l'information — Télécommunications et échange d'informations entre systèmes — Utilisation du protocole X.25 pour fournir le service de réseau OSI en mode connexion

General Information

• Status: Published
• Publication Date: 29-Dec-1992
• ICS: 35.100.30 - Network layer
• Technical Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Drafting Committee: ISO/IEC JTC 1/SC 6/WG 7 - Network, transport and future network
• Current Stage: 9093 - International Standard confirmed
• Start Date: 16-Aug-2002
• Completion Date: 12-Feb-2026

Relations

• Revises: ISO 8878:1987/Amd 3:1991 - Information processing systems — Data communications — Use of X.25 to provide the OSI connection-mode network service — Amendment 3
• Effective Date: 16-Oct-2025
• Revises: ISO 8878:1987/Cor 4:1991 - Information processing systems — Data communications — Use of X.25 to provide the OSI connection-mode network service — Technical Corrigendum 4
• Effective Date: 15-Apr-2008
• Revises: ISO 8878:1987 - Information processing systems — Data communications — Use of X.25 to provide the OSI connection-mode network service
• Effective Date: 15-Apr-2008

Overview

ISO/IEC 8878:1992 specifies how to use the X.25 Packet Layer Protocol (PLP) to provide the OSI Connection‑mode Network Service (CONS). The standard defines a mapping between the abstract CONS primitives/parameters and the concrete X.25 packet fields and procedures. The main body addresses X.25/PLP‑1984 using Virtual Calls (VCs) and the annexes provide alternative mappings and implementation guidance (including an SNDCP for X.25/PLP‑1980 and a PVC method).

Keywords: ISO/IEC 8878:1992, X.25, OSI Connection‑mode Network Service, CONS, X.25/PLP‑1984, virtual calls

Key topics and technical requirements

• Primitive-to-packet mapping: Detailed relationships between CONS primitives/parameters and X.25 PLP packets/fields for connection establishment, data transfer, release and reset phases.
• Procedure sets and implementation classes: Two sets of procedures are specified from which three classes are described - System‑1984, System‑1980, and Compatible implementations - to support interworking and migration.
• Data transfer services: Support for normal data transfer, receipt confirmation, expedited transfer and reset services, including packet/field mappings and procedures.
• Annexed protocols and guidance:
  • Annex A: Subnetwork Dependent Convergence Protocol (SNDCP) for X.25/PLP‑1980.
  • Annex B: Classification of systems and interworking rules.
  • Annex C: Mapping for Permanent Virtual Circuits (PVCs).
  • Annex D: Protocol Implementation Conformance Statement (PICS) proforma.
  • Annexes E–I: additional considerations (NPAI addressing, priority negotiation, transit delay calculations, differences vs. X.223).
• Conformance and optional features: Clause 13 and annex D define conformance criteria and PICS requirements for claimants.

Keywords: primitive mapping, PICS, SNDCP, PVC, conformance, X.25 VC

Practical applications

• Enabling legacy and current X.25 subnetworks to support OSI‑model network services where CONS semantics are required.
• Providing a migration path from older X.25 implementations (1980) to X.25/PLP‑1984 features while preserving interoperability.
• Designing or testing network layer implementations (end systems and relay nodes) that must interoperate across mixed X.25 environments.
• Documenting conformance for product certification and interoperability testing.

Keywords: legacy networks, migration, interoperability, X.25 subnetwork, network layer

Who should use this standard

• Network protocol engineers and architects implementing OSI Network Layer over X.25.
• Vendor product teams building X.25 DTE/DCE or network‑layer relay software.
• Test labs and compliance teams preparing PICS and interoperability test plans.
• Organizations operating packet‑switched or integrated networks (public/private X.25, LAN gateways, ISDN interworking).

Related standards

• CCITT/ITU‑T Recommendation X.223 (related mapping)
• CCITT/ITU‑T X.25 (Packet Layer Protocol) and ISO/IEC 8208 (X.25 PLP for DTE)
• ISO/IEC 8348 / CCITT X.213 (Network Service definition)

Keywords: X.223, ISO/IEC 8208, ISO/IEC 8348, X.25 PLP

Standards Content (Sample)

INTERNATIONAL lSO/IEC
STANDARD
Second edition
1992-I 2-l 5
Information technology -
Telecommunications and information
exchange between systems - Use of X.25
to provide the OSI Connection-mode
Network Service
- T6lkommunications et khange
Technologies de I’informa tion
en tre s ys t&mes - Utilisation du protocole X.25 pour
d ‘in formations
fournir le service de r&eau OSI en mode connexion
Reference number
lSO/IEC 88783 992(E)
SO/l EC 8878: 1992(E) 0 ISO/IEC
CONTENTS Paae
WA
Foreword. . . . . . . n l . l l . l l l l . . . . . . . . . . . . . . . iv
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V
1. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Normative references . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Identical Recommendations 1 International Standaids. . . . . .
2.2 Paired Recommendations 1 International Standards equi.valent.in &hni’ca~content . . . . . .
2.3 Additional references . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
3. Definitions . . . . . . . . .
3.1 Referendehnodelbe;inition’s . . . . . . . . . . . . . . . . . . . . . . .
3.2 Service Conventions definitions . . . . . . . . . . . . . . . . . . . . . .
3.3 Network Service definitions l . . . . . . . . . l . . l l . l l . . . . . .
3.4 X.25 definitions . . . . . . . . . . . . . l l l l l . . . l . l . . . .
3.5 X.96 definitions l l l . l l . . l l l l . . l l . . l . l l . . . l . .
4. Abbreviations l l l l . . . . . l m . l l . l l l l l .
. . 3
4.1 Network Semwide abbeviatibns . l . l . . . . l . . . . l . . l . . . . . .
4.2 X.25 abbreviations . l l l . l . l l l l . l l l l l l . l l l l . l . .
5. Overview. . l . l l l l l l l l l l . . l l l l l l l l l l l l . . . .
5.1 Elements Of the X.25/PLP-I984 USed tO SUppOe the OSI CONS . . . . . l l l . . . .
5.2 General operation of the X.25/PLP-1984 for supporting the OSI CONS . . . . . l . . . .
6. Network connection establishment phase . . . . . . . . . l . . . . . l . l l . .
6.1 Primitive/Parameter and packet/field relationships . . . . . . . . . l l . . . . l
6.2 Procedures l l l l l l l l l l . l l l l . l l l l l . l . . . . . l
7. Networkconnection release phase . l . l . . l . . . l . . l . . l . l . . . .
7.1 Primitive/Parameter and packet/field relationships . . . . . . . . . . . . . . . l
7.2 Procedures l l l l l l l l l l . l l . . . l l l l l l l l . l l . .
8. Data transfer phase- Data transfer service . . . . l . . l . . . . l l . l . l . l 17
8.1 Primitive/Parameter and packet/field relationships . . . l . . . . l . l . . . . . 17
8.2 Procedures . . l l l . m l l l l . . . . l l l l l l l l l l l . . . 17
9. Data transfer phase - Receiptconfirmationsewice . . . . . . . . . . . l . l . l l 18
9.1 Primitive and packet/field relationships l l . . . . . . . . . . . l l . l l l . 18
9.2 Procedures . . l . . . . . l . . . . . l l l l l . . . l l . . l . . 18
10. Data transfer phase - Expediteddatatransferservice . . . . l . . . . . . . l l . l . 19
10.1 Primitive/Parameter and packet/field relationships . . . l . . . . l l l . . l . . 19
10.2 Procedures l l . l l l m l l . . l . . l l . l l . . l m l l l l . . 19
11. Data transfer phase - Reset service l l l l . . 8 . . l . l . l l l
11 .I Primitive/Parameter and packet/field relatibnships . . l l l . . . . . . . l . l . l
Il.2 Procedures . . m l l l l l l l . l . . l l l l . . l l l l l l l . l
0 ISO/lEC 1992
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced
or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm, without permission in writing from the publisher.
ISO/lEC Copyright Office l Case postale 56 l CH-1211 Geneve 20 l Switzerland
Printed in Switzerland
ii
o ISO/IEC
lSO/IEC 8878:1992(E)
12. Response to protocol violations . . . . . . . . . . . l . . . . l .
. . . . . . 21
13. Conformance
. . l l . . .
. . . . l l .
13.1 Conformance &&em% . l l . . . . . . . . . . . 1 1 1 1 l l . . l . 22
l l . . . .
.
13.2 Optional features . . . . . . . . . l . l
. . . .
. . . . l l l l
. . . 22
Annex A: X.25 (1980) Subnetwork Dependent Convergence Protocol . . . . . . . l l . . . . 23
A.1 Introduction . . . . . . . . . l . . . .
A.2 Scope . . . . . . . . . . . . l l . . l . l . . l . . . l . . l l . 23
. .
. . . . . . . . . .
. . .
A.3 Abbreviations
. . . . . . . l . .
A.4 Overview of the pro&l . . . . . . l l . . : . . . . . . . . . . . . . . 24
A.5 Protocol mechanisms . . . . . . . . . . . . : . . . . . . . . . . . . . 26
. . . . . . . . . . . .
.
A.6 Protocol description
. l l l l l l .
. . . . . 0 . . . . . . .
. 38
A.7 Protocol encoding in X.25 packeis . . . . l . . . . . . . . . . . . . . . . . 48
Annex B: Classification . . . . . . . . . l . l .
l
B.1 Classification of systems . . . . l . l l . . : : : . l . l l l l . . l l l 54
B.2 Functionality of classes . . . . . . l l l l . .
. . . l l . . l . . . . l . . . . 54
. . . . . 0 . .
B.3 Scenarios . . . . . . . l .
. l l l l . . .
8.4 Procedures for selecting class of operation . l l . . . . . : : : l . l . . . . . 55
l l . . . . . .
B.5 lntenworking by relay system . . l . . . . . l . . .
. . .
. . . . . . 0 . 55
Annex C: Subnetwork Convergence Protocol for Use With X.25 Permanent Virtual Circuits
. l . . . .
C.l Introduction and scope . . . . . . . . l . . . l
. . . . l l
. . . . . . 58
C.2 OveMew . . . . . . l . . . .
C.3 Abbreviations . . . . . . . l . . : : : . . . . . l l l . . . . D . 58
. . . . l l . . . .
. . . .
C.4 Protocol mechanisms
. . . . . . l l . .
C.5 Protocol encoding for NC establishment and .rel&e . . . . . . . . . . : : : : : : 60
Annex 0: Protocol Implementation Conformance Statement Proforma
. . . . . . . . . .
. . . 62
D.1 Introduction . . . . . . . . . l . . . .
. . l l l l . . . .
. . . 62
0.2 Scope . . . . . . . . . l . . . l
l . . . l . . l l l . . .
. . . . 62
0.3 Normative references . . l l l l l . . l l I
. . . . . l . . l
. . . . . . 62
0.4 Definitions . . . . . . l l . l .
l l . . . . l l l l . .
. . . . . 62
D.5 Abbreviations .
. . . l l l l
. . . . . . 63
D.6 Protocol Implementation Ccnforr&ce.State&t Proforma.
l . . l l l l
. . . . . . 64
0.7 Modified PICS requirements for ISO/IEC 8208 . . . . .
l . . l l l l
l l . . . . 76
Annex E: Additional Considerations of CONS Primitives . . . . . . . . l . . . . .
.
. . . 83
E.l Introduction . . . . . . l l l l l l
. . . .
E.2 Environment for X.25/PLP operation . l . . . l . l l : : : : l . l l . . l l 83
. . . . .
l l .
Annex F: Use of X.25/PLP NPAI l l . l . l l l . l . . . . l l . l . . . . . . . 85
F.l Introduction . . . . l l . . . . . l . .
F.2 Obtaining an SNPA address . . l . . . l . . : : : : : : l l . l . . . . . 85
F.3 Examples of Network Address encoding . . . . l l l l . l . : I : : : . . . l 85
. . . l
Annex G: Transit Delay Calculations . . . . . l l . m l l . . . . .
l .
. . . . . l 87
Annex HZ Example of Priority Negotiation . . l . . l . l . . l l l l . .
.
. . . . . . 89
Annex I: Differences between Recommendation X.223 and ISO/IEC 8878 . . . . . . . l . . . . 81

0 ISOAEC
ISOAEC 8878:1992( E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the Inter-
national Electrotechnical Commission) form the specialized system for
worldwide standardization. National bodies that are members of IS0 or
IEC participate in the development of International Standards through
technical committees established by the respective organization to deal
with particular fields of technical activity. IS0 and IEC technical commit-
tees collaborate in fields of mutual interest. Other international organiz-
ations, governmental and non-governmental, in liaison with IS0 and IEC,
also take part in the work.
In the field of information technology, IS0 and IEC have established a joint
technical committee, lSO/IEC JTC 1. Draft International Standards adopted
by the joint technical committee are circulated to national bodies for vot-
ing. Publication as an International Standard requires approval by at least
75 % of the national bodies casting a vote.
International Standard lSO/IEC 8878 was prepared by Joint Technical
’ Committee lSO/IEC JTC 1, Information technology.
This second edition cancels and replaces the first edition
which has been technically revised. It consolidates
(IS0 8878:1987),
Technical Corrigenda 1, 2 and 3, Addenda 1 and 2 and Amendment 1 as
well as Technical Corrigendum 1 to Addendum 2.
NOTE - lSO/lEC DIS 8878-2 as well as defect reports 8878-012, 013,
014 and 015 have also been included in this second edition.
Annexes A, B, C and D form an integral part of this International Standard.
Annexes E, F, G, H and I are for information only.

0 ISO/IEC ISOAEC 8878:1992( E)
Introduction
This International Standard defines methods for providing the OSI Connection-Mode Network Service (CONS)
through the use of the virtual circuit services of the X.25 Packet Layer Protocol (X.25 PLP). The method presented
in the main body of this International Standard specifies a mapping between elements of the 1984 or later versions
of the X.25/PLP (referred to as X.25/PLP-1984) using X.25 Virtual Call (VC) services and elements of the OSI
CONS. Features associated with versions of X.25 later than 1984 are identified as to which version they relate.
This International Standard is similar to CCITT Recommendation X.223; however, the two are currently published
as separate documents.
Clause 13 contains the requirements for systems claiming conformance to this International Standard.
Other methods using other virtual circuit services and/or other versions of X.25 are also defined. In particular, a
second method for VCs, which is presented in Annex A, defines a Subnetwork Dependent Convergence Protocol
(SNDCP) that shall be used to provide the OSI CONS over subnetworks or with equipment using the 1980 or
earlier versions of the X.25/PLP (referred to as X.25/PLP-1980). This SNDCP should only be used if the elements
of the X.Z5/PLP-1984, as defined in 5.1 herein, are not available to support the OSI CONS. Annex B contains a
classification of systems according to whether they implement the procedures defined in the main body of this
International Standard, the procedures defined in Annex A, or both. In addition, it describes the possibilities and
the rules for interworking between the classes of equipment identified.
Annexes A and B are integral parts of this International Standard. They are intended to provide a migration
strategy towards the use of the 1984 version of X.25 in both subnetworks and DTEs. Because of the evolution of
technology, the status of Annexes A and B will be reviewed in the future.
Annex C defines another method for providing the OSI CONS, in this case in conjunction with the PVC sewice of
X.25.
Annex D provides the Protocol Implementation Conformance Statement (PICS) Proforma for this International
Standard.
Annexes C and D are integral parts of this International Standard.
Annex E provides additional considerations on the relationship between the X.25 protocol procedures and the
CONS primitives.
Annex F illustrates the use of X.25 Network Protocol Address Information (NPAI), i.e., the Address Field and the
Address Extension Facilities.
Annex G illustrates the use of the X.25 transit delay facilities.
Annex H illustrates the use of the X.25 Priority Facility.
Annex I lists the differences between CCITT Rec. X.223 and lSO/IEC 8878.
Annexes E through I are not integral parts of this International Standard.
The relationship between the X.25/PLP-1984 and the OSI CONS is shown in Figure 1. This relationship is
described only in terms of the Network Layer entities that provide the CONS. No discussion is given here to
describe the actions of a Network Layer entity that only provides a relay function for a given network connection.
The OSI Network Service is defined in terms of
a) the primitive actions and events of the Service;
b) the parameters associated with each primitive action and event, and the form which they take;
c) the interrelationship between, and the valid sequences of, these actions and events.

ISOAEC 8878:1992(E) 0 ISOAEC
TRANSPORT
TRANSPORT -------USESSERVICE--------:
c
PROTOCOL
I
LAYER
I
I
V
NETWORK SERVICE
A
X.25 PACKET I
NETWORK
LAYER
LAYER
-------
PROVIDES SERVICE - - - - - 1
PROTOCOL
Figure 1 - Relationship of the X.25 Packet Layer Protocol to the OSI Connection-Mode Network Service
The OSI Network Service does not specify individual implementations or products nor does it constrain the
implementation of entities and interfaces within a computer system.
The X.25/PLP-1984 is defined in terms of
a) procedures for Virtual Calls and Permanent Virtual Circuits;
b) formats of packets associated with these procedures;
c) procedures and formats for optional user facilities and CCIlTSpecified DTE facilities.
The use of the word “Network” to name the “Network” Layer of the OSI Reference Model should be distinguished
from the use of the word “network” to denote a communications network as conventionally understood. To
facilitate this distinction, the term “subnetwork” is used for a collection of physical equipment, commonly called a
“network” (reference CCITT Rec. X.200 1 IS0 7498). Subnetworks may be either public or private networks. In
the case of public networks, their properties may be determined by separate CCITT Recommendations such as
CCllT Rec. X.21 for a circuit-switched network or CCIlT Rec. X.25 for a packet-switched network.
Throughout the set of OSI-related Recommendations 1 International Standards, the term “Service” refers to the
abstract capability provided by one layer of the OSI Reference Model to the layer above it. Thus, the Network
Service is a conceptual architectural Service, independent of administrative divisions.
It is important to distinguish the specialized use of the term “Service” within the set of OSI-related
NOTE -
Recommendations 1 international Standards from its use elsewhere to describe the provision of a service by an organization
(such as the provision of a service, as defined in CCllT Recommendations, by an Administration).
vi
INTERNATIONAL STANDARD 0 ‘sunEC
ISOIIEC 8878:1992(E)
Information technology -
Telecommunications and
information exchange between systems -
Use of X.25 to
provide the OS Connection-mode Network Service
1. Scope
The OSI Connection-mode Network Service (CONS) is defined in terms of a set of primitive actions and events
and associated parameters. For a protocol to support this service, there must be a mapping between the abstract
primitives and parameters of the CONS and the real elements of the protocol. For the X.25 Packet Layer Protocol
(PLP), the main body of this International Standard provides such a mapping for the X.25/PLP-1984 using Virtual
Calls.
This International Standard also provides a mapping of the CONS primitives and parameters to the X.25/PLP-1980
plus an SNDCP (Annex A). These mappings apply to the X.25 VC setice. In addition, the method of selecting
the appropriate mapping, if any, for different combinations of end systems and Network Layer relay systems
implementing one or more of the mappings is defined (Annex B).
For the PVC setice for both the X.25/PLP-1984 and the X.25/PLP-1980, a mapping of CONS primitives and
parameters to the X.25/PLP is given in Annex C.
This International Standard specifies two sets of procedures from which three classes of implementation are
described. The requirements of these procedures are applicable both to end system operation and to half the
operation of a Network Layer relay. Where relay operation is concerned, the two halves of the relay may be the
same or different classes of implementation.
This International Standard specifies the requirements to be met by a System-1984 implementation.
Implementations in this class are designed to operate directly and efficiently with other System-l 984
implementations, including cases of operation across an X.25( 1984) subnetwork.
This International Standard also specifies the procedures to be operated by a System-1980 implementation.
Implementations in this class are designed to operate directly with other System-1980 implementations, including
cases of operation across any form of X.25 subnetwork, but will operate less efficiently than System-1984
implementations.
This International Standard also specifies the requirements to be met by a Compatible implementation.
Implementations in this class are designed to operate directly with all other implementation classes, including
cases of operation across any type of X.25 subnetwork. They make efficient use of X.25(1 984) when placed in
this environment.
The X.25/PLP is usually regarded as operating between an end system (i.e., a “Data Terminal Equipment” in X.25
terminology) and a packet-switched public data subnetwork. However, the X.25/PLP can also be used in other
0 ISO/IEC
environments to provide the OSI CONS. Examples of such other uses include
a) an end system connected to an X.25 packet-switched private data subnetwork;
b) an end system connected to a local area network;
or circuit-switched connection (including connection across a circuit-switched data
direct connection
C)
subnetwork;
subnetwork) of two end systems without an intervening packet-switched public data
d) an end system connected to an Integrated Services Digital Network.
2. Normative references
The following CCITT Recommendations and International Standards contain provisions which, through reference
in this text, constitute provisions of this International Standard. At the time of publication, the editions indicated
were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this
International Standard are encouraged to investigate the possibility of applying the most recent edition of the
Recommendations and Standards listed below. Members of IEC and IS0 maintain registers of currently valid
International Standards. The CCITT Secretariat maintains a list of currently valid CCITT Recommendations.
2.1 identical Recommendations 1 International Standards
- CCITT Recommendation X.21 3 (1992) 1 ISO/IEC 8348:1992, Information Technology - Network Service
Definition for Open Systems Interconnection.
2.2 Paired Recommendations 1 International Standards equivalent in technical content
- CCITT Recommendation X.25 (1988), 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.
NOTE - This Recommendation is referred solely with respect to its Packet Layer Protocol description. However, this
Recommendation fully specifies the behaviour of the DCE while specifying only a minimum set of requirements for the DTE.
Additional guidance for the design of DTEs is available in ISOAEC 8208.
ISO/IEC 8208: 1990, Information technology - Data communications - X.25 Packet Layer Protocol for Data
Terminai Equipment.
- CCITT Recommendation X.200 (1988), Reference model of Open Systems Interconnection for CCITT
applications.
IS0 7498: 1984, Information processing systems - Open Systems Interconnection - Basic Reference Model.
- CCITT Recommendation X.21 0 (1988), Open Systems Interconnection layer sewice definition conventions.
- Open Systems Interconnection - Service conventions.
ISOfTR 8509:1987, Information processing systems
2.3 Additional references
- CCITT Recommendation X.96 (1988), Call progress signals in Public Data Networks.
3. Definitions
For the purpose of this International Standard, the following definitions apply.
3.1 Reference Model definitions
The following terms, developed and defined in the OS1 Reference Model (CCITT Rec. X.200 1 IS0 7498), are
used:
a) Network connection
b) Network Layer
c) Network Service
d) Network Service Access Point
e) Network Sewice Access Point address
f) Subnetwork
ISOAEC 8878:1992(E)
0 ISO/IEC
3.2 Service Conventions definitions
The following terms, as they apply to the Network Layer and as defined in the OSI Service Conventions (CCIIT
Rec. X.210 1 ISO/TR 8509), are used:
a) Network, Service user
b) Network Service provider
c) primitive
d) request
e) indication
f) response
g) confirm
3.3 Network Service definitions
The following terms, as defined in the Network Service (CCITT Rec. X.213 1 ilSO/IEC 8348), are used:
a) Calling Network Service user
b) Called Network Service user
c) Subnetwork Point of Attachment address
d) Network Protocol Address Information
e) Initial Domain Part
f) Authority and Format Identifier
g) Initial Domain Identifier
h) Domain Specific Part
3.4 X.25 definitions
The following terms, as developed in the X.25 Packet Layer Protocol (CCITT Rec. X.25 1 ISO/IEC 8208), are
used:
a) virtual circuit
b) Virtual Call
c) logical channel
d) Packet Layer
e) Data Terminal Equipment
f) Data Circuit-terminating Equipment
g) DXE (either a DTE or a DCE)
3.5 X.96 definitions
The following terms, as defined in CCITT Rec. X.96, are used:
a) Category C call progress signal
b) Category D call progress signal
4. Abbreviations
4.1 Network Service abbreviations
AFI Authority and Format Identifier
Connection-Mode Network Service
CONS
DSP Domain Specific Part
Initial Domain Identifier
IDI
IDP Initial Domain Part
N Network
NC Network-connection
NL Network Layer
NPAI Network Protocol Address Information
NS Network Service
NSAP Network Senn’ce Access Point

0 ISO/IEC
ISOIIEC 8878:1992(E)
OSI Open Systems Interconnection
QOS Quality of Service
Subnetwork Point of Attachment
SNPA
4.2 X.25 abbreviations
AEF Address Extension Facility
AF
Address Field
B-MTCN
Basic Minimum Throughput Class Negotiation (Facility)
B-TCN
Basic Throughput Class Negotiation (Facility)
D-bit
Delivery Confirmation bit
DCE Data Circuit-terminating Equipment
DTE
Data Terminal Equipment
EDN
Expedited Data Negotiation (Facility)
EETDN
End-to-End Transit Delay Negotiation (Facility)
FPF Facility Parameter Field
General Format Identifier
GFI
LC Logical Channel
M-bit
More Data bit
MBS M-bit Sequence
PLP
Packet Layer Protocol
Packet receive sequence number
P(R)
Packet send sequence number
p(s)
PVC Permanent Virtual Circuit
Qualifier bit
Q-bit
TDSAI Transit Delay Selection And Indication (Facility)
vc Virtual Cal I
5. Overview
The Network Service (NS) provides for the transparent transfer of data between NS users. It makes invisible to
these NS users the way in which supporting communications resources are utilized to achieve this transfer.
5.1 Elements of the X.25/PLP-1984 used to support the 0% CONS
The X.25/PLP-1984, as defined by CCITT Rec. X.25 1 ISO/IEC 8208, provides a specific realization for the
transparent transfer of data between NS users of the CONS. The elements of this protocol to be considered are
a) the virtual-circuit types;
b) the packet types and fields to be mapped to the primitives and parameters of the OSI CONS;
c) the optional user facilities and CCITT-Specified DTE facilities.
Of the two types of virtual circuits defined in CCITT Rec. X.25 1 ISO/IEC 8208, the use of Virtual Calls (VCs) is
mapped to the network connection (NC) establishment and release phases of the OSI CONS in clauses 6 and 7
and to the data transfer phase in clauses 8-11. (The corresponding mapping for PVCs is given in Annex C.)
Table 1 lists the X.25/PLP-1984 packets and associated fields that shall be used when supporting the OSI CONS.
In addition, the following optional user facilities and CCITT-Specified DTE facilities shall be used and/or agreed to:
a) optional user facilities:
1) Fast Select (facility used; when operating in a DTE-to-DTE environment without an intervening packet-
switched network, the use of the Fast Select Facility shall also be agreed to by the two DTEs);
2) Fast Select Acceptance (facility agreed to if operating in a packet-switched network environment);
3) Basic Throughput Class Negotiation (facility agreed to and used);
4) Transit Delay Selection And Indication (facility used).
b) CCIlT-Specif.ied DTE facilities:

0 lSO/IEC ISOAEC 8878:1992(E)
Table 1 - Packets and fields of the X.25/PLP-1984 used to support the OS CONS
Packet Types’) Fields’)
CALL REQUEST General Format Identifiefl), Address Field, Facility Field,
INCOMING CALL
Call and Called User Data Field41
CALL ACCEPTED
CALL CONNECTED
CLEAR REQUEST Clearing Cause Field, Diagnostic Code Field, Address
CLEAR INDICATION Field, Facility Field, Clear User Data Field4)
DATA D-bit, M-bit, P(S)5), P(R)? User Data Field41
INTERRUPT Interrupt User Data Field4)
RECEIVE READY6> P( R)5)
RECEIVE NOT READY61
REJECT61 (if agreed to)
Resetting Cause Field, Diagnostic Code Field
RESET REQUEST
RESET INDICATION
RESTART INDICATION Restarting Cause Field, Diagnostic Code Field
Notes to Table 1:
I - The packets shown in the table are used in support of the primitives of the OSI CONS. Other packets not shown in the
table (i.e., CLEAR CONFIRMATION, INTERRUPT CONFIRMATION, RESET CONFIRMATION, and RESTART CONFIRMA-
TION packets) are essential to the use of the packets shown. Yet other packets (i.e., RESTART REQUEST, DIAGNOSTIC,
REGISTRATION REQUEST, and REGISTRATION CONFIRMATION packets) have no relationship to the provision of the OSI
CONS.
2 - The information in the fields shown in the table have a direct relationship to the parameters associated with the primitives of
the OSI CONS. Other fields not shown in the table (e.g., the Logical Channel Identifier, the Packet Type Identifier, the Q-bit, the
Address Length Fields, and the Facility Length Field) are essential to the use of the appropriate packets.
3 - Bit 7 of octet 1 of the General Format Identifier (GFI) in these packets is used to negotiate the overall availability of the
Delivery Confirmation bit (D-bit) in support of the Receipt Confirmation Service. As such, this bit has no specific field-name as
defined in the X.25/PLP-1984.
4 - All user data fields are octet aligned.
5 - The P(S) and P(R) fields are essential to the operation of the X.25/PLP-1984 in providing the Receipt Confirmation Service.
6 - The action implied by these packets has no relationship to the primitives of the OSI CONS. However, the P(R) field is
essential to the operation of the X.25/PLP-1984 in providing the Receipt Confirmation Service.
1) Called Address Extension (facility used);
2) Calling Address Extension (facility used);
3) End-to-End Transit Delay Negotiation (facility used);
4) Expedited Data Negotiation (facility used);
5) Basic Minimum Throughput Class Negotiation (facility used);
6) Priority (facility used with 1988 or later versions of the X.25/PLP).
5.2 General operation of the X.25/PLP-1984 for supporting the OS CONS
The X.25/PLP-1984 can be used to provide the OSI CONS in an end system connected to a public or private X.25
packet-switched subnetwork. It can also be used in environments where the end system is connected to a Local
Area Network or where end systems are connected by a dedicated path or by a circuit-switched connection.

ISOAEC 8878:1992(E) 0 ISO/IEC
As shown in Figure 2, the NS provider (more particularly, the Network Layer (NL) entity in an end system) must
provide a translation between
a) the primitives and parameters of the OSI CONS;
b) the packets and associated fields of the X.25/PLP-1984.
END SYSTEM B
END SYSTEM A
m
I
l
n
n
NS
USERS
NETWORK
-----
SERVICE
NS
PROVIDER
DTE/DXE
INTERFACE (Note)
NOTE - This interface consists of zero or more Network Layer entities providing a Network Layer relay function.
Figure 2 - Operation of 0% Connection-Mode Network Service and X.25 Packet Layer Protocol (1984)
Request and response primitives are translated into packets to be transmitted across the DTUDXE interface by
the NL entity. Received packets, where appropriate, are translated by the NL entity into indication and confirm
primitives.
Annex E provides additional considerations on the relationship between the X.25 protocol procedures and the
CONS primitives.
NOTE -The Network Service Definition specifies valid sequences of primitives at an NC endpoint and valid parameter
responses at the called NC endpoint to Receipt Confirmation negotiation, Expedited Data negotiation, and Quality of Service
(QOS) parameter negotiation. The necessity for the NL entity to monitor compliance and the actions to be taken on non-
compliance are a local matter, and not subject to standardization.
There is also a relationship between some local mechanism used to identify a particular NC and a Logical Channel
(LC) number used to identify a particular virtual circuit. This relationship is a local matter and is not discussed
here.
0 ISO/IEC SO/l EC 8878: 1992(E)
6. Network connection establishment phase
6.1 Primitive/Parameter and packet/field relationships
Table 2 shows the relationships between the primitives/parameters used during the NC establishment phase and
the packets/fields associated with the call setup procedures.
Table 2 - CONS:X.25/PLP-1984 mapping for the NC establishment phase
CONS X.25/PLP-1984
PRIMITIVES: PACKETS:
N-CONNECT request CALL REQUEST
N-CONNECT indication INCOMING CALL
N-CONNECT response CALL ACCEPTED
N-CONNECT confirm CALL CONNECTED
.
PARAMETERS: FIELDS (INCLUDING FACILITIES):
Called DTE Address Field
Called Address
Called Address Extension Facility
Calling DTE Address Field
Calling Address
Calling Address Extension Facility
Called DTE Address Field
Responding Address
Called Address Extension Facility
General Format Identifier’)
Receipt Confirmation Selection
Expedited Data Selection Expedited Data Negotiation Facility
QOS-Parameter Set Basic Throughput Class Negotiation Facility’)
Basic Minimum Throughput Class Negotiation Facility
Transit Delay Selection And Indication Facility
End-to-End Transit Delay Negotiation Facility
Priority Facility
NS-User-Data Call and Called User Data Field
Fast Select Facili@
Notes to Table 2:
1 - Bit 7 of octet 1 of the GFI in call setup packets is used to negotiate the overall availability of the D-bit in support of the
Receipt Confirmation Service. As such, this bit has no specific field-name as defined in the X.25/PLP-1984.
2 - For proper operation, this optional user facility shall also be agreed to for use on the interface.
3 - For proper operation, the Fast Select Acceptance Facility shall also be agreed to on the interface when accessing a
packet-switched network.
6.2 Procedures
6.2.1 Primitive/Packet mapping
When an NL entity receives an N-CONNECT request or an N-CONNECT response primitive from an NS user, it
transmits a CALL REQUEST or a CALL ACCEPTED packet, respectively, across the DTE/DXE interface.
When an NL entity receives an INCOMING CALL or a CALL CONNECTED packet, it signals an N-CONNECT
indication or an N-CONNECT confirm primitive, respectively, to the NS user.

60/I EC 8878:1992(E) 0 ISO/IEC
6.2.2 Network addresses
Local operation determines the contents of the Network Protocol Address Information (NPAI) and whether Network
Addresses, where explicitly supplied, are mapped to and from the Address Field (AF) or the Address Extension
Facilities (AEF) of X.%/PLP-1984 call setup packets. Annex F describes guidelines .for the methods by which the
required AF contents may be derived from the Network Address. The permitted techniques for the placement of
Network Addresses in either the AF or AEF are given in this clause. The encoding techniques to be employed are
those specified in CCITT Rec. X.25 f ISO/IEC 8208 for the AF and AEF. The content of these fields shall be in the
preferred binary encoding defined in CCIlT Rec. X.213 1 ISO/IEC 8348. Examples of encoding Network
Addresses in the NPAI of the X.25/PLP-1984 are also given in Annex F.
6.2.2.1 Encoding of Network addresses
6.2.2.1.1 Use of the Address Field (AF)
Under certain conditions, the Network Address, as defined in CCITT Rec. X.213 1 ISO/IEC 8348, may be
conveyed entirely in the AF. These conditions are
a) the Network Address consists solely of the Initial Domain Part (IDP) (i.e., the Domain Specific Part (DSP) is
null);
b) the Authority and Format Identifier (AFI) can be deduced from the contents of the AF (e.g., with knowledge of
the subnetwork to which the DTE is attached);
c) the Initial Domain Identifier (IDI) is the same as the Subnetwork Point of Attachment (SNPA) Address.
When all of the above conditions are satisfied, the AF may be used to convey the semantics of the entire Network
Address (the AFI is implied and the contents of the AF are equivalent to the IDI). In these cases, the AEF may
also be used (see 6.2.2.1.2).
NOTE -The use of the preferred binary encoding results in binary-coded decimal digits in the AF, as required by CCITT Rec.
X.25 1 ISO/IEC 8208.
6.2.2.1.2 Use of the AEF
If any of the conditions in 6.2.2.1 .I are not satisfied, the AEF shall be used. The Network Address, complete with
AFI, is placed in the AEF (bits 8 and 7 of the first octet of the Facility Parameter Field (FPF) of the AEF are both
set to zero). In this case, the contents of the AF are not defined by this International Standard. Guidelines for their
derivation are given in Annex F.
6.2.2.2 Decoding of Network addresses
If, after decoding the Network address as specified in the subclauses below, the Network address does not exist,
then the NL entity clears the call by transmitting a CLEAR REQUEST packet across the DTE/DXE interface with a
clearing cause code of “DTE Originated.” It is recommended that the diagnostic code value be set to 232 (or 224),
“Connection Rejection - NSAP Unreachable (Permanent Condition).” The NL entity shall not signal any primitive
to the NS User.
6.2.2.2.1 Absent AEF case
If the AEF is not present, then local knowledge is required by the receiving NL entity to determine whether a
Network Address is to be deduced from the content of the AF. If this local knowledge indicates that a Network
Address is present, its abstract syntax is as follows:
a) the AFI is deduced from knowledge of the subnetwork from which the packet was received;
b) the IDI is the same as the contents of the AF;
c) the DSP is absent.
If insufficient local knowledge exists to derive a Network Address from a received AF-only Called Address in an
INCOMING CALL packet, then the call is rejected by transmission of a CLEAR REQUEST packet across the
DTE/DXE interface with a clearing cause code of “DTE Originated.” The diagnostic code value is recommended to
be set to 232 “Connection Rejection - NSAP Unreachable (Permanent Condition)“.
0 ISO/IEC ISO/IEC 8878:1992(E)
6.2.2.2.2 AEF case
If the AEF is present and bits 8 and 7 of the leading octet of the FPF are both set to zero, then the Network
Address is contained entirely within the AEF. The abstract syntax is as follows:
a) the AFI is contained within the first two digits of the AEF;
b) the IDI is the remainder of the IDP after any leading and trailing padding digits are discarded;
if remainder of the AEF
the DSP, present, constitutes the content after any trailing padding digits are
C>
discarded.
If a Network Address cannot be derived from the Called AEF in an INCOMING CALL packet, then the call is
rejected by transmission of a CLEAR REQUEST packet across the DTE/DXE interface with a clearing cause code
of “DTE Originated.” It is recommended that the diagnostic code value be set to 232 (or 224) “Connection
Rejection - NSAP Unreachable (Permanent Condition).”
6.2.3 Receipt Confirmation selection
Bit 7 of octet I in the GFI of X.25/PLP-1984 call setup packets is mapped to/from the Receipt Confirmation
Selection parameter of N-CONNECT primitives.
If the Receipt Confirmation Selection parameter of the N-CONNECT request primitive indicates “use of Receipt
Confirmation,” then the NL entity, if it can support the D-bit procedure as defined in 8.2.3 and 92.1, sets bit 7 of
the GFI to I to indicate use of receipt confirmation during the data transfer phase. If “no use of Receipt
Confirmation” is indicated or the NL entity cannot support the D-bit procedure, then bit 7 is set to 0.
When an NL entity receives an INCOMING CALL packet with bit 7 of the GFI set to 1 but it cannot support the D-
bit procedure, it indicates “no use of Receipt Confirmation” in the Receipt Confirmation Selection parameter of the
N-CONNECT indication primitive signaled to the Called NS user. Otherwise, if bit 7 of the GFI is set to 1
(respectively, 0), then the NL entity indicates “use (respectively, no use) of Receipt Confirmation” in the Receipt
Confirmation Selection parameter of the N-CONNECT indication primitive signaled to the Called NS user.
When an NL entity receives an N-CONNECT response primitive with the Receipt Confirmation Selection
parameter indicating “use (respectively, no use) of Receipt Confirmation,” it sets bit 7 of the GFI in the CALL
ACCEPTED packet to 1 (respectively, 0).
When an NL entity receives a CALL CONNECTED packet with bit 7 of the GFI set to 1 (respectively, 0), it indicates
“use (respectively, no use) of Receipt Confirmation” in the Receipt Confirmation Selection parameter of the N-
CONNECT confirm primitive signaled to the Calling NS user.
6.2.4 Expedited Data selection
The Expedited Data Negotiation (EDN) Facility of the X.25/PLP-1984 is mapped to/from the Expedited Data
Selection parameter of N-CONNECT primitives.
If the Expedited Data Selection parameter of the N-CONNECT request primitive indicates “use of Expedited Data,”
then the NL entity, if it can support the Interrupt procedure using 32-octet INTERRUPT packets, encodes the EDN
Facility in the CALL REQUEST packet to indicate use of expedited data during the data transfer phase. If “no use
of Expedited Data” is indicated or the NL entity cannot support 32-octet INTERRUPT packets, then the EDN
Facility shall be either encoded to indicate no use of expedited data or omitted.
When an NL entity receives an INCOMING CALL packet with no EDN Facility or with the EDN Facility indicating
use of expedited data but it cannot support 32-octet INTERRUPT packets, it indicates “no use of Expedited Data”
in the Expedited Data Selection parameter of the N-CONNECT indication primitive signaled to the Called NS user.
Otherwise, if the EDN Facility indicates use (respectively, no use) of expedited data, then the NL entity indicates
“use (respectively, no use) of Expedited Data” in the Expedited Data Selection parameter of the N-CONNECT
indication primitive signaled to the Called NS user.
When an NL entity receives an N-CONNECT response primitive with the Expedited Data Selection parameter
indicating “use of Expedited Data,” it encodes the EDN Facility in the CALL ACCEPTED packet to indicate use of
expedited data. If the Expedited Data Selection parameter indicates “no use of Expedited Data,” then the EDN
Facility shall be either encoded to indicate no use of expedited data or omitted.
When an NL entity receives a CALL CONNECTED packet with the EDN Facility indicating use (respectively, no
use) of expedited data, it indicates “use (respectively, no use) of Expedited Data” in the Expedited Data Selection
ISO/lEC 8878:1992( E) 0 ISO/IEC
parameter of the N-CONNECT confirm primitive signaled to the Calling NS user. If the CALL CONNECTED
packet has no EDN Facility, then the NL entity indicates “no use of Expedited Data” to the Calling NS user.
6.2.5 QOS parameter set
The set of QOS parameters that are conveyed during the NC establishment phase consists of the following
parameters:
a) the throughput for the direction of data transfer from the Calling NS user to the Called NS user;
b) the throughput for the direction of data transfer from the Called NS user to the Calling NS user;
c) the transit delay that applies to both directions of data transfer;
d) the priority of the data transferred on the NC (with respect to data transferred on other NCs);
e) the priority of gaining an NC;
f) the priority of keeping this NC.
For each of these parameters, a set of “subparameters” is defined as follows:
a) a “Target” value, which is the QOS value desired by the Calling NS user;
b) a “Lowest Quality Acceptable” value, which is the lowest QOS value agreeable to the Calling NS user;
c) an “Available” value, which is the QOS value the NS provider is willing to provide;
d) a “Selected” value, which is the QOS value to which the Called NS user agrees.
The set of values that can be specified for each subparameter is defined in every Network Service. This set
includes the value “unspecified.” It may also include a value defined to be a “default value” that is mutually
understood by the NS provider and an NS user as applying in the absence of particular values.
6.251 Throughput QOS parameters
The Basic Throughput Class Negotiation (B-TCN) Facility and the Basic Minimum Throughput Class Negotiation
(B-MTCN) Facility of the X.25/PLP-1984 are mapped to/from both Throughput QOS parameters of N-CONNECT
primitives. The specific mapping of these X.25/PLP-1984 facilities to/from both sets of Throughput subparameters
is aiven in Table 3.
Table 3 - Mapping of Throughput QOS subparameters to X.25/PLP-1984 Facllltles
CONS X.25/PLP-1984
Su bparameter Primitive Facility Packet
Target N-CONNECT request B-TCN CALL REQUEST
Lowest Quality Acceptable N-CONNECT request B-MTCN CALL REQUEST
Available N-CONNECT indication B-TCN INCOMING CALL
Lowest Quality Acceptable N-CONNECT indication B-MTCN INCOMING CALL
Selected N-CONNECT response B-TCN CALL ACCEPTED
Selected N-CONNECT confirm B-TCN CALL CONNECTED
The set of values that can be specified for each Throughput subparameter ranges from 75 bits per second through
19 2000’) bits per second, inclusive.
This set consists of the following discrete values: 75, 150, 300, 600, 1 200,
2 400,4 800, 9 600, 19 200, 48 000,
64 000, 128 000, and 192 000 bits per second. An NL entity supports either
all of these values or a contiguous subset of them. The value “unspecified” is also allowed.
1) For the 1984 X.WPLP, only throughputs up to 48 000 bits per second are available. For the 1988 X.WPLP, this set is extended to 64 000
bits per second. For the 1992 X.HPLP, this set is extended to 192 000 bits per second.
0 lSO/IEC lSO/IEC 8878:1992(E)
6.2.5.1.1 Processing an N-CONNECT request primitive
If an NL entity, when receiving an N-CONNECT request primitive, cannot support the Lowest Quality Acceptable
throughput (i.e., the minimum throughput) when specified for either direction of data transfer, then it rejects the
request. In this case, the NL entity does not transmit any X.25/PLP-1984 packet but it does signal an N-
DISCONNECT indication primitive to the Calling NS user.
The Originator parameter is “NS Provider.” The
Reason parameter is “Connection Rejection -
QOS Not Available/Transient Condition,” or “Connection Rejection
- QOS Not Available/Permanent Condition” if the NL entity could never support the Lowest Quality Acceptable for
either direction of data transfer.
If an NL entity, when receiving an N-CONNECT request primitive, can support the Lowest Quality Acceptable
throughput when specified, for both directions of transfer, then for each direction of transfer it
a) encodes the Lowest Quality Acceptable value in the B-MTCN facility;
b) encodes the lesser of the Target value and the highest value that the NL entity is prepared to support in the
B-TCN facilit
...