State Tables for Service Instances

4.5State Tables for Service Instances

4.5.1Introduction

1. 
   SLE Service Provider
   

1. 
   Common state table (see 4.5.3.2);
   
2. 
   Return link SLE services state table (see 4.5.3.3);
   
3. 
   Forward link SLE services state table (see 4.5.3.4).
   

2. 
   SLE Service User
   

1. 
   Common state table (see 4.5.4.2);
   
2. 
   Return link SLE services state table (see 4.5.4.3);
   
3. 
   Forward link SLE services state table (see 4.5.4.4).
   

The common state tables are applicable to all service types; the return link tables and the forward link tables are applicable for all return link services and all forward link services respectively. Because some service types only use a subset of the SLE operations defined, not all events defined in the tables can occur for those services, unless there are serious errors in the application or in the API Proxy. If such events are encountered, the service instance is expected to reject them with an appropriate error code. These actions are not specifically shown in the state table.

For some of the actions defined in the state tables processing is service-type specific, but the fact that the action must be performed is independent of the service type. Obviously, actions related to events that are not supported by a given service type, are not applicable for that service type.

4.5.2Processing Context

4.5.2.1Overview

The Proxy Interface comprises the interfaces ISLE_SrvProxyInitiate, exported by the proxy for an association and the interface ISLE_SrvProxyInform, exported by the service element. The Application Interface includes the interface ISLE_ServiceInform, exported by the application, and ISLE_ServiceInitiate, exported by the service element.

In addition, the service instance shall receive updates for service parameters from the application via the service-type specific interface I_SIUpdate, which is referred to as Management Interface (MIF) in the figure. These parameters are needed to respond to a GET PARAMETER request and to generate status reports.

Finally the locator interface (ISLE_Locator), by which the service element is informed of an incoming BIND invocation, needs to be considered. This interface is not shown in the figure.

Figure 4 1818: Processing Context for the Service Instance State Table

In order to simplify the state tables, processing steps that are common for all PDUs passed across an interface and are independent of the state of the service instance have been excluded from the state tables. These are allocated to ‘pre-processing’ and ‘post-processing’ functions.

As shown in figure 4 -18, it is assumed that pre-processing is performed on an event before it is passed to the state machine. If pre-processing fails, the associated action shall be performed as part of the pre-processing function, and the event shall not be forwarded to the state machine. Post-processing of an event shall be performed after the event has been processed or generated by the state machine. If a pre-processing function or a post-processing function encounters a situation in which the association must be aborted, it shall generate an internal event (INT: Peer Abort(reason)), which shall then be processed by the state machine.

Furthermore, the state tables do not include processing performed by call to the locator interface. This processing is described to more detail in 4.5.2.6.

It is stressed that the specification of pre- and post-processing functions as well as the details related to calls on the locator interface have only the purpose of simplifying the presentation of the state tables. They do not prescribe any specific implementation. The only requirement on implementations is that the behavior defined by the combination of the state tables and the auxiliary functions shall actually be provided by service instance objects.

4.5.2.2Pre-Processing of Events Received from the Proxy

Pre-processing of events received from the proxy includes the following tasks:

1. 
   Verification that the PDU passed with the event is supported by the service type handled by the service instance. If that check fails, the event shall be rejected with the error ‘unknown PDU’.
   
2. 
   Verification that the PDU is compatible with the role of the service instance (SLE service user or SLE service provider). If the check fails, the association shall be aborted with the diagnostic ‘protocol error’.
   
3. 
   Checking that an operation object passing a return is actually on the list of pending remote returns. If that check fails, the request shall be rejected, because this problem should have been handled by the proxy. Otherwise the operation object shall be removed from the list of pending remote returns.
   
4. 
   Canceling of the return timer for a return PDU.
   
5. 
   Checking for duplicate invocation identifiers for confirmed invocations. If duplicate invocation identifiers are detected, the pre-processing function shall generate and send a return PDU with a negative result and the diagnostic ‘duplicate invocation id’.
   
6. 
   Checking of invocation and return arguments on completeness, consistency and range. If there is an error, the reaction depends on the type of the PDU. For a confirmed invocation, the pre-processing function shall generate and send a return PDU with a negative result and the appropriate diagnostic. In all other cases it shall abort the association with the appropriate diagnostic code.
   
7. 
   Checking of the consistency of the PDU and the parameters with the configuration of the service instance. If these checks fail, the function shall generate a return with a negative result and the appropriate diagnostic. These checks are service-type specific.
   

The checks and actions are partially service-type specific.

4.5.2.3Post-Processing of Events Received from the Proxy

Post-processing of events received from the proxy includes the following tasks:

1. 
   adding the operation object to the list of pending local returns for confirmed invocations;
   
2. 
   passing of the PDU to the application.
   

These actions are independent of the service type.

4.5.2.4Pre-Processing of Events Received from the Application

Pre-processing of events received from the application includes:

1. 
   Checking that the PDU is valid for the service type handled by the service instance.
   
2. 
   Verification that the PDU is compatible with the role of the service instance (SLE service user or SLE service provider).
   
3. 
   Verification that an operation object used to forward a return PDU is on the list of pending local returns.
   
4. 
   Checking of invocation and return arguments on completeness, consistency and range.
   
5. 
   Checking of the consistency of the PDU and the parameters with the configuration of the service instance.
   

If there is any error, the pre-processing function shall reject the request with the appropriate return code. These tasks are partially service-type specific.

4.5.2.5Post-Processing of Events Generated or Received from the Application

Post-processing of events received from the application includes:

1. 
   Generation of a unique invocation identifier and inserting the id into the operation object, if the PDU transmitted is a confirmed invocation.
   
2. 
   Addition of the operation object to the list of pending remote returns and starting of the return timer for confirmed invocations.
   
3. 
   Forwarding the operation to the proxy for transmission. If the transfer request is rejected by the proxy, e.g., because the send queue is full, the association shall be aborted.
   
4. 
   Because of the flow control mechanisms built into the API, queue overflow cannot be caused by transfer of space link data-units.
   

These tasks are not service-type specific.

4.5.2.6Processing of Calls to the Locator Interface

Processing of calls to the locator interface includes the following steps:

1. 
   Location of the service instance requested by the BIND invocation. If the service instance cannot be found, the function shall return with an error ‘no such service instance’.
   
2. 
   Verification that the initiator identifier matches the one defined for the service instance. If that is not the case, the function shall return with an error ‘service instance not accessible to this initiator’.
   
3. 
   Verification that the service instance is not already bound. If the service instance is bound, the function shall return with an error ‘already bound’.
   
4. 
   Verification that the scheduled provision period of the service instance has started and has not yet ended. If the check fails, the function shall return with the error ‘invalid time’.
   

When receiving an error response from the locator, the proxy shall generate a BIND return with a negative result and the diagnostic related to the error code returned. If the locator returns a code indicating success and a pointer to the interface ISLE_SrvProxyInform, the proxy shall pass the BIND invocation to that interface. Except for location of the service instance, an implementation may choose to perform these checks by the service instance, when the BIND invocation has been passed to the interface ISLE_SrvProxyInform. If that is done, the service instance must generate the BIND return PDU.

Directory: sec -> docs -> 201510 Documents for SC13 Submission
sec -> Security Education Narrative Database Patterns of Professional Education
sec -> Guidelines for implementation of Prime Minister’s New 15 Point Programme for the Welfare of Minorities
sec -> Morphodynamics of a Constructed Marsh: Project Greenshores, Pensacola, Florida
sec -> Registration 6: 00pm – 6: 10pm Welcome/Opening Remarks
sec -> ¡bienvenidos! Welcome to Puerto Rico! 2 Things to know immediately upon arrival 2
sec -> Cadillac Racing cts-v coupe Media Kit
sec -> Sure Bet Narrative Nonfiction Suggestions
sec -> Executive Board of the United Nations Development Programme, the United Nations Population Fund and the United Nations Office for Project Services
201510 Documents for SC13 Submission -> Recommendation for Space Data System Practices

Download 2.26 Mb.

Share with your friends: