ributed agent can be a master, a slave or a peer. A master is a distributed agent that handles the provider ports of the object in the centralized solution. A distributed agent that handles no provider port is a slave. Note, how- ever, that in many decentralized control solutions, all or several distributed agents handle provider ports. This would most certainly be the case for the substructure of TEPC, since this object handles many users (TECs), and is normally given a decen- tralized control solution. When two communicating distributed agents both handle provider ports, they are peers. According to these definitions, the parts of the CNPC in the solution in Fig. 6.29 are master and slave. How the centralized object resource model (ORM) becomes partitioned into a master-ORM and a slave-ORM represents a number of important design decisions: One decision was to distribute control of the two switches. This leads to that the SW and AR models, that belong respectively to switches, become distributed as Fig. 6.29 shows. To let the master object manage all core routes (the switch route and the internal route) is a natural design decision for this simple network. For a larger network with many core routes, it would not be SO. Another design decision that affects the partitioning of the centralized CNW model, is that the master will handle the complete set of properties for the cen- tralized CNW. This model will therefore be modified to one version for the mas- ter (the complete model according to Fig. 6.9, comprising all CNUs, and all CNU-properties), and a reduced version for the slave, comprising only the iden- tities (TR-SAPI) of the CNUs that are handled on the slave side. The slave- ORM records blocking conditions of its own CNUs and access routes, but it also reports that to the master, and the master records that in the master-CNW. A similar design decision, which also requires that the slave reports to the mas- ter, is to let the master record fault and congestion situations, such as blocking states in the mast