 The DSS1 L3 example: The AMLn definition of association handling assumes it to be a procedure that is executed before any invokes can be generated, and after the last invoke is detected. This corresponds to how a common agent layer would deal with the prob- lem (e.g., TCAP and ACSE). The DSS1 L3 agent layer is, however, not a common agent layer. In such cases it is normal for the association identifier (ASi) to be established at the same time as the first invoke is generated by simply including an ASi value in the first message of a new dialogue. In the case of DSS1 L3 this mes- sage is the SETUP and the ASi is the parameter callRef in the SETUP. Logically we can view this as the originating actor generating two SAG primitives before the agent sends the SETUP: one assReq(As, callRef) and one r-invokeOrder(call- Ref, <the first LSM-event, carried by the SETUP>). The only questions are: is there any actor identifier parameter (As) in the DSS1 L3 protocol, and what parameters are used for identifying actors in the LE SAG? Every event generated by a DSS1 L3 actor in a TE is detected by the single LE actor. Thus, there is no need for a TE actor to identify any remote actor in com- munication with its DSS1 L3 agent. Consequently, no parameter is needed in DSS L3 messages for actor identification in this case In order to make the DSS1 L3 actor in an LE independent of how endsystems and terminals are connected to the operator network, and how ASi values are used over the DSS1 L3 layer, we do not want this actor to know anything about LAPD routes and callRefs to ESs. Therefore, when the LE actor wants to estab- lish a new association to a particular ES, it only refers an idle ASi and an ISDN/ PSTN network address, in communication with its DSS1 L3 agent. This agent has a table that associates such a number to a particular LAPD route (i.e., ES). Thus, no actor identification parameter in DSS1 L3 messages is needed in this case either. The DSS1 L3 agent in an LE translates the ASi value to an idle call- Ref of the actual E