vents, the elements are either abstract machines, service objects or operation implementa- tions. If they communicate by abstract data, they are OSI applications. If they com- municate by messages, they are message protocol elements. The corresponding Fid is either an SEid, an object identifier (OBid) or an operation identifier (OPid). event Chain terminator Event handlers destFidlevData Relaying element O/T/(R) O/T/R O/T/(R) (part of integrator) association A, B, C, D Fids O Origination Protocol element evData Event data T Termination destFid Destination Fid R Relaying Fid Functional identifier Fig. 5.39 A relaying chain Figure 5.39 shows a possible PDU format for supporting one service element (B) to access another (E). The O/T/R function in the intermediate protocol element will just relay the message, since it does not recognize the destination Fid (destFid). A relaying element in a protocol element needs only to know which Fid values can be terminated in its own element. If an incoming message refers a Fid value that is not recognized, the message is just relayed to next element. To support some error handling, protocol elements at the ends of the chain, chain terminators, must know that they are terminating the chain. If e.g. one protocol element sends a message referring to a Fid that is not recognized by any element in the chain, it will sooner or later end at a chain terminator. If the Fid is not recognized by this element either, it should send an error event back to the originating element. Note that chain termi- nators should also have relay capabilities, SO that relay chains can be extended. Often, one of the chain terminators is a master and all the other elements are slaves. This is particularly SO when the functionality of a chain supports communi- cation over an external interface that is handled by the master. Figure 5.40 shows an example. All events are between the master and the slaves. In that case, the relaying protocol comprises only two message types: a downlink message (d, mas- ter to sla