ISO/IEC 4396-2:2023

Telecommunications and information exchange between systems - Recursive inter-network architecture - Part 2: Common application connection establishment procedure

This document provides the common application connection establishment procedure (CACEP) specification. It includes an overview of CACEP, its specification, the syntax of the protocol data units (PDUs), and the policies available.

Titre manque — Partie 2: Titre manque

General Information

• Status: Published
• Publication Date: 04-Dec-2023
• ICS: 35.100.30 - Network layer
• Technical Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Drafting Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Current Stage: 6060 - International Standard published
• Start Date: 05-Dec-2023
• Due Date: 11-May-2024
• Completion Date: 05-Dec-2023

Overview

ISO/IEC 4396-2:2023 specifies the Common Application Connection Establishment Procedure (CACEP) for the Recursive Inter‑Network Architecture (RINA). Published by ISO/IEC, this part of the ISO/IEC 4396 series defines the protocol exchange used to establish application connections between application processes. The standard covers an overview of CACEP, the detailed procedure and state machine for initiators and responders, the syntax of Protocol Data Units (PDUs), ASN.1 definitions, and available policies (including authentication).

Key topics and technical requirements

• CACEP purpose: Exchange application naming information, optionally perform mutual authentication, and initialize access to objects and protocol parameters required for subsequent data transfer.
• Protocol design: Patterned after the Association Control Service Element (ACSE) - chosen for existing functionality, minimalism, and recursive suitability for RINA.
• State machine: Defined initiating and responding states (e.g., Null, FlowPending, Authenticating, ConnectPending, Established, Releasing) that govern connection lifecycle.
• Primitive operations / PDUs: Specification includes primitives such as Allocate_Request.submit, Allocate_Response.deliver, Allocate_Indication, A_CONNECT Request/Response, optional A_DATA, A_RELEASE Request/Response, A_UNIT_DATA, deallocate/indication and timers (e.g., potential enrollment timer).
• PDU syntax and encoding: ASN.1 definitions for PDUs are provided; Annex includes legacy encoding rules for compatibility.
• Policies: Authentication and other policy mechanisms are described to allow implementers to select or define how mutual authentication and parameter negotiation occur.
• Interoperability: CACEP is primarily designed to pair with CDAP (Common Distributed Application Protocol) but can be wrapped around other data-transfer protocols (e.g., HTTP) to support legacy integrations.

Applications and who uses it

• Network architects and protocol designers implementing or evaluating RINA-based systems.
• Software engineers and implementers building application-layer connection managers, authentication modules, and PDU encoders/decoders (ASN.1).
• System integrators who need to wrap legacy application protocols with a standardized connection-establishment layer.
• Researchers studying recursive inter-network models and access/control semantics in distributed systems.

Practical uses include secure application connection setup, initialization of application naming and context (e.g., object model versions, abstract/encoding rules), and enabling interoperable application-layer exchanges in RINA deployments or in hybrid environments where CACEP fronts legacy protocols.

Related standards

• ISO/IEC 4396-1 - Recursive inter‑network architecture: reference model (normative reference used by this document)
• ACSE-related literature and ASN.1 encoding standards for PDU definitions and legacy encoding guidance.

Keywords: ISO/IEC 4396-2:2023, CACEP, Recursive inter-network architecture, RINA, connection establishment, PDUs, ASN.1, ACSE, CDAP, application naming, authentication policy.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 4396-2
First edition
2023-12
Telecommunications and
information exchange between
systems — Recursive inter-network
architecture —
Part 2:
Common application connection
establishment procedure
Reference number
© ISO/IEC 2023
© ISO/IEC 2023
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
© ISO/IEC 2023 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Overview . 1
5 Detailed specification . .2
5.1 General . 2
5.2 Definitions of the process states . 2
5.2.1 General . 2
5.2.2 Initiating states . 2
5.2.3 Responding states . 2
5.3 Allocate_Request.submit . 2
5.3.1 When invoked . 2
5.3.2 Action upon receipt . 2
5.4 Allocate_Response.deliver . 3
5.4.1 When invoked . 3
5.4.2 Action upon receipt . 3
5.5 Allocate_Indication . 3
5.5.1 When invoked . 3
5.5.2 Action upon receipt . 3
5.6 A_CONNECT Request . 3
5.6.1 When invoked . 3
5.6.2 Action upon receipt . 3
5.7 A_CONNECT Response . . 4
5.7.1 When invoked . 4
5.7.2 Action upon receipt . 4
5.8 A_DATA (Optional) . 4
5.8.1 When invoked . 4
5.8.2 Action upon receipt . 4
5.9 A_RELEASE Request . 4
5.9.1 When invoked . 4
5.9.2 Action upon receipt . 4
5.10 A_RELEASE Response . 5
5.10.1 When invoked . 5
5.10.2 Action upon receipt . 5
5.11 Deallocate indication . 5
5.11.1 When invoked . 5
5.11.2 Action upon receipt . 5
5.12 A_UNIT_DATA (optional) . 5
5.12.1 When invoked . 5
5.12.2 Action upon receipt . 5
5.13 Potential enrollment timer . 5
5.13.1 When invoked . 5
5.13.2 Action upon receipt . 5
6 Syntax of the PDUs .6
6.1 General . 6
6.2 ASN.1 Definition . 6
7 Policies . 9
Annex A (informative) Legacy encoding rules .10
iii
© ISO/IEC 2023 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance
are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria
needed for the different types of document should be noted. This document was drafted in
accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives or
www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve
the use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability
of any claimed patent rights in respect thereof. As of the date of publication of this document, ISO and
IEC had received notice of (a) patent(s) which may be required to implement this document. However,
implementers are cautioned that this may not represent the latest information, which may be obtained
from the patent database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall
not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 6 Telecommunications and information exchange between systems.
A list of all parts in the ISO/IEC 4396 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
iv
© ISO/IEC 2023 – All rights reserved

Introduction
The functions of creating an application connection between instances of application processes are to:
— exchange application naming information;
— ) optionally, authenticate each;
.
— ) establish the set of objects to which remote operations on the flow have access.
This document defines the Common Application Connection Establishment Procedure (CACEP),
patterned after the Association Control Service Element (ACSE) protocol. ACSE was chosen for three
reasons:
— it already exists;
— it provides all of the necessary functions and no more;
— it was designed to be used recursively.
ACSE provides the basic requirements for exchanging application naming and context information and
provides for an authentication module to be included.
Although the primary use of CACEP is to combine it with common distributed application protocol
(CDAP) for the application information data transfer phase, there are situations when it is desirable
to use CACEP with a different protocol in the data transfer phase, e.g. HTTP, in effect, wrapping
CACEP establishment around a legacy protocol. CACEP exchanges naming information and provides
for an authentication policy. CACEP is a protocol exchange over a flow that serves to authenticate
flow participants to their mutual satisfaction and to initialize the application naming information
and information related to the application protocol that will be used by applications to exchange
information, e.g. abstract and encoding rules, object model versions. In the case of recursive inter-
network architecture (RINA), the application protocol is CDAP
v
© ISO/IEC 2023 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 4396-2:2023(E)
Telecommunications and information exchange between
systems — Recursive inter-network architecture —
Part 2:
Common application connection establishment procedure
1 Scope
This document provides the common application connection establishment procedure (CACEP)
specification. It includes an overview of CACEP, its specification, the syntax of the protocol data units
(PDUs), and the policies available.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 4396-1, Telecommunications and information exchange between systems — Recursive inter-network
architecture — Part 1: Reference model
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 4396-1 and the following
apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: avaiable at https:// www .electropedia .org/
3.1
Application Naming Information
names used to reference an application that includes the required name Application Process Name and
can include distributed application facility (DAF) name or distributed IPC (inter-process communication)
facility (DIF) name, application process name, application process instance id, application entity id, and
application entity instance id
4 Overview
The Initiating Process first allocates an (N-1)-flow with a destination application. When this is complete,
it sends an A_CONNECT Request with the appropriate parameters and initiates the authentication
policy. When the Authentication policy completes, a positive or negative A_CONNECT Response is
returned by the destination application process and the connection is established.
© ISO/IEC 2023 – All rights reserved

5 Detailed specification
5.1 General
This specification describes both sides of the procedure for establishing communication between the
Initiating and Responding Processes.
5.2 Definitions of the process states
5.2.1 General
Creating an applications connection will transition among the following states:
5.2.2 Initiating states
— Authenticating – a connection is in the process of being established and the initiator is authenticating
within policy the responder and vice versa.
— ConnectPending – a Connect Request has been sent, awaiting a response.
— Established – the connection is established and PDUs can be exchanged.
— FlowPending – determining if the flow is well-formed.
— Null – the state machine is awaiting input.
— Releasing – the state machine is releasing all resources associated with this connection.
5.2.3 Responding states
— Authenticating – a connection is in process of being established and the responder is authenticating
within policy the initiator and vice versa.
— ConnectPending – a Connect Request has been sent, awaiting a response.
— Established – the connection is established and PDUs can be exchanged.
— Null – the state machine is awaiting input.
— Releasing – the state machine is releasing all resources associated with this connection.
5.3 Allocate_Request.submit
5.3.1 When invoked
This primitive is invoked when a process has been instructed to create an application connection.
5.3.2 Action upon receipt
The Initiating-Process is provided with the Application-Naming-Information and a supporting DIF that
can be used to contact the Destination Application Process. The Initiating-Process is in the NULL state
and invokes an Allocate_Request to the supporting DIF:
— Allocate_Request(.any.DIF or URL, , QoS parameters, access
control parameters).
The Initiating-Process transitions to the FlowPending state.
© ISO/IEC 2023 – All rights reserved

5.4 Allocate_Response.deliver
5.4.1 When invoked
When the Initiating Application Process is in the FlowPending state and the supporting DIF receives a
Create Flow Response.
5.4.2 Action upon receipt
If the Initiating Application Process is not in the FlowPending state, this is an error, the Initiating
Process should invoke a Deallocate primitive and report the error appropriately. If the Allocate was
successful, then there is an allocated flow with the requested QoS and the Initiating Process can
transition from the FlowPending state to the ConnectPending state, sending a A_CONNECT PDU to the
Responding Process. If the Response was negative, an error is returned, and the state returns to NULL.
5.5 Allocate_Indication
5.5.1 When invoked
When the named Destination Application in the NULL state and receives an Allocate_Indication from
the supporting DIF.
5.5.2 Action upon receipt
The Responding Process is in the NULL state. If the Allocate_Indication specified an Application
Process-Instance and Application-Entity-Instance and the instance was not in the NULL state, then this
is an error; otherwise, a new instance is created and it is not an error.
If the Responding Process is not willing to accept the request, it returns a negative Allocate_Confirm
to the supporting DIF. The state remains NULL. If the Responding Process is willing to accept the
connection, it notifies the supporting DIF with a positive Allocate_Confirm primitive. The Responding
Process transitions to ConnectPending state.
5.6 A_CONNECT Request
5.6.1 When invoked
When a supporting flow has been allocated, the Responding Process is in the ConnectPending State
(waiting for an A_CONNECT Request).
5.6.2 Action upon receipt
If the Responding Entity-instance is not in the ConnectPending State, the Responding Entity-instance
should send an A_RELEASE and invoke a Deallocate and abruptly terminate the connection.
Otherwise, If the PotentialConnection Timer is set then (this is a retry), the timer is cancelled.
Otherwise, The Responding Entity-instance will evaluate the parameters of the A_CONNECT Request
and if they are valid will invoke the Authentication module and transition to the Authenticating state.
If the Authentication module completes successfully, the Responding Entity instance sends a positive
A_CONNECT Response and transitions to the Established state.
If Authentication fails, the Responding Entity-instance sends a negative A_CONNECT Response. The
Responding Entity instance increments the count of number of retries. If the count is less than or equal
MaxConnectRetries, then it sets a PotentialConnection Timer greater than 2MPL (Maximum Packet
Lifetime) and remains in the ConnectPending State.
© ISO/IEC 2023 – All rights reserved

-
...