rk, the master and slave must communicate by a set of operations. The operations that are used are annotated in Fig. 6.29. They consist of two groups of operations: Those that are used for handling connection setup on the slave side. All requests for connections come from TEPC. A connection may be needed between two CNUs on the master side, two CNUs on the slave side or between two CNU on each side. In the two last cases, the master must be able to request the slave set up connections to CNUs on the slave side. The ASP for this is: cnuConnRequest(Cl, CHOICE{LocalCon, RemoteCon) LocalCon::={TR-SAPI,TR-SAPI} RemoteCon::={TR-SAPI, chld} where CI is the connection identifier, TR-SAPI identifies the CNUs on the slave side and chld identifies a channel in the switch route (note that things become more complicated if the slave connects more than one core route). The ASP for disconnecting connections on the slave side is simple: cnuDiscOrder(Cl) 2. Another group of operations are those that are used for recording congestion and resource fault situations in the network. According to our design decision, the slave shall supervise the state of its switch, access routes and CNUs. The slave must also report changed conditions to the master. This can be done with the devStateRepCnf(Device, newState{busy, idle, blocked, deblocked}) Device::=CHOICE{switch, TR-SAPI} where TR-SAPI is a common identifier for both access routes and CNUs. Complementary ASPs, which may be used when blocking situations on the slave side are detected by other means, are the operations blockDevORD and deblockDevORD, used by the master. Based on the operations and the actual ORM model, the behaviour for each of the two distributed agents can now be described, using the principles for modelling object behaviour (see Sect. 6.2.6). This exercise is left to the reader. However, the reader will most likely end up in rather complex state diagrams, mostly because the two set of operations are time independent. The operations cnu- ConnREQ and cnuDiscORD are used 