A Group Communication Framework
ABSTRACT This paper presents a general architectural model for group communications which are communications that may involve more than two parties. The concept of group is presented and the concept of group association, which is an instance of group communication, is analysed. Those group associations are modelled as a set of basic components called multicast conversations. At the service boundery, new architectural concepts are introduced to identify a group association as well as its multicast conversations. Then, facilities to handle the group associations and the multicast conversations are defined and the properties of data transfer on a group association are examined. Finally, the paper deals with aspects of group management. 1. Introduction One of the key issues to fulfil the requirements of modern distributed applications such as teleconferencing, multimedia distribution or client/server applications, is the efficient exchange of information between multiple entities, that is group or...
- SourceAvailable from: Roberto Canonico[Show abstract] [Hide abstract]
ABSTRACT: Despite its obvious suitability for distributed multimedia applications, multicasting has not yet found widespread application. Having analyzed shortcomings of today's approaches, we devise in the GCAP project a new end-to-end transport architecture for multimedia multicasting that supports partial order and partial reliability. In this paper, we argue that, at the network layer, single-source multicasting (PIM-SSM) should be chosen. Consequently, our Monomedia Multicast protocol provides, along with reliability and QoS monitoring functionality, an ALM based multicast solution referred to as TBCP (Tree Building Control Protocol), to be used as back channel for SSM, e.g. for retransmission requests. On top of the Monomedia protocol, our Multimedia Multicast protocol handles multimedia sessions composed of multiple monomedia connections: The FPTP (Fully Programmable Transport Protocol) allows applications to specify, through its API, the (global) synchronization and (individual) reliability requirements within a multimedia session. Our group management approach is focused on group integrity.08/2002;
- [Show abstract] [Hide abstract]
ABSTRACT: : In recent years computers have developed very rapidly from simple processing machines to sophisticated communication systems employing multiple media. Computers are imcreasingly used for all kinds of man-machine and interpersonal communication and co-operation. Many of these applications involve multiple communicating entities as well as multimedia. However, in general no sufficient support for multimedia group communication is yet available. In this paper we first analyse existing systems offering group support at different levels of the system and communication architecture. Subsequently a study on multimedia group application requirements is described. It is mainly concerned with highly interactive applications such as CSCW. The study is based on the examination of existing systems, system scenarios and ethnographical studies. To describe the multitude of characteristics and requirements of these applications in a structured and comprehensive way a set of group application charact...03/1996;
Broadband Islands ‘94: Connecting with the End-User
W. Bauerfeld, O. Spaniol and F. Williams, eds.
Elsevier (North-Holland), 1994, pp 167-178
A Group Communication Framework1
Laurent Mathy, Guy Leduc, Olivier Bonaventure, André Danthine
Institut d'Electricité Montefiore B28, Université de Liège, B-4000 Liège, Belgium
This paper presents a general architectural model for group communications which are
communications that may involve more than two parties. The concept of group is presented
and the concept of group association, which is an instance of group communication, is
analysed. Those group associations are modelled as a set of basic components called multicast
conversations. At the service boundery, new architectural concepts are introduced to identify
a group association as well as its multicast conversations. Then, facilities to handle the group
associations and the multicast conversations are defined and the properties of data transfer on
a group association are examined. Finally, the paper deals with aspects of group management.
One of the key issues to fulfil the requirements of modern distributed applications such as
teleconferencing, multimedia distribution or client/server applications, is the efficient
exchange of information between multiple entities, that is group or multipeer
Several proposals of multipeer service definitions exist . However these
documents do not use the same terminology and even when they do, it is not sure that the
same word has a unique semantics. Moreover, the incorporation of group communications
into the OSI reference model is only at an early stage. Consequently, the need for a general
architectural model for group communications has appeared.
This paper presents a general framework in which the basic general concepts associated
with group communications are identified and analysed. Those concepts are intended to make
up the core of an architecture designed to face the variety of the issues that can be
encountered in group communications. This framework is in no way intended to relate to a
particular layer of the OSI reference model. No attempt has been made to propose solutions
on how those concepts could be applied to particular problems and how protocol functions
could effectively provide them. However, it may serve as a basis for various instantiations or
designs of services with different levels of complexity.
This paper is structured as follows. First, we explain the concept of group. Then, we
analyse the concept of a group association that is an instance of group communication and we
focus on multicast conversations which are the basic components of group associations.
Finally, the group management policy is presented.
1This paper has been accepted at Broadband Islands '94.
2. The Concept of Group
A group is a set of entities. Those entities are called members of the group and are
allowed to participate in the communications between members of the group. The members
are identified by a rule which is the unambiguous description of the entities that are members.
Any entity that fulfils the conditions defined by the rule is a member of the group: being a
member is thus a state.
Aspects of group management will be treated later in section 4.
One of the main reason to create a group is the possibility to address it with a single group
address, that is to say seeing the group as a virtual single entity.
However, we do not consider that 'being a member of a group' necessarily means 'being
reachable by the group address'. A group member which has expressed (implicitly or
explicitly) its wish to be bound to the group address is said to be registered . The group
address is an alias for the list of the registered members' individual addresses.
The registered members make up the registered group. There is only one registered group
for a given group and only those members of the group that have performed registration are
reachable through the group address. A registered group is thus a subset of a group.
Let us take an example to illustrate this concept.
Assume a group - the example group - composed of five members (A, B, C, D and E). A,
B, C and D are registered members while E is not. If D, for instance, wishes to establish a
group communication, then it performs an establishment request specifying the group address
as destination address. As the group address is an alias for the list of registered members'
addresses, only A, B and C receive an establishment indication, while E is not even informed
of the establishment of the group communication.
The reverse operation, that enables to 'untie' an individual address from the group address,
is called de-registration.
A rule specifies the way registration and de-registration are performed (see section 4).
3. The Concept of Group Association
An invocation of the group is needed to identify the subset of members that actually take
part in an instance of communication. This introduces the concept of group association
 which is an association established between a subset of members of the group for the
purpose of transferring data. A group association may thus have more than two endpoints
and is identified with a group association identifier so that several group associations may
simultaneously exist within a given group. Multipeer association is a synonym for group
The members that have accepted to participate in a group association are said to be
participants of that group association . Two classes of participants are then defined.
The participants that are in the state to take part in the data transfer phase of the group
association (participants that can exchange data units with the service provider) are said to be
active participants, otherwise they are said to be passive participants.
The set of active participants make up the active group of the group association.
As it is shown below, the two main characteristics of a group association are its active
group and its topology.
3.1. Active Group Characteristics
An active group may be characterised in several ways:
• a static active group is an active group where the membership must remain
fixed throughout the group association lifetime.
• a dynamic active group is one where the membership may change during the
group association lifetime.
• a determinate active group is one where the membership is known by some
or all participants.
• an indeterminate active group is one where the membership is not
necessarily known by any participant.
• an open active group is one where a non registered member of the group may take
part in. It should be clear that by definition of registration, a non-registered member
cannot be involved in a group association unless it first requests it.
• a closed active group is one where only registered members may take part in.
An active group can always be characterised by three qualifiers. Indeed, an active group is
either static or dynamic, either determinate or indeterminate and either open or closed.
On a group association established for our example group and whose active group is set to
open, any member could become an active participant. If the active group is set to closed,
then member E could never become an active participant.
An important concept which appears with the one of active group is the Active Group
Integrity (AGI) . AGI specifies conditions on the active group membership of a group
association. These conditions might be minimal ones, maximal ones or both (quorums, list of
mandatory active participants, and so on). When the AGI condition is not satisfied any more,
the group association is either released (hard AGI) or suspended (complete standstill of data
transfer=soft AGI) until all conditions are satisfied again.
An example of AGI condition is : "At least 4 active participants".
A connectionless group association has no AGI condition, because a receiver is identified
as active when it participates in the data indication primitive.
3.2. Topology of Communication
There is no a priori restriction on the topology of a group association . Hence, a
group association may look like the one on figure 1, where each set of identical oriented lines
represents a data flow. From this, it is clear that for a given active group, many different
topologies are possible. Therefore, the active group is not sufficient to completely
characterise a group association: the topology of the group association is needed as well.
Fig 1 Group association
3.2.1. Basic Components of Group Associations: Multicast Conversations
Let us now consider the basic components of group associations:
• (1!N) multicast conversation: an instance of communication with only one
participant being a sender and all the other participants being receivers and in which
the sender sends the same Service Data Unit (SDU) to the receivers in a single
invocation of the service provider. A (1!N) multicast conversation may be a
connection or not.
The term 'multicast conversation' has been chosen by extension of the concept of
multicast transmission that is defined as the transmission of a same data unit from one
sender to multiple receivers, in a single invocation of a service facility.
• (N!1) multicast conversation: an instance of communication with only one
participant being a receiver and all the other participants being senders and where the
receiver receives the SDUs without additional information, added by the service
provider, on their origin .
The mechanisms involved in such a multicast conversation are sometimes referred to as
(N!1) concentration , but we call it (N!1) multicast conversation because of its duality
with the previous case. In , the term 'concentration' implies that each delivered data unit is
a concatenation of N transmitted data units (one per sender), which we do not require.
From the above definitions, we see that a multicast conversation has a central endpoint.
The active participant associated with this endpoint is sometimes called the master of the
multicast conversation. The two kinds of multicast conversations are illustrated on figure 2.
(N!1) Multicast Conversation(1!N) Multicast Conversation
Fig 2 Multicast conversations
3.2.2. General Topology of Group Associations
In general, a complex group association such as the one on figure 1 can always be seen as
a set of basic components (1!N and N!1 multicast conversations).
A group association in which the master of every multicast conversation is the same
participant is called a centralised group association. If several participants are masters on
different multicast conversations, the group association is said to be a decentralised group
Several types of group associations are illustrated on figure 3 and described below.
A group association in which participants are clearly partitioned into two sets, namely
those with send-only capabilities and those with receive-only capabilities, is said to be a one-
way (or simplex) group association (fig 3a). A group association in which some participants
may act both as senders and receivers but can however be seen as partitioned into two sets
such that a participant in one set can only exchange SDUs with the participants in the other
set, is said to be a two-way (or duplex) group association (fig 3b). A group association that
is neither one-way nor two-way is said to be a N-way group association (fig 3c & 3d).
Group associations may thus have 'simultaneous' senders: if dialogue control is needed,
proper mechanisms are to be used to achieve it.
Fig 3 One-way, two-way and N-way group associations
The concepts of participants and of active group, and hence the one of AGI, may be
applied to a multicast conversation as well. In order not to confuse these concepts pertaining
to a group association and those ones pertaining to a multicast conversation, we call the latter
Multicast Conversation participants (MC-participants), Multicast Conversation Active Group
(MC-active group) and Multicast Conversation AGI (MC-AGI). A MC-active group is a
subset of an active group. The master of a multicast conversation is always implicitly a
mandatory MC-active participant.
The group association topology may be either static or dynamic . A static group
association topology is one where, during its lifetime, no multicast conversation may be
established nor terminated and where all the MC-active groups are static. A dynamic group
association topology is one where multicast conversations may be established and released
and where the MC-active groups may be dynamic, during the lifetime of the conversation.
As with the active group, conditions may be specified on the group association topology.
These conditions, which may be either minimal ones, maximal ones or both, are called the
Association Topology Integrity (ATI).
The ATI is composed of two kinds of conditions:
• conditions on each individual multicast conversation of the group association,
expressed in terms of MC-AGI (hard or soft).
• conditions on the whole group association in terms of multicast conversations
for which the MC-AGI must be verified (i.e. in data transfer phase).
If the conditions on the whole group association are not satisfied any more, the group
association is either released or suspended until the conditions are satisfied again. In the
former case, the ATI is said to be hard, in the latter case, it is said to be soft.
As the topology of a multicast conversation is completely known thanks to its MC-active
group membership, its master and its type (1!N or N!1), no ATI condition is required at the
multicast conversation level: the MC-AGI can express all the conditions imposed to the
To illustrate the use of the ATI conditions, suppose a group association established among
the members of our example group. Assume a hard ATI is specified as follows:
• for a (1!N) multicast conversation (MC1) on which the master is A, the hard MC-
AGI is: "member B is a mandatory active MC-participant". It should be noted that A is
also a mandatory active MC-participant but this is known implicitly since it is the
master of the conversation.
for each of three (1!N) multicast conversations (MC2, MC3, MC4) on which the
masters are respectively B, C and D, the soft MC-AGI is: "at least 3 active MC-
participants (quorum)", which means the master and at least 2 others.
• At least 1 multicast conversation.
In addition, suppose the specified hard AGI is: "At least 4 active participants".
If there are 4 active MC-participants on one of the MC, say MC3, then both the AGI (4
active participants) and the ATI (1 MC in data transfer) are fulfilled.
The AGI and the ATI are also verified in the following scenario:
MC3: 3 active MC-participants (C, A, D)
MC4: 3 active MC-participants (D, A, E)
As the union of both MC-active groups contains 4 active participants and there are 2 MC
in data transfer phase, both AGI and ATI are verified. It should be noted that, even though the
union of the MC-active groups makes up the active group of the association, the AGI
condition cannot be seen as a combination of the MC-AGIs.
Indeed, in our examples, B is mandatory on MC1 but does not appear to be mandatory for
the AGI to be fulfilled: if B is not an active participant, then MC1 is released but the group
association may still exist. It is thus clear that the AGI and ATI conditions are independent
from each other and that a hard AGI may be used with a soft ATI and vice versa.
Rules exist to define the characteristics of the group associations for a given group: those
rules concern the active group and the topology.
3.2.3. Identification of Group Associations
This view of a group association introduces the need to distinguish each basic component
separately at each Service Access Point (SAP), in order to be able to identify the component
with which a service primitive is associated. This may be realised by identifying locally each
component with a Conversation EndPoint (CoEP) and grouping them within a Group
Association EndPoint (GAEP) which allows the identification of the whole group association
at a SAP .
CoEPs and GAEPs are defined locally and are unique in the scope of a SAP. The
architecture of the SAP is illustrated on figure 4.
In contrast, the group association identifier is global. Moreover, an identifier, the scope of
which is the group association, may be required for each component so that members could
identify them separately and globally. The situation is summarised in table 1.
A CoEP is said to be active if it is in a state in which data units can be exchanged through
it, otherwise it is said to be passive.
A GAEP that gathers either CoEPs which are all passive or no CoEP, is said to be passive.
If the GAEP contains at least one active CoEP, it is said to be active. An active participant is
one associated with an active GAEP whereas a passive participant is one associated with a
Fig 4 Service Access Point (user involved in two GAs)
Global Id. Local Id.
Group Association (GA) GA IdentifierGAEP
scope = SAP
scope = GA
scope = GAEP
Table 1 Identifiers in group associations
For any association composed of only one basic component, the distinction between the
GAEP and the CoEP is no longer relevant. So, if the association is composed of a single peer-
to-peer simplex connection ((1!1) multicast conversation), the GAEP/CoEP may be called a
CEP. If the association is a duplex peer-to-peer connection (i.e. an association composed of
two simplex peer-to-peer connections), the GAEP is called a CEP. It is thus clear that the
model is backward compatible with the OSI Reference Model.
3.3. Facilities Defined at the Group Association Level
In this section, we will describe the facilities that apply to the group associations. This
section will then be followed by a section (3.4) describing the facilities that apply to the
multicast conversations of a group association.
3.3.1. Group Association Activation
The group association activation facility is used to establish a group association among
members of a group and to create the group association identifier.
The member that activates a group association is called the activator. The activator is a
member: not necessarily a registered member nor does it necessarily become a participant of
the group association.
If the rules defining restrictions on group associations (see section 4) allow alternatives for
some characteristics of the group association, those ones may be fixed by the activator at
activation time (staying within the bounds of the rules). If those characteristics are not set,
default values are taken into account.
In the case of peer-to-peer communications, a connection is considered as established if
the called party accepts the establishment. In the case of multipeer communications, several
registered members (the called parties) may accept the activation of the group association
while others may reject it. For the service provider to be able to decide if the activation is
successful or not, a condition needs to be verified. Such a condition, called the activation
condition, expresses constraints such as the minimum number or the mandatory acceptations
that must be performed in order that the group association be activated. The activation
condition is either specified by the activator or by default values (see section 4).
The effect of the activation on the group association is illustrated on figure 5(a).
On successful activation, the registered members that have accepted the activation of the
group association get a passive GAEP for it. Those that have rejected the activation have no
GAEP. The effect of the group activation at a GAEP is illustrated on figure 5(b).
No GAEPPassive GAEPActive GAEP
One active CoEP
No active CoEP
Fig 5 Facilities at the group association level
3.3.2. Group Association Deactivation
The group association deactivation facility is used to terminate a group association. The
deactivation may occur at any time and may be abrupt or not. It is destructive which means
that the result of the deactivation is that the group association does not exist any longer.
The effect of the group deactivation on the group association and on a GAEP are
illustrated on figure 5.
Activation and deactivation are implicit on a connectionless group association.
3.3.3. Group Association Join
The group association join facility is used to allow a member of the group to participate
in an on-going (i.e. already activated) group association.
On completion of the group association join, the member gets a passive GAEP for the
group association and is then a passive participant.
This facility may, for example be used by a non-registered member that wishes to become
a participant on a group association that has already been activated (remember that non-
registered members do not take part in the activation of a group association).
The effect of the group association join is illustrated on figure 5(b).
3.3.4. Group Association Leave
The group association leave facility is used to withdraw a participant from a group
association. On completion of the group association leave, the member is no longer a
participant of the group association and has no longer a GAEP for it.
When a member is removed from any group (registered or definition group), it is
automatically excluded from one or several group associations where it participated.
The group association leave may also be used to reject (service provider) or to cancel
(member concerned) a join demand.
The effect of the group association leave is illustrated on figure 5(b).
Group association join and leave are also implicit on a connectionless group association.
3.4. Facilities Defined at the Multicast Conversation Level
The four facilities described above apply to the group association as a whole and hence to
the GAEPs. Similar facilities also exist for the multicast conversations. Those facilities (MC-
activation, MC-deactivation, MC-join and MC-leave) can only be used by participants of the
group association to establish or release components of the association and to join or leave
However, just like what happens with the GAEPs, the MC-activation and MC-join
functions only result in passive CoEPs. That is why two other functions are required to
operate on the CoEPs: the MC-allocation and MC-deallocation. The effect of those facilities
on a CoEP is illustrated on Figure 6.
No CoEPPassive CoEP Active CoEP
Fig 6 Facilities at the multicast conversation level
The MC-allocation is used to turn the state of a CoEP from passive to active. Data units
can be exchanged through a CoEP only if the MC-allocation has been previously invoked for
it. The effect of the MC-allocation on a CoEP is illustrated on figure 6.
The MC-deallocation is used to turn the state of a CoEP from active to passive. The effect
of the MC-deallocation on a CoEP is illustrated on figure 6.
The MC-allocation and MC-deallocation always entail an AGI and ATI checking. If the
AGI or the ATI were transgressed by the allocation of a participant, this allocation would be
rejected; if one or both conditions were transgressed by the withdrawal of an active MC-
participant, the multicast conversation would be either deactivated or suspended.
However, the suspension of a multicast conversation does not mean that an active MC-
participant is returned to the passive state. It only means that the service provider will not
exchange data units with the active MC-participants until all the conditions are satisfied
MC-allocation and MC-deallocation are implicit on a connectionless component of a
It should be clear that there is no equivalent function relating to the GAEPs since the state
of a GAEP (and therefore of the associated participant) depends on the state of the CoEPs it
Finally, all the facilities described above may be subject to vote and/or notification .
3.5. Properties of Data Transfer on a Group Association
Once the AGI and ATI conditions are fulfilled, the group association enters (or re-enters)
data transfer phase. Only active participants are concerned with data transfer.
Data transfer on a group association is characterised by the data transfer characteristics on
each of its multicast conversations.
All data transfer semantics encountered in point-to-point communications directly extend
to multicast conversations.
A new feature of reliable data transfer that appears on a multicast conversation is the
degree of reliability :
• k-reliable (k ranging from zero to the total MC-active group size, but fixed) means a
SDU is received by at least k active receivers. A list of active MC-participants may be
associated with the degree of reliability to identify the k mandatory receivers.
• all-reliable means that all the active members must receive each SDU.
A special kind of all-reliable transfer is the synchronised transfer: at each moment, a data
unit is delivered to either all active MC-participants or to none of them. An unsynchronised
transfer does not have that feature .
The desired performance in data transfer may be specified through Quality of Service
(QoS) parameter values.
A multicast conversation is characterised by one set of QoS parameter values. QoS
parameters pertaining to different multicast conversations (within a same group association)
may be bound together so that they are negotiated the same way .
A feature that applies to the group association as a whole is the semantics of sequenced
data delivery :
• local ordering where the SDUs from a source are delivered to an active receiver in
the order they have been transmitted but where the order of the SDUs from different active
senders may be different from one active receiver to another.
• global ordering where the order of the SDUs is the same for all active receivers and
corresponds to the order the data have been provided to the service provider.
4. Group Management
As it has been shown earlier in the previous sections, rules are needed to define all the
characteristics of a group . These rules make up a group definition structure and are:
• the rule of identification of members.
• the rules that describe the abilities given to each member of the group. This rule
identifies the members that may activate and/or deactivate group associations and/or
multicast conversations, the members that may be sender and/or receiver on a group
• the rule specifying the way to perform registration.
• the rules that define group association characteristics (active group and
• the rules for group management policy, the identification of the entities which
may perform group management operations (called group managers) and their
attributions (see section 4.1). The group managers are not necessarily members of the
The creation of a group definition structure, made by the group creator, defines a phase
called 'group definition'. The cancellation of a group definition structure defines a phase
called 'group deletion'.
Entities which are not identified by any rules of the group definition structure have no
right on that group and its instances of communications.
4.1. Group Management Policy
The management operations on a group are performed by the group managers. Those
operations define a phase called 'group management phase' and are modifications of the rules
of the group definition structure. This phase may obviously have no sharp limits in time.
For each rule of the group definition structure, it must be stated whether it may be
modified or not and, on positive alternative, which group managers are allowed to perform
A group where all the management operations are performed by the group creator is said
to be a permanent group while a group where some or all management operations may be
performed by group managers (other than the group creator) is said to be a temporary group
. All the management operations which may be performed by managers may be subject to
vote and/or notification .
A group where management may be performed by a group manager which is not a
member of the group is said to be an open group. If management can only be performed by
members, the group is said to be a closed group.
A group whose membership cannot change (the rule of identification of members cannot
be changed) is said to be a static group, but if the membership may change during its
lifetime, it is said to be a dynamic group.
A registered group whose membership cannot change is said to be a static registered
group, but if the membership may change during its lifetime, it is said to be a dynamic
registered group. It should be clear that a dynamic registered group may be used with a
All the concepts presented in this paper are general. Any service of any layer of the OSI
reference model would probably be designed to provide some of the proposed facilities but
not all of them. In particular lower layers (transport layer and below) are likely to provide
restricted association forms such as (1!N) multicast conversations or group associations
composed of N identical components, each being a (1!N) multicast conversation (this
enumeration is not exhaustive) and in which group management might be provided in limited
The MPDT TS , the CIOMBTS  and the ETS  can be described within this
This work has been fully supported by the RACE project 2060 (CIO): "Coordination,
Implementation and Operation of Multimedia Services".
Transmission (MPDT), Ref: ISO/TC 97/SC21 N3287, 1988.
ISO/TC 97/SC21, Working Draft Addendum to ISO7498-1 on Multipeer Data
Ref: ISO/IEC JTC1/SC21 N6813, March 1992.
ISO/IEC JTC1/SC21, Draft Addendum for Multipeer Data Transmission (MPDT),
Ref: ISO/IEC JTC1/SC6 N7445, July 13,1992.
ISO/IEC JTC1/SC6, USA Contribution on Multipeer Data Transmission Service,
Multicast Work X.pms, Ref: ISO/IEC JTC1/SC6 N7179, February 22, 1992.
ISO/IEC JTC1/SC6, Liaison Contribution from CCITT SC VII to SC6 Regarding
Multipeer/Multicast Application Requirements, Ref: ISO/IEC JTC1/SC6 N7214, March
ISO/IEC JTC1/SC6, Request for Comments- Request for National Body Input on
ISO/IEC JTC1/SC6 N7883, January 13, 1993.
ISO/IEC JTC1/SC6, Specification of ETS, the enhanced transport service, Ref:
Transport Service Definition (HSTS) Specification, Ref: ISO/IEC JTC1/SC6/WG4 N806,
December 19, 1992.
US expert, ISO/IEC JTC1/SC6/WG4, Proposed Draft Text for a High-speed
Broadband Transport Service (M26a), Technical report from RACE Project 2060("CIO"),
September 10, 1993.
Henckel L., Multimedia Communication Platform: Specification of the Enhanced
Broadcast (M26b), Technical report from RACE Project 2060("CIO"), October 16, 1993.
Miloucheva I., Specification of Enhanced Protocol Facilities for Multicast and
 Waters A., Multicast Provision for High Speed Networks, in: Participant's
Proceedings of the 4th IFIP Conference on High Performance Networking, Liège, December
14-18, 1992, pp G1.1-16.
of Service Architecture (QOS-A) for Distributed Multimedia Communications, in:
Participant's Proceedings of the 4th IFIP Conference on High Performance Networking,
Liège, December 14-18, 1992, pp G2.1-14.
Leopold H., Campbell A., Hutchinson D., Singer N., Towards an Integrated Quality
Associated Functionalities, LGI-IMAG.
Bouat S., Scabello P., Sicard P., Diot C., A Survey of Multicast Protocols and
Network Service, Ref: ISO/IEC JTC1/SC6 N7433, June 25, 1992.
ISO/IEC JTC1/SC6, Proposed Multicast Extensions to the Connectionless-mode
in: ACM Transactions on Computer Systems, 1991, Vol.9, nr.3, pp 242-271.
Garcia-Molina H., Spauster A., Ordered and Reliable Multicast Communication,
Communications of the ACM, 1993, Vol.36, nr.12, pp 37-53.
Birman K., The Process Group Approach to Reliable Distributed Computing, in:
Service and the Group Communication Framework, Technical report from RACE Project
2060("CIO"), ref: R2060/ULg/CIO/IN/P/007, January 1994.
Mathy L., Bonaventure O., Danthine A., The CIO Multipeer Broadband Transport
 Mathy L., Bonaventure O., Leduc G., Danthine A., The Multipeer Data
Transmission Transport Service and the Group Communication Framework, Technical
report from RACE Project 2060("CIO"), ref: R2060/ULg/CIO/IN/P/008, January 1994.
Service and the Group Communication Framework, Technical report from RACE Project
2060("CIO"), ref: R2060/ULg/CIO/IN/P/009, February 1994.
Mathy L., Bonaventure O., Leduc G., Danthine A., The Enhanced Transport