ISO/IEC 4396-1:2023

Telecommunications and information exchange between systems - Recursive inter-network architecture - Part 1: Reference model

This document provides the reference model for the Recursive Inter-Network Architecture (RINA). It describes: - the basic concepts of distributed systems and distributed applications; - distributed management systems (DMSs); - the fundamental structure of distributed Inter-Process Communications; - the Distributed Inter-Process Facility (DIF) operations.

Télécommunications et échange d'information entre systèmes — Architecture récursive inter-réseaux — Partie 1: Modèle de référence

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-1:2023 - "Telecommunications and information exchange between systems - Recursive inter-network architecture - Part 1: Reference model" is the authoritative, high‑level reference model for the Recursive Inter‑Network Architecture (RINA). Published as the first edition in 2023, this standard defines the fundamental concepts and terminology for RINA and provides the top‑level architecture that later, more detailed specifications will build upon. It is intended as a reference model (not a tutorial) for distributed systems, distributed applications and recursive inter‑process communication.

Keywords: ISO/IEC 4396-1, RINA, Recursive Inter‑Network Architecture, Distributed Inter‑Process Facility (DIF), DAF, CDAP, DMS, IPC, distributed systems, network architecture.

Key Topics Covered

The document systematically describes the elements and operations that make up RINA. Major technical topics include:

• Basic concepts of distributed systems and distributed applications
  • Definitions for application processes (AP), application entities (AE), naming and naming domains.
• Distributed Application Facilities (DAFs)
  • Elements of a DAF, DAF security principles, Common Distributed Application Protocol (CDAP) and enrollment procedures.
• Distributed Management Systems (DMSs)
  • Roles and types of DMSs such as Network Management DMS (NM‑DMS), Application Management DMS (AM‑DMS), and Name Space Management DMS (NSM‑DMS), plus DIF allocator structure and operations.
• Distributed Inter‑Process Communication (IPC) - fundamental structure
  • Definition of a Distributed‑IPC‑Facility (DIF), IPC process components, flows and connections, DIF security principles and how DIFs stack as layers.
• Error and flow control components
  • Terminology and roles for EFCP, DTP and DTCP (as defined in the reference model).
• Naming, addressing and binding
  • Addressing semantics within DIFs and name‑space management.

Note: ISO/IEC 4396-1 contains no normative references; it establishes the terminology and architecture for the ISO/IEC 4396 series.

Practical Applications and Who Uses It

ISO/IEC 4396-1 is intended for professionals and stakeholders involved in modern network architecture and distributed systems design:

• Network architects and protocol designers adopting or evaluating RINA as an alternative to traditional TCP/IP layering.
• Software and systems engineers building DIFs, DAFs, CDAP-based services, or RINA‑compatible middleware.
• Vendors and integrators designing secure, multi‑layer IPC platforms for carrier, enterprise or research networks.
• Standards bodies, academic researchers and technical writers who need a formal reference model for recursive inter‑network concepts.

Related Standards & Further Reading

• Part of the ISO/IEC 4396 series; other parts expand detailed specifications and operational procedures referenced from this top‑level model.
• ISO Online Browsing Platform and IEC Electropedia for terminology and cross‑references.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 4396-1
First edition
2023-12
Telecommunications and
information exchange between
systems — Recursive inter-network
architecture —
Part 1:
Reference model
Télécommunications et échange d'information entre systèmes —
Architecture récursive inter-réseaux —
Partie 1: Modèle de référence
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 Symbols and abbreviated terms.9
5 Basic concepts of distributed applications .10
5.1 Introduction to distributed applications . 10
5.2 Naming concepts for Distributed-Application Facilities (DAFs) . 11
5.3 Elements of a Distributed-Application Facility (DAF) . 11
5.3.1 Overview . 11
5.3.2 DAF security principles . 13
5.3.3 Common Distributed-Application Protocol (CDAP) .13
5.3.4 DAF enrollment .15
6 Introduction to distributed management systems (DMSs) .16
6.1 General . 16
6.2 Network Management DMS (NM-DMS) . 16
6.3 Application Management DMS (AM-DMS) . 18
6.4 Name Space Management DMS (NSM-DMS) . 18
6.5 DIF allocator. 19
6.5.1 General . 19
6.5.2 DIF allocator structure . 20
6.5.3 Operations . 21
7 Distributed InterProcess Communication — Fundamental structure .22
7.1 Distributed-IPC-Facility (DIF) .22
7.1.1 Overview . 22
7.1.2 IPC process . 23
7.1.3 Flows and connections . 24
7.1.4 DIF security principles . 24
7.1.5 IPC components .25
7.1.6 DAF Infrastructure for IPC .28
7.2 Naming in Distributed IPC Facilities . 30
7.3 DIFs are layers . 31
Annex A (informative) Basic concepts of distributed systems .32
Bibliography .39
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 purpose of this document is to provide a reference model for the concepts in Recursive Inter-
[1],[2]
Network Architecture (RINA) . This document provides the fundamental definitions for the
ISO/IEC 4396 series. It defines an architecture.
This document is the high-level description of the concepts, the elements and how they work. This is a
top-level specification, not a tutorial. Other more detailed specifications will draw on the ISO/IEC 4396
series as their starting point.
v
© ISO/IEC 2023 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 4396-1:2023(E)
Telecommunications and information exchange between
systems — Recursive inter-network architecture —
Part 1:
Reference model
1 Scope
This document provides the reference model for the Recursive Inter-Network Architecture (RINA). It
describes:
— the basic concepts of distributed systems and distributed applications;
— distributed management systems (DMSs);
— the fundamental structure of distributed Inter-Process Communications;
— the Distributed Inter-Process Facility (DIF) operations.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions 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: available at https:// www .electropedia .org/
3.1
address
identifier that is a synonym for the fully qualified IPC-Process-Instance-name, which is a member of a
distributed-IPC-facility (DIF) (3.32)
Note 1 to entry: An address is only unambiguous within the DIF (and is assigned by the DIF). This identifier can
be assigned to facilitate its usefulness to the operation of the DIF, i.e. location-dependent.
3.2
application connection
shared state maintained by two communicating peer application entities (AEs) (3.3)
Note 1 to entry: Application connections go initially through an establishment phase, in which enough data is
exchanged to establish a shared understanding between both AEs, to later proceed to the data transfer phase,
in which both AEs exchange data. In Recursive Inter-Network Architecture (RINA), the establishment phase is
handled by common application connection establishment procedure (CACEP) (3.17), while the data transfer phase
is the responsibility of common distributed application protocol (CDAP) (3.18).
© ISO/IEC 2023 – All rights reserved

3.3
application-entity
AE
task within an application process that is directly involved with exchanging application information
with other application processes (APs) (3.9)
3.4
application entity instance
AE-instance
AEI
instantiation of an application entity (AE) (3.3) within an application process (AP) (3.9)
3.5
application entity instance identifier
AE-instance-id
AEI-id
identifier which is unambiguous within the application entity (AE) (3.3)
Note 1 to entry: The AE-instance-id may be ambiguous within the application process (AP) name space (3.13)
unless qualified by the application process name, application process instance id (3.11), and the application entity
(AE) name (3.6).
3.6
application entity name
AE name
identifier from the application entity (AE) name space (3.8) which is unambiguous within the scope
(3.55) of the application process (AP) (3.9)
Note 1 to entry: An AE name when concatenated with an AP name (3.12) is unambiguous within the AP name
space (3.13), as is an AE name concatenated with an AP name and an AP instance id (3.11).
3.7
application programming interface primitive
API primitive
library or system call used by an application to invoke functions, in particular inter process
communication (IPC) (3.39) functions, such as requesting the allocation of IPC resources
3.8
application entity name space
AE name space
set of strings which may be assigned to application entities (AEs) (3.3) of a given application process (AP)
(3.9) and used to reference them by other applications in the same naming domain
3.9
application- process
AP
software program in a processing system (3.46) intended to accomplish some purpose
Note 1 to entry: An application process contains one or more tasks or application entities (AEs) (3.3) as well as
functions for managing the resources (e.g. processor, storage, and IPC) allocated to this AP.
Note 2 to entry: Tasks are also application processes.
3.10
application process instance
AP instance
instantiation of an application process (AP) (3.9) on an operating system
© ISO/IEC 2023 – All rights reserved

3.11
application process instance id
AP instance id
identifier that is unambiguous within the application process (AP) (3.9) and is bound to an AP instance
(3.10) in order to distinguish among multiple AP instances
Note 1 to entry: An AP instance id concatenated with an AP name (3.12) is unambiguous in the AP name space
(3.13).
3.12
application -process -name
AP -name
string assigned to a single application process (AP) (3.9) from an AP name space (3.13)
Note 1 to entry: An AP name is not assigned to any other AP while bound to the one to which it has been assigned.
3.13
application process name space
AP name space
set of strings which may be assigned to application processes (APs) (3.9) and used to reference them by
other APs in the same naming domain
3.14
application protocol
protocol used between two application entities (AEs) (3.3) to perform operations external to the protocol
machine (PM) (3.50) itself
Note 1 to entry: The distinguishing characteristic of application protocols is that they modify states external to
the protocol.
3.15
assignment
operation that allocates a name in a name space (3.43), essentially marking it as being in use
Note 1 to entry: Assignment makes names available to be bound. This allows certain portions of a name space to
be “reserved” and not be available for binding (3.16). The corresponding reverse operation, de-assignment (3.25),
removes it from use.
3.16
binding
function, F ,N , that defines the mapping of a subset of elements of {NS} to elements of {M}
M S
Note 1 to entry: This function is one-to-one and into. The operation, binding, binds a name to an object.
Note 2 to entry: Once bound, any reference to the name locates or accesses the object.
3.17
common application connection establishment procedure
CACEP
procedure to authenticate flow participants and initialize the application naming and protocol
information
Note 1 to entry: CACEP naming and protocol information relates to the application protocol (3.14) that will be
used by applications to exchange information (e.g. abstract and encoding rules, object model versions). In case of
Recursive Inter-Network Architecture (RINA), the application protocol is common distributed application protocol
(CDAP) (3.18).
© ISO/IEC 2023 – All rights reserved

3.18
common distributed application protocol
CDAP
application protocol (3.14) component of a distributed application facility (DAF) (3.27) used to construct
arbitrary distributed applications
Note 1 to entry: CDAP enables distributed applications to deal with communications at an object level, rather
than forcing applications to explicitly deal with serialization and input/output operations. CDAP provides a
straightforward and unifying approach to sharing data over a network without having to create specialized
protocols.
Note 2 to entry: Distributed IPC facility (DIF) (3.32) is an example of a distributed application facility (DAF) (3.27).
3.19
computing system
collection of all processing systems (3.46) (some specialized) in the same management domain
Note 1 to entry: There are no restrictions on the connectivity of computing systems.
3.20
connection
shared state between error and flow control protocol machine EFCP PMs (3.34)
3.21
connection-endpoint-identifier
CEP-id
identifier that is unambiguous within the scope (3.55) of an interprocess communication (IPC) process
which identifies an error and flow control protocol machine EFCP PM (3.34) instance
3.22
connection-identifier
identifier internal to the distributed IPC facility (DIF) (3.32) that are unambiguous within the scope of
communicating error and flow control protocol machine EFCP PMs (3.34) from that DIF
Note 1 to entry: The connection identifier is formed by the concatenation of the source and destination connection
establishment procedure (CEP)-ids to identify the two directions of the connection.
3.23
data transfer control procedure
DTCP
half of an error and flow control protocol (EFCP) (3.33) that performs loosely bound (feedback)
mechanisms, such as retransmission and flow control
Note 1 to entry: The DTCP protocol machine (PM) maintains state, which can be discarded after long periods of
no traffic.
Note 2 to entry: One instance of a DTCP is created for each connection of a flow.
Note 3 to entry: All connections in Recursive Inter-Network Architecture (RINA) have flow control. Connections
without flow control are denial of service attack vector.
3.24
data transfer procedure
DTP
half of an error and flow control protocol (EFCP) (3.33) that performs tightly bound mechanisms, such as
ordering and fragmentation/reassembly
Note 1 to entry: One instance of a DTP protocol machine (PM) is created for each connection allocated.
3.25
de-assignment
operation that deallocates a name in a name space (3.43), removing it from use
© ISO/IEC 2023 – All rights reserved

3.26
delimiting
operation to delineate the beginning and end of a service-data-unit (SDU) (3.56) and package it into the
user-data field of a protocol-data-unit (PDU) (3.45)
Note 1 to entry: Delimiting is usually the first operation performed by the distributed IPC facility (DIF) (3.32)
when an SDU is submitted.
Note 2 to entry: Delimiting enables the DIF to deliver the SDU as a unit of data to its recipient intact.
3.27
distributed application facility
DAF
distributed application
collection of application processes (APs) (3.9) in processing systems (3.46) that exchange information
using interprocess communication (IPC) (3.39) and maintain shared state to cooperate in performing
some task or function
Note 1 to entry: There are at least two APs and at least one processing system in each DAF.
Note 2 to entry: The DAF forms a black box to the members of the DAF who may be executing on one or more
processing systems.
Note 3 to entry: In some DAF, all members of the DAF will be the same, i.e. a homogeneous DAF, while in others
they may be different, i.e. a heterogeneous DAF.
3.28
distributed application name
whatevercast name (3.61) for the set of application processes (APs) (3.9) comprising a distributed
application depending on the operation
Note 1 to entry: A whatevercast name is generally taken from the same name space (3.43) as the APs and is used
to identify a distributed application. An important type of distributed application is a distributed IPC facility (DIF)
(3.32), i.e. the set of cooperating interprocess communication (IPC) (3.39) processes.
3.29
distributed application process
DAP
application process (AP) (3.9) that is a member of a distributed application facility (DAF) (3.27)
3.30
distributed application process name
DAP name
synonym for an application process (AP) (3.9) name
3.31
distributed application process synonym
DAP synonym
synonym for a distributed application process (DAP) (3.30) that is a member of a specific distributed
application facility DAF (3.27) and is only unambiguous within the DAF (and is assigned by the DAF)
Note 1 to entry: The names may be structured to facilitate their use within the DAF.
3.32
distributed IPC facility
DIF
layer
collection of application process (AP) instances (3.10) that are cooperating to provide interprocess
communication (IPC) (3.9)
Note 1 to entry: A DIF is a distributed application facility (DAF) (3.27) that does IPC.
© ISO/IEC 2023 – All rights reserved

Note 2 to entry: The DIF provides IPC services to AP instances of a DAF or IPC process instances of other DIFs via
a set of application programming interface (API) primitives that are used to exchange information with the IPC
process instances’ peer.
3.33
error and flow control protocol
EFCP
data transfer protocol used to maintain an instance of interprocess communication (IPC) (3.39) within a
distributed IPF facility (DIF) (3.32).
Note 1 to entry: The functions of this protocol can be used to provide reliability, order and flow control as
required as determined by policy.
3.34
EFCP protocol machine
EFCP PM
instance of the error and flow control protocol (EFCP) (3.33) for a single connection
Note 1 to entry: An EFCP PM consists of two state machines loosely coupled through a single state vector: one
that performs the data transfer procedure (DTP) (3.24) protocol machine (PM) (3.50) and the other that performs
the data transfer control procedure (DTCP) (3.23) protocol machine (PM) (3.50).
3.35
flow
binding (3.16) of a connection to source and destination ports
3.36
flow allocator
FA
task that handles requests to allocate a flow (3.35)
3.37
flow allocator instance
FA-instance
FAI
instance created for each allocation request to manage the flow for its lifetime
Note 1 to entry: The flow allocator instance will translate the (quality of service ) QoS requested by the
Application-Process into specific policies and find the destination Application and determine if the allocation can
be honoured. The FAI-identifier or port–id is returned to the application as a handle for referencing the allocation.
3.38
IPC process
IPCP
application process (AP) (3.9) whose primary purpose is managing inter process communication (IPC)
(3.39)
3.39
inter process communication
IPC
service that allows two or more application process (AP) instances (3.10) to exchange data
3.40
IPC resource manager
IRM
component of a distributed application facility (DAF) (3.27) that manages its use of IPC
© ISO/IEC 2023 – All rights reserved

3.41
multiplexing task
MT
task within the interprocess communication (IPC) (3.39) process that performs multiplexing onto (N-1)-
ports
Note 1 to entry: There is potentially one MT for each (N-1)-port.
3.42
name
unique string, N, in some alphabet, A, that, when seen within a name space (NS) (3.43) unambiguously
denotes an object or denotes a statement in some language, L, constructed using the alphabet, A
3.43
name space
NS
set of names, {N}, from which all names for a given collection of objects are taken
Note 1 to entry: A name from a given name space may be bound to one and only one object at a time.
3.44
port
binding (3.16) of an (N)- error and flow control protocol (EFCP) protocol machine (PM) (3.34) instance
to either an application entity (AE) instance (3.4) (if a distributed application facility (DAF) (3.27)) or an
(N)-IPC process instance [if a distributed IPC facility (DIF) (3.32)] in the layer above
3.45
port id
identifier that is unambiguous within the scope (3.55) of the application process (AP) instance (3.10) and
a distributed IPC facility (DIF) (3.32) interprocess communication process (IPCP) instance that is used
to distinguish an instance of communication, i.e. a specific IPC allocation
Note 1 to entry: A port-id is a flow-allocator-instance-identifier (FAI-id) unique within the flow allocator (3.36)
task, which identifies a flow-allocator-instance (FAI). FAI-id or port-id is returned to requesting applications as a
handle to refer to this instance of IPC. The FAI maintains a mapping between the Port-id and the Connection-End-
Point-id.
3.46
processing system
hardware and software that are capable of executing programs instantiated as application processes
(APs) (3.9) that can coordinate using the equivalent of a “test and set” instruction, i.e. the tasks can all
atomically reference the same memory
3.47
protocol
syntax and procedures of protocol data units (PDUs) (3.49) that specify the behaviour of two protocol
machines (PMs) (3.50) cooperating for the purpose of maintaining shared state
3.48
protocol control information
PCI
that part of a protocol data unit (PDU) (3.49) that is interpreted by the protocol machine (PM) (3.50) in
order to maintain the shared state of the protocol
3.49
protocol data unit
PDU
unit of data exchanged by protocol machines (PMs) (3.50) consisting of protocol control information (PCI)
(3.48) and user data
© ISO/IEC 2023 – All rights reserved

3.50
protocol machine
PM
finite state machine that implements a protocol for maintaining a shared state
Note 1 to entry: A PM accepts input from its user and exchanges protocol data units (PDUs) (3.49) with a peer by
transferring service data units (SDUs) (3.56) to a supporting service.
Note 2 to entry: The intent is to maintain the shared state with a corresponding PM, usually in another processing
system (3.46).
3.51
relaying task
RT
task within an interprocess communication (IPC) (3.39) process that performs relaying of protocol data
units (PDUs) (3.49)
Note 1 to entry: There is one RT in each IPC process.
3.52
resource allocator
component of the interprocess communication (IPC) (3.39) process that manages resource allocation
and monitors the resources in the distributed IPC facility (DIF) (3.32) by sharing information with other
DIF IPC processes and the performance of supporting DIFs
3.53
resource information base
RIB
logical representation of the local repository of the objects for the distributed application facility DAF
(3.27)
Note 1 to entry: Each member of the DAF maintains a RIB.
Note 2 to entry: A distributed application may define a RIB to be its local representation of its view of the
distributed application.
Note 3 to entry: From the point of view of an OS model, this is storage.
3.54
RIB daemon
common component of an application entity (AE) (3.3)
Note 1 to entry: a common component of the AE is a task in a local application process (AP) (3.9) may request
the resource information base (RIB) (3.53) daemon to provide information from other members of the distributed
application facility (DAF) (3.27) either on demand, on an event, or periodically.
Note 2 to entry: The RIB daemon can optimize AP requests for information.
Note 3 to entry: From the point of view of an OS model, this can be considered storage management.
3.55
scope
function, MNS, which defines the class of objects, {M}, that can be named with elements of {NS}
Note 1 to entry: This is sometimes referred to as the scope of the name space.
Note 2 to entry: This can also refer to actual objects or the potential for objects to be created.
3.56
service data unit
SDU
contiguous amount of data passed by an application process or IPC-Process in an IPC API primitive with
integrity preserved during delivery to a corresponding application process protocol machine (AP PM)
© ISO/IEC 2023 – All rights reserved

3.57
service data unit protection
SDU protection
interprocess communication (IPC) (3.39) function that protects service data units (SDUs) (3.56) from
being given to the (N-1)- distributed IPC facility (DIF) (3.32) for delivery
Note 1 to entry: SDU protection may include (but is not limited to) integrity preservation, encryption, time-to-
live functions and confidentiality.
3.58
synonym
multiple names assigned to the same object
3.59
unbinding
breaking the binding (3.16) between a name and an object
Note 1 to entry: Once unbound, any reference will not access any object.
3.60
user data
portion of a protocol data unit (PDU) (3.49) that is not interpretable by the protocol machine (PM) (3.50)
and is delivered transparently to its destination application process (AP) (3.9) as a service data unit
(SDU) (3.56)
3.61
whatevercast name
identifier that is the name of a set, usually taken from a name space (3.43) from the same name space as
the members of the set with an associated rule
Note 1 to entry: When the name is referenced, the rule is used to select names from the set.
Note 2 to entry: Traditional multicast and anycast names are specific forms of whatevercast.
Note 3 to entry: A unicast name or address (3.1) can be considered as a degenerate case of a whatevercast name
where there is only one element in the set.
Note 4 to entry: No assumptions are made about the static or dynamic membership of the set.
4 Symbols and abbreviated terms
AE Application-Entity
AEI Application-Entity-Instance
AEI-id Application-Entity-Instance-Identifier
AP Application-Process
API Application Programming Interface
CACEP Common Application Connection Establishment Procedure
CDAP Common Distributed-Application Protocol
CEP-id Connection-Endpoint-Identifier
DTCP Data Transfer Control Procedures
DTP Data Transfer Procedures
© ISO/IEC 2023 – All rights reserved

DA Distributed-Application
DAF Distributed-Application-Facility
DAN Distributed-Application-Name
DAP Distributed-Application-Process
DIF Distributed-IPC-Facility
DMS Distributed Management System
DTP Data Transfer Procedure
DTCP Data Transfer Control Procedure
EFCP Error and Flow Control Protocol
FA Flow-Allocator
FAI Flow-Allocator-Instance
IPCP IPC-Process
IPC InterProcess Communication
IRM IPC Resource Manager
MT Multiplexing Task
NS Name Space
PCI Protocol-Control-Information
PDU Protocol-Data-Unit
PM Protocol Machine
QoS Quality of Service
RA Resource Allocator
RIB Resource Information Base
RINA Recursive Inter-Network Architecture
SDU Service-Data-Unit
5 Basic concepts of distributed applications
5.1 Introduction to distributed applications
A Distributed-Application is a set of two or more Application-Processes that can cooperate to perform
some function. A set of AP Instances, a Distributed-Application Facility (DAF) and the members of the
DAF are called Distributed-Application-Process Instances (DAP-Is).
There are several kinds of DAFs that are useful in providing infrastructure for DAF operations. The
most important of these are DAFs that provide Inter-Process Communication. These DAFs are called
Distributed IPC Facilities (DIFs) and are discussed in much greater detail in Clause 6. DIFs are necessary
when IPC using shared memory synchronization is not possible. Other DAFs of interest are Management-
DAFs for managing both DIFs and DAFs (see 5.2, 5.3 and Annex A).
© ISO/IEC 2023 – All rights reserved

Application processes or DAPs in the same processing systems may use different DIFs of the same or
different rank, with maybe different scopes. All communicating Application-Process Instances are,
by definition, part of a DAF. DAFs operate over any (N)-DIF that they have access to and which has
sufficient scope to communicate with the members of the DAF.
5.2 Naming concepts for Distributed-Application Facilities (DAFs)
A DAF is a set of (two or more) cooperating Application-Process Instances. A DAF is assigned a
distributed application-name (DAN). There may also be distributed application instance identifiers
(DAII) if there are multiple instances of the same DAF.
The DAN is a whatevercast name of a set that contains the DAP-Names of all of the DAPs in the DAF and a
rule to select a subset when the name is referenced. A DAF may have more than one whatevercast name
that has different access control and different rules. When an Application-Process joins a DAF, it may
also be assigned a synonym (or alias), which is only unambiguous within the scope of the DAF and may
be structured to facilitate its use within the DAF. More than one set of synonyms may be assigned to the
DAP-Is. Different sets of synonyms would be used independently within the DAF for different purposes.
An Application-Process may have access to several DIFs, but not all DIFs in a processing system.
When a DAF is created, at least two whatevercast names for the set of all members of the DAF are
created:
a) one has the rule to return all members of the set, i.e. a multicast name;
b) one resolves to a single member.
This latter whatevercast name has a rule that may be the “nearest” member (for some concept of
nearest) or a designated member. This name should have a supporting DIF in common with the DAP-I
resolving the name.
The RIB Daemon manages the mapping between namespaces this level presents to its users, among any
internal naming, and between any internal namespaces and the namespaces provided by the supporting
level, e.g. it translates the logical “where” of this layer into the “physical” “where” of the layer below. The
scope of the namespaces supported by a DAF to its users may be greater than the scope of any one DAF.
5.3 Elements of a Distributed-Application Facility (DAF)
5.3.1 Overview
5.3.1.1 General
DAFs have common elements. Application processes have infrastructure to manage their local
resources: task scheduling, memory management, and IPC. A DAF has the same four components, but
with the difference that they are distributed.
Potentially each DAP has tasks to perform the same three management components for the DAF. They
coordinate with their peers to support the operation of the cooperating tasks that make up the DAF. In
the case of the DAF, the DAF Management task may have a range of functionality from merely providing
access to management data to a distributed management functionality.
— Task scheduling (Resource Allocation) may send work to different members for execution, either
because they have unique capabilities, e.g. print a document, or for load balancing. In a DIF, routing
and resource allocation are Task Scheduling policies.
— Memory management (RIB Daemon) has the dual role of ensuring information is available to tasks
in a timely manner and ensuring that the distributed data of the DAF is managed. The former
may entail periodic retrieval and/or distribution of information, either periodically or on specific
events and maintaining a given level of replication, synchronization, etc. In networking terms, this
combines what has traditionally been known as routing update and event management.
© ISO/IEC 2023 – All rights reserved

— IPC Management manages the underlying communication resources used by the DAP and its
tasks, ensuring that tasks have flows with given quality of service. IPC Management balances the
communication requirements of the tasks with the efficiency requirements of the DAF.
— DAF Management is concerned with DAF enrollment and overall management, similar to the
management agent.
5.3.1.2 Task scheduling
This DAF infrastructure task is responsible for coordinating processing load among the members of the
DAF. For DIFs, the function is routing and resource allocation.
5.3.1.3 Memory Management (RIB Daemon)
The RIB is the logical view of the local information relative to the function of the DAF. For a DAF,
Resource Information Base (RIB) is the logical representation of the local repository of the objects.
Each member of the DAF maintains a RIB. A Distributed-Application may define a RIB to be its local
representation of its view of the distributed application. From the point of view of the OS model, this is
storage.
A common component is a RIB Daemon, from which other tasks may request information held by other
members of the DAF either on demand, on an event, or periodically. The RIB Daemon can then optimize
these requests for information.
The term “RIB” is used very loosely and need not imply a complete Object Manager or database system.
It is just interpreted as a generic term for DAF-related storage without constraining the range of
implementation.
The role of the RIB Daemon, as it is with Memory Management, is to make data in the application’s
name space available as efficiently as possible and to delay the tasks using the data as little as possible.
A RIB Daemon manages the maintenance of information and its veracity for the DAF, i.e. the degree of
veracity, the aging of replicated data, ACID properties if any.
The tasks of DAF members should be able to register subscriptions with the RIB Daemon to have
information collected from or distributed to a set of members of the DAF on a periodic or event driven
basis.
Consideration in the design of a DAF should be given to making the RIB Daemon the only generator
of application SDUs to the underlying DIF. This not only allows better optimization and control, but
facilitates the shift from an IPC model to a programming language model. Hence, the work of the DAF
can be expressed entirely in terms of operations on the RIB.
5.3.1.4 IPC management
The IPC Management task manages the use of supporting IPC resources, i.e. an underlying DIF, by the
tasks of the DAP. The primary functions of IPC Management are:
a) SDU Protection, protecting the integrity and confidentiality of communication, appears in the
DAF so that application data can be protected from compromise by the top-level DIF. This module
provides any required protection for the SDUs this distributed application may pass to an IPC
facility, distributed or otherwise. Any data corruption protection over the data and PCI including
life-time guards (e.g. TTL, hop count) and/or encryption are performed here. SDU Protection may be
different on each allocated flow. It is strongly recommended that all DAF flows have confidentiality
and integrity protection.
b) Multiplexing SDUs from multiple DAP tasks onto one or more supporting flows, or more than one
supporting flows onto a single stream to a DAP task. The DAF may have policies for multiplexing
multiple allocation requests onto the supporting DIF, maintaining pools of flows, etc. It is also
possible for the DAF to support reverse multiplexing, i.e. combining several incoming flows into a
© ISO/IEC 2023 – All rights reserved

single flow. This may require a policy for marks to be inserted in the data stream for synchronizing
across the flows.
c) IPC Resource Manager (IRM) provides the policy coordination among the elements of IPC
Management of a DAF. The primary role of the IRM is managing the use of supporting DIFs and in
some cases, participate in creating new DIFs (for more detail, see Clause 6).
d) DIF Allocator Agent. When IPC Management receives an Allocate Request for IPC resources, if
the IRM fails to find the requested application supported by any of the DIFs available to it, it will
consult the DIF Allocator to find a DIF that does support the requested application. The result of
consulting the DIF Allocator will be to join a DIF. Whether this requires the creation of a new DIF
will be determined by the DIF Allocator interacting with the Management Systems responsible for
the resources required to create new IPC-Processes.
Flows managed by IPC Management are with specified AP-names. These AP-names may be primitive, or
names of sets, i.e. whatevercast names.
Each of these tasks coordinates with its peers in the DAF. When a new member joins a DAF, it is made
a member of a whatevercast set with a “for all” rule. There is at least a multicast group consisting of
all members of the DAF. The number of flows required for this coordination depends on the DAF, i.e.
all coordination can be over a single flow, or each can have a dedicated flow, or something in between.
Flows can exist only with “nearest” neighbours, parent/child structures, fully-connected, etc. If a
DAF uses multiple management flows internally, it is more likely that they will be allocated to better
optimize performance and load, rather than functional differences.
5.3.2 DAF security principles
The primary task of security for DAFs is to protect itself from malicious attacks or the collection of
sensitive information about its operation. There are five security services that may be supported by a
DAF: Authentication, Access Control, Confidentiality, Integrity, and Non-Repudiation.
All members of a DAF should be authenticated as legitimate members of the DAF (this is part of the
Enrollment Phase). While Access Control most commonly appears in the (N)-DIFs directly supporting
Applications, AE, IRMs may be used for the same purpose within a DAF. When a (N)-PDU is passed as
an (N-1)-SDU, and if confidentiality measures are in place, the (N-1)-SDU cannot be interpreted by the
(N-1)-IPC-Process, i.e. no elements of the (N)-SDU are clear-text. No identifier should be used for more
than one purpose. Multi-level security is a DAF issue. Any method to support multiple levels in the DIFs
below violates security by distinguishing multiple levels of security. A DAF is a securable container. The
security level of the  DAF depends on the policies used.
5.3.3 Common Distributed-Application Protocol (CDAP)
5.3.3.1 General
The Common Distributed-Application Protocol (CDAP) is a platform for building all distributed
[4]
applications . The use of CDAP is to make a clean transition from the IPC model of the DIF to the
programming model of DAFs. While only a single application protocol is required, the CDAP protocol is
constructed from modules (see ISO/IEC 15954). The modular approach is taken for two reasons:
— to provide flexibility in accommodating legacy protocols;
— to accommodate better “language support” in the future.
5.3.3.2 Basic form of CDAP
The basic form of CDAP consists of three components:
[5]
— the common application connection establishment procedure (CACEP) ;
— the authentication module;
© ISO/IEC 2023 – All rights reserved

----------------------
...