In this section, we introduce the common structure of the following sections. Each section comprises the same sequence of sub-sections. Following the approach we adopted in Chap-ter 4, we present the protocols in two steps: First, a version for static groups, and subse-quently, the extensions required to support dynamic groups will be presented. Hence, there will be two sections for most of the protocols. Protocols that are only used in dynamic groups ― that is to say, the dynamic network scheduling and the membership protocol ― will be presented in a single section.
As explained above, there are two kinds of stations: the AP and the clients. The AP and the clients exhibit asymmetric behaviors during the execution of the protocol. Accordingly,
each protocol has two roles; that is, each layer consists of two kinds of layer entities, each with its own behavioral specification. Therefore, we specify an AP and a client role for each protocol.
All specifications belonging to the same layer are combined in an SDL package. Such a package contains:
1. The specifications of the signals that are the service primitives of that layer. This includes also those data types that are used to declare the parameters of the signals;
2. The specification of the PDUs;
3. The specification of the AP role;
4. The specification of the Client role.
Correspondingly, each of the following sections has four sub-sections, named “Services and Interfaces”, “PDUs”, Specification of the AP Role”, and “Specification of the Client Role”. Some of the sub-sections may be omitted in sections presenting the dynamic group extensions of some protocol if there are no extensions to be presented in that sub-section.
For example, if no new PDUs need to be introduced to support dynamic groups, sub-section “PDUs” will be omitted.
In the “Services and Interfaces” sub-section, the signals exchanged between the user and the provider of the service are specified. The signal names observe the following naming convention: <service_name>_<kind_of_signal>. We distinguish five kinds of signals poll, rqu, ind, rsp, cnf. To request a service X the user sends a signal X_rqu to the service pro-vider. There are services, called polled services, where the user is not free to send the X_rqu at any time but only after receiving a polling signal X_poll from the service pro-vider. For example, the AP_DATA service of the polling protocol is a polled service, where the AP role sends an AP_DATA_poll signal to its user to solicit an AP_DATA_rqu. The provider of a service X sends the signal X_ind to its user to indicate that a relevant event w.r.t to that service has occured; for example, the client role of the polling protocol sends an AP_DATA_ind to its user when it receives a data frame from the AP. We call a service a responded service if the provider expects a signal X_rsp in response to the indication. Con-sider as an example the service FAIL of the polling protocol: After indicating that a client became invalid, the AP role waits until it receives a FAIL_rsp signal from the user in order to give the user the chance to change the polling list in reaction to the indication. Finally, a service is called a confirmed service if the provider sends a signal X_cnf to indicate whether or not the requested services has been executed successfully. For example, a user that initiates the JOIN service at the client role of the polling protocol gets a JOIN_cnf sig-nal from the client role, when the client has been added to the polling list at the AP.
In the architecture, there is the concept of service “forwarding” or “inheriting” between successive layers. A layer inherits a service from the lower layer if it uses that service and also provides it to the following layer. This allows using a service initially realized on a low layer of the architecture on all the following layers. Consider, for example, the EXT_POLL service of the polling protocol. Not only the layer above the polling layer may be interested in piggybacking data on the polling frames but also the layers above. This kind of “forwarding” or “inheriting” a service allows stacking layers above each other that
all depend on the same service. If a layer inherits a service from a lower layer, the corre-sponding signals need not be defined a second time in the specification of the higher layer.
Following the external, service-oriented view, the following sub-sections turn to the inter-nals of the layer. Sub-section “PDUs” presents the definition of PDUs the protocol entities exchange. There are typically several types of PDUs each with its own internal structure.
Each PDU type is defined as a SDL data type. For example, in the polling protocol the peers exchange poll, data, and null PDUs.
The next two sub-sections present the specifications of the protocol roles. Each protocol role is modeled as a SDL block type. The block type definitions of the protocol roles typi-cally have a structure as depicted in Figure A-1.
Figure A-1. Example of the block type definition of a protocol role
The block type definition diagram reveals the internal structure of the protocol role. It de-picts the SDL processes running in each instance of the protocol role (the single-lined six-cornered box in Figure A-1), the signal flows between these processes, and the signal flows between the processes and the environment of the protocol role. Most of the protocol roles encompass a single process, like in the example above, but there are also roles that comprise two processes ― like, for example, the reliable multicast protocol. For sake of brevity, we omit block type diagrams that include only a single process and exhibit the same structure as the example in Figure A-1.
Each process in a protocol role is the instance of a process type. For example, in Figure A-1, the process p is an instance of the process type Polling_AP; the douple-lined six-cornered box in the diagram represents a reference to the definition of the process type.
The specification of the behavior of a process is provided in the definition of its process types. For each process type used in a protocol role its definition will be presented in the SDL Textual Phrase Representation (SDL/PR). The definitions of the process types there-fore represent the definition of the protocol’s behavior. The SDL/PR representation style is somewhat more space efficient than the graphical representation, and since the single proc-ess type definitions are not too complex, it should be similarly comprehendible as the graphical representation. Each process type definition describes an extended finite state machine (EFSM). An EFSM has a finite number of explicit, discrete states. Additionally, EFSMs are allowed to contain variables as well, so that the values of these variables are part of the state of the machine too. EFSMs communicate via signals. When an EFSM re-ceives a signal it performs a state transition. During a transition, the EFSM can output sig-nals or change the values of its variables.
The points where the instances of a process type connect with their environment are called gates. For example, process p in Figure A-1 has three gates: SAP, BotPort, and MIB. If a protocol role contains a single process, the gates of that process are connected to the corre-sponding gates of the block type representing the protocol role (In Figure A-1, the arrows outside of the box denote the gates of the block type). Thus, each instance of the protocol role has the same three connection points SAP, BotPort, and MIB. The gate SAP represents the service access point (SAP) of the protocol where it exchanges signals with its user. At the gate BotPort, the protocol role accesses the services of the lower layer. Thus, in a stack, the BotPort of a layer n entity is connected to SAP of the layer n-1 entity. Addition-ally, a protocol role may have a MIB gate where it accesses the services of the Manage-ment Information Base (MIB), which is a common information repository for the stack. For each process type it is specified what signals it sends or receives across the gates.
In the presentation of the dynamic group extensions of a protocol, the first two sub-sections introduce new services and signals and new PDU types respectively, which have been added to support dynamic groups. To add dynamic group support in the specifications of the protocol roles, we use inheritance. To extend a protocol role, we define a sub-type of the block type representing that role. The new block type may add new structural elements such as processes and gates to its super-type or redefine the properties of existing ele-ments. The most important kind of specialization usually performed is to redefine the process types within the protocol roles. Consider, for example, the polling protocol. In the extended version of the AP role, the process type Polling_AP, which describes the behav-ior of the AP role, is redefined to change the behavbehav-ior of the role. The redefined process type inherits the specification of the process type it refines. When redefining a process type, one can add new states, new variables, and new transitions, or change transitions of the refined type. Using the inheritance/redefinition facility of the SDL, we are able focus on those aspects that need to be added to or changed in the protocol to support dynamic groups.