re them in a library as the application programming interface (API) for the layer inter- face. 2. It must be possible to run the layer elements in different derived nodes. At low network levels (i.e., within a local network), it is sometimes possible to use a network platform that supports distribution of software elements to different nodes. example is the CORBA 3 platform that also defines IDL as its inter- face language. 3. The two layer elements may not be realized as software, however. Even if they are, network platforms such as CORBA may not be suitable. The limited real- time properties they offer and the processing power they require may make them unsuited for the actual layer interface. In those cases we must transform the layer interface into a protocol that can carry the ASPs of the layer interface. It is important that the model can tell that such protocols are realizations of layer interfaces, which is why we call them inter- layer protocol (to distinguish them from the intralayer protocols that are a result of vertical partitioning). An interlayer protocol must also be supported by an addi- tional connectivity stratum that is defined internally in the node that defines the layer interface. The principle of this transformation is depicted in Fig. 4.7. Intralayer protocols Node-internal connectivity stratum Refine model ASPs are: sendReq(-uest) recRep(-ort) Interlayer protocol Fig. 4.7 The principle of realizing a layer interface in terms of an interlayer protocol. See CORBA/IIOP specification, Chap. 3, IDL Syntax and Semantics. www.omg.org/ 3 See CORBA/IIOP specification (www.omg.org/) or Orfali (1996). 4.3 Horizontal Partitioning In this model, A, B and C are layer elements that handle intralayer protocols and layer interfaces, A', B' and C' are layer elements that handle both intra- and inter- layer protocols, and E is a layer element that offers connectivity within nw1 for node n11. It is obvious that the decision that is made about how to realize layer interfaces affects the design of layer eleme