Synchronous Channel

multicast message, this protocol ensures that no member delivers the message so that the omission failure is perceived consistently. Thus, the application can trade reliability for improved timing guarantees while agreement is still guaranteed.

4.3.4.3 Dynamic Group Extensions

Supporting dynamic groups only requires minor changes of the protocol. Yet, changes in the membership have two implications:

1. The bound ∆Round on the duration of a round can no longer be computed assuming n to represent the fixed number of group members. Instead, n represents an upper bound on the number of members.

2. Changes in the membership M(t) imply that the set of stations from which the AP expects acknowledgments changes also. Stations that are added to M(t) after the AP transmitted a multicast m for the first time are not guaranteed to deliver m. In fact, such stations may or may not deliver m. It is the job of the atomic multicast protocol to achieve agreement in this case.

is stopped, it delivers no decisions at all. We say that a station is joined if it is not crashed and the service at that station is in state joined. When the service changes from state joined to state stopped, it sends an indication FAIL_ind to its user. Now, since a stations is only required to deliver the AP’s decisions while being joined, we define two properties to en-sure that a station is joined whenever possible. The first property (Bounded Join Delay, Property 4-18) requires a valid station to become joined in bounded time after it started joining. The second property (Justification of Fail Notifications, Property 4-19) ensures that a station does not arbitrarily change its service state to stopped; that is to say, it only leaves state joined if there has been an interval of time since it became joined during which it has not been valid.

For the formal definition of the properties, we assume that all decisions the AP multicasts can be distinguished. There are known constants ∆SynchCh and ε such that the following properties hold.

Property 4-17 (Validity): For all stations si, all decisions d, and all times t, if the AP mul-ticasts d at t and si is joined throughout [t, t + ∆SynchCh + ε], then si delivers d by t + ∆SynchCh.

Property 4-18 (Bounded Join Delay): For all stations si and all times t, if si starts joining at t and si is valid throughout [t, t + ∆DNSjoin + ∆SynchCh], then si is joined by t + ∆DNSjoin + ∆SynchCh.

Property 4-19 (Justification of Fail Notifications): For all stations si and all times t', if si

signals FAIL_ind at t', then there is a time t such that t < t' and si is joined throughout [t,t'[

and not valid during [t,t'[.

To define the ordering property of the protocol, let ≺i denote the transitive reduction of the delivery order of the decisions as observed by si. That is, for any two decisions d and d', d ≺i d' if and only if si delivers d before d' and no other decisions in between. The first decision si delivers after joining the group is defined to have no predecessor in ≺i. Let fur-thermore dk, k ∈ N, denote the sequence of decisions as the AP multicasts them. Since the AP multicasts exactly one decision during each slot, dk is the decision the AP multicasts in slot k.

Property 4-20 (Strong FIFO): For all stations si, all decisions d, d' and all k ∈ N, if d ≺i d' and d = dk, then d' = dk+1.

We added the adjective “strong” because the property not only requires that if a station delivers two decisions, it delivers them in the order in which the AP multicast them, but also that the station delivers all decisions the AP multicast between these two decisions.

This means that this property does not permit gaps within the sequence of delivered deci-sions at any station. The service fulfills the properties of Integrity and Timeliness too. As the properties are very similar to the corresponding properties stated in the previous sub-section, we do not provide a formal definition here. Mainly, the time bound now is ∆SynchCh

instead of ∆RelMC.

Additionally, the service delivers an ID denoting the member to which the decision relates together with each decision.

4.3.5.2 Operation of the Protocol

Each time before the AP sends a mc frame, the synchronous channel protocol solicits its user to multicast a decision. As the synchronous channel is designed as a small bandwidth channel, there are only a small number of possible decisions, which can be coded in a few bits. Each decision relates to the member on behalf of which the mc frame is sent; that is, it relates to the owner of the corresponding entry in the polling list. The protocol piggybacks a sequence sy of OD+1 decisions on each mc frame the reliable multicast protocol sends (cf. Figure 4-20). When the AP multicasts a decision di the protocol inserts it at position 0 in the sy field and piggybacks the sy field on the mc frames. When the next mc frame is sent during the following slot, the protocol shifts all decisions in the sy field to the next higher position so that a further decision can be inserted at position 0. Thus, in this mc frame, decision di is transmitted at position 1 of the sy field. Accordingly, di is transmitted at position 2 during the next slot and so forth. Therefore, each decision is transmitted at positions 0,1, …, and OD in the sy field of OD+1 consecutive mc frames. Each valid member receives and processes at least one of these mc frames no more than

∆SynchCh := OD × ∆Slot + δm time units after the AP multicast the decision.

Figure 4-20. Transmission of decisions in the synchronous channel

Whenever a station receives a sy field piggybacked on a mc frame, it delivers exactly those decisions the AP multicast since the station received the last mc frame. The station uses the global sequence numbers in the mc frames to decide which decisions in the sy field it must deliver. For example, if the last mc frame the station received carried sequence number 25 and the one it currently processes has sequence number 28, the station delivers the deci-sions at positions 2, 1, and 0 in the sy field. These are the decideci-sions the AP multicast before sending the mc frames with sequence numbers 26, 27, 28. Note that this protocol not only ensures that valid members deliver each decision the AP multicast exactly once, but also that they deliver the decisions in the order in which the AP multicast them. Using the se-quence numbers, stations can also find out if they lost more than OD mc frames consecu-tively. This is the case, if the difference between the last received sequence number and the

current one is greater than OD+1. A station that lost more than OD mc frames consecu-tively lost some of the APs decisions in the synchronous channel also. To adhere to the Strong FIFO and Validity properties, such a station stops delivering decisions, changes to service state stopped, and delivers a failure indication.

For the synchronous channel to be useful, stations must be able to find out which members the decisions of the AP relate to. This is because the decisions made by the atomic multi-cast and the membership protocol ― the two users of the service ― either relate to the members themselves or to their atomic multicast messages. Hence, we require the protocol to deliver with each decision a member ID that identifies the member the decision relates to. Let m0, …, mn-1 be the stations in the membership view of the AP in the order in which they appear in the polling list. When the AP multicasts a decision on behalf of a member mi, the synchronous channel protocol delivers the ID i of that member together with the decision. In static groups, stations can easily determine the IDs in the following way: Since the AP sends mc frames for the members in a round-based manner, the decision dk relates to member mk mod n. Thus, the clients are able to determine the ID IDk to be delivered with decision dk iteratively starting with ID0 := 0 and setting IDk := IDk-1 + 1 mod n each time it has delivered a decision.

In contrast to the reliable multicast protocol where we advocate a dynamic redundancy approach for sake of efficiency, we use static redundancy for the synchronous channel. The reason for using two different approaches in the two protocols is the difference in the amount of data to be transmitted. In particular, the reliable multicast messages (possibly several hundred bytes), which are the SDUs of the reliable multicast protocol, are by far larger, than the decisions (currently, only three bits), which are the SDUs of the synchro-nous channel protocol. While the dynamic redundancy approach allows saving retransmis-sions of SDUs, it also introduces overhead for the transmission of acknowledgments. Sav-ing retransmissions of SDUs of several hundreds bytes warrants the overhead of the ack field. By contrast, saving retransmissions of some three-bit decisions does not warrant ad-ditional overhead. Hence, we decided to use static redundancy to implement the synchro-nous channel. With this approach, we efficiently realized a reliable and timely simplex channel that enables the AP to transmit essential decisions relating to the members. This is a valuable internal service for higher layers, as will turn out in the following sub-sections.

4.3.5.3 Dynamic Group Extensions

In a dynamic group, determining the ID to be delivered with a decision gets more sophisti-cated. The size n of the membership, which is used to determine the IDs at the clients, is no longer fixed but subject to change. Therefore, the stations must be notified when the size of the membership changes. To this end, the protocol itself uses the synchronous channel.

When a client is added to or removed from the membership view of the AP, the protocol multicasts a new or exclude decision respectively in the synchronous channel. Each mem-ber receives this decision and is therefore able to adjust its current view of the memmem-bership size accordingly. As an example, let us consider a situation where the membership size was 5 right from the start and where the protocol entity at some client is processing deci-sion d25, which is an exclude decision. The client iteratively updates the member IDs as described above and hence knows that ID25 = 0. The first thing the member learns is that the new membership size n' is 4. Furthermore, knowing that the member m0 with ID 0 has been removed from the membership, the protocol entity can deduce that the successor m1

of m0 in the old membership has ID 0 in the new membership m0',…,m3', where mi' = mi+1. Generally, when a member with ID IDi-1 is excluded the next decision relates to IDi := IDi-1

mod n'. Let us now assume d25 were a new decision. First, the protocol learns that the new membership size n' is 6. Furthermore, the next decision relates to the member with ID 1 because it is the successor of the new member in the new membership m0',…,m5', where mi'

= mi-1 for i ∈ 1..5 and m0 is the new member. Generally, when a new decision relates to IDi-1, the next decision will relate to IDi = (IDi-1 + 1) mod n'. Thus, using the synchronous channel itself, the protocol can determine the member IDs decisions relate to a dynamic group also.

The protocol provides a notification service at the clients that informs the higher layers of additions to and exclusions from the membership. Thus, the protocol not only uses the transmission of new and exclude decisions internally, but also exploits them to offer a noti-fication service to higher layers.

To determine member IDs in dynamic groups, it is not only necessary to inform current group members of changes in the membership, but also to provide the information they need to initialize the protocol to joining stations. In particular, a joining station must learn the following information to take part in the protocol: (a) the current membership size and (b) a pair of a decision dk and the corresponding member ID IDk, which together serve as a starting element for the iterative computation. To initialize joining stations, the AP piggy-backs the required information on the mc frames it sends. In more detail, when the protocol entity at the AP learns that a station was added to the membership, it transmits in the fol-lowing OD+1 mc frames not only the sy field but also the current membership size and member ID. The joining station will receive at least one of these frames. Suppose it is the frame with global sequence number k and that it carries the member ID ID and the group size gs. The joining station knows that the first decision in the sy field of that frame, that is, dk, relates to the member ID IDk := ID. Once the station knows this starting point and the corresponding membership size, it can iteratively determine the IDs while processing the decisions in the synchronous channel. After performing this initialization, the protocol sets the service state to joined.

The protocol uses piggybacking and static redundancy to transmit initialization informa-tion to joining stainforma-tion. The addiinforma-tional overhead appears to be acceptable since (a) it only becomes effective when stations join the group and (b) neither the membership size nor the member ID will incur too much overhead in the frame when efficiently coded. Each join-ing station that is valid for ∆SynchCh time units after being added to the membership will receive at least one of the mc frames carrying the initialization information and will there-fore turn its service state to joined.

Stations are able to detect if they are not able to provide a valid service. As explained above, by computing the difference of the sequence numbers of two consecutively received mc frames, a station is able detect if it observed more than OD+1 omissions. Since deliver-ing decisions in this case would imply gaps in the delivery order of that station, it does not deliver any decision at all and turns its service state to stopped. Furthermore, the stations use a timeout to be able to indicate their failure in case they receive no more frames at all.

The length of the timeout is set to ∆SynchCh(1+ρ), where ∆SynchCh is an upper bound on the inter arrival time of two mc frames at a valid station and (1+ρ) accounts for the drift rate of the client’s clocks. Since reacting to the timeout may additionally take up to ∆sched time

units, the duration between the reception of the last mc frame and the time when the station changes to service state stopped is bounded by

∆'SynchCh := ∆SynchCh(1+ρ) + ∆sched . Thus, the constant ε in the above definitions can be computed as

ε = ∆'SynchCh - ∆SynchCh = ∆SynchChρ + ∆sched .