meters. This makes it impossi- ble to confuse and mix LSM behavior with LPM behavior (as in conventional standards). In this case study we have (more or less) used the existing standard text frag- ments. In reality we would have produced a state diagram representation instead, possibly annotated with text fragments where needed since behavior descriptions on the LSM level are considerably simpler than when LSM and LPM behavior are mixed (in which case the state diagram often becomes too complex to be of any value). Within the context of a standard, resource control points (rCP) are normally not specified. 16 Implementors can, however, use this model as a basis for their implementations by adding rCP specifications and refine the behavior specifica- tion into complete ESM specifications, from which implementations of ESMs can be generated. You can read more about this in Muth (2001). Let's now turn to the LPM specification and its relation to the LSM. Assuming that the LSM abstract protocol is specified as described, the only thing the LPM has to do is to create messages for the ASPs defined by the abstract protocol, and to interface the connectivity service, which is the LAPD service. Since all ASPs are (presumably) built in the same way, a general format for messages that carry ASP information may look like Fig. 2.26. In general, an LPM may also perform other functions except mapping ASPs on messages, such as message error control, frag- mentation, and flow control (but not in DSS1 L3). There may therefore exist mes- sages as well that do not carry ASPs. The translation (or "mapping") between the ASPs of the LSM and the messages of the LPM is performed by the DSS1 L3 agents. It must therefore be described as part of the LPM specification. Compared to the existing standard, the LPM specifi- cation becomes rather simple because all ASP parameters are defined and typed in the LSM specification. The LPM specification need therefore only comprise the depicted formats, encoding algorithms and LPM-specific functions an