ions show which nodes and tables are affected. For example, if we would move the DNS server n36 from the IP node n16 to n19, we would move the hosts relation from n16 to n19. The model will then tell us that the T-RE tables of the DNS resolvers n37 and n38, hosted in n17 and n18, must be modified. hosts TCP,UDP/IP Fig. 4.5 The model of Fig. 4.3, modified by logical network definitions If we want to refine a layer interface, we must first have access to a specification of that interface. If a layer structure has been produced (assumable as a result of vertical partitioning), each layer interface type that is defined by that structure should also be associated to a layer interface specification (in ITU-T standards sometimes called "service definition"). However, since we cannot rely on that (as regards existing standards), we may have to update the layer structure with such specifications, before we can approach the refinement activity of that interface type. Figure 4.6 shows how the TCP and UDP layer interface can be specified. The AMLs formalism for defining ASPs has been used here (other formalism may do as well). The AMLs variant of finite state machine (FSM) is used to describe the behavior in the interfaces. 4.3 Horizontal Partitioning TCP ASPs: UDP ASPs: connectReq(destSocket) sendOrd(destSocket) connectRef(cause) receiveRep(sourceSocket) connectCnf(destSocket) closeOrd(destSocket) UDP behaviour (FSM): sendOrd(destSocket) receiveRep(sourceSocket) established TCP behaviour (FSM): connRef sendOrd closed connReq receiveRep connReq connCnf established sendOrd closeOrd receiveRep Fig. 4.6 Layer-interface specifications. Cnf=confirm; FSM=finite-state machine; Ord=order; Ref=refuse; Rep=report; Req=request Note that while UDP defines two operations only (send and receive), TCP defines another two (connect and close). The behavior description for datagram services (such as UDP) is also SO elementary that (normally) no behavior is explic- itly described for such interfaces. The difference in complexity lies otherwise