1 Introduction
An interaction
is a way in which communicating processes can influence one another. Interactions in the time of the World Wide Web and of the Internet of Things (IoT) are something more than input and output between two entities. Actually, the word itself can be misleading, by suggesting a reciprocal or mutual kind of actions. Instead, interactions more and more often involve many parties, and actions are difficult to classify under output and input primitives. This is a common situation when, e.g. a client interacts with a website that in turn invokes some services from other websites. At a certain level of abstraction it is important to know which are the involved services, while it is not important how they are contacted. This practice follows the “separation of concern” modelling style, where the modeller is not interested in the details of “how” (with how many synchronisations, for example) the interaction takes place as long as a specific phase of the overall procedure is concluded with success. Intuitively, we can imagine an interaction as the composition of a jigsaw puzzle: all partners provide different pieces that fit together to complete the picture.
Networks have become part of the critical infrastructure of our daily activities (for business, home, social, health, government, etc.) and a large variety of loosely coupled processes have been offered over global networks, as services. As a consequence, more sophisticated forms of interactions have become common, for which convenient formal abstractions are under investigation. In this regard, one important trend in networking is moving towards architectures where the infrastructure itself can be manipulated by the software, as in the Software Defined Networking (SDN) approach DBLP:journals/pieee/KreutzRVRAU15 . Software clients can remotely access and modify the control plane, by using standard open protocols such as OpenFlow.^{2}^{2}2See, e.g. the Open Networking Foundation website http://www.opennetworking.org. In this case, it is therefore possible to decouple the network control from dataflow and from the network topology and to provide Infrastructure as a Service (IaaS) over datacenters, cloud systems and IoT.
Another example, coming from a completely different research field, is that of complex biological interactions as the ones emerging in biocomputing and membrane systems, where interactions typically involve several compounds and catalysts.
As a consequence, from a foundational point of view, it is strategic to provide the convenient formal abstractions and models to naturally capture these new communication patterns, by going beyond the ordinary binary form of communication, here called dyadic. These models should be sufficiently expressive to faithfully describe the complex phenomena, but they have also to provide a basis for the formal analysis of such systems, by offering sufficient mathematical structure and suitable abstraction mechanisms for tractability.
We present here a process algebra, called CNA, which takes interaction as its basic ingredient. The described interactions are multiparty, i.e. they may involve more than two processes and are open, i.e. the number of the processes they involve is not fixed or known a priori. This is not to be confused with multiparty interactions represented as a global choreography DBLP:conf/popl/HondaYC08 ; DBLP:journals/csur/HuttelLVCCDMPRT16 , whose realisation is still based on dyadic interactions. Traditionally in process algebras, communication is based on synchronisation send/receive on specific channels. In CNA, instead, communication actions are given not in terms of channels but in terms of links that record the source and the target ends of each hop of interactions. Links can be indeed combined in link chains in order to describe how information can be routed across processes before arriving at destination. Note that links can be combined if they are to some extent “complementary”, i.e. if each process contributes with links that are compatible, if not necessary, with the chain of links provided by the other processes. According to the puzzle analogy, different parts of a chain can be composed separately, and, afterwards, assembled by superposition without overlays.
To help the intuition, we can see links as Zshaped tetrominos that can be joined together along a line when the labels of the edges match (see Figure 1).
Despite the inherent complexity of representing more sophisticated forms of interaction, we show that the underlying synchronisation algebra and name handling primitives are quite simple, being a straight generalisation of dyadic ones. This is witnessed by the operational semantic rules of our calculus that, in their simpler version (i.e. without message passing), resemble the rules of CCS DBLP:books/daglib/0067019 , while in the full one, not considered here (see BodeiBB12 ), they resemble the ones of calculus pi . In this sense, CNA processes can be seen as running over a dedicated middleware that guarantees a proper handling of links, in the same way as CCS and calculus processes can be seen as running over a middleware that guarantees a proper handling of pointtopoint messaging (e.g. messages are not lost).
Finally, we address a more technical issue, by providing a convenient abstract semantics, called network bisimilarity for CNA processes, which is the analogous of strong bisimilarity for CCS processes. Remarkably, network bisimilarity is a congruence w.r.t. all useful composition operators and also w.r.t. substitutions, a feature mostly missed in other frameworks.
Synopsis
In Section 2, we recall the basics of CCS, although we assume the reader has some familiarity with process algebras. Furthermore, we illustrate a simple scenario of a modular network infrastructure that will serve as a running example to demonstrate that the level of abstraction provided by CNA is much more convenient w.r.t. the one provided by processes with dyadic interactions.
In Section 3, we present the theory of link chains, to be used as labels in the operational semantics of CNA. The theory is quite rich, as it consists of several key operators for building and manipulating link chains. Some nice properties of the introduced operators are also proved, which later will turn out useful to assess semantics properties of CNA processes.
In Section 4, we introduce the syntax and operational semantics of CNA, together with some simple usage examples that should help the reader in understanding the driving principles behind our design choices. The key technical contribution in this section is the Accordion Lemma 7.
In Section 5, we close the loop by introducing network bisimilarity, the abstract semantics of CNA processes. We prove the main congruence results (see Theorem 13 and Proposition 17) and show how network bisimilarity fits well in the running example. Some variations are discussed by the end of Section 5.
Discussion of related work and some concluding remarks are in Section 6.
Some auxiliary results and the proofs of technical lemmata can be found in A.
Previous work
This article is the full version of the extended abstract in BodeiBB12 , where also the message passing version of CNA was presented, called linkcalculus. Here we focus on the core version of the framework and spell out its theory in full detail. It is worth mentioning that we have revised the definition of the equivalence on link chains that is the basis of network bisimilarity and introduced a finer equivalence that considerably simplifies the proofs of the main properties. The motivating and running example is completely original to this contribution. Finally, we give here all proofs at a good level of detail.
The main contribution in BodeiBB12 was to show that the linkcalculus can be used to encode Mobile Ambients (MA) GC03 in such a way that there is a bijective correspondence between the reduction steps of MA processes and silent transitions of their encodings in the linkcalculus. This was a much stronger operational correspondence than any available in the literature, such as the ones in Brodo11 ; B16 .
In BodeiBBC14 , following a similar line, we have provided an encoding of Brane Calculi C05 in the linkcalculus. In particular, we have shown that biologically interactions that usually involve several compounds can be naturally rendered by multiparty interactions. Furthermore, locality can be easily handled, without introducing any specific operator, just encoding any membrane compartment as a separate process.
2 Background on CCS and a Running Example
2.1 CCS: the Calculus of Communicating Systems
The Calculus of Communicating Systems (CCS) DBLP:books/daglib/0067019 was introduced by Turing Award winner Robin Milner in the early 1980s. It is based on the notion of processes that communicate on shared channels by executing actions and coactions over them. Without loss of generality, we can imagine them as input and output actions with synchronous dyadic interaction. Let be the set of channels and, by coercion, input actions. We denote by the set of coactions (i.e. output actions), with and let denote the set of observable actions ranged over by . We extend the barnotation to observable actions, by letting . We also fix a distinguished silent action and let denote a generic action. A channel relabelling is a function . It is extended to generic actions by letting and for any observable action . It is called a renaming when it is bijective.
A CCS process is then a term generated by the following grammar:
where is a channel relabelling function and is any constant drawn from a set of possibly recursive definitions of the form .
Roughly the process is the inactive process that cannot perform any action. The action prefixed process can execute the action and then behaves as . The operator introduces nondeterminism: the composed process can behave as or as , but once it performs an action as the option is discarded, and vice versa. The parallel composition of two processes, written , allows and to interleave their actions or to interact by performing complementary actions and : if this is the case, the synchronisation is represented as a silent action and the channel where it takes places is not recorded. The restricted process can perform all actions that can perform, except for actions and , which are blocked. The relabelled process can perform all actions that can perform, but they are relabelled according to , i.e. if can do an action then can do . Relabelling is very useful for reusing process components in different parts of the system just by changing the set of channels on which they operate. Finally, the constant behaves as if .
In some cases we shall use constants that are parametric on a set of channel names , written more concisely as , and that can be instantiated with actual names, as in or just for short. Similarly, we write for .
The operational semantics of CCS is given in the form of a Labelled Transition System (LTS), where the states are CCS processes and the transitions are labelled by actions. We write if can perform the action and behave as afterwards. The inference rules that generate the LTS are defined in the style of Structural Operational Semantics (SOS) as they are driven by the syntax of processes (see Figure 2.1).
For example, we have transitions such as , and . The interplay between restriction and parallel composition is interesting as it can be used to impose synchronisation on some channel. In fact, while for we have transitions such as , , and , among others, the process cannot perform any action labelled by and but can still perform the synchronisation , because actions cannot be restricted.
To keep the notation compact, we write when there exist some processes that we do not need to mention such that , and for .
Recursive definitions can be used to account for infinite behaviour. For example, if , then the process can do any finite sequence of actions terminated by an action , as in but it can also perform an infinite sequence of actions , as in
The main notion of equivalence for CCS processes is called strong bisimilarity and is denoted by . It is defined as the largest strong bisimulation relation, i.e. as the largest binary relation on CCS processes such that whenever we have that:

for any such that there exists such that and ;

for any such that there exists such that and .
Notably, strong bisimilarity is a congruence w.r.t. all the operators of CCS. Here we point out that it is not a congruence w.r.t. action substitution. For example, it is wellknown that strong bisimilarity reduces concurrency to nondeterminism, as . However, if we apply the (noninjective) substitution that replaces all the (free) occurrences of with to both processes we get , because the former process can do the silent step , while the latter process cannot.
Sometimes one wants to abstract away from silent transitions . Correspondingly weak bisimilarity can be considered instead of strong bisimilarity, where in the bisimulation game a single transition can be simulated by exploiting any number of silent transitions. Unfortunately, weak bisimilarity is not a congruence w.r.t. the choice operator and substitutions.
2.2 Software Defined Infrastructures
In this subsection we sketch four scenarios of increasing complexity together with their possible modelling in CCS. Once introduced CNA, in Sections 4 and 5, we will revisit these examples to show that they can be more conveniently accounted for in CNA.
The reference case study consists of a network infrastructure with requestor agents , servers and a routing infrastructure that regulates which requestors are connected to which servers in a way that is out of the control of agents and requestors. For the sake of simplicity, in the following we let .
[Blind routing] Initially, we keep the scenario as simple as possible: the idea is that a requestor can repeatedly request a service if there is a nonbusy server connected to it via . Let us suppose that connects with and , while only with . In CCS, the system can be readily modelled by the following recursive processes that run in parallel.
For example we can let the system be defined as
so that synchronisation is enforced for all the interactions between requestors and the infrastructure (on channels and ) and between the infrastructure and servers (on channels and ).
The routing depends on the state of the system. Suppose, for instance, that becomes busy and that sends a request to , according to the transition sequence with
This is perfectly admissible, but leaves thinking its request has been served, because the interaction with has taken place, while the server has not even received it.
[Acknowledged routing] To remedy the problem raised by the previous model, one can introduce some acknowledgement protocol, to ensure each agent that its request has been assigned to some server. The CCS model can thus be improved by redesigning the processes as follows:
For example we can let the system be defined as
where is defined as before.
At a very abstract level, we can view an infrastructure as an oriented graph with nodes on the left boundary and nodes on the right boundary: the assignment of a request from to the server is possible if is available and if there is a connection between the th node on the left boundary and the th node on the right boundary. Graphically, can be depicted as below:
This time, when is busy and interacts with the infrastructure on channel , the requestor blocks until the server becomes available and can accept the request by interacting on channel with . In fact, when this is the case, sends the acknowledgment on channel to .
[Composite, acknowledged routing] Now suppose that the infrastructure is not monolithic, and that it is instead obtained by composing some network infrastructures together, which is a necessity for complex systems.
To make the infrastructure compositional, we must make interaction symmetric on the two, left and right, boundaries, i.e. we must assume that servers also send some acknowledgement. Correspondingly, we set
Now the system can be depicted as below:
Now consider the case where is obtained by juxtaposing three other infrastructures , and defined as follows:
Note that does not forward any request coming from its first port. The resulting infrastructure is illustrated in the figure below:
In general, an assignment of a request to a server is possible only if there is a path of connections in the graph associated with the infrastructure. In the example, the requests coming from and can only be assigned to , as there is no path towards .
Unfortunately, it may happen that the routing of the infrastructure comes to a dead point. In the example, can forward the request from to on , but then is blocked because it will not be able to pass the request to on .
To remedy this, either all dead paths must be removed before the infrastructure is deployed or some deadlockdetection and backtracking mechanism should be put in place, which requires some additional efforts.
[Dynamic routing] Finally, imagine the situation where the infrastructure is software defined, in the sense that connections can be added and removed dynamically. This time statictime deadpath analysis is not possible at all, and the integration of this additional feature with the previous acknowledgement, deadlockdetection and backtracking mechanisms looks overly complicated.
3 A Theory of Link Chains
To address the challenges posed by the scenarios in Section 2, the idea is to move from dyadic interaction to multiparty one. Correspondingly, communication actions are given in terms of links and a single atomic interaction is possibly composed by more than one link. A link is a pair that records the source and the target sites of a communication, meaning that the input available at the source site can be forwarded to the target one . Links are suitably combined in link chains to describe how information can be routed across processes before arriving at their destination. Therefore, links are combined like pieces in a jigsaw puzzle, where each party contributes with its link. As explained in the introduction, we can think about links as Zshaped tetrominos that are joined together in a line when the labels of the edges match so to form a link chain. Standard I/O communication is made more accurate, by recording the route of information across several sites. Furthermore, link chains allow seamless realisation of multiparty synchronisations.
To achieve compositionality, we allow processes to provide link chains that are assembled just in part. Intuitively they correspond to puzzles where some, but not all, the pieces are present. As an example, Figure 3 shows a chain with a missing link from to .
In this section we present the underlying theory of links and link chains, posing the emphasis on the operations for combining them and on some relevant properties they satisfy.
3.1 Links
Let be the set of channels, ranged over by , and let be the set of actions, ranged over by , where the symbol denotes a silent action, while the symbol denotes a virtual (nonspecified) action (i.e. a missing piece of the puzzle according to the analogy proposed above).
[Links: solid, virtual, valid] A link is a pair ; it can be read as forwarding the input available on to , and we call the source site of and the target site of . A link is solid if ; the link is called virtual. A link is valid if it is solid or virtual. We let be the set of valid links.
Examples of non valid links are and , while both and are solid valid links. From now on, we only consider valid links.
As it will be shortly explained, the virtual link is a sort of “missing link” inside a link chain; it represents a needed link that can be supplied, as a solid link, by another link chain, via a suitable composition operation called merge (see below).
3.2 Link Chains
Links can be combined in link chains that record the source and the target sites of each hop of the interaction.
[Link Chain] A link chain is a finite sequence of (valid) links such that:

for any ,

.
The first condition says that any two adjacent solid links must match on their adjacent sites; it also imposes that, in particular, cannot be matched by . The second condition disallows chains made of virtual links only. A nonempty link chain is solid if all its links are so. For example, is a solid link chain, while is not solid.
In counting links in a chain we may decide to ignore or not virtual links.
[Length and size] The length of a chain , written , is the number of valid (virtual and solid) links that are in . The size of , written , is the number of solid links that are in .
For example, , while .
The following definition introduces an equivalence relation over link chains that equates two valid link chains if they only differ for the presence of virtual links only.
[Equivalence ] We let be the least equivalence relation over link chains closed under the axioms (whenever both sides are well defined link chains):
From the above definition, it follows that the chain size is invariant w.r.t. , i.e. implies that (although and can have different lengths). Furthermore, for a solid link and a link chain, we write if and only if is the only solid link that occurs in .
The following basic operations over links and link chains are partial and strict, i.e. they may issue (undefined) and the result is if any argument is . To keep the notation short, we tacitly assume that the result is if either one of the subexpressions in the righthand side of any defining equation is undefined, or if none of the conditions in the righthand side of any defining equation is met.
Merge
We remind that the virtual links in a chain can be seen as the part in the chain not yet specified, and possibly provided by another link chain when merged.
Two link chains can be merged if they are to some extent “complementary”, in the sense that: (i) they have the same length; (ii) each of them provides solid links that are missing in the other, and (iii) superimposed together they still form a link chain.
In particular, if there is a position where both link chains carry solid links, then there is a clash and the merge is not possible (undefined). Also if the merge would result in a non valid sequence, then the merge is not possible.
[Merge] For and , with and for any , we define their merge by defining the merge of two actions as follows:
and then taking its homomorphic extension to links and link chains:^{3}^{3}3As anticipated, we remark that in the defining equations for merge it is implicitly understood that: if for some , then ; if the sequence is not a link chain, then ; if or , then ; if , then .
Roughly, the merge is defined elementwise on the actions of a link chain, by ensuring that whenever two actions are merged, (at least) one of them is and that the result of the merge is still a link chain. Note that the merge is undefined if the link chains have different lengths.
Intuitively, we can imagine that and are two parts of the same puzzle separately assembled, where solid links are the pieces of the puzzle and virtual links are the holes in the puzzle and their merge puts the two matched parts together, without piece overlaps (see Figure 4).
Let , , and be three link chains of the same length . Then and can be merged to obtain . Similarly, and can then be merged to obtain: .
The merge operation enjoys some simple algebraic properties.
Lemma 1.
For any :

The merge of links and link chains is commutative and associative.

if and only if .

If is solid, then for any we have .
Finally, the following lemma about the composition of link chains will be exploited in Lemma 7 to prove that the operational semantics of CNA is insensitive w.r.t. the equivalence .
Lemma 2.
Let , , and be three link chains such that , then there must exist and such that and with .
Restriction
Certain actions of the link chain can be hidden by restricting the channel where they take place. Of course, restriction of is possible only if no pending communication on (like ) is present, i.e. only matched communication pairs, in intermediate positions, can be restricted (as in ).
[Matched Action] Let , with for . We say that an action is matched in if:

, and

for any , either or .
Otherwise, we say that is unmatched (or pending) in .
It follows from the definition that we say that is matched in also when does not appear at all in .
For instance, is matched in the sequence , while it is pending in the sequences and in .
[Restriction] Let , with with . We define the restriction operation by letting
where:
Restriction on links enjoy properties similar to the usual structural congruence laws for processes.
Lemma 3.
For any

if and only if .

if does not occur in .

.
Let and . Then, we have that , while , because does not occur in .
Finally, we prove a technical lemma, similar to Lemma 2 for the merge, that will be exploited in the proof of Lemma 7.
Lemma 4.
Let and be two link chains such that is defined and , then there exists such that and .
Renaming
The last operation that we present is called renaming and allows us to change, in a uniform way, the channel names appearing in a link chain. A channel renaming function is a bijection such that and .
[Renaming] Let , with with , and be a channel renaming function. We define the renaming operation by letting
It can be readily checked that channel renaming functions enjoy the following properties.
Lemma 5.
For any

if and only if .

.

.

.

If then .
We conclude this section by proving a last technical lemma that will be exploited in the proof of Lemma 7.
Lemma 6.
Let be a channel renaming function and be two link chains such that , then there exists such that and .
4 A Core Network Algebra
In this section we build on the theory of links and link chains to present the syntax and operational semantics of CNA.
4.1 Syntax
The CNA processes are generated by the following grammar:
where is a solid link (i.e. with ), is a channel renaming function, and is a process identifier for which we assume a definition is available in a given set of (possibly recursive) process definitions.
As usual, we write for tuples of channels and we allow parametric process definitions of the form , where is the set of free channels of . For brevity, in the examples, we sometimes write leaving implicit that the free channles of are the parameters of .
The extension in which generic link chains are allowed as action prefixes instead of solid links is discussed in Section 5.3.
It is evident that processes are built over a CCSlike syntax, with inactive process , action prefix , choice , parallel , restriction , renaming and constant definition , but where the underlying synchronisation algebra DBLP:journals/tcs/Winskel84 is based on link chains. This is made evident by the operational semantics that we present next.
As usual, binds the occurrences of in , the sets of free and of bound names of a process are defined in the obvious way and processes are taken up to alphaconversion of bound names. We shall sometimes omit trailing , e.g. by writing instead of .
CNA provides us with a natural way to rephrase the communication primitives of usual process calculi, such as CCS and CSP Hoare85 , in terms of links.

Intuitively, the output action (resp. the input action ) of CCS can be seen as the link (resp. ) and the solid link chain as a dyadic communication, analogous to the silent action of CCS.

The action of CSP can be seen as the link and the solid link chain as a CSPlike communication among three peers over .
4.2 Operational Semantics
The idea is that communication can be routed across several processes by combining the links they make available to form a link chain. Since the length of the link chain is not fixed a priori, an open multiparty synchronisation is realised.
Comments
There are no comments yet.