You are on page 1of 279

ICAO EUR DOC 005

INTERNATIONAL CIVIL AVIATION ORGANIZATION

EUR CIDIN MANUAL


Sixth Edition

Published by the European and North Atlantic Office of ICAO

April 2011

EUR CIDIN MANUAL

Record of Amendments and Corrigenda


No.

AMENDMENTS
Date
Date
applicable
entered

Entered
by

11/4/03

June 2004

eb

13/4/04

June 2004

eb

No.

Sixth Edition
Page i of v

CORRIGENDA
Date
Date
applicable
entered

Entered
by

14/04/2011

EUR CIDIN MANUAL

Amendments to CIDIN Manual

Amendment

Subject(s)

Adopted

1st Edition

Introduction of guidance material for CIDIN Implementation


in the EUR Region.

June 1990

2nd Edition

Major review, including update of the Manual to take account


of new Annex 10 format.

August 2002

1st
Amendment

Review of testing terminology as well as test cases in


Appendix D.
Revision of Chapters 9 & 10 and Appendix D.
Description of network management interface in Chapter 1.

April 2003

2nd
Amendment

Introduction of Network management application interface


procedures (Chapter 9 and Appendix D).
Refinements in Chapters 8, 10 and Appendix F.

April 2004

3rd Edition

New edition to consolidate 1st and 2nd Amendments.

June 2004

4th Edition

New edition to introduce Chapters 12 and 13 and Appendix H.

July 2005

5th Edition

New edition to introduce Chapter 6 Transport Layer,


paragraph 6.2.9.1 and Chapter 10 Operational Procedures,
paragraph 10.2.3

September 2006

6th Edition

Incorporation of CP-CIDINM-10-001,
Incorporation of CP-CIDINM-10-002,
Minor editorial changes and reformatting

April 2011

Sixth Edition
Page ii of v

14/04/2011

EUR CIDIN MANUAL

Table of Contents
Record of Amendments and Corrigenda .........................................................................................................i
Amendments to CIDIN Manual ..................................................................................................................... ii
Table of Contents............................................................................................................................................ iii
1.
Introduction ............................................................................................................................................ 1
1.1 PURPOSE OF THIS MANUAL ....................................................................................................................... 1
1.2 A COMMON NETWORK FOR VARIOUS APPLICATIONS ............................................................................... 2
1.2.1
Existing Services ............................................................................................................................. 2
1.2.2
CIDIN architecture .......................................................................................................................... 3
1.3 OPTIONAL PARAMETERS AND X.25 VERSION ......................................................................................... 10
2.
Physical Layer (1)................................................................................................................................... 1
2.1 STANDARDS AND RECOMMENDED PRACTICES .......................................................................................... 1
2.2 GUIDANCE MATERIAL .............................................................................................................................. 1
3.
Link Layer (2)......................................................................................................................................... 1
3.1 STANDARDS AND RECOMMENDED PRACTICES .......................................................................................... 1
3.2 GUIDANCE MATERIAL .............................................................................................................................. 1
3.2.1
Data Link Layer Functions .............................................................................................................. 1
3.2.2
Frame Structure and Formats .......................................................................................................... 2
3.2.3
Transparent Transmission of Bit Strings ......................................................................................... 3
3.2.4
Link States and Modes .................................................................................................................... 3
3.2.5
Numbered Frames and Flow Control .............................................................................................. 4
3.2.6
Error Detection and Recovery ......................................................................................................... 5
3.2.7
Parameters ....................................................................................................................................... 6
4.
Network Layer (3a) ................................................................................................................................ 1
4.1 STANDARDS AND RECOMMENDED PRACTICES .......................................................................................... 1
4.1.1
PVC Procedures .............................................................................................................................. 1
4.1.2
Packet Format.................................................................................................................................. 1
4.1.3
Logical channels.............................................................................................................................. 2
4.1.4
Receiving Unknown Packets and Packets of Less Than Three Octets in Length ........................... 2
4.1.5
Procedure for Initialisation .............................................................................................................. 2
4.1.6
Procedure for Data Transfer ............................................................................................................ 3
4.1.7
Procedure for Reset ......................................................................................................................... 6
4.1.8
Procedure for Restart ....................................................................................................................... 8
4.1.9
Procedure When Link Layer is Out of Order ................................................................................ 10
4.1.10
Diagnostic Code Values ................................................................................................................ 10
4.1.11
Resetting Cause Field Values ........................................................................................................ 11
4.1.12
Restarting Cause Field Values ...................................................................................................... 12
4.2 GUIDANCE MATERIAL ............................................................................................................................ 12
4.2.1
X.25 Packet Layer Functions ........................................................................................................ 12
4.2.2
X.25 Packet Formats ..................................................................................................................... 15
4.2.3
RESTART Procedure .................................................................................................................... 16
4.2.4
RESET Procedure ......................................................................................................................... 16
4.2.5
Flow Control ................................................................................................................................. 19
4.2.6
Error Detection .............................................................................................................................. 19
4.2.7
SVC Set Up and Clearing Procedures ........................................................................................... 19
4.2.8
VC management and SVC implementation .................................................................................. 19
4.2.9
Parameters ..................................................................................................................................... 19
5.
CIDIN Network Layer (3b) ................................................................................................................... 1
5.1 STANDARDS AND RECOMMENDED PRACTICES .......................................................................................... 1
5.1.1
The CIDIN Packet protocol Layer .................................................................................................. 1
5.1.2
The CIDIN Packet Header Format .................................................................................................. 1
5.1.3
CIDIN Packet Procedures ............................................................................................................... 3
5.2 GUIDANCE MATERIAL .............................................................................................................................. 5
5.2.1
Functions of the CIDIN Network Layer .......................................................................................... 5
5.2.2
CIDIN Packet Formats .................................................................................................................... 5
Sixth Edition
Page iii of v

14/04/2011

EUR CIDIN MANUAL

5.2.3
Routing and Relay ........................................................................................................................... 6
5.2.4
Multiple Dissemination ................................................................................................................... 7
5.3 STANDARDS AND RECOMMENDED PRACTICES ON SVC IMPLEMENTATION .............................................. 9
5.3.1
Virtual Circuit Management ............................................................................................................ 9
5.3.2
Virtual Circuit Initialisation .......................................................................................................... 10
5.3.3
Call Establishment ........................................................................................................................ 10
5.3.4
Data Transfer ................................................................................................................................. 15
5.3.5
Disconnection ................................................................................................................................ 15
5.3.6
Reception of a RESET Indication Packet ...................................................................................... 16
5.3.7
Reception of an INTERRUPT Indication Packet .......................................................................... 16
5.3.8
Security and Reliability Aspects ................................................................................................... 17
6.
Transport Layer (4) ............................................................................................................................... 1
6.1 STANDARDS AND RECOMMENDED PRACTICES .......................................................................................... 1
6.1.1
The Transport Protocol Layer ......................................................................................................... 1
6.1.2
The Transport Protocol.................................................................................................................... 1
6.2 GUIDANCE MATERIAL .............................................................................................................................. 8
6.2.1
Functions of the CIDIN Transport Layer ........................................................................................ 8
6.2.2
Entry Centre (Ae) ............................................................................................................................ 8
6.2.3
Exit Centre (Ax) ............................................................................................................................ 10
6.2.4
CIDIN Transport Protocol Formats ............................................................................................... 12
6.2.5
Message Identification and Addressing......................................................................................... 12
6.2.6
Acknowledgement Procedures ...................................................................................................... 14
6.2.7
Error Handling .............................................................................................................................. 14
6.2.8
Form of the Service Interface to the Transport Layer ................................................................... 15
6.2.9
Enquiry (ENQ) procedures............................................................................................................ 17
6.2.10
Flow Control ................................................................................................................................. 17
6.2.11
Parameters ..................................................................................................................................... 17
7.
The AFTN Interface ............................................................................................................................... 1
7.1 INFORMATION MAPPING ............................................................................................................................ 1
7.2 LOGICAL VIEW ......................................................................................................................................... 1
7.3 AFTN HEADER AND MESSAGE PART........................................................................................................ 1
7.4 ADDRESS MAPPING ................................................................................................................................... 2
7.5 PRIORITY MAPPING ................................................................................................................................... 2
7.6 ERROR HANDLING ..................................................................................................................................... 3
7.7 ERRORS REQUIRING OPERATOR ACTION .................................................................................................... 3
8.
Statistics .................................................................................................................................................. 1
8.1 FUNCTIONAL AREAS ................................................................................................................................. 1
8.2 APPLICATION LAYER STATISTICS............................................................................................................... 1
8.3 LAYER 4 STATISTICS ................................................................................................................................. 1
8.4 LAYER 3B STATISTICS ............................................................................................................................... 2
8.5 LAYER 3A/2 STATISTICS ............................................................................................................................ 2
8.6 ADDITIONAL STATISTICS ........................................................................................................................... 2
9.
Testing ..................................................................................................................................................... 1
9.1 INTRODUCTION ......................................................................................................................................... 1
9.2 SCOPE ....................................................................................................................................................... 1
9.3 GENERAL PRINCIPLES ............................................................................................................................... 1
9.4 CIDIN TEST STRATEGY ............................................................................................................................ 1
9.5 DESCRIPTION TECHNIQUE ......................................................................................................................... 2
9.6 PERFORMANCE OF THE TESTS ................................................................................................................... 5
9.7 CONFORMANCE TESTING .......................................................................................................................... 6
9.7.1
General ............................................................................................................................................ 6
9.7.2
Physical Layer ................................................................................................................................. 6
9.7.3
Data Link Layer .............................................................................................................................. 6
9.7.4
X.25 Network Layer ........................................................................................................................ 7
9.7.5
CIDIN Network Layer .................................................................................................................... 9
9.7.6
CIDIN Transport Layer ................................................................................................................. 10
9.7.7
Application Interface ..................................................................................................................... 12
9.8 INTEROPERABILITY TESTING................................................................................................................... 13
9.9 TESTING PHASES IN CIDIN ..................................................................................................................... 16
9.9.1
Conformance testing (single layer - local) .................................................................................... 16
Sixth Edition
Page iv of v

14/04/2011

EUR CIDIN MANUAL

9.9.2
Conformance testing (Single layer - remote) ................................................................................ 16
9.9.3
Interoperability testing (bilateral) .................................................................................................. 17
9.9.4
Interoperability testing (quadrilateral)........................................................................................... 17
9.9.5
Network extension ........................................................................................................................ 18
10. Operational Procedures ......................................................................................................................... 1
10.1 INTRODUCTION OF NEW CIDIN COM CENTRES IN THE INTERNATIONAL NETWORK ................................ 1
10.1.1
Preconditions ................................................................................................................................... 1
10.1.2
Stepwise approach ........................................................................................................................... 1
10.1.3
Routeing arrangements for the Ax of the new COM Centre ........................................................... 1
10.1.4
Introduction of the operational AFTN Routeing Tables ................................................................. 1
10.2 QSP PROCEDURE IN CIDIN OPERATIONS .................................................................................................. 3
10.2.1
Introduction ..................................................................................................................................... 3
10.2.2
Message Types ................................................................................................................................ 3
10.3 ROUTING UPDATE PROCEDURE IN THE CIDIN NETWORK ......................................................................... 4
10.3.1
Purpose of the procedure ................................................................................................................. 4
10.3.2
Procedure and Documentation ........................................................................................................ 4
11. Quality of Service ................................................................................................................................... 1
11.1 INTRODUCTION ......................................................................................................................................... 1
11.2 REQUIREMENTS ........................................................................................................................................ 1
11.3 ENABLERS ................................................................................................................................................. 1
11.4 STANDARD PERFORMANCE MEASUREMENT METHOD ................................................................................ 2
11.4.1
Capacity assessment of a switch ..................................................................................................... 2
11.4.2
Transit time assessment ................................................................................................................... 2
Attachment A: Change Control Mechanism of the EUR CIDIN Manual ............................................... 1
A.1 PROCEDURE FOR DR ................................................................................................................................. 1
A.2 PROCEDURE FOR CP.................................................................................................................................. 1
A.3 TEMPLATE FOR DEFECT REPORTS / CHANGE PROPOSALS ......................................................................... 2

Sixth Edition
Page v of v

14/04/2011

EUR CIDIN MANUAL

1.
1.1

Introduction
Purpose of this Manual

1.1.1

1.1.2

Chapter 1

The objectives of the CIDIN manual are to:

Provide guidance to implementers and users,

Define uniquely the requirements placed on an implementation of the CIDIN


protocols so that implementations may be compatible with each other,

Review the rationale of the protocols,

Define tests to be performed on protocol implementations, and

Describe the interfaces of applications to CIDIN.

The manual is organised into the following format:

Chapter 1 provides an overview of CIDIN and the ISO 7 layer model. Appendix
B details optional parameters of the CIDIN protocol layers.

Chapter 2 describes the physical layer.

Chapter 3 describes the link layer

Chapter 4 describes the network layer. Appendix F contains guidance


information on the implementation of SVCs.

Chapter 5 describes the CIDIN network layer. Appendix G contains detailed


profile information for PVCs and SVCs.

Chapter 6 describes the transport layer. Appendix E contains information on


interface primitives of the state transition diagrams which describe the functions
of the transport layer.

Chapter 7 describes the AFTN interface.

Chapter 8 describes the statistical requirements for CIDIN.

Chapter 9 describes the test strategy for routing implementations. Appendix D


contains detailed material corresponding to this chapter.

Chapter 10 provides information relating to the operation of the CIDIN network.

Chapter 11 provides information relating to Quality of Service.

Sixth Edition
Page 1 of 10

14/04/2011

EUR CIDIN MANUAL

1.2

A Common Network for Various Applications

1.2.1

Existing Services

1.2.1.1

The conventional AFTN represents a large investment in equipment and operations.


Nevertheless it is capable of supporting only one type of application, i.e. those applications
which can communicate via the transmission of AFTN messages. Other types of
applications such as:

interactive computer applications (response times in seconds),

conversational mode between terminals (session relationship between users),

transmission of facsimile data (binary data, not characters), and

file transfer applications (large messages and data volumes)

cannot be supported by AFTN even though the locations of these aeronautical applications
coincide with those normally served by AFTN stations.
1.2.1.2

The installation and maintenance of networks dedicated to one special application is an


inefficient use of valuable resources such as switches, operating personnel etc. There is a
potential cost benefit in a common ICAO network.

1.2.1.3

CIDIN allows the possibility of data interchange between computers and between
terminals and computers.
Applications which fall in this category are:

Air Traffic Services,

Aeronautical Information Service,

Operational Meteorological Service and

Search and Rescue Service.

1.2.1.4

The implementation of CIDIN has significantly improved the operation of the Air
Navigation Services. It is possible that applications as yet not identified will be
implemented using the service provided by CIDIN.

1.2.1.5

Although ICAO is concerned with international data interchange standards, individual


States are equally concerned with any special interfacing or equipment costs that such
standards might impose on national plans. The goal is to minimise interface costs and to
avoid the provisioning of special national facilities significantly different from
international facilities.

Chapter 1

Sixth Edition
Page 2 of 10

14/04/2011

EUR CIDIN MANUAL

1.2.2

CIDIN architecture

1.2.2.1

The Reference Model for Protocol Layers

1.2.2.1.1

The design of CIDIN follows existing standards for data communications and fits into the
ISO 7 layer model. However, because of the design history of CIDIN, it spans two layers
of the model i.e. layers 3 and 4. Because of this, layer 3 has been subdivided into two
layers: 3 (network) and 3b (CIDIN Network).

1.2.2.1.2

Current international communications protocol standardisation work is based on the


Reference Model for Open Systems Interconnection. The concepts of the Reference Model
are contained in the ISO standard ISO 7498 (and its various addenda) and in the
corresponding CCITT recommendation X.200.

1.2.2.1.3

A system, which can communicate with other systems, is an implementation of a collection


of different functions or procedures. (The implementation can be in hardware, software or
in manual procedures.) The basic concept of the Reference Model is to separate the
functions into a number of groups or layers. It describes which communication functions
belong to which layer, without defining any specific communication procedures to execute
the functions. This structure, however, lays down the framework or architecture for the
definition of procedures.

1.2.2.1.4

There are good reasons for dividing the functions in this way:

The rules for communication between a layer in one system and the
corresponding layer in another system (a "protocol") are independent from the
rules for other higher or lower layers. A protocol therefore belongs to a specific
layer and may perform only the functions allowed there. This reduces
considerably the number of different protocols which have to be defined and
implemented. Protocols belonging to the same layer can be easily compared.

The functions resident in the lower layers are basic and hardware-oriented. The
functions in the upper layers are more user- or application-oriented. In principle
it is possible to change the protocol in one layer without affecting the protocols
being used in other layers, allowing considerable system flexibility.

The separation of communication functions into layers with reduced


functionality simplifies the task of defining the protocols.

1.2.2.1.5

The set of functions, which a protocol layer provides to the layer above it (its "user"), is
called the "service" of the layer. Addressing according to the Reference Model takes place
between points ("service access points") at the service interface. In general, it is the task of
a layer to take the service provided to it by the layer below and turn it into a more
application-oriented service for the user of the layer. A service according to the Reference
Model is, however, only an abstract concept and there are no strict requirements for
implementing the service interface corresponding to a particular layer and protocol.

1.2.2.1.6

On the other hand, the protocol executed between two parts of a layer in different systems
(i.e. "the peer-to-peer protocol" or the protocol between two "peer entities") must obey the
same rules in both implementations. The rules are expressed by the exchange of logical units
of data called "protocol data units", PDUs. It follows from the basic principles of the model
that the PDUs of one layer are encapsulated into the PDUs of the layer below it for
transmission. This leads to a nested structure for the PDU headers. When protocol
implementations are tested for compatibility, the adherence to the protocol rules and the
correct coding of the PDUs must be investigated.

1.2.2.1.7

In order to structure the functions of a layer in a more logical way, the Reference Model
allows the separation of a layer into "sub-layers". For example, the structure of the network

Chapter 1

Sixth Edition
Page 3 of 10

14/04/2011

EUR CIDIN MANUAL

layer according to the ISO shows three sub-layers with well defined functions. The principles
defined for the layers of the Reference Model apply correspondingly to sub-layers as well.
1.2.2.1.8

These basic concepts of the Reference Model are illustrated in Figure 1.1.

System A

System B

Users of

Users of

the system

the system

N-service

N-service
Peer-to-peer protocol
of layer (N)

layer N

(N-1)-service

(N-1)-service
layer N-1

Peer-to-peer protocol
of layer (N-1)

physical connection
Figure 1.1 Concepts Used in Connection with the Reference Model for Open Systems
Interconnection

1.2.2.2

The Functions of the Layers

1.2.2.2.1

The Reference Model for Open Systems Interconnection identifies seven distinct layers
with the following functions.

1.2.2.2.2

The application layer is the highest layer and contains the user functions which the system
is designed to perform. The functions of the other layers are subordinate to the application
functions.

Chapter 1

The presentation layer is responsible for negotiating the form in which the
application data are expressed (data syntax) and ensures that the applications are
communicating in the same "language".

The session layer manages the logical relationships between users over time
("sessions") together with synchronisation and dialogue aspects.
Sixth Edition
Page 4 of 10

14/04/2011

EUR CIDIN MANUAL

The transport layer is responsible for the reliable transport of data from end
system to end system independently of the network resources used.

The network layer manages the transmission of data through the network(s)
used with the associated tasks of routing, flow control, error recovery etc.

The link layer has the task of transmitting data across the individual physical
connections in the network.

The physical layer as the lowest layer is concerned with physical interfaces
(interchange circuits and their electrical characteristics).

1.2.2.2.3

The Reference Model recognises two types of relationships between users on some layers,
viz. connection-oriented and connectionless. A connection-oriented relationship involves a
fixed association between communicating partners and can consist of connection
establishment, data transfer and disconnection phases. A connectionless relationship does
not maintain this fixed association.

1.2.2.2.4

In terms of the Reference Model, CIDIN provides its users with a connectionless transport
service.

1.2.2.2.5

CIDIN does not contain implementations of protocols above the transport layer. Applications
using CIDIN are responsible for providing these functions themselves (concerning the
application "AFTN", see section 1.2.2.4).

1.2.2.2.6

CIDIN does not maintain fixed relationships between its users since the service is
connectionless. For applications such as interactive dialogue, a session relationship must be
established by the user (e.g. in a session protocol).

1.2.2.2.7

Since CIDIN provides a transparent transport service, it is "open" in the sense that any
application can use it if the service characteristics are suitable.

1.2.2.3

The CIDIN Protocols

1.2.2.3.1

Figure 1.2 illustrates the architecture of the CIDIN protocols using the concepts of the
Reference Model. In the example, the upper figure shows the spatial relationships between
CIDIN centres and the lower figure the logical relationships between protocol layers.

1.2.2.3.2

The example shows two entry/exit centres (A and C) and a relay centres (B) used for
transmitting a message (a transport PDU) through CIDIN from A to C or vice versa. The
message is not multiply disseminated. The functions of the CIDIN centres (entry/exit or
relay) refer to this particular message: for another path through the network the functions
could be distributed differently.

1.2.2.3.3

The transport protocol (layer 4) is not "seen" in the relay centres: the data expressing the
transport protocol are processed transparently there. This is a necessary feature of the
transport layer since it only has end-to-end significance.

Chapter 1

Sixth Edition
Page 5 of 10

14/04/2011

EUR CIDIN MANUAL

B
Boundary
of CIDIN
Messages

Messages

3b

3b

3a

3a

1
B

routing and relay


functions
A, C = Entry/exit centres
B=

Relay centre performing PVC termination functions in level 3a and


relay functions in level 3b

Figure 1.2 The Functions of CIDIN Centres Related to Protocol Layers


1.2.2.3.4

The network layer (layer 3) consists of the two sub-layers layers 3a and 3b. Layer 3a is a
"network access protocol" while layer 3b is necessary to raise the level of functionality of
the network layer to the required service.

1.2.2.3.5

The two sides of a relay centre operate independently from each other except at their
topmost layer 3b where a bridge (shaded area) joins the two sub-layer entities. The
principal function of this bridge is routing of CIDIN packets.

1.2.2.3.6

In a CIDIN relay centre the two layer 3a entities have no direct relationship. Routing is done
on the next higher sub-layer, in the bridge in sub-layer 3b.

1.2.2.3.7

The connection between centres B and C is shown in the figure to be implemented with a
leased line. As indicated in para.2.2.3, this may also be implemented via a PSN. In this case,
the protocol layers 1, 2 and 3a become network access protocols, accessing the PSN, rather
than being protocols between the centres B and C as in the figure. The protocol on layer 3b

Chapter 1

Sixth Edition
Page 6 of 10

14/04/2011

EUR CIDIN MANUAL

will not be affected by this change, i.e. it remains a protocol between centres B and C and is
transmitted transparently by the PSN.
1.2.2.3.8

Layers 1 to 3a in CIDIN correspond to the CCITT recommendation X.25 for PVCs and
optionally, SVCs. Layers 3b and 4 are special ICAO protocols: no other internationally
standardised protocols fulfil at the moment the requirements of CIDIN on these layers.
Because the CIDIN transport layer provides a transparent transport service to its user,
implementations of the OSI standard protocols for layers 5 and 6 can be used in the
applications supported by CIDIN.

1.2.2.3.9

Major users of CIDIN, interfacing to it with software on top of the transport layer, are the
conventional AFTN and OPMET. Other applications are necessary for network management
i.e. the communication of information relating to network congestion, network configuration,
re-routing, degradation in quality of service, service messages, etc. This message exchange
can be between CIDIN operators and/or network management applications. The design of
CIDIN does not, in principle, restrict the range of other possible user applications which can
be supported.

1.2.2.3.10 The names of the logical information units (PDUs) on the respective layers are as follows:

layer 4 :

CIDIN message

layer 3b:

CIDIN packet

layer 3a:

X.25 packet

layer 2 :

data link frame

1.2.2.4

The AFTN Interface

1.2.2.4.1

Amongst the many possible applications which can be supported, the conventional AFTN
is a special user of CIDIN. AFTN manual teletypewriter procedures, as defined in Annex
10, form essentially a transport protocol according to the classification of the Reference
Model; the higher layer functions being performed manually. For reasons of efficiency, the
CIDIN transport and packet protocols reflect aspects of AFTN message coding. When
transporting an AFTN message, some items of the AFTN message must be mapped onto
the CIDIN transport and packet headers in the entry centre and mapped out of the CIDIN
transport and packet headers at the exit centre. The transport service user called the "AFTN
interface" performs this mapping.

1.2.2.4.2

Figure 1.3 illustrates this situation (compare Figure 1.2) without the intermediate relay
centres. Two CIDIN entry/exit centres are shown together with their associated AFTN
centres and stations. The figure does not imply that AFTN and CIDIN functions should be
implemented on the same or on different equipment; this is a local matter, which does not
need to be standardised. The shaded box represents the interfacing function performing the
mapping. This can be implemented together with the AFTN functions or with the CIDIN
functions.

1.2.2.4.3

Apart from the mapping which is explicitly described in this manual, AFTN messages are
conveyed transparently by CIDIN.

1.2.2.4.4

The format of the AFTN messages is specified in ICAO Annex 10 Volume II. For these
messages the MCF value 2 has been allocated. The fifth character of the Ae/Ax shall be
A.

Chapter 1

Sixth Edition
Page 7 of 10

14/04/2011

EUR CIDIN MANUAL

Transport of AFTN messages via CIDIN:

AFTN
Interface

AFTN
centre

AFTN
Interface
4

3b

3b

3a

3a

CIDIN
entry/exit
centre

CIDIN
entry/exit
centre

AFTN
centre

Logical Equivalent:

Leased Line

Figure 1.3 Logical View of the AFTN Interface to CIDIN

1.2.2.5

The Network Management Interface

1.2.2.5.1

Network Management Messages (commonly referred to as operator messages) enable


operators of CIDIN centres to exchange free-text information within the framework of
CIDIN network management. Unlike the AFTN application, there is no requirement for
destination addressing.

1.2.2.5.2

The structure of the CUDF for Network Management Messages is:

CUDF

Message part
nm_identifier
nm_function +
message_type

Value / Specification
(NM)
OP

message_body

1{line}24 maximum 1968 characters

line

cr + lf + {ia5_printable_characters}80

Note 1: cr carriage return (ia5 encoding)


lf line feed (ia5 encoding)

Chapter 1

Sixth Edition
Page 8 of 10

14/04/2011

EUR CIDIN MANUAL

1.2.2.5.3

For these messages the MCF value 1 has been allocated. The fifth character of the Ae/Ax
shall be M. The value of the priority parameter is from 1 to 8 as determined by the
sending operator.

1.2.2.5.4

A description of the Network Management application parameters is presented in


Appendix B. The format of various types of CIDIN network management messages
(operator, routing, statistics) is specified in appropriate sections of this Manual.

1.2.2.6

The OPMET Interface

1.2.2.6.1

Distribution of alpha-numerical meteorological products (OPMET) is another application


which is supported by CIDIN. Unlike AFTN, there is no special requirement for
destination addressing; rather there are requirements for the mapping of OPMET data onto
the CIDIN User Data Field.

1.2.2.6.2

The format of the OPMET messages is specified in WMO document 386. The structure of
the CUDF for messages in OPMET format is:
Message part
Modified starting line
Abbreviated heading

CUDF

Text (IA-5 only)


End of message signals

Component of the message part


Start of heading (SOH)
Alignment function
Data designators
ICAO location indicator
International date-time group
Optional BBB group
Alignment function
Text of a meteorological bulletin (15000 octets max.)
Alignment function
End-of-text (ETX)

1.2.2.6.3

For these messages the MCF value 3 has been allocated. The fifth character of the
Ae/Ax shall be O. The priority value of OPMET messages is from 1 to 8.

1.2.2.6.4

The format of OPMET operator messages (including MCF) is identical to that of CIDIN
network management messages. However, the fifth and sixth characters of the Ae/Ax are
MM. The priority of OPMET operator messages is 6.

1.2.2.6.5

A description of the CIDIN OPMET and CIDIN OPMET operator message parameters is
presented in Appendix B.

1.2.2.7

The ATN Subnetwork Interface

1.2.2.7.1

When CIDIN is used as an ATN subnetwork, the CIDIN transport service assumes the socalled ATN Subnetwork Access Role. A particular subnetwork dependent convergence
function (CIDIN SNDCF) has been defined for the adaptation of the CIDIN transport
service to the requirements of the ATN inter-network layer. A given ATN Network
Protocol Data Unit is mapped onto one or more CIDIN User Data Fields. Neither the
destination address feature nor the network acknowledgements of the CIDIN are used.

1.2.2.7.2

The CIDIN SNCDF is specified in the ICAO Document 9705-AN/956. Related Guidance
Material, especially for the modelling of the access to the CIDIN transport service, is
provided in ICAO Document 9739-AN/961.

1.2.2.7.3

For the ATN subnetwork role of the CIDIN, the MCF value 4 has been allocated. The
CIDIN priorities 2, 5 and 7 are used. There is no special recommendation for the fifth to
eighth characters of the Ae/Ax used.

Chapter 1

Sixth Edition
Page 9 of 10

14/04/2011

EUR CIDIN MANUAL

1.2.2.7.4

1.3

A description of the CIDIN ATN subnetwork parameters is presented in Appendix B.

Optional Parameters and X.25 Version

1.3.1

The network layer adheres to CCITT X.25 (1980) although this does not restrict the usage
of later versions if experience shows backward compatibility with older CIDIN centres.

1.3.2

A number of configurable parameters are associated with CIDIN. Their values depend on
network design and operating experience. The recommended values are contained in
Appendix B.

Chapter 1

Sixth Edition
Page 10 of 10

14/04/2011

EUR CIDIN MANUAL

2.
2.1

Physical Layer (1)


Standards and Recommended Practices

2.1.1

Analogue or digital transmission means are used for the conveyance of CIDIN data. The
transmission speed shall be agreed bilaterally; it shall be determined according to the data
volume and available infrastructure.

2.1.2

The physical link protocol shall be as described in section 8.6.2 of ICAO Annex 10,
Volume III.

2.2

Guidance Material

2.2.1

The physical layer is the lowest layer and has no service provider. Its function is to make
the data transmission capability of the circuits available to the data link layer in the CIDIN
centre.

2.2.2

Aspects of the data transmission service are:

2.2.3

Transparency

Any bit sequence can be transmitted and received

Full duplex operation

Simultaneous transmission and reception is possible

Line synchronism

Timing signals are provided by the circuit and not by the user

Error detection

The user is notified in the case of physical errors, e.g. circuit failure or loss of
synchronism.

In general, physical circuits for the transmission of data in CIDIN are provided by a
network carrier (e.g. PTT). This means that standards for the interface between the Data
Terminal Equipment (DTE) and the Data Circuit-Terminating Equipment (DCE) have to
be observed. Depending upon the type of circuit or public data network used, specific
CCITT standards for the physical interface are required:
V.24/V.28 describes the interface between DTE and DCE for data transmission via an
analogue circuit, i.e. the way in which the modem is controlled by the DTE and the
electrical characteristics of the signals.
Note. The range of interchange circuits defined in the Recommendation V.24 relates to
various applications and alternative implementations. Thus, in a particular case, only a
subset of interchange circuits will be applicable.
X.21 (including X.24 and X.27) contains a description of the physical interface
between DTE and DCE for synchronous operation on Public Data Networks (PDN).
Note. The PDN may be a packet or circuit switched network.
X.21bis describes the V.24 based physical interface to a PDN.

Chapter 2

Sixth Edition
Page 1 of 2

14/04/2011

EUR CIDIN MANUAL

2.2.4

Chapter 2

The way in which the interface to the physical circuit is made available to the data link
layer in a CIDIN centre is a local matter not subject to standardisation within CIDIN.

Sixth Edition
Page 2 of 2

14/04/2011

EUR CIDIN MANUAL

3.
3.1

Link Layer (2)


Standards and Recommended Practices

3.1.1

Packets to be transferred between two CIDIN switching centres or a CIDIN switching


centre and a PDN shall be formatted into data link frames.

3.1.2

Each data link frame shall consist of a data link control field (DLCF), possibly followed by
a link data field, and shall be terminated by a frame check sequence and flag (being the
second part of the DLCF). If a link data field is present, the frame shall be denoted as an
information frame.

3.1.3

X.25 packets shall be transmitted within the link data field of information frames. Only one
packet shall be contained in the link data field.

3.1.4

The data link protocol shall be as described in section 8.6.4 of ICAO Annex 10, Vol. III.

3.2

Guidance Material

3.2.1

Data Link Layer Functions

3.2.1.1

3.2.1.2

The data link layer provides its users with the capability of sending and receiving bit
strings. Some of its characteristics are:

Transparency

Any bit sequences can be sent and received.

Timing independence

The user is not required to send or receive information continuously but can use the service
randomly according to requirements. The service is "balanced" in the sense that the users
on both sides of the link have equal rights

3.2.1.3

3.2.1.4

Chapter 3

Data integrity

The data link layer effectively guarantees to its users that the bit strings sent and received
are free from bit errors. The probability that bit errors are not detected is very low.

Link establishment

The layer establishes and maintains the logical relationship with its partner
entity

Notification of link failures

The user is notified when the link has failed or has been re-established after a
failure.

The protocol used for the data link layer in CIDIN is a particular variant of the ISO High
Level Data Link Control procedures (HDLC), called LAP-B (Link Access Procedure,
Balanced Class) by CCITT. It is used in a point-to-point configuration. The term
"balanced" means in this context that the communicating DTE and DCE share equal status
with respect to sending and receiving. LAP-B forms layer 2 of the CCITT
Recommendation X.25.

Sixth Edition
Page 1 of 6

14/04/2011

EUR CIDIN MANUAL

3.2.2

Frame Structure and Formats

3.2.2.1

The data units which form the basis of the protocol (protocol data units, PDUs) are called
"frames" (see Figure 3.1). Only complete frames have any significance in the protocol. The
delimiter which marks the beginning and end of a frame is the special bit sequence
01111110, called a flag.

3.2.2.2

The flag is also used to fill the gap between the transmission of frames. The transmission
sequence on the line is therefore:
<flags><frame><flags><frame>
Where:
<flags> represents a sequence of zero or more flags.

3.2.2.3 The structure of a frame is:


F A C information_field FCS F'
Where:
F and F' are flags, F' being optional if another frame follows immediately;
A is an address field;
C is a control field; and
information field represents user data. It is a sequence of octets up to a
maximum length of 259 octets.
FCS is a "frame check sequence"

Data Link
Control Field

Data link Control Field

Flag

Address

Control Field

Frame Check
Sequence

User Data

Figure 3.1 Frame Structure


3.2.2.4

The control field contains a "command" or "response" together with sequence numbers
where applicable. A response is, in general, a reply to a command. A "poll bit" is used in a
command to request a reply from the partner; a "final bit" is an indication whether a
response is a reply to such a request.

3.2.2.5

The address octet may have two values:

Address A
Address B
3.2.2.6

Chapter 3

Bit 8
0
0

0
0

0
0

0
0

0
0

0
0

1
0

Bit 1
1
1

All other address values are invalid. Allocation of addresses is by bilateral agreement
between concerned States (see Parameters, section 3.2.7). Addresses are used to
distinguish between commands and responses: a CIDIN centre uses its own address when
sending a response and the address of its partner when sending a command. See Figure 3.2
for an example. A CIDIN centre consists logically at the data link layer of two parts

Sixth Edition
Page 2 of 6

14/04/2011

Flag

EUR CIDIN MANUAL

("combined"): a "primary" part sends commands and receives responses while a


"secondary" part receives commands and sends responses.
3.2.2.7

3.2.3

The FCS consists of a 16 bit sequence derived from all the preceding bits in a frame
according to a particular algorithm. It is used to show when bit errors have occurred in the
transmission of a frame. The probability that bit errors have occurred without this being
indicated by the FCS is very low.

Transparent Transmission of Bit Strings

3.2.3.1

The information part of a frame can be any bit string. This includes the possibility of the
bit combination for a flag. In order to maintain the integrity and identity of a frame, a flag
must be recognised exclusively as a delimiter. The method for transmitting the bit
combination for a flag without the function of a flag is called "bit stuffing" and operates as
follows.

3.2.3.2

If, when sending information other than flags, a station recognises a continuous sequence
of 5 1-bits, an additional bit set to 0 is inserted into the sending sequence.

3.2.3.3

If, when receiving, a station recognises a sequence of five 1-bits followed by a 0-bit, the 0bit is removed from the bit sequence.

3.2.3.4

This procedure guarantees that any bit string can be transmitted. Figure 3.3 shows the
logical relationships between the bit-stuffing, FCS and flag procedures.

3.2.4

Link States and Modes

3.2.4.1

A link is either in the idle or active state. The idle state is the initial state when the link is
brought into operation, e.g., when one of the stations is still being initialised. The active
state is entered when both stations are transmitting bit sequences recognised by the
procedure. Within the active state, the procedure distinguishes between two modes. The
non-operational and operational modes are called asynchronous disconnected mode
(ADM) and asynchronous balanced mode (ABM) respectively. The modes are
"asynchronous" since the CIDIN centres perform their own timing and scheduling at layer
2 and are co-ordinated only by the elements of the procedure. ABM is "balanced" since the
communicating CIDIN centres have equal status: they are distinguished only by the
differing addresses.

3.2.4.2

The transition of the link between ADM and ABM is affected by the exchange of
"unnumbered" frames i.e. frames which contain no sequence numbers referring to other
frames. The mode transition takes place in general when the CIDIN centre initiating it has
sent an unnumbered command and has received an unnumbered response as a reply. Either
CIDIN centre can initiate a mode transition. The situation in which both centres initiate the
transition simultaneously is known as a contention.

Chapter 3

Sixth Edition
Page 3 of 6

14/04/2011

EUR CIDIN MANUAL

Commands
Primary

Secondary
Responses
Commands

Secondary

Primary
Responses

CIDIN centre with


address A

CIDIN centre with


address B
Command
(B)

Command
(A)

Response
(A)

Response
(B)

Command (B) and


poll bit set

Response (B) and poll


bit set
Command (A) and
poll bit set
Response (A) and
final bit set

Figure 3.2 Example of Combined Operation in the Data Link Layer

3.2.5

Numbered Frames and Flow Control

3.2.5.1

The "numbered" frames are transmitted in operational mode (ABM). The purpose of the
numbering is to permit a sequencing of the frames and to allow one centre to refer to the
frames sent by its partner. The sequence numbers are coded as binary numbers in three bits
and therefore obey the rules of modulo 8 arithmetic.

3.2.5.2

The numbered frames are classified into information and supervisory frames. An
information or I-frame is used to transmit user data while the supervisory frames are used
to control the exchange of I-frames. An I-frame (always a command) carries in its control
field a send sequence number indicating the position of the frame in the string of user data
sent on the link.

3.2.5.3

The sequence numbers provide a means for acknowledging I-frames by the receiving
centre. An acknowledgement gives the sequence number of the next I-frame expected by
that receiving centre thereby implicitly acknowledging all I-frames with send sequence
numbers less than this number. A sending centre may not have more than a certain number
of I-frames unacknowledged. This maximum number of outstanding I-frames is known as
the "window" of a link and is a measure of the buffering capacity on layer 2 of the centres
communicating on it. In order that the I-frames can be identified uniquely with the
sequence numbers, the window size must be less than the modulus of the arithmetic used.

Chapter 3

Sixth Edition
Page 4 of 6

14/04/2011

EUR CIDIN MANUAL

For example, satellite links with their relatively long transmission delays require large
windows and extended numbering.

Sender
A,C and info
fields

Receiver

FCS Correct

A,C and info fields

FCS indicates
transmission error

FCS generation and


checking procedure

FCS recalculated
and compared
with transmitted
FCS

Bit stuffing
procedure

Any sequence of
6 1-bits in
original data
recreated

FCS generated

Sequence of 6
1-bits modified

Frame unpacked
Frame packed
between flags

Flag generation
and detection

Invalid frames
rejected
transmission circuit

Figure 3.3 Relationship between Bit Stuffing, FCS generation/checking and Flag
Processing
3.2.5.4

3.2.6

If the data transmission is taking place in both directions simultaneously,


acknowledgements can be included in the I-frames since the I-frame also contains a
receive sequence number. The supervisory frames also make use of the receive sequence
number for flow control purposes. The supervisory frame "receive not ready" (RNR), for
example, can be used as an acknowledgement but also to indicate that the receiving centre
is temporarily unable to receive further I-frames. Such a command or response would
normally be initiated by a higher protocol layer which is having difficulties in coping with
the data flow. A sending centre can request the sending of a flow control response by
setting the poll bit in a command to 1.

Error Detection and Recovery

3.2.6.1

The LAP-B protocol is capable of detecting a wide range of error conditions and provides
recovery procedures.

3.2.6.2

Bit transmission errors are detected with high probability with the FCS and recovery is
performed by the various elements of the protocol. An invalid frame with no detected bit
errors is rejected explicitly and recovery is performed by other elements of the protocol.
Procedure errors, such as the transmission of a PDU which is logically out of sequence, are
handled by re-initialising the link, e.g. by re-entering ABM. This can be associated with a

Chapter 3

Sixth Edition
Page 5 of 6

14/04/2011

EUR CIDIN MANUAL

loss of user data. The missing send sequence number indicates the loss of an I-frame;
recovery is normally performed with the reject procedure. Missing responses are detected
with time-out procedures.

3.2.7

Parameters

3.2.7.1

Window size
This is the maximum number (k) of information frames that a station may have
unacknowledged. The recommended value for k is 7.

3.2.7.2

Duration of time-out function T1


T1 is the time after which a frame can be retransmitted. T1 must be greater than the time
normally necessary for the sending of a command and the reception of the corresponding
response. The recommended value for T1 is 3 seconds.

3.2.7.3

Repetition counter N2
N2 is the maximum number of times a frame can be retransmitted after the time-out T1.
The recommended value for N2 is 5.

Chapter 3

Sixth Edition
Page 6 of 6

14/04/2011

EUR CIDIN MANUAL

4.

Network Layer (3a)

4.1

Standards and Recommended Practices

4.1.1

PVC Procedures

4.1.1.1

Each CIDIN packet to be transferred on CIDIN circuits between CIDIN switching centres
shall be formatted into one X.25 packet. When PDN circuits are used, it shall be permissible
to format the CIDIN packet into more than one X.25 packet.

4.1.1.2

The integrity of each CIDIN packet shall be preserved by the X.25 packet protocol by
mapping each CIDIN packet onto one complete X.25 packet sequence, as defined in CCITT
Recommendation X.25 (1981/1984).

4.1.1.3

Each X.25 packet shall consist of an X.25 packet header, possibly followed by a user data
field (UDF).

4.1.1.4

The X.25 packet protocol is based on the application of permanent virtual circuit (PVC)
procedures. A permanent virtual circuit shall be defined as a logical path between two CIDIN
switching centres. If a packet switched data network is used to interconnect two CIDIN
switching centres, the procedure shall provide full compatibility with the procedures to be
followed for PVCs according to CCITT Recommendation X.25 (1981/1984). A packet
switched data network providing an X.25 interface to a CIDIN switching centre may offer a
number of options. The following options shall be selected if available:

4.1.1.5

4.1.2

a)

maximum user data field length of 256 octets; and

b)

default window size of seven, or maximum available.

The following descriptions shall apply to the packet layer procedures for permanent virtual
circuits.
a)

A permanent virtual circuit (PVC) is a logical path which conveys data solely from
one PVC termination centre to a single distant PVC termination centre via an
assigned logical channel on each of one or more data links.

b)

A PVC termination centre is a centre which introduces data into, and receives data
from a PVC.

c)

An octet is a group of 8 consecutive bits.

d)

In the over-all centre architecture, packet layer procedures are considered to exist
above the link procedures and below the transport layer procedures.

Packet Format

4.1.2.1

The packet format used shall be one of the following:

4.1.2.2

Data packet (Figure 4.1), comprising:

Chapter 4

a)

the general format identifier;

b)

the logical channel identifier, comprising a logical channel group number and a
logical channel number;

Sixth Edition
Page 1 of 3

14/04/2011

EUR CIDIN MANUAL

c)

the packet type identifier, including the packet receive sequence number P(R), the
packet send sequence number P(S), and the more data bit M which has no
significance on CIDIN circuits and shall be set to zero;

d)

the user data field, comprising up to 256 octets and ending on an integral octet
boundary.

Note.- Data networks operating in the packet mode and connected with CIDIN using
procedures described in ITU CCITT Recommendation X.25-1981 that limit the user data
field to not more than 128 octets may require the use of the m bit. Later versions of
Recommendation X.25 will be reviewed as they are released to ascertain whether or not
they should be adopted.
4.1.2.3

4.1.2.4

4.1.2.5

4.1.2.6

4.1.2.7

RECEIVE READY packet (RR) (Figure 4.2), comprising:


a)

the general format identifier;

b)

the logical channel identifier, comprising a logical channel group number and a
logical channel number;

c)

the packet type identifier, including P(R).

RECEIVE NOT READY packet (RNR) (Figure 4.3), comprising:


a)

the general format identifier;

b)

the logical channel identifier, comprising a logical channel group number and a
logical channel number;

c)

the packet type identifier, including P(R).

RESET REQUEST packet (Figure 4.4), comprising:


a)

the general format identifier;

b)

the logical channel identifier, comprising a logical channel group number and a
logical channel number;

c)

the packet type identifier;

d)

the resetting cause field (see 4.1.11 below);

e)

the diagnostic code (see 4.1.10 below).

RESET CONFIRMATION packet (Figure 4.6), comprising:


a)

the general format identifier;

b)

the logical channel identifier, comprising a logical channel group number and a
logical channel number;

c)

the packet type identifier;

d)

transmission order within each octet.

RESTART REQUEST packet (Figure 4.5), comprising:


a)

Chapter 4

the general format identifier;

Sixth Edition
Page 2 of 3

14/04/2011

EUR CIDIN MANUAL

4.1.2.8

b)

the logical channel identifier, comprising a logical channel group number and a
logical channel number;

c)

the packet type identifier;

d)

the restarting cause field;

e)

the diagnostic code (see 4.1.10 below).

RESTART CONFIRMATION packet (Figure 4.7), comprising:


a)

the general format identifier;

b)

the logical channel identifier, comprising a logical channel group number and a
logical channel number;

c)

the packet type identifier.

4.1.2.9

Each packet shall be completely contained in the link data field of a frame.

4.1.2.10

Only one packet shall be contained in the link data field of a frame.

4.1.2.11

The octets of each packet shall be transferred beginning with octet 1.

4.1.2.12

The bits of each octet shall be transferred beginning with bit 1.

4.1.2.13

The first bit transferred of the logical channel group number, logical channel number, P(R)
and P(S) shall be the arithmetically least significant bit.

transmission order of bits within each octet


8

7
6
5
general format
identifier
0
0
0
1

3
2
1
logical channel
group number

logical channel number

Packet type identifier


P(R)

P(S)

User data field


*

(<= 256 octets )

octet
sequence
1

3
0
4
<=259

* Data networks operating in the packet mode and connected with CIDIN using
procedures described in ITU CCITT Recommendation X.25-1981 may limit the user
data field to not more than 128 octets. Later versions of Recommendation X.25 will
be reviewed as they are released to ascertain whether or not they should be adopted.
Data networks operating in the packet mode and connected with CIDIN using
procedures described in ITU CCITT Recommendation X.25-1981 may limit data
packets to not more than 131 octets. Later versions of Recommendation X.25 will be
reviewed as they are released to ascertain whether or not they should be adopted.
Figure 4.1 Reset request packet format

Chapter 4

Sixth Edition
Page 3 of 3

14/04/2011

EUR CIDIN MANUAL

transmission order of bits within each octet


8

7
6
5
general format
identifier
0
0
0
1

3
2
1
logical channel
group number

logical channel number


P(R)

packet type identifier


0
0
0
0

transmission order of bits within each octet


8

octet
sequence
1

7
6
5
general format
identifier
0
0
0
1

2
1

P(R)

3
2
1
logical channel
group number

logical channel number

7
6
5
4
3
2
1
general format
logical channel
identifier
group number
0
0
0
1
0
0
0
0
logical channel number
0
0
0
0
0
0
0
0
Packet type identifier
1

1
4

0
diagnostic code

1 1
1
0
1
restarting cause field
0
0
0
0
0
0
diagnostic code

Figure 4.4 Reset request packet


format

7
6
5
general format
identifier
0
0
0
1

3
2
1
logical channel
group number

logical channel number

Figure 4.6 Reset confirmation


packet format

4.1.3

1
4
0
5

octet
sequence
1

7
6
5
4
3
2
1
general format
logical channel
identifier
group number
0
0
0
1
0
0
0
0
logical channel number
0
0
0
0
0
0
0
0

3
1

transmission order of bits within each octet

packet type identifier

Octet
sequence
1

Figure 4.5 Restart request


packet format

transmission order of bits within each octet


8

octet
sequence
1

0 1
1
0
1
resetting cause field

packet type identifier


0
0
1
0

transmission order of bits within each octet

Packet type identifier

octet
sequence
1

Figure 4.3 Receive not ready


packet format

transmission order of bits within each octet


7
6
5
general format
identifier
0
0
0
1

3
2
1
logical channel
group number
0
0
0
0

logical channel number

Figure 4.2 Receive ready


packet format

packet type identifier


1
1
1
1
1

Figure 4.7 Restart confirmation packet format

Logical channels

4.1.3.1

Each data link shall carry up to 4 096 logical channels also called virtual circuits (VC).

4.1.3.2

Each logical channel shall be designated by a logical channel identifier, a number between
0 and 4 095, inclusive, which equals the logical channel group number multiplied by 28
and added to the logical channel number.

Chapter 4

octet
sequence
1
2

Sixth Edition
Page 2 of 2

14/04/2011

EUR CIDIN MANUAL

4.1.3.3

On each data link used to construct a VC, a logical channel identifier between 1 and 4 095,
inclusive, shall be assigned solely to that VC.

4.1.3.4

The logical channel identifier assigned to a VC on each data link shall not be required to be
identical to the logical channel identifiers assigned to the same VC on other data links.

4.1.3.5

On each data link, and when specified by the procedures described below, a centre shall
transfer RESTART REQUEST and RESTART CONFIRMATION before transferring any
other packets.

4.1.3.6

On each logical channel, and when specified by the procedures described below, a centre
shall transfer RESET REQUEST and RESET CONFIRMATION before transferring any
other packets on that logical channel.

4.1.3.7

A logical channel shall be in one of the following states:

4.1.3.8

4.1.4

a)

unassigned, indicating the logical channel has not been assigned to carry a VC;

b)

restart, indicating that the procedure for restart has been initiated but not completed;

c)

reset, indicating that the procedure for reset has been initiated but not completed;

d)

flow control ready, indicating that the procedure for data transfer is being executed.

In the event of a restart, reset, reset time-out procedure error, outage or restoration of
service, the operator shall be informed, along with the meaning of resetting cause fields
and diagnostic codes as required.

Receiving Unknown Packets and Packets of Less Than Three Octets in Length

4.1.4.1

Unknown packets, packets of less than three octets in length and over-long packets are
non-valid packets.

4.1.4.2

A centre, which receives a packet with a general format identifier not equal to one of the
general format identifiers specified in 4.1.2 above, shall discard the packet.

4.1.4.3

A centre, which receives a packet of less than two octets in length, shall discard the packet.

4.1.4.4

A centre, which receives a packet of at least two, but less than three octets in length shall:

4.1.4.5

4.1.5

a)

if the logical channel is in the unassigned, restart or reset state, discard the packet;

b)

if the logical channel is in the flow control ready state: execute the procedure for reset
with the resetting cause field indicating "local procedure error" and the diagnostic
field indicating "packet type invalid when in flow control ready state".

A centre which receives a packet with a packet type identifier not defined in 4.1.2 above
shall:
a)

if the logical channel is in the unassigned, restart or reset state, discard the packet;

b)

if the logical channel is in the flow control ready state: execute the procedure for reset
with the resetting cause field indicating "local procedure error" and the diagnostic
field indicating "packet type invalid".

Procedure for Initialisation

Chapter 4

Sixth Edition
Page 2 of 20

14/04/2011

EUR CIDIN MANUAL

4.1.5.1

4.1.6

To simultaneously initialise all logical channels conveyed over a single data link, a centre
shall execute the procedure for restart with the diagnostic code indicating "no additional
information".

Procedure for Data Transfer

4.1.6.1

The following descriptions shall apply to the data transfer procedure:


a)

The transfer lower window edge is the oldest P(S) number associated with the
transfer (outgoing) direction of packets whose corresponding data packet has not yet
been acknowledged by a P(R) transferred from the receiving centre.

b)

The receive lower window edge is the oldest P(S) number associated with the receive
(incoming) direction of packets whose corresponding data packet has not yet been
acknowledged by a P(R) transferred from the receiving centre.

c)

The window size W is the maximum number of packets which shall be transferred in
a given direction on a logical channel before waiting for an acknowledgement from
the receiving centre of the data packet with P(S) equal to the transfer lower window
edge.

4.1.6.2

The data transfer procedure shall operate on each logical channel in the flow control ready
state, independently from any other logical channel on that data link.

4.1.6.3

The data transfer procedure shall operate in each direction of data flow, independently
from the opposite direction of data flow.

4.1.6.4

When a logical channel enters the flow control ready state, the receive and transfer lower
window edges shall be set to 0.

4.1.6.5

W shall normally be 7 but other window sizes may be negotiated on a bilateral basis.
Note.- Public data networks operating in the packet mode and connected with CIDIN using
procedures described in ITU CCITT Recommendation X.25-1981 may require W to be
some other value between 2 and 6, inclusive. Later versions of Recommendation X.25 will
be reviewed as they are released to ascertain whether or not they should be adopted.

4.1.6.6

Arithmetic on lower window edges, P(S) and P(R) shall be performed modulo 8.

4.1.6.7

Receiving data packets

4.1.6.7.1

A centre which receives a data packet on a logical channel which is not in the flow control
ready state shall discard the data packet.

4.1.6.7.2

A centre shall expect the first data packet received after a logical channel enters the flow
control ready state to contain P(S) equal to 0.

4.1.6.7.3

A PVC termination centre which receives a data packet which is less than or equal to the
maximum established length for data packets, and which contains P(S) equal to the next
expected value of P(S), and which contains P(S) less than the receive lower window edge
plus W, shall:

Chapter 4

a)

increment its next expected value of P(S) and, if this value differs from the receive
lower window edge by more than one-half W, execute the procedure to update the
receive lower window edge given in 4.1.6.13;

b)

queue the data packet for processing by the transport layer procedures;

Sixth Edition
Page 3 of 20

14/04/2011

EUR CIDIN MANUAL

c)

if the P(R) is greater than or equal to the transfer lower window edge, and less than or
equal to the P(S) to be assigned to the next data packet for transfer:
1) set the transfer lower window edge to equal P(R);
2) consider all unacknowledged data packets which have been transferred with P(S)
less than the new value of the transfer lower window edge as acknowledged and
delivered to the next centre;

d)

4.1.6.7.4

4.1.6.7.5

4.1.6.7.6

if the P(R) is not greater than or equal to the transfer lower window edge, and not less
than or equal to the P(S) to be assigned to the next data packet for transfer: execute
the procedure for reset with the resetting cause field indicating "local procedure error"
and the diagnostic code field indicating "invalid P(R)".

A centre which receives a data packet which is less than or equal to the maximum
established length for data packets, and which contains P(S) equal to the next expected
value of P(S), and which contains P(S) equal to or beyond the receive lower window edge
plus W, shall:
a)

discard the data packet;

b)

execute the procedure for reset, with the resetting cause field indicating "local
procedure error" and the diagnostic code indicating "invalid P(S)";

A centre which receives a data packet which is less than or equal to the maximum
established length for data packets, and which contains P(S) not equal to the next expected
value of P(S), shall:
a)

discard the data packet;

b)

execute the procedure for reset, with the resetting cause field indicating "local
procedure error" and the diagnostic code indicating "invalid P(S)".

A centre which receives a data packet greater than the maximum established length for
data packets shall:
a)

discard the data packet;

b)

execute the procedure for reset, with the resetting cause field indicating "local
procedure error" and the diagnostic code indicating "packet too long";

4.1.6.8

Transferring RECEIVE NOT READY

4.1.6.8.1

A centre which is becoming temporarily unable to accept further data packets shall transfer
a RECEIVE NOT READY with P(R) equal to the receive lower window edge.

4.1.6.9

Receiving RECEIVE NOT READY

4.1.6.9.1

A centre which receives a RECEIVE NOT READY on a logical channel which is not in
the flow control ready state shall discard the RECEIVE NOT READY.

4.1.6.9.2

A centre which receives a valid RECEIVE NOT READY shall:


a)

if the P(R) is greater than or equal to the transfer lower window edge, and less than or
equal to the P(S) to be assigned to the next data packet for transfer:
1)

Chapter 4

set the transfer lower window edge to equal P(R);

Sixth Edition
Page 4 of 20

14/04/2011

EUR CIDIN MANUAL

2)

consider all unacknowledged data packets which have been transferred with P(S)
less than the new value of the transfer lower window edge as acknowledged and
delivered to the next centre;

3) stop transferring data packets until a RECEIVE READY is received or the logical
channel re-enters the flow control ready state;
b)

if the P(R) is not greater than or equal to the transfer lower window edge, and not less
than or equal to the P(S) to be assigned to the next data packet for transfer, execute
the procedure for reset with the resetting cause field indicating "local procedure error"
and the diagnostic code field indicating "invalid P(R)".

4.1.6.9.3

A centre which receives a non-valid RECEIVE NOT READY shall execute the procedure
for reset, with the resetting cause field indicating "local procedure error" and the
appropriate diagnostic code.

4.1.6.10

Transferring RECEIVE READY

4.1.6.10.1 A centre which was becoming temporarily unable to accept further data packets and thus
transferred one or more RECEIVE NOT READYs, and which subsequently has become
able to accept further data packets, shall transfer a RECEIVE READY with P(R) equal to
the receive lower window edge.
4.1.6.11

Receiving RECEIVE READY

4.1.6.11.1 A centre which receives a RECEIVE READY on a logical channel which is not in the flow
control ready state shall discard the RECEIVE READY.
4.1.6.11.2 A centre which receives a valid RECEIVE READY shall:
a)

if the P(R) is greater than or equal to the transfer lower window edge, and less than or
equal to the P(S) to be assigned to the next data packet for transfer:
1) set the transfer lower window edge to equal P(R);
2) consider all unacknowledged data packets which have been transferred with P(S)
less than the new value of the transfer lower window edge as acknowledged and
delivered to the next centre;
3) resume transferring data packets;

b)

if the P(R) is not greater than or equal to the transfer lower window edge, and not less
than or equal to the P(S) to be assigned to the next data packet for transfer, execute
the procedure for reset with the resetting cause field indicating "local procedure error"
and the diagnostic code field indicating "invalid P(R)";

4.1.6.11.3 A centre which receives a non-valid RECEIVE READY shall execute the procedure for
reset, with the resetting cause field indicating "local procedure error" and the appropriate
diagnostic code.
4.1.6.12

Transferring data packets

4.1.6.12.1 The first data packet transferred in each direction after a logical channel (re-enters the flow
control ready state shall have P(S) equal to 0, and each subsequent data packet shall have a
P(S) equal to the P(S) of the preceding data packet plus one.
4.1.6.12.2 When transferring a data packet, the procedure for updating the receive lower window
edge shall be executed and the P(R) shall then be set equal to the value of the receive lower
window edge.

Chapter 4

Sixth Edition
Page 5 of 20

14/04/2011

EUR CIDIN MANUAL

4.1.6.12.3 A data packet shall not be transferred when the P(S) is equal to or beyond the transfer
lower window edge plus W.
4.1.6.13

Procedures for updating the receive lower window edge (see 4.1.6.7.4 a) and 4.1.6.7.5 a))

4.1.6.13.1 A PVC termination centre shall set the receive lower window edge to equal the next
expected P(S).
4.1.6.13.2 A centre which has changed the value of the receive lower window edge, and which cannot
send a data packet, and which remains temporarily unable to accept further data packets,
shall transfer a RECEIVE NOT READY.
4.1.6.13.3 A centre which has changed the value of the receive lower window edge, and which cannot
send a data packet, and which is able to accept further data packets, shall transfer a
RECEIVE READY.

4.1.7

Procedure for Reset

4.1.7.1

The procedure for reset shall be used to reinitialise a logical channel.

4.1.7.2

A centre shall not initiate the procedure for reset when the logical channel is in the restart
or unassigned state.

4.1.7.3

A centre shall initiate the procedure for reset as follows:


a)

discard all packets waiting to be transferred or acknowledged on the logical channel;

b)

cause the logical channel to enter the reset state;

c)

transfer a RESET REQUEST;

d)

start a 180-second timer T22; and

e)

if the centre is a PVC termination centre for the PVC assigned to the logical channel,
notify the CIDIN packet layer that the PVC assigned to the logical channel is not
usable.

4.1.7.4

Receiving RESET REQUEST

4.1.7.4.1

A centre which receives a valid RESET REQUEST when the logical channel is in the flow
control ready state shall:
a)

discard all packets waiting to be transferred or acknowledged on the logical channel;

b)

immediately transfer a RESET CONFIRMATION;

c)

cause the logical channel to re-enter the flow control ready state;

d)

if the centre is a PVC termination centre for the PVC assigned to the logical channel,
and the resetting cause field is out of order or network out of order, notify the
CIDIN packet layer that the PVC is not usable; and

e)

if the centre is a PVC termination centre for the PVC assigned to the logical channel
and the resetting cause field is network operational or remote DTE operational,
notify the CIDIN packet layer that the PVC is usable.
if the centre is a PVC termination centre for the PVC assigned to the logical channel
and the resetting cause field is DTE originated and the corresponding resetting
diagnostic indication is DTE not operational, notify the CIDIN packet layer that the
PVC is not usable; and

f)

Chapter 4

Sixth Edition
Page 6 of 20

14/04/2011

EUR CIDIN MANUAL

g)

if the centre is a PVC termination centre for the PVC assigned to the logical channel,
the resetting cause field is DTE originated and the corresponding resetting
diagnostic indication is DTE operational, notify the CIDIN packet level that the
PVC is usable.

Note.- Procedures regarding operator initiated resetting are described in 4.1.7.5.6 below.
4.1.7.4.2

A centre which receives a valid RESET REQUEST shall:


a)

cancel T22;

b)

cause the logical channel to enter the flow control ready state;

c)

if the centre is a PVC termination centre for the PVC assigned to the logical channel,
notify the CIDIN packet layer that the PVC assigned to the logical channel is usable.

4.1.7.4.3

A centre which receives a RESET REQUEST when the logical channel is in the restart or
unassigned state shall discard the RESET REQUEST.

4.1.7.4.4

A centre which receives a non-valid RESET REQUEST shall:


a)

if the logical channel is in the flow control ready or reset state, execute the procedure
for reset with the resetting cause field indicating "local procedure error" and the
appropriate diagnostic code.

b)

if the logical channel is in the restart or unassigned state, discard the RESET
REQUEST.

4.1.7.5

Receiving RESET CONFIRMATION

4.1.7.5.1

A centre which receives a RESET CONFIRMATION when the logical channel is in the
flow control ready state shall, execute the procedure for reset with the resetting cause field
indicating "local procedure error" and the diagnostic code indicating "packet type invalid
when in flow control ready state".

4.1.7.5.2

A centre which receives a valid RESET CONFIRMATION when the logical channel is in
the reset state shall:
a)

cancel T22;

b)

cause the logical channel to enter the flow control ready state;

c)

if the centre is a PVC termination centre for the PVC assigned to the logical channel,
notify the CIDIN packet layer that the PVC assigned to the logical channel is usable.

4.1.7.5.3

A centre, which receives a RESET CONFIRMATION when the logical channel is in the
restart or unassigned state, shall discard the RESET CONFIRMATION.

4.1.7.5.4

A centre which receives a non-valid RESET CONFIRMATION shall:

Chapter 4

a)

if the logical channel is in the reset state, execute the procedure for reset with the
resetting cause field indicating "local procedure error" and the diagnostic code.

b)

if the logical channel is in the flow control ready state, execute the procedure for reset
with the resetting cause field indicating "local procedure error" and the diagnostic code
indicating "packet type invalid when in flow control ready state".

c)

if the logical channel is in the restart or unassigned state, discard the RESET
CONFIRMATION.
Sixth Edition
Page 7 of 20

14/04/2011

EUR CIDIN MANUAL

4.1.7.5.5

When T22 expires, the centre shall execute the procedure for reset with the resetting cause
field indicating "local procedure error" and the diagnostic code indicating "timer expired
for reset".
Note.- After unsuccessful retries, the logical channel should be considered out of order.
The RESTART procedure should only be invoked for recovery if re-initialisation of all
logical channels is acceptable.

4.1.7.5.6

Recommendation.- Operator control of PVCs

4.1.7.5.6.1 It should be possible to render a PVC usable or not usable by operator command.
4.1.7.5.6.2 A PVC may be rendered not usable by initiating a RESET REQUEST with the resetting
cause field indicating DTE originated and the diagnostic code indicating DTE not
operational. A PVC may be rendered usable by initiating a RESET REQUEST with the
resetting cause field indicating DTE originated and the diagnostic code indicating DTE
operational. Both local and remote DTEs will stop or start sending packets on the PVC
respectively.
4.1.7.5.6.3 If the DTE initiating a RESET REQUEST to render a PVC not usable receives packets
whilst in a not usable state, it may reassert the not usable state by initiating a RESET
REQUEST with the resetting cause field indicating DTE originated and the diagnostic
code indicating DTE not operational.
4.1.7.5.6.4 If a PVC has been rendered not usable by the remote DTE, it may be rendered usable by
any of the following:

4.1.8

a)

reception of a RESET INDICATION with the resetting cause field indicating DTE
originated and the diagnostic code indicating DTE operational;

b)

reception of data from the remote DTE;

c)

reception of a RESET REQUEST with the resetting cause field indicating remote
DTE operational, network operational or network DTE operational;

d)

reception of a RESTART INDICATION.

Procedure for Restart

4.1.8.1

The procedure for RESTART shall be used to reinitialise a link.

4.1.8.2

A centre shall initiate the procedure for restart as follows:

4.1.8.3

Chapter 4

a)

transfer a RESTART REQUEST;

b)

discard all packets waiting to be transferred or acknowledged on each logical


channel;

c)

cause each logical channel to enter the restart state;

d)

start a 180-second timer T20; and

e)

if the centre is a PVC termination centre, notify the CIDIN packet layer that all PVCs
assigned to logical channels carried on the data link are not usable.

Receiving RESTART REQUEST

Sixth Edition
Page 8 of 20

14/04/2011

EUR CIDIN MANUAL

4.1.8.3.1

4.1.8.3.2

A centre, which receives a RESTART REQUEST with a logical channel identifier equal to
0 and whose logical channels are not in the restart state, shall:
a)

discard all packets waiting to be transferred or acknowledged;

b)

discard all packets waiting to be transferred or acknowledged;

c)

cause each logical channel assigned to carry a PVC to re-enter the flow control;

d)

cause each logical channel not assigned to carry a PVC to re-enter the unassigned
state;

e)

for each PVC assigned to a logical channel carried on the data link, if the centre is a
PVC termination centre, notify the CIDIN packet layer that a restart is occurring.

A centre, which receives a valid RESTART REQUEST with a logical channel identifier
equal to 0 and whose logical channels are in the restart state, shall:
a)

cancel T20;

b)

cause each logical channel assigned to carry a PVC to enter the flow control ready
state;

c)

cause each logical channel not assigned to carry a PVC to enter the unassigned state;

d)

for each PVC assigned to a logical channel carried on the data link, if the centre is a
PVC termination centre, notify the transport layer procedure that a restart is occurring.

4.1.8.3.3

A centre which receives a RESTART REQUEST with a logical channel identifier equal to
0 shall execute the procedure for restart with the appropriate diagnostic code.

4.1.8.3.4

A centre, which receives a RESTART REQUEST with a logical channel identifier not
equal to 0 shall:
a)

if the indicated logical channel is in the flow control ready state, execute the
procedure for reset with the resetting cause field indicating "local procedure error" and
the diagnostic code indicating "restart packet received with non-zero logical channel
identifier".

b)

if the indicated logical channel is in the restart, reset or unassigned state, discard the
RESTART REQUEST.

4.1.8.4

Receiving RESTART CONFIRMATION

4.1.8.4.1

A centre, which receives a RESTART CONFIRMATION with a logical channel identifier


equal to 0 and whose logical channels are not in the restart state, shall execute the
procedure for restart with the diagnostic code indicating "packet type invalid when not in
restart state".

4.1.8.4.2

A centre, which receives a RESTART CONFIRMATION with a logical channel identifier


equal to 0 and whose logical channels are in the restart state, shall:
a)

cancel T20;

b)

cause each logical channel assigned to carry a PVC to enter the flow control ready
state;
cause each logical channel not assigned to carry a PVC to enter the unassigned state;

c)

Chapter 4

Sixth Edition
Page 9 of 20

14/04/2011

EUR CIDIN MANUAL

d)

for each PVC assigned to a logical channel carried on the data link, if the centre is a
PVC termination centre, notify the CIDIN packet layer that all PVCs assigned to logical
channels carried on the data link are usable.

4.1.8.4.3

A centre, which receives a RESTART CONFIRMATION with a logical channel identifier


equal to 0 shall execute the procedure for restart with the appropriate diagnostic code.

4.1.8.4.4

A centre, which receives a RESTART CONFIRMATION with a logical channel identifier


not equal to 0 shall:

4.1.8.4.5

a)

if the indicated logical channel is in the flow control ready state, execute the
procedure for reset with the resetting cause field indicating "local procedure error" and
the diagnostic code indicating "restart packet received with non-zero logical channel
identifier";

b)

if the indicated logical channel is in the restart, reset or unassigned state, discard the
packet.

When T20 expires, the centre shall execute the procedure for restart with the diagnostic
code indicating "timer expired for restart".
Note.- After unsuccessful retries, recovery decisions should be taken at higher layers.

4.1.9

Procedure When Link Layer is Out of Order

4.1.9.1

A centre, which determines that the link layer is out of order on a particular data link shall:

4.1.9.2

4.1.10

a)

discard all packets waiting to be transferred on any logical channel carried on the data
link;

b)

for each PVC assigned to a logical channel carried on the data link, if the centre is a
PVC termination centre, notify the CIDIN packet layer that all PVCs assigned to logical
channels carried on the data link are not usable.

A centre, which determines that the link layer is no longer out of order shall:
a)

execute the procedure for restart;

b)

for each PVC assigned to a logical channel carried on the data link, if the centre is a
PVC termination centre, notify the CIDIN packet layer that the PVC assigned to each
logical channel carried on the data link is usable.

Diagnostic Code Values

Diagnostic indication
No additional information
Invalid P(S)
Invalid P(R)
Packet type invalid when not in restart state
Packet type invalid when in flow control ready state
Packet type invalid on PVCs
Packet too short
Packet too long
Restart packet with non-zero logical channel identifier
Timer expired for reset
Timer expired for restart

Chapter 4

Sixth Edition
Page 10 of 20

Bits of diagnostic code


8 7 6 5 4 3 2
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 1
0 0 0 1 0 0 0
0 0 0 1 1 0 1
0 0 1 0 0 0 1
0 0 1 0 0 1 1
0 0 1 0 0 1 1
0 0 1 0 1 0 0
0 0 1 1 0 0 1
0 0 1 1 0 1 0

1
0
1
0
1
1
1
0
1
1
1
0

14/04/2011

EUR CIDIN MANUAL

Note.- Other bit combinations reserved.


4.1.10.1

When using a packet switched data network to provide a communication path between
CIDIN switching centre, these centres will act as DTEs. According to the CCITT
Recommendations X.25-1981, a DCE prevents values of the resetting cause field other
than 0 given in a RESET INDICATION packet to the DTE, when receiving a RESET
REQUEST from the other end of the PVC. The following diagnostic code values are
additionally recommended to indicate the reason for the reset procedure to an adjacent exit
centre (DTE).
Bits of diagnostic code
8 7 6 5 4 3 2 1
1 0 1 0 0 0 0 1
1 0 1 0 0 0 1 0

Diagnostic indication
DTE operational (Note 2)
DTE not operational (Note 1)

Note 1.- If a DTE receives a REQUEST INDICATION and the centre is a PVC termination
centre for the PVC assigned to the logical channel, notify the CIDIN packet layer that the
PVC assigned to the logical channel is not usable.
Note 2.- If a DTE receives a REQUEST INDICATION and the centre is a PVC termination
centre for the PVC assigned to the logical channel, notify the CIDIN packet layer that the
PVC assigned to the logical channel is usable.

4.1.11

Resetting Cause Field Values

4.1.11.1

When using a packet switched data network to provide a communication path between
CIDIN switching centres, the resetting cause field in reset packets transferred from a CIDIN
switching centre to the data network shall always be equal to 0. Resetting cause fields
received by a CIDIN switching centre from such a network shall be handled in accordance
with 4.1.7.
Bits of resetting cause field
8
7
6
5
4
3
0
0
0
0
0
0
1
x
x
x
x
x
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
1
0
0
0
0
1
0
0
0
0
0
1
1
0
0
0
1
0
0
0
0
0
1
1
1

Resetting cause indication


DTE originated
DTE originated (Note 1)
Out of order (Note 2)
Remote procedure error
Local procedure error
Network congestion
Remote DTE operational (Note 2)
Network operational (Note 2)
Incompatible destination
Network out of order (Note 2)

2
0
x
0
1
0
1
0
1
0
0

1
0
x
1
1
1
1
1
1
1
1

Note 1.- When bit 8 is set to 1, the bits represented by Xs are those indicated by the remote
DTE in the resetting cause field (virtual calls and permanent virtual circuits).
Note 2.- Applicable to permanent circuits only.
Note 3.- Other bit combinations reserved.
4.1.11.2

Chapter 4

When using a packet switched data network to provide a communication path between
CIDIN switching centre these centres will act as DTE. In this case the coding of the
resetting cause field in a reset packet is given as shown in the following table:

Sixth Edition
Page 11 of 20

14/04/2011

EUR CIDIN MANUAL

Resetting cause indication


DTE originated
DTE originated
Out of order
Remote procedure error
Local procedure error
Network congestion
Remote DTE operational
Network DTE operational
Incompatible destination
Network out of order

4.1.12

Bits of resetting cause field


8
7
6
5
4
3
0
0
0
0
0
0
1
x
x
x
x
x
1
0
0
0
0
0
1
0
0
0
0
0
1
0
0
0
0
1
1
0
0
0
0
1
1
0
0
0
1
0
1
0
0
0
1
1
1
0
0
1
0
0
1
0
0
1
1
1

2
0
x
0
1
0
1
0
1
0
0

1
0
x
1
1
1
1
1
1
1
1

Restarting Cause Field Values

4.1.12.1

A centre shall always set the restarting cause field to equal 0.


Note.- Public data networks operating in the packet mode and connected with CIDIN using
procedures described in ITU CCITT Recommendation X.25-1981 may also transfer
restarting cause fields of the following values:

Restarting cause indication


Local procedure error
Network congestion
Network operational

4.2

Guidance Material

4.2.1

X.25 Packet Layer Functions

Bits of restarting cause field


8
7
6
5
4
3
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1

2
0
1
1

1
1
1
1

4.2.1.1
The X.25 packet layer in CIDIN is responsible for the establishment and maintenance of
logical connections which are multiplexed onto data links. The number of possible
connections (4095) is more than adequate for CIDIN. The user can send and receive strings
of octets on these connections at will. The X.25 packet layer provides this service by
transmitting and receiving the data in fixed units called "packets". This leads to a flexible
and efficient use of communication resources and the possibility of adaptation to various
load conditions.
4.2.1.2
The logical connections in X.25 ("virtual circuits") can be of two types: permanent virtual
circuits (PVCs) and switched virtual circuits (SVCs). Connections between CIDIN centres
via dedicated circuits should, by preference, be implemented with PVCs. Although SVCs
are also permitted, the choice of PVCs might lead to less processing overhead when the
circuit needs to be established. Connections between CIDIN centres via PSNs can be
implemented with PVCs or SVCs. The choice will depend on availability, service features
and their cost for the configuration in question.

4.2.1.3

Main and Alternate Connection Paths

4.2.1.3.1

Connection Paths connect a CIDIN centre to another CIDIN centre.

Chapter 4

Sixth Edition
Page 12 of 20

14/04/2011

EUR CIDIN MANUAL

4.2.1.3.2

The connection between CIDIN Centres is normally achieved through a preferred


connection path over a group of Virtual Circuits. This path is called the MAIN Connection
Path (MCP).

4.2.1.3.3

Should connection not be possible through the MCP then an attempt should be made to
connect via the ALTERNATE Connection Path (ACP) group of Virtual Circuits.
Exit Centre to Connection Path Mapping for each Ax
Main Connection Path

Alternate Connection Path

Virtual Circuit Group (1)

Virtual Circuit Group (2)

Note.VCG(1) and VCG(2) shall take different Virtual Circuit routes to different
adjacent CIDIN Centres.

4.2.1.4

Virtual Circuit Group

4.2.1.4.1

A Virtual Circuit Group (VCG) consists of a number of Virtual Circuits (VC) that connects
two, and only two, CIDIN centres. A Primary-type VC is always present and a Secondarytype VC is optional. Within this group, selection of the VC is a local matter. VC groups
form redundant connections between adjacent CIDIN centres. PVCs and SVCs may be
mixed within a VCG according to the table below:
Virtual Circuit Group (VCG)
Primary VC
Secondary VCs
PVC
additional PVCs (optional)
PVC
additional PVCs (optional)
SVC
Not recommended

Option 1
Option 2
Option 3

SVC
Not recommended

Notes. Where:

PVC = Permanent Virtual Circuit


SVC = Switched Virtual Circuit (established by a Virtual Call).

The number of PVCs forming a VCG is subject to bilateral agreement.


Secondary-type VCs are not allowed where the Primary-type VC is an SVC. The Packet
Switched Network (PSN) will provide redundancy in the case of SVCs. Note that it is
recognised that DTE addressing problems can lead to two SVCs being established
simultaneously. However two established SVCs are not permitted.

4.2.1.5

Virtual Circuits

4.2.1.5.1

Virtual Circuits (VC) within a group connect two, and only two, adjacent CIDIN centres.
In general, a VC is defined for Primary-type use (first selected or primary) with a
Secondary-type VC(s) (secondary) as backup. A CIDIN centre will use a Secondary-type
VC only when the Primary-type VC is not operational and vice versa. VCs of this type are
only used to increase the redundancy between adjacent CIDIN centres.

4.2.1.5.2

A VC can be of type PVC (Permanent Virtual Circuit) or SVC (Switched Virtual Circuit).
The PVC is a circuit connection in which a permanent association exists between two
DTEs. The SVC is a circuit connection in which a call set-up (Virtual Call) procedure and
call clearing procedure will determine a period of communication between two DTEs.

Chapter 4

Sixth Edition
Page 13 of 20

14/04/2011

EUR CIDIN MANUAL

4.2.1.6

Adjacent CIDIN Centre

4.2.1.6.1

Adjacent CIDIN centres are those that are connected via a one-hop VCG. In effect, all
centres that support SVC procedures to an interconnected PSN can be adjacent.

4.2.1.7

X.121 Addressing principles

4.2.1.7.1

When connected to a X.25 network a CIDIN Centre shall conform to the X.121 addressing
principles. This is particularly pertinent when connected to a PSN network. An X.121
address is a series of numbers from the 10-digit numeric character set 0-9, which
uniquely identifies a DTE/DCE interface on a given network. The X.121 address is
structured as follows:
DNIC

PNIC

PNTN

Sub Address

14 digits maximum
4.2.1.7.2

The Data Network Identification Code (DNIC) uniquely identifies a given network and
shall consist of four digits.

4.2.1.7.3

The Private Network Identification Code (PNIC) is utilised to identify a specific private
network connected to the public data network and shall consist of 1 to 6 digits. The Private
Network Terminal Number (PNTN) should consist of the full address that is used when
calling the data terminal from within its serving data network. Depending on the Private
Network, the PNTN may be followed by a sub-address. The sub-address is not processed
by the network for routing purposes.

4.2.1.7.4

For routing via Gateways, a 15th digit (namely 0) is used as an international prefix.

4.2.1.8

Characteristics of the PVC service provided by the CIDIN X.25 packet layer are:

PVC initialisation

All PVCs on a data link are initialised with the RESTART procedure.

Independence

The events occurring on one PVC are independent from those on other PVCs

Sequencing

Data is received in the same sequence in which it was sent

Error detection

4.2.1.9

Error detection in addition to that provided by the data link layer is performed. Errors are,
however, reported to the user without error recovery being performed: the RESET
procedure, which is initiated, can lead to packets being lost. Recovery procedures on a
higher layer prevent information loss.

4.2.1.10

Characteristics of the SVC service provided by the CIDIN X.25 packet layer are essentially
the same as those for PVCs (see above) except that the initialisation of virtual circuits by
means of the RESTART procedure does not apply to SVCs. In addition there are circuit
establishment and clearing procedures specifically for SVCs. Detailed guidance on the use
of SVCs can be found in Appendix F. The terminology used in conjunction with PVCs and
SVCs can be found in Appendix G.

Chapter 4

Sixth Edition
Page 14 of 20

14/04/2011

EUR CIDIN MANUAL

4.2.1.11

4.2.2

Layer 3a in CIDIN is composed of a subset of the corresponding CCITT X.25 layer.


Procedures associated with PVCs are mandatory while procedures associated with SVCs
may be implemented as an option. None of the extensions to X.25 (1980) introduced in the
1984 version are used. PVCs logically connect two adjacent CIDIN centres via one data
link. SVCs connect two adjacent CIDIN centres. Both types of virtual circuits appear
identical to their users i.e. to layer 3b.

X.25 Packet Formats

4.2.2.1

The X.25 packet layer provides for a set of logical connections multiplexed on the same
physical link (see Figure 4.8). The data units recognised by the protocol (PDUs) are called
packets. Unlike a frame of the data link layer, a packet is accompanied by a header but no
control information as a trailer. Each packet is transmitted as the user data of one I-frame
of the data link layer.

4.2.2.2

The packet formats associated with PVCs are:

4.2.2.3

4.2.2.4

Chapter 4

data packet

RR packet

RNR packet

RESET REQUEST packet

RESET CONFIRMATION packet

RESTART REQUEST packet

RESTART CONFIRMATION packet.

In addition, the packet formats associated with SVCs are:

CALL REQUEST / INCOMING CALL packet

CALL ACCEPTED / CALL CONNECTED packet.

Each packet format has, in the leading two octets:

a general format identifier and a logical channel group number and

a logical channel number.

Sixth Edition
Page 15 of 20

14/04/2011

EUR CIDIN MANUAL

CIDIN Packet Layer


Centre A

Centre B

PVC3

PV C2

PV C3

PVC2

Centre C

PV C4

X.25
Packet
Layer

PV C4

Data link

Data link
Data Link Layer

Figure 4.8 Relationship between PVCs and the Data Link Layer
4.2.2.5

The general format identifier has the constant value of '0001'. The logical channel number
(one octet) identifies the logical channel on which the packet is (logically) transmitted. The
logical channel group number effectively extends the logical channel number by four bits.
The twelve bits available to identify a logical channel therefore allow a multiplexing
capacity of 4095 logical channels on one data link. The logical channel with a logical
channel identifier of 0 is reserved for special uses. The logical channel in use between two
given CIDIN centres are a set of configuration parameters.

4.2.2.6

The format of the third octet depends on the packet type: a data packet, identified by bit 1
set to 0, contains send and receive sequence numbers and a "more data bit". The other
packet types contain a packet type identifier. In addition, the RR and RNR packets contain
a receive sequence number. Only the data packet carries a user data field. Its maximum
length is 256 octets although this can be restricted to 128 octets by some packet switched
data networks providing a communication path between CIDIN switching centres.

4.2.3

RESTART Procedure

4.2.3.1

4.2.4

The state of a logical channel in which data packets can be transmitted is called "flow
control ready state". The execution of the protocol procedures is, in general, specific to one
particular logical channel, i.e. to the logical channel whose logical channel identifier
appears in the packets. However in order to initialise all logical channels on a link, i.e. to
bring them into flow control ready state, a RESTART procedure is available. This is done
on the logical channel 0. The execution of the RESTART procedure is functionally
equivalent to the execution of the RESET procedure on each logical channel configured.
The RESTART procedure should be performed on each link when initialising a CIDIN
centre.

RESET Procedure

4.2.4.1

Chapter 4

The RESET procedure is used to initialise or re-initialise a particular logical channel. It


consists of the partner initiating the procedure sending a RESET REQUEST packet and
waiting for a RESET CONFIRMATION packet as a reply. The various cases in which
both partners initiate the procedure simultaneously (RESET collision) or in which a reply
is not received within a time-out period are described in the protocol specification. A
logical channel on which a RESET is being performed is temporarily not available for use
by the upper layer.

Sixth Edition
Page 16 of 20

14/04/2011

EUR CIDIN MANUAL

4.2.4.2

Additional information may be carried in RESET REQUEST packets as diagnostic data.


One such use is to allow a DTE to convey to remote a DTE the status of the VC between
them. A CIDIN PVC may be marked as unavailable for the transfer of CIDIN packets
(invalidated) by initiating a RESET REQUEST (cause code 00) with diagnostic code A2.
Conversely, a CIDIN PVC may be marked as available for the transfer of CIDIN packets
(validated) by initiating a RESET REQUEST (cause code 00) with diagnostic code A1.

4.2.4.3

The following tables and diagrams provide an analytical schematic presentation of the
CIDIN PVC Reset Handling procedures.
Event
PVCval
PVCinval
RESIval
RESI

Description
PVC validated by operator
PVC invalidated by operator
PVC validated by a remote DTE
Reset Indication for one of the following events:
reception of data from the remote DTE
reception of RESET Remote DTE Operational
reception of RESET Network Operational
reception of Restart Indication

RSTI
RESRval
RESRinval

Restart Indication
Reset request to validate the PVC
Reset request to invalidate the PVC
Figure 4.9 Table of events for PVC validation/invalidation

PVC Validated
RSTI

PVCval

PVCinval
RESIinval

(internal)

RESI
PVCval
RESIval
PVC Invalidated

PVC Invalidated
(external)

(internal)
PVCinval
(internal)

Figure 4.10 State transition diagram for PVC validation/invalidation

Chapter 4

Sixth Edition
Page 17 of 20

14/04/2011

EUR CIDIN MANUAL

External Events
RESI
RESIinval

RSTI
Initial State

PVC Validated

External Events

PVC Invalidated
(internal)
PVC Invalidated
(external)
RESRinval

RESIval

Internal Events
PVCinval
PVCval

RESRval
Final State

PVC Validated
PVC Invalidated
(internal)
PVC Invalidated
(external)
Implementation
Error

Figure 4.11 State transition table for PVC validation/invalidation

DTE

DCE

Example 1
Reset Request
Invalidate PVC (A2)
Data
Reset Request
Invalidate PVC (A2)
Reset Request Validate
PVC (A1)
Data
ACK

Example 2

Reset Indication
Invalidate PVC (A2)
Data
ACK
Data

Example 3

Reset Indication
Invalidate PVC
Reset Indication
DTE Operational

Data
ACK

Figure 4.12 Examples of the operation of PVC validation/invalidation

Chapter 4

Sixth Edition
Page 18 of 20

14/04/2011

EUR CIDIN MANUAL

4.2.5

Flow Control

4.2.5.1

4.2.6

The flow control mechanisms in the X.25 packet layer are analogous to those in the data
link layer. The flow control on one logical channel is independent from the flow control on
all other logical channels. The procedures involve the use of packet send and receive
sequence numbers and the window technique using modulo 8 arithmetic is equivalent. The
values of the packet send and receive sequence numbers are initialised by the RESET and
RESTART procedures.

Error Detection

4.2.6.1

The X.25 packet layer protocol detects a wide range of error conditions. The actions to be
performed in each case are described in the protocol specification. In the event of errors
associated with data packets, no recovery is performed and user data can be discarded.
Such errors are reported to the user (layer 3b).

4.2.6.2

In the case of procedural errors, RESET or RESTART procedures are initiated. If a


RESET or RESTART procedure cannot be successfully performed, the logical channel in
question is not available for use by the upper layer which must be informed of the
situation. This provides essential information for the routing algorithm of the CIDIN
packet layer.

4.2.7

SVC Set Up and Clearing Procedures

4.2.7.1

Contrary to PVCs, SVCs need only exist when they are required for data transmission.
This opens up the possibility of minimising charges, for example, when using PSNs. There
may be some differences in interpretation of the procedures between the cases DTE-DTE
and DTE-PSN-DTE. The configuration DTE-DTE may also require some additional
bilateral agreements concerning connection parameters. For setting up virtual circuits,
addressing formats according to CCITT X.121 are used.

4.2.7.2

The contents of the User Data field in CALL REQUEST packets may be used by higher
CIDIN layers (e.g. extensions for sub-addressing, security information, etc.) and must be
processed transparently by layer 3a. The length of the field is restricted to 16 octets.

4.2.7.3

For SVC set-up, the calling DTE sends a CALL REQUEST packet which (having been
processed by the network in the case of a PSN) arrives at the called DTE as an
INCOMING CALL packet. The called DTE responds with a CALL ACCEPTED packet,
which arrives at the calling DTE as a CALL CONNECTED packet. A similar procedure
applies for clearing a logical channel.

4.2.8

VC management and SVC implementation

4.2.8.1 A detailed analysis on VC management and SVC implementation is provided in section 5.3.

4.2.9

Parameters
The parameters of the X.25 packet layer are as follows.
Assignment of logical channel numbers to data links
The logical channel numbers are the identification of the X.25 packet layer connection
(VC) on a given link and are necessary because of the multiplexing function. These
must be agreed upon between the CIDIN centres on both ends of the link.

Chapter 4

Sixth Edition
Page 19 of 20

14/04/2011

EUR CIDIN MANUAL

Timers for restart and reset procedures


These timers are commonly known as T20 and T22 respectively and could typically be
of the order of 30 seconds
Packet length
The packet length is normally 256 octets. If a packet switched network is used, the
packet length can be restricted to 128 octets.

Chapter 4

Sixth Edition
Page 20 of 20

14/04/2011

EUR CIDIN MANUAL

5.

CIDIN Network Layer (3b)

5.1

Standards and Recommended Practices

5.1.1

The CIDIN Packet protocol Layer

5.1.1.1

A CIDIN packet header shall precede each transport header and the associated segment.
No further segmentation of the CIDIN message shall be used between transport protocol
layer and CIDIN packet protocol layer. Both headers, therefore, shall be used in
combination. Together they shall be referred to as the Communications Control Field
(CCF). Together with the message segment they form CIDIN packets that shall be
transmitted from entry centre to exit centre(s), when necessary through one or more relay
centres, as an entity.

5.1.1.2

CIDIN packets of one CIDIN message shall be relayed independently via predetermined
routes through the network thus allowing alternative routing on a CIDIN packet basis as
necessary.

5.1.1.3

The CIDIN packet header shall contain information to enable relay centres to handle
CIDIN packets in the order of priority, to transmit the CIDIN packets on the proper
outgoing circuit(s) and to duplicate or multiply CIDIN packets when required for multiple
dissemination purposes. The information shall be sufficient to apply address stripping on
the exit addresses as well as on the addressee indicators of messages in AFTN format.
Note.- Guidance material on address stripping in the CIDIN is contained in the Manual on
the Planning and Engineering of the Aeronautical Fixed Telecommunication Network
(Doc 8259).

5.1.2

The CIDIN Packet Header Format

5.1.2.1

Chapter 5

The CIDIN packet header shall contain the following components:


- Packet looping counter and
message priority indicator

(PLC and MP)

- Exit address(es)

(Ax)

- Destination address(es)

(Ad)

Sixth Edition
Page 1 of 17

14/04/2011

EUR CIDIN MANUAL

5.1.2.2

The CIDIN packet header shall be generated by the entry centre or station and shall be
interpreted by relay centre(s) and exit centre(s) receiving the CIDIN packets.

First bit transmitted


(low order bit)

0 1 1 0 0 0 1
PLC
MP

PACKET LOOPING COUNTER


AND MESSAGE PRIORITY ITEM

1
LENGTH
Ax1

EXIT ADDRESS
ITEM

0 Number of Ads
Ad1
Ad2
Ad3
.
.
Ad15

DESTINATION
ADDRESS
ITEM

0 Number of Ads
Ad16
Ad17
etc.

DESTINATION
ADDRESS
ITEM

Only in
the first
packet
of a
message
in AFTN
format

8 7 6 5 4
3 2 1

Last bit transmitted


Note.- Axs and Ads are specified as IA-5 in Annex 10, Vol. III, Part 1, 8.6.2.5
5.1.2.3

The components contained in the octets of the CIDIN packet header shall be the following.

5.1.2.4

The first item shall contain a five bit packet looping counter (PLC, bits 8, 7, 6, 5 and 4) and
a three bit message priority indicator (MP, bits 3, 2 and 1) which shall be interpreted as
follows:
000
001
010
011
100
101
110
111

Priority 1
Priority 2
Priority 3
Priority 4
Priority 5
Priority 6
Priority 7
Priority 8

5.1.2.5

The five bit packet looping counter (PLC) shall be set to 31 by the entry centre or station.

5.1.2.6

The highest CIDIN priority shall be reserved for CIDIN network management messages.
The remaining priorities shall be available for user messages.

5.1.2.7

The following item of the CIDIN packet header shall contain the exit address(es). The exit
address shall consist of the four-letter location indicator of the concerned exit centre,
followed immediately by one letter identifying a type of user in the CIDIN. If required,
one, two or three additional characters to further identify the application entity. In those
cases where a station is directly connected to CIDIN, the exit address shall consist of the
four-letter indicator of the concerned CIDIN station, followed immediately by one to four
letters identifying a user within that CIDIN station. The total number of letters in an exit

Chapter 5

Sixth Edition
Page 2 of 17

14/04/2011

EUR CIDIN MANUAL

address shall not exceed 8. Upper case letters shall be used only. The number of octets
used by each exit address shall be indicated in bits 1 to 4 of the first octet of each exit
address item. There shall be an exit address item for each exit address to which the CIDIN
packet is to be transmitted. The maximum number of exit addresses in a CIDIN message
shall be 16.
5.1.2.8

If destination addresses (Ads) are used they shall be inserted in the first packet only and
shall be inserted immediately following each associated exit centre address. (See 5.1.2.2
above).

5.1.2.9

The number of destination addresses associated with an exit address shall be indicated in
bits 1 to 4 of each destination address item. The length of each destination address shall be
8 octets.

5.1.2.10

When the number of destination addresses associated with an exit address exceeds 15 an
additional destination address item shall be added following the item containing the first 15
destination addresses. The maximum number of destination addresses associated with an
exit address in a CIDIN message shall be 21.

5.1.3

CIDIN Packet Procedures

5.1.3.1
The CIDIN packet procedures shall be defined for:
a)

entry centres;

b)

relay centres;

c)

exit centres and stations.

5.1.3.2

CIDIN packet header generation

5.1.3.2.1

For each information message submitted, the CIDIN packet layer shall accept the
following elements from the transport layer:
a)

message content, segmented such that the maximum packet length would not be
exceeded if the routing analysis were to require output on a single CIDIN circuit;

b)

exit centre address(es);

c)

CIDIN message priority;

d)

destination address(es), for inclusion in the first packet of messages in AFTN format
only.

5.1.3.2.2

The entry centre shall generate the packet header based on the information given in b), c)
and d), and based on the information derived in the routing analysis process.

5.1.3.3

Routing and relay of CIDIN packets

5.1.3.3.1

All packets shall be sent by the predetermined route available to effect delivery to the exit
address. Where the routing requires that a CIDIN packet be sent to the relay/entry centre
from which it was received, the next most expeditious route shall be used.

5.1.3.3.2

Centres shall be interconnected by one or more VCs. The route shall be defined as that
which requires the least number of traversals to reach the exit centre.

Chapter 5

Sixth Edition
Page 3 of 17

14/04/2011

EUR CIDIN MANUAL

5.1.3.3.3

It shall be permissible to choose between two or more equally expeditious predetermined


routes by any suitable method.

5.1.3.4

Selection of VC for transmission of a CIDIN packet

5.1.3.4.1

Each CIDIN switching centre shall maintain a routing table relating exit addresses with
primary, and if applicable, secondary outgoing VCs.

5.1.3.5

Transmission of CIDIN packets

5.1.3.5.1

Higher priority packets shall be transmitted before lower priority packets.

5.1.3.5.2

The relay of CIDIN packets shall not be delayed unnecessarily.

5.1.3.5.3

The relay of CIDIN packets shall not wait for complete CIDIN message receipt.

5.1.3.5.4

Packets having the same priority shall be transmitted in the order in which they are
received.

5.1.3.6

Action on packets with errors

5.1.3.6.1

When a centre or station receives a packet that does not contain a valid packet header, it
shall discard that packet.

5.1.3.7

Loss of communication

5.1.3.7.1

When a relay centre is notified that a VC is not usable it shall:


a)

discard all packets destined to exit centres for which both primary and secondary
outgoing VCs are not usable;

b)

transmit all packets destined for exit centres for which the primary outgoing VC is
not usable along the secondary outgoing VC to the exit centres;

c)

discard all packets which the routing requires to be sent to the relay/entry centre from
which they were received (see 5.1.3.3.1);

d)

for multi-addressed packets, transmit the packets to those exit addresses for which
communication is possible; and

e)

inform the operator of the action taken.

5.1.3.7.2

When a CIDIN switching centre ceases operation because of equipment failure, it shall,
when it resumes operations, discard all packets which are neither originated by, nor
addressed to it. The action on packets addressed to or originated by the failed centre will be
left for national determination.

5.1.3.8

Handling of multiple dissemination

5.1.3.8.1

A centre, which receives a CIDIN packet for multiple dissemination, shall determine the
outgoing VC on which the CIDIN packets of the CIDIN message shall be transmitted for
each exit address.

Chapter 5

Sixth Edition
Page 4 of 17

14/04/2011

EUR CIDIN MANUAL

5.1.3.8.2

The CIDIN packet header of packets transmitted on each outgoing VC shall contain only
the exit addresses and destination addresses (first packet of messages in AFTN format
only) to be reached via the particular VC. The relay of CIDIN packets shall not result in
unnecessary multiplication of packets. Address stripping shall be applied to Axs and Ads
(messages in AFTN format only) for destinations that cannot be reached via the particular
VC.
Note.- Guidance material on address stripping is contained in Annex 10, Volume II,
Attachment C.

5.1.3.8.3

Relay centres shall not alter the received CIDIN packet headers of CIDIN packets that are
transmitted on a single outgoing VC for all exit addresses specified.

5.1.3.8.4

Relay centres shall compose new CIDIN packet headers for CIDIN packets that are
transmitted on more than one outgoing VC and apply address stripping.

5.1.3.8.5

Centres detecting their own address among the exit addresses shall act as exit centre for
their own address, and as relay centre for the other exit addresses.

5.1.3.9

Action to be taken with packet looping counter

5.1.3.9.1

When a relay centre receives a packet with a PLC value of greater than zero it shall
decrement the PLC by 1 and transmit the packet. If, on receipt, the value of the PLC is zero
the packet shall be discarded.

5.2

Guidance Material

5.2.1

Functions of the CIDIN Network Layer

5.2.1.1

The CIDIN packet layer supplements the X.25 packet layer with the functions necessary to
bring the network up to the functionality required by the CIDIN user. It provides a
connectionless service in transmitting blocks of user data up to a maximum length of 256
octets ("CIDIN packets") through CIDIN. Its functions are:
Accepting message segments and control information from the transport layer
In an entry centre, information is accepted from the transport layer to be relayed
through the network.
Passing message segments and control information to the transport layer
On recognising that a CIDIN packet bears a local exit centre address, a CIDIN exit
centre passes the information on to its transport layer.

5.2.1.2

5.2.2

All packet switched networks require internal protocols to perform routing and relay
functions in addition to the network access functions of a protocol such as X.25. CIDIN is
no exception. The CIDIN packet layer protocol is designed to meet the special needs of
CIDIN.

CIDIN Packet Formats

5.2.2.1

Chapter 5

A CIDIN packet is the unit of data recognised by the CIDIN packet protocol with a
maximum length of 256 octets. It is transmitted as an X.25 user data field in layer 3a. In
the case where the maximum user data field length in layer 3a is 128 octets, the CIDIN
packet is transmitted in two X.25 user data fields. The M bit in the first of these two
Sixth Edition
Page 5 of 17

14/04/2011

EUR CIDIN MANUAL

packets is set to one to indicate that the following packet contains a continuation of the
user data.
5.2.2.2

A CIDIN packet consists of a CIDIN message (or segment of a message) preceded by a


CIDIN transport header and a CIDIN packet header:
CIDIN
packet header

CIDIN
transport header

CIDIN
message or
segment of
message

5.2.2.3

The CIDIN packet and transport headers together are called the "communications control
field". The communications control field may be at the most 256 octets long. Strictly
speaking, according to the principles of the OSI Reference Model, the CIDIN transport
header should be included only with the first segment of a CIDIN message rather than with
every message segment. Its inclusion is necessary because the re-assembly function is
located in the transport layer.

5.2.2.4

The CIDIN packet header consists of header items coded according to the principles
described in Appendix C. The first item is the packet looping and message priority
indicator. It is followed by a sequence of exit addresses or, in the case of the first segment
of messages in "AFTN format", by a sequence of exit addresses with their related
destination addresses. The coding of a message in AFTN format is characterised by the
presence of destination addresses and an indication in the MCF field (see transport
protocol). An exit address item may contain only one exit address while a destination
address item may contain up to 15 fixed length destination addresses.

5.2.2.5

The length of a CIDIN exit address, Ax, is variable up to a maximum of 8 characters. This
maximum length is designed for future requirements when CIDIN is expanded and for the
efficient addressing of applications.

5.2.2.6

The CIDIN packet layer generates the CIDIN packet header on the basis of information
supplied to it by the CIDIN transport layer. The messages are already divided into
segments of the appropriate size.

5.2.3

Routing and Relay

5.2.3.1

The relaying of CIDIN packets through CIDIN is done in layer 3b. Each CIDIN centre
contains a so-called routing table, which is distinct for each centre. In this table, each
possible Ax in CIDIN is associated with a primary and perhaps a secondary virtual circuit.
The discussion below is concerned initially with messages containing only one Ax, i.e.
with non-multiply disseminated messages. The procedure for routing and relay is as
follows:
A CIDIN centre recognising its own address, i.e. Ax = the address of the local CIDIN
centre, passes the CIDIN packet on to the CIDIN transport layer.
A CIDIN relay centre retransmits the CIDIN packet on the primary VC for the Ax
contained in the CIDIN packet if the primary VC is operational.
A CIDIN relay centre retransmits the CIDIN packet on the secondary VC for the Ax
contained in the CIDIN packet if the primary VC is not operational but the secondary
VC is operational.
In various error cases, the CIDIN packet is discarded
When the primary VC fails during the transmission of a message, care shall be taken to
ensure that the message is received in its entirety in the destination nodes. This can be

Chapter 5

Sixth Edition
Page 6 of 17

14/04/2011

EUR CIDIN MANUAL

achieved either by retransmitting the message on the standby VC or transmitting the


residue of the message over the standby VC. In this second case, the packet handling
procedures will ensure that no packets are lost.
5.2.3.2

The retransmission of CIDIN packets follows some priority rules. Each CIDIN packet
carries a priority indicator between 1 (highest) and 8 (lowest) in the CIDIN packet header
(the priority is assigned by an application program). CIDIN packets with the same priority
are retransmitted on a given VC in the same order in which they were received. CIDIN
packets with higher priority are transmitted on a given VC before CIDIN packets with
lower priority.

5.2.3.3

Since the routing is performed using a distributed algorithm, i.e. each CIDIN relay centre
is responsible for its own routing, it is important to guard against paths in the network
which contain infinite or very inefficient loops. These could, for example, come about by
incorrect editing of the routing table in a CIDIN relay centre. For this reason, the packet
looping counter is initially set to a maximum number of "hops" allowed between entry and
exit centre. The packet looping counter is decreased by 1 for each hop and the CIDIN
packet is discarded should the counter reach zero.

5.2.4

Multiple Dissemination

5.2.4.1

A message to be multiply disseminated contains more than one Ax in its CIDIN packet
header. The processing in a CIDIN relay centre at layer 3b of a CIDIN packet belonging to
such a message is logically equivalent to the processing of a set of messages, each of
which is not to be multiply disseminated (note that this is only a logical view of the
procedure and not a recommendation for the implementation). The outgoing CIDIN
packets on the same VC are grouped together into one CIDIN packet. They are identical
except for their address items.

5.2.4.2

The following example illustrates this procedure:


CIDIN packet received at CIDIN
centre E with Axs:

(A,B,C,D,E,F,G)

is first divided logically into a set of


CIDIN packets, each with one Ax:

(A) (B) (C) (D) (E) (F) (G)

and routing is performed logically


on each (see 5.2.3 above). Outgoing
VC:

VC1
(A)(C)(D)

VC2
(B)(G)

VC3
(F)

(A,C,D)

(B,G)

(F)

Before transmission, the CIDIN


packets on VC circuit are combined:

5.2.4.3

A CIDIN packet, which has been relayed, contains only those addresses which are relevant
to its onward path in the network. This procedure is called "address stripping" since it can
appear that addresses have been removed from the original CIDIN packet. Address
stripping in a relay centre is usually associated with the duplication of the CIDIN packet.
When an Ax is removed from the first CIDIN packet of a message in AFTN format, the set
of Ads associated with the Ax are removed as well. In order to demonstrate this feature, the
above example is shown in Figure 5.1 for the case in which the message is in AFTN
format.

5.2.4.4

Figure 5.2 shows an example of a routing table based on a fictitious routing plan. It
demonstrates the use of primary and secondary VCs as well as the way in which a
conventional AFTN switch, EK, is integrated into CIDIN.

Chapter 5

Sixth Edition
Page 7 of 17

14/04/2011

EUR CIDIN MANUAL

Transport
layer
E

CIDIN packet

To application
with address E

VC1

A
C
D

C
D

Incoming VC

E
F
G

VC2
G

exit address
destination addresses
transport header
message segment

VC3

Figure 5.1 Example of Multiple Dissemination

Chapter 5

Sixth Edition
Page 8 of 17

14/04/2011

EUR CIDIN MANUAL

AFTN
EK

EG

EB

LS

LI

KM
EG
CY
EB
See II
EB
EB
LI
KM
See III
KM
KM
LI
KM
KM
KM
EK
LI
KM
LI

III

EB
EB
EB
ED

EB
EB
ED
EG

ED
ED
EB
EB

EG
EG
ED
EG
EG
EG
ED
ED
EG
ED

EB
EB
EB
EB
EB
EB
ED
EB
EB
EB

EB
ED
EF
EG
EI
EK
EL
EN
EP
ES
ET

EB
ED

EB
ED
EK

EG
EG

EG
EG
EK

EB

EB
EK
EK
EK
EK

LB
LC
LE
LF
LG
LH
LI
LK
LL
LM
LO
LP
LR
LS
LT
LX
LY

LO
LI
EB
EB
LI
LO
LI
ED
LI
LI
LO
EB
LO
LS
LI
EB
LO

Primary

ED
ED
EB
EB
ED
ED
ED
ED
ED
ED
ED
EB
ED
ED
ED
EB
ED

Figure 5.2 Example of a Routing Table for EHAM (based on a fictitious routing plan)

5.3

Standards and Recommended Practices on SVC Implementation

5.3.1

Virtual Circuit Management


Virtual circuits are managed within layer 3b.
The operator has access to virtual circuit management functions. He may manually initiate a
RESTART on a link, RESET a virtual circuit, validate or invalidate a PVC and connect or
disconnect an SVC.

5.3.1.1

General specifications

5.3.1.1.1 The list of virtual circuits (PVCs and SVCs) maintained in association with the routing
table(s) in layer 3b is a static description of the configuration relative to all adjacent CIDIN
centres. For each SVC, this includes information on whether the centre can set up the SVC

Chapter 5

Sixth Edition
Page 9 of 17

14/04/2011

Secondary

CIDIN

Exit Centre

CIDIN
ED
EB
ED
EB
EB
ED
ED
ED
ED
ED
ED

Destination

Circuit

Secondary

AFTN

CIDIN

Primary

AFTN

Exit Centre

CIDIN

EG
EG
EG
EB

Destination

Circuit

Secondary

AFTN

CIDIN

Primary

AFTN

Exit Centre

Destination

LO

II
Circuit

A
B
C
D
E
F
G
H
K
L
M
N
O
P
R
S
U
V
W
Z

ED

AFTN

EH

CIDIN

CY

AFTN

KM

EB
EB
ED
ED
EB
EB
EB
EB
EB
EB
EB
ED
EB
EB
EB
ED
EB

EUR CIDIN MANUAL

automatically, by operator intervention, on demand or only when a primary PVC is out of


operation etc. An "idle time" and a "retry interval" are also associated with each SVC.
5.3.1.1.2 Two main timers shall be used:
The Idle timer and
The Retry timer.
Note 1. The Retry timer and the retry interval identify the same object.
The reference to a timer triggered at a Call request generation packet is made. This
timer is named the Call timer.
Note 2.-The way of implementing each timer is not specified; only the function and the
behaviour associated with them is described. The Retry timer and the Call timer may or
may not be the same.
5.3.1.1.3 Dynamic information shall be also maintained on the current status of each virtual circuit. The
information is used whenever a CIDIN packet is entered into an outgoing queue and it is also
used by the outgoing queue handling.
5.3.1.1.4 To facilitate identification:

Each PVC shall be assigned a five-character identifier; the first four characters
being the location indicator of the destination as defined in the relevant ICAO
documentation. The fifth character shall be a sequencing number, starting with 1, to
discriminate between PVCs (also to be used in the event of only one PVC being
used).
In case an SVC is used, it shall be assigned a five-character identifier. The first four
characters shall be the location indicator of the destination as defined in the
relevant ICAO documentation. The fifth character shall be a fixed number. (The
value 9 is being considered)

5.3.1.1.5 The capability shall exist for an established SVC to be cleared when no message has to be
transmitted after the expiration of a configurable timer.
5.3.1.1.6 In normal configurations only one SVC is to be set up between any two centres.
5.3.1.1.7 The X.121 address format shall be used (precision in APPENDIX F).
5.3.1.1.8 Minimum security aspects shall be considered consisting of the incoming call address checking
in the INCOMING CALL (Precision below in the paragraph: 5.3.3.3 and in APPENDIX F).

5.3.2

Virtual Circuit Initialisation

5.3.2.1 When a CIDIN centre (or a part of it) is initialised, all PVCs are initialised with the
RESTART procedure. All SVCs configured to be set up automatically are also connected.
5.3.2.2 If an internal error condition specific to a virtual circuit is detected, e.g. no packet throughput,
then the centre can initiate the RESET procedure on the virtual circuit for a limited number of
times within a given time period. When a RESET INDICATION packet is received, the
RESET procedure should be completed.

5.3.3

Call Establishment

5.3.3.1

Outgoing Call establishment

5.3.3.1.1

Normal Case

Chapter 5

Sixth Edition
Page 10 of 17

14/04/2011

EUR CIDIN MANUAL

5.3.3.1.1.1 For a given direction, as soon as data are to be transmitted and in case no established SVC
exists, an outgoing call shall be set up.
5.3.3.1.1.2 When the conditions for setting up an SVC are satisfied, it should be established with the
CALL REQUEST procedure. A centre which successfully initiates the setting up of an
SVC is considered to be its "owner", and this centre would normally be the one to initiate
the CLEAR REQUEST procedure (see below). An SVC can transmit CIDIN packets in
both directions, independent of which centre initiated the CALL REQUEST.
The figure below describes the principle:
LOCAL CENTRE

SUBNETWORK

REMOTE CENTRE

SVC is Idle
Start Call timer
CALL REQUEST
INCOMING CALL
CALL ACCEPTED
CALL CONNECTED

Stop Call timer


SVC becomes ESTABLISHED
data
data
Figure 5.3 Outgoing call establishment

5.3.3.1.2
5.3.3.1.2.1
5.3.3.1.2.1.1

Connection failure
Call timer elapses
When the Call timer elapses:

the CALL REQUEST shall be disconnected with the generation of a CLEAR


REQUEST with the clearing cause set to 00 (DTE originated),

periodic attempts shall be made to re-establish the SVC.

The figure below describes the principle:

Chapter 5

Sixth Edition
Page 11 of 17

14/04/2011

EUR CIDIN MANUAL

LOCAL CENTRE

SUBNETWORK

REMOTE CENTRE

SVC is Idle
Start Call timer
CALL REQUEST
INCOMING CALL
Call timer elapses
CLEAR INDICATION

CLEAR REQUEST

CLEAR CONFIRMATION

CLEAR CONFIRMATION

SVC is trying to be
re-established periodically
Figure 5.4 Connection failure due to elapsed timer
5.3.3.1.2.2

Call Request Cleared

5.3.3.1.2.2.1 An SVC CALL REQUEST may be cleared by a DTE originated CLEAR REQUEST or
a network initiated CLEAR (CLEAR INDICATION). Periodic attempts shall be made to
re-establish the SVC.
The figure below describes the principle:
LOCAL CENTRE

SUBNETWORK

REMOTE CENTRE

SVC is Idle
CALL REQUEST

CLEAR INDICATION

CLEAR CONFIRMATION

SVC is trying to be
re-established periodically

Figure 5.5 Connection failure due to CLEAR request

Chapter 5

Sixth Edition
Page 12 of 17

14/04/2011

EUR CIDIN MANUAL

5.3.3.2

CIDIN Crossing Call avoidance

5.3.3.2.1

When a Crossing Call is detected, a mechanism shall be set up to manage the situation such
as the call being re-established with an inferior probability for re-occurrence of Crossing
Call.

5.3.3.2.2

When an INCOMING CALL occurs, a CLEAR REQUEST packet shall be generated with
the clearing cause set to 00 (DTE originated).
Note.- The Call cleared may be the INCOMING CALL, the OUTGOING CALL or both of
them depending on the design intended.

5.3.3.2.3

To minimise the occurrence of multiple CIDIN Crossing Call, the specific timer Retry
timer shall be used.

5.3.3.2.4

To avoid multiple CIDIN Crossing Calls, the Retry timer pertaining to the two
communicating CIDIN Centres shall be given different values.
Recommendation.- The value of the Retry timer should be a random value.
Note. Different ways can be set up to implement the Retry timer management.

5.3.3.2.5

After the Retry timer elapses, an Outgoing SVC call shall be retried.
The figure below describes the principle:
LOCAL CENTRE

SUBNETWORK

REMOTE CENTRE

CALL REQUEST

CALL REQUEST

INCOMING CALL

INCOMING CALL

CLEAR REQUEST
CLEAR REQUEST
CLEAR CONFIRMATION
CLEAR CONFIRMATION
SVC is trying to be
re-established

SVC is trying to be
re-established

Figure 5.6 Crossing Call avoidance

5.3.3.3

Incoming Call establishment

5.3.3.3.1

Normal Case
The figure below describes the principle:

Chapter 5

Sixth Edition
Page 13 of 17

14/04/2011

EUR CIDIN MANUAL

LOCAL CENTRE

NETWORK

REMOTE CENTRE

SVC is Idle
CALL REQUEST
INCOMING CALL

CALL ACCEPTED
CALL CONNECTED
SVC is established
data
data
Figure 5.7 Incoming call establishment
5.3.3.3.2

Incoming call refusal

5.3.3.3.2.1 An SVC incoming call shall be refused for the following reasons:

5.3.3.3.2.2

the Calling address is unknown by the Local CIDIN Centre,


an SVC already exists with the Remote CIDIN Centre with the
received CALLING DTE address (only one SVC permitted between
two CIDIN Centres),
a CIDIN Crossing call is detected,
an SVC-type CIDIN exchange with the remote CIDIN Centre is not
possible as either Local or Remote DTE have been disabled.

An SVC Incoming call refused for the reasons listed above shall be cleared with the clear
reason code 00 (DTE originated).
The figure below describes the principle:

LOCAL CENTRE

NETWORK

REMOTE CENTRE
CALL REQUEST

INCOMING CALL

CLEAR REQUEST
CLEAR INDICATION

CLEAR CONFIRMATION
CLEAR CONFIRMATION

Figure 5.8 Incoming call refusal

Chapter 5

Sixth Edition
Page 14 of 17

14/04/2011

EUR CIDIN MANUAL

5.3.4

Data Transfer

5.3.4.1

5.3.5

The transfer of data shall be made under the control of the X.25 flow mechanism which is
the same as for PVCs.

Disconnection

5.3.5.1 Normal case


5.3.5.1.1 The two following cases shall lead to SVC disconnection:

When the Idle timer elapses, meaning that no data have been
transferred before the timer elapses. The SVC is re-established as soon
as pending data exist.

When a CLEAR REQUEST is sent as a result of disabling the SVCtype CIDIN exchange with the remote CIDIN Centre by Operator
command. Outgoing SVC establishment to the remote CIDIN Centre
remains disabled and INCOMING CALLs are rejected (CLEAR
REQUEST) until the SVC-type exchange is enabled by an Operator
command.

The figure below describes the principle:

LOCAL CENTRE

NETWORK

REMOTE CENTRE

SVC is established
data
data

Idle timer elapsed

CLEAR REQUEST
CLEAR INDICATION
CLEAR CONFIRMATION
CLEAR CONFIRMATION
SVC is Ilde
Figure 5.9 SVC disconnection
5.3.5.1.2

Chapter 5

After an idle period during which no CIDIN packets have been transmitted on an SVC in
either direction, the centre which had initiated the CALL REQUEST procedure for the
SVC should start the CLEAR REQUEST procedure. The length of the idle period is a
configurable parameter. The idle period can be set to the value "infinitely long" if the
SVC is not to be cleared automatically. Under exceptional conditions, e.g. a system reset,
either centre using an SVC can start the CLEAR REQUEST procedure.

Sixth Edition
Page 15 of 17

14/04/2011

EUR CIDIN MANUAL

5.3.5.1.3

When an established SVC is set Invalid by an operator command, the established SVC
shall be cleared with the clearing cause code set to 00 (DTE originated).

5.3.5.2 Network or CIDIN Remote Centre disconnection


5.3.5.2.1

5.3.6

After a Clear indication is received the Local CIDIN Centre shall attempt to re-establish
the SVC connection.

Reception of a RESET Indication Packet

5.3.6.1

A RESET Indication packet is received at the Local CIDIN Centre in case the remote
centre (remote DTE) or the network (DCE) request re-initialisation of an established SVC.

5.3.6.2

When a RESET Indication packet is received on an established SVC, the loss of data
packets may occur. As there are data recovery procedures implemented in the transport
layer, the SVC should be cleared in the case of reception of a RESET Indication packet by
a CIDIN centre.

5.3.6.3

A CLEAR REQUEST packet with cause code 00 (DTE originated) and an appropriate
diagnostic code (see Appendix F) is used for clearing the SVC.
Figure 5.10 and Figure 5.11 describe the above principles.

5.3.7

Reception of an INTERRUPT Indication Packet

5.3.7.1

The use of INTERRUPT Indication packets in CIDIN is not recommended. In case of


reception of an INTERRUPT Indication packet, the established SVC shall be cleared.

5.3.7.2

A CLEAR REQUEST packet with cause code 00 (DTE originated) and an appropriate
diagnostic code (see Appendix F) is used for clearing the SVC.
This procedure is similar to the one depicted in Figure 5.10 and Figure 5.11.

LOCAL CENTRE

NETWORK

REMOTE CENTRE
RESET REQUEST

RESET INDICATION

RESET CONFIRMATION
RESET CONFIRMATION
CLEAR REQUEST
CLEAR INDICATION

CLEAR CONFIRMATION

CLEAR CONFIRMATION

Figure 5.10 Reception of RESET Indication packet when re-initialisation is originated by


the DTE (remote centre)

Chapter 5

Sixth Edition
Page 16 of 17

14/04/2011

EUR CIDIN MANUAL

LOCAL CENTRE
RESET INDICATION

NETWORK
RESET REQUEST

RESET CONFIRMATION

REMOTE CENTRE
RESET INDICATION

RESET CONFIRMATION

CLEAR REQUEST

CLEAR REQUEST

CLEAR CONFIRMATION

CLEAR CONFIRMATION

Figure 5.11 Reception of RESET Indication packet when re-initialisation is originated by


the DCE (network)

5.3.8

Security and Reliability Aspects

5.3.8.1

It shall be possible to configure (and check) multiple X.25 addresses for a Remote CIDIN
Centre.

5.3.8.2

If the Calling address is not suitable, the CIDIN Centre receiving the Incoming call packet
shall clear the SVC with the clearing cause set to 00 (DTE originated).

5.3.8.3

In case of a connection to a network, a CIDIN Centre shall be connected physically to at


least one X.25 switch. In the event of DCE disconnection due to a network failure and in
case a second access1 to the network is available, call re-establishment should be made
available via this second access.

To increase reliability, it is recommended to connect CIDIN Centres via two physical links, preferably
belonging to different network switches (DCEs).

Chapter 5

Sixth Edition
Page 17 of 17

14/04/2011

EUR CIDIN MANUAL

6.

Transport Layer (4)

6.1

Standards and Recommended Practices

6.1.1

The Transport Protocol Layer

6.1.1.1

Information exchanged over the CIDIN shall be transmitted as CIDIN messages.

6.1.1.2

The length of a CIDIN message shall be defined by the CIDIN packet sequence number
(CPSN). The maximum permissible length is 215 packets, which in effect results in no
practical limitation.

6.1.1.3

Recommendation.- The maximum CIDIN message length should be restricted to 64 Kbytes.

6.1.1.4

If the length of a CIDIN message and its transport and packet headers (as defined below)
exceeds 256 octets the message shall be divided into segments and placed in the user data
field of CIDIN packets. Each segment shall be preceded by a transport header containing
information to enable the re-assembly of the CIDIN message at the exit centre(s) from
individually received segments and to determine further handling of the received complete
CIDIN message.

6.1.1.5

All segments of one CIDIN message shall be provided with the same message identification
information in the transport header. Only the CPSN and final CIDIN packet (FCP) indicator
shall be different.

6.1.1.6

Recovery of messages shall be performed at the transport layer.

6.1.1.7

Recommendation.- When an entry centre has to make separate transmissions of the same
message to more than one exit centre, the same message identification number (MIN) should
be used for each transmission.

6.1.1.8

The transport protocol shall be as described in 6.1.2 below.

6.1.2

The Transport Protocol

6.1.2.1

The Transport Header Format

6.1.2.1.1

The transport header shall contain the following components:

Chapter 6

Message identification number

(MIN)

Final CIDIN packet indicator

(FCP)

Message code and format or


network management field

(MCF/NMF)

Message type indicator

(MT)

Conversation protect indicator

(CP)

Network acknowledgement indicator

(NA)

Entry address

(Ae)

End of header

(EOH)

Sixth Edition
Page 1 of 17

14/04/2011

EUR CIDIN MANUAL

6.1.2.1.2

The transport header shall be generated by the entry centre and shall be interpreted by the exit
centre(s) receiving the CIDIN packet.

6.1.2.1.3

The transport header shall consist of:

First bit transmitted


(low order bit)
0
LENGTH
MIN
1

MIN ITEM

LENGTH

CPSN

CPSN ITEM

FCP
0

NA CP MT

MCF/NMF
0

LENGTH

ENTRY ADDRESS
ITEM

Ae
1
0 0
0 0
8
7 6
5 4

last bit transmitted


6.1.2.1.4

0
3

0
2

MESSAGE
CHARACTERISTICS
ITEM

0
1

END OF HEADER
ITEM

The components contained within the transport header shall be as follows:

6.1.2.1.4.1 The first item of the transport header shall contain the message identification number (MIN)
expressed in binary form. The low order bit of the MIN shall be bit 1 in the second octet of
the item. Any number of octets between one and four shall be employed to provide the MIN.
The number of octets used by the MIN shall be indicated in bits 1 to 4 of the first octet of this
item. The MIN shall identify the number of a CIDIN message transmitted by a specific entry
centre or station.
6.1.2.1.4.2 Recommendation.- Where the volume of traffic requiring acknowledgement so permits, the
number of MINs used should be limited.
6.1.2.1.4.2.1 At each entry centre or station only one pool of MINs shall be used for information and
network management messages.
6.1.2.1.4.2.2 Only when a CIDIN centre or station fails and the value of the last used MIN is
unrecoverable shall the MIN value be reset to zero. At all other times, the next available MIN
from the MIN pool shall be used.
6.1.2.1.4.3 The second item of the transport header shall contain the following two components:
1) A CIDIN packet sequence number (CPSN), beginning in the second octet of this item,
shall identify the sequence number of each CIDIN packet of a message. The CPSN shall
be assigned in sequence beginning with X0000000. The low order bit of the CPSN shall
be bit 1 of the second octet of this item.
Note.a) If the CPSN item consists of two octets including the header item then the X
(bit 8) in the second octet is the FCP component.
b) In the header item a length indication of 0000 is not used and one octet of
information is represented by a length indication of 0001.

Chapter 6

Sixth Edition
Page 2 of 17

14/04/2011

EUR CIDIN MANUAL

2) A final CIDIN packet (FCP) component (bit 8 of the last octet of this item) which shall be
set to:
1

to indicate the last CIDIN packet of a multi-packet message, or the only


packet of a single-packet message;

to indicate all other packets.

6.1.2.1.4.3.1 The number of octets used by the CPSN and FCP shall be indicated in bits 1 to 4 of the first
octet of this item.
6.1.2.1.4.4 The third item of the transport header shall contain the following four components:
1) A five bit component contained in bits 1 to 5, interpreted according to the setting of bit 6
as either:
a)

message code and format (MCF) component, designating which one of the
code and format types specified (see Table 6-1) is employed in the CUDF
for CIDIN information messages; or

b) a network management function (NMF) component, designating one of 32


network management message types and the means for interpreting the
CUDF (see Table 6-1).
2) A message type (MT) component (bit 6) which shall be set to:
0

to indicate an information message;

to indicate a network management message.

3) A one bit conversation protect (CP) component (bit 7) is reserved for future use.
4) A network acknowledgement (NA) component (bit 8) which shall be set to:
0

to indicate acknowledgement not required;

to indicate acknowledgement required.

6.1.2.1.4.5 The fourth item of the transport header shall contain the entry address (Ae) which identifies
the entry point of a CIDIN message into the CIDIN. The entry address shall consist of the
four-letter location indicator of the concerned entry centre followed immediately by one letter
identifying a type of user in the CIDIN. If required, one, two or three additional characters to
further identify the application entity may be used. In those cases where a user is connected
to the CIDIN via a CIDIN station, the entry address shall consist of the four letter location
indicator of the concerned station, followed immediately by four letters identifying a user
within that CIDIN station. The total number of letters in an entry address shall not exceed 8.
Upper case letters shall be used only. The number of octets used by the Ae shall be indicated
in bits 1 to 4 of the first octet of this item and a length of 0000 shall not be used.
Note.- Normally the entry address of a user is set identically to the exit address
6.1.2.1.4.6 The last item of the transport header shall be the end of header (EOH) item, as shown in
6.1.2.1.3 above.

Chapter 6

Sixth Edition
Page 3 of 17

14/04/2011

EUR CIDIN MANUAL

6.1.2.2

Transport Procedures

6.1.2.2.1

General: The transport procedures shall be defined for:


a)

entry centres;

b)

exit centres

6.1.2.2.1.1 Relay centres shall not perform processing functions at the transport layer.
6.1.2.2.2

Transport header generation

6.1.2.2.2.1 For each information message submitted, the entry centre shall accept the following
elements:
a)

message content (any approved code and format);

b)

exit centre address(es);

c)

destination addresses applicable to each exit centre address;

d)

message priority;

e)

message code/format;

f)

requirement for acknowledgement;

g)

requirement for uninterrupted conversation (future use);

h)

requirement for priority interruptible conversation (future use).

Item c) shall be provided for messages in AFTN format.


6.1.2.2.2.2 The entry centre shall generate the appropriate transport header based on the information
given in e), f), g) and h).
6.1.2.2.3

Message identification number assignment

6.1.2.2.3.1 The entry centre shall assign a MIN value to each message, from a pool of available
numbers. MIN values shall be assigned in continuous numerical sequence.
6.1.2.2.3.2 For CIDIN messages which require network acknowledgement, a given MIN value shall not
be reassigned to a new message until the corresponding network acknowledgement has been
received by the entry centre or station.
6.1.2.2.4

Information message handling

6.1.2.2.4.1 The information message content received from the applications software shall be placed in
one or more CUDF, with no addition or modification (see Figure 1.2). This shall be the
responsibility of the entry centre or station.
6.1.2.2.5

Network management message handling

6.1.2.2.5.1 The entry centre shall generate and respond to network management messages using the
standard format. Network management CUDF contents are generated by the entry centre or
station.
Note.- The format of the network management messages is contained in Table 6-2.

Chapter 6

Sixth Edition
Page 4 of 17

14/04/2011

EUR CIDIN MANUAL

6.1.2.2.6

Recovery procedure for messages on CIDIN

6.1.2.2.6.1 Handling of messages requiring acknowledgement on the transport layer


6.1.2.2.6.1.1 For messages requiring network acknowledgement the entry centre shall, before initiating
transmission, set the NA bit to "1" and temporarily store the message for possible
retransmission. After sending the last frame of the message a response time-out (TMR),
based on the transit time to the most remote exit centre, shall be initiated.
6.1.2.2.6.1.2 After complete and error free receipt of the first packet to arrive of any message requiring
network acknowledgement, the exit centre or station shall start a time-out (TNMA) for that
message; the time-out shall be restarted each time a further CIDIN packet of the same
message is received. The time-out shall be stopped when all packets of the message have
been completely received.
6.1.2.2.6.1.3 At the exit centre or station, once a message with the NA bit set to "1" has been completely
assembled and recorded, a network acknowledgement message shall be sent back to the entry
centre or station.
Note.- The format of the acknowledgement message is contained in Table 6-2.
6.1.2.2.6.1.4 Upon receiving a valid network acknowledgement response from all addressed exit
addresses for the complete message, the entry centre shall remove the corresponding message
from retransmission storage, and shall release the MIN value for future use.
6.1.2.2.6.2 Action on detection of message loss
6.1.2.2.6.2.1 If an entry centre or station does not receive a network acknowledgement message for a
message sent with the NA bit set to "1", within a period of time (TMR) it shall retransmit the
message with the same MIN value.
6.1.2.2.6.2.2 If a network acknowledgement message is still not obtained, the entry centre or station shall
send an enquiry message to that exit address, initiate a message response time-out (TEM) and
shall stop transmissions of information messages to that exit address.
6.1.2.2.6.2.3 When an entry centre or station fails to obtain an acknowledgement even after a retry to the
address, it shall inform the application layer and the operator of the unsuccessful attempt to
communicate. No information messages shall be sent to that exit address until one of the
ENQ messages periodically sent to that address is acknowledged for that address by an ENQ
response.
6.1.2.2.6.2.4 When a multiply disseminated message is not acknowledged for one or more exit addresses,
the entry centre or station, on expiry of time-out (TMR) shall retransmit the message only to
those addresses from which no acknowledgement was received. In this instance the exit
centres shall retain packets of a message for a period of time (TNMA) and discard these
packets if the message is not completed. This time TNMA shall be shorter than or equal to
TMR.
Note.- The format of the enquiry message is contained in Table 6-2.
6.1.2.2.6.2.5 On receipt of an enquiry message, the exit centre shall acknowledge the enquiry message by
transmitting an enquiry response message back to the entry centre or station.
Note.- The format of the enquiry response message is contained in Table 6-2.
6.1.2.2.6.2.6 Once the entry centre has received the enquiry response message, it shall resume sending
information messages to that exit address and inform the operator of this event.

Chapter 6

Sixth Edition
Page 5 of 17

14/04/2011

EUR CIDIN MANUAL

Note.- ENQ response messages received without a preceding ENQ message shall be logged
and reported to the operator, but the response message will not be taken as a valid data
exchange.
6.1.2.2.6.2.7 When a response to an enquiry message is not received within a period of time (TEM), the
entry centre or station shall retransmit the enquiry message.
6.1.2.2.6.2.8 When the exit centre or station time-out period expires before all packets of the message
have been completely received, the exit centre or station shall discard the incomplete
message.
6.1.2.2.7

Handling of messages not requiring acknowledgement on the transport layer

6.1.2.2.7.1 After complete and error-free receipt of the first packet to arrive of any message not requiring
network acknowledgement, the exit centre or station shall start a time-out (TNMA) for that
message. The time-out shall be restarted each time a further CIDIN packet of the same
message is received. The time-out shall be stopped when all packets of the message have
been completely received.
6.1.2.2.7.2 When the exit centre or station time-out period expires before all packets of the message have
been completely received, the exit centre shall discard the incomplete message.
6.1.2.2.8

Handling of messages with unacceptable code/format combinations

6.1.2.2.8.1 When an exit centre or station receives a message, requiring or not requiring an
acknowledgement which is in a code and format for which it has no applications software, it
shall discard the message, and send an MCF error message to the entry centre or station.
Note.- The format of the MCF error message is contained in Table 6-2.
6.1.2.2.8.2 On receipt of an MCF error message, the entry centre or station shall notify the application
layer.
6.1.2.2.9

Handling of multiple dissemination messages

6.1.2.2.9.1 For messages requiring multiple dissemination, the recovery procedures shall take place
between the entry centre and all exit centres concerned.
Table 6-1:

Significance of MCF and NMF indicators

MCF/NMF value
b5
b4
b3

b2

b1

Meaning
MCF (MT = 0)

NMF (MT = 1)

0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0

0
0
1
1
0
0
1
1
0
0
1
1
0
0
1
1

0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1

Reserved
Network management messages
AFTN
OPMET
ATN

Not yet allocated

Not yet allocated

Reserved
Network management messages
Enquiry
Acknowledgement
Enquiry response
Not yet allocated

MCF error
Not yet allocated

Not yet allocated

0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1

Chapter 6

0
0
0
0
1
1
1
1
0
0
0
0
1
1
1
1

Sixth Edition
Page 6 of 17

14/04/2011

EUR CIDIN MANUAL

MCF/NMF value
b5
b4
b3
1
0
0
1
0
0
1
0
0
1
0
0
1
0
1
1
0
1
1
0
1
1
0
1
1
1
0
1
1
0
1
1
0
1
1
0
1
1
1
1
1
1
1
1
1
1
1
1

b2
0
0
1
1
0
0
1
1
0
0
1
1
0
0
1
1

b1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1

Meaning
MCF (MT = 0)
Not yet allocated

Not yet allocated

Reserved for regional use

Table 6-2:

Format for network management messages

NETWORK MANAGEMENT
MESSAGE
C
O
M
M
U
N
I
C
A
T
I
O
S
C
O
N
T
R
O
L
F
I
E
L
D

CIDIN
PACKET
HEADER

T
R
A
N
S
P
O
R
T
H
E
A
D
E
R

NMF (MT = 1)
Not yet allocated

Not yet allocated

Reserved

ACK

ENQ

MP

Enquiry
response

MCF error

Note c)

Note a)

000

Ax

Note a)

Note b)

MIN

next available

CPSN

all zero

FCP

MCF/NMF

see Table 6-1

MT

CP

NA

Ae

Note b)

Note a)

EOH

Note d)

1 000 0000
0100

CIDIN USER DATA FIELD

LENGTH
Note e)
0001
LENGTH
Note f)
0101
LENGTH
Note g)

NOTES:
a) Use the Ae of the original information message
b) Use the Ax of the original information message
c) Use the Ae of the original information message
d) Use the Ax identifier of own centre or station to
which the message refers

Chapter 6

Note b)

0100
NONE

NONE

LENGTH
Note e)
0001
LENGTH
Note f)
0101
LENGTH
Note g)

e) Use the MIN of the original information message


f) Use the Ax of the original information message
g) Use the CPSN of the last packet of the received
CIDIN message. Bit 8 shall be set to 0.

Sixth Edition
Page 7 of 17

14/04/2011

EUR CIDIN MANUAL

6.2
6.2.1

Functions of the CIDIN Transport Layer

6.2.1.1

The CIDIN transport protocol has been designed to perform efficiently those end-to-end
functions required of CIDIN not provided by the network layer. The network layer does
not, for example, consider the message as a whole and processes only individual segments
of it in the CIDIN packets. An end-to-end acknowledgement procedure is also not
contained in the network layer.

6.2.1.2

The CIDIN transport layer contains the end-to-end control functions of the message
transport service provided by CIDIN. The protocol is executed between entry and exit
centres and is handled transparently by other centres for a given message.

6.2.2

6.2.2.2.1

Guidance Material

Entry Centre (Ae)

6.2.2.1

Entry Centre Functions

6.2.2.1.1

Segmenting: Transport PDUs (messages) are divided into segments which will fit into 256
octet CIDIN packets at the entry centre.

6.2.2.1.2

Transmission of AFTN parameters: A special user of the transport layer is the AFTN
interface. Indicators specific to this user (AFTN destination addresses, and priority) are
transmitted.

6.2.2.1.3

Detection that an acknowledgement is missing: As a first recovery step, the message is


retransmitted. If an acknowledgement is still not obtained, the entry centre starts sending
ENQ messages to that Ax and does not send further information messages to that exit
centre until a reply has been received.

6.2.2.2

Entry Centre Finite State Machine

A simplified form of the state transition diagram for the transport entry centre module is shown in
Figure 6.1 and the corresponding state transition table in Table 6-3. A description of primitives, states
and events can be found in Appendix E.

Chapter 6

Sixth Edition
Page 8 of 17

14/04/2011

EUR CIDIN MANUAL

TIMconf
MCF error

TIMconf
ACK

IDLE
TPind
ACK

TIMconf
MCF error

TIMconf
ACK

TPind
MCF error

ATEM
SENQ

SME
ATMR
TPind
MCF error

TPind
ACK
SME
ATMR

WAIT2

TEM
timeout

TIMreq
TS user

TMR
timeout

WAIT1

SME
ATMR*

TPind

Resp ENQ
TMR
timeout

TIMconf
ATEM
SENQ

Legend: events
Action
* other actions possible

Figure 6.1 State Transition Diagram for the Entry Centre Module of a Transport Entity
(Simplified)

Table 6-3:

State Transition Table for the Entry Centre Module of a Transport


Entity
External Events
TIMreq
TS user

IDLE
Initial State

SME

Internal
Events

Chapter 6

TMR

TEM

TIMconf MCF
TIMconf Ax
out of service

SENQ

ATMR

TIMconf ACK
External
Events

TPind
resp
ENQ

WAIT2

TPind
MCF
error

TPind
ACK

WAIT1

Internal Events

ATEM

Sixth Edition
Page 9 of 17

14/04/2011

EUR CIDIN MANUAL

External Events
TIMreq
TS user

WAIT1

TPind
MCF
error

TPind
resp
ENQ

TMR

WAIT2
Implementation
error

6.2.3

TEM

IDLE

Final State

TPind
ACK

Internal Events

Exit Centre (Ax)

6.2.3.1

Exit centre Functions

6.2.3.1.1

Reassembling: Transport PDUs (messages) are reassembled from CIDIN packets at the
exit centre.

6.2.3.1.2

Network acknowledgement: Messages (e.g. AFTN messages) can be given to the


transport layer with the requirement that they be acknowledged within CIDIN. This
acknowledgement has end-to-end significance between entry and exit centres and gives a
high level of confidence in the message transport. For multiple disseminated messages, this
procedure applies to each entry/exit centre pair as though the messages were sent as a set
of non-multiple disseminated messages.

6.2.3.1.3

Detection of an incomplete message: An incomplete message is detected in an exit centre


when one or more CIDIN packets do not arrive in due time. The incomplete message is
discarded and no automatic recovery is performed.

6.2.3.1.4

Detection of unacceptable code/format combinations: An exit centre, which detects this


condition, discards the complete message and sends an error message to the entry centre.
On receiving an error message, an entry centre transport layer notifies its user.

6.2.3.2

Exit Centre Finite State Machine

6.2.3.2.1

A simplified form of the state transition diagram for the transport entry centre module is
shown in Figure 6.2 and the corresponding state transition table in Table 6-4. A description
of primitives, states and events can be found in Appendix E.

Chapter 6

Sixth Edition
Page 10 of 17

14/04/2011

EUR CIDIN MANUAL

TIMind:
TPreq*1

TPind
ENQ
TPreq
ENQ

UNASSIGNED

discard
message

TPind
FCP=1
TIMind:
TPreq*1

TPind
FCP=0
ATMA

ATNMA

TPind
FCP=0

TNMA

TPind
FCP=1

IN_PROCESS
Legend: events
action
Tpreq*1 = ACK or MCF as appropriate
Figure 6.2 State Transition Diagram for the Exit Centre Module of a Transport Entity
(Simplified)

Table 6-4:

State Transition Table for the Exit Centre Module of a Transport Entity
External Events

UNASSIGNED
Initial state

TPind
FCP=1

TPind
FCP=0

TPind
ENQ

IN_PROCESS

External events

Internal Events

TIMind

TPreq*1

TNMA

TPreq ENQ

ATNMA
Internal events

discard message
UNASSIGNED
Final state

IN_PROCESS

Implementation
error

Chapter 6

Sixth Edition
Page 11 of 17

14/04/2011

EUR CIDIN MANUAL

6.2.4

CIDIN Transport Protocol Formats

6.2.4.1

The structure of the CIDIN packet is shown in Figure 6.3. The transport header precedes
the segment of user data and, although it is present in every CIDIN packet, it is processed
only in the entry centre where it originates and in the addressed exit centre.

256 octets
CIDIN packet header

CIDIN transport header

Processed in
each CIDIN
centre

Processed in
each entry and exit
centre

Message segment
Transparent to CIDIN

Data communications field


Figure 6.3 Structure of a CIDIN Packet

6.2.4.2

The transport header consists of 5 header items coded according to the principles
described in Appendix C.
The MIN and Entry address items identify the message uniquely.
The CPSN item indicates the position of the message segment in the complete message
and whether the segment is the final one in the message.
The message characteristics item indicates the type of processing required for the
message.
The entry address item gives the address of the CIDIN centre at which the CIDIN
message was generated.
The end of header item delimits the header.

6.2.5

Message Identification and Addressing

6.2.5.1

When the user of the transport layer requests a message to be sent, the transport layer
generates a number (the MIN) to identify the message. Each entry centre generates MINs
independently so that the combination of entry centre address and MIN should identify
uniquely a message known to the whole of CIDIN at any one time. There will be only one
MIN pool per centre. The MINs will be allocated in numerical order, step size 1, starting
value 0, and will be re-used after reaching maximum value (wrap-around). The uniqueness
requirement implies that the entry centre, when generating MINs, should use as large a
pool as possible. However the size of the MIN represents a transmission overhead and
should therefore be restricted to a maximum size of four octets. The MIN and entry address
are used in the exit centre for reassembling the CIDIN packets into distinct messages and
for identifying the messages end-to-end in the acknowledgement or error procedures. As
such, the MIN should not be reset to zero other than when it roles over from its maximum
value or due to a failure of a centre which renders the last MIN unrecoverable.
Note 1.- Care should be taken that the MIN pool is sufficiently large to prevent MINs reused within a specific time period; 48 hours minimum, 31 days recommended.

Chapter 6

Sixth Edition
Page 12 of 17

14/04/2011

EUR CIDIN MANUAL

Note 2.- For the re-use of MIN no check on the acknowledgement of the message for which
it was previously is necessary.
6.2.5.2

In order to avoid any misunderstanding with regard to referencing of messages the MIN
should be presented to the operator as a decimal number.

= message parameters such as Ae of sender


= message parameters such as addressed remote Axs
= message parameters such as Ads
Application 1

Application 2

Ax1

Ax2

Application 3 e.g. AFTN Interface

Ax3

Common service
access point

Figure 6.4 Segmenting, Re-assembly and Addressing in the Transport Layer


6.2.5.3

Chapter 6

When passing messages up to the application programs, the exit addresses Ax are the
standard means of addressing the users of CIDIN (transport users) - see Figure 6.4. The
Axs are therefore the "transport service access point identifiers" in OSI terminology. There
should be a one-to-one correspondence between application processes and Axs. The
interactions between the users and the transport layer are a local matter and the way in
which they are implemented is not a subject for standardisation. This includes the way in
Sixth Edition
Page 13 of 17

14/04/2011

EUR CIDIN MANUAL

which a user registers with the transport layer when operational, the transfer of messages,
etc. An entry centre is not required to check the compatibility of the MCF with the Axs of
the message.

6.2.6

Acknowledgement Procedures

6.2.6.1

When sending a message, a user of the transport layer can indicate whether the message
should be acknowledged end-to-end within CIDIN. The acknowledgement procedure
functions in an entry centre as follows: a transport entity must first store a message
requiring acknowledgement for possible subsequent retransmissions. After segmenting the
message and passing it down to the CIDIN packet layer, it waits for an acknowledgement
to be received from the addressed exit centre. After receiving the acknowledgement, the
temporary storage can be deleted. If no acknowledgement is received, the transmission is
repeated and if an acknowledgement is still not received within a reasonable time, the
application is informed. The address in question is thereafter polled at regular intervals and
no further messages may be sent to it until a positive response has been obtained to this
polling.

6.2.6.2

The acknowledgement procedure for a message which is multiply disseminated is logically


equivalent to the case in which a simple message (not multiply disseminated) is sent to
each Ax addressed.

6.2.6.3

The acknowledgement procedure can lead, in some very rare cases, to a message being
received twice. For example, an acknowledgement can cross a retransmitted message in the
network, implying that the re-transmitter timer, TMR, has been set to too low a value. An
entry centre transport entity must therefore be able to cope with the reception of two
acknowledgements for the same message. The action performed by the exit centre
receiving the same message twice is a local matter: it could pass the duplicated message on
to the user or it could apply an ageing process to Ae/MIN combinations of messages
received. The possibility of duplicated messages must be considered when designing
higher-level protocols for users of CIDIN.

6.2.6.4

The acknowledgement procedure and the associated retransmission can also lead to
messages arriving at an exit centre in a different order from the one in which they were
transmitted. This must be taken into account by the higher level protocols.

6.2.6.5

The destination address item of the CIDIN protocol does not exclude the possibility to
code more than twenty one Ads to one Ax. However, since the source of a message
transmitted via the CIDIN AFTN application is an AFTN message with a maximum
number of twenty-one addressee indicators, all messages containing more than twenty-one
Ads per Ax should not be acknowledged.

6.2.7

Error Handling

6.2.7.1

Apart from the errors detected by the acknowledgement procedure, other errors can be
recognised by, and should be handled by the transport procedure. The general approach
taken is that the message in error should be handled if possible, but if that is not possible
then the event should be journalised. A warning message to the operator will alert him to
the event. More application specific information will be generated as other applications are
defined in the procedures.
a)

CIDIN packet of a message missing:


This situation can arise, for example, because timer TNMA has expired during the
assembly of a message at layer 4. A missing packet will prevent the exit function
from building a complete message from the received packets. The incomplete
message should be discarded, the event logged and a warning message sent to the
operator containing the Ae/MIN.

Chapter 6

Sixth Edition
Page 14 of 17

14/04/2011

EUR CIDIN MANUAL

b)

Receipt of ACK, ENQ response or MCF error packet:


The event is logged, reported to the operator and the packet is discarded.

c)

Receipt of packets with sequence numbers higher than the sequence number of a
packet with FCP=1:
Incoming packets containing the address of the CIDIN centre or station as an exit
address and belonging to the same message (as indicated by entry address and MIN)
are held until they form a complete message or until the packet reception timer
expires. A complete message consists of a continuous sequence of packets including
the packet sequence number zero and a packet with the Final CIDIN Packet Indicator
(FCP) set. As soon as a complete message is formed, it is passed up to the higher
layer of protocol handling for normal processing. If it contains packets with sequence
numbers higher than that of the lowest numbered packet with FCP set, those higher
numbered packets are discarded. The action is recorded in the log.

d)

Any other inconsistency in the CIDIN packet header data in related packets:
The header data is taken from the first received packet of the message (CPSN not
necessarily = 0) or from the packet (with CPSN = 0) of the message. The event is
logged and a warning message sent to the operator containing the Ae/MIN.
It is recommended that the maximum length of a message transmitted by CIDIN be
considerably less than the maximum allowed. This is in order to place a bound on the
retransmission time necessary in the case of an error in transmission. The
recommendation is analogous to the segmentation of long messages in the AFTN.
If, for a multiply disseminated message, some Axs are not available because, for
example, an enquiry/response exchange is in progress, the message should be sent to
the available Axs. The application should be informed that some Axs were not sent the
message. When they become available again, the application can send a new CIDIN
message with the original contents.

6.2.8

Form of the Service Interface to the Transport Layer

6.2.8.1

6.2.8.2

Chapter 6

The information required by the transport layer when accepting a message from a user for
transmission includes:

message priority

acknowledgement required or not

message characteristics (AFTN or other format, conversation protect, etc.)

exit centre address(es)

destination addresses (if AFTN message)

message content.

The way in which this information is mapped onto the various headers of the CIDIN
protocols is shown in Figure 6.5. The form of the interface between transport layer and
application is, however, a local matter.

Sixth Edition
Page 15 of 17

14/04/2011

EUR CIDIN MANUAL

AFTN Message

CIDIN Transport Layer

CIDIN message
segment
transport Header

X.25 Packet Layer

Message Priority
Message code/Format
conversation protection
AFTN destination Address
Exit Centre Address
CIDIN Packet Sequence Number
Final CIDIN Packet Indicator
Message Identification Number
Message type indicator
Entry centre address

general format identifier


logical channel (group) number
packet type identifier

Application Layer

CIDIN Packet Layer

Network ACK

CIDIN Packet Header


X.25 Packet Header

Figure 6.5 Mapping of Message Parameters onto Headers


6.2.8.3

Messages are fully entered at entry centres before transmission begins and fully assembled
at exit centres before delivery to applications. An example of the way in which an AFTN
message can be segmented through the layers is shown in Figure 6.6.

Protocol Layer

Protocol Data Units and Control Information

AFTN Message

Application
Software

AFTN Header

Pri

Ad Ad Ad Ad Ad Ad Ad Ad Ad

Origin

Message text

(Axs derived from tables)


MCF, NA, CP

MP

Ax1(Ad) Ax2(Ad Ad Ad) Ax3(Ad Ad Ad Ad Ad)


Pri

Origin

Message text

transport header

Transport Layer

MP

Ax1(Ad) Ax2(Ad Ad Ad) Ax3(Ad Ad Ad Ad Ad)


first message segment (256 octets)
MP Ax1 Ax2 Ax3
second message segment (256 octets)
etc.

formation of CIDIN packets of maximum length 256 octets

CIDIN Packet Layer

CIDIN packets
sent to Ax1
CIDIN packets
sent to Ax2 Ax3

MP Ax1 Ad1

MP Ax2 Ad...Ad Ax3 Ad...Ad

MP Ax1

MP Ax2 Ax3

Figure 6.6 Example of the Way in which Messages can be segmented

Chapter 6

Sixth Edition
Page 16 of 17

14/04/2011

EUR CIDIN MANUAL

6.2.9

Enquiry (ENQ) procedures

6.2.9.1

6.2.10

If it is indicated in the message transport that acknowledge is required, then it is possible


for the sender to know that the responsibility for further treatment of the message has been
taken over by the addressed application entity. When the message has not been
acknowledged even after a retry, the sending centre starts an ENQ procedure, that is, it
sends ENQ messages to the particular Ax in a regular interval (TEM) until an ENQ
response is received from this particular Ax. Until that event has occurred no further
messages to that address are sent. It may be possible to reduce the ENQ message frequency
after a certain time period has elapsed, but it should be realised that this reduction causes
delay in restoring the traffic flow after restoration of service. The operator shall be
informed of the start of an enquiry procedure, and on the leaving the ENQ state. The
operator thus has the opportunity to initiate message delivery to an alternate Ax if required.
The operator shall have the means of initiating or stopping ENQ procedures. ENQ
responses received without a preceding ENQ message will be logged and reported, but will
not be taken as valid information.

Flow Control
Flow control at the transport layer is performed through the implementation of a windowing
mechanism. The range of the transport layer window sizes is 1 to 99, the recommended value
being 5.

6.2.11

Parameters
The parameters of the CIDIN transport layer are three timer values and the window size:

TMR:

time-out for expected network acknowledgement (Message Response). The


recommended value is 40 seconds.
Furthermore, the ability to configure the TMR per Ax or Ax could be
implemented.

TNMA:

time-out for reassembling of CIDIN packets to a message (Next Message


Arrival) The recommended value is 35 seconds. TNMA is less than or
equal to TMR.

TEM:

time-out for enquiry response (Enquiry Message). The recommended value


is 40 seconds.

w:

transport layer window size is the number of outstanding messages. The


range of w is 1 to 99. The recommended value is 5.

Chapter 6

Sixth Edition
Page 17 of 17

14/04/2011

EUR CIDIN MANUAL

7.
7.1

The AFTN Interface


Information mapping

7.1.1

In an entry centre, the AFTN interface maps the information contained in an AFTN
message onto the information required by CIDIN for transmitting the message. In the exit
centre, the AFTN interface performs the reverse operation. Information to be mapped is:

Network addresses
AFTN addressee indicators are mapped onto exit centre addresses.

Priority
The AFTN priority indicator is mapped onto CIDIN priorities in the entry
centre.

Parameters
Certain message parameters (acknowledgement required, message type =
AFTN) are set in the entry centre.

7.2

Logical View

7.2.1

7.3

The AFTN interface does not constitute a protocol as in the layers below since it does not
execute procedures between peer entities. The AFTN interface therefore only has local
functions to perform. However the rules executed by the AFTN interface for mapping
AFTN messages to and from the CIDIN layers is standardised. If this were not the case,
the transmission of a message by CIDIN would not be equivalent to its transmission by a
physical leased circuit (see Figure 1.3).

AFTN Header and Message Part

7.3.1

Chapter 7

The conventions for mapping an AFTN message onto a CIDIN user data field are shown in
Figure 7.1. Note that IA5 characters are used.

Sixth Edition
Page 1 of 3

14/04/2011

CIDIN user data field

Modified AFTN heading

EUR CIDIN MANUAL

Message part
MODIFIED
ADDRESS
(see 4.4.15.2)

Component of the message part


Start-of-Heading Character
Alignment Function
Priority Indicator
Alignment Function

ORIGIN
(see 4.4.15.2.2)

Filing Time
Originator Indicator
Priority Alarm
Optional Heading Information
Alignment Function
Start-of-Text Character

TEXT
(see 4.4.15.3)

Beginning of Text
Message text
Confirmation (if necessary)
Correction (if necessary)

ENDING
(see 4.4.15.3.12)

Alignment Function
Page-feed sequence
End-of-text Character

Figure 7.1 Structure of CIDIN User Data Field for Messages in AFTN format
(paragraph numbers refer to ICAO, Annex 10, Vol. II)

7.4

Address Mapping

7.4.1

For each AFTN address (Ad) in an AFTN message, the corresponding CIDIN exit address
(Ax) is determined from a table. The rules for generating Axs and Ads are described in
conjunction with the CIDIN packet protocol.

7.4.2

AFTN addresses are removed from AFTN messages in the mapping to CIDIN format since
this facilitates address stripping in CIDIN.

7.4.3.

The address mapping software should take advantage of the implicit limits placed on the
numbers of addresses: an AFTN message can have up to three lines of addresses. The
CIDIN packet protocol requires that all address items (Axs and associated Ads) for a
message must fit into one CIDIN packet. In the case where an AFTN message would
exceed this restriction, the AFTN interface must generate more than one CIDIN message
corresponding to the AFTN message.

7.4.4

The AFTN interface is allowed some flexibility in associating Ads with the Axs which are
responsible for the Ads. The choice of an alternate exit centre for an AFTN message is thus
the task of the AFTN interface. Alternative exit centres are not handled within CIDIN
itself. Where practicable, AFTN messages shall be re-routed to an alternative exit centre
for further delivery on the low speed AFTN in cases where delivery to the Ad via the
primary Ax is not possible.

7.5

Priority Mapping

7.5.1

Chapter 7

The AFTN priorities are mapped into the CIDIN priorities as indicated in the following
table:

Sixth Edition
Page 2 of 3

14/04/2011

EUR CIDIN MANUAL

Table 7-1:

7.5.2

7.6

CIDIN
Priority

bit-code

Description of
Characteristics

AFTN-Priority
Assignment

000

Vital to network operation

001

Messages relating to personal safety

010

Very urgent message

011

ATS co-ordination messages

AFTN DD

100

Flight safety message

AFTN FF

101

Routine message

AFTN GG

110

Low priority

AFTN KK

111

Non time critical message

AFTN SS

The original AFTN priority is left together with the date/time group and the origin address
in the AFTN message (CIDIN user data). This means that the AFTN priority does not have
to be derived from the CIDIN priority in the exit CIDIN centre.

Error handling

7.6.1

7.7

AFTN priority mapping

In the transmission of an AFTN message through the CIDIN network, the AFTN
transmission identifier (channel designator and sequence number) disappears from the
message headers. For this reason it is not practical to use the Annex 10 Vol. II procedures
(using the TI as a reference) as for low speed AFTN.

Errors requiring operator action

7.7.1

In the cases where errors which require active investigation are detected in the
AFTN/CIDIN interface, it is convenient to report such errors to the local AFTN operator
for further action. Each CIDIN Entry centre maintains a journal which cross refers the
Ae/MIN with the incoming (to the entry centre) AFTN TI, and each CIDIN Exit centre
maintains a similar journal which cross refers the Ae/MIN with the outgoing (from the
AFTN centre) AFTN TI. These two journals allow for end-to-end message tracing.

7.7.2

All cases of AFTN/CIDIN interface errors should give rise to an operator error message
with the following information:
a)
b)
c)

Error reason
Ae/MIN
ORIGIN LINE (from CIDIN information field).

7.7.3

Both b) and c) are included in the error message since either could be corrupted, and at
least one of these fields is required in order to be able to trace back to the originator of the
message.

7.7.4

The local AFTN operator (at the exit centre) receives an error message, and a service
message is sent to the entry centre AFTN operator with the following text:
CIDIN/AFTN
"ERROR REASON"
Ae/MIN
ORIGIN LINE (from CIDIN information field)

Chapter 7

Sixth Edition
Page 3 of 3

14/04/2011

EUR CIDIN MANUAL

8.
8.1

Statistics
Functional Areas

8.1.1

Four main functional areas may be identified when considering the application of CIDIN
statistics as follows:

System planning
for estimating future requirements.

Centre supervision
to assist in the immediate supervision of the CIDIN centre.

Network supervision
to assist in the evaluation of the need to rearrange the network configuration
and/or routing.

Facility performance
for use in isolating immediate operational and statistical problems in
automatic systems.

8.1.2

Statistics can be processed on-line, off-line or a mixture of both. In any case, the source
information must be collected on-line and archived on a suitable storage medium.

8.1.3

The statistics should be gathered and presented in a layered manner, corresponding to the
CIDIN protocol layers. The time span for each report can be fixed or variable by
command. It is suggested that one hour time divisions is convenient, with the facility to
present information at 10 minutes intervals when required for more definitive analysis.

8.2

Application layer statistics


Number of messages leaving application for transmission over CIDIN.
Number of messages arriving at application after transmission over CIDIN.

8.3

Layer 4 statistics

Chapter 8

Number of messages received

Number of messages transmitted

Average length of received messages

Average length of transmitted messages

Number of unacknowledged messages (requiring ACK)

Number of messages transmitted to each Ax

Number of messages received from each Ae.

Sixth Edition
Page 1 of 2

14/04/2011

EUR CIDIN MANUAL

8.4

Layer 3b statistics
Number of CIDIN packets received
Number of CIDIN packets transmitted
Number of CIDIN packets received per priority
Number of CIDIN packets transmitted per priority
Number of CIDIN packets discarded with PLC = 0

8.5

Layer 3a/2 statistics

8.5.1

These statistics are listed for consideration by Administrations when producing


specifications.

8.5.2

For each PVC defined on the route:

8.5.3

Number of packets received

Number of packets transmitted

Number of Reset requests sent

Number of Reset confirmations received

For each link from the centre:

8.5.4

Load in percentage of capacity (utilisation)

Number of link failures and recoveries

Percentage of time that line is out of service

Number of restart requests sent

Number of restart confirmations received.

The following statistic is considered to be useful but is not required for network
management purposes:

8.6

Number of centres found to be unreachable.

Additional statistics

8.6.1

The average and maximum elapsed time from the transmission of a message to the
reception of the corresponding ACK, are considered important statistics in the assessment
of network performance.

8.6.2

Additional statistics information may be required to support the CIDIN Network


Management function as detailed in the CIDIN Network Management Centre specification
e.g. PVC occupancy, average message length per Ax, number of messages per VC.

Chapter 8

Sixth Edition
Page 2 of 2

14/04/2011

EUR CIDIN MANUAL

9.

Testing

9.1

Introduction

9.1.1

9.2

In order that the various implementations of the CIDIN protocols are compatible, it is
important that they be tested according to the same set of principles. Experience has shown
that, although it is claimed that systems have been implemented according to the one set of
protocol specifications, they are often not capable of inter-working. This is due to errors in
implementation or to different interpretations of the specifications. The primary objective
of this chapter is to formulate recommendations for testing the ability of a given CIDIN
implementation to inter-work with an adjacent system and within a network environment.

Scope

9.2.1

9.3

This chapter provides general recommendations for the testing of CIDIN implementations.
The actual testing procedures are contained in Appendix D. Tests are described in
sufficient detail to give an appreciation of the variety of functions that are covered and the
facilities required.

General Principles

9.3.1

The creation of standards for testing is subject to consideration by a number of


standardisation bodies concerned with open systems (e.g. ISO, ITU-T).

9.3.2

CIDIN implementations consist of protocol layers according to the principles of the


Reference Model for Open Systems Interconnection. In this context, the OSI test concepts
distinguish between "multi-layer" and "embedded single-layer" testing.

9.3.3

In multi-layer testing, more than one protocol layer is subject to testing at the one time. An
extreme case of multi-layer testing is when the whole system containing the protocol
implementation, the "system under test" (SUT) is tested as a "black box" i.e. with no
regard for its internal structure. This strategy is likely to be more efficient when testing
implementations containing very few errors and has the advantage that layers are tested in
their real environment. However the multi-layer strategy is not suited to localising the
source of errors in individual protocol layers.

9.3.4

In embedded single-layer testing, an individual layer is the "implementation under test"


(IUT) and all test sequences are designed to test the behaviour of only this one layer. This
strategy, when repeated for each layer, requires more effort than the multi-layer strategy.
Single-layer testing is, however, more efficient in localising errors. It requires access to the
service interfaces of the protocol layer implementations.

9.3.5

A distinction is also made between "active" and "passive" testing. In active testing, the
SUT or IUT is tested against an implementation specifically designed for testing purposes.
For example, the reaction of the SUT to unexpected events, e.g. protocol errors, can be
tested explicitly. In passive testing, events at a given layer are merely monitored using a
suitable device in order to show that the SUT behaves correctly under normal operating
conditions.

9.4

CIDIN Test Strategy

9.4.1

Chapter 9

It is recommended that tests of CIDIN implementations be performed using active testing.


This does not preclude the additional use of passive testing. However active testing is

Sixth Edition
Page 1 of 18

14/04/2011

EUR CIDIN MANUAL

considered to be necessary in the CIDIN environment, in which equipment from different


suppliers must inter-work internationally.
9.4.2

Initially, it is recommended that a new CIDIN implementations be tested according to the


single-layer strategy. Testing begins with the layer suspected of being in error and works
upwards. Each set of tests concentrates on only one layer. Only after confidence has been
gained in an implementation of layer "N", does testing of layer "N+1" begin. If
subsequently an error is suspected in a layer that has already been accepted, tests must be
repeated on this layer. Additional tests may be required in this case. Depending upon the
changes made to this layer after the error has been found, the repetition of tests on
overlying layers could be necessary. For the purposes of this Manual, this approach is
called CIDIN Conformance Testing.

9.4.3

After successful completion of Conformance Testing, additional tests are performed,


involving the SUT and one or more "test partners". In the case of CIDIN, the test partners
are the SUT (a complete CIDIN centre, possibly together with an AFTN centre) and one or
more CIDIN centres or other complete implementations of the CIDIN protocols. For the
purposes of this Manual, this approach is called CIDIN Interoperability Testing.

9.4.4

The methods used in the various testing phases are different. They are described in the
appropriate sections.

9.4.5

In the case of CIDIN single-layer conformance tests, one of the test partners is an
implementation of a protocol layer (layer N) in a CIDIN centre. This implies that the
software modules representing CIDIN layers 2 to N should be separable from protocol
layers N+1 and higher. Stated in terms of the OSI Reference Model, this means that layer
N must offer a "service interface" to the higher layers. It can be assumed that this is true of
CIDIN implementations since this requirement conforms to modern software design
principles concerning modularity. The service interface should be accessible for testing
purposes: if this is not the case then only a restricted set of tests can be performed. The
other test partner is special-purpose test equipment.

9.4.6

The other test partner in CIDIN single-layer conformance tests is one or more intelligent
protocol monitor/analysers. Depending upon the layer being tested, this equipment will
simulate certain CIDIN layers and have special test software on top of it.

9.4.7

It can be expected that, as experience with CIDIN implementations accumulates, the set of
test procedures will grow and the procedure definitions themselves will evolve. For
example, if a problem occurs during operation of the network due to incompatibility of
implementations, additional tests should be included in the test suite so that this problem
can in future be excluded during the testing of new implementations.

9.4.8

A principal difficulty in performing protocol testing is the co-ordination of the test


partners: actions performed by one partner must be in correct sequence with the actions
performed by the other. This difficulty is often overcome by embedding the
implementation under test in an environment which makes it behave passively ("test
responder" or "ferry"). The responsibility for the test sequences and the co-ordination is
then taken over by the test equipment, which consequently must be more sophisticated.
The use of such test equipment is not always possible within the scope of CIDIN testing so
that a different strategy has to be adopted.

9.5

Description Technique

9.5.1

Chapter 9

The strategy requires the exact specification of steps in the test procedures and their
sequencing for all partners involved. The format used in Appendix D for this purpose is
called "Procedures" and forms the bulk of the test descriptions. The test procedures are
divided up into sets, each of which is summarised in an "Overview" format.

Sixth Edition
Page 2 of 18

14/04/2011

EUR CIDIN MANUAL

9.5.2

Each test is performed using a particular configuration defined in the "Configuration"


format. A configuration is used to test only one layer of the protocol stack. More than one
test configuration may be required.

9.5.3

The formats "Configuration", "Overview" and "Procedures" are described briefly below:

9.5.3.1

Configurations

Implementation under test (IUT)

Which layer in which function (e.g. entry centre)?

Parameter settings
Values of parameters in the IUT and constant when using this configuration.

Underlying layer
Which layer in which function underlies the IUT?

Initialisation state
How is this layer initialised before using this configuration?

Parameters
Values of parameters in this layer constant when using this configuration.

Number of test connections involved


How many logical connections are accessed by the IUT when using this configuration?

Connections in underlying layer


Logical connections accessed by the layer under the IUT.
Logical connections accessed by the layer under the IUT.
How many?
(a)to (c)
Association of these connections with the test partners (X) to (Y).
Test partners
Physical entities involved in this configuration.
(X) to (Z)
Association of the identifiers (X) to (Z) with the test partners in this configuration.
Additional conditions
Other requirements placed on this configuration.
Figure

Chapter 9

Sixth Edition
Page 3 of 18

14/04/2011

EUR CIDIN MANUAL

Graphical representation of the configuration.


9.5.3.2 Overview
9.5.3.2.1

Testing can in principle never be exhaustive. For this reason, the complete set of tests is
divided into functional sets, called "test group" which can be extended as required. A test
group concentrates on one aspect of the protocol being tested e.g. the connection
establishment phase. The tests for any one layer are contained in a number of test groups.
A test group is associated with the testing of only one layer in single-layer testing.

9.5.3.2.2

All common features of the tests in a test group are described in the format "Overview".
The parameters in such a description are as follows:
Purpose
Which functions are to be tested by this test group?
References to CIDIN SARPs
Which paragraphs of the CIDIN SARPs describe the protocol functions being tested?
Configuration used
A test group is associated with only one previously defined configuration.
To be preceded by test groups
It could be advisable for reasons of test efficiency to complete other test groups
before beginning on this one.

Coding
The coding of all protocol data units (PDUs) used in the test group is defined here.

Initialisation
Initialisation conditions common to all the procedures in this test group. All test
procedures start in this state with all partners waiting.

Special considerations

Miscellaneous information.

Test procedures
List of all procedures in this test group and their purposes

9.5.3.3 Procedures
9.5.3.3.1

The test sequences in a test group are called "procedures". A procedure specification must
detail the actions to be performed by each test partner and the sequence of these relative to
those of other partners. The procedure specification describes this situation of test partners
active in parallel.

9.5.3.3.2

There are two basic types of operations to be performed by test partners: either the partner
sends a PDU or it waits for an external event to occur. Each procedure begins with all
partners in a wait state except for the partner which performs the initial send.

Chapter 9

Sixth Edition
Page 4 of 18

14/04/2011

EUR CIDIN MANUAL

9.5.3.3.3

The parameters associated with each step in a procedure are as follows:


Step number
Sequential number
Alternate step
If after execution of this step an additional test partner must become active, the
appropriate step number is given here. This can lead to a "forking", i.e. an increasing
number of test partners can become active simultaneously.
Test partner
Which test partner performs the step - (X), (Y) or (Z) - see the configuration
description?
Connection
On which connection does the event occur - (a), (b) or (c) - see the configuration
description?
Wait event / Send?
Does the test partner wait for an event or send a PDU?
PDU, Time
Which PDU is sent or which time-out occurs?
Parameters/Comments
Additional information

9.6

Performance of the Tests

9.6.1

In general, two or more test operators, who determine when and what PDUs are sent at the
layer under test by their respective implementations, execute each test procedure. It is
important that an operator has voice contact with other operators.

9.6.2

Each test procedure begins with all test partners in a stable wait state. The appropriate
operator then causes the partner active in procedure step 1 to send its specified PDU. The
ensuing sequence of events and their synchronisation is then as detailed in the procedure
description.

9.6.3

The method with which the operator causes the appropriate PDU to be sent depends upon
whether he is operating the IUT or test equipment side of the configuration:
at the IUT, the PDU is sent (a) as an automatic reaction of the protocol machine with
no interaction at the service interface or is sent (b) as a result of an interaction at the
service interface with the operator possibly via special test software;
at the test equipment, the required PDU is sent explicitly by the operator either via predefined test sequences or manually.
Note that the IUT itself is not modified since this would defeat the purpose of testing.

Chapter 9

Sixth Edition
Page 5 of 18

14/04/2011

EUR CIDIN MANUAL

9.6.4

In specifying the test procedures, care has been taken to test the reactions of the IUT only
as required by CIDIN SARPs. Where CIDIN SARPs allow some freedom (e.g. in layer 3a:
when to send RR when receiving information packets), the test procedures should allow for
various possible implementation design decisions.

9.6.5

The interactions required at the service interface of the IUT in the single-layer testing are
those which would normally be caused by an ordinary layer on top of the IUT. No
abnormal behaviour of the IUT is required by the test procedures. This simplifies the
performance of the tests at the IUT.

9.7

Conformance Testing

9.7.1

General

9.7.1.1

9.7.2

Conformance testing is performed per CIDIN protocol layer in order to localise and
diagnose errors in an IUT and to increase confidence in a new CIDIN centre.

Physical Layer

9.7.2.1

The layer 1 tests are not described in this manual because they concern only the physical
interface of each CIDIN centre (DTE) with the authority (e.g. PTT) supplying the
communication lines (DCE). However there is a need for co-ordination between the
respective centres to ensure agreement on the details involved, in addition to provision of
the lines themselves.

9.7.2.2

In the case where CIDIN centres are connected to each other locally or to test equipment
during a testing phase, special physical interfaces can be agreed upon bilaterally with or
without modems.

9.7.2.3

Equipment to be used will vary from case to case but will normally consist of special
physical line monitors/analysers displaying bit patterns sent and received together with
indicators for the status of the interface lines.

9.7.2.4

When performing single-layer tests, the physical layer must be working reliably before
tests with layer 2 are commenced. However, extensive testing of the physical layer is only
feasible in conjunction with tests of the higher layers when timing or synchronisation
problems become apparent.

9.7.2.5

It is important that higher layer tests (in particular, layer 2 tests) be performed using
different data rates in the physical layer. This is necessary in order to detect possible timing
errors. The data rates to be tested should include, as a minimum, all those at which the
CIDIN centre under test will use in operations. Although protocol testing in discrete steps
as recommended here can never detect all timing problems of real-time operations,
experience has shown that the use of different data rates in the physical layer can be a help
in this matter.

9.7.3

Data Link Layer

9.7.3.1

The layer 2 tests consist of the following four test groups:


1. Test the transfer between non-operational (ADM) and operational (ABM) modes under
various conditions including error situations.
2. Test the transfer of data in I-frames for the normal error-free cases.
3. Test flow control procedures during data transfer.

Chapter 9

Sixth Edition
Page 6 of 18

14/04/2011

EUR CIDIN MANUAL

4. Test flow control procedures during data transfer.


9.7.3.2

One test configuration is used - see Figure 9.1. The CIDIN centre under test is connected
directly to a protocol monitor/analyser. This is the traditional and most effective way of
testing link layer protocols. In the monitor/analyser, the Test sequences are programmed
manually since no direct use can be made of its HDLC (LAP-B) implementation. However
advantage can be taken of the tools available for generating the test sequences.

9.7.3.3

No changes are to be made to the layer 2 implementation in the CIDIN centre under test.
The reactions expected from it in the test procedures are those required by the protocol
definition. This is appropriate because it can be expected that the HDLC implementations
in CIDIN centres will at least partly be in intelligent line controllers or in firmware.

9.7.3.4

The test operator at the CIDIN centre needs indications of the status of the HDLC
implementation, e.g. whether it is in ADM or ABM state. It must be possible to set the
implementation in a number of different initialisation states.
(X)

CIDIN operator
with access to
service interface

(Y)

Test operator
terminal

Layer 3a or test
software
Protocol
analyser/
monitor

Layer 2 (IUT)

One physical circuit


Figure 9.1 Test Configuration: Layer 2
9.7.3.5

The interactions necessary between the test operator and the layer 2 implementation under
test are those normally offered to a layer 3a implementation. Not all of the actions of the
implementation under test need to be visible to the operator e.g. the spontaneous sending
of an RR.

9.7.3.6

For effective testing, the test operator may need access to the layer 2 service interface, e.g.
for:
manipulating the data being passed to layer 2
simulating congestion.
It appears important that the interactions at this service interface can be traced if necessary.

9.7.4

X.25 Network Layer

9.7.4.1

The layer 3a tests consist of the following three test groups:


initialisation procedures: transition to and from flow control ready state
non-error procedures in flow control ready state
recovery procedures

Chapter 9

Sixth Edition
Page 7 of 18

14/04/2011

EUR CIDIN MANUAL

9.7.4.2

A functioning layer 2 in the test equipment and in the CIDIN implementation under test is
a pre-condition for the layer 3a tests. The test equipment will normally consist of a
protocol monitor/analyser in which the layer 3a test sequences are generated and executed
by hand. The generation of the test sequences can be supported by a set of tools designed
especially for X.25 layer 3.

9.7.4.3

Two distinct configurations are used - see Figure 9.2. A test operator at the CIDIN centre
under test participates in the three test groups. In general, a flexible method of generating
and changing routing tables, in the CIDIN centre under test, is necessary.

9.7.4.4

The required test operator interactions are those, which would normally be expected from
the layer 3b software. This means that a layer 3b implementation, properly configured,
could be used to drive the tests. Test operator access to a layer 3a service interface
(corresponding to the interface with layer 3b) is not necessary.

9.7.4.5

No changes should be necessary to the layer 3a implementation under test. All reactions to
the test procedures are those prescribed by the protocol definition.

Configuration 1
(X)

(Y)
Protocol
analyser/monitor

Test operator

Layer 3b
CIDIN operator with
access to layer 3b

Layer 3a (IUT)

Test sequences

Layer 2

Layer 2

Configuration 2
(Z)

(X)

(Y)
Operator access for
monitoring (tracing)

Protocol
analyser/monitor

Test sequences

Layer 3a (IUT)

Layer 2

Test sequences

Layer 2

(b)

Protocol
analyser/monitor

Layer 2

(a)

Figure 9.2 Test Configurations: layer 3a

Chapter 9

Sixth Edition
Page 8 of 18

14/04/2011

EUR CIDIN MANUAL

9.7.5

CIDIN Network Layer

9.7.5.1

The layer 3b tests consist of the following test groups:

9.7.5.2

entry centre layer 3b functions


relay functions for messages without multiple dissemination
multiple dissemination and address stripping in a relay centre
error processing

The exit centre layer 3b functions, consisting mainly of recognising of the local Axs, are
included with the relay functions. This grouping is determined by the following properties
of layer 3b:
Entry centre layer 3b functions can conveniently be isolated from relay centre
functions.
Exit centre layer 3b functions (except for the recognition of its own Ax in a packet) are
local matters and not a subject for conformance testing.
All other functions of layer 3b can be tested in the context of a relay centre.

9.7.5.3

The test configurations are shown in Figure 9.3. The partner against which the CIDIN
centre under test is tested is an intelligent protocol monitor/analyser containing the full
X.25 implementation required by CIDIN, together with the test sequences, as specified in
the procedure descriptions. The latter is a user of layer 3a, simulating the layer 4
implementation. No routing or passing on of CIDIN packets is necessary in the test
equipment.

9.7.5.4

The logical connections between the IUT and the corresponding test partner are generally
considered to be VCs. However, the test groups may contain tests applicable exclusively to
PVC or SVC type connections.

9.7.5.5

The software required in the SUT consists of an operator interface for controlling the test
runs together with diagnostic tools (e.g. traces). Operator access must be possible at the
CIDIN packet service interface layer (as well as at the transport layer) since the test
procedures involve individual CIDIN packets. These components are similar to software
which would normally be written during the software development for self test purposes.

9.7.5.6

In the CIDIN centre under test, the test procedures are driven by a standard layer 4
implementation. In test group 1, some operator intervention is necessary at the layer 3b
service interface.

Chapter 9

Sixth Edition
Page 9 of 18

14/04/2011

EUR CIDIN MANUAL

Configuration 1
(X)
(Y)

Layer 4
Layer 3b(IUT)

Test sequences

Layer 3a

Layer 3a

Layer 2

Layer 2
(a)
(b)
Two VCs on the same or different circuits

Configuration 2
(X)
(Y)
Layer 4
Layer 3b(IUT)

Test sequences

Layer 3a

Layer 3a

Layer 2

Layer 2
(a)
(b)
(c)
Three VCs on at least two different circuits
Figure 9.3 Test Configurations: Layer 3b

9.7.6

CIDIN Transport Layer

9.7.6.1

The layer 4 tests are divided into two basic functional sets:
entry centre functions and
exit centre functions.

9.7.6.2

Chapter 9

This division is convenient since the sets of functions are clearly distinct. A separate test
configuration is necessary for each of the two sets. For each set we distinguish between
normal and exceptional sequences of events and tests applicable to both types of VCs or
only one type (SVC or PVC). This leads to six test groups.

Sixth Edition
Page 10 of 18

14/04/2011

EUR CIDIN MANUAL

9.7.6.3

The configuration (see Figure 9.4) in the CIDIN centre under test is very similar to an
operational configuration since we are dealing with the uppermost standardised CIDIN
layer. The test procedures are driven in the SUT by an operator (via an operator terminal)
and appropriate application software. In the case of AFTN messages, the operator interface
could be via an AFTN software interface or an AFTN centre.
However more efficient testing is to be expected from using an operator interface directly
on top of the transport layer.

9.7.6.4

The operator sends and receives messages. In addition, he must be able to:
reset layer 4 and
trace the service interface between layer 4 and the application software.

9.7.6.5

The ability to trace the interface between layers 4 and 3b is also useful.

Configuration 1
(Y)
Test equipment
simulating two exit
centres

(X)

Application

Test sequences

Layer 4 (IUT)

EXIT1

Layer 3b

Layer 3b

Layer 3a

Layer 3a

Layer 2

Layer 2

EXIT2

(a)
(b)
Two VCs possibly on the same circuit
Configuration 2
(X)

(Y)
Test equipment
simulating one entry
centre

Application
EXIT 1

Test sequences

Layer (IUT)
Layer 3b

Layer 3b

Layer 3a

Layer 3a

Layer 2

Layer 2
(a)
One VC
Figure 9.4 Test Configurations: Layer 4

Chapter 9

Sixth Edition
Page 11 of 18

14/04/2011

EUR CIDIN MANUAL

9.7.6.6

The test equipment consists of a system with complete implementations of CIDIN layers 2
to 3b and special layer 4 test software. Since no particular demands are placed upon
throughput in the single-layer tests, this equipment could consist of an intelligent protocol
monitor/analyser. It could also consist of a CIDIN centre modified for testing the layer 4
implementation. The lower layers 2, 3a and 3b are normal operational implementations.
Layer 4 is replaced by test software specially written to test layer 4 and to exercise the
lower layers. Depending upon the design of the test equipment, it is likely that this test
software would have the same structure as and many components common with the layer
3b test software.

9.7.6.7

Basic requirements placed upon the test software in the test equipment are the ability to:
send and receive CIDIN messages which have been edited before the test is started,
manipulate the sequence in which CIDIN packets are sent,
send network management messages and to
analyse and record CIDIN packets received.

9.7.7

Application Interface

9.7.7.1

CIDIN provides a reliable connectionless transport service for any application which can
use this service conveniently. The specification of CIDIN protocols extends up to layer 4
and the application protocols of a CIDIN user are, in general, of no interest to CIDIN since
the application protocol data units are transmitted transparently by it. Therefore,
application protocols need not be tested within the scope of testing CIDIN protocol
implementations.

9.7.7.2

This is however not true when the user is the AFTN - see Chapter 7. Parts of the AFTN
"protocol" (e.g. addressing conventions) are mapped onto the headers of layer 3b and 4
protocol data units at an entry centre and mapped out of the headers at an exit centre. The
implementation of this mapping (the "AFTN interface") is therefore relevant when testing
a CIDIN centre. The AFTN interface is used by all applications which communicate via
AFTN messages.

9.7.7.3

By comparison with the single-layer test configurations for all other CIDIN layers, the
configurations necessary for testing the AFTN interface are not "peer-to-peer" - see Figure
9.5. This means that the implementation under test (AFTN Interface: application layer) is
not located logically on the same protocol layer as the test software (layer 4 or user of layer
3b). The possible configuration in which the AFTN application is tested peer-to-peer
(AFTN station to AFTN station) is not suitable for detecting all possible errors.

9.7.7.4

The AFTN interface tests are divided into two basic sets:
entry centre mapping, and
exit centre mapping.

9.7.7.5

Within each set, the normal and error cases are tested, thus giving four test groups.

9.7.7.6

The test configurations include a CIDIN centre to which AFTN stations are connected
either directly or via an AFTN centre. No assumptions are made on how or where the
AFTN interface is implemented since this is a local matter. The test configurations also
include protocol test equipment. Alternatively a modified CIDIN centre could be used.

9.7.7.7

Sets of testing procedures concerning the AFTN and the CIDIN network management
application interfaces are included in Appendix D.

Chapter 9

Sixth Edition
Page 12 of 18

14/04/2011

EUR CIDIN MANUAL

Configuration 1
(X)

(Y)

AFTN
station

Test equipment
simulating two exit
centres

AFTN interface
(IUT)

AFTN centre

ENTRY
Layer 4

Test sequences

Layer 3b

Layer 3b

Layer 3a

Layer 3a

Layer 2

Layer 2

EXIT1

EXIT2

(a)
(b)
Two VCs possibly on the same circuit
Configuration 2
AFTN
stations

AFTN centre

(X)

(Y)

Test equipment
simulating one entry
centre

AFTN interface
(IUT)

Test sequences
EXIT
Layer 4

ENTRY

Layer 3b

Layer 3b

Layer 3a

Layer 3a

Layer 2

Layer 2
(a)
One VC
Figure 9.5 Test Configurations: AFTN Interface

9.8

Interoperability Testing

9.8.1

Chapter 9

In interoperability testing, the CIDIN centre under test is treated as a whole without any
regard to its internal structure and without concentrating on any one particular protocol
layer. However, such an approach must allow access to configuration tables and other
parameters in the CIDIN system.

Sixth Edition
Page 13 of 18

14/04/2011

EUR CIDIN MANUAL

9.8.2

The tests performed are equivalent to the interactions, which may take place during normal
operations. Interoperability tests are highly dependent upon the test configuration available
(test equipment, other CIDIN centres, connectivity, physical interface to the AFTN). The
functions investigated during interoperability testing are a subset of those investigated
during single-layer testing.

9.8.3

It may be useful, when diagnosing the results of a test session, to look at traces which have
been made at various points in the SUT. It is recommended that tracing be performed at the
service interfaces of the protocol layers. It is helpful for trouble-shooting purposes if a
tracing capability is present in all CIDIN implementations and this can be switched on or
off with a software switch according to need. It is also advisable to monitor the
communication line(s) between the SUT and the test equipment at various protocol layers
with a suitable device during testing.

9.8.4

The CIDIN centre under test is tested in its functions as an entry/exit and as a relay centre
as shown in Figure 9.6. The status of the AFTN centre is only schematic and can, in fact,
be connected to or integrated into the CIDIN centre in different ways. We distinguish
between the operation of the entry/exit centre when handling AFTN and non-AFTN traffic.
Tests involving the latter via an operator interface at the SUT are necessary in order to
investigate the handling of non-AFTN formats. They are also necessary to investigate
functions, which would not be accessible via an AFTN centre.

9.8.5

Interoperability tests are normally restricted to bilateral and quadrilateral tests.

9.8.5.1

In the case of bilateral tests, the minimal set of interoperability tests to be performed is:
Group 1: AFTN and non-AFTN messages: Sending and receiving of various types of
messages by the SUT under different conditions (flow control blockages, line
disturbances).
Group 2: Mechanisms for re-transmission of messages: acknowledgement loss and
consequent procedures.
Group 3: Traffic exchange using SVCs: Verification of functionalities CIDIN SVCs.

9.8.5.2

In the case of quadrilateral tests, the minimal set of interoperability tests to be performed
is:
Group 1: Transmission/reception of multi-destination messages in normal cases and
in cases of network failure.
Group 2: Alternative routing selection procedures

Chapter 9

Sixth Edition
Page 14 of 18

14/04/2011

EUR CIDIN MANUAL

Configuration 1

AFTN Station

AFTN Station

SUT
Other implementation or
test equipment simulating
an AFTN+CIDIN
entry/exit centre.

AFTN + CIDIN
Entry/Exit Centre

1 physical circuit with 1 VC

Configuration 2
CIDIN operator
terminal

Test operator
terminal

SUT

Other implementation or
test equipment simulating
an AFTN+CIDIN
entry/exit centre

AFTN + CIDIN
Entry/Exit Centre

One or more physical circuits with several VCs

Configuration 3
Test operator
terminal

SUT
Other implementation or
test equipment simulating
a CIDIN entry/exit centre

CIDIN Relay
Centre

Several physical circuits


Figure 9.6 Test Configurations: Interoperability Testing

Chapter 9

Sixth Edition
Page 15 of 18

14/04/2011

EUR CIDIN MANUAL

9.9

Testing phases in CIDIN

9.9.1

Conformance testing (single layer - local)

9.9.1.1

Purpose

9.9.1.1.1

This type of testing is called conformance testing by the relevant ISO groups. Its purpose is
to test the logic of the protocol implementation in the system under test, without
necessarily considering dynamic (performance) aspects. The rationale behind the layer-forlayer approach is discussed extensively in the CIDIN manual.

9.9.1.2

Configurations

9.9.1.2.1

The configurations involve one CIDIN centre, the system under test, and the test
equipment with local connections (see CIDIN Manual Figure 9.1 to Figure 9.5). Note that,
in general, access to the service interfaces of the implementation of individual layers under
test is necessary.

9.9.1.3

Tools

9.9.1.3.1

Common to all test groups in this phase is the use of dedicated test equipment, either

special purpose analyser/monitors, or

CIDIN centres extended with features to drive conformance tests.

9.9.1.4

Test cases

9.9.1.4.1

In particular, the test cases include the generation of protocol errors by the test equipment
in order to test the reaction to these in the system under test. The specification of
conformance test cases in Appendix D cannot be considered to be complete. Almost
certainly, additional cases will have to be specified reflecting the experience in this and
other phases during the testing.

9.9.2

Conformance testing (Single layer - remote)

9.9.2.1

Purpose

9.9.2.1.1

Although desirable, the performance of this test phase is not mandatory in the CIDIN
context. It is a variation of the first conformance testing phase: the test tools are used
remotely from the system under test. This allows the CIDIN implementation in one State,
to be tested via communication lines against test equipment in another State with the
possibility of discovering additional errors in the implementations.

9.9.2.2

Configurations

9.9.2.2.1

As for previous phase (remotely).

9.9.2.3

Tools

9.9.2.3.1

As for previous phase.

Chapter 9

Sixth Edition
Page 16 of 18

14/04/2011

EUR CIDIN MANUAL

9.9.2.4

Test cases

9.9.2.4.1

As for previous phase

9.9.3

Interoperability testing (bilateral)

9.9.3.1

Purpose

9.9.3.1.1

This and the following test phases are called interoperability testing by the relevant ISO
working groups. By comparison with conformance testing, the system under test is
considered as one unit with no regard for the individual layers. This test phase is described
under "interoperability testing" in paragraph 9.8. Dynamic aspects are not handled in this
phase.

9.9.3.2

Configurations

9.9.3.2.1

The configurations involve one CIDIN centre (the system under test) and the test partner
(see Appendix D - Interoperability Tests and CIDIN Manual Figure 9.6).

9.9.3.3

Tools

9.9.3.3.1

The test partner could be another CIDIN centre taking part in the interoperability tests or
equipment simulating a complete CIDIN centre. In addition, tracing and monitoring
facilities are necessary.

9.9.3.4

Test cases

9.9.3.4.1

See Appendix D, Interoperability Tests. Because the test partner is a complete CIDIN
centre, it is recommended that no protocol errors be intentionally generated to test the
reaction of the system under test; this is more the task of conformance testing.

9.9.4

Interoperability testing (quadrilateral)

9.9.4.1

Purpose

9.9.4.1.1

Quadrilateral interoperability testing is a natural extension of bilateral interoperability


testing in that more than two centres are tested together. It includes dynamic (performance
and load) testing.

9.9.4.2

Configurations

9.9.4.2.1

The configurations involve one CIDIN centre (the system under test) and three or more
test partners (see Appendix D - Interoperability Tests).

9.9.4.3

Tools

9.9.4.3.1

The test partners could be other CIDIN centres taking part in the network tests or
equipment simulating complete CIDIN centres. In addition, tracing and monitoring
facilities are necessary.

Chapter 9

Sixth Edition
Page 17 of 18

14/04/2011

EUR CIDIN MANUAL

9.9.4.4

Test cases

9.9.4.4.1

See Appendix D Interoperability Tests. It is probable that the performance of such tests
will lead to the specification of additional single-layer tests.

9.9.5

Network extension

9.9.5.1

Purposes

9.9.5.1.1

Network extension refers to the procedures for extending a functioning CIDIN network
either by the addition of further centres or by additional functions. Because of the
introduction of new features into an existing operational environment, it is likely that test
procedures different from those used in the previous phases will be necessary.

9.9.5.2

Configuration

9.9.5.2.1

These will depend on the type of extension being tested.

9.9.5.3

Tools

9.9.5.3.1

These are likely to be the same as those used for network testing.

9.9.5.4

Test cases
(to be defined)

Chapter 9

Sixth Edition
Page 18 of 18

14/04/2011

EUR CIDIN MANUAL

10.

Operational Procedures

10.1

Introduction of new CIDIN COM Centres in the International Network

10.1.1

Preconditions
Before a new CIDIN COM Centre becomes operational, a set of pre-defined steps must be
completed in accordance with the principles and procedures provided in the EUR
CIDIN Manual and the ATS Messaging Management Manual. Full compliance is
necessary, in order to avoid disturbances in the daily operation of the CIDIN Centres during
this phase. For example, if the operational tables were loaded into the new system without
any international co-ordination, all operational CIDIN COM Centres would receive ENQ
from an unknown Entry Centre.

10.1.2

Stepwise approach
The following preparatory steps must be carried out successfully before any action for
introduction into the CIDIN network is initiated (also see Chapter 9):
1.

successful technical and operational acceptance of any new system, including CIDIN
Protocol Conformance Tests,

2.

bilateral Interoperability Tests with each adjacent COM Centre,


In this phase, the routing tables of the new system contain only the Ax of the COM
Centres which are involved in test activities. The tests are agreed on a bilateral or basis.

3.

quadrilateral Interoperability tests with adjacent COM Centre(s) and the first centre(s)
behind.
In this phase, only the Ax of the additional COM Centres are included in the routing
tables of the new system. The tests are agreed on a quadrilateral basis.

10.1.3

Routeing arrangements for the Ax of the new COM Centre

10.1.3.1 In accordance with the Routeing Update Procedure, which is described further in 10.3, a
COM Centre requesting to be integrated into the international CIDIN network sends a
Change Request to the AMC Operator.
10.1.3.2 As a result of the successful execution of the above procedure, the Ax and the routeing
arrangements for the new CIDIN Centre are known and the CIDIN routeing tables in all
CIDIN Centres are updated at the same time i.e. the agreed AIRAC date.
10.1.4

Introduction of the operational AFTN Routeing Tables

10.1.4.1 The introduction of the fully established AFTN Routeing Table, as agreed during the AMC
procedure, must be performed step by step. The new CIDIN COM Centre carries out the
following procedure with every CIDIN node of the network:
1) the next COM Centre is contacted and an agreement on the date for testing and starting
operation is reached i.e. AFTN message exchange using the respective exit addresses,
2) a simulation of message exchange is performed (testing),
3) actual traffic is exchanged (operation)
10.1.4.2 If one or more COM Centres are affected by transit traffic (CIDIN Relay), then the new
CIDIN Centre should inform these centre(s) in advance about the tests and the operational
date.
10.1.4.3 The introduction of the fully established AFTN Routeing Tables throughout the network
should be completed by the AIRAC date following the AIRAC referred to in 10.1.3.2. In
case this introduction procedure is not completed by this time, the new Centre informs the
AMC accordingly and provides a list of the centres already introduced.

Chapter 12

Sixth Edition
Page 1 of 4

14/04/2011

EUR CIDIN MANUAL


10.1.4.4 When the introduction of the AFTN Routing Tables is completed, the integrated COM
Centre informs the AMC of its successful introduction into the international network.
10.1.4.5 It is the responsibility of the new CIDIN Centre or the respective Authority to co-ordinate the
above actions.

Chapter 12

Sixth Edition
Page 2 of 4

14/04/2011

EUR CIDIN MANUAL

10.2

QSP procedure in CIDIN operations

10.2.1

Introduction

10.2.1.1 When requesting agreement on the re-routeing of traffic in the CIDIN environment, unlike
the conventional AFTN, a clear distinction must be made between re-routeing in terms of
VCG to reach the original exit address Ax (conventional QSP), and re-routeing that implies
re-mapping of AFTN addressee indicators (Ad) to a new exit address (alternate Ax).
10.2.1.2 The QSP procedure used in the conventional AFTN (Ref. Annex 10, Volume II, Chapter 4)
was adapted to produce a CIDIN QSP procedure, according to which, formal and
unambiguous messages are used for the co-ordination of CIDIN traffic re-routeing.
10.2.2

Message Types

10.2.2.1

The analysis of the workflow led to the establishment of the following message types:

Name of message Direction of co-ordination

Subject

Request

 from the initiating body

to initiate a re-routeing/re-mapping request

Agreement

response to the initiating body

to confirm the request

Partial Agreement response to the initiating body

to confirm the request in part

Disagreement

response to the initiating body

to disagree to the request

Cancellation

 from the initiating body

to stop the re-routeing/re-mapping measure

Confirmation

response to the initiating body

to confirm stopping

10.2.2.2

As there are two different possibilities for change requests, each kind of change uses a
dedicated message set (re-routeing messages, re-mapping messages).

Note.- To facilitate migration to AMHS, CIDIN Network Management Messages (operator messages),
are being replaced by corresponding AFTN service messages. The content and format of these
messages is described in detail in the EUR/NAT Routing Directory.

Chapter 12

Sixth Edition
Page 3 of 4

14/04/2011

EUR CIDIN MANUAL

10.3

Routing Update Procedure in the CIDIN network

10.3.1

Purpose of the procedure

10.3.1.1 The aim of the routeing update procedure is to ensure that the routeing tables implemented
by all CIDIN/AFTN COM Centres correspond to those contained in the ATS Messaging
Management Centre (AMC) database and that no inconsistency or other operational
problems arise as a result of a routeing modification not previously analysed and agreed
formally.

10.3.2

Procedure and Documentation

10.3.2.1 The procedure is detailed in EUR Doc 021 ATS Messaging Management Manual.

Chapter 12

Sixth Edition
Page 4 of 4

14/04/2011

EUR CIDIN MANUAL

11.
11.1

Quality of Service
Introduction

11.1.1

Quality of Service (QoS) provided by a network is the ability of the network to satisfy user
requirements. In this context, a user may be a network application, a human end user or a
network administrator.

11.1.2

Aeronautical applications impose particular safety critical and time critical performance
requirements on the AFS.

11.1.3

By defining appropriate Quality of Service (QoS) performance requirements for the AFS
and identifying criteria by which performance can be measured, it is possible to ensure that
current applications are served in an optimal manner, network resources are efficiently
deployed and network developments are in line with the evolution of applications.

11.1.4

Within the scope of the AFS, QoS performance requirements are most effectively expressed
in terms of the following parameters:

message loss probability

transit times

integrity

availability

11.2

Requirements

11.2.1

The AFS accommodates various applications that may have different requirements. A
formal analysis to determine QoS parameter values that should be met by the AFS is a very
complex task, so over-dimensioning of the network is usually adopted, resulting in sufficient
capacity and service assurance but also significantly higher costs.

11.2.2

In a pragmatic approach, the following sources of information are considered:

available regulatory documentation,

characteristics of present and projected traffic,

user and network operator expertise.

11.2.3

Furthermore, to arrive at concrete values for performance parameters, a number of


assumptions and restrictions are made:

as it is virtually impossible to adapt the network to the specific requirements of each


application, the most demanding QoS requirements are considered,

the QoS values defined represent worst-case performance,

the QoS values defined are those the transport layer should provide to the application,

only the international segment of the network is considered. Local arrangements


should ensure provision of appropriate QoS at the national level (SLAs between users
and national AFS providers).

11.2.4

Based on the above analysis the following numerical values are assigned to performance
parameters for the EUR AFS:
QoS performance requirements
Message loss probability (ACK is not received within 2 min)
Maximum transit time (for 95% of the traffic)
Integrity (probability of undetected message corruption)
Availability on a yearly basis

11.3

Numerical values
< 10-4
< 10 sec
< 10-6
99.99%

Enablers

11.3.1

Chapter 11

Network performance is highly dependent on features, facilities and services such as:

switching capacity of a communications centre,


Sixth Edition
Page 1 of 2

14/04/2011

EUR CIDIN MANUAL

11.3.2

11.4

bandwidth/line capacity,
reliability of network components,
appropriate staffing,
efficient management of network resources at the operational and administrative
levels.

Furthermore, in the frame of AFS performance, particular application requirements such as


retention of traffic archives for investigation purposes, provision of back-up media etc.
should also be noted, even though they are not formally considered as factors contributing to
QoS.

Standard performance measurement method

11.4.1

The specification of numerical values for performance requirements is meaningless unless


provision is foreseen for measurement of network performance. In practical terms,
measurements are performed on the two major components of the network, which are the
switching systems (nodes) and the links used.

11.4.2

Technically, such measurements involve, among other things:


generation of large message/data volumes,
automation of measurement,
time stamping of messages,
use of statistical analysis.

11.4.1

Capacity assessment of a switch

11.4.3.1

An estimation of the traffic volumes a switching system should be able to handle in its
lifetime could be made through the following calculations:
Current traffic figures under normal operation are increased by:
30% spare capacity for rerouting purposes
100% for anticipated general traffic growth (5% yearly growth over 12 years)
50% for new applications, and their expected decreased efficiency in data handling and
the additional amount of details to be transported.

11.4.3.2

The required capacity (for the lifetime of a system) is thus four times the current traffic.

11.4.3.3

Knowledge of the actual switching capacity of a communication centre is considered very


important for the operation, management and development of the AFS network and the
assessment of network performance. To measure this switching capacity specially designed
test equipment should be deployed using specific test principles and performance values
commonly agreed in the EUR AFS community.

11.4.3.4

A high level description of such equipment, called test harness and of the testing
methodology to be applied is provided in Appendix H of this Manual.

11.4.2

Transit time assessment

11.4.4.1

Statistical analysis of transit time measurements may be used for the evaluation of the
efficiency of main and alternate routes deployed within the network so that the network
performance is optimized to meet the corresponding QoS performance requirements.

11.4.4.2

Dedicated or integrated tools allow, among other things, for the measurement of actual
transit time between Ae/Ax pairs, based on the time stamping of the original message and
the corresponding ACK. These tools may also be used for monitoring and analysis of CIDIN
traffic and investigation of error situations and other protocol-related events.

Chapter 11

Sixth Edition
Page 2 of 2

14/04/2011

EUR CIDIN MANUAL

Attachment A:

Change Control Mechanism of the EUR CIDIN Manual

Proposals to introduce changes to the existing CIDIN procedures/documentation may arise


from CIDIN users or manufacturers. The procedure for submission and processing of a
Defect Report (DR) or a Change Proposal (CP) involves the following steps:

A.1

Procedure for DR
a.

A problem is detected concerning the operation of the CIDIN network, which may be
attributed to the CIDIN protocol, implemented CIDIN procedures and/or
inconsistencies in CIDIN documentation.

b.

The problem is reported to the Rapporteur of the AFSG Operations Group, by


submission a defect report (DR). A standard reporting format is used (see attached
template).

c.

The Rapporteur assigns a number and priority to the defect report and introduces it to
the agenda of an upcoming meeting of the AFSG Operations Group.

d.

The AFSG Operations Group evaluates the report and either adopts it as a working
item or rejects it. The party, which submitted the defect report, is notified accordingly.

e.

Experts of the AFSG Operations Group are assigned to the problem and milestone
dates are set. Outside expertise may be invited to participate, as appropriate.

f.

The AFSG Operations Group develops proposals for resolving the problem and
submits them to the AFSG for approval.

g.

The AFSG approves or rejects the presented proposals. In case of the latter, the subject
is referred back to the AFSG Operations Group (step e) or discarded.

h.

The AFSG Operations Group drafts appropriate text for amendment of the EUR
CIDIN Manual and submits it to the AFSG for approval.

i.

The AFSG approves or rejects the proposed material. In case of the latter, the subject
is referred back to the AFSG Operations Group (step h).

j.

The proposed amendments to the CIDIN Manual are presented to the EANPG for
approval.

k.

Solutions are implemented.

Steps (f) and (h) may run in parallel.

A.2

Procedure for CP
The same structured procedure, with the exception of steps (f) and (g) applies in case of
proposed enhancements to the CIDIN Manual or inconsistencies in existing CIDIN
documentation.
In this case, a change proposal (CP) should be submitted to the AFSG Operations Group.
The format of the CP is similar to that of the DR.

Attachment A

Sixth Edition
Page 1 of 3

14/04/2011

EUR CIDIN MANUAL

A.3

Template for Defect Reports / Change Proposals

TEMPLATE FOR DEFECT REPORTS / CHANGE PROPOSALS

DR_____

CP_____

Title:

Short, indicative textual name

Reference:

Number assigned by the OG Rapporteur

Originator reference:

Provided by the originator

Submission date:

Submitting State/Organization:

Author:

Contact Information:

e-mail, fax, telephone and postal address

Experts involved:

Status:

Assigned by the OG Rapporteur

Priority:

Assigned by the OG Rapporteur

Document reference:

Affected section(s) of the EUR AMHS Manual


or its Appendices

Description of defect:

Nature of the problem in detail


Reason(s) for requesting changes

Assigned expert(s):

Task history:

Working Papers and Information Papers


Produced on the subject

Proposed solution:

Including amendments to the text, if feasible

Attachment A

Sixth Edition
Page 2 of 3

14/04/2011

EUR CIDIN MANUAL

DR/CP STATUS control sheet


Event

Date

DR or CP received
submission date
discussion at
OG/ ...
Date for development of
proposals/ solutions
discussion at
OG/ ...
presentation to
AFSG/ ...
Date for development of
amendment to the Manual
discussion at
OG/
presentation to
AFSG/ ...

Status

Remark

Set to submitted
Set to accepted

Set to rejected
Responsible:

Set to resolved
Set to adopted

Set to rejected
Responsible:

Set to approved
Set to approved
for application

Additional DATES and comments

END of document

Attachment A

Sixth Edition
Page 3 of 3

14/04/2011

ICAO EUR DOC 005

INTERNATIONAL CIVIL AVIATION ORGANIZATION

APPENDICES
of the

EUR CIDIN MANUAL


Sixth Edition

Published by the European and North Atlantic Office of ICAO

April 2011

EUR CIDIN MANUAL APPENDICES

Table of Contents
A
Appendix A - Abbreviations and Terms .............................................................................................. 1
A.1 ABBREVIATIONS.................................................................................................................................. 1
A.2 DEFINITION OF TERMS ....................................................................................................................... 6
B
Appendix B CIDIN Conformance Proforma .................................................................................... 1
B.1 INTRODUCTION ......................................................................................................................................... 1
B.2 DOCUMENT STRUCTURE ........................................................................................................................... 1
B.3 REFERENCES AND STANDARDS ................................................................................................................. 2
B.4 CONFORMANCE PROFORMAE .................................................................................................................... 2
B.4.1
Physical Layer Layer 1 ................................................................................................................. 2
B.4.2
Link Layer Layer 2 ....................................................................................................................... 3
B.4.3
Network Layer Layer 3a (X.25 Packet Layer) ............................................................................. 3
B.4.4
Network Layer Layer 3b (CIDIN Packet Layer) .......................................................................... 4
B.4.5
CIDIN Transport Layer Level 4 ................................................................................................... 5
B.4.6
Application Layer CIDIN Network Management Application .................................................... 6
B.4.7
Application Layer AFTN Application.......................................................................................... 6
B.4.8
Application Layer OPMET Operator Message Application ........................................................ 7
B.4.9
Application Layer OPMET Application ...................................................................................... 7
B.4.10 Application Layer ATN Subnetwork Application........................................................................ 7
B.5 ABBREVIATIONS AND SYMBOLS ............................................................................................................... 8
B.6 CONFIGURABLE PARAMETERS PROFORMA FOR NEW CIDIN CONNECTIONS ............................................ 9
C
Appendix C General Coding Principles ............................................................................................ 1
C.1 CODING PRINCIPLES.................................................................................................................................. 1
C.1.1
General ............................................................................................................................................ 1
C.2 FORMATS .................................................................................................................................................. 1
C.2.1
Header Items ................................................................................................................................... 1
C.2.2
Header Item Code ........................................................................................................................... 1
C.2.3
Allocation of Header Item Codes .................................................................................................... 2
D
Appendix D CIDIN TESTING PROCEDURES............................................................................... 1
D.1 CONFORMANCE TESTS (SINGLE LAYER) ....................................................................................... 1
D.1.1
CONFORMANCE TESTING PROCEDURES .............................................................................. 2
D.1.2
Purpose of conformance tests .......................................................................................................... 2
D.1.3
Testing prerequisites ....................................................................................................................... 2
D.1.4
CONFORMANCE TESTS (SINGLE LAYER) Layer 3b .............................................................. 3
D.1.5
CONFORMANCE TESTS (SINGLE LAYER) Layer 4 .............................................................. 23
D.1.6
CONFORMANCE TESTS (SINGLE LAYER) AFTN interface ................................................. 49
D.1.7
CONFORMANCE TESTS (SINGLE LAYER) CIDIN Network Management Application
Interface . . . . ................................................................................................................................................ 64
D.2 INTEROPERABILITY TESTS (BILATERAL) ........................................................................................ 72
D.2.1
INTEROPERABILITY TESTING PROCEDURES (Bilateral) ................................................... 73
D.2.2
Purpose of bilateral interoperability tests ...................................................................................... 73
D.2.3
Testing prerequisites ..................................................................................................................... 73
D.3 INTEROPERABILITY TESTS (QUADRILATERAL)............................................................................... 81
D.3.1
INTEROPERABILITY TESTING PROCEDURES (Quadrilateral) ............................................ 82
D.3.2
Purpose of quadrilateral interoperability tests ............................................................................... 82
D.3.3
Testing prerequisites ..................................................................................................................... 82
E
Appendix E Interface Primitives........................................................................................................ 1
E.1 PRIMITIVES ............................................................................................................................................... 1
E.2 ENTRY CENTRE STATES ............................................................................................................................ 2
E.3 ENTRY CENTRE EXTERNAL EVENTS ......................................................................................................... 2
E.4 ENTRY CENTRE INTERNAL EVENTS .......................................................................................................... 2
E.5 ENTRY CENTRE ACTIONS .......................................................................................................................... 2
E.6 EXIT CENTRE STATES ............................................................................................................................... 2
E.7 EXIT CENTRE EXTERNAL EVENTS ............................................................................................................. 3
E.8 EXIT CENTRE INTERNAL EVENTS .............................................................................................................. 3
E.9 EXIT CENTRE EXTERNAL ACTIONS ........................................................................................................... 3

Sixth Edition
Page i of ii

14/04/2011

EUR CIDIN MANUAL APPENDICES

E.10 EXIT CENTRE INTERNAL ACTIONS ............................................................................................................ 3


F
Appendix F - Guidance on the Implementation of SVCs.................................................................... 1
F.1 INTRODUCTION ......................................................................................................................................... 1
F.2 PURPOSE AND SCOPE ................................................................................................................................ 1
F.3 NETWORK IMPLEMENTATION .................................................................................................................... 1
F.3.1
Availability ...................................................................................................................................... 1
F.3.2
Security ........................................................................................................................................... 3
F.4 NETWORK CONFIGURATION ...................................................................................................................... 3
F.4.1
Description ...................................................................................................................................... 3
F.4.2
Advantages of the use of SVCs ....................................................................................................... 6
F.4.3
Implementation phases .................................................................................................................. 11
F.5 SVC SET-UP AND CLEARING .................................................................................................................. 11
F.5.1
Timers ........................................................................................................................................... 11
F.5.2
Particularities of alarms ................................................................................................................. 12
F.5.3
Call re-establishment periodicity................................................................................................... 13
G
Appendix G X.25 PICS/PRL .............................................................................................................. 1
G.1 DEFINITIONS ............................................................................................................................................. 1
G.1.1
ITU-T and OSI X.25 Standards ....................................................................................................... 1
G.1.2
Usage and explanation .................................................................................................................... 2
G.1.3
Notation ........................................................................................................................................... 2
G.1.4
References ....................................................................................................................................... 2
G.2 CONFORMANCE STATEMENT..................................................................................................................... 3
G.3 NETWORK LAYER REQUIREMENTS ........................................................................................................... 3
G.4 GENERAL DTE CHARACTERISTICS ........................................................................................................... 4
G.5 PROCEDURES, PACKET TYPES AND PACKET FORMATS. ............................................................................ 5
G.6 MISCELLANEOUS FEATURES AND OPTIONS ............................................................................................. 10
G.7 FACILITIES .............................................................................................................................................. 11
G.8 PARAMETER VALUES AND RANGES ........................................................................................................ 15
H
Appendix H Centre Switching Capacity ........................................................................................... 1
H.1 INTRODUCTION ......................................................................................................................................... 1
H.2 SWITCHING CAPACITY MEASUREMENT .................................................................................................... 1
H.2.1
Test Harness .................................................................................................................................... 1
H.2.2
Test Principles and Performance Values ......................................................................................... 2
H.2.3
Method of Capacity Measurement .................................................................................................. 3
H.3 REALISATION ............................................................................................................................................ 4

Sixth Edition
Page ii of ii

14/04/2011

EUR CIDIN MANUAL APPENDICES

Appendix A - Abbreviations and Terms

A.1

ABBREVIATIONS
(as used in the EUR CIDIN Manual)
ABM

Asynchronous Balanced Mode

ACK

Acknowledgement message

ACP

Alternate Connection Path

ADISP

Automated Data Interchange Systems Panel

Ad

Destination address

ADM

Asynchronous Disconnected Mode

Ae

Entry address

AFS

Aeronautical Fixed Services

AFSG

European Aeronautical Fixed Services Group

AFTN

Aeronautical Fixed Telecommunication Network

AIS

Aeronautical Information Service

ANC

Air Navigation Commission

ASCII

American Standard Code for Information Interchange

ATC

Air Traffic Control

ATFM

Air Traffic Flow Management

ATN

Aeronautical Telecommunication Network

ATS

Air Traffic Service(s)

ATSO

Air Traffic Services Organization

Ax

Exit address

BCC

Block Check Character

BER

Bit Error Rate

bps

Bits per second

CCC

Co-operating CIDIN Centre

CCITT

Comit Consultatif International Tlgraphique et Tlphonique


International Telegraph and Telephone Consultative Committee

CCS

Appendix A

Calculus of Communicating Systems

Sixth Edition
Page 1 of 14

14/04/2011

EUR CIDIN MANUAL APPENDICES

CIDIN

Common ICAO Data Interchange Network

CMC

CIDIN Management Centre

CP

Conversation Protect

CPU

Central Processor Unit

CPSN

CIDIN Packet Sequence Number

CR

Call Redirection

CRC

Cyclic Redundancy Check

CSN

Channel Sequence Number

DBE

Data Bank EUROCONTROL

DCE

Data Circuit-Terminating Equipment

DEP

Departure Message

DLE

Data Link Escape

DTE

Data Terminal Equipment

DIS

Draft International Standard

DISC

Disconnect

DLCF

Data Link Control Field

DM

Disconnected Mode

DNIC

Data Network Identification Code

EAN

European ATSO Network

EANPG

European Air Navigation Planning Group

ENQ

Enquiry

EOT

End of transmission

ETB

End of transmission block

ETX

End of text

EUR

European

Flag

FCP

Final CIDIN Packet

FCS

Frame Check Sequence

FEC

Forward Error Correction

Appendix A

Sixth Edition
Page 2 of 14

14/04/2011

EUR CIDIN MANUAL APPENDICES

FPL

Filed Flight plan

FFPL

Formatted Flight plan

FMP

Flow Management Position

FRMR

Frame Reject

FSM

Finite State Machines

HDLC

High Level Data Link Control Procedures

HG

Header Generation

HG

Hunt Group

HIC

Header Item Code

HR

Header Removal

ICAO

International Civil Aviation Organisation

IDB

Integrated Data Base

ISO

International Organisation for Standardisation

ISO/DP

ISO Draft Proposal

ISO/IS

ISO International Standard

ITA-2

International Telegraph Alphabet Number 2

IA-5

International Alphabet Number 5

ITU

International Telecommunication Union

IUT

Implementation Under Test

Length Indicator

LAP-B

Link Access Procedure, Balanced mode

LDF

Link Data Field

M-bit

More data bit

MCF

Message Code and Format

MCP

Main Connection Path

MIN

Message Identification Number

MP

Message Priority

MT

Message Type

NA

Network Acknowledgement

Appendix A

Sixth Edition
Page 3 of 14

14/04/2011

EUR CIDIN MANUAL APPENDICES

NACK

Negative Acknowledge

NAM

North American

NASC

National AIS Service Centre

NAT

North Atlantic

NOTAM

Notice to Airmen

OPMET

Operational Meteorological (information)

OSI

Open Systems Interconnection

PDN

Public Data Network

PDU

Protocol Data Unit

PICS

Protocol Implementation Conformance Statement

PLC

Packet Looping Counter

PNIC

Private Network Identification Code

PNTN

Private Network Terminal Number

PRL

Profile Requirements List

PSN

Packet Switched (data) Network

PTT

Postal Telephone and Telegraph Administration

PVC

Permanent Virtual Circuit

REV

Revision (message)

REJ

Reject

RNR

Receive Not Ready

RR

Receive Ready

SABM

Set Asynchronous Balanced Mode

SARPS

Standards and Recommended Practices (ICAO)

SITA

Socite Internationale de Tlcommunications Aronautiques

SNDCF

Subnetwork Dependent Convergence Function

SREJ

Selective Reject

SOH

Start of header

STX

Start of text

SUT

System Under Test

Appendix A

Sixth Edition
Page 4 of 14

14/04/2011

EUR CIDIN MANUAL APPENDICES

SVC

Switched Virtual Circuit

T20

X.25-timer

T22

X.25-timer

TAF

Aerodrome forecast

TEM

Time-out for Enquiry response

TMR

Time-out for Message Response (ACK).

TNMA

Time-out for reassembling of CIDIN packets to a message (Next


packet to the current arrival message)

TSG

Technical Sub-group

UTC

Universal Coordinated Time

VC

Virtual Circuit

VCG

Virtual Circuit Group

VP

Variable Length Parameter

V.nn

CCITT Recommendation belonging to the V Series

Window size

WMO

World Meteorological Organisation

X.nn

CCITT Recommendation belonging to the X series

Appendix A

Sixth Edition
Page 5 of 14

14/04/2011

EUR CIDIN MANUAL APPENDICES

A.2

DEFINITION OF TERMS
(as used in the EUR CIDIN Manual)

Note.- The indications in brackets (thus) give the source of the term or the context in which the term is used.
acknowledgement:

element of a procedure used for confirming to a message sender that a


message has reached its destination; term used at different protocol layers;

active testing:

the activity of investigating the properties of an implementation by means


of special purpose test equipment and procedures; not performed during
normal operations;

address mapping:

the finding of correspondences between an address in one address space


and address(es) in another; normally performed by means of tables of
correspondences;

address space:

a set of addresses which have some common features, e.g. same format,
reachable on the same network;

address stripping:

(ICAO/Annex 10) in connection with multiple addressing procedures, the


procedure for removing addresses from messages when the addresses are
not required for onward transmission by another centre;

addressing:

the association of identifiers to protocol entities for the purpose of directing


protocol data units to the entities;

Aeronautical Fixed Service:

(ICAO/Annex 10) voice and data telecommunications service operated by


ICAO States; users are at fixed locations;

Aeronautical Fixed
Telecommunication Network:

(ICAO/Annex 10) the world-wide network providing the data part of the
AFS

AFTN interface:

(CIDIN) a CIDIN application which uses the CIDIN transport service with
the corresponding mapping for the purpose of forwarding AFTN messages
within the AFTN;

alternate routing:

the procedure of forwarding data by a route which is different from the


normal one; normally due to the normal route being out of service or
overloaded;

application:

a specific group of users of the CIDIN network, that share the same global
task type and use compatible procedures and protocols; these users can be
persons or automated processes;

application entity:

a specific user within this application is identified with the words


"application entity"; the application entities are the units which are to be
addressed, and who are assigned the Axs/Aes (Ax and Ae are identical for
the same entity).

ASCII:

a 7-bit coded character set; includes alpha-numeric, control and graphic


characters;

audit trail:

the recording of a sequence of events which belong to one context, e.g. the
transmission of one message; used for the investigation of error situations;

bearer network:

network equipment which plays the server role in a client-server


relationship between network components or layers;

Appendix A

Sixth Edition
Page 6 of 14

14/04/2011

EUR CIDIN MANUAL APPENDICES

bit error rate:

average fraction of bits which are received in error; an acceptable rate might
be, e.g. 10-6

bit stuffing:

procedure for avoiding the presence of a delimiter (e.g. flag) while allowing
complete transparency of user data;

boundary:

(CIDIN) a virtual closed line enclosing a set of CIDIN centres;

bulk data transfer:

a type of application of communication services in which large volumes


(e.g. megabytes) of data are transferred;

bulletin:

a set of data with common characteristics, e.g. meteorological data for a


specified area at a given time;

centre:

(CIDIN) switching centre in the CIDIN network which handles the CIDIN
protocols;

CIDIN Management Centre

a centralised entity which stores the CIDIN network management database


and performs the centralised management functions;

Co-operating CIDIN Centre:

a COM Centre which participates in the centralised CIDIN network


management activities;

code and byte independence:

(ICAO) procedures allowing the transmission of any bit combinations in


complete octets of data;

code/format:

(CIDIN) indication of the way in which user data is structured and


expressed in bit combinations in a message; refers to a type of application;

common network:

a network providing service not only to one particular application or user;

Common ICAO Data


Interchange Network:

(CIDIN) data network within the AFS;

confirmation:

(ISO) a type of service primitive; information returned to a service user


concerning the execution of a service requested by the user;

conformance test:

(OSI) a test of a protocol implementation with respect to its specification;

conformance test procedure:

part of a conformance test; usually relates to a specific aspect of the


protocol and is performed according to a well-defined script;

connection oriented:

(ISO) a class of protocols/service providing a connection context;


necessitate connection establishment and disconnection phases;

connectionless:

(ISO) a class of protocols/service providing no connection context; data is


transmitted without a previous connection establishment phase;

conventional AFTN:

(ICAO/Annex 10) data part of the AFS without CIDIN; based on teletype
procedures;

conversational mode:

(CIDIN) type of communication between two users in which a sequence of


interactions together form a dialogue;

cutover:

transition of a system from testing to operations;

cyclic redundancy check:

a set of redundant data in a protocol data unit which allow the detection and
correction of a class of transmission errors;

Appendix A

Sixth Edition
Page 7 of 14

14/04/2011

EUR CIDIN MANUAL APPENDICES

data circuit terminating


equipment (DCE):

(CCITT) network equipment providing user access to the network;

data integrity:

measure of the quality of transmission;

data link frame:

protocol data unit in the link layer;

data link layer:

layer providing service to the network layer; concerned with the reliable
transfer of data across the data link;

data terminal equipment (DTE):

(CCITT) user system accessing a network;

deadlock:

situation in which each of two or more related parties waits for enabling
conditions to be signalled from the other party(ies); no useful work is
performed in this state;

dedicated circuit:

transmission resource used for one particular service or application or


between one pair of locations;

dedicated procedures:

procedures which are useful only to one particular type of application;

delimiter:

indication of the end of a field;

destination address:

(ICAO/Annex 10) AFTN addressee indicator when contained in a CIDIN


packet header;

digital facsimile:

presentation protocol for the transmission of images;

diversion:

an exceptional route for a message to a destination;

duplex:

allowing two way simultaneous traffic;

dynamic routing:

a routing strategy which varies with time depending on the current state of
the network;

encapsulate:

enclose a block of data between header and trailer without changing the
data;

end-to-end:

range of a function extends right up to the corresponding points at the users;

enquiry:

(CIDIN) the request to a remote CIDIN exit centre for information on its
status; the procedure is performed when an entry centre has reasons to
believe that the remote centre is out of order or cannot be reached;

entry address:

CIDIN address of an application entity submitting a message to CIDIN;

entry centre:

(CIDIN) CIDIN centre at which a given message is submitted for transport


by CIDIN;

error processing:

the treatment of non-normal situations with the aim of recovery;

evolutionary upgrade:

enhancement of the functionality of a system in small steps without placing


great change requirements on the systems environment;

exit address:

(CIDIN) unique identification of a CIDIN user for the purpose of delivering


messages;

Appendix A

Sixth Edition
Page 8 of 14

14/04/2011

EUR CIDIN MANUAL APPENDICES

exit address:

(CIDIN) CIDIN address of an application entity to which a message is


being sent;

exit centre:

(CIDIN) CIDIN centre at which a message leaves CIDIN;

facsimile data:

binary representation of images;

ferry:

(ISO) technique for conformance testing; a ferry channel provides the


means for co-ordinating local and remote implementations under test;

file transfer:

- see bulk data transfer

finite state machine:

technique for representing the behaviour of an automation; at any time it


exists in one of a finite number of States; State changes dependent on
external events are defined;

formal description technique:

method of defining a protocol using formal syntax and semantics; a goal is


the proof of correctness and consistency of the definition;

frame:

protocol data unit transferred across a data link;

functional requirement:

requirement placed on a system referring to qualitative features rather than


quantitative features such as capacity, throughput, etc.;

general coding principles:

common methods for coding information as binary values;

general format identifier:

method of indicating the type of contents in a set of data fields; applicable


to a wide range of field types;

glossary:

(CIDIN) explanation of terms and abbreviations from the CIDIN Manual;


may contain a reference to itself;

High Level Data Link Control


Procedures (HDLC):

(CCITT) a set of bit-oriented link layer procedures;

IA-5, International Alphabet


Number 5:

a 7 bit alpha-numeric character set coding system;

implementation under test:

(ISO) implementation of one or more protocols which are to be studied by


testing;

improved AFTN:

(ICAO) data part of the AFS based on CIDIN;

incomplete message:

(CIDIN) message at an exit centre of which parts are missing;

indication:

(ISO) type of service primitive; information provided to a user who did not
initiate the interaction;

information frame:

(CCITT) frame containing user information;

interoperability testing:

(CIDIN) testing phase in which two (bilateral) or four (quadrilateral)


CIDIN centres are tested together.

interactive:

a mode of working in which two or more systems or people co-operate


under strict time constraints;

inter-working:

the co-operation of systems (networks) to deliver a common service;

Appendix A

Sixth Edition
Page 9 of 14

14/04/2011

EUR CIDIN MANUAL APPENDICES

ITA-2, International Telegraph


Alphabet Number 2:

a 5 bit alpha-numeric character set coding system;

line monitor/analyser:

test equipment which records and analyses transmitted data;

Link Access Procedure,


Balanced Class (LAP-B):

(CCITT) a variant of HDLC; component of X.25;

logical channel:

(CCITT) possible connection-oriented relationship provided by X.25;

looping counter:

(CIDIN) a counter which contains the number of relay centres which a


CIDIN packet has traversed;

looping of messages:

(CIDIN) an error situation in which a message repeatedly travels the same


path through the network without coming closer to its destination; can be
caused by inconsistencies in routing tables;

main connection path

the preferred connection path between two CIDIN centres established over
a group of virtual circuits;

M-bit:

a bit in X.25 coding used in CIDIN for chaining segments of CIDIN


packets in public packet switching networks;

management centre:

(CIDIN) network management system with global knowledge of network


configuration and status;

medium speed:

transmission at speeds of the order of 2,400 bps;

meshed network:

interconnection of network nodes (switching enters) in such a way that


many alternative routes through the network are possible;

message:

(CIDIN) block of data which together represents a set of information;


handled as one whole by the network (as seen by the user);

message handling:

the transfer and processing of messages (documents)

message identification number:

(CIDIN) unique identification of a message generated by an entry centre;

modulo arithmetic:

arithmetic with a small finite number of digits;

multi layer testing:

the testing of more than one protocol layer implementation simultaneously:

multiple dissemination:

the transmission of a message to more than one destination; replication is


done in the network layer;

multiplexing:

a method to combine many different channels of information on to one


physical link;

natural language description:

specification by means of a spoken language such as English;

nesting:

containment of one object within another;

network access protocol:

protocol between a network users system and the network;

network acknowledgement:

(CIDIN) confirmation by the exit centre of successful message reception to


the entry centre

network carrier:

provider of network services (e.g. PTT)

Appendix A

Sixth Edition
Page 10 of 14

14/04/2011

EUR CIDIN MANUAL APPENDICES

network extension:

(CIDIN) testing phase in which new features or an extended configuration


are tested;

network management:

the task of organising, controlling and administering the resources in a


network;

octet:

an eight bit byte;

Open Systems Interconnection


(OSI):

(ISO) a distributed computer system interconnection architecture


standardised by the ISO;

operator:

(CIDIN) person operating a CIDIN centre performing system monitoring


and control;

OSI reference model:

(ISO) the basic model for the open system interconnection as defined by the
ISO;

packet:

(CIDIN) block of data which is handled as an integral unit;

packet header:

(CIDIN) protocol control information in a packet;

packet layer:

(CIDIN) provider of service to the transport layer;

packet looping indicator:

see looping counter;

packet switching:

a technique used in data communication for transmitting information in


blocks (packets) utilising store-and-forward technique;

peer-to-peer:

(ISO) a relationship between entities in the same layer of the OSI Reference
Model;

permanent virtual circuit:

(CCITT) an X.25 virtual circuit that is permanently set up. No connection


or disconnection phases are needed;

permanent virtual circuit


termination centre:

(CIDIN) a centre in which a user of a permanent virtual centre is located;

permanent virtual transit centre:

(CIDIN) a centre which provides a concatenation of a pair of virtual circuits


in a predefined manner;

physical layer:

(ISO) the lowest layer of the OSI Reference Model;

point-to-point:

a communication relationship between two (and only two) partners;

poll:

request for information or reply from a remote communication partner;

primary route:

a route which is selected for data flow from source to destination unless
circumstances indicate that this is undesirable;

primitive:

(ISO) a single interaction between service user and service provider in the
OSI Reference Model;

priority handling:

the processing, e.g. scheduling of events depending on their relative


importance;

priority indicator:

(ICAO/ANNEX10) indication of the relative importance of a data unit (or


message) with respect to other data units (or messages);

Appendix A

Sixth Edition
Page 11 of 14

14/04/2011

EUR CIDIN MANUAL APPENDICES

profile:

(ISO) a set of one or more standards and/or the identification of chosen


classes, subsets, options or parameters of those standards;

protocol:

a set of rules formulated to control the exchange of data between two


communicating parties;

protocol architecture:

relationships between protocols in a communication context;

protocol control information


(ISO):

that part in a protocol data unit which is used between entities to co-ordinate
their operation;

protocol data unit:

(ISO) a set of data exchanged between two protocol entities at a particular


layer;

protocol layer:

(ISO) a constituent part of the OSI Reference Model which defines a well
defined function in the communication context; (the OSI Reference Model
consists of 7 protocol layers)

protocol implementation
conformance statement

a statement denoting which capabilities have been implemented for a


protocol;

profile requirements list

profile requirements expressed in the form of conformance requirements


and arranged in a tabular list format;

public data network (PDN):

a network providing a transmission service which can be subscribed to;

PVC Validate

an operator action to enable the reception of CIDIN packets on a PVC;

PVC Invalidate

An operator action to prevent the reception of CIDIN packets on a PVC;

queue:

an ordered collection on objects waiting for service;

re-assembly:

the process of putting a set of parts, e.g. of a message, together in the


original sequence;

recording:

storing information on the sequence of events;

regional subnetwork:

part of a network located in one geographical area;

relay centre:

(CIDIN) CIDIN centre, at which passes the CIDIN packets are forwarded
from one centre to another centre;

request (ISO):

type of service primitive issued by the user of a service to invoke a specific


service;

reset:

a function which sets the correspondent entities to a predefined state (reinitialisation);

reset collision:

the simultaneous and uncoordinated issuing of reset requests of two or more


communication parties;

response:

(ISO) a type of service primitive issued by the user of the service to


acknowledge or complete some procedure previously invoked by an
indication to that user;

restart:

bringing a resource, e.g. a set of PVCs, into its original state to resume
operation;

Appendix A

Sixth Edition
Page 12 of 14

14/04/2011

EUR CIDIN MANUAL APPENDICES

routing:

procedures for passing messages or other data units through a network to


specified destination;

routing table:

a table of correspondences between message destinations and next centre;

routing exchange:

(CIDIN) network management procedure for exchanging information


related to routing;

segmenting:

the process of dividing a block of data (message) into a concatenated


sequence of smaller parts;

service access point (ISO):

conceptual point at which a service user accesses the service provider in a


layered communication system associated with an address;

service provider:

(OSI) concept of the Reference Model referring to the lower layer of a pair
of layers;

session:

a relationship between two users of communication services which


normally lasts for an extended time interval, e.g. minutes;

single layer testing:

the testing of protocol layers individually;

static routing:

routing procedures which are not dynamically dependent on the current


state of the network;

station:

(CIDIN) a centre providing only entry/exit functions;

statistics gathering:

the recording of statistical information;

store-and-forward:

a technique in which blocks of data are stored in a node before being passed
on to the next node;

sublayer:

(OSI) subdivision of a layer;

switched virtual circuit:

an X.25 virtual circuit which requires a connection and disconnection


phase;

system under test (SUT):

a system which is the object of testing;

systems management:

(ISO) functions in the application layer related to the management of


various OSI resources across all layers of the architecture;

test group:

(CIDIN) group of test procedures;

test partner:

(CIDIN) another installation involved in a test;

test phase:

(CIDIN) one of the five parts of testing a CIDIN implementation or part of


the network;

test procedure:

a set of activities to be performed when testing;

test responder:

user of a protocol layer under test; not the initiator of test procedures;

time out:

monitoring in time for no activity;

topology:

a set of spatial relationships; the physical and logical relationship of nodes


in a network (schematic arrangement of links and nodes);

Appendix A

Sixth Edition
Page 13 of 14

14/04/2011

EUR CIDIN MANUAL APPENDICES

trailer:

last part of a PDU;

transit time:

time taken to traverse a (sub-)network;

transparent:

not visible to and not affected by a process;

transport header:

(CIDIN) protocol control information in a transport protocol data unit;

transport layer:

(CIDIN) provider of the CIDIN service to the CIDIN users and


applications;

transport layer:

the lowest layer of the Reference Model with end-to-end significance;

transport service:

service provided by the transport layer;

trials:

(CIDIN) the testing of CIDIN protocols and centre implementations before


operations commence;

tributary:

a subordinate part of a network;

user:

the client in a client-server relationship;

user data:

data which are only understood and processed by the user;

virtual circuit:

(CCITT, X.25) logical relationship between two users of the X.25 service;

virtual circuit group

a number of VCs that connect two and only two CIDIN centres;

END of Appendix A

Appendix A

Sixth Edition
Page 14 of 14

14/04/2011

EUR CIDIN MANUAL APPENDICES

Appendix B CIDIN Conformance Proforma

B.1

Introduction

B.1.1

The CIDIN standard contains a large number of configurable options, for which there is no simplified
material to aid either future procurement of CIDIN equipment or the setting up of new CIDIN links.

B.1.2

Over/under specification of new equipment and complications in establishment of new links could be
avoided if the details of essential operational parameters and mandatory/optional functions were
clarified.

B.1.3

EUR AFS 1995 proposed the development of a guidance document that contained a summary of
essential detail from the CIDIN Manual and other relevant references.

B.1.4

It should be pointed out that in cases of interconnected networks, the values specified in Layers 1, 2
and 3a may not apply. In such cases, the relevant functional equivalents should be use

B.1.5

The CIDIN Conformance Proforma is a dynamic document, which should be regularly updated to
reflect relevant amendments to Annex 10 and the CIDIN Manual, as well as AFSG recommendations.

B.2

Document Structure

B.2.1

This document is structured in a manner corresponding to the CIDIN layered model, i.e. Physical,
Link, Network, CIDIN and Application Layers.

B.2.2

The Proforma syntax is as follows:

Item

Value/Configuration

Status

References

Where:

B.2.3

Item

= parameter to be defined/specified

Value

= value, specification or configuration of the item

Status

= shows Mandatory or Optional status

Reference

= shows references into ICAO and other documentation

The following symbols are used in the proforma:


(Item number)
B
M
NA
O
O(n)
(P)
R
R(n)
S

B.2.4

Conditional item symbol dependent upon the support marked for (item)
Dependant on bilateral agreement with connecting Centre
Mandatory
Not applicable
Optional
Optional, but at least one of reference (n) must be supported
Parameter
Recommended
Recommended where options supported by reference (n) are not supported
Superseded by later recommendation

It is recommended that the following information, as a minimum, be requested as part of any CIDIN
supply enquiry:

Appendix B

Supplier Details

Sixth Edition
Page 1 of 9

14/04/2011

EUR CIDIN MANUAL APPENDICES

Date of statement
Implementation name/version

Hardware name/version

Operating system name/version

Other Operating systems/version claimed compatible

Statement of compliance with relevant provisions of standard documents

B.2.5

Section 6 shows a breakdown of parameters that have "optional" or "non-defined" value. These must
be compatible between connecting CIDIN centres to achieve successful operation and they should
be agreed on initial link establishment.

B.3

References and Standards

B.3.1

ICAO Annex 10, Vol. II and III (up to and including Amendment 76)

B.3.2

ICAO EUR CIDIN Manual, Second Edition, Issue 1

B.3.3

CCITT/ITU-T Recommendations X, V, M

B.3.4

Recommendations of EUR AFS/AFSG Meetings

B.4

Conformance Proformae

B.4.1

Physical Layer Layer 1

Item
B.4.1.1Physical Interface
B.4.1.1.1
B.4.1.1.2
B.4.1.1.3
B.4.1.2 Signaling Rate
B.4.1.2.1
B.4.1.2.2
B.4.1.2.3
B.4.1.2.4
B.4.1.3 Modulation
B.4.1.3.1
B.4.1.3.2
B.4.1.3.3
B.4.1.3.4
B.4.1.4 Circuit Type
B.4.1.4.1
B.4.1.4.2
B.4.1.5 Character Set
B.4.1.6 User Notification
B.4.1.6.1

Appendix B

Value/Configuration

Status

V.24/V.28
X.21 bis
X.21
(P) bits per second
600, 1200
2400, 4800
9600
64 kbps or greater
(P)
V.23
V.26, V.27
V.29
V.32

O 4.1.1
O 4.1.1
O 4.1.1

M.1020
Digital
IA-5

R 4.1.4, B
O 4.1.4, B
M

Physical Errors

References
CM 2, CM 2.2.3

CM 2.1, A10 8.6.2


O 4.1.2, B
O 4.1.2, B
O 4.1.2, B
O 4.1.2, B
CM 2.1, A10 8.6.2.3
O 4.1.3, B
O 4.1.3, B
O 4.1.3, B
O 4.1.3, B, R for 4.1.2.3
CM 2.1.1

Sixth Edition
Page 2 of 9

CM 2.1.2
A10 8.6.1, A10 8.6.2.4
CM 2.2.2

14/04/2011

EUR CIDIN MANUAL APPENDICES

B.4.2

Link Layer Layer 2

Item
B.4.2.1 Link Procedure

B.4.2.2 Data Field Length


B.4.2.3 Repetition Counter
B.4.2.3.1 N2
B.4.2.3.2 N2
B.4.2.4 Window Size
K
B.4.2.5 Timer Values
B.4.2.5.1.1 T1
B.4.2.5.1.2 T1
B.4.2.6 Address
B.4.2.6.1 A/B
B.4.2.6.2 B/A
B.4.2.7 Statistics
B.4.2.8 User Notification
B.4.2.8.1

B.4.3

Value/Configuration
HDLC LAP-B
Frame format, Transmission
Sequences, Modes of Operation,
Functions
and
Parameters,
Commands and Responses, Busy
Condition, Time Out Functions
N1 = 259 Octets Maximum
(P)
10
5
K = 1 to 7
7
(P) seconds
5
3
(P)
01/03
03/01
As listed in References
Link Failure and
Re-establishment

Status
M

References
CM 3.1, CM 3.2
A10 8.6.4

CM 3.2.2.3
CM 3.2.7.3

S
R
R
S
R
O
O 4.2.6, B
O 4.2.6, B
M
M

CM 3.2.5.1
CM 3.2.7.1
CM 3.2.7.2

CM 3.2.2.5

CM 8.5
CM 3.2.1.3

Network Layer Layer 3a (X.25 Packet Layer)

Item
B.4.3.1 Procedure

Status
M
R

References
CM 4, A10 8.6.5.3.2

CM 4.1.1

(P) 0 to FFF
(P)

M
R
B, R
R

CM 4.1.1, 4.2
CM 4.1.7, CM 4.2.4
CM 4.1.3.2
CM 5.3.1.1.4

By Bilateral Agreement

B, O

CM 4.2.1, CM 4.2.2,
CM 4.2.7,CM 5.3,CM ApF

B.4.3.2.1.6 SVC Range


SVC Identifier
Format
B.4.3.3 User Data Field

400 to 4FF
(P)

B,R, 4.3.2.1.3
R

256 Octets Maximum

B.4.3.4 Window Size


W
B.4.3.5 Timer Values
B.4.3.5.1.1 T20
B.4.3.5.1.2 T20
B.4.3.5.3.1 T22

(P) K = 2 to 7
7
(P) seconds
180
30
180

O, B
R

CM 4.1.1.4,
A10 8.6.5.1.3.4
CM 4.2.5, CM 4.1.6.5,
CM 4.1.1.4

S
R
S

CM 4.1.8.2
CM 4.2.9
CM 4.1.7.3

B.4.3.2 Virtual Circuits and


Procedures
B.4.3.2.1.1 PVC Implementation
B.4.3.2.1.2 PVC Reset Handling
B.4.3.2.1.3 PVC LCI
B.4.3.2.1.4 PVC Identifier
Format
B.4.3.2.1.5 SVC Implementation

Appendix B

Value/Configuration
X.25 1980
X.25 1984
Packet Format,
Logical Channels,
Reaction to Invalid Packets,
Initialization Procedures,
Data Transfer Procedures
By Bilateral Agreement

Sixth Edition
Page 3 of 9

CM 5.3.1.1.4

14/04/2011

EUR CIDIN MANUAL APPENDICES


Item
B.4.3.5.3.2 T22
B.4.3.6 Statistics
B.4.3.7 User Notification

Value/Configuration
30
As listed in References

Status
R
M

B.4.3.7.1
B.4.3.7.2
B.4.3.7.3
B.4.3.7.4

Reset/Restart Initiation and


Termination
Format Errors
Message Queue per PVC

B.4.4

M
R

Network Layer Layer 3b (CIDIN Packet Layer)

Item
B.4.4.1 Procedure

B.4.4.2 Routing

B.4.4.3 CIDIN Packet Length


B.4.4.4 Message Priority
B.4.4.5 Ax Length
B.4.4.6 Number of Ax per
CIDIN Message
B.4.4.7 Number of Ad per
Destination Address Item
B.4.4.8 Number of Ad per Ax
B.4.4.9 Statistics
B.4.4.10 User Notification
B.4.4.10.1
B.4.4.10.2

Appendix B

References
CM 4.2.9
CM 8.5, CM 8.6
CM 4.2.1.3, CM 4.2.6,
CM 4.1.7.5.6, CM 5.3.1

Value/Configuration
CIDIN Packet Protocol
Packet Format, Packet
Procedures, Packet
Transmission, Loss of
Communication Procedure,
VC Management
(P)
Routing, Relay,
Multiple Dissemination,
Alternative Routing
(P) 256 Octets Maximum
(P) 1 to 8

Status
M

M
M

CM 5.2.2.1
CM 5.1.2.4,

(P) 5 to 8 Octets
16 Maximum

M
M

CM5.1.2.7, CM5.2.2.5
CM 5.1.2.7

15 Maximum

CM 5.2.2.4

21 Maximum
As listed in References

M
M

CM 6.2.6.5
CM 8.4, CM 8.6
CM 5.2

Incorrect Format
Message Queue per Ax

M
R

Sixth Edition
Page 4 of 9

References
CM 5, A10 8.6.5.3.3

M
CM 5.1.3, CM 5.2.3
CM 5.2.4

14/04/2011

EUR CIDIN MANUAL APPENDICES

B.4.5

CIDIN Transport Layer Level 4


Value/Configuration
CIDIN Transport Protocol
Transport Header Format,
Transport Procedures,
MIN Assignment,
Message Handling,
Invalid Message Handling
(P) 4 Octets Maximum

Status
M

References
CM 6, A10 8.6.5.3.4

CM 6.1.2.1.4.1

(P) 2 Octets Maximum

CM 6.1.2.1.4.3,

B.4.5.3.2.1 Message Length


B.4.5.3.2.2 Message Length
B.4.5.4 Ae Length
B.4.5.5 Window Size
w
B.4.5.6 Timers
B.4.5.6.1 TMR
B.4.5.6.2 TNMA
B.4.5.6.3 TEM
B.4.5.7 Network Management

215 CIDIN Packets Maximum


64 Kb
(P) 5 to 8 Octets
(P) = 1 to 99
5
(P) seconds
40
35
40

S
R
M
O
R
O
R
R
R

CM 6.1.1.2, A10 8.6.5.4.2


CM 6.1.1.3
CM 6.1.2.1.4.5
CM 6.2.10
CM 6.2.10
CM 6.1.2.2.6
CM 6.2.10
CM 6.2.10
CM 6.2.10
CM Table 6.1
CM Table 6.2

B.4.5.7.1 NA
B.4.5.7.2 CP
B.4.5.7.3 MT
B.4.5.7.4 ENQ NMF
B.4.5.7.5 ENQ Response NMF
B.4.5.7.6 ACK NMF
B.4.5.7.7 MCF Error NMF
B.4.5.8 Network Management
Procedures
B.4.5.8.1
B.4.5.8.2
B.4.5.8.3
B.4.5.8.4
B.4.5.9 Handling of CIDIN
Message Repetition
B.4.5.9.1
B.4.5.9.2

0
0
1
2
4
3
8

M
M
M
M
M
M
M
M

Item
B.4.5.1 Procedure

B.4.5.2 MIN Length


B.4.5.3
B.4.5.3.1 CPSN Length

B.4.5.10 Statistics
B.4.5.11 User Notification
B.4.5.11.1
B.4.5.11.2
B.4.5.11.3
B.4.5.11.4
B.4.5.11.5

Appendix B

ACK
ENQ
MCF Error
Flow Control

CM 6.2.6, CM 6.1.2.2.6
CM 6.2.6
CM 6.2.9
CM 6.1.2.2.8
CM 6.2.11

MIN Handling
TMR Configurable per Ax
Group
As listed in References
Ax Accessibility
Missing ACK
Incomplete Message
Incorrect Format
Timer Expiration

Sixth Edition
Page 5 of 9

R
R

CM 6.2.5.2, 6.2.5.2
C.M. 6.2.10

M
M

CM 8.3
CM 6.1.2.2.6.2.6,
CM 6.1.2.2.6.2.3, CM 6.2.2.1.3
CM 6.2.3.1.3
CM 6.2.3.1.4, CM 6.2.7.1
CM 6.2.7.1, CM 6.2.6
CM 6.2.9.1, 6.1.2.2.6

14/04/2011

EUR CIDIN MANUAL APPENDICES

B.4.6

Application Layer CIDIN Network Management Application

Item
B.4.6.1 Procedure
B.4.6.1.1
B.4.6.1.2
B.4.6.2 Parameters
B.4.6.2.1 NA
B.4.6.2.2 CP
B.4.6.2.3 MT
B.4.6.2.4 MCF
B.4.6.3 Ae/Ax Fifth Character
B.4.6.4 Message Priority
B.4.6.4.1 Operator
B.4.6.4.2 Routing
B.4.6.4.3 Statistics
B.4.6.5 Message Format
B.4.6.5.1
B.4.6.5.2
B.4.6.5.3
B.4.6.6 Statistics

B.4.7

Status

References
CM 1.2.2.3.9

M
O
CM Table 6.1
M
M
M
M
M

MP = 1 to 8/Codes 000 to 111


MP = 1/Code 000
MP = 7/Code 110

M
M
M

Operator Messages
Routing Messages
Statistics Messages
As listed in References

M
M
M
M

CM 1.2.2.4.5
CM 7.5

CM 7.7
CM 10.2
CM 11
CM 8.2

Application Layer AFTN Application

Item
B.4.7.1 Procedure
B.4.7.2 Parameters
B.4.7.2.1 NA
B.4.7.2.2 CP
B.4.7.2.3 MT
B.4.7.2.4 MCF
B.4.7.3 Ae/Ax Fifth Character
B.4.7.4 Message Priority
B.4.7.4.1 SS
B.4.7.4.2 DD
B.4.7.4.3 FF
B.4.7.4.4 GG
B.4.7.4.5 KK
B.4.7.5 Message Format
B.4.7.6 Audit Trail
B.4.7.7 Statistics
B.4.7.8 User Notification
B.4.7.8.1

Appendix B

Value/Configuration
Network Management and
Administration,
Operator Message Exchange,
Network Message
Management Exchange
(P)
1
0
0
1
M

Value/Configuration
Aeronautical Fixed
Telecommunication Network
(P)
1
0
0
2
A

Status
M

MP = 2/Code 001
MP = 4/Code 011
MP = 5/Code 100
MP = 6/Code 101
MP = 7/Code 110
A10, Vol. II, Ch. 4
Ae/MIN-TI/CSN Correlation
As listed in References

M
M
M
M
M
M
M
R

Errors

Sixth Edition
Page 6 of 9

References
CM 7, A10-Vol.II-Ch.4
CM Table 6.1

M
M
M
M
M

CM 1.2.2.4.4
CM 7.5

CM 7.3, A10-Vol.II-Ch.4
CM 7.7.1
CM 8.2
CM 7.7.2

14/04/2011

EUR CIDIN MANUAL APPENDICES

B.4.8

Application Layer OPMET Operator Message Application

Item
B.4.8.1 Procedure
B.4.8.2 Parameters
B.4.8.2.1 NA
B.4.8.2.2 CP
B.4.8.2.3 MT
B.4.8.2.4 MCF
B.4.8.3 Ae/Ax Fifth and Sixth
Character
B.4.8.4 Message Priority
B.4.8.5 Message Format
B.4.8.6 Statistics

B.4.9

References

(P)
1
0
0
1
MM

R
M
M
R
R

CM Table 6.1

MP = 1 to 8
As Described in References
TBD

R
R
R

CM 1.2.2.5.2
WMO 386

Status
R

References
WMO 386
CM Table 6.1

CM 1.2.2.5.3

Value/Configuration
(P)
1
0
0
3
O
MP = 6/Code 101
As Described in References
TBD

M
M
M
R
M
R
M
R

CM 1.2.2.5.2
CM 1.2.2.5.3
WMO 386

Application Layer ATN Subnetwork Application

Item
B.4.10.1 Procedure
B.4.10.2 Parameters
B.4.10.2.1 NA
B.4.10.2.2 CP
B.4.10.2.3 MT
B.4.10.2.4 MCF
B.4.10.3 Ae/Ax Fifth
Character
B.4.10.4 Message Priority
B.4.10.5 Message Format
B.4.10.6 Statistics

Appendix B

Status
R

Application Layer OPMET Application

Item
B.4.9.1 Procedure
B.4.9.2 Parameters
B.4.9.2.1 NA
B.4.9.2.2 CP
B.4.9.2.3 MT
B.4.9.2.4 MCF
B.4.9.3 Ae/Ax Fifth Character
B.4.9.4 Message Priority
B.4.9.5 Message Format
B.4.9.6 Statistics

B.4.10

Value/Configuration

Value/Configuration

Status
R

(P)
0
0
0
4
TBD

M
M
M
R
R

MP = 2,5,7/Codes 001,100,110
As Described in References
TBD

R
M
R

Sixth Edition
Page 7 of 9

References
ICAO Doc 9705-AN/956
CM Table 6.1

ICAO Doc 9739-AN/961


ICAO Doc 9705-AN/956

14/04/2011

EUR CIDIN MANUAL APPENDICES

B.5

Abbreviations and Symbols

ACK
Ad
Ae
AFSG
AFTN
AN
Ap
Ax
A10
A10, Vol. II

Acknowledgement Message
CIDIN Destination Address
CIDIN Entry Address
Aeronautical Fixed Service Group
Aeronautical Fixed Telecommunication Network
Air Navigation
Appendix B to the CIDIN Manual
CIDIN Exit Address
Annex 10, Volume III, July 1995 up to and including Amendment 76
Annex 10, Volume II, July 1995 up to and including Amendment 76

bps
CID
CM
CP
CPSN
CSN

bits per second


Common ICAO Data Interchange Network
CIDIN Manual/ICAO EUR DOC 005
Conversation Protect Indicator
CIDIN Packet Sequence Number
Channel Sequence Number

ENQ
HDLC LAP-B
IA
LCI

Enquiry Message
High Level Data Link Control - Link Access Protocol-B
International Alphabet
Logical Channel Identifier

M
MCF
MIN
MP
MT

ITU-T Recommendation M-Series


Message Code and Format Indicator
Message Identification Number
Message Priority Indicator
Message Type Indicator

NA
NMF

Network Acknowledgement Indicator


Network Management Field Indicator

PVC
R
SVC

Permanent Virtual Circuit


CCITT/ITU-T Recommendation R-Series
Switched Virtual Circuit

TEM
TI
TMR
TNMA
TBD
V
WMO
X

Appendix B

Time-out for Enquiry Response


Transmission Identification
Time-out for Expected Network Acknowledgment
Time-out for Re-assembling of CIDIN Packets to a Message
To be Determined
CCITT/ITU-T Recommendation V-Series
World Meteorological Organization
CCITT/ITU-T Recommendation X-Series

Sixth Edition
Page 8 of 9

14/04/2011

EUR CIDIN MANUAL APPENDICES

B.6

Configurable Parameters Proforma for New CIDIN Connections

Reference
P.4.1.2
P.4.1.3
P.4.1.4

Item
Signaling Rate
Modulation
Circuit Type

Value
B
B
M.1020/64k

L.4.2.2

Data Field Length N1

259 Octets Max.

L.4.2.3
L.4.2.4
L.4.2.5.1.2
L.4.2.6.1
L.4.2.6.2

Repetition Counter N2
Window Size K
Timer Value T1
Address A/B
Address B/A

5/10
7
3
01/03
03/01

N.4.3.2.1.3
N.4.3.2.1.6
N.4.3.3
N.4.3.4
N.4.3.5.1.2
N.4.3.5.3.2

PVC LCI or
or SVC Range
Packet Size
Window Size W
Timer T20
Timer T22

CP.4.4.3

CIDIN Packet Length

CT.4.5.5
CT.4.5.6.1
CT.4.5.6.2
CT.4.5.6.3

Window Size W
Timer TMR
Timer TNMA
Timer TEM

Actual Value
B
B
B

0 to FFF
400 to 4FF
256 Octets
7
30
30

Comment
Bilateral agreement
Varies by P.4.1.2
Bilateral agreement
May vary by higher level
requirements

R
R

Bilateral agreement

B
R
R
R
R
R

Bilateral agreement
Bilateral agreement
Bilateral agreement
Bilateral agreement

R
R
R
R

May be modified dynamically

256 Octets Max.


5
40
35
40

Where:
P

= Physical Layer Parameters

= Link Layer Parameters

= Network X.25 Layer (3a) Parameters

CP

= CIDIN Packet Layer (3b) Parameters

CT

= CIDIN Transport Layer (4) Parameters

Note.- The table shows only parameters that are not specified as of Mandatory value and are required for the
setting up of new CIDIN connections between centres.

END of Appendix B

Appendix B

Sixth Edition
Page 9 of 9

14/04/2011

EUR CIDIN MANUAL APPENDICES

Appendix C General Coding Principles

C.1

Coding Principles

C.1.1

General

C.1.1.1

The formats in which the protocol control information (headers, trailers) is coded for the level 2 and
3a protocols are taken from the international standard X.25 and are not specific to CIDIN. The
CIDIN protocols for levels 3b and 4, on the other hand, are designed specifically for CIDIN. In
order to establish common principles for the coding of these layers, to simplify implementations and
to provide rules for the extension of headers if necessary at some later date, general coding
principles have been drawn up by the ADIS Panel.

C.2

Formats

C.2.1

Header Items

C.2.1.1

A self-contained unit within a header is called a "header item" or "item" for short. Two types of
formats are used for header items: a fixed length item (one octet) and a variable length item. The
fixed length item consists of a header item code (HIC) and a fixed length parameter (P). The
variable length item consists of a HIC, a parameter of variable length parameter (VP) and a length
indicator (L) which gives the length of VP in octets or as the number of its sub-parameters.

C.2.2

Header Item Code

C.2.2.1

The HIC is an identifier which uniquely specifies a particular item. It is coded as a binary number
which occupies bits 5 to 8 of the first octet of the item. (The bits of an octet are numbered 1 to 8, bit
1 being transmitted first).

C.2.2.2

In the HIC of a fixed length item, bits 7 and 8 are set to 0 and 1 respectively. The HIC can therefore
identify 4 distinct fixed length header items. In the HIC of a variable length item, bit 8 is set to 0.
The HIC can therefore identify 8 distinct variable length header items.

C.2.2.3

Parameters

C.2.2.3.1

The fixed length parameter (P) in the fixed length item occupies bits 1 to 4 of the first (and only)
octet of this item and is represented as a binary number.

C.2.2.3.2

The variable length parameter (VP) in the variable length item may be represented as a binary
number or as a string of IA5 characters, one character per octet. It occupies the second and
subsequent octets of the item. The length indicator (L) is the number of octets in VP. It is
represented as a binary number and occupies bits 1 to 4 of the first octet.

C.2.2.3.3

Since the type and length of header items are self defining, they can be skipped by the software
processing them without having to be processed in detail.

C.2.2.3.4

The two types of header items are illustrated below.

Appendix C

Sixth Edition
Page 1 of 3

14/04/2011

EUR CIDIN MANUAL APPENDICES


C.2.2.3.4.1 Fixed length item
<----------HIC---------->
1
0
X
X

<------P------>
P
P

8
Last bit
transmitted

1
First bit
transmitted

C.2.2.3.4.2 Variable Length Items


<------HIC------>
O
X
X
X
p
p
p
p

<---------L----------->
y
y
y
y
p
p
p
p

=
p
p

=
p
p

p
p

p
p

p
p

p
p

8
Last bit
transmitted

p
p

Parameter VP

p
p

1
First bit
transmitted

C.2.3

Allocation of Header Item Codes

C.2.3.1

Some of the possible codes have already been allocated to the headers of the level 3b and 4 protocol
data units.

C.2.3.1.1

Fixed Length Items


HIC
1000

CP/T
T*

1001
1010
1011

Header Item
End of header
(P is set to 0000)
not allocated
not allocated
not allocated

CP/T = Item belongs to CIDIN packet or transport header


* = The end of header item terminates the CIDIN transport header.
C.2.3.1.2

Variable Length Items


HIC
0000
0001
0010
0011
0100
0101
0110

CP/T
T
CP +
CP #+
CP
T
CP
T

Header Item, length of VP


entry address (Ae), L octets, 1<L<9.
exit address (Ax), L octets, 1<L<9.
destination address (Ad), 8L octets, 0<L<16
packet looping counter and priority, 1 octet
message identification number (MIN), L octets, 0<L<16
packet sequence number/final packet, L octets, 0<L<3
message characteristics, 1 octet

CP/T = Item belongs to CIDIN packet or transport header

Appendix C

Sixth Edition
Page 2 of 3

14/04/2011

EUR CIDIN MANUAL APPENDICES

#=

This item is only valid in the first CIDIN packet of message.

+=

These items can be present as pairs more than once in a CIDIN packet header.

END of Appendix C

Appendix C

Sixth Edition
Page 3 of 3

14/04/2011

EUR CIDIN MANUAL APPENDICES


Date of issue : 2003

Appendix D CIDIN TESTING PROCEDURES

CIDIN TESTING PROCEDURES

Appendix D

Sixth Edition
Page 1 of 1

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Conformance Testing

D.1

Appendix D

Date of issue:

2003

CONFORMANCE TESTS (SINGLE LAYER)

Sixth Edition
Page 1 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES

D.1.1

CONFORMANCE TESTING PROCEDURES

D.1.2

Purpose of conformance tests

The purpose of conformance testing is to demonstrate conformity of an implementation to the CIDIN protocol SARPs,
to diagnose and localize errors in individual protocol layers and, generally, to increase confidence in a new CIDIN
centre, by using a layer-for layer testing approach.
In the frame of such single layer conformance testing, each individual layer of the CIDIN protocol suite is considered as
an IUT and test sequences are designed to test the behaviour of only this one layer.
However, as the data link and network layer of CIDIN are based on well proven industrial standards (HDLC
LAPB/X.25), testing of these lower layers is not considered necessary. A certificate of conformance to X.25 provided
by the manufacturer involved should suffice.
The testing configurations proposed involve the system under test, CIDIN testing equipment or another CIDIN centre
and local connections. Depending on the type of connection used (PVC, SVC), CIDIN network layer test sequences are
distinguished in three categories:

Tests that apply to both types of VCs (VC)


Tests that apply to both types of VCs with minor adjustments (PVC/SVC)
Tests specific to PVCs
Tests specific to SVCs

For the CIDIN transport and application layer test sequences, the connection between the two centres is considered to
be one sole VC without distinction (PVC or SVC).
In case of SVCs, the SUT shall use an already established SVC to send user data and CIDIN ENQ, ENQr, ACK or
MCF Error messages. If no SVC has been established, the SUT shall send an X.25 call request.

D.1.3

Testing prerequisites

Prior to the actual testing phase, the appropriate general and specific parameters per layer must be set.

Appendix D

Sixth Edition
Page 2 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Conformance Testing

D.1.4

Appendix D

Date of issue: 2003

CONFORMANCE TESTS (SINGLE LAYER) Layer 3b

Sixth Edition
Page 3 of 101

14/04/2011

CIDIN Conformance Tests


Configurations

Layer :
Configuration :

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue: 2003

3b
A
Page: 1/2

System Under Test (SUT)


Parameter settings

Underlying layer
Installation state

CIDIN Centre, entry/exit centre, layer 3b

Exit Addresses Axs


(routing tables drawn up according to the needs of the procedures)

layer 3a

PVCs in flow control ready state


SVCs: In this configuration SVCs may also be used (where possible this is
indicated per test case) At any moment in time only one SVC shall exist
between two exit centres.

Parameter settings
Timers

window size = 7

T20 (reply to RESTART): 60 sec


T22 (reply to RESET): 60 sec
Maximum number of repetitions after timeout: 10

Number of test connections involved


Test Parameters

N.A.

:
SUT

System Under Test

CIDIN Testing Equipment or anther CIDIN Centre

Number of connections in underlying layer :


Connections
a: VCa
b: VCb

Additional conditions

(SUT) - (Y), VC
(SUT) (Y), VC

The configuration should be varied with links a and b on the same and/or different physical circuits.
When using SVCs: At any moment in time only one SVC shall exist between two exit centres.

SUT

Layer 4
Layer 3b

Test
Sequences

Layer 3a

Layer 3a

Layer 2

a: VCa

Layer 2

b: VCb

Appendix D

Sixth Edition
Page 4 of 101

14/04/2011

CIDIN Conformance Tests


Configurations

Layer :
Configuration :

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue: 2003

3b
B
Page: 2/2

System Under Tests (SUT)

CIDIN Centre, replay centre, layer 3b

Parameter settings

Exit Addresses Axs (routing tables drawn up according to the needs of the
procedures).

Underlying layer

layer 3a

all PVCs in flow control ready state

Installation state

SVCs: In this configuration SVCs may also be used (where possible this is
indicated per test case). At any moment in time only one SVC shall exist
between two exit centres.
Parameter settings
Timers

window size = 7

T20 (reply to RESTART): 60 sec


T22 (reply to RESET): 60 sec
Maximum number of repetitions after timeout: 10
Number of test connections involved

N.A.

Test Parameters

SUT

System Under Test

CIDIN Testing Equipment or anther CIDIN Centre

Number of connections in underlying layer :


Connections
a: VCa
b: VCb
c: VCc
Additional conditions

(SUT) - (Y), VC
(SUT) (Y), VC
(SUT) (Y), VC

Tests should be performed using various different correspondences of PVCs to circuits. More than one link is necessary.
For example a possible correspondence is VCa in link 1 and VCb and VCc in link 2.
When using SVCs: At any moment in time only one SVC shall exist between two exit centres.

SUT

Layer 4
Layer 3b

Test
Sequences

Layer 3a

Layer 3a

Layer 2

a: VCa

Layer 2

b: VCb
c: VCc

Appendix D

Sixth Edition
Page 5 of 101

14/04/2011

CIDIN Conformance Tests


Overview

Layer :
Test Group
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue: 2003

3b
1
Page: 1/1

Purpose :

Test entry centre functions for normal and error cases

List of procedures:
1.1

Entry centre functions (normal cases)

1.2

Entry centre functions (error cases)

1.3

Flow control on outgoing PVCs and independence of PVCs

Configuration used:

3b.A

To be preceded by test groups:

Coding:
CID 1 to CID 7:

layer 4 messages (AFTN and non-AFTN) with various sets and different
addresses (see procedure descriptions)
MP:

message priority 8

INV 1 to INV 6:

as CIDi but with various invalid features (see procedure descriptions)

M 1 to M2:

as CIDi but different message lengths (see procedure descriptions)

Installation:
The SUT is configured to initialise VCs (a) and (b) as appropriate.
The driving layer 4 has a batch of messages to send.

Special considerations:
The contents of the messages should be varied so that the CIDIN packets can be identifiable.
The non-AFTN messages could originate in the service message application.

Appendix D

Sixth Edition
Page 6 of 101

14/04/2011

CIDIN Conformance Tests


Procedures

Layer :
Test Group
:
Procedure
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

3b
1
1 (PVC/SVC)

Date of issue: 2003

Purpose: Entry centre functions (normal cases)

Page: 1/1
Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

Results - Additional
Comments during test
period

Prepare test messages CID 1 CID 5


Centre SUT (System Under Test) is initialised and
acting as a CIDIN entry centre
1

SUT

wait

SUT

a: VCa

send

CID 1

- 1 CIDIN packet, free text


- Addresses to 1 exit centre via VCa

SUT

a: VCa
b: VCb

send

CID 2

- 1 CIDIN packet, free text


- Addressed to several exit centres via VCs a & b

SUT

a: VCa

send

CID 3

- 1 CIDIN pocket, in AFTN format, addressed to


10 Ad's related to 1 Ax.

SUT

a: VCa

send

CID 4

- 2 CIDIN packets, in AFTN format, addresses to


10 Ad's related to 1 Ax

SUT

a: VCa

send

CID 5

- 1 CIDIN packets, in AFTN format addressed to


20 Ad's related to 1 Ax

a: VCa

wait

b: VCb

waits for operator indications


- layer 3b initialised
- VCs a & b initialised
[In case an SVC connection is used the SUT
issues an X.25 call request and Y accepts the
Call] At any moment in time only one SVC shall
exist between SUT and Y.
- Y is in the RECEIVE READY state

CID 1 to 5 Wait for CID 1 to 5 and check on correct reception


in particular check:
- CID 1 correctly coded (e.g. looping counter is set
to 31)
- CID 2 message duplicated on b
- in CID 3 addresses correctly coded
- in CID 4 addresses Ads only present within first
packet
- in CID 5 , correct coding of addresses
END OF PROCEDURE

Appendix D

Sixth Edition
Page 7 of 101

14/04/2011

CIDIN Conformance Tests


Procedures

Layer :
Test Group
:
Procedure
:
Step
No.

Alt.
Step
No.

Centre

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

3b
1
2 (PVC/SVC)
Connection

Action

Date of issue: 2003

Purpose: Entry centre functions (error cases)


Page: 1/1
Event

Parameters/Comments

Results - Additional
Comments during test
period

Prepare test messages CID 1 CID 5


Centre X (System Under Test) is initialised and
acting as a CIDIN entry centre
1

SUT

wait

SUT

a: VCa

send

CID 1

- 1 CIDIN packet, free text


- Addressed to 1 exit centre (Y) via VCa

SUT

a: VCa

send

INV 1

- 1 CIDIN packet, free text


- Addressed to 1 exit centre (Y) via VCa
(exit address unknown in SUT)

SUT

a: VCa

send

INV 2

- 1 CIDIN pocket, free text


- Addressed to 1 exit centre (Y) via VCa
(maximum allowed length exceeded)

SUT

a: VCa

send

INV 3

- 1 CIDIN packet, free text


- Addressed to 1 exit centre (Y) via VCa
(exit address is address of SUT)

SUT

a: VCa

send

INV 4a

as INV 1 except invalid HIC (i.e. not 0011)

SUT

a: VCa

send

INV 4b

as INV 1 except exit address item code non-valid


(i.e. not 0001)

SUT

a: VCa

send

INV 4

- 1 CIDIN packet, in AFTN format address to


several Axs
(With transport header not fit in one CIDIN packet)

INV 5

Message in AFTN format with more than 16 exit


addresses

b : VCb
9

SUT

a: VCa
b: VCb

send

10

a: VCa

wait

b: VCb

wait for operator indications


- layer 3b initialised
- VCs a & b initialised
[In case an SVC connection is used the SUT
issues an X.25 call request and Y accepts the
Call] At any moment in time only one SVC shall
exist between SUT and Y.
- Y is in the RECEIVE READY state

INV 1 TO Receive valid messages derived from CID 1


INV 5
& INV 1 to 5
& CID 1
Check for valid formats, in particular CHECK:
- INV 1 leads to no transmission
- INV 2 is truncated or not sent
- INV 3 is not sent
- for INV 4 and INV 5, more than one
messages generated

END OF PROCEDURE

Appendix D

Sixth Edition
Page 8 of 101

14/04/2011

CIDIN Conformance Tests


Procedures

Layer :
Test Group
:
Procedure
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

3b
1
3 (PVC)

Purpose:

Date of issue: 2003

Flow control of outgoing PVC and


independence of PVCs
Page: 1/1

Step
No.

Alt. Centre Connection


Step
No.

Action

Event

Parameters/Comments

Results - Additional
Comments during test
period

Prepare test messages CID 6 and CID 7


Centre SUT (System Under Test) is initialised
1

SUT

a: VCa

send

CID 6

Non AFTN message consisting of 64 CIDIN packets

SUT

b: VCb

send

CID 7

Message consisting of 1 CIDIN packet send on PVC


distinct from that of CID 6
CHECK:
- CID 6 and CID 7 can be sent simultaneously
(i.e. PVCs are independent)

a: VCa

wait

CID 6/1

b: VCb

wait

CID 7

a: VCa

wait

CID 6/2

Second CIDIN packet of CID 6


(Y now reduces rate of reception of CIDIN packets (e.g.
< one per sec.)

a: VCa

wait

CID 6/20

Twentieth CIDIN packet of CID 6

SUT

b: VCb

send

CID 7

b : VCb

wait

CID 7

a: VCa

wait

CID 6/64

First CIDIN packet of CID 6

Reception of remaining CIDIN packets

END OF PROCEDURE

Appendix D

Sixth Edition
Page 9 of 101

14/04/2011

CIDIN Conformance Tests


Overview
Layer
Test Group

:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue: 2003

3b
2

Page: 1/1

Purpose: Test relay functions


List of procedures:
2.1

Relay functions in a relay centre

2.2

Alternate routing in case of link failure

2.3

Priority handling and looping prevention

Configuration used:

3b.B

To be preceded by test groups:

Coding:
PDU 1 to PDU 6 :
CID 8

PDU11, PDU 12 :
PDU 7 :

CIDIN packets with different routing requirements


a long message consisting of 64 CIDIN packets
CIDIN packets with priorities 4 and 5 respectively
CIDIN packet with PLC set to 31

Installation:
The SUT is configured to initialise VCs a, b and c as PVCs or as SVCs.
When using SVCs: At any moment in time only one SVC shall exist between two exit centres.
(Initialisation by the test partner (Y) should also be demonstrated).

Special considerations:

Appendix D

Sixth Edition
Page 10 of 101

14/04/2011

CIDIN Conformance Tests


Procedures
Layer
Test Group
Procedure

Step
No.

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

3b
2
1 (PVC)

Alt. Centre Connection


Step
No.

Purpose:

Date of issue: 2003

Relay functions in a relay centre


Page: 1/1

Action

Event

Parameters/Comments

a: VCa

send

PDU 1

First CIDIN packet of a message to be routed


from SUT to Y via b

a: VCc

send

PDU 2

Second CIDIN packet of a message to be routed


from SUT to Y via b

a: VCa

send

PDU 3

First CIDIN packet of a message to be routed from


SUT to Y via a

b: VCb

send

PDU 4

Second CIDIN packet of a message to be routed


from SUT to Y via a

b: VCb

wait

PDU 1

b: VCb

wait

PDU 2

a: VCc

wait

PDU 3

a: VCc

wait

PDU 4

a: VCa

send

PDU 5

CIDIN packet 5 which SUT would normally route


via a
CHECK: PDU is not relayed via a

10

a: VCa

send

PDU 6

CIDIN packet which should be routed from SUT to Y


via b
CHECK: If a and b on the same circuit, the packet is
returned to Y

Results - Additional
Comments during test
period

END OF PROCEDURE

Appendix D

Sixth Edition
Page 11 of 101

14/04/2011

CIDIN Conformance Tests


Procedures
Layer
Test Group
Procedure

Step
No.

:
:
:

Alt. Centre
Step
No.

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

3b
2
2 (PVC)

Purpose:

Date of issue: 2003

Alternate routing in case of link failure


Page: 1/1

Connection

Action

Event

CID 8

Parameters/Comments

a: VCa

send

b: VCb

wait

CID 8/20 Receive the first 20 packets


Reduce rate of reception in Y on VCb
Execute RESET or RESTART on VCb

b: VCb

wait

CID 8/64 Receive remaining packets of CID 8


CHECK: at most 7 packets have been lost
because of the disturbance

a: VCa

send

c: VCb

wait

CID 8/20 Receive the first 20 packets


Reduce rate of reception in Y on VCb
Cause a link failure on the line carrying VCb

c: VCc

wait

CID 8/64 Receive remaining packets of CID 8 on c


CHECK: At most 7 packets have been lost
because of the disturbance

a: VCa

send

b: VCb

wait

b: VCb
c: VCc

wait

Results - Additional
Comments during test period

Non-AFTN message consisting of 64 packets


to be routed via b (primary) or a (alternate)

CID 8

CID 8
CID 8/20 Receive the first 20 packets
Reduce rate of reception in Y on VCb
Cause a link failure on the line carrying VCc
Cause a link failure on the line carrying VCb
Remove the failures on both links
Wait for SUT to initialise VCs b and c
CHECK: the message P is not retransmitted
and has been discarded
END OF PROCEDURE

Appendix D

Sixth Edition
Page 12 of 101

14/04/2011

CIDIN Conformance Tests


Procedures
Layer
Test Group
Procedure
Step
No.

Alt.
Step
No.

:
:
:
Centre

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

3b
2
3 (PVC/SVC)
Connection

Action

Purpose:

Date of issue: 2003

Priority handling and looping prevention


Page: 1/1

Event

Parameters/Comments

Results - Additional
Comments during test period

Cause blockage on line carrying b

At any moment in time only one SVC


shall exist between SUT and Y
1

a: VCa

send

PDU 8 CIDIN packet with priority 4 to be routed in SUT


via b

a: VCa

send

PDU 9 CIDIN packet with priority 5 to be routed in SUT


via b
Repeat steps 1 and 2 several times

b: VCb

wait

PDU 8

b: VCb

wait

PDU 9 CHECK: in analysing the sequence in which PDU 8


and PDU 9 have been received, show that, in
general, PDU 8 overtakes PDU 9 and that the
received sequence within the one priority group is
the same as the sending sequence

a: VCb

send

In the following steps SUT and Y simulate a loop.


PDU 7 CIDIN packet with looping counter set to 31

b: VCb

wait

PDU 7 CHECK: Looping counter decremented

a: VCb

send

PDU 7 Looping counter not manipulated


CHECK: This looping sequence is terminated by a
looping counter of 1
END OF PROCEDURE

Appendix D

Sixth Edition
Page 13 of 101

14/04/2011

CIDIN Conformance Tests


Overview

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue:

Layer
Test Group

:
:

3b
3

Purpose

Test multiple dissemination and address stripping in relay centre

List of procedures

2003

Page: 1/1

:
3.1

Multiple dissemination and address stripping (normal cases) (PVC)

3.2

Multiple dissemination and address stripping (error cases)

Configuration used

3b.B

To be preceded by test groups

(PVC)

Coding:
PDU 10 to PDU18:

PDU 17(b), PDU 17(c), etc:

Installation

single CIDIN packets with various sets of different addresses


(see procedure descriptions)
packets derived from PDU 17 and modified according to stripping rules

:
The SUT is configured to initialise VCs a, b and c as PVCs.
(Initialisation by the test partner (Y) should also be demonstrated)

Special considerations:
Special attention should be directed to the coding of the address stripped packets

Appendix D

Sixth Edition
Page 14 of 101

14/04/2011

CIDIN Conformance Tests


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

3b
3
1 (PVC)

Purpose:

Step
No.

Alt.
Step
No.

Centre

Connection

Action

10

a: VCa

send

Event

Date of issue: 2003

Multiple dissemination and address


stripping (normal cases)
Page: 1/1
Parameters/Comments

Results - Additional
Comments during test
period

PDU 10 First CIDIN packet of non-AFTN message with


Axs:
Ax1 to be routed via b
Ax2 to be routed via b

a: VCa

send

PDU 11 As for PDU 10 but AFTN format


(5 Ads for Ax1 and 3 Ads for Ax2)

a: VCa

send

PDU 12 As for PDU 10 but not first packet

a: VCa

send

PDU 13 As for PDU 10 but


Ax1 to be routed via b
Ax2 to be routed via c

a: VCa

send

PDU 14 As for PDU 13 but AFTN format as PDU 11

a: VCa

send

PDU 15 First CIDIN packet in message with AFTN format


with Axs:
Ax1 to be routed via b (5 Ads)
Ax2 to be routed via c (3 Ads)
Ax3 to be routed via b (5Ads)

a: VCa

send

PDU 16 As for PDU 13 but not first packet

a: VCa

send

PDU 17 Not first packet in message with Axs:


Ax1 to Ax8 to be routed via b
Ax9 to Ax11 to be routed via a
Ax12 to be routed via c
Ax13 to Ax15 to be routed via b

a: VCa

send

PDU 18 First CIDIN packet in message with AFTN format


with Axs:
Ax1 to be routed via b (5Ads)
Ax2 is the exit address of SUT (1 Ads)
Ax3 to be routed via c (no Ads)

10

a: VCa
b :VCb
c: VCc

wait

PDU 10 Receive the packets derived from steps 1 to 9


to
PDU 18
CHECK: Coding and address stripping is correct. In
particular:
No packets received on VCa
PDU 10, PDU 11 and PDU 12 received as sent
PDU 13 to PDU 17 correctly routed and stripped
PDU 18 not routed further to Ax2
END OF PROCEDURE

Appendix D

Sixth Edition
Page 15 of 101

14/04/2011

CIDIN Conformance Tests


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

3b
3
2 (PVC)

Purpose:

Date of issue: 2003

Multiple dissemination and address


stripping (error cases)
Page: 1/1

Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

a: VCa

send

PDU 17

b: VCb

wait

PDU 17(b) Packets derived from PDU 17


(Ax1 to Ax8 and Ax13 to Ax15)

c: VCc

wait

PDU 17 (c) Packet derived from PDU 17 (Ax12)


(the packet to be routed via c could also,
depending on routing tables in SUT, be
transmitted via b and c)

Results - Additional
Comments during test period

Non-first packet in message with Axs:


Ax1-Ax8 to be routed via b
Ax9-Ax11 to be routed via a
Ax12 to be routed via c
Ax13-Ax15 to be routed via b

Cause of failure of the link carrying VCc


4

a: VCa

send

b: VCb

wait

PDU 17

Repeat step 1

PDU 17 (bb) Packet equivalent to PDU 17 (b) supplemented


by those Axs for which b is the secondary route.
Re-establish the failed link

a: VCa

send

PDU 17

b: VCb

wait

PDU 17 (b) As in step 2

c: VCc

wait

PDU 17 (c) As in step 3


Cause the failure of the link carrying VCc

a: VCb

send

10

c: VCc

wait

PDU 17

As in step 1

Repeat step 1

PDU 17 (cc) Packet equivalent to PDU 13 (b) supplemented


by those Axs for which b is the secondary route
Re-establish the failed link

11

a: VCa

send

PDU 17

As in step 1

12

b: VCb

wait

PDU 17 (b) As in step 2

13

c: VCc

wait

PDU 17 (c) As in step 3


END OF PROCEDURE

Appendix D

Sixth Edition
Page 16 of 101

14/04/2011

CIDIN Conformance Tests


Overview

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Layer
Test Group

:
:

3b
4

Purpose

Test reaction to errors and transmission failure

List of procedures

Date of issue: 2003

Page: 1/1

:
4.1

Processing of erroneous packets received

4.2

Discarding of packets when loss of communications occurs

4.3

Operator initiated resets

4.4

Network initiated resets

4.5

Switching between PVC (primary VC) and SVC (secondary VC)

Configuration used

3b. B

To be proceeded by test groups

3b.3.1

Coding :
PDU 7

INV 7 to INV 17 :

valid first CIDIN packet of message in AFTN format


invalid variations of PDU 7

Sequence of CIDIN packets contained in procedure 3b.3.1


Installation

:
The relay centre (SUT) is configured to initialise all VCs as PVCs in flow control ready state
SVCs can be used in some procedures, others are dedicated to PVCs
SVC necessary in test procedure 3b.4.5
At any moment in time only one SVC shall exist between two exit centres
No congestion

Special considerations

:
In the test equipment (Y) the rate of receiving CIDIN packets must be adjustable
Facilities are required for causing link failures

Appendix D

Sixth Edition
Page 17 of 101

14/04/2011

CIDIN Conformance Tests


Procedures
Layer
Test Group
Procedure
Step
No.

Alt.
Step
No.

:
:
:
Centre

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

3b
4
1 (PVC/SVC)
Connection

Action

Date of issue: 2003

Purpose: Processing of erroneous packets received


Page: 1/1
Event

Parameters/Comments

Results Additional
Comments during test period

At any moment in time only one SVC shall exist


between SUT and Y
1

a : VCa

send

PDU 7

b : VCb

wait

PDU 7

a: VCa

send

INV 7

As PDU 17 but invalid header item code 1011

a : VCa

send

INV 8

As PDU 17 but number of characters in an


Ax >8

a : VCa

send

INV 9

As PDU 17 but Axs are unknown in SUT

a : VCa

send

INV 10 As PDU 17 but an Ax consists of zero characters

a : VCa

send

INV 11 As PDU 17 but CP3N (transport header) non-zero

a: VCa

send

INV 12 As PDU 17 but exit and address items repeated


with the last item not completely contained in
the packet

a: VCa

send

INV 13 As PDU 17 but address item Ax2 repeated (without


Ads) an additional 15 times

10

a : VCa

send

INV 14 As PDU 17 but no message priority item present

11

a : VCa

send

INV 15 As PDU 17 but no Ax item present

12

a : VCa

send

INV 16 As PDU 17 but packet header not terminated


by MIN item (transport header)

13

a : VCa

send

INV 17 As PDU 17 but CP3N indicates second


CIDIN packet and Ads are present

14

b : VCb
c: VCc

wait

Valid first packet of message in AFTN format


with addresses:
Ax1 to be routed via b (5 Ads)
Ax2 to be routed via b (3 Ads)

CHECK: No CIDIN packet should be received


from SUT. Operator messages and error
logs can be generated in centre SUT
END OF PROCEDURE

Appendix D

Sixth Edition
Page 18 of 101

14/04/2011

CIDIN Conformance Tests


Procedures
Layer
Test Group
Procedure
Step
No.

Alt.
Step
No.

:
:
:
Centre

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

3b
4
2 (PVC/SVC)
Connection

Action

Purpose:

Date of issue: 2003

Discarding of packets when loss


of communication occurs
Page: 1/1

Event

Parameters/Comments

Results Additional
Comments during test period

At any moment in time only one SVC


shall exist between SUT and Y
Cause failure of links carrying VCs b and c
1
2
3
4
5
6
7
8
9

)
) Carry out steps 1 to 9 of procedure 3b.3.1
)
) Repeat until the congestion situation in SUT
) causes transmission to be halted by means
) of flow control in layer 3a
)
)
)
Reinitialise the links carrying VCs b and c

10
11
12
13
14
15
16
17
18
19

)
)
) Repeat the same 9 steps
)
)
)
)
)
)
-

b : VCb
c : VCc

wait

PDU 8 to Receive the routed packets from steps 10 to 18 as in


PDU 16 procedure 3b.3.1
CHECK: The failure and recovery of the links
has not affected the packets received in step 19

END OF PROCEDURE

Appendix D

Sixth Edition
Page 19 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Conformance Tests
Procedures

Single Layer Tests

Layer
Test Group
Procedure

Purpose:

:
:
:

3b
4
3 (PVC)

Date of issue: 2003

Operator initiated resets


-Reaction to resets with diagnostic code A1/A2
-Generation of resets with diagnostic code A1/A2

Page: 1/1
Step
No.

Alt.
Step
No.

Centre

Connection Action

Event

Parameters/Comments

Results Additional
Comments during test period

PDU 7: Valid first and last packet of message in


AFTN format with Ax1 to be routed via:
VCa (primary PVC) / VCb (secondary PVC)
1

SUT

a: VCa

send

PDU 7

PDU 7 via primary VC

a :VCa

wait

PDU 7

Reception of PDU 7

a :VCa

send

SUT

b: VCb

send

PDU 7

PDU 7 via secondary VC


SUT demonstrates switching to secondary VC
because the CIDIN packet layer was notified that
the primary logical channel is not usable

b :VCb

wait

PDU 7

Reception of PDU 7

a :VCa

send

SUT

a: VCa

send

PDU 7

PDU 7 via primary VC


SUT demonstrates switching back to primary VC
because the CIDIN packet layer was notified that
the logical channel is usable

a :VCa

wait

PDU 7

Reception of PDU 7

SUT

a: VCa

send

10

SUT

b: VCb

send

X.25 reset
request
00/A2
PDU 7

11

SUT

a: VCa

send

12

SUT

a: VCa

send

X.25 reset Operator (on Y) initiates X.25 reset with cause


request code 00, diagnostic code A2 (DTE not operational)
00/A2

X.25 reset Operator (on Y) initiates X.25 reset with cause


request code 00, diagnostic code A1 (DTE operational)
00/A1

PVC invalidated by operator


SUT sends X.25 reset with cause code 00,
diagnostic code A2 (DTE not operational)
PDU 7 via secondary VC
SUT demonstrates that it does not use the logical
channel which was set to not usable by the operator

X.25 reset PVC validated by operator


request SUT sends X.25 reset with cause code 00,
00/A1
diagnostic code A1 (DTE operational)
PDU 7

PDU 7 via primary VC


SUT to demonstrate that it does use the logical
channel which has was set to usable by operator

END OF PROCEDURE

Appendix D

Sixth Edition
Page 20 of 101

14/04/2011

CIDIN Conformance Tests


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

3b
4
4 (PVC)

Purpose:

Date of issue: 2003

Network initiated resets


-Cause: Out of order, network out of order
-Remote DTE operational, network operational

Page: 1/1
Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

Results Additional
Comments during test period

PDU 7: Valid first and last packet of message in


AFTN format with Ax1 to be routed via:
VCa (primary PVC) / VCb (secondary PVC)
Note: in order to execute this test Y has to be
configured as DCE (logical level)
1

SUT

a: VCa

send

PDU 7

PDU 7 via primary VC

a: VCa

wait

PDU 7

Reception of PDU 7

a :VCa

send

SUT

b: VCb

send

PDU 7

PDU 7 via secondary VC


SUT demonstrates switching to secondary VC
because the CIDIN packet layer was notified that
the primary logical channel is not usable

b :VCb

wait

PDU 7

Reception of PDU 7

a :VCa

send

SUT

a: VCa

send

PDU 7

PDU 7 via primary VC


SUT demonstrates switching back to primary VC
because the CIDIN packet layer was notified that
the logical channel is usable

10

a :VCa

wait

PDU 7

Reception of PDU 7

11

a :VCa

send

10

13

SUT

b: VCb

send

11

b :VCb

wait

12

14

a :VCa

send

13

SUT

a: VCa

send

PDU 7

PDU 7 via primary VC


SUT demonstrates switching back to primary VC
because the CIDIN packet layer was notified that
the logical channel is usable

14

a :VCa

wait

PDU 7

Reception of PDU 7

X.25 reset Operator (on Y) initiates an X.25 reset with cause


request code 01 (out of order), diagnostic code nn (any
01/nn diagnostic code can be selected)

X.25 reset Operator (on Y) initiates an X.25 reset with cause


request 09 (remote DTE operational)
09/nn

X.25 reset Operator (on Y) initiates an X.25 reset with cause


request 1D (network out of order)
1D/nn
PDU 7 PDU 7 via secondary VC
SUT demonstrates switching to secondary VC
because the CIDIN packet layer was notified that
the primary logical channel is not usable
PDU 7

Reception of PDU 7

X.25 reset Operator (on Y) initiates an X.25 reset with cause


request 0F (network operational)
0F/nn

END OF PROCEDURE

Appendix D

Sixth Edition
Page 21 of 101

14/04/2011

CIDIN Conformance Tests


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

3b
4
5 (PVC/SVC)

Purpose:

Date of issue: 2003

Check switchover between PVC and SVC

Page: 1/1
Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

Results Additional
Comments during test period

PDU 7: Valid first and last packet of message in


AFTN format with Ax1 to be routed via:
VCa (primary VC, type PVC) / VCb (secondary
VC, type SVC)
1

SUT

a: VCa

send

PDU 7 PDU 7 via primary VC (PVC)

a: VCa

wait

PDU 7 Reception of PDU 7 (PVC)

a:

disconnect
link a

Disconnect link a

SUT

b: VCb

send

a:

reconnect
link a

SUT

a: VCa

send

PDU 7 PDU 7 via secondary VC


SUT demonstrates:
1
issue of an X.25 call request to establish
an SVC
-switch to secondary VC because the CIDIN packet
layer was notified that the primary logical channel
is not usable
Re-connect link a

PDU 7 PDU 7 via primary VC (PVC)


SUT demonstrates:
-switch back to primary VC because the CIDIN
packet layer was notified that the primary logical
channel is usable
Note: The goal of the test is to switch back whilst
the SVC still exists (not cleared due to expiration of
the idle timer). This can be achieved by:
-performing this step quickly after steps 4 and 5, or
-sending CIDIN packets from Y to SUT via VCb to
prevent expiration of the idle timer.

END OF PROCEDURE

Appendix D

Sixth Edition
Page 22 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES

CIDIN Conformance Testing

D.1.5

Appendix D

Date of issue:

2003

CONFORMANCE TESTS (SINGLE LAYER) Layer 4

Sixth Edition
Page 23 of 101

14/04/2011

CIDIN Conformance Testing


Configurations

Layer :
Configuration :

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue: 2003

4
A
Page: 1/1

System Under Test (SUT)

CIDIN Centre, entry centre, layer 4

Timers:
TNMA = 35 sec, TMR = 40 sec, TEM = 40 sec
MIN range:
1 to 100
Max message length: 64.000 octets

layer 3b

Installation state

operational state

Parameter settings

routing tables set up for the individual procedures

Parameter settings

Underlying layer

Number of test connections involved :

N.A.

Test Parameters :
SUT

System Under Test

CIDIN Testing Equipment or another CIDIN Centre

Number of connections in underlying layer :


Connections
a: VCa
b: VCb

(SUT) (Y), route to EXIT 1


(SUT) (Y), route to EXIT 2

Additional conditions :
The test partner Y simulates two separate exit centres
The VC type used is PVC

SUT

Application
Layer 4

Test Sequences
EXIT1 EXIT2

Layer 3b

Layer 3b

Layer 3a

Layer 3a

Layer 2

a: VCa

Layer 2

b: VCb

Appendix D

Sixth Edition
Page 24 of 101

14/04/2011

CIDIN Conformance Testing


Configurations

Layer :
Configuration :

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue:

2003

4
B
Page: 1/1

System Under Test (SUT)

CIDIN Centre, exit centre, layer 4

Timers
:
Min range
:
Max message length:

layer 3b

Installation state

operational state

Parameter settings

exit address of SUT is EXIT 1

Parameter settings

Underlying layer

Number of test connections involved

TNMA = 35 sec, TMR = 40 sec, TEM = 40 sec.


1 to 100
64.000 octets

N.A.

Test Parameters

SUT

System Under Test

CIDIN Testing Equipment or anther CIDIN Centre

Number of connections in underlying layer :


Connections
a: VCa

(SUT) - (Y), route to EXIT 1

The VC type used is either PVC or SVC


Link a may carry more than one VCs
Additional conditions

It should also be demonstrated that the events on route a are independent from those (e.g. route failures) on
other routes

SUT

Application
(EXIT 1)
Layer 4

Test
Sequences

Layer 3b

Layer 3b

Layer 3a

Layer 3a

Layer 2

Appendix D

a: VCa

Sixth Edition
Page 25 of 101

Layer 2

14/04/2011

CIDIN Conformance Testing


Configurations

Layer :
Configuration :

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue:

2003

4
C
Page: 1/1

System Under Test (SUT)

CIDIN Centre, entry/exit centre, layer 4

Purpose

Verification of centre behaviour upon reception of messages with errors


and in exceptional cases

Timers :

layer 3b

Parameter settings
Underlying layer

Installation state :
Parameter settings

PVCs in flow control ready state. In case SVCs are used they are
established dynamically.

Number of test connections involved


Test Parameters

TNMA = 35 sec, TMR = 40 sec, TEM = 40 sec.

N.A.

:
SUT

System Under Test

Test CIDIN Centre or Testing Equipment

Number of connections in underlying layer :


Connections
b: VCb

Additional conditions

(SUT) - (Y), only one VC is defined (either PVC or SVC)

The configuration should be varied with connections a and b on the same and or different circuits

SUT

AFTN/CIDIN
Application
Layer 4

Test
Sequences

Layer 3b

Layer 3b

Layer 3a

Layer 3a

Layer 2

Layer 2
b: VCb

Appendix D

Sixth Edition
Page 26 of 101

14/04/2011

CIDIN Conformance Testing


Overview

Layer :
Configuration :

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue: 2003

4
1
Page: 1/1

Purpose

List of procedures

Test entry centre functions for normal cases


:
1.1

Acknowledgement of single address messages, check the processing of


ACKs received

1.2

Acknowledgement of multiple address messages, check the processing of


ACKs received

Configuration used

4.A

To be preceded by test groups

Coding:
MACK1 to MACK2:

messages consist of 3 CIDIN packets and requiring acknowledgement

MACK3 to MACK4:

messages consist of 3 CIDIN packets with multiple Axs requiring


acknowledgement

ACK, ENQ, ENQr :

network management messages

TMR

Timeout

Initialisation:
Normal operation state
Initialisation of entry centre started by application software and operator should be demonstrated

Special considerations:
Operators access for resetting the MIN generator is necessary.
For reasons of efficiency in the testing, facilities for repetition of messages are desirable.

Appendix D

Sixth Edition
Page 27 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

4
1
1 (PVC)

Purpose:

Date of issue: 2003

Acknowledgement of single address messages,


check the processing of ACKs received
Page: 1/1

Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

SUT

a: VCa

send

MACK1 Message requiring acknowledgement

a : VCa

wait

MACK1

12

a: VCa

send

ACK

SUT

a: VCa

wait

ACK

SUT

a: VCa

send

SUT

a: VCa

wait

SUT

a: VCa

send

SUT

a: VCa

wait

TMR

SUT

a: VCa

send

ENQ

Results Additional
Comments during test
period

Acknowledgement

MACK2 Message requiring acknowledgement


TMR

Timeout

MACK2 Repetition of step 5


Second timeout

CHECK : SUT refuses the transmission of


further messages to Y
10

SUT

a: VCa

wait

TEM

ENQ timeout

11

17

SUT

a: VCa

send

ENQ

12

a : VCa

wait

MACK2 Receive but do not acknowledge

13

a : VCa

wait

MACK2 Receive but do not acknowledge

14

a : VCa

wait

ENQ

15

a : VCa

wait

ENQ

16

a: VCa

send

ENQr

Enquiry response

17

SUT

a: VCa

wait

ENQr

CHECK: SUT now accepts messages for


transmission to Y

Receive but do not acknowledge

END OF PROCEDURE

Appendix D

Sixth Edition
Page 28 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

4
1
2 (PVC)

Purpose:

Date of issue:

2003

Acknowledgement of multiple address messages


check the processing of ACKs received
Page: 1/1

Step
No.

Centre

Connection

Action

Alt.
Step
No.
2

Event

Parameters/Comments

SUT

a: VCa

send

MACK 3 Message requiring acknowledgement sent to two Axs

MACK3 Receive at both Axs

Results Additional
Comments during test
period

b : VCb
2

a: VCa
b : VCb

wait

a: VCa
b: VCb

send

ACK

Acknowledgement

SUT

a: VCa
b: VCb

wait

ACK

Acknowledgement

SUT

a: VCa
b : VCb

send

MACK4 Message requiring acknowledgement sent to two Axs

a: VCa
b : VCb

wait

MACK4 Receive at both Axs

15

a: VCa

send

ACK

SUT

a: VCa

wait

ACK

SUT

wait

TMR

10

SUT

11

SUT

12

SUT

13

SUT

14

19

SUT

15

16

b: VCb

send

Only one exit centre acknowledges

Timeout on acknowledgement expected on b

MACK4 Retransmit on b

wait

TMR

Second timeout

send

ENQ

CHECK: SUT refuses the transmission of


further messages to Ax(b) in Y

wait

TEM

ENQ timeout

b: VCb

send

ENQ

b: VCb

wait

b : VCb

wait

ENQ

17

b : VCb

wait

ENQ

18

b: VCb

send

ENQr

Enquire response

19

SUT

b: VCb

wait

ENQr

CHECK: SUT now accepts messages for


transmission Ax(b) in Y

b: VCb

MACK4 Receive but do not acknowledge


Receive but do not acknowledge

END OF PROCEDURE

Appendix D

Sixth Edition
Page 29 of 101

14/04/2011

CIDIN Conformance Testing


Overview
Layer
Test Group

:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue:

2003

4
2
Page: 1/1

Purpose: Test entry centre functions for error cases

List of procedures:
2.1

Reaction of transport layer in case of link failures (show route independence of ACK,
handling of temporary and permanent link errors)

2.2

Check the centre reaction on reception of MCF error messages

Configuration used

4.B

To be preceded by test groups

4.1

Coding:
MACK1 to MACK2:

as for procedure 4.1.1

ACK, ENQ, ENQr:

as for procedure 4.1.1

MCF:

MCF error message

Initialisation:
Normal operation state
Initialisation of entry started by application software and operator should be demonstrated

Special considerations:
Procedures are based upon disturbances of procedure 4.1.1
Means for simulation of link failures are required

Appendix D

Sixth Edition
Page 30 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

4
2
1 (PVC/SVC)

Purpose:

Date of issue: 2003

Reaction of transport layer in


transmission failures
Page: 1/1

Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

SUT

a: VCa

send

MACK1

Message requiring acknowledgement

a : VCa

wait

MACK1

Message is acknowledged

Results Additional
Comments during test
period

3
4

Cut the connection


SUT

SUT

a: VCa

SUT

SUT

SUT

SUT

send

MACK1

wait
a: VCa

send

TNMA expires
MACK 1

wait
a: VCa

Message requiring acknowledgement

Message is repeated
TNMA expires

send

ENQ

Enquiry message is sent

wait

ENQ

ENQ timeout
CHECK: operator/application/error log is informed

END OF PROCEDURE

Appendix D

Sixth Edition
Page 31 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

4
2
2 (PVC/SVC)

Purpose:

Date of issue: 2003

Check the centre reaction on reception of MCF


error Messages
Page: 1/1

Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

SUT

a: VCa

send

MACK1

a : VCa

wait

MACK1

a: VCa

send

MCFe

SUT

a: VCa

wait

MCFe

Parameters/Comments

Results Additional
Comments during test
period

0
Message requiring acknowledgement

MCF error message indicating an error in the


CIDIN packet of MACK1

CHECK: operator/application/error log is informed


5

SUT

a: VCa

send

M1

a : VCa

wait

M1

a: VCa

send

MCFe

Message not requiring acknowledgement

MCF error message indicating an error in a CIDIN


packet of M1
CHECK: operator/application/error log is informed

END OF PROCEDURE

Appendix D

Sixth Edition
Page 32 of 101

14/04/2011

CIDIN Conformance Testing


Overview
Layer
Test Group

:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue: 2003

4
3
Page: 1/1

Purpose:

Test exit centre functions for normal cases

List of procedures:
3.1

Reassembling of CIDIN packets in exit centre (show that packets are correctly assembled
into messages in spite of irregularities in sending)

Configuration used

4.B

To be preceded by test groups

Coding:
CID 9

CID 10 :

Layer 4 message with 20 CIDIN packets not requiring ACK


Layer 4 message with 20 CIDIN packets requiring ACK
(sub-messages CID 10+CID 10)

Initialisation:
Normal operation state
Initialisation of exit centre started by application software and operator should be demonstrated.

Special considerations:
This test group requires extensive manipulation of the sequence of CIDIN packets sent by the
simulated entry centre.

Appendix D

Sixth Edition
Page 33 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

4
3
1 (VC)

Purpose:

Date of issue: 2003

Reassembling of CIDIN packets in exit centre


(show that packets are correctly assembled into
messages in spite of irregularities in sending)
Page: 1/1

Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

a : VCa

send

CID 9

Message not requiring acknowledgement and


consisting of 20 CIDIN packets

SUT

a: VCa

wait

CID 9

CHECK: message correctly assembled

a : VCa

send

CID 9

Last 10 packets sent before the first 10 packets

SUT

a: VCa

wait

CID 9

CHECK: message correctly assembled

a : VCa

send

CID 9

CIDIN packet number 10 not sent

SUT

a: VCa

wait

CID 9

Receive first CIDIN packets

SUT

a: VCa

wait

TNMA

Timeout on packet number 10


CHECK: message is discarded in SUT

10

a : VCa

send

CID 9

CIDIN packet number 10 is sent twice before


last packet is sent

11

SUT

a: VCa

wait

CID 9

CHECK: message correctly assembled

10

12

a : VCa

send

CID 9

Message is sent except for packet number 10


Packet number 10 is then sent with FCP=1

11

13

SUT

a: VCa

wait

CID 9

CHECK: 10 packets correctly assembled

12

14

a : VCa

send

CID 9

Message is sent in packets of random length


<=256 octets

13

15

SUT

a: VCa

wait

CID 9

CHECK: message correctly assembled

14

a : VCa

send

CID 10

As for CID 1 but requiring acknowledgement.


All packets are sent except CIDIN packet number
10

15

SUT

wait

TNMA

CHECK: incomplete message retained only until


timeout TMNA

Results Additional
Comments during test period

END OF PROCEDURE

Appendix D

Sixth Edition
Page 34 of 101

14/04/2011

CIDIN Conformance Testing


Overview
Layer
Test Group

:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue: 2003

4
4
Page: 1/1

Purpose

List of procedures

Test exit centre functions for error cases

4.1

Reaction of transport layer in transmission failures (temporary link failure, discarding of incomplete
messages)

4.2

Reaction of exit centre to invalid messages (show that the MCF error messages are sent under the
correct condition)

Configuration used

4.B

To be preceded by test groups

4.3

Coding :
CID 10

as in test group 3 (sub-messages CID 10+CID10)

ACK

as for procedure 4.1.1

INV 18 to INV 24
MCF

Initialisation

:
:

messages whose CIDIN packets contain invalid coding


(see procedure descriptions)
MCF error messages

Normal operation state


Initialisation of exit centre started by application software and operator should be demonstrated
Special considerations

Means for simulation of link and centre failures are required

Appendix D

Sixth Edition
Page 35 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

4
4
1 (VC)

Purpose:

Date of issue: 2003

Reaction of transport layer to transmission


failures (temporary link failure, discarding of
incomplete messages)
Page: 1/1

Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

a : VCa

send

CID 10

a: VCa

wait

CID 10

a: VCa

send

ACK

a: VCa

wait

ACK

Parameters/Comments

Results Additional
Comments during test
period

Message requiring acknowledgement

Acknowledgement

Cause temporary failure on link a


Remove failure and re-initialise/re-establish link a
5

a : VCa

send

CID 10

CID 2 without first CIDIN packet

a : VCa

wait

TMR

11

a : VCa

send

CID 10

a: VCa

wait

CID 10

a: VCa

wait

CID 10

10

13

a: VCa

send

ACK

Acknowledgement

11

a : VCa

wait

ACK

CHECK: Operation is not affected by above failure


of link a

12

a : VCa

send

CD 10

Simulate waiting for ACK


Complete message

Cause permanent failure on the link a


13

wait

TMNA

Timeout on arrival of missing packet


CHECK: CID 10 is discarded in SUT

END OF PROCEDURE

Appendix D

Sixth Edition
Page 36 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Conformance Testing
Procedures

Single Layer Tests

Layer
Test Group
Procedure

Purpose:

:
:
:

4
4
2 (VC)

Date of issue: 2003

Reaction of exit centre to invalid messages


(show that the MCF error messages are sent
under the correct conditions)
Page: 1/1

Step
No.

Alt.
Step
No.

7
-

Centre Connection Action

a : VCa

send

Event

INV 18

Parameters/Comments

Results Additional
Comments during test
period

Network management message

1
which requires response (ENQ) without ECH
2

a : VCa

send

INV 19

ENQ with non-zero CP3N

a : VCa

send

INV 20

ENQ with FCP=0

a : VCa

send

INV 21

ENQ response

a: VCa

send

INV 22

Message with MT=1 and invalid NMF

a : VCa

send

INV 23

Message consisting of valid first CIDIN packet


(CP3N) followed by CIDIN packet with
CP3N2=CP3N-1

SUT

a: VCa

wait

INV 18 to
INV 23

Receive invalid messages


CHECK: SUT does not send responses to invalid
messages

11

a : VCa

send

INV 24

Information message with invalid MCF (MT=0)

SUT

a: VCa

wait

INV 24

10

SUT

a: VCa

send

MCFe

11

a : VCa

wait

MCFe

Send appropriate MCF error message

END OF PROCEDURE

Appendix D

Sixth Edition
Page 37 of 101

14/04/2011

CIDIN Conformance Testing


Overview
Layer
Test Group

:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue: 2003

4
5
Page: 1/1

Purpose

List of procedures

Verification of centre behaviour upon reception of packets containing errors

:
5.1

Reaction on reception of enquiry response messages without an enquiry message


having been previously sent

5.2

Reception of acknowledgement and MCF error for messages not sent by the centre

5.3

Centre reaction upon reception of packets of one message with different Axs in their
headers

5.4

Reaction upon reception of packets of one message, several of which contain the
final CIDIN packet indicator

5.5

Verification of centre behaviour upon reception of a message with Ax whose


location code is correct although the application does not exist at the centre

5.6

Loop prevention mechanism: no retransmission of packets via the receiving VC

Configuration used

4.C

To be preceded by the groups

Coding :
PDU 19 to PDU 22

(see procedure description)

ENQ and ACK

As for procedure 4.1.1

MCF

MCF error message

Initialisation

Special considerations

Appendix D

Sixth Edition
Page 38 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

4
5
1 (VC)

Purpose:

Date of issue: 2003

Reaction to reception of enquiry response


messages without an enquiry message having
previously been sent
Page: 1/1

Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

b : VCb

wait

INIT

Upgrading of link b. [VC initialisation]

SUT

b: VCb

send

ENQr

ENQr message correct


Ax: CBAFTN, Ae: CAAFTN
Text field empty

b : VCb

receive

ENQ r

Reception of ENQr

Results Additional
Comments during test period

Verify if Y discards the received packet without


additional action

END OF PROCEDURE

Appendix D

Sixth Edition
Page 39 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

4
5
2 (VC)

Purpose:

Date of issue: 2003

Reception of ACK and MCF error for messages


not sent by the centre
Page: 1/1

Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

b : VCb

wait

INIT

Upgrading of link b, [VC initialisation]

SUT

b: VCb

sent

ACK

ACK message correct


Ax: CBAFTN, Ae: CAAFTN
text field: MIN=25/CP3N=7/Ax=CAAFTN

b : VCb

receive

ACK

Reception of ACK of message not sent by Y

SUT

b: VCb

send

MCF e

MCFe message correct


Ax: CBAFTN, Ae: CAAFTN
Text field: MIN=27/CP3N=3/Ax=CAAFTN

b : VCb

receive

MCF e

Reception of MCFe for a message not sent by Y


Verify if Y discards the packets received in steps 2
and 4 without additional action

Results Additional
Comments during test period

END OF PROCEDURE

Appendix D

Sixth Edition
Page 40 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

4
5
3 (VC)

Purpose:

Date of issue: 2003

Centre reaction upon reception of packets


of one message with different Axs in their
headers
Page: 1/1

Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

b : VCb

wait

INIT

Upgrading of link c, [VC initialisation]


PDU 8 and PDU 9 are packets with identical
Aes and MINs

SUT

b: VCb

send

PDU 19

Correct packet with:


Ax: CBOPCID, Ae: CAOPCID
CP3N=0/FCP=0/NA=1/MT=0/MCF=00001

SUT

b: VCb

send

PDU 20

Correct packet with:


Ax: CBOPCID, Ae: CAOPCID
CP3N=0/FCP=0/NA=1/MT=0/MCF=00001

b : VCb

receive

Results Additional
Comments during test
period

PDU 19 & Reception of message


PDU 20 CHECK: Reaction of Y to reception of the message

END OF PROCEDURE

Appendix D

Sixth Edition
Page 41 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

4
5
4 (VC)

Purpose:

Date of issue: 2003

Reaction upon reception of packets of one


message, several of which contain the Final
CIDIN Packet Indicator
Page: 1/1

Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

b : VCb

wait

INIT

Upgrading of link b, [VC initialisation]


P1, P2 and P3 are packets of one message with
Ax: CBOPCID, Ae: CAOPCID
NA=1/MT=0/MCF=0001
1 packet CP3N=1-1

SUT

b: VCb

send

P19

FCP=0

SUT

b: VCb

send

P20

FCP=1

SUT

b: VCb

send

P21

FCP=0

b: VCb

receive

P19

Y completes message PDU 19

b : VCb

receive

P20

Y completes messages PDU 20

b: VCb

receive

P21

Y discards PDU 21 upon expiry of TNMA

b : VCb

send

ACK

ACK (CPSN=1)

SUT

b: VCb

receive

ACK

Reception of ACK

10

SUT

b: VCb

send

P19

FCP=0

10

11

SUT

b: VCb

send

P21

FCP=1

11

SUT

b: VCb

send

P20

FCP=1
CHECK: reaction of Y
possible reception of ACK at SUT

Results Additional
Comments during test
period

END OF PROCEDURE

Appendix D

Sixth Edition
Page 42 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

4
5
5 (VC)

Purpose:

Date of issue: 2003

Verification of centre behaviour upon


reception of a message with Ax whose location
code is correct although the application
does not exist at the centre
Page: 1/1

Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

b : VCb

wait

INIT

Upgrading of link b, [VC initialisation]

SUT

b: VCb

send

PDU 22

Message PDU 22 packets sent


(Ax without application at Y)

b: VCb

receive

PDU 22

Reception of PDU 22

Results Additional
Comments during test
period

CHECK: reaction of Y upon reception of the


message

END OF PROCEDURE

Appendix D

Sixth Edition
Page 43 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

4
5
6 (VC)

Purpose:

Date of issue: 2003

Loop prevention mechanisms


(no retransmission of packets via the receiving
VC)
Page: 1/1

Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

b : VCb

wait

INIT

Upgrading of link b, [VC initialisation]

SUT

b: VCb

send

PDU 19

CIDIN packet correct:


Ax : CAAFTN

b: VCb

receive

PDU 19

Reception of PDU 19
CHECK: Y does not retransmit PDU 19

Results Additional
Comments during test
period

END OF PROCEDURE

Appendix D

Sixth Edition
Page 44 of 101

14/04/2011

CIDIN Conformance Testing


Overview

Layer :
Test Group :

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue: 2003

4
6
Page: 1/1

Purpose

List of procedures

Test functionalities exclusive to SVCs


:

6.1

Verification of the calling DTE address against a list of configured DTEs,


check rejection of call in case the DTE address is not recognised.

6.2

Repetition of a call request after expiration of the call retry timer. Check
that no ENQ is sent during the retry phase.

6.3

Crossing call avoidance.

Configuration used

4.B

To be preceded by test groups

Coding :
MACK1 to MACK2:

messages consist of 3 CIDIN packets and requiring acknowledgement

ACK, ENQ, ENQr:

network management messages

Initialisation

Y is initially configured with DTE Address DTE-Y1


SUT is configured with DTE Address DTE-SUT
SUT has a DTE-Y1, DTE-Y2, DTE-Y3 and DTE-Y4 configured as DTE addresses for Y
SUT and Y are initialised, no SVCs are established.

Special considerations:
Y must be able to change its own X.25 DTE address.

Appendix D

Sixth Edition
Page 45 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

4
6
1 (SVC)

Purpose:

Date of issue: 2003

Verification of the calling DTE address against


a list of configured DTEs by the NSU

Page: 1/1
Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

Results - Additional
Comments during test
period

Prepare configuration of Y and SUT


1

a: VCa

send

SUT

a: VCa

wait

SUT

a: VCa

send

X.25 call
accepted

Call accepted

a: VCa

wait

X.25 call
connected

Call connected

a: VCa

send

MACK1

Message requiring acknowledgement

SUT

a: VCa

wait

MACK1

Receive MACK1

SUT

a: VCa

Send

ACK

SUT

a: VCa

Send

X.25 clear
request

SUT/Y

a: VCa

repeat 1-8

X.25 call
request

Trigger X.25 call request with calling address


DTE-Y1 and called address DTE-SUT

X.25
Incoming call with calling address DTE-Y1 and
incoming call called address DTE-SUT, checking of the calling
address

Acknowledgement for MACK1


SVC is cleared by Y after expiration of the idle timer

Repeat steps 1-7 with Y configured with DTE-Y2,


DTE-Y3 and DTE-Y4.

10

12

SUT

11

14

a: VCa

Send

SUT

a: VCa

Wait

SUT

a: VCa

Send

X.25 clear
request

Clear Request

14

a: VCa

Wait

X.25 clear
indication

Clear Indication, clearing cause/diagnostic 00/F2

15

a: VCa

send

X.25 clear Clear confirmation


confirmation

16

SUT

a: VCa

Wait

X.25 clear Clear confirmation


confirmation

12

13

16

Remove DTE-Y4 from the SUT configuration


X.25 call
request

Trigger X.25 call request with calling address DTEY4 and called address DTE-SUT

X.25
Incoming call with calling address DTE-Y4 and
incoming call called address DTE-SUT, checking of the calling
address

END OF PROCEDURE

Appendix D

Sixth Edition
Page 46 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

4
6
2 (SVC)

Purpose:

Date of issue: 2003

To verify call retry timer operation

Page: 1/1
Step
No.

Alt.
Step
No.

Centre Connection

Action

Event

Parameters/Comments

SUT

SUT

a: VCa

send

MACK1

SUT

a: VCa

send

X.25 call
request

a: VCa

wait

a: VCa

send

X.25 clear
request

Clear Request, clearing cause/diagnostic 00/F2

SUT

a: VCa

wait

X.25 clear
indication

Clear Indication, clearing cause/diagnostic 00/F2

Remove DTE-SUT from the Y configuration.


Y shall be configured with address DTE-Y1
Attempt to send MACK1

Send of a X.25 call request with calling address DTESUT and called address DTE-Y1 (initially triggered by
step 2)
X.25 incoming Incoming call with calling address DTE-SUT (unknown)
call
and called address DTE-Y1

SUT

a: VCa

send

X.25 clear Clear confirmation


confirmation

11

a: VCa

wait

X.25 clear Clear confirmation


confirmation

SUT

a: VCa

wait

repeat 3-8

call retry timer Expiration of the call retry timer shall trigger the sending
expiration of the call request again (step 3)

10

12

SUT

a: VCa

11

15

a: VCa

12

SUT

a: VCa

send

X.25 call
request

X.25 call request with calling address DTE-SUT and


called address DTE-Y1

13

SUT

a: VCa

wait

X.25 call
connected

Call connected (Y receives incoming call, sends call


accept)

SUT

a: VCa

send

ENQ

Enquiry

a: VCa

wait

ENQ

Enquiry. Check that the SUT does not send multiple


enquiries.

a: VCa

send

ENQr

Enquiry response

SUT

a: VCa

wait

ENQr

Enquiry response

SUT

a: VCa

send

MACK1

MACK1

19

a: VCa

wait

MACK1

MACK1

20

a: VCa

send

ACK

Acknowledgement for MACK1

21

SUT

a: VCa

wait

ACK

Acknowledgement for MACK1

22

SUT

a: VCa

send

X.25 clear
request

14

17

15

16

19

17
18

21

Results - Additional
Comments during test
period

Observe the repetition of step 3-8 for 5 minutes (at least


> 2 x TMR + 2 x TEM to check queuing of ENQs)
Add DTE-SUT as remote DTE in the configuration of Y

SVC is cleared by SUT after expiration of the idle timer

END OF PROCEDURE

Appendix D

Sixth Edition
Page 47 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

4
6
3 (SVC)

Purpose:

Date of issue: 2003

Crossing call avoidance

Page: 1/1
Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

SUT

a: VCa

send

MACK1

Attempt to send MACK1

SUT

a: VCa

send

X.25 call
request

Send of a X.25 call request with calling address


DTE-SUT and called address DTE-Y1 (initially
triggered by step 1)

a: VCa

wait

a: VCa

send

SUT

a: VCa

wait

SUT

a: VCa

send

X.25 clear
indication

SUT detects the crossing call and shall send a Clear


Indication, clearing cause/diagnostic 00/F5

a: VCa

wait

X.25 clear
indication

Clear Indication, clearing cause/diagnostic 00/F5

a: VCa

send

X.25 clear Clear confirmation


confirmation

SUT

a: VCa

wait

X.25 clear Clear confirmation


confirmation

1
2

Parameters/Comments

Results - Additional
Comments during test
period

X.25
Incoming call with calling address DTE-SUT and
incoming call called address DTE-Y1. Y shall ignore this call.
X.25 call
request

Trigger a X.25 call request with calling address DTEY1 and called address DTE-SUT

X.25
Incoming call with calling address DTE-Y1 and
incoming call called address DTE-SUT, checking of the calling
address

Note: After expiration on the X.25 timer T21, the


SUT shall also send a clear request for its original
call (step 2). Then the next call (retry) shall be
accepted and data can be exchanged

Appendix D

Sixth Edition
Page 48 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES

CIDIN Conformance Testing

D.1.6

Appendix D

Date of issue:

2003

CONFORMANCE TESTS (SINGLE LAYER) AFTN interface

Sixth Edition
Page 49 of 101

14/04/2011

CIDIN Conformance Testing


Configurations

Layer :
Configuration :

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue:

2003

AFTN
A
Page: 1/1

System Under Test (SUT)

AFTN interface software in a CIDIN entry centre

Purpose

Verification of AFTN interface behaviour in normal and exceptional cases

Address of AFTN origin station EAFTNTST

layer 4

Installation state

operational state

Parameter settings

Ae of centre ENTRY

Parameter settings
Underlying layer

Number of test connections involved


Test Parameters

N.A.

:
SUT

CIDIN entry centre

Test CIDIN Centre or Testing Equipment simulating 2 exit centres

Number of connections in underlying layer :


Connections
a: VCa
b: VCb
Additional conditions

(SUT) - (Y) (EXIT1)


(SUT) (Y) (EXIT2)

The protocol analyser requires complete X.25 software with test software superimposed

SUT

AFTN station
EAFTNTST

AFTN
centre

Protocol analyzer/
Test equipment

AFTN
interface
Layer 4

Test Sequences

Layer 3b

EXIT1 EXIT2

Layer 3a

Layer 3a

Layer 2

a: VCa

Layer 2

b: VCb

Appendix D

Sixth Edition
Page 50 of 101

14/04/2011

CIDIN Conformance Testing


Configurations

Layer :
Configuration :

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue:

2003

AFTN
B
Page: 1/1

System Under Test (SUT)

AFTN interface software in a CIDIN exit centre

Purpose

Verification of AFTN interface behaviour in normal and exceptional cases

Address of AFTN destination stations EAFTNTS1, EAFTNTS2

layer 4

Installation state

operational state

Parameter settings

Ax of centre EXITA

Parameter settings
Underlying layer

Number of test connections involved


Test Parameters

N.A.

:
SUT

CIDIN exit centre

Test CIDIN Centre or Testing Equipment simulating an entry centre

Number of connections in underlying layer :


Connections
a: VCa
Additional conditions

(SUT) - (Y), route between ENTRY and EXITA

The protocol analyser requires complete X.25 software with test software superimposed

SUT

Y
AFTN stations
EAFTNTS1, EAFTNTS2

AFTN
centre

AFTN
interface
Test Sequences

EXTIA
Layer 3b

ENTRY

Layer 3a

Layer 3a

Layer 2

Appendix D

Protocol analyzer/
Test equipment

a: VCa

Sixth Edition
Page 51 of 101

Layer 2

14/04/2011

CIDIN Conformance Testing


Overview

Layer :
Test Group :

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue: 2003

AFTN
1
Page: 1/1

Purpose

List of procedures

Test entry centre functions (normal cases)


:
1.1
1.2

Messages with addresses mapped onto one Ax


Messages with addresses mapped onto more than one Ax

Configuration used

A.A

To be preceded by test groups

Coding :
Text
repetitions*

Priority

Addresses (DESTINxx, xx=)

MES1

FF

AA

MES2

FF

BB

MES3

SS

AA to CC

MES4

GG

AA to PP

MES5

10

FF

AA to BB

MES6

10

DD

AA to DD

MES7

10

FF

AA to QQ

Text*

CIDIN/AFTN tests The quick brown fox jumped over the lazy dog 123456789

NA: 1

MT:0

CP:0

MCF:2

P: 2 for SS 3 for DD, FF 3 for GG, KK

Initialisation

Normal operational state; in routing tables: all messages sent via EXIT1 or EXIT2.
Initialisation of entry centre started by application software and operator should be demonstrated.

Special considerations:
Test procedure should be repeated using input messages in ITA-2 or IA-5 characters.
The internal link between the AFTN interface software and the AFTN centre is implicitly tested.

Appendix D

Sixth Edition
Page 52 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

AFTN
1
1

Purpose:

Date of issue: 2003

Messages with addresses mapped onto one Ax:


demonstrate correct mapping of AFTN message
onto CIDIN packets.
Page: 1/1

Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

SUT

VCa

send

MES1

AFTN message with one Ad (Ax = EXIT1)

VCa

wait

MES1

CHECK: correct coding of CIDIN packet

SUT

VCb

send

MES2

As MES1 but with different Ad (Ax = EXIT2)

VCb

wait

MES2

CHECK: correct coding of CIDIN packet

SUT

VCa

send

MES3

AFTN message with several Ads (Ax = EXIT1)

VCa

wait

MES3

CHECK: correct coding of CIDIN packet

VCa

send

MES4

AFTN message with 16 Ads (Ax = EXIT1)

VCa

wait

MES4

CHECK: correct coding of two CIDIN packets


(two CIDIN messages)

Results - Additional
comments during test
period

END OF PROCEDURE

Appendix D

Sixth Edition
Page 53 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

Step
No.

:
:
:

AFTN
1
2

Centre Connection

Purpose:

Date of issue: 2003

Messages with addresses mapped onto more than one


Ax: demonstrate correct mapping of AFTN messages
onto CIDIN packets.
Page: 1/1

Alt.
Step
No.
2

Action

Event

Parameters/Comments

SUT

Vca, VCb

send

MES5

AFTN message with 2 Ads, mapped to EXIT1 and


EXIT2 respectively

Vca, VCb

wait

MES5

CHECK: correct coding of CIDIN packets

SUT

Vca, VCb

send

MES6

AFTN message with 4 Ads, one mapped onto EXIT1


and three onto EXIT2

Vca, VCb

wait

MES6

CHECK: correct coding of CIDIN packets

SUT

VCa

send

MES7

AFTN message with 17 Ads, each mapped onto a


different Ax. (The 17 Axs are logically distinct but are
routed via EXIT1.)

VCa

wait

MES7

CHECK: correct coding of CIDIN packets

Results - Additional
comments during test
period

END OF PROCEDURE

Appendix D

Sixth Edition
Page 54 of 101

14/04/2011

CIDIN Conformance Testing


Overview

Layer :
Test Group :

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue: 2003

AFTN
2
Page: 1/1

Purpose

List of procedures

Test entry centre functions (exceptional cases)


:
2.1
2.2

Reaction to AFTN messages with format errors


Reaction to transmission errors

Configuration used

A.A

To be preceded by test groups

A.1

Coding :

INV1 to INV5: variations of MES6 (see test group A.1)


MES1:

(see test group A.1)

ACK, ENQ, ENQr: level 4 management messages

Initialisation

:
As for test group A.1

Special considerations:

Appendix D

Sixth Edition
Page 55 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

AFTN
2
1

Purpose:

Date of issue: 2003

Reaction to AFTN messages with format errors: show


that incorrect messages input at an AFTN station lead
to no incorrect CIDIN messages (possibly a function of
the AFTN centre).
Page: 1/1

Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

SUT

VCa

send

INV1

AFTN message with addresses unknown at the


entry centre (*)

SUT

VCa

send

INV2

AFTN message with unknown priority (*)

SUT

VCa

send

INV3

AFTN message with no carriage returns


between heading and addresses (*)

SUT

VCa

send

INV4

AFTN message with incorrectly formatted


origin line (*)

SUT

VCa

send

INV5

AFTN message with no carriage returns before


text (*)

SUT

VCa

send

INV6

AFTN message with no end of text signal (*)

SUT

VCa

send

INV7

AFTN message
characters (*)

with

text

length

Results - Additional
comments during test period

>1800

END OF PROCEDURE

Note: After expiration on the X.25 timer T21,


the SUT shall also send a clear request for its
original call (step 2). Then the next call (retry)
shall be accepted and data can be exchanged
(*) The action required from the AFTN centre
and AFTN interface software is a local matter.
The minimum requirements are:
- creation of an AFTN message conforming to
the standard, if possible, before transmission
over CIDIN and
- operator message or entry in error log

END OF PROCEDURE

Appendix D

Sixth Edition
Page 56 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

AFTN
2
2

Purpose:

Date of issue: 2003

Reaction to transmission errors: show that


transmission errors in CIDIN lead to the correct
reaction in the sending AFTN/CIDIN centres.
Page: 1/1

Step
No.

Centre

Connection

Action

Event

Alt.
Step
No.
2

Parameters/Comments

SUT

VCa

send

MES1

VCa

wait

MES1

VCa

send

ACK

ACK for MES1

SUT

VCa

send

MES1

Repetition of step 1

VCa

wait

MES1

VCa

wait

T(TMR)

VCa

wait

MES1

Receive again
CHECK: MIN unchanged

10

VCa

send

ACK

ACK for MES1

SUT

VCa

send

MES1

Repetition of step 1

10

VCa

wait

MES1

11

VCa

wait

T(TMR)

No ACK sent

12

VCa

wait

MES1

Receive again

13

15

VCa

wait

T(TMR)

14

SUT

VCa

send

MES1

15

VCa

wait

ENQ

No ACK sent
CHECK: AFTN and/or CIDIN centre operator
is informed
Repetition of step 1
CHECK: The entry centre does not transmit the
message
Wait for next ENQ

16

VCa

send

ENQr

Positive ENQ response

17

VCa

wait

MES1

CHECK: MES sent by the entry centre without


further operator action

18

20

VCa

send

ACK

ACK for MES1

19

22

SUT

VCa

send

MES1

Repetition of step 1

20

VCa

wait

MES1

21

VCa

send

MCFe

MCF error message

22

SUT

VCa

wait

MCFe

CHECK: the application level is informed and


appropriate action is taken

Results - Additional
comments during test period

Simple AFTN message

No ACK sent

END OF PROCEDURE

Appendix D

Sixth Edition
Page 57 of 101

14/04/2011

CIDIN Conformance Testing


Overview

Layer :
Test Group :

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue: 2003

AFTN
3
Page: 1/1

Purpose

List of procedures

Test exit centre functions (normal cases)


:
3.1
3.2

Normal reception of AFTN messages


Flow control in exit centres

Configuration used

A.B

To be preceded by test groups

Coding :
Text
repetitions*

Priority

Addresses (Ad1, Ad2, Ad3)

MES11

FF

EAFTNTS1

MES12

FF

EAFTNTS1, EAFTNTS2

MES13

SS

EAFTNTS1, DUMMY1, DUMMY2

Text*: sample_test; ITA-2_characters 29, 1 to 26, 30 to 32, 1to 28 (69 characters)

ACK: level 4 acknowledgement

Initialisation

:
Normal operational state
Initialisation of the exit centre started by the application software and the operator should be
demonstrated

Special considerations:

Appendix D

Sixth Edition
Page 58 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

AFTN
3
1

Purpose:

Date of issue: 2003

Normal reception of AFTN messages: show that AFTN


messages sent via CIDIN reach the addressed AFTN
station in the correct format.
Page: 1/1

Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

VCa

send

MES11

Message addressed to Ad1 (EAFTNTS1)

VCa

send

MES12

Message addressed to Ad1 and Ad2 (EAFTNTS1,


EAFTNTS2)

VCb

send

MES13

Message addressed to Ad as well as Ads connected


to other exit centres (EAFTNTS1, DUMMY1,
DUMMY2)

SUT

VCb

wait

MES11
MES12
MES13

Message output to AFTN stations


Ad1 and Ad2

Results - Additional
comments during test
period

CHECK: AFTN messages are correctly converted


from CIDIN to AFTN format
5

VCa

wait

ACK

Reception of ACKs corresponding to MES11,


MES12 and MES13

END OF PROCEDURE

Appendix D

Sixth Edition
Page 59 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

AFTN
3
2

Purpose:

Date of issue: 2003

Flow control in the exit centre: show that the


AFTN/CIDIN centre reacts correctly to a high
volume of messages to be output.
Page: 1/1

Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

VCa

send

MES11

Send MES11 repeatedly in rapid succession


simulating a sequence of distinct messages

SUT

VCa

wait

MES11

Receive MES11 repeatedly to demonstrate correct


implementation of rate adaptation and flow control

Results - Additional
comments during test
period

CHECK: Messages are output to the AFTN station


in correct order
No messages are lost
The flow control mechanism eventually restricts
the transmission from Y
3

VCa

wait

ACKs

Receive ACKs corresponding to each message sent

END OF PROCEDURE

Appendix D

Sixth Edition
Page 60 of 101

14/04/2011

CIDIN Conformance Testing


Overview

Layer :
Test Group :

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue: 2003

AFTN
4
Page: 1/1

Purpose

List of procedures

Test exit centre functions (exceptional cases)


:
4.1
4.2

Reaction to AFTN messages with format errors


Reaction to failure of the AFTN station

Configuration used

A.B

To be preceded by test groups

Coding :

Initialisation

INV1 to INV7

variations of MES12

MCFe, ACK

level 4 management messages

MES11

(see test group 3)

:
As for test group 3

Special considerations:

Appendix D

Sixth Edition
Page 61 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

AFTN
4
1

Purpose:

Date of issue: 2003

Reaction to received AFTN messages with format


errors: show that the appropriate action is taken
in the CIDIN exit centre/AFTN station.
Page: 1/1

Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

VCa

send

INV1

AFTN message with unknown Ads

VCa

wait

INV2

AFTN message with unknown priority

VCa

send

INV3

AFTN message with no carriage returns between


heading and addresses

VCa

wait

INV4

AFTN message with incorrectly formatted origin


line

VCa

send

INV5

AFTN message with no carriage returns before text

VCa

wait

INV6

AFTN message with no end-of-text signal

VCa

send

INV7

AFTN message with text length > 1800 characters

SUT

VCa

wait

INV1 to
INV7

Results - Additional
comments during test
period

CHECK: Appropriate action in AFTN interface


software and AFTN centre
The minimum requirements are:
- creation of an AFTN message conforming to the
standard, if possible
- operator message or entry in error log

END OF PROCEDURE

Appendix D

Sixth Edition
Page 62 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

AFTN
4
2

Purpose:

Date of issue: 2003

Reaction to failure of the AFTN station: show that


no messages sent via CIDIN are lost.
Page: 1/1

Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

VCa

send

MES11

VCa

wait

ACK

SUT

VCa

wait

MES11

Parameters/Comments

Results - Additional
comments during test
period

Send simple AFTN message


Repeat this sending sequence as fast as the ACK
procedure allows simulating the sending of distinct
messages
Output first instance of MES11
Cause a failure of the connection to the AFTN
station addressed in MES11
Restore the connection to the AFTN station

SUT

VCa

wait

MES11

Output further instances of MES11


CHECK: No instances of MES11 have been lost

END OF PROCEDURE

Appendix D

Sixth Edition
Page 63 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES

CIDIN Conformance Testing

D.1.7

Appendix D

Date of issue:

2004

CONFORMANCE TESTS (SINGLE LAYER)


CIDIN Network Management Application Interface . . . .

Sixth Edition
Page 64 of 101

14/04/2011

CIDIN Conformance Testing


Configurations

Layer :
Configuration :

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue:

2004

CIDIN Network Management Application Interface


A
Page: 1/1

System Under Test (SUT)

CIDIN Network Management interface software in a CIDIN entry centre

Purpose

Verification of the interface behaviour in normal cases

layer 4

Installation state

operational state

Parameter settings

Ae of centre ENTRM

Underlying layer

Number of test connections involved


Test Parameters

N.A.

:
SUT

CIDIN entry centre

Test CIDIN Centre or Testing Equipment simulating an exit centre

Number of connections in underlying layer :


Connections
a: VCa
Additional conditions

(SUT) - (Y) (EXITM)

The protocol analyser requires complete X.25 software with test software superimposed

SUT

Network Management working position


Protocol analyzer/
Test equipment
Local
matter

NM interface
Test Sequences
EXITM

Layer 4
Layer 3b
Layer 3a
Layer 2

Appendix D

Layer 3a
a: VCa

Sixth Edition
Page 65 of 101

Layer 2

14/04/2011

CIDIN Conformance Testing


Configurations

Layer :
Configuration :

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue:

2004

CIDIN Network Management Application Interface


B
Page: 1/1

System Under Test (SUT)

CIDIN Network Management interface software in a CIDIN exit centre

Purpose

Verification of NM interface behaviour in normal cases

layer 4

Installation state

operational state

Parameter settings

Ax of centre EXITM

Underlying layer

Number of test connections involved


Test Parameters

N.A.

:
SUT

CIDIN exit centre

Test CIDIN Centre or Testing Equipment simulating an entry centre

Number of connections in underlying layer :


Connections
a: VCa
Additional conditions

(SUT) - (Y), route between ENTRM and EXITM

The protocol analyser requires complete X.25 software with test software superimposed

SUT

Network Management working position


Protocol analyzer/
Test equipment
Local
matter

NM interface
Test Sequences
ENTRM

EXITM
Layer 3b
Layer 3a
Layer 2

Appendix D

Layer 3a
a: VCa

Sixth Edition
Page 66 of 101

Layer 2

14/04/2011

CIDIN Conformance Testing


Overview

Layer :
Test Group :

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Date of issue: 2004

CIDIN Network Management Application Interface


1
Page: 1/1

Purpose

Test entry centre functions (normal cases)

List of procedures

:
1.1
1.2

Messages with all possible priorities (B.4.6)


Messages up to the maximum length (1.2.2.5.2)

Configuration used

To be preceded by test groups

Coding :
Message

Priority

Text

NA-bit

MES1

NA=1

MES2

NA=1

MES3

NA=1

MES4

NA=1

MES5

NA=1

MES6

NA=1

Text A:

(NM)OP
CCCC DE BBBB 18:10:25
AFTN MAPPING AGREEMENT REQUEST (AD-AX)
BBBB TO MAP AFTN INDICATORS LP TO AX CCCCA
DUE TO OUTAGE EEEEA
PLEASE CONFIRM AGREEMENT OR DISAGREEMENT
NA: see procedure

MT:0

CP:0

MCF:1

Text B:

(NM)OP
123456....line 1lines are 80 characters long plus cr/lf) ..7890
123456line 2 .7890
123456line 3 .7890
|
| total CUDF = 24 x 82 = 1968 + 8 for (NM)OP cr lf
|
123456line 23.7890
123456line 24.7890
NA: 1

Appendix D

MT:0

CP:0

MCF:1
Sixth Edition
Page 67 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


Text C:

(NM)OP
123456....line 1lines are 80 characters long plus cr/lf) ..7890
123456line 2 .7890
123456line 3 .7890
|
| total CUDF = 24 x 82 = 1968 + 8 for (NM)OP cr lf
|
123456line 23.7890
123456line 24.7890
...text exceeding the max CUDF length for NM
NA: 1

Initialisation

MT:0

CP:0

MCF:1

Normal operational state; in routing tables: all messages sent via EXITM
Initialisation of entry centre started by application software and operator should be demonstrated.

Special considerations:
The selection of the priority is a local matter.
The internal link between the Network Management working position and the IUT is implicitly tested.

Appendix D

Sixth Edition
Page 68 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Test Group
Procedure

Step
No.

Alt.
Step
No.

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Network Management
1 (entry centre)
1

Date of issue: 2004

Purpose: Ability to generate messages with different


priorities (B.4.6) and Network Acknowledgment bit
(NA=1)
Page: 1/1

Centre

Connection

Action

Event

Parameters/Comments

SUT

VCa

send

MES1

NM message with priority 1 (000), NA=1

VCa

wait

MES1

CHECK: correct coding of CIDIN message

SUT

VCa

send

MES2

NM message with priority 2 (001), NA=1

VCa

wait

MES2

CHECK: correct coding of CIDIN message

SUT

VCa

send

MES3

NM message with priority 8 (111), NA=1

VCa

wait

MES3

CHECK: correct coding of CIDIN message

SUT

VCa

send

MES4

NM message with priority 3 (010), NA=1

VCa

wait

MES4

CHECK: correct coding of CIDIN message

Results - Additional
comments during test
period

END OF PROCEDURE

Appendix D

Sixth Edition
Page 69 of 101

14/04/2011

CIDIN Conformance Testing


Procedures
Layer
Group
Procedure

Step
No.

:
:
:

EUR CIDIN MANUAL APPENDICES


Single Layer Tests

Network Management
1 (entry centre)
2

Centre Connection

Action

Event

Date of issue: 2004

Purpose: Ability to transmit Messages up to maximum


text length.
Checking of the text length
Page: 1/1

Alt.
Step
No.
2

Parameters/Comments

SUT

VCa

send

MES5

NM message with priority 1 (000), NA=1

VCa

wait

MES5

CHECK: correct coding of CIDIN message

SUT

VCa

send

MES6

Overlong NM message with priority 1 (001), NA=1

VCa

wait

Results - Additional
comments during test
period

CHECK: no message produced.


END OF PROCEDURE

Note: Step No. 3 The way to prevent transmitting


overlong messages is a local matter.

Appendix D

Sixth Edition
Page 70 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Conformance Testing
Overview

Layer :
Test Group :

Single Layer Tests

Date of issue: 2004

Network Management
2
Page: 1/1

Purpose

List of procedures

Test exit centre functions (normal cases)


:
2.1

Normal reception of Network Management messages with


different priorities
Reception of a message with maximum message length and
reception of an overlong message

2.2

Configuration used

To be preceded by test groups

Coding :

Appendix D

See configuration A

Sixth Edition
Page 71 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing

D.2

Appendix D

Date of issue: April 2003

INTEROPERABILITY TESTS (Bilateral)

Sixth Edition
Page 72 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES

D.2.1

INTEROPERABILITY TESTING PROCEDURES (Bilateral)

D.2.2

Purpose of bilateral interoperability tests

The purpose of bilateral interoperability tests is to test the joint operation of two CIDIN centres in normal operating
conditions, including all defined CIDIN layers. They are also intended to test the complete operation of more than one
application, verifying their interfaces with Layer 4.
These are performed between two CIDIN centres at the system level. The centres subject to testing (Centre A and
Centre B) are treated as a whole, without taking into account their internal structure or the particular implementation of
each of the CIDIN protocol layers.
The testing of the specific functions of each layer (single-layer testing) shall have been previously performed at each
centre, in local or remote mode and their correct operation layer by layer shall have been demonstrated.
For the purpose of such tests, the connection between the two centres is considered to be one sole VC without
distinction (PVC or SVC). However, some dedicated integration tests are included in this section concerning particular
operational features of SVC communications, PVC/SVC switchover procedures and others.
Bilateral interoperability tests will test the behaviour of the centres in entry and exit functions. More complete tests will
be performed during the quadrilateral interoperability testing phase, including the relay functions. These latter tests will
be performed once bilateral tests have been carried out successfully between each two centres participating in the
quadrilateral tests.
The centres subject to testing will be equipped with real operation software, which will not have been modified for
testing purposes. This software will consist of CIDIN Layers 1-4, as well as sources for providing AFTN and nonAFTN messages, both requiring and not requiring end-to-end acknowledgements. Thus, the centres must be able to
respond to at least two different Axs one for AFTN messages, and the other for non-AFTN messages.
The tracing functions available at each centre will be used to analyse the results of the testing sessions, as well as
protocol analysers monitoring the lines at both ends. In the event that the anticipated results are not obtained in any of
the tests, this will permit a subsequent analysis of the situation in order to determine the cause of variance in the
behaviour of the centres or the type of error detected. As a result of this analysis, it may be necessary to repeat some of
the tests at a single layer (in the case of error detection), or to expand the testing sequence or include new tests in
subsequent versions (in the case of variance in interpretation of the specification).

D.2.3

Testing prerequisites

Prior to the actual testing phase, the following items must be discussed and agreed as a minimum between the two test
partners:

General and specific parameters


Connections to be used (Characteristics and association)
Initial state (Steps completed before the starting point)
Test messages to be used
Test addresses to be used
Mapping of Ads to Axs
Sets of routing tables for each centre

Appendix D

Sixth Edition
Page 73 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Bilateral Tests
Configurations/Overview

Type:
Test Group:

Date of issue:

2003

I
1
Page 1/1

Purpose: Verification of centre behaviour in normal AFTN and non-AFTN traffic.


List of procedures:
1.1

Normal transmission/reception of AFTN messages.

1.2

Normal transmission/reception of non-AFTN messages.

1.3

Simultaneous transmission of AFTN and non-AFTN messages in normal conditions.

Type:
Test Group:

I
2

Purpose: Mechanisms for retransmission of messages


List of procedures:
2.1

Verification of retransmission mechanisms based on ACK loss

Type:
Test Group:

I
3

Purpose: Verification of centre behaviour in normal traffic exchange situations (incoming call reception, traffic
exchange, clearing due to elapse of the idle timer, operator initiated clearing etc. when using SVCs
List of procedures:
3.1

AFTN message exchange using SVCs


General parameters:
As in Single Layer Tests (layers 3b & 4)
Specific parameters:
Connections:

(SUT) (Y)

One link a between Centres SUT and Y


One VC is defined
In Test Group 3 the VC type is SVC.

Configuration:
SUT

AFTN/CIDIN
Application

AFTN/CIDIN
Application

Layer 4

Layer 4

Layer 3b

Layer 3b

Layer 3a

Layer 3a

Layer 2

Appendix D

a: VCa

Sixth Edition
Page 74 of 101

Layer 2

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Bilateral Tests
Procedures
Type:
Test Group:
Procedure:

I
1
1 (VC)

Date of issue:

2003

Purpose: Normal transmission/reception of AFTN messages

Page: 1/1
Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

1,2

SUT, Y

a: VCa

wait

INIT

Upgrading of link a [VCa initialisation]

SUT

a: VCa

send

M11

Message M11 sent

a: VCa

receive

M11

Reception of M11

SUT

a: VCa

send

M21

Message M21 sent

a: VCa

receive

M21

Reception of M21
CHECK: correct reception at Y

a: VCa

send

ACK

Acknowledgement of M11

SUT

a: VCa

receive

ACK

a: VCa

send

ACK

SUT

a: VCa

receive

ACK

Results - Additional
Comments during test period

Acknowledgement of M21

END OF PROCEDURE

Appendix D

Sixth Edition
Page 75 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Procedures
Type:
Test Group:
Procedure:

Bilateral Tests

I
1
2 (VC)

Date of issue:

2003

Purpose: Normal transmission/reception of non-AFTN messages

Page: 1/1
Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

1,2

SUT, Y

a: VCa

wait

INIT

Upgrading of link a [VCa initialisation]

SUT

a: VCa

send

M31

Message M31 sent

a: VCa

receive

M31

Reception of M31

a: VCa

send

ACK 1

Acknowledgement of M31

SUT

a: VCa

receive

ACK1

Reception of M31 acknowledgement

SUT

a: VCa

send

M42

Message M42 sent

a: VCa

receive

M42

Reception of M42

a: VCa

send

ACK 2

Acknowledgement of M42

SUT

a: VCa

receive

ACK 2

Reception of M42 acknowledgement

Results - Additional
Comments during test period

END OF PROCEDURE

Appendix D

Sixth Edition
Page 76 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Bilateral Tests
Procedures
Type:
Test Group:
Procedure:

I
1
3 (VC)

Date of issue:

2003

Purpose: Simultaneous transmission of AFTN and


non-AFTN messages in normal conditions
Page: 1/1

Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

1,5

SUT, Y

a: VCa

wait

INIT

Upgrading of link a [VCa initialisation]

SUT

a: VCa

send

M11

SUT

a: VCa

send

M21

SUT

a: VCa

send

M31

11

SUT

a: VCa

send

M42

)
)
) Steps 1 to 4 should be repeated ten times
)
)
)
)

a: VCa

send

M11

a: VCa

send

M21

a: VCa

send

M31

a: VCa

send

M42

)
)
) Steps 5 to 8 should be repeated ten times
)
)
)
)

10

a: VCa

receive

MIJ

Y receives MIJ (messages deriving from steps 1 to 4)

10

14

a: VCa

send

ACK

Acknowledgement of MIJ

11

12

SUT

a: VCa

receive

ACK

12

13

SUT

a: VCa

receive

MIJ

Y receives MIJ (messages derived from steps 5 to 8)

13

SUT

a: VCa

send

ACK

Acknowledgement of MIJ

14

a: VCa

receive

ACK

CHECK: no message has been lost at either centre

Results - Additional
Comments during test
period

END OF PROCEDURE

Appendix D

Sixth Edition
Page 77 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Bilateral Tests
Procedures
Type:
Test Group:
Procedure:

I
2
1 (VC)

Date of issue:

2003

Purpose: Verification of retransmission mechanisms based on ACK loss

Page: 1/1
Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

Results - Additional
Comments during test
period

TMR = 0 at SUT
0

1,5

SUT, Y

a: VCa

wait

INIT

Upgrading of link a [VCa initialisation]

SUT

a: VCa

send

M11

Message M11 sent (AFTN with NA=1)

SUT

wait

TMR

TMR expires at SUT

SUT

send

M11

Retransmission of M11

SUT

wait

TMR

TMR expires at SUT again

a: VCa

receive

M11

Reception of M11

a: VCa

send

ACK

Acknowledgement of M11

a: VCa

receive

M11

Reception of M11

10

a: VCa

send

ACK

Acknowledgement of M11

12

SUT

a: VCa

send

ENQ

SUT enquires Y

10

11

a: VCa

receive

ENQ

Reception of ENQ at Y

11

a: VCa

send

ENQr

Y responds to enquiry

12

SUT

a: VCa

receive

ACK

Reception of acknowledgement

13

SUT

a: VCa

receive

ACK

Reception of acknowledgement
(The ACKs received in steps 12 and 13 should be
ignored and the operator informed)

14

SUT

a: VCa

receive

ENQr

Reception of ENQr at SUT

15

a: VCa

send

M11

Message M11 sent

a: VCa

END OF PROCEDURE

Appendix D

Sixth Edition
Page 78 of 101

14/04/2011

CIDIN Conformance Tests


Procedures
Type:
Test Group:
Procedure:
Step
No.

Alt.
Step
No.

EUR CIDIN MANUAL APPENDICES


Integration Tests

I
3
1 (SVC)
Centre Connection

A,B

Date of issue: 2002

Purpose: AFTN message exchange (SVC, normal case)


Page: 1/2
Action

Event

Parameters/Comments

wait

INIT

Configuration
[initialisation]

VCa

send

CALL REQUEST

CALL REQUEST sent

VCa

receive

INCOMING CALL

Reception of INCOMING CALL

VCa

send

CALL ACCEPTED

CALL ACCEPTED sent

VCa

receive

CALL CONNECTED

CALL CONNECTED received

VCa

send

M11

Message M11 sent

VCa

receive

M11

Message M11 received

VCa

send

ACK

Acknowledgement of M11

VCa

receive

ACK

Reception of acknowledgement

VCa

send

M12

Message M12 sent

10

VCa

receive

M12

Message M12 received

11

VCa

send

ACK

Acknowledgement of M12

12

VCa

receive

ACK

Reception of acknowledgement

wait

Idle timer elapsed


Initiation of clearing procedure (by
the Centre that requested the call)

13
14

VCa

send

CLEAR REQUEST

15

VCa

receive

CLEAR INDICATION

16

VCa

send

CLEAR CONFIRMATION

17

VCa

receive

CLEAR CONFIRMATION

of

VCa

as

Results - Additional
Comments during test
period
SVC

SVC becomes idle


18-25

Repetition of steps 1-8

(B acts as the Local Centre and A as


the Remote Centre)
Operator initiated CLEAR (Cause
code 00)

26

VCa

send

CLEAR REQUEST

27

VCa

receive

CLEAR INDICATION

28

VCa

send

CLEAR CONFIRMATION

29

VCa

receive

CLEAR CONFIRMATION
SVC cleared

Appendix D

Sixth Edition
Page 79 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


Page: 2/2
Step
No.

Alt.
Step
No.

Centre

Connection

Action

Event

Parameters/Comments

30

VCa

send

CALL REQUEST

CALL REQUEST sent

31

VCa

receive

INCOMING CALL

Reception of INCOMING CALL

Repetition of steps 26-29

Incoming call refusal

32-35

Results - Additional
Comments during test
period

CHECK: After repetition of 30-35


several times the SVC becomes
not operational. DTE remains
disabled until enabled by the operator
END OF PROCEDURE

Appendix D

Sixth Edition
Page 80 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing

D.3

Appendix D

Date of issue: April 2003

INTEROPERABILITY TESTS (Quadrilateral)

Sixth Edition
Page 81 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES

D.3.1

INTEROPERABILITY TESTING PROCEDURES (Quadrilateral)

D.3.2

Purpose of quadrilateral interoperability tests

The purpose of quadrilateral interoperability tests is to test the validity of implementation of relay centres, routeing
principles in normal cases and using secondary routes, and simultaneous traffic situations from various centres. Also to
be tested will be CIDIN protection mechanisms against loops, packet loss, message loss, etc., within a real operation
configuration, providing initial conclusions concerning window values, timers, MIN ranges, etc., to be used in the
future.
These tests will usually be performed among four CIDIN centres in real operation, although only three centres are
required in some cases. A prerequisite for the performance of the tests will be that each of the centres participating in
this phase shall have successfully completed bilateral interoperability testing with at least one other CIDIN centre,
preferably of a different manufacturer.
Tests at this level are not concerned with the type of connection (PVC, SVC) established between any two participating
centres.
The centre subject to testing will be equipped with complete CIDIN software (up to and including Layer 4), and will be
able to generate and receive both AFTN and non-AFTN messages, consequently responding to more than one Ax/Ae.
Centres must have facilities available for varying timers, particularly TMR and TEM, to permit message loss
simulation. Also, as in the case of bilateral interoperability testing, it is felt to be advisable for centres to be equipped
with protocol analysers for monitoring their lines in various tests, also permitting errors analysis if the results of any
particular test are not expected.
Since tests do not require equivalent behaviour in all centres, most of them will have to be performed from the
beginning at each of the participating centres.

D.3.3

Testing prerequisites

Due to the number of participating centres, such tests should be scheduled and co-ordinated in detail.
Prior to the actual testing phase, the following items must be discussed and agreed as a minimum:

General and specific parameters


Connections to be used (Characteristics and association)
Initial state (Steps completed before the starting point)
Test messages to be used
Test addresses to be used
Mapping of Ads to Axs
Sets of routing tables for each centre

Appendix D

Sixth Edition
Page 82 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Quadrilateral Tests
Overview
Type:
Test Group:

Date of issue: 2003

N
1
Page: 1/1

Purpose: Verification of correct transmission/reception of multi-destination


messages in normal cases and in the event of network out of service

List of procedures:
1.1

Transmission of an AFTN message from one centre to more than 2 other centres.

1.2

Transmission of AFTN multi-destination messages with remote link out of order.

1.3

Transmission of AFTN multi-destination messages with adjacent primary link out of


service.

1.4

Transmission of messages to an isolated centre and its progressive recovery process.

1.5

Transmission of a message not requiring acknowledgement to three other centres when the adjacent link of the
primary route to one of the destination centres is out of service.

1.6

Transmission of a message not requiring acknowledgement from one centre to several other centres when a
remote link is out of service.

Type:
Test Group:

N
2

Purpose: Verification of alternative routing selection procedures at message entry/relay centres


List of procedures:
2.1

Verification whether a relay centre selects alternate route

Appendix D

Sixth Edition
Page 83 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Quadrilateral Tests
Procedure Abstract

Type:
Test Group:
Procedure:

N
1
1

Date of issue: 2003

Purpose: Transmission of an AFTN message from one centre


to more than 2 other centres
Page: 1/1

CONFIGURATION DIAGRAM

a: VCa

B
b: VCb

d: VCd
c: VCc

Primary routes:

Centres:
Links:

A, B, C, D
a, b, c, d (carrying VCa, VCb, VCc and VCd respectively and possibly other VCs)

Activities:
This test is intended to verify if the centres involved react in accordance with the provisions of the protocol. For this
purpose, one single centre (A) sends messages addressed to all other centres involved in the test (B, C and D). The
correct return of ACK messages from the destination centres is verified.

Appendix D

Sixth Edition
Page 84 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:

N
1
1

Date of issue: 2003

Purpose: Transmission of an AFTN message from one


centre to more than two other centres
Page: 1/1

Step
No.

Ref.
Step
No.
CENTRE A

Ref.
Centre

Connection

Action

a: VCa, d:VCd send

Event

M11

Parameters/Comments

Results - Additional
Comments during test
period

AFTN message M11 sent to centres B,C and D


Reception of acknowledgements
(not necessarily in the indicated order)

a: VCa

receive

ACK

ACK sent from Centre B to Centre A

d:VCd

receive

ACK

ACK sent from Centre D to Centre A

a: VCa

receive

ACK

ACK sent from Centre C to Centre A

CENTRE B
1

a: VCa

receive

PM1I

Reception of M11 message packets from centre A

b: VCb

send

M1I

Centre B relays packets to Centre C


CHECK: correct address suppression

wait

M11

Wait for complete M11

a: VCa

send

ACK

ACK sent from Centre B to Centre A

b: VCb

receive

PACK

) Centre B relays ACK sent from Centre C to Centre A

a: VCa

send

PACK

)
)

receive

PM1I

Reception of M11 messages packets from Centre A

CENTRE C
1

b: VCb

wait

M11

Wait for complete M11

b: VCb

send

ACK

ACK sent from Centre C to Centre A

receive

PM1I

Reception of M11 message packets from Centre A

CENTRE D
1

d:VCd

wait

M11

Wait for complete M11

d:VCd

send

ACK

ACK sent from Centre D to Centre A

END OF PROCEDURE

Appendix D

Sixth Edition
Page 85 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Quadrilateral Tests
Procedure Abstract

Type:
Test Group:
Procedure:

N
1
2

Date of issue: 2003

Purpose: Transmission of AFTN multi-destination


messages with remote link out of service
Page: 1/1

CONFIGURATION DIAGRAM

a: VCa

X b: VCb

d: VCd
c: VCc

Primary routes:

Centres:
Links:

A, B, C, D
a, b, c, d (carrying VCa, VCb, VCc and VCd respectively and possibly other VCs)

Activities:
With link b out of service, A sends a message addressed to centres B, C and D. The test is intended to verify that centres
B and D correctly return ACK messages to A, that Centre A initiates and carries out the process provided in the
protocol with respect to C (resends the message to C, ENQUIRY process, etc.). Finally, it will be verified that after the
recovery of link b, A resends the message and C receives and returns the appropriate ACK message.

Appendix D

Sixth Edition
Page 86 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:

N
1
2

Date of issue: 2003

Purpose: Transmission of AFTN multi-destination


messages with remote link out of service
Page: 1 / 2

Step
No.

Ref.
Step
No.

Ref.
Centre

Connection

Action

Event

Parameters/Comments

Results - Additional
Comments during test period

CENTRE A
1

a: VCa

d:VCd

wait

SYNC

Wait for performance of step 1 at Centre B

M11

AFTN message M11 sent to centres B,C and D


Reception of acknowledgements
(not necessarily in the indicated order)

receive

ACK

ACK sent from Centre B to Centre A

receive

ACK

ACK sent from Centre D to Centre A

wait

TMR

TMR expires

a: VCa

send

M11

M11 sent only to Centre C

wait

TMR

TMR expires

a: VCa

send

ENQ

ENQ sent from Centre A to Centre C

wait

TEM

TEM expires
Steps 8 to 9 are repeated several times

10

a: VCa

receive

ENQr

Centre C response to Centre A enquiry

11

a: VCa

send

M11

M11 sent only to Centre C

12

a: VCa

receive

ACK

ACK sent from Centre C to Centre A

DISCONNECT LINK b

receive

PM11

M11 packets addresses to Centre B and C


CHECK: Centre B discards packets addresses
to Centre C

a: VCa, d:VCd send

CENTRE B
1

a: VCa

wait

M11

Wait for complete M11

a: VCa

send

ACK

ACK sent from Centre B to Centre A

a: VCa

receive

M1I

M11 packets addresses to C

a: VCa

receive

PENQ

ENQ sent from Centre A to Centre C

RECONNECT LINK b

a: VCa

receive

PENQ

ENQ sent from Centre A to Centre C

b: VCb

send

PENQ

Centre B relays ENQ sent from Centre A to


Centre C

Appendix D

Sixth Edition
Page 87 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:

N
1
2

Date of issue: 2003

Purpose: Transmission of AFTN multi-destination


messages with remote link out of service
Page: 2/2

Step
No.

Ref.
Step
No.

Ref.
Centre

Connection

Action

Event

Parameters/Comments

10

b: VCb

receive

PENQr

Centre C response to Centre A ENQ

11

10

a: VCa

send

PENQr

Centre B relays Centre C ENQr to Centre A

12

11

a: VCa

receive

PM11

M11 packets addresses to Centre C

13

12

b: VCb

send

PM11

Centre B relays packets to Centre C

14

b: VCb

receive

ACK

ACK sent from Centre C to Centre A

15

14

a: VCa

send

ACK

B relays ACK sent from Centre C to Centre A

Results - Additional
Comments during test period

CENTRE C
1

b: VCb

receive

ENQ

ENQ sent from Centre A to Centre C

b: VCb

send

ENQr

Centre C response to A enquiry

13

b: VCb

receive

PM11

Reception of M11 message packets from Centre A

11

wait

M11

Wait for complete M11

b: VCb

send

ACK

ACK sent from Centre C to Centre A

receive

PM11

Reception of M11 message packets from Centre A

CENTRE D
1

d:VCd

wait

M11

Wait for complete M11

d:VCd

send

ACK

ACK sent from Centre D to Centre A

END OF PROCEDURE

Appendix D

Sixth Edition
Page 88 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Quadrilateral Tests
Procedure Abstract

Type:
Test Group:
Procedure:

N
1
3

Date of issue: 2003

Purpose: Transmission of AFTN multi-destination


messages with adjacent primary link out of service
Page: 1/1

CONFIGURATION DIAGRAM

a: VCa

B
b: VCb

d: VCd
c: VCc

Primary routes:

Centres:
Links:

A, B, C, D
a, b, c, d (carrying VCa, VCb, VCc and VCd respectively and possibly other VCs)

Activities:
With link a out of service, a message requiring ACK is sent from A to all the other centres (B, C and D). All of the
centres receive the message and send ACK. The ACK sent by centre C cannot progress beyond B, such that A considers
it out of service and sends ENQ messages. At a given time, link a is restored and the reply to the ENQ and the correct
reception of the ACK will be checked.

Appendix D

Sixth Edition
Page 89 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:

N
1
3

Date of issue: 2003

Purpose: Transmission of AFTN multi-destination


messages with adjacent primary link out of service
Page: 1/3

Step
No.

Ref.
Step
No.

Ref.
Centre

Connection

Action

Event

Parameters/Comments

Results - Additional
Comments during test
period

CENTRE A
1

DISCONNECT LINK a

d:VCd

send

M11

AFTN message M11 sent to Centres B, C and D

d:VCd

receive

ACK

ACK sent from Centre B to Centre A

d:VCd

receive

ACK

ACK sent from Centre B to Centre A

wait

TMR

TMR expires

d:VCd

send

M11

M11 sent only to Centre C

wait

TMR

TMR expires again

d:VCd

send

ENQ

ENQ sent from Centre A to Centre C

wait

TEM

TEM expires
Steps 8 to 9 are repeated several times

10

RECONNECT LINK a

11

a: VCa

send

ENQ

ENQ sent from Centre A to Centre C

12

13

a: VCa

receive

ENQr

Centre C response to Centre A enquiry

13

a: VCa

send

M11

M11 sent only to Centre C

14

16

a: VCa

receive

ACK

ACK sent from Centre C to Centre A

receive

PM11

M11 packets addressed to Centre B

CENTRE B
1

b: VCb

wait

M11

Wait for complete M11

b: VCb

send

ACK

ACK sent from Centre B to Centre A

b: VCb

receive

PACK

ACK sent from Centre C to Centre A

b: VCb

receive

PACK

ACK sent from Centre C to Centre A

11

b: VCb

receive

PENQr

Centre C response to Centre A ENQ


Step 6 is repeated several times

11

a: VCa

receive

PENQ

ENQ sent from Centre A to Centre C

b: VCb

send

PENQ

Centre B relays ENQ sent from Centre A to Centre C

Appendix D

Sixth Edition
Page 90 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:

N
1
3

Date of issue: 2003

Purpose: Transmission of AFTN multi-destination


messages with adjacent primary link out of service
Page: 2/3

Step
No.

Ref.
Step
No.

Ref.
Centre

Connection

Action

Event

Parameters/Comments

13

b: VCb

receive

PENQr

Centre C response to Centre A ENQ

10

a: VCa

send

PENQr

Centre B relays Centre C ENQr to Centre A

11

13

a: VCa

receive

PM11

M11 packets addressed to Centre C

12

11

a: VCa

send

PM11

Centre B relays packets to Centre C

13

16

b: VCb

receive

PACK

ACK sent from Centre C to Centre A

14

13

a: VCa

send

PACK

Centre B relays ACK sent from Centre C to Centre A

Results - Additional
Comments during test
period

CENTRE C
1

c: VCc

receive

PM11

M11 packets addressed to Centres B and C

b: VCb

send

PM11

Centre C relays packets addresses to Centre B

wait

M11

Wait for complete M11

b: VCb

send

ACK

ACK sent from Centre C to Centre A

b: VCb

receive

PACK

ACK sent from Centre B to Centre A

c: VCc

send

PACK

Centre C relays ACK sent from Centre B to Centre A

c: VCc

receive

PM11

M11 packets addressed to Centre C

wait

M11

Wait for complete M11

b: VCb

send

ACK

ACK sent from Centre C to Centre A

10

d:VCd

receive

ENQ

ENQ sent from Centre A to Centre C

11

b: VCb

send

ENQr

Centre C response to Centre A ENQ


Steps 10 and 11 are repeated several times

12

11

b: VCb

receive

ENQ

ENQ sent from Centre A to Centre C

13

b: VCb

send

ENQr

Centre C response to Centre A ENQ

14

12

b: VCb

receive

PM11

M11 packets addressed to Centre C

15

13

wait

M11

Wait for complete M11

16

b: VCb

send

ACK

ACK sent from Centre C to Centre A

Appendix D

Sixth Edition
Page 91 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:

N
1
3

Date of issue: 2003

Purpose: Transmission of AFTN multi-destination


messages with adjacent primary link out of service
Page : 3/3

Step
No.

Ref.
Step
No.

Ref.
Centre

Connection Action

Event

Parameters/Comments

Results - Additional
Comments during test period

CENTRE D
1

d:VCd

receive

PM11

M11 packets addressed to Centres B, C and D

c: VCc

send

PM11

Centre D relays packets to Centres B and C

wait

M11

Wait for complete M11

d:VCd

send

ACK

ACK sent from Centre D to Centre A

c: VCc

receive

PACK

ACK sent from Centre B to Centre A

d:VCd

send

PACK

D relays ACK sent from Centre B to Centre A

d:VCd

receive

PM11

M11 packets addressed to Centre C

c: VCc

send

PM11

D relays packets to Centre C

d:VCd

receive

PENQ

ENQ sent from Centre A to Centre C

10

c: VCc

send

PENQ

D relays ENQ sent from Centre A to Centre C


Steps 9 and 10 are repeated several times

END OF PROCEDURE

Appendix D

Sixth Edition
Page 92 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Quadrilateral Tests
Procedure Abstract

Type:
Test Group:
Procedure:

N
1
4

Date of issue: 2003

Purpose: Transmission of messages to an isolated centre and


its progressive recovery process
Page: 1/1

CONFIGURATION DIAGRAM

a: VCa

B
b: VCb

d: VCd
c: VCc

Primary routes:
Secondary routes
Centres:
Links:

A, B, C, D
a,b,c,d (carrying VCa, VCb, VCc and VCd respectively and possibly other VCs)

Activities:
Centre A sends a multi-destination message addressed to Centres B, C and D with links b and c out of service. Centre A
receives ACK from Centres B and D. Centre B discards packets addressed to C. When TMR expires, Centre A resends
the message only to Centre C with B again discarding the packets. When TMR expires a second time, A sends ENQ
packets to C, with B also discarding these packets.
Link c is now restored. Centre A continues making enquiries to C through B. Finally, link b is restored. Centre C
receives Centre A ENQ and responds through B. When A receives Centre C ENQr, it sends the message through B. C
sends the appropriate ACK also through B.

Appendix D

Sixth Edition
Page 93 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:

N
1
4

Date of issue: 2003

Purpose: Transmission of messages to an isolated centre and


its progressive recovery process
Page 1 /2

Step
No.

Ref.
Step
No.
CENTRE A
1
1

Ref.
Centre

Connection

Action

wait

a: VCa, d:VCd send

Event

Parameters/Comments

SYNC

Wait for performance of step 1 at Centre C

M11

AFTN message M11 sent to Centres B, C and D

Results - Additional
Comments during test
period

Reception of ACKs not necessary in the indicated


order
3

a: VCa

receive

ACK

ACK sent from Centre B to Centre A

d:VCd

receive

ACK

ACK sent from Centre D to Centre A

wait

TMR

TMR expires

a: VCa

send

M11

M11 sent only to Centre C

wait

TMR

TMR expires again

a: VCa

send

ENQ

ENQ sent from Centre A to Centre C

wait

TEM

TEM expires
Steps 8 to 9 are repeated several times

10

a: VCa

receive

ENQr

Centre C response to Centre A ENQ

11

a: VCa

send

M11

M11 sent only to Centre C

12

a: VCa

receive

ACK

ACK sent from Centre C to Centre A

wait

SYNC

Wait for performance of step 1 at Centre C

receive

PM11

Reception of M11 packets


(Ax for Centres B and C)

CENTRE B
1

a: VCa

wait

M11

Wait for complete M11

a: VCa

send

ACK

ACK sent from Centre B to Centre A

a: VCa

receive

PM11

Reception of M11 packets (Ax only for Centre C)

a: VCa

receive

PENQ

ENQ sent from Centre A to Centre C


Step 6 is repeated several times

wait

SYNC

Wait for performance of step 4 at Centre C

a: VCa

receive

PENQ

ENQ sent from Centre A to Centre C

Appendix D

Sixth Edition
Page 94 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:

N
1
4

Date of issue: 2003

Purpose: Transmission of messages to an isolated centre and


its progressive recovery process
Page 2/2

Step
No.

Ref.
Step
No.

Ref.
Centre

Connection

Action

Event

Parameters/Comments

b: VCb

send

PENQ

Centre C response to Centre A ENQ

10

b: VCb

receive

PENQr

Centre C response to Centre A ENQ

11

10

a: VCa

send

PENQr

M11 packets addressed to Centre C

12

11

a: VCa

receive

PM11

M11 packets addressed to Centre C


(Ax only for Centre C)

13

12

b: VCb

send

PM11

Centre B relays packets to Centre C

14

b: VCb

receive

PACK

ACK sent from Centre C to Centre A

15

14

a: VCa

send

PACK

Centre B relays ACK sent from Centre C to Centre A

Results - Additional
Comments during test
period

CENTRE C
1

DISCONNECT LINKS b AND c

wait

SYNC

Wait for performance of steps 9 of Centre A


and 6 of Centre B

CONNECT LINK c

CONNECT LINK d

b: VCb

receive

ENQ

ENQ sent from Centre A to Centre C

b: VCb

send

ENQr

Centre C response to Centre A ENQ

13

b: VCb

receive

PM11

M11 packets addresses to Centre C


(Ax only for Centre C)

11

wait

M11

Wait for complete M11

b: VCb

send

ACK

ACK sent from Centre C to Centre A

CENTRE D
1
1

wait

SYNC

Wait for the performance of step 1 at Centre C

d:VCd

receive

PM11

Reception of M11 packets


(Ax only for Centre D)

wait

M11

Wait for complete M11

d:VCd

send

ACK

ACK sent from Centre D to Centre A

wait

SYNC

Wait for step 3 at Centre C


END OF PROCEDURE

Appendix D

Sixth Edition
Page 95 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Quadrilateral Tests
Procedure Abstract

Type:
Test Group:
Procedure:

N
1
5

Date of issue: 2003

Purpose: Transmission of a message, not requiring an ACK, to three


other Centres, when the adjacent primary link of the route
to one of the destination centres is out of order.
Page: 1/1

CONFIGURATION DIAGRAM

a: VCa

B
b: VCb

d: VCd
c: VCc

Primary routes:

Centres:
Links:

A, B, C, D
a, b, c, d (carrying VCa, VCb, VCc and VCd respectively and possibly other VCs)

Activities:
With link a out of service, a message not requiring an ACK is sent from A to all other centres. All the centres receive
the message. A line monitor connected between C and D shows the message passing from D to C.
Acknowledgements are not received at centre A.

Appendix D

Sixth Edition
Page 96 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Quadrilateral Tests
Procedure

Type:
Test Group:
Procedure:

N
1
5

Date of issue: 2003

Purpose: Transmission of a message, not requiring an ACK, to three


other Centres, when the adjacent primary link of the route
to one of the destination centres is out of order.
Page 1/1

Step
No.

Ref.
Step
No.

Ref.
Centre

Connection

CENTRE A
1
-

CENTRE B
1
2
2

Action

Event

Parameters/Comments

DISCONNECT LINK a

d:VCd

send

M62

Non-AFTN message M62 sent to Centres B, C and D

b: VCb

receive

PM62

M62 packets addressed to Centre B

wait

M62

Wait for complete M62


(Ax for Centres B and C)

CENTRE C
1
2

c: VCc

receive

PM62

M62 packets addressed to Centres B and C

b: VCb

send

PM62

Centre C relays packets addressed to Centre B

wait

PM62

Wait for complete M62

CENTRE D
1
2

d:VCd

receive

PM62

M62 packets addressed to Centres B,C and D

b: VCb

send

PM62

Centre D relays packets addressed to Centres B and C

wait

PM62

Wait for complete M62

Results - Additional
Comments during test
period

END OF PROCEDURE

Appendix D

Sixth Edition
Page 97 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Quadrilateral Tests
Procedure Abstract

Type:
Test Group:
Procedure:

N
1
6

Date of issue: 2003

Purpose: Transmission of a message, not requiring an ACK, from one


Centre to several other Centres when a remote link is out of order.
Page: 1/1

CONFIGURATION DIAGRAM

a: VCa

X b: VCb

d: VCd
c: VCc

Primary routes:

Centres:
Links:

A, B, C, D
a, b, c, d (carrying VCa, VCb, VCc and VCd respectively and possibly other VCs)

Activities:
When link b out of service, a message not requiring an ACK is sent from A to all the other centres. The message is
received at B and D, but B discards the packets for centre C.
Then link b is restored and it is verified that when Centre A re-sends the message it will be delivered at all centres.
Acknowledgements are not received at Centre A.

Appendix D

Sixth Edition
Page 98 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:

N
1
6

Date of issue: 2003

Purpose: Transmission of a message, not requiring an ACK, from one Centre


to several other Centres when a remote link is out of order.
Page 1/1

Step
No.

Ref.
Step
No.
CENTRE A
1
-

Ref.
Centre

Connection

Action

Event

Parameters/Comments

SYNC

Wait for performance of step1 at Centre B

M62

Non-AFTN message sent to Centres B,C and D

wait

M62

Wait for performance of step 4 at Centre B

a: VCa, d:VCd send

M62

Non-AFTN message sent to Centres B,C and D

DISCONNECT LINK b

receive

PM62

M62 packets addressed to Centres B and C


CHECK: that Centre B discards the packets
addressed to Centre C

a: VCa, d:VCd send


-

CENTRE B
1
-

a: VCa

wait

M62

Wait for complete M62

RECONNECT LINK b

a: VCa

receive

P62I

M62 packets addressed to Centres B and C

send

PM62

Centre B relays packets to Centre C

wait

M62

Wait for complete M62

CENTRE C
1
2

SYNC

Check that no message is received at C

SYNC

Wait for completion of step 4 at Centre B

wait

PM62

Reception of M62 packets from Centre A

wait

M62

Wait for complete M62

CENTRE D
1
2

d:VCd

receive

PM62

Reception of M62 from Centre A

wait

M62

Wait for complete M62

d:VCd

receive

PM62

Reception of M62 from Centre C

wait

M62

Wait for complete M62

Results - Additional
Comments during test period

END OF PROCEDURE

Appendix D

Sixth Edition
Page 99 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Quadrilateral Tests
Procedure Abstract

Type:
Test Group:
Procedure:

N
2
1

Purpose:

Date of issue: 2003

Verify whether a relay centre selects alternate route

Page: 1/1

CONFIGURATION DIAGRAM

a: VCa

B
VCe

d: VCd

X b: VCb
C

c: VCc

Primary routes:
Secondary routes

Centres:

A, B, C, D

Links:

a, b, c, d, e (carrying VCa, VCb, VCc, VCd and VCe respectively and possibly other VCs)

Activities:
Centre A sends a message requiring ACK to C in normal conditions. Routing for the message and the corresponding
ACK is checked.
Link b is disconnected, and a new message is sent from A to C. Routing for the message (ABDC) and the
corresponding ACK (CDA) is checked.

Appendix D

Sixth Edition
Page 100 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES


CIDIN Interoperability Testing
Quadrilateral Tests
Procedures
Type:
Test Group:
Procedure:

N
2
1

Purpose:

Date of issue: 2003

Verify whether a relay centre selects alternate route

Page 1/1
Step
No.

Ref.
Step
No.
CENTRE A
1
-

Ref.
Centre

Connection

Action

Event

Parameters/Comments

a: VCa

send

M41

AFTN message is sent to Centre C

a: VCa

receive

ACK

ACK sent from Centre C to Centre A

wait

SYNC

Ensure that link b is out of service

a: VCa

send

M41

Message M41 sent to Centre C

d:VCd

receive

ACK

ACK sent from Centre C to Centre A

CENTRE B
1
1

a: VCa

receive

PM41

Reception of M41 packets addressed to Centre C

b: VCb

send

PM41

Centre B relays packets to Centre C

b: VCb

receive

PACK

ACK sent from Centre C to Centre A

a: VCa

send

PACK

Centre B relays ACK sent from Centre C to Centre A

a: VCa

receive

PM41

Reception of M41 packets addressed to Centre C

e:VCe

send

PM41

Centre B relays packets to Centre C using link e

CENTRE C
1
2

b: VCb

receive

PM41

Reception of message M41 packets

wait

M41

Wait for complete M41

b: VCb

send

ACK

ACK sent from Centre C to Centre A

DISCONNECT LINK b

c: VCc

receive

PM41

Reception of message M41 packets

wait

M41

Wait for complete M41

:VCc

send

ACK

ACK sent from Centre C to Centre A using link c


instead of link b

CENTRE D
1
6

e:VCe

receive

PM41

Reception of M41 packets addressed to Centre C

c: VCc

send

PM41

Centre D relays packets to Centre C

c: VCc

receive

PACK

ACK sent from Centre C to Centre A

d:VCd

send

PACK

Centre D relays ACK sent from Centre C to Centre A

Results - Additional
Comments during test
period

END OF PROCEDURE

END of Appendix D
Appendix D

Sixth Edition
Page 101 of 101

14/04/2011

EUR CIDIN MANUAL APPENDICES

Appendix E Interface Primitives

E.1

Primitives

Primitive
TIMreq

Description
Request for transmission of an
information message

TIM conf

Confirmation of transmission of
an information message

TIMind

Indication of a received
information message

TIMresp

Transmission information
message response
Request for transmission of a
CIDIN packet

Tpreq

TPconf
Tpind

Appendix E

Confirmation of transmission of a
CIDIN packet
Indication of a received packet

Associated Parameters
Interface control information: (a) Exit address vector
Ax whose elements Ax(I), I=1,..n,n<=16, denote the set
of exit centre addresses for the message. (b) For
messages in AFTN format destination address matrix
Ad whose row vectors Ad(I,j), j=1,..m, m<=15, denote
the set of destination addresses reached via the exit
centre Ax(i). (c) Message priority MP. (d) Message
code and format MCF. (e) Network acknowledgement
flag NA.
Interface data: (a) Message content, including. In the
case of a message in AFTN format, the priority
indicator, origin and ending parts. TIMconf (in the case
of messages requiring acknowledgement).
Interface control information: Response vector R
from which a response (ACK or MCF error) has been
received. The boolean element R(i) is true if and only if
a response has been received from the exit centre Ax(i)
Response type vector RT.RT(i)=1,2 means ACK and
MCF error respectively for the exit centre Ax(i),
I=1,n<=16.
Interface control information: (a) Destination address
vector Ad. For messages in AFTN format, Ad denotes
the set of destination addresses reached via the exit
centre address. (b) Message priority MP. (c) Message
code and format MCF.
Interface data: Message content including, in the case
of a message in AFTN format, the priority indicator,
origin and ending parts.
_____
Interface control information: (a) Exit address vector
Ax. (b) Destination address matrix Ad (only in the first
CIDIN packet of messages in AFTN format). (c)
Message priority MP.
Interface data: (a) CIDIN transport header. (b)
segment of information message or ACK, ENQ, ENQ
response or MCF error.
The implementation of a TPconf is a local matter and
not considered further here.
Interface control information: () Destination address
vector Ad of maximum dimension 15 (for messages in
AFTN format). In the case where more than one Ax is
present in an exit centre, the address Ax(s) can be
passed as a parameter as well. (b) Message priority MP.
Interface data: (a) CIDIN transport header. (b)
Sixth Edition
Page 1 of 3

14/04/2011

EUR CIDIN MANUAL APPENDICES

TPresp

E.2

Transmission of packet response

Entry Centre States


State
IDLE
WAIT1
WAIT2

E.3

Description
Inactive but available for transport of an information
message
Waiting for responses after the first transmission of
the message
Waiting for responses after the second transmission of
a message

Entry Centre External Events


Event
TIMreq from TS user
TPind (parameter ACK)
TPind (parameter MCF error
TPind (response to enquiry)

E.4

Description
time-out repeat message
time-out repeat enquiry

Entry Centre Actions


Action
SME
ATMR
TIMconf ACK
TIMconf Ax out of service
ATEM
SENQ

E.6

Description
send a message via the corresponding
Tpreq
activate the timer TMR

activate the ENQ timer


send ENQ via TPreq

Exit Centre States


State
UNASSIGNED
IN_PROCESS

Appendix E

Description

Entry Centre Internal Events


Event
TMR time-out
TEM time-out

E.5

Segment of information message or ACK, ENQ, ENQ


response or MCF error.
_____

Description
inactive but available for receiving an information
message
waiting for a non-first segment of a message

Sixth Edition
Page 2 of 3

14/04/2011

EUR CIDIN MANUAL APPENDICES

E.7

Exit Centre External Events


Event
TPind (FCP = 1)
TPind (FCP = 0)
TPind (ENQ)

E.8

Description

Exit Centre Internal Events


Event
TNMA

E.9

Description
time-out, message assembly

Exit Centre External Actions


Action
TIMind to the TS user
TPreq*1 send ACK or MCF
error
TPreq ENQ send message
response to the ENQ

E.10

Description

Exit Centre Internal Actions


Action
ATNMA
DISCARD the message

Description
activate the timer TNMA

END of Appendix E

Appendix E

Sixth Edition
Page 3 of 3

14/04/2011

EUR CIDIN MANUAL APPENDICES

Appendix F - Guidance on the Implementation of SVCs

F.1

Introduction

F.1.1

As more and more CIDIN Centres migrate in order to use PSN facilities, X.25 SVC usage is being
considered. SVCs offer a more flexible way to connect systems (including these systems that were
previously exchanging data via CIDIN relay); however, in using SVCs, addressing aspects that do
not exist for PVCs need to be addressed. Furthermore, some concern arises regarding security
aspects and a minimum guidance about call management is deemed necessary.

F.2

Purpose and Scope

F.2.1

The purpose of this Appendix is to give initial guidance on issues relating to availability, reliability,
addressing, security and call management, in relation with SVCs in an interconnected X.25 network
environment.

F.3

Network Implementation

F.3.1

Availability

F.3.1.1

To increase service reliability, CIDIN Centres should be connected to the network via two physical
links, preferably belonging to different network switches. In the event of a DCE (PSN end)
disconnection due to a network failure, call re-establishment should be made via the second access.

F.3.1.2

To make this configuration transparent to adjacent CIDIN Centres and thereby optimise network
routing and limit unsuccessful calls, it is recommended that the knowledge of X.25 DTE addresses
be minimised by using the PSN Call Redirection facility or the Hunt Group facility (preferred
operation)1.

F.3.1.3

This should be done in a transparent way that fully utilises SVCs without the need to implement
additional logic. This transparency can be achieved by many PSNs, by performing internal address
translation and stripping of facility fields. The PSN (DCE) at the called DTE side should suppress
the notifications related to the Hunt Group facility or the Call Redirection facility (CLAMN and
CRN) and should perform address translation (in both directions) to an agreed single X.121 address.

F.3.1.4

CIDIN Centres can then be connected with redundancy (multiple links, on-line/stand-by systems)
without the need for adjacent Centres to be aware of these multiple connections, i.e., the remote
CIDIN Centre is known by one X.121 address.

F.3.1.5

The following points provide some information on the way most networks implement address
management.

In some cases even both facilities could be used. In Centres with on-line and stand-by systems the addresses for
the first system could belong to a hunt group and this one could be re-directed to a second hunt
group with the addresses of the second system.

Appendix F

Sixth Edition
Page 1 of 13

14/04/2011

EUR CIDIN MANUAL APPENDICES


-

F.3.1.5.1 Address handling


The network, at port level, performs verification of called and calling addresses, and address insertion
or modification. According to the setting of the option to ignore the local address, the insertion or
modification of a called or calling address is done (in case of CIDIN Centres connected to networks this
option should not be set due to security reasons).


Call Request: A calling address is optional, however, any calling address provided by a DTE must
match that configured in the network (if the option to ignore local address is not subscribed; if set,
the network does not perform any checking of the DTE-provided calling address against that
configured in the network). If the DTE does not provide a calling address, the address configured in
the network is used as the calling address.

Call Accept: It is optional for the called DTE to provide calling and called addresses in a call accept
packet. If the calling address is provided by the called DTE, the address must match that specified
in the corresponding incoming call request packet. If the called DTE does not provide a calling
address, the DCE inserts the calling address from the corresponding incoming call request packet.
The called address from the corresponding incoming call request packet is inserted as the called
address if the called DTE does not provide a called address or if the DTE provides a called address
and the option to ignore the local address is set. If this option is not subscribed and the called DTE
provides a changed called address, a CLAMN is inserted by the DCE if not present. The called
DTE must provide a changed called address if it provides a CLAMN or else the call is cleared.

Call Connect: The DCE passes to the calling DTE the called and calling addresses returned from
the remote DCE.

Clear Request: Called and calling addresses are not allowed in clear packets sent by the calling
DTE. When providing a called address, the called DTE must always specify a CLAMN (if either a
called address or CLAMN is provided by a called DTE, both must be provided). If the called DTE
does not specify a called address and the corresponding incoming call was redirected, the redirected
address and CLAMN are inserted in the clear packet.

Clear Indication generated by the network: Clear packets received by a called and calling DTE
normally contain called and calling addresses of length zero.

F.3.1.5.2 Address suppression


Usually networks are able to remove the called address in all call accept/call connect and clear request
packets and the calling address in all call accept/call connect and call request/incoming call packets (in
case of CIDIN Centres connected to networks this option should not be set due to security reasons).
F.3.1.5.3 Hunt groups
When a DTE calls a Hunt Group, the call is established with a Hunt Group member address. A common
option offered by network is to notify the calling DTE of the successful connection to the Hunt Group
address instead of to the member address. Also, calls from a Hunt Group member can be configured to
signal the Hunt Group address instead of the member address. This option forces the Hunt Group
address over the member address for calls from the network to the Hunt Group, and for calls from the
Hunt Group member towards the network. Calls from the network directly to the Hunt Group member
are unaffected.
F.3.1.5.4 ADDRESS TRANSLATION
Networks allow, as an option at port level, translation of calling and/or called addresses in packets from
and to remote DTEs. If this option is enabled, a call originating on the network will have the calling
and/or called addresses translated and these calling and/or called addresses will be translated back to the
original addresses when the call accept is received from the DTE). A similar mechanism applies to call
originating on the remote DTE.

Appendix F

Sixth Edition
Page 2 of 13

14/04/2011

EUR CIDIN MANUAL APPENDICES

F.3.2

Security

F.3.2.1 Address checking


The X.121 addresses of remote DTEs should be configured. These addresses are needed for:

verification of the Calling DTE Address field in the INCOMING CALL packet. A
non-configured INCOMING CALL should be rejected (CLEAR REQUEST).

the Called DTE Address in the CALL REQUEST packet.

For a given Ax, the above two addresses will normally be the same (by using the facilities described in
point 3.1 above), however systems should be prepared for different addresses. In case of a duplicate
connection using the Hunt Group principle, it may happen that the INCOMING CALL address is either
a port address or the hunt group address.
F.3.2.3 Closed User Group
The International Closed User Group (ICUG) facility can be used by the PSN for security reasons
(bilateral agreement on its usage is required because the facility is excluded in the X.25 PRL as shown
in Appendix G).

F.4

Network Configuration

F.4.1

Description
In this section, a VCG configuration in the context of CIDIN centres connected among them using
PSNs and leased lines is going to be considered, providing finally some advantages in the use of SVCs
as a component of a VCG.
As it has been introduced in the CIDIN Manual, a Virtual Circuit Group (VCG) consists of a number of
Virtual Circuits (VC) that connect two, and only two, CIDIN centres. Also it states that a Primary-type
VC is always present and a Secondary-type VC is optional.
In the case of having CIDIN centres connected to PSNs, it is recommended in a first step that any VCG
consist of the use of a PVC as a Primary-type VC and a single SVC as a Secondary-type VC (in section
4.3 an implementation plan is presented).
Virtual Circuit group (VCG)
Primary VC
PVC

Secondary VC
SVC

In this way, in a normal situation only the PVC of each VCG is established.
If this PVC is detected to be out of order, then a Call establishment procedure is initialised in order to
set up a single SVC (secondary VC) between the CIDIN centres involved.
The SVC is disconnected when one of the following occurs:

Appendix F

The Idle timer elapses. In this case, it is attempted to switch back from the secondary VC
(SVC) to the primary VC (PVC).
The SVC-type CIDIN exchange is disabled by an operator command.
The PVC is re-established (reception of a positive RESET code).

Sixth Edition
Page 3 of 13

14/04/2011

EUR CIDIN MANUAL APPENDICES


As an example Figure F.1 shows different network configurations:

Ax2

Ax3a
Line 4

Line 5

Line 3

Line 6

CR

HG
GW4

GW5

PSN2

PSN3

PVC1

PVC2

GW2
GW1

GW3

PSN1

Line 1

Line 2

Line 8

Line 7
Leased line

Ax4

Ax3b

Ax1

Leased line

PVC4

PVC3

Ax5

Figure F.1 Example of VCG Network Configuration

Appendix F

Sixth Edition
Page 4 of 13

14/04/2011

EUR CIDIN MANUAL APPENDICES


Five CIDIN centres have been considered in the example:
-

CIDIN centre 1 is connected to PSN1 by using two different lines (Line 1 and Line 2). Line 1
supports the PVC1 and a potential SVC and Line 2 supports the PVC2 and a potential SVC.
Besides, there exist one leased line with CIDIN Centre 4 and another leased line with CIDIN Centre
5. CIDIN level 3b has been configured in CIDIN Centre 1 as follows:

> Ax2:
Main Virtual Circuit group VCG(1)
Primary VC
PVC1

Secondary VC
SVC1

Alternate Virtual Circuit group VCG(2)


Primary VC
PVC2

Secondary VC
SVC2

> Ax3:
Main Virtual Circuit group VCG(1)
Primary VC
PVC2

Secondary VC
SVC2

Alternate Virtual Circuit group VCG(2)


Primary VC
PVC1

Secondary VC
SVC1

> Ax4:
Virtual Circuit group VCG(1)
Primary VC

Secondary VC

PVC3
> Ax5:
Virtual Circuit group VCG(1)
Primary VC

Secondary VC

PVC4

Appendix F

Sixth Edition
Page 5 of 13

14/04/2011

EUR CIDIN MANUAL APPENDICES


-

CIDIN centre 2 is connected to PSN2 by using two different lines (Line 3 and Line 4). Line 3
supports the PVC1 and a potential SVC and Line 2 supports a potential SVC.

CIDIN centre 3 is composed of two different systems for redundancy purposes. The first one is
connected to PSN3 by using Line 5 supporting the PVC2 and a potential SVC. The second one is
connected to PSN3 by using Line 6 supporting a potential SVC.

CIDIN centre 4 is connected with CIDIN Centre 1 by using the leased line Line 7.

CIDIN centre 5 is connected with CIDIN Centre 1 by using the leased line Line 8.

F.4.2

Advantages of the use of SVCs


The VCG network configuration proposed above has the following advantages:

F.4.2.1 Network economy.


In the case of CIDIN centres connected to PSN, the use of a SVC per VCG, provides a more efficient
use of the mentioned PSN since network resources are only used when they are required.
That means that SVCs are established only when there exists a real need for interchanging information
between two CIDIN centres. The Idle Timer mechanism has been envisaged for disconnecting the
SVC when there are no messages to be transmitted.
On the other hand, only one PVC per VCG is going to be established between two CIDIN Centres in
normal conditions instead of two or more that there exist in real interconnections.
F.4.2.2 Redundancy
The use of SVCs in CIDIN centres interconnected by PSNs allows the possibility of taking advantage of
network facilities such as the PSN Hunt Group and Call Redirection facilities.
If the PVC becomes out of order, then a Call establishment procedure would be initialised in order to set
up a SVC between the corresponding CIDIN centres. At this step, it is possible to take advantage of the
following:
-

Hunt Groups (HGs).

Call Redirection (CR).

Potential redundancy at the PSN accesses.

Use of different Gateways among PSNs.

Appendix F

Sixth Edition
Page 6 of 13

14/04/2011

EUR CIDIN MANUAL APPENDICES


F.4.2.2.1 Hunt Group
Having a look on Figure F.2, a Hunt Group has been configured on the CIDIN Centre 2 side.

Ax2

Ax3a
Line 4

Ax3b

Line 5

Line 3

Line 6

CR

HG
GW4

GW5

PSN2

PSN3

SVC1d

PVC1

PVC2

SVC1

GW2
GW1

GW3

PSN1

Line 1

Line 2

Line 8

Line 7
Leased line

Ax4

Ax1

Leased line

PVC4

PVC3

Ax5

Figure F.2 Example of redundancy by using Hunt Group facilities


It is possible that any of the PSN ports to which CIDIN Centre 2 is connected is down (for example,
port associated to Line 3). That means that the PVC1 and/or SVC1 becomes out of order (PVC) or
cleared (SVC) and CIDIN Centre 1 initiates a call establishment procedure in order to set up a new SVC
with CIDIN Centre 2, following the CIDIN layer 3B configuration drawn up in the previous section.
In this way, SVC1d will be set up by using another physical connection between CIDIN Centre 2 and
PSN2 (Line 4), in a manner completely transparent to the calling CIDIN Centre.

Appendix F

Sixth Edition
Page 7 of 13

14/04/2011

EUR CIDIN MANUAL APPENDICES


F.4.2.2.2 Call Redirection
Having a look on Figure F.3, a Call Redirection has been configured on the CIDIN Centre 3 side.

Ax2

Ax3a
Line 4

Ax3b

Line 5

Line 3

Line 6

CR

HG
GW4

GW5

PSN2

PSN3
SVC2
SVC2b

PVC1

PVC2

GW2
GW1

GW3

PSN1

Line 1

Line 2

Line 8

Line 7
Leased line

Ax4

Ax1

Leased line

PVC4

PVC3

Ax5

Figure F.3 Example of redundancy by using Call Redirection facilities


It is possible that one of the systems goes down (for example CIDIN Centre 3, on-line system). That
means that the PVC2 and/or SVC2 becomes out of order (PVC) or cleared (SVC) and CIDIN Centre 1
initiates a call establishment procedure in order to configure a new SVC with CIDIN Centre 3,
following the CIDIN layer 3b configuration drawn up in the previous section.
In this way, SVC2b can be set up by using a Call Redirection facility in order to get the other system
(CIDIN Centre 3, stand-by system), in a manner completely transparent to the calling CIDIN Centre.

Appendix F

Sixth Edition
Page 8 of 13

14/04/2011

EUR CIDIN MANUAL APPENDICES


F.4.2.2.3 Potential redundancy at the PSN accesses
Having a look on Figure F.4, at CIDIN Centre 1, in order to access the PSN configuration, it is possible:
-

To force that the SVC uses a specific line.

To have a configuration table where two or more potential PSN access are collected in order to be
used dynamically by the DTE.

Ax2

Ax3a
Line 4

Ax3b

Line 5

Line 3

Line 6

CR

HG
GW4

GW5

PSN2

PSN3

PVC1

PVC2

SVC1

GW2
GW1

GW3

PSN1

SVC1c

Line 1

Line 7
Leased line

Ax4

Line 2

Line 8
Leased line

Ax1

PVC4

PVC3

Ax5

Figure F.4 Example of redundancy by using redundancy at the PSN accesses


In order to improve reliability, the second approach is recommended.
In this way, if Line 1 is going down, then the PVC1 and/or SVC1 becomes out of order and CIDIN
Centre 1 initiates a call establishment procedure in order to set up a new SVC with CIDIN Centre 2,
following the layer 3B configuration drawn up in the previous section.
In this way, SVC1c will be set up by using another physical connection between CIDIN Centre 1 and
PSN1 (Line 2).

Appendix F

Sixth Edition
Page 9 of 13

14/04/2011

EUR CIDIN MANUAL APPENDICES


F.4.2.2.4 Use of different gateways between PSNs
Having a look on Figure F.5, two different gateways have been configured for interconnecting PSN1
and PSN2.

Ax2

Ax3a
Line 4

Line 5

Line 3

Line 6

CR

HG
GW4

GW5

PSN2

PSN3

PVC1

PVC2

SVC1

GW2
GW1

SVC1b

GW3

PSN1

Line 1

Line 2

Line 8

Line 7
Leased line

Ax4

Ax3b

Ax1

Leased line

PVC4

PVC3

Ax5

Figure F.5 Example of redundancy by using different gateways between PSNs


It is possible that any of the above-mentioned gateways is out of service (for example, GW1). That
means that the PVC1 and/or SVC1 are (is) out of service and CIDIN Centre 1 initiates a call
establishment procedure in order to set up a new SVC with CIDIN centre 2, following the L3B
configuration drawn up in the previous section.
In this way, SVC1b will be set up by using another gateway between PSN1 and PSN2 completely
transparent to the calling and called DTE.
F.4.2.3 On-line manipulations
The use of SVC through PSNs allows, as it was described above, the use of X.25 network facilities
(Hunt Group (HG), Call Redirection (CR)) as well as potential redundancy at the PSN accesses and the
use of different Gateways among PSNs.
That means that, in a remote CIDIN centre different activities can be performed without any operational
implication in the adjacent CIDIN centres:
-

Configuration/maintenance activities of X.25 PVCs and/or SVCs.

Configuration/maintenance activities on systems that could conform the remote CIDIN centre.

Appendix F

Sixth Edition
Page 10 of 13

14/04/2011

EUR CIDIN MANUAL APPENDICES

F.4.3

Implementation phases
In the case of having CIDIN centres connected to PSNs, it is recommended to follow the next approach:

1st PHASE: Any VCG consists of a PVC as a Primary-type VC and a single SVC as a
Secondary-type VC.

This has been the Network Configuration recommended previously. The VCG would be as follows:
Virtual Circuit group (VCG)
Primary VC

Secondary VC

PVC

SVC

2nd PHASE: Use of a single SVC as a Primary-type VC.

Once SVCs are widely configured and used by CIDIN centres and the Operational staff is confident
about their use, it is proposed to go into this second phase, that consists of:
Virtual Circuit group (VCG)
Primary VC

Secondary VC

SVC
In this way, in a normal situation only one SVC per VCG would be established between two adjacent
CIDIN centres, taking the maximum advantage of the features of X.25 SVCs.

F.5

SVC Set-up and Clearing

F.5.1

Timers

F.5.1.1 The Idle Timer


The Idle timer must be configured to be:
-

triggered when the transmission of all the data have been achieved,

stopped when the data transmission is resumed.

When the Idle timer elapses, the SVC shall be disconnected by sending a Clear request to the network
with the Clearing cause set to 00 (DTE originated).
A specific value must be configured to indicate that the timer is set to an infinite value, which leads to
not clearing the SVC.
Note.-: This value is called infinite long in the paragraph 4.1.13.1.6.
The Idle timer must be configurable per SVC, taking into account traffic requirements.
The length of the idle period is a configurable parameter. The minimum value should be 2*TMR +
TEM + T21 (X.25 DTE Call Request Response Timer) seconds. The value should be chosen so that an
optimum is achieved in minimising overhead caused by CLEAR/CALL REQUEST procedures and
avoiding unnecessary allocation of PSN resources.
F.5.1.2 The Call retry timer
The Call retry timer must be:

Appendix F

Triggered when a Call request is sent,

stopped when a Call connected is received originated by the Remote CIDIN Centre.

Sixth Edition
Page 11 of 13

14/04/2011

EUR CIDIN MANUAL APPENDICES


Note 1.- The Call retry timer plays its role particularly in the case of CIDIN Crossing call avoidance.
Note 2.- Though the Call retry timer is triggered by the same event as the T21 timer and the action
entailed is similar (generation of a Clear request), they are not managed by the same level.
The T21 timer value should be higher than the Call retry timer value.

F.5.2

Particularities of alarms

F.5.2.1 Two types of alarms can be distinguished:


-

The technical alarms with a detail information intended to specialist operators for investigation
purpose. These alarms should be streamed and saved in log files,

The operator alarms with a synthetic information such as: CIDIN SVC <svc name> connected or
CIDIN SVC <svc name> disconnected. These alarms should be real-time displayed or printed on
administration devices.

F.5.2.2 When a SVC is established:


-

an explicit information message should be generated indicating the context (e.g.: SVC
established),

an explicit and appropriate operator alarm should indicate: CIDIN SVC <svc name> connected.

F.5.2.3 In case of a Clear SVC due to a Call retry timer expiration, an explicit and an appropriate information
message should be generated indicating precisely the context (e.g.: Call retry timer elapsed). Because
of possible multiple and numerous attempts to re-establish a SVC, the number of times this information
is generated should be configurable to prevent the information support from being overloaded.
F.5.2.4 When a Call is Cleared by the network, an explicit and appropriate information message should be
generated indicating precisely the default (e.g.: Outgoing call cleared).
F.5.2.5 When it appends a CIDIN crossing call an explicit and appropriate information message should be
generated indicating precisely the context (e.g.: Incoming call refused: collision on CIDIN SVC <svc
name>).
F.5.2.6 When an incoming call is accepted:
-

An explicit and appropriate information message should be generated indicating precisely the
context (e.g.:
Incoming call accepted).

An explicit and appropriate operator alarm should indicate: CIDIN SVC <svc name> connected.

F.5.2.7 For three cases concerning an incoming call refused an explicit and appropriate information message
should be generated indicating precisely the context, which could be respectively:
-

Incoming call refused: unknown calling remote centre <name>,

Incoming call refused: <svc name> already connected,

Incoming call refused: collision on CIDIN SVC <svc name>

F.5.2.8 When the Idle timer elapses:


-

An explicit and appropriate information message should be generated indicating precisely the
context (e.g.: Idle timer elapses for CIDIN SVC <svc name>).

An explicit and appropriate operator alarm should indicate: CIDIN SVC <svc name> disconnected.

F.5.2.9 When a SVC-type CIDIN exchange is disabled by an operator command:


-

Appendix F

An explicit and appropriate information message should be generated indicating precisely the
context (e.g.: Invalidation of CIDIN SVC <svc name>).
Sixth Edition
Page 12 of 13

14/04/2011

EUR CIDIN MANUAL APPENDICES


-

An explicit and appropriate operator alarm should indicate: CIDIN SVC <svc name> disconnected.

F.5.2.10 When a closed SVC is validated by an operator command an explicit and appropriate information
message should be generated indicating precisely the context (e.g.: Validation of CIDIN SVC <svc
name>).
F.5.2.11 When a Clear indication is received:
-

An appropriate information message should be generated indicating precisely the default (e.g.:
Incoming clear indication for CIDIN svc <svc name>).

An explicit and appropriate operator alarm should indicate: CIDIN SVC <svc name> disconnected.

F.5.2.12 If the Calling address is not suitable, an explicit and appropriate information message should be
generated indicating precisely the default (e.g.: Incoming call address not allowed the svc <svc
name>).

F.5.3

Call re-establishment periodicity


The periodicity to attempt to re-establish the call should depend on a configurable timer and a
configurable number.

F.5.4

Specific diagnostic values for Clear packets


Different errors may lead to the generation of a CLEAR REQUEST packet by the Local CIDIN Centre
ports with the clearing cause code equal to 00and an appropriate clearing diagnostic code.
The recommended values for clearing diagnostic codes to be used in the CIDIN environment are
derived from the ISO 8208 standards
The clearing diagnostic codes that should be generated for a CLEAR REQUEST packet with clearing
cause code 00, are described in the following table:
Corresponding ISO 8208
origin reason

Decimal
value

Higher Level Initiated:


disconnection normal

Hex-decimal
value

CIDIN origin reason

F1

241

Operator disconnection

Higher level Initiated


Disconnection abnormal

Higher level Initiated:


Connection
rejection,
reason
unspecified
(permanent condition)

242

F2

242
245

F2
F5

Table F-1:
Note:

idle timer elapses (no message to


transmit)
Unknown Calling Address
Reception of an Interrupt packet.
Retry Timer elapses.
Already connected.

CLEAR Diagnostic Codes

The values listed in the table above are used to inform the operators.
No automatic action depending on CLEAR DIAGNOSTIC CODES are foreseen.

END of Appendix F

Appendix F

Sixth Edition
Page 13 of 13

14/04/2011

EUR CIDIN MANUAL APPENDICES

Appendix G X.25 PICS/PRL


This Appendix provides the PICS/PRL for the X.25 level 3 (CIDIN Network Layer 3a) profile for PVCs
and SVCs.
The requirements for the lower layers (Data Link Layer and Physical Layer) are laid down in the Annex
10.

G.1

Definitions

Profile:

A set of one or more base standards, and, where applicable, the


identification of chosen classes, subsets, options and parameters of those
base standards, necessary for accomplishing a particular function.

Profile Requirements
List (PRL):

The profile requirements are expressed in the form of conformance


requirements and are arranged in a tabular list format.

Protocol Implementation
Conformance
Statement
(PICS):

A statement denoting which capabilities have been implemented for a


protocol.

G.1.1

ITU-T and OSI X.25 Standards


In 1976 the International Consultative Committee recommended X.25 as the desired protocol for
Telegraphy and Telephony (CCITT). X.25 is a packet switched data network protocol which defines an
international recommendation for the exchange of data as well as control information between a user
device (host), called Data Terminal Equipment (DTE) and a network node, called Data Circuit
Terminating Equipment (DCE). X.25 utilises a Connection-Oriented service, which insures that packets
are transmitted in order.
The following standards were produced:





CCITT X.25 1976 (Orange Book)


CCITT X.25 1980 (Yellow Book)
CCITT X.25 1984 (Red Book)
CCITT X.25 1988 (Blue Book)

Since 1993 the CCITT is renamed into ITU-T (International Telecommunication Union). The most
recent ITU-T Recommendation X.25 (10/96) was revised by the ITU-T Study Group 7 and was
approved by the WTSC2 (05.10.96).
The matching OSI X.25 standard, which is the base standard for the CIDIN X.25 PRL, is:


ISO/IEC 8208:1993, Information Technology Data communications X.25 Packet Layer


Protocol for Data Terminal Equipment (3rd edition).

The initial ISO/IEC International Standard was based on the CCITT Red Book. Subsequent editions
also followed CCITT/ITU-T standards. The ISO/IEC 8208 and ITU X.25 are different in scope. The
CCITT/ITU-T specification specifies the behaviour of the DCE and a minimum set of requirements is
specified for the DTE. The OSI specification focus is on the DTE and interworking between DTEs
(including direct DTE-to-DTE) and contains additional guidance for DTEs.

World Telecommunication Standardization Conference.

Appendix G

Sixth Edition
Page 1 of 15

14/04/2011

EUR CIDIN MANUAL APPENDICES

G.1.2

Usage and explanation


By mandating a X.25 profile for CIDIN using a PRL the interoperability on X.25 level with X.25
networks and between CIDIN Centres using different X.25 versions as well can be guaranteed.
To evaluate conformance of a particular implementation, it is necessary to have a statement of which
capabilities and options have been implemented. Such a statement is called a PICS. This statement is
normally made by the supplier of the system.
New implementations in a Centre shall be validated against the PRL and a PICS shall be completed.
Deviations from the PRL shall be agreed on a bilateral basis only3.

G.1.3

Notation
The following notations from ISO/IEC TR 10000-1 are used in the PRL to indicate the status of
features:
m:

mandatory

o:

optional

O.<n>

optional, but support of at least one of the group of options labelled by the
same numeral <n> is required

not applicable (i.e. logically impossible in the scope of the profile)

x:

excluded

Notes.1) Two-character combinations may be used, in which case the first character refers to the static
(implementation) status, and the second to the dynamic (use); thus 'mo' means 'mandatory to
be implemented, optional to be used'.
2) The 'o.<n>' notation is used to show a set of selectable options (i.e. at least one of the set must
be implemented) with the same identifier n.
3) A feature marked 'x' may nonetheless be part of an implementation so long as it is not used
when the implementation is operating in conformance with the profile.
4) Use of features marked 'x' would require bilateral agreement. In this event, the status of the
features should be revised as they may be of interest to other implementations.
The following predicate notation is used:
<predicate>:
<predicate>:

introduces a group of items, all of which are conditional on <predicate> (the extent of
the group is shown by the layout).
introduces a single item which is conditional on <predicate>.

Note. - In each case, the predicate may be the identifier of a profile feature, or a Boolean combination
of predicates ('' is the symbol for logical negation).
Base standard requirements are shown using the equivalent notations in upper case (i.e. M, O, O.<n>,
X).

G.1.4

References
This profile references the following protocol specifications:

It shall be assured that such deviations do not have influence on the communication with other partners
(especially in the area of SVCs certain parameters are system wide).

Appendix G

Sixth Edition
Page 2 of 15

14/04/2011

EUR CIDIN MANUAL APPENDICES

G.2

EUR CIDIN Manual Second Edition (August 2002)


Connection-mode Network Protocol using ISO/IEC 8208.

Conformance Statement
Table G-1:

Conformance Overview

Supplier
Contact point for queries about the PICS
Implementation name/version
Machine name/version
Operating system name/version
Other hardware and operating systems claimed
System name (if applicable)
Date of statement
Have the features of the base standards been
implemented in accordance with requirements
of this PRL?

Yes o

NOTE. - Failure to respond 'Yes' to all of these questions indicates a failure of conformance to this
profile

G.3

Network Layer Requirements


The PRLs given in this section are based on the PICS proforma for ISO/IEC 8208:1993 (Annex B). The
entries in the 'References' column under 'Base standard features' of the following tables are references to
clauses in that standard.

Appendix G

Sixth Edition
Page 3 of 15

14/04/2011

EUR CIDIN MANUAL APPENDICES

G.4

General DTE Characteristics


Table G-2:

General DTE Characteristics

ISO/IEC 8208:1993
Base Standard Features
Item
General DTE Characteristics
Service supported
Vs
virtual call
Vp
permanent virtual circuit

References

Status

EUR CIDIN Manual


Profile Features
References
Status

O.1
O.1

4.1
4.1

m
m

O.2

1.3,
4.1.1.2,
4.1.1.4,
4.2.1.6
1.3,
4.1.1.2,
4.1.1.4,
4.2.1.6
1.3,
4.1.1.2,
4.1.1.4,
4.2.1.6
1.3,
4.1.1.2,
4.1.1.4,
4.2.1.6
1.3,
4.1.1.2,
4.1.1.4,
4.2.1.6
1.3,
4.1.1.2,
4.1.1.4,
4.2.1.6

o.2

Ec/3

Environments supported
DTE/DCE(1993)

Ec/8

DTE/DCE(1988)

O.2

Ec/4

DTE/DCE(1984)

O.2

Ec/0

DTE/DCE(1980)

O.2

Et/t

DTE/DTE in fixed role as DTE

O.2

Et/c

DTE/DTE in fixed role as DCE

Vs: O.2

Et/d

DTE/DTE with dynamic role selection

M8

Packet sequence numbering supported


Modulo 8

M128

Rna

Reference Number optional user facility


supported, for alternative Logical Channel
Identifier assignment
- without reversion to use of logical
channel ranges
-with possible reversion to use logical
channel ranges

RNb

Appendix G

3, 3.2

Modulo 128

o.2

o.2

o.2

o.2

o.2

4.5

Vs: O.2

13.2,
12.1.1,
Table 3
13.2,
12.1.1,
Table 3
13.29, 13.29.1,
13.29.2, 13.29.3,
13.29.4, Fig 31
13.29.2.1

O.3

O.3

Et: O
Et: X
Et: O
Et: X

13.29.2.1

Sixth Edition
Page 4 of 15

14/04/2011

EUR CIDIN MANUAL APPENDICES

G.5

Procedures, Packet Types and Packet Formats.


Table G-3:

Packet Layer Functions Independent of Logical Channels

ISO/IEC 8208:1993
Base Standard Features
Item
Packet Layer Functions Independent of Logical
Channels

Z2s

Are the following packet layer functions


supported:
Sending diagnostic packet

Z4i

Initiating On-line Facility Registration:


-

Z4r

send REGISTRATION REQUEST


receive REGISTRATION
CONFIRMATION
Responding to On-line Facility Registration:
receive REGISTRATION REQUEST
send REGISTRATION
CONFIRMATION

Appendix G

EUR CIDIN Manual


Profile Features
References
Status

References

Status

12.7, Table 24

Et: O
Et: X
O

ox

Et: O

13.1,
13.1.1.1,
13.1.1.3, 13.1.1.4
12.9.1
12.9.2, Table 10
13.1,
13.1.1.1,
13.1.1.4
12.9.1
12.9.2, Table 10

Sixth Edition
Page 5 of 15

14/04/2011

EUR CIDIN MANUAL APPENDICES


Table G-4:
ISO/IEC 8208:1993
Base Standard Features
Item
Call Setup
Are outgoing Virtual Calls supported:
S1a
S1b
S1c
SP1b

- Fast Select, no restriction on response?


- Fast Select with restricted response?
- non-Fast Select?
CALL REQUEST, basic format

SP1e

send CALL REQUEST, extended format

SP2b
SP2e

receive CALL CONNECTED, basic format


receive CALL CONNECTED, extended
format
Is alternative addressing supported for
outgoing Virtual Calls:
- using A = 1 and expanded Address
Block format?
- using the Called Address Extension
Facility?
Are incoming Virtual Calls supported:

S2a
S2b
S2c

SP4b

- Fast Select with acceptance possible?


- Fast Select, always cleared?
- non-Fast Select with acceptance
possible?
- non-Fast Select, always cleared?
receive INCOMING CALL, basic format
receive INCOMING CALL, extended
format
send CALL ACCEPTED, basic format

SP4e

send CALL ACCEPTED, extended format

DN1
DN2

Is D-bit negotiation supported:


- for outgoing Virtual Calls
- for incoming Virtual Calls

S2d
SP3b
SP3e

Call Setup

References
5.2.1,
5.2.5,
Table 33
5.2.4, 13.16
13.16
5.2.4
12.2.3.1
12.2.3.1,
12.2.3.2
12.2.4.1
12.2.4.1,
12.2.4.2
13.28
13.28.2.1,
12.2.1.2
13.28.2.2.

Status

O
O
O
S1c: M
S1ab: O.4
S1ab: O.4
S1ac: M
S1a: M

EUR CIDIN Manual


Profile Features
References Status

4.2.7

x
4.2.7

Ec/3: O
Ec/3: X
Ec/3: O
Ec/3: X

O
O
O

m
m
x
m

12.2.4.1,
12.2.4.2

O
S2: M
S2ab: M
S2axc: O.5
S2c: M
S2axc: O.5
S2axc: O.5
S2anc: O

6.3
6.3

S1ac: O
S1ac: O

5.2.2, 5.2.5,
Table 33
5.2.3, 13.17
13.17
5.2.3
5.2.3
12.2.3.1
12.2.3.1,
12.2.3.2
12.2.4.1

4.2.7

Sixth Edition
Page 6 of 15

x
x

Note. - The D-bit shall always be negotiated to 0.

Appendix G

x
x
m
m

14/04/2011

EUR CIDIN MANUAL APPENDICES


Table G-5:
ISO/IEC 8208:1993
Base Standard Features
Item
Call Clearing

Call Clearing

References

Status

EUR CIDIN Manual


Profile Features
References
Status

Is call clearing supported, for:


- response to indication of clearing
- aborting an outgoing Virtual Call attempt?
- rejecting an incoming Virtual Call?

5.5.4, Table 33
5.5.2
5.4, 5.5.1, 5.5.3
5.3, 5.5.1, 5.5.3

5.5.1, 5.5.3
12.2.5.1
12.2.5.1, 12.2.5.2

Cany: M
Cany: M

4.2.2.3

12.2.6.1
12.2.6.1, 12.2.6.2

C1: M
C1rn: M

4.2.2.3

m
x

CP3b

- originating clearing of an established


Virtual Call?
receive CLEAR INDICATION, basic format
receive CLEAR INDICATION, extended
format
send CLEAR CONFIRMATION, basic format
send CLEAR CONFIRMATION, extended
format
send CLEAR REQUEST, basic format

O
S1: O
S2bd: M
S2acxbd:
O
O

12.2.5.1

4.2.2.3

CP3e

send CLEAR REQUEST, extended format

12.2.5.1 12.2.5.2

CP4b

receive CLEAR CONFIRMATION, basic


format
receive CLEAR CONFIRMATION, extended
format

12.2.6.1

C2a: M
C2bcxa:
O.6
C2bcxa:
O.6
C2axbc: X
C2: M

12.2.6.1, 12.2.6.2

C2rnci: M

C1
C2a
C2b

C2c
CP1b
CP1e
CP2b
CP2e

CP4e

Table G-6:
ISO/IEC 8208:1993
Base Standard Features
Item
Resetting of Logical Channels
RSi

RSr

Is resetting supported:
as initiator?
send RESET REQUEST
receive RESET CONFIRMATION/
INDICATION
as responder?
receive RESET INDICATION
send RESET CONFIRMATION

Appendix G

m
o
m

4.2.2.3

Resetting of Logical Channels

References
8, 8.4, Table 34
8.1, 8.3
12.5.1
12.5.2, 12.5.1
8.2
12.5.1
12.5.2

Sixth Edition
Page 7 of 15

Status

EUR CIDIN Manual


Profile Features
References
Status

4.1.2, 4.1.7

mm

4.1.2, 4.1.7

mm

14/04/2011

EUR CIDIN MANUAL APPENDICES


Table G-7:
ISO/IEC 8208:1993
Base Standard Features
Item
Error Procedures (Virtual Call Service)

References
5.2.1, 5.4, 8.1,
Table 33

Is ERROR-C procedure:
W1a
W1b

clear the Virtual Call?


restart the packet layer?

Is ERROR-R procedure for virtual calls:

W2sc

restart the packet layer?

ISO/IEC 8208:1993
Base Standard Features
Item
Interrupt Transfer
Is
Is sending interrupts supported?
send INTERRUPT REQUEST
receive INTERRUPT CONFIRMATION
Is receiving interrupts supported?
receive INTERRUPT INDICATION
send INTERRUPT CONFIRMATION

Table G-9:
ISO/IEC 8208:1993
Base Standard Features
Item
Sending Data
DS1
Is sending of DATA packets supported?

DS2
DS4a
DS4b
DS5a
DS5b
DS6

DS7a
DS7b
DS8

Are the following supported:


- send-window rotation on receiving updated
P(R) values?
- sending M = 0 in DATA packets?
- sending M = 1 in DATA packets?
- sending Q = 0 in DATA packets?
- sending Q = 1 in DATA packets?
- responding to packet retransmission requests
(received
REJECT packets)?
- Window Rotation Timer procedure?
- ERROR-R action on expiry
- packet retransmission on expiry
- discard of over-length flow control packets
(instead of ERROR-R)?

Appendix G

Status

EUR CIDIN Manual


Profile Features
References
Status

O.7
O.7

m
x

O.8

6.3, 6.4, 6.6,


6.8.1,
6.8.2,
7.1.3, 7.1.4, 8.2,
11.2.1,
13.4.1,
Tables 34-36

Table G-8:

Ir

Error Procedures

Interrupt Transfer

References
6.8, 6.8.1, 6.8.3,
Table 35
12.3.2
12.3.3
6.8, 6.8.2, 6.8.3
Table 35
12.3.2
12.3.3

Status
O

EUR CIDIN Manual


Profile Features
References
Status
ox

Sending Data

References
6, 6.1, 7.1.1,
7.1.2,
7.1.3,
12.3.1

Status
O

7.1, 7.1.2, 7.1.3

6.4, 6.5, 6.7


6.4, 6.5, 6.7
6.6
6.6
13.4.2 12.8

M
O
O.10
O.10
Et: O

11.2.1(a)
11.2.1(b)

O
Et: O
Et: X
O

Table 36 Note 2

Sixth Edition
Page 8 of 15

EUR CIDIN Manual


Profile Features
References
Status
mm

mm
4.1.2.3 c
4.1.2.3 c

mm
x
mm
ox

ox
ox
ox

14/04/2011

EUR CIDIN MANUAL APPENDICES


Table G-10: Receiving Data
ISO/IEC 8208:1993
Base Standard Features
Item
Receiving Data
DR1
Is receiving of DATA packets supported?

DR2

DR3

DR4b
DR5a
DR5b
DR6

DR7a
DR7b
DR7c

DR8a
DR8b
DR8c
DR9

Are the following supported:


- receive-window rotation by sending
updated P(R)
values?
- flow control by sending RECEIVE NOT
READY
and RECEIVE READY?
- receiving M = 1 in DATA packets?
- receiving Q = 0 in DATA packets?
- receiving Q = 1 in DATA packets?
- requesting packet retransmission by sending
REJECT packets?
- recovery from receipt of DATA packets
containing invalid P(S), by:
- ERROR-R action?
- requesting packet retransmission ?
- ignoring the packet and waiting for a correct
retransmitted packet?
- recovery from receipt of DATA packets
with
invalid User Data field, by:
- ERROR-R action?
- requesting packet retransmission?
- ignoring the packet and waiting for a correct
retransmitted packet?
- Window Status Transmission Timer
procedure?

EUR CIDIN Manual


Profile Features
References
Status
mm

References
6, 6.1, 6.2, 7.1.1,
7.1.2,
7.1.3,
12.3.1

Status
O

7.1.2, 7.1.3

mm

7.1.5,
7.1.6,
12.4.1, 12.4.2

mm

6.4, 6.5, 6.7


6.6
6.6
13.4.1, 12.8

O
O.11
O.11
O

11.3(a)
11.3(b)
11.3(c)

O.12
O.12
O.12

mm
ox
ox

11.3(a)
11.3(b)
11.3(c)

O.13
O.13
O.13

mm
ox
ox

11.2.2

ox

4.1.2.3 c

ox
mm

ox

Table G-11: Delivery Confirmation


ISO/IEC 8208:1993
Base Standard Features
Item
Delivery Confirmation
DC
Is Delivery Confirmation supported?

Appendix G

References
6.3, 6.5,
7.1.4

Sixth Edition
Page 9 of 15

6.7,

Status
O

EUR CIDIN Manual


Profile Features
References
Status
x

14/04/2011

EUR CIDIN MANUAL APPENDICES

G.6

Miscellaneous Features and Options


Table G-12: Values of Cause and Diagnostic Codes

ISO/IEC 8208:1993
Base Standard Features
Item
Values of Cause and Diagnostic Codes
In RESTART REQUEST packets sent:

Y1d

Y2b

Y3d

Y4b

Y5d

Y6b

References
12.6.1.1,
12.6.1.2,
Tables 24-25

- Cause = 128, private diagnostic codes


In RESTART INDICATION packets received:
- Cause not 0 or 128, any diagnostic code
value
In CLEAR REQUEST packets sent:

- Cause = 128, private diagnostic codes


In CLEAR INDICATION packets received:
- Cause not 0 or 128, any diagnostic code
value
In RESET REQUEST packets sent:

- Cause = 128, private diagnostic codes


In RESET INDICATION packets received:

O.14

ox

EC: M
EC: O

O.15

ox

EC: M
EC: O

O.16

ox

EC: M
EC: O

12.6.1.1, Table 9,
12.6.1.2

12.2.3.1.1,
12.2.3.1.2,
Tables 24-25
12.2.3.1.1, Table
7 12.2.3.1.2,

12.5.1.1,
12.5.1.2,
Tables 24-25
12.5.1.1, Table 8,
12.5.1.2

- Cause not 0 or 128, any diagnostic code


value

Appendix G

Status

EUR CIDIN Manual


Profile Features
References
Status

Sixth Edition
Page 10 of 15

14/04/2011

EUR CIDIN MANUAL APPENDICES

G.7

Facilities
Table G-13: Facilities Sent in CALL REQUEST Packets

ISO/IEC 8208:1993
Base Standard Features
Item
Facilities Sent in CALL REQUEST Packets
FS1pi
Flow Control Parameter Negotiation, packet
size
FS1wi
Flow Control Parameter Negotiation, window
size
FS2ib
Basic Throughput Class Negotiation
FS2ie

Extended Throughput Class Negotiation

FS3b

Closed User Group Selection, basic format

FS3e

FS5
FS6a
FS6b
FS6c

Closed User Group Selection, extended


format
Closed User Group With Outgoing Access
Selection, basic format
Closed User Group With Outgoing Access
Selection, extended format
Bilateral Closed User Group Selection
Fast Select
Reverse Charging
ICRD Status Selection

FS7i

Network User Identification

FS8i
FS9b

Charging Information, requesting service


RPOA selection, basic format

FS9e

RPOA selection, extended format

FS12
FS99i

Transit Delay Selection and Indication


Local non-X.25 facilities, following Facility
Marker
Remote non-X.25 facilities, following
Facility Marker
Facility Marker, CCITT-specified DTE
facilities
Calling Address Extension
Called Address Extension
Minimum Throughput Class Negotiation,
basic format
Minimum Throughput Class Negotiation,
extended format
End-to-end Transit Delay Negotiation
Expedited Data Negotiation
Priority
Protection

FS4b
FS4e

FS98i
FS20i
FS21i
FS22i
FS23ib
FS23ie
FS24i
FS25i
FS26i
FS27i

Appendix G

EUR CIDIN Manual


Profile Features
References
Status
x

References
13.12, 15.2.2.1.1

Status
O

13.12, 15.2.2.1.2

13.13, 15.2.2.2.1,
Table 20a
13.13, 15.2.2.2.2,
Table 20b
13.14.6,
15.2.2.3.1
13.14.6,
15.2.2.3.2
13.14.7,
15.2.2.4.1
13.14.7,
15.2.2.4.2
13.15, 15.2.2.5
13.16, 15.2.2.6
13.18, 15.2.2.6
13.25.4.2,
15.2.2.6
13.21, 13.21.3,
15.2.2.7
13.22, 15.2.2.8.1
13.23, 13.23.2,
15.2.2.9.1
13.23, 13.23.2,
15.2.2.9.2
13.27, 15.2.2.13
15.1, Table 18

O
O
O
O

x
x
x
x

O
O

x
x

O
O

x
x

15.1, Table 18

15.1

x
x
x

O
O
O
O

x
x
x
x

14.1, 15.3.2.1
14.2, 15.3.2.2
14.3, 15.3.2.3.1,
Table 20a
14.3, 15.3.2.3.2,
Table 20b
14.4, 15.3.2.4
14.7, 15.3.2.7
14.5, 15.3.2.5
14.6, 15.3.2.6

Sixth Edition
Page 11 of 15

14/04/2011

EUR CIDIN MANUAL APPENDICES


Table G-14: Facilities Sent in CALL ACCEPT Packets
ISO/IEC 8208:1993
Base Standard Features
Item
Facilities Sent in CALL ACCEPT Packets
FS1pr
Flow Control Parameter Negotiation, packet
size
FS1wr Flow Control Parameter Negotiation, window
size
FS2rb
Basic Throughput Class Negotiation
FS2re

Extended Throughput Class Negotiation

FS7r

Network User Identification

FS8r
FS10r
FS99r

Charging Information, requesting service


Called Line Address Modified Notification
Local non-X.25 facilities, following Facility
Marker
Remote non-X.25 facilities, following
Facility Marker
Facility Marker, CCITT-specified DTE
facilities
Called Address Extension
End-to-end Transit Delay Negotiation
Expedited Data Negotiation
Priority
Protection

FS98r
FS20r
FS22r
FS24r
FS25r
FS26r
FS27r

References
13.12, 15.2.2.1.1,
Table 13
13.12, 15.2.2.1.2,
Table 13
13.13, 15.2.2.2.1,
Table 20a
13.13, 15.2.2.2.2,
Table 20b
13.21,
13.21.3
15.2.2.7
13.22, 15.2.2.8.1
13.26, 15.2.2.12
15.1 Table 18

Status
O

EUR CIDIN Manual


Profile Features
References
Status
x

O
O
O

x
x
x

15.1, Table 18

15.1

14.2, 15.3.2.2
14.4, 15.3.2.4
14.7, 15.3.2.7
14.5, 15.3.2.5
14.6, 15.3.2.6

O
O
O
O
O

x
x
x
x
x

Table G-15: Facilities Sent in CALL REQUEST Packets


ISO/IEC 8208:1993
Base Standard Features
Item
Facilities Sent in CALL REQUEST Packets
FS10d
Called Line Address Modified Notification
FS13
Call Deflection Selection
FS99d
FS98d
FS20d
FS22d

Appendix G

Local non-X.25 facilities, following Facility


Marker
Remote non-X.25 facilities, following
Facility Marker
Facility Marker, CCITT-specified DTE
facilities
Called Address Extension

EUR CIDIN Manual


Profile Features
References
Status
x
x

References
13.26, 15.2.2.12
13.25.2.2,
15.2.2.10
15.1, Table 18

Status
O
O
O

15.1, Table 18

15.1

14.2, 15.3.2.2

Sixth Edition
Page 12 of 15

14/04/2011

EUR CIDIN MANUAL APPENDICES


Table G-16: Facilities Received in INCOMING CALL Packets
ISO/IEC 8208:1993
Base Standard Features
Item
Facilities Received in INCOMING CALL
Packets
FR1pi
Flow Control Parameter Negotiation, packet
size
FR1wi
Flow Control Parameter Negotiation, window
size
FR2ib
Basic Throughput Class Negotiation
FR2ie

Extended Throughput Class Negotiation

FR3b

Closed User Group Selection, basic format

FR3e

FR5
FR6a

Closed User Group Selection, extended


format
Closed User Group With Outgoing Access
Selection, basic format
Closed User Group With Outgoing Access
Selection, extended format
Bilateral Closed User Group Selection
Fast Select

FR6b

Reverse Charging

FR11

Call Redirection or Call Deflection


Notification
Transit Delay Selection and Indication
Local non-X.25 facilities, following Facility
Marker
Facility Marker, CCITT-specified DTE
facilities
Calling Address Extension
Called Address Extension
Minimum Throughput Class Negotiation,
basic format
Minimum Throughput Class Negotiation,
extended format
End-to-end Transit Delay Negotiation
Expedited Data Negotiation
Priority
Protection

FR4b
FR4e

FR12i
FR99i
FR20i
FR21
FR22i
FR23b
FR23e
FR24i
FR25i
FR26i
FR27i

Appendix G

EUR CIDIN Manual


Profile Features
References
Status

References

Status

13.12, 15.2.2.1.1

13.12, 15.2.2.1.2

13.13, 15.2.2.2.1
Table 20a
13.13, 15.2.2.2.2
Table 20b
13.14.6,
15.2.2.3.1
13.14.6,
15.2.2.3.2
13.4.7, 15.2.2.4.1

13.4.7, 15.2.2.4.2

13.15, 15.2.2.5
13.16,
13.17,
15.2.2.6
13.18,
13.19,
15.2.2.6
13.25.3,
15.2.2.11
13.27, 15.2.2.13
15.1, Table 18

O
O

x
x

O
O

x
x

15.1

x
x
x

O
O
O
O

x
x
x
x

14.1, 15.3.2.1
14.2, 15.3.2.2
14.3, 15.3.2.3.1,
Table 20a
14.3, 15.3.2.3.2,
Table 20b
14.4, 15.3.2.4
14.7, 15.3.2.7
14.5, 15.3.2.5
14.6, 15.3.2.6

Sixth Edition
Page 13 of 15

14/04/2011

EUR CIDIN MANUAL APPENDICES


Table G-17: Facilities Received in CALL CONNECT Packets
ISO/IEC 8208:1993
Base Standard Features
Item
Facilities Received in CALL CONNECT
Packets
FR1pr
Flow Control Parameter Negotiation, packet
size
FR1wr Flow Control Parameter Negotiation, window
size
FR2rb
Basic Throughput Class Negotiation
FR2re

Extended Throughput Class Negotiation

FR10r
FR12r
FR99r

Called Line Address Modified Notification


Transit Delay Selection and Indication
Local non-X.25 facilities, following Facility
Marker
Facility Marker, CCITT-specified DTE
facilities
Called Address Extension
End-to-end Transit Delay Negotiation
Expedited Data Negotiation
Priority
Protection

FR20r
FR22r
FR24r
FR25r
FR26r
FR27r

EUR CIDIN Manual


Profile Features
References
Status

References

Status

13.12, 15.2.2.1.1,
Table 14
13.12, 15.2.2.1.2,
Table 14
13.13, 15.2.2.2.1,
Table 20a
13.13, 15.2.2.2.2,
Table 20b
13.26, 15.2.2.12
13.27, 15.2.2.13
15.1, Table 18

O
O
O

x
x
x

15.1

14.2, 15.3.2.2
14.4, 15.3.2.4
14.7, 15.3.2.7
14.5, 15.3.2.5
14.6, 15.3.2.6

O
O
O
O
O

x
x
x
x
x

Table G-18: Facilities Received in CLEAR INDICATION Packets


ISO/IEC 8208:1993
Base Standard Features
Item
Facilities Received in CLEAR INDICATION
Packets
FR8ad
Charging information, monetary unit
FR8bd
Charging information, segment count
FR8bc
Charging information, call duration
FR10d
Called Line Address Modified Notification
FR99d
Local non-X.25 facilities, following Facility
Marker
FR20d
Facility Marker, CCITT-specified DTE
facilities
FR22d
Called Address Extension

EUR CIDIN Manual


Profile Features
References
Status

References

Status

13.22, 15.2.2.8.2
13.22, 15.2.2.8.3
13.22, 15.2.2.8.4
13.26, 15.2.2.12
15.1, Table 18

O
O
O
O
O

x
x
x
x
x

15.1

14.2, 15.3.2.2

Table G-19: Facilities Received in CLEAR CONFIRMATION Packets


ISO/IEC 8208:1993
Base Standard Features
Item
Facilities
Received
in
CLEAR
CONFIRMATION Packets
FR8af
Charging information, monetary unit
FR8bf
Charging information, segment count
FR8cf
Charging information, call duration

Appendix G

References

Status

13.22, 15.2.2.8.2
13.22, 15.2.2.8.3
13.22, 15.2.2.8.4

O
O
O

Sixth Edition
Page 14 of 15

EUR CIDIN Manual


Profile Features
References
Status
x
x
x

14/04/2011

EUR CIDIN MANUAL APPENDICES

G.8

Parameter Values and Ranges


Table G-20: Parameter Values and Ranges

ISO/IEC 8208:1993
Base Standard Features
Item
Parameter Values and Ranges
What values are supported:
V1s
- Default packet sizes (sending)?

References

Status

16.2.2.5

V1r

Default packet sizes (receiving)?

16.2.2.5

V2s

Default window sizes, sending?

16.2.2.6

V2r

Default window sizes, receiving?

16.2.2.6

16, 32, 64,


128, 256, 512,
1024, 2048,
4096 octets
16, 32, 64,
128, 256, 512,
1024, 2048,
4096 octets
(M8: in the
range 1-7)
(M8: in the
range 1-7)

EUR CIDIN Manual


Profile Features
References
Status
4.1.1.4 a

256

4.1.1.4 a

256

4.1.1.4 b

4.1.1.4 b

END of Appendix G

Appendix G

Sixth Edition
Page 15 of 15

14/04/2011

EUR CIDIN MANUAL APPENDICES

Appendix H Centre Switching Capacity

H.1

Introduction

H.1.1.1

To know the switching capacity of COM Centres in the EUR Region is regarded as extremely
important as this, apart from the identification of potential COM Centre problems, helps to
continuously improve the long-term operation of the EUR AFS.

H.1.1.2

A test equipment (test harness) provided for this purpose, shall be able to measure the switching
capacity of a COM Centre in accordance with specified test principles and performance values.

H.1.1.3

The purpose of this Appendix is to define the high-level requirements such test equipment shall
fulfil.

H.2

Switching Capacity Measurement

H.2.1

Test Harness

H.2.1.1

Figure H.1 shows the test harness of a COM centre, which may consist of multiple systems.

COM centre under test


(SUT)

(Fast)
Ethernet

serial lines
V.24/V.11

CIDIN
X.25
ASYNC

TCP/IP

Test System 1

serial lines
V.24/V.11

CIDIN
X.25
ASYNC

(Fast)
Ethernet

TCP/IP

Test System n

serial lines
V.24/V.11

CIDIN
X.25
ASYNC

(Fast)
Ethernet

TCP/IP

Test System n+1

Figure H.1 Test Harness


H.2.1.2

The test harness shall emulate real life conditions to the maximum extent possible:

Appendix H

The test equipment shall provide standard serial interfaces (V.24/V.11) and, if applicable, (Fast)
Ethernet LAN interfaces.
CIDIN, X.25 and the character-oriented asynchronous protocol (ASYNC) shall be supported on
serial connections, TCP/IP on LAN connections.
Sixth Edition
Page 1 of 4

14/04/2011

EUR CIDIN MANUAL APPENDICES

H.2.2

Test Principles and Performance Values

H.2.2.1

Table H-1 gives an overview of the test principles and performance values considered along with the
resulting requirements the system under test and the test equipment have to fulfil.

Table H-1:

No.

Requirements to be fulfilled by COM Centre and Test Equipment

Test Principles /
Performance Values

Requirements
COM Centre
Under Test

Requirements
Test Equipment

1.

Tests to be performed on a system


that behaves correctly

Approved message
Approved test equipment shall be used.
handling system shall be Interfaces should be of real-life type
tested.

2.

The system is not used for other


purposes during capacity tests

COM Centre shall not be Test equipment shall be linked with the
charged with any other
COM Centre interfaces. Therefore the test
than test traffic
equipment shall provide
COM Centre shall be
exclusively connected to
test equipment

a flexible number of V24 (RS232)


and/or V11 (X.21) interfaces,

a flexible number of (Fast) Ethernet


interfaces

CIDIN/X.25/HDLC protocol stack


(serial V.24/V.11 interfaces)

Asynchronous Byte protocol stack


(serial V.24 interfaces)

TCP/IP protocol stack


(Ethernet Interfaces)

The quantity and kind of the interfaces


used shall provide the same overall
bandwidth as the operational COM Centre
connections.
3.

Only the stable equilibrium


situation is taken into account (e.g.
one hour duration of traffic load)

4.

CPU load indication and transit


times are not taken into account

5.

Input/output ratio 1:3 (1 incoming


message generates 3 outgoing
messages)

6.

COM Centre shall not


show exceptional or
overload conditions.

Test equipment shall not show any


exceptional or overload conditions (lack of
resources in terms of memory, disk space,
increasing message queues, etc.)

COM Centre shall be


configured accordingly

Test equipment shall provide the following


possibilities to configure test messages:
-

up to 21 AFTN addresses,

AFTN

AFTN Priority,

CIDIN

AFTN Originator,

CIDIN Relay Packet (only if


applicable)

some message text,

message length up to 64 kbytes,

test messages shall be storable as


templates.

2 out of 3 CIDIN packets are relay


packets

Appendix H

COM Centre shall be


configured accordingly

Sixth Edition
Page 2 of 4

14/04/2011

EUR CIDIN MANUAL APPENDICES

No.

7.

Test Principles /
Performance Values
Different, standardized message
lengths (text length without AFTN
header) shall be used:

Requirements
COM Centre
Under Test
COM Centre shall be
able to handle AFTN
messages longer than
2.100 bytes

200 bytes (share: 20%)


400 bytes (share: 50%)
1000 bytes (share: 20%)
3000 bytes (share: 10%)

Requirements
Test Equipment
Test equipment shall be able to
-

generate and transmit AFTN messages


via AFTN circuits and via CIDIN
connections;

receive AFTN messages on AFTN


circuits and CIDIN connections
(message sink);

generate the required mix of messages


and transmit them to COM Centre;

exactly specify the amount of


messages to be generated and
transmitted:
frequency (e.g. messages/minute),
overall number of messages to be
transmitted,
continuous message transmission;

provide statistics about the amount of


messages transmitted/received.

H.2.3

Method of Capacity Measurement

H.2.3.1

The switching capacity of a COM Centre is defined as the maximum number of messages that can
be permanently switched, i.e. the COM Centre remains fully operable and shows no overload or
exceptional behaviour under this switching load.

H.2.3.2

COM Centres have different architectures and work in distinct environments; hence no standardised
test scenario can be applied. This means that the test harness has to be configured individually for
each COM Centre in accordance with the requirements defined in Table H-1.

H.2.3.3

In order to quantify the actual amount of switched messages, the test equipment shall record and
provide statistics about the messages transmitted to/received from the COM Centre under test.

H.2.3.4

Measurement method:

H.2.3.5

The COM Centre under test is charged with a certain number of messages that were generated
following the profile as defined in Table H-1/points 5-9. The message load is generated by applying
a defined transmission frequency.

H.2.3.6

After one hour of testing, the statistical values recorded by the test equipment shall be checked
against the expected values. The expected values can be calculated from the message profile
and the transmission frequency used. If measured values and calculated values do not correspond
and there are no problems with the lines, the COM Centre under test is not able to cope with the
message load.

Appendix H

Sixth Edition
Page 3 of 4

14/04/2011

EUR CIDIN MANUAL APPENDICES

H.3

Realisation

H.3.1

The system shall be based on state-of-the-art PC-AT-compatible hardware and a standard operating
system (e.g. MS Windows, Unix etc.).

END of Appendix H

Appendix H

Sixth Edition
Page 4 of 4

14/04/2011