the time being, we can use this assumption to specify layer interfaces in an abstract way. This means that we specify communication over layer interfaces in a simplified way, using abstract service primitives (ASP, a kind of "function call," or "operation call") as the interaction element between layers. For example, if a layer element requests a connection to another layer element (of its own layer) from a layer "below", we describe that event as something like connectRequest(otherLayerElementIdentity). 3 The requesting and performing layer elements may be implemented as two different processes in the same machine or in different machines. In any way they need to be connected to some kind of commu- nication mechanism for "intra- or inter-process communication." This is viewed as a problem for suppliers/implementors of the node to solve, however, and therefore disregarded when communication over a layer interface is specified. Through the use of ASPs, a layer-interface specification shows what the used layer can do for a using layer, normally expressed in terms of the used layer offer- ing some kind of service to using layers, the latter accessing the service through ASPs. Besides describing all ASPs and how to use them, layer-interface specifica- tions also describe service characteristics, such as transfer rate for connectivity services and diverse quality of service (QoS) properties. A layer interface is supposed to offer a single service. There is, however, no clear definition, neither in the OSI RM nor in existing standards, of a "single serv- ice" (other than as "a layer-interface specification describes a single service"). An analysis of existing layer-interface specifications, will show that many of them describe a clean cut connectivity service, e.g., the IP layer. Others define a single control service (such as the call handling layer in ISDN), or a single information service (such as DNS4 and some of the "application service elements" that OSI RM places in the lower part of its application layer). Ther