ket-switched services were introduce in stand- ards, it became obvious that the original definition of the OSI-SAP did not hold. At the very least, one had to distinguish between SAPs that offered CON and CNL services respectively, as shown in Fig. 3.9. OSI Service Provider CONNECT request with CNL-services User protocol CONNECT indication added: CONNECT response CONNECT confirm CON-SAP RESET request DATA request CON Service provider DATA indication User protocol DATA request(SAPI,...) CNL-SAP DATA indication(SAPI,...) CNL Service provider Fig. 3.9 Two types of SAPs to cover both connection-less and connection-oriented packet serv- When ISDN services and protocols (and the CCS standard) became standard- ized, ITU-T tried to use the OSI RM for describing the ISDN architecture. Now other problems arose: OSI RM defined only one type of network service interface. In ISDN, there is clear separation between the process control system and the resource system, in the sense that the interface for requesting a circuit-switched teleservice is associ- ated with the process control system, and the interface for using a circuit- switched connection belongs to the resource system, as seen in Figs. 3.5-3.6. The ISDN architects solved the problem by defining two parallel architectures (the user plane and the control plane). In SM&AML we use, instead, two dif- ferent interface concepts: we use SAPs to denote the user's interface to the resource system, and CSIs to denote the user's interface to the process control system. We also separate users into two units: the SAP-user (TEU, if teleserv- ice) and the CSI user (TEC, if teleservice). 3 Logical Network Modelling In ISDN there is one single CSI for requesting all types of teleservices, which means that the same address (SAPI) is used for all teleservice SAPs. In the OSI RM view of SAP, there is a unique address associated with each SAP (which is how packet data services are used). When the OSI RM user sends data over a SAP, he must identify his partner. In the CNL case, he uses th