 SAP. For example, if the log- ical node in A-EVH in Fig. 4.22 wants the logical node in B-EVH to send a glo- bal SDU to a remote user, it will initiate a global ASP of type sendCnlOrder(globalSAPI, globalSDU), intended for the logical node in B- EVH. The only way that the ASP can be detected by the logical node in B-EVH is to hand it over to the A-MEH, which will pack it in a local PDU to the B-- MEH and send the corresponding local SDU over the node platform to the B-- MEH, using a suitable local send operation. The operations that are defined over the local SAP are assumed to be local send and receive operations, and may be some type of remote procedure call mechanism between internal nodes. Since the MEH is supposed to make message handling between the user and provider nodes transparent to the EVHs, we must define a symbolic interface between the EVH and the MEH, over which global ASP information can be trans- ported. How this interface is implemented is a local matter inside each of the two physical nodes. The EVH-MEH interface comprises two symbolic operations: generateEventOrder(<the information elements of a global ASP>) - detectedEventReportConfirm(<the information elements of a global ASP>) 4.5 Implementing Network Service Interfaces The short version of these ASPs are gevOrd(...) and devRepCnf(...). The param- eter field of gevOrd and devRepCnf of, e.g. the elements in a global ASP, which are: The operation name of the global operation (some type of global send and receive), The primitive type of the global operation (Request, Order, etc.), The parameters of the global operation (global SDU, global SAPI, etc.). The MEHs transport global-ASP information between the two physical nodes, using the local send and receive operations that are offered by the node platform. To describe how an MEH maps between global ASPs and local send and receive operations, we must define a generic set of such operations. We will therefore assume that the CSP supports three generic local communication operations: A local sen