INTERNATIONAL CIVIL AVIATION ORGANIZATION

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 No. CORRIGENDA Date Date applicable entered Entered by 1 11/4/03 June 2004 eb 2 13/4/04 June 2004 eb Page i of v

EUR CIDIN MANUAL Amendments to CIDIN Manual Amendment Subject(s) Adopted 1 st Edition Introduction of guidance material for CIDIN Implementation in the EUR Region. 2 nd Edition Major review, including update of the Manual to take account of new Annex 10 format. 1 st Amendment 2 nd 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. Introduction of Network management application interface procedures (Chapter 9 and Appendix D). Refinements in Chapters 8, 10 and Appendix F. June 1990 August 2002 April 2003 April 2004 3 rd Edition New edition to consolidate 1 st and 2 nd Amendments. June 2004 4 th Edition New edition to introduce Chapters 12 and 13 and Appendix H. July 2005 5 th Edition New edition to introduce Chapter 6 Transport Layer, paragraph 6.2.9.1 and Chapter 10 Operational Procedures, paragraph 10.2.3 6 th Edition Incorporation of CP-CIDINM-10-001, Incorporation of CP-CIDINM-10-002, Minor editorial changes and reformatting September 2006 April 2011 Page ii of v

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 Page iii of v

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 Page iv of v

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 Page v of v

EUR CIDIN MANUAL 1. Introduction 1.1 Purpose of this Manual 1.1.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. 1.1.2 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. Chapter 1 Page 1 of 10

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 Page 2 of 10

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 Page 3 of 10

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 the system Users of the system N-service Peer-to-peer protocol of layer (N) N-service layer N layer N-1 (N-1)-service Peer-to-peer protocol of layer (N-1) (N-1)-service 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. 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. Chapter 1 Page 4 of 10

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 Page 5 of 10

EUR CIDIN MANUAL A C B Boundary of CIDIN Messages Messages 4 4 3b 3b 3a 3a 2 2 1 1 A B C 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 Page 6 of 10

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 Page 7 of 10

EUR CIDIN MANUAL Transport of AFTN messages via CIDIN: AFTN Interface AFTN Interface 4 4 3b 3b 3a 3a 2 2 1 1 AFTN centre 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: Message part nm_identifier nm_function + message_type message_body Value / Specification (NM) OP 1{line}24 maximum 1968 characters CUDF line cr + lf + {ia5_printable_characters}80 Note 1: cr carriage return (ia5 encoding) lf line feed (ia5 encoding) Chapter 1 Page 8 of 10

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: CUDF Message part Modified starting line Abbreviated heading 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 Page 9 of 10

EUR CIDIN MANUAL 1.2.2.7.4 A description of the CIDIN ATN subnetwork parameters is presented in Appendix B. 1.3 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 Page 10 of 10

EUR CIDIN MANUAL 2. Physical Layer (1) 2.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: 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. 2.2.3 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 Page 1 of 2

EUR CIDIN MANUAL 2.2.4 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. Chapter 2 Page 2 of 2

EUR CIDIN MANUAL 3. Link Layer (2) 3.1 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 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 3.2.1.2 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 Data integrity 3.2.1.3 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. 3.2.1.4 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. Chapter 3 Page 1 of 6

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: 3.2.2.3 The structure of a frame is: <flags> represents a sequence of zero or more flags. 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 Flag Address Control Field User Data Data Link Control Field Frame Check Sequence Flag 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: Bit 8 Bit 1 Address A 0 0 0 0 0 0 1 1 Address B 0 0 0 0 0 0 0 1 3.2.2.6 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 Chapter 3 Page 2 of 6

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 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. 3.2.3 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 0- bit 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 Page 3 of 6

EUR CIDIN MANUAL Primary Commands Responses Secondary Secondary Commands Responses Primary CIDIN centre with address A Command (B) Command (A) CIDIN centre with address B 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 Page 4 of 6

EUR CIDIN MANUAL For example, satellite links with their relatively long transmission delays require large windows and extended numbering. Sender Receiver A,C and info fields A,C and info fields FCS Correct FCS indicates transmission error FCS generated FCS generation and checking procedure FCS recalculated and compared with transmitted FCS Sequence of 6 1-bits modified Bit stuffing procedure Any sequence of 6 1-bits in original data recreated Frame packed between flags Flag generation and detection Frame unpacked transmission circuit Invalid frames rejected Figure 3.3 Relationship between Bit Stuffing, FCS generation/checking and Flag Processing 3.2.5.4 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. 3.2.6 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 Page 5 of 6

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 Page 6 of 6

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: a) maximum user data field length of 256 octets; and b) default window size of seven, or maximum available. 4.1.1.5 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. 4.1.2 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: a) the general format identifier; b) the logical channel identifier, comprising a logical channel group number and a logical channel number; Chapter 4 Page 1 of 3

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 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). 4.1.2.4 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). 4.1.2.5 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). 4.1.2.6 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. 4.1.2.7 RESTART REQUEST packet (Figure 4.5), comprising: a) the general format identifier; Chapter 4 Page 2 of 3

EUR CIDIN MANUAL 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). 4.1.2.8 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 4 3 2 1 general format identifier logical channel group number octet sequence 0 0 0 1 1 logical channel number 2 Packet type identifier P(R) M P(S) 0 User data field 4 (<= 256 octets * ) <=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. 3 Figure 4.1 Reset request packet format Chapter 4 Page 3 of 3

EUR CIDIN MANUAL transmission order of bits within each octet 8 7 6 5 4 3 2 1 general format identifier logical channel group number octet sequence 0 0 0 1 1 logical channel number 2 packet type identifier P(R) 0 0 0 0 1 3 transmission order of bits within each octet 8 7 6 5 4 3 2 1 general format identifier logical channel group number octet sequence 0 0 0 1 0 0 0 0 1 logical channel number 2 packet type identifier P(R) 0 0 1 0 1 3 Figure 4.2 Receive ready packet format Figure 4.3 Receive not ready packet format transmission order of bits within each octet 8 7 6 5 4 3 2 1 general format identifier logical channel group number octet sequence 0 0 0 1 1 logical channel number 2 Packet type identifier 3 0 0 0 1 1 0 1 1 resetting cause field 4 diagnostic code 5 transmission order of bits within each octet 8 7 6 5 4 3 2 1 general format identifier logical channel group number Octet sequence 0 0 0 1 0 0 0 0 1 logical channel number 0 0 0 0 0 0 0 0 2 Packet type identifier 3 1 1 1 1 1 0 1 1 restarting cause field 4 0 0 0 0 0 0 0 0 diagnostic code 5 Figure 4.4 Reset request packet format Figure 4.5 Restart request packet format transmission order of bits within each octet 8 7 6 5 4 3 2 1 general format identifier logical channel group number octet sequence 0 0 0 1 1 logical channel number 2 packet type identifier 0 0 0 1 1 1 1 1 3 transmission order of bits within each octet 8 7 6 5 4 3 2 1 general format identifier logical channel group number octet sequence 0 0 0 1 0 0 0 0 1 logical channel number 2 0 0 0 0 0 0 0 0 packet type identifier 1 1 1 1 1 1 1 1 3 Figure 4.6 Reset confirmation packet format Figure 4.7 Restart confirmation packet format 4.1.3 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 2 8 and added to the logical channel number. Chapter 4 Page 2 of 2

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: 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. 4.1.3.8 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. 4.1.4 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: 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". 4.1.4.5 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". 4.1.5 Procedure for Initialisation Chapter 4 Page 2 of 20