ITU/ISO collaborative standardization work on that subject, where a clear distinction has been introduced between the Remote Operation Service (ROS) model ...
REMOTE OPERATIONS: FROM A GENERIC MODEL TO THE OS1 AND ITU SS7 REALIZATIONS
Bruno Chatras France T e l e c o d C N E T Paris, France
Bijan Jabbari George Mason University Fairfax, VA,USA
Abstract This article gives an overview of the concept of Remote Operations and its use in OS1 and telecommunications signalling networks. It builds upon the latest results of the ITU/ISO collaborative standardization work on that subject, where a clear distinction has been introduced between the Remote Operation Service (ROS) model and its OS1 realization, known as the Remote Operation Service Element (ROSE). The article shows that the Transaction Capabilities of Signalling System Number 7 can be viewed as a specific realization of the ROS model.
in [4].Although they were both built upon the same concept, the initial versions of the ROSE and TC specifications look quite different, especially the association and information transfer services that they used [SI, [ 6 ] . Lately, there has been a growing interest in converging the two specifications. From one end, the new requirements of signalling applications have resulted in integration of some missing functionalities of TC from the OS1 (e.g. Application-Context negotiation). From the other end, the OS1 has taken into account the necessity of efficiency in protocol design as present in the TC. The convergence has been further accelerated as a result of work by some experts in both areas. During the years 1990-1993 the OS1 ROS specifications were rewritten 171 for the third time in such a way that a clear distinction is made between the Remote Operation model (Recom. X.880) and its OS1 realization, namely the Remote Operation Service Element (Recom. X.88 1-X.882).
1. Introduction During the last decade, the concept of Remote Operations has been thoroughly used for the specification of application layer protocols involving the exchange of requests and replies between computers or telecommunication equipment. Remote Operations is the OS1 view of the concept of remote procedure call [l] which is an extension of the concept of procedure used in programming languages with the difference that the caller and the called entities may reside in different physical locations. This concept was initially introduced as a means of specifying the Message Handling Systems (MHS) protocols P3 (submission and delivery of messages) in the CCITT Red Books [2].
In the next section we will give an overview of the operation paradigm using the model and concepts defined in Recom. ITU-T X.880. Subsequently, we will show how the model and the concepts apply to the OS1 and the Signalling world, highlighting the differences between the two approaches.
During the 1984-1988 study period of the CCITT (now ITU-T), the specification of Remote Operations were rewritten in order to make them independent of the MHS and clarify that they were intended to support a large variety of applications. This work resulted in the adoption of a joint ISO-CCITT standard [ 3 ] . In parallel, CCITT SG XI, started studying the introduction of the same concept for supporting advanced telecommunication signalling applications. This resulted in the definition of the Transaction Capabilities (TC) for Signalling System Number 7 (SS7), whose latest specifications are available
2. The Remote Operation Concept ITU Recom. X.880 defines Remote Operations as a client-server paradigm for interactive communication between objects (known as ROS-Objects). A Remote Operation is a task that one object (the invoker) can request another (the performer) to carry out. The operation is said to be "remote" in that the performer is remote to the invoker. Depending on certain properties of the operation, the performer may return a report of the
0-7803-1820-X/94 $4.00 0 1994 IEEE 634
operation outcome which indicates whether the completion of the associated task is successful (result) or not (error). The paradigm also includes the ability for the performer of an operation to request the invoker of this operation to carry out another task. This is achieved through the invocation of another operation which is said to be linked to the original operation. Hence, a distributed application built upon this paradigm is merely a collection of operations together with some logic for chaining the invocations.
interconnects the two objects and on some quality of service criteria.
X.880 models the medium as being composed of two stub objects (one for the invoker, one for the performer) and one information transfer object (see Figure 1). The role of each stub object is merely to transform invocations and replies into protocol data units (and vice-versa) they exchange using the information transfer object. 3. Remote Operations in OS1 In this section, we discuss the OS1 realization of the Remote Operations model, information transfer and the association realization.
The definition of an operatioin involves i) the specification of an identifier on which the invoker and the performer have an agreement, ii) the specification of the type of the parameters which accompany the request and the reply (if any), iii) the specification #of the errors which can be reported (if any), and iv) whether the performer should always report the outcome of the operation execution. Four generic ROS PDU definitions are provided to help the protocol designers to specify a ROS realization. These are: Invoke, Return result, Return error, and Reject.
3.1 The Remote Operation Service Element The Remote Operation Service Element (ROSE) is a particular OS1 Application Service Element (ASE) which serves as a basis for the realization of the ROS model. The Recom. X.881-X.882 define a number of OS1 realizations of ROS which differ by the way the information transfer object is realized. In all cases, the stub is realized by the ROSE and a collection of operation specific ASEs (0-ASEs) each of which embodies the knowledge of the set of operations contained in an operation-package. The application-context is the OS1 view of the operation contract.
Beside the notion of operation and error, ITU-T Recom. X.880 defines additional concepts for structuring the specification of a ROS-basled application. A particular ROS-based application is modeled as one or more association-contracts. The specification of an applicationcontract mainly involves: 1) a reference to a connectionpackage which specifies the role of each ROS-Object in the establishment and release of the association (if any) over which the Remote Operations are invoked and two specific operations (bind and unbind) which may be used during the establishment and release of this association in order to transfer some application-specific information (e.g. authentication data); and 2) a reference to a list of operation-packages each of which corresponds to a group of (related) operations which can be used between the two ROS-Objects.
ROSE provides a set of unconfirmed services to its users to support the invocation of operations and the return of their replies. The APDUs associated with these services are the generic PDUs provided as part of the generic model. Beside these operation-oriented services ROSE provides two additional services for controlling the establishment and release of the association (if any) over which the ROSE protocol data unit is to be exchanged. These are RO-BIND and RO-UNBIND which are used respectively to invoke the Bind and Unbind specific operations defined as part of a connection-package.
3.2 Information Transfer and Association Realization
The realization of ROS involves the selection of a suitable medium to convey invocations and replies between a pair of ROS-Objects. The possible media can be classified in two broad categories: a) Those required when rile invoker and the performer are to be mq&"znted in a single physical equipment; b) Those required when the invoker and the performer are to be imp~ementeclin separated physical equipment. The first categcq can be further divided into message-passing and prxedure calling facilities. The medium in the second category depends on the type of network which
Two of the proposed realizations correspond to those described in the 1988 version of this specification. The others have been added in order to introduce more flexibility in the choice of the information transfer object, making the OS1 ROSE closer to the signalling realization (TC) than it was initially. For that purpose the information transfer object is modeled as being composed of three types of ASEs together with the presentation service provider:
635
obvious shortcomings were: i) The standard OS1 Presentation, Session and Transport layer introduced too much overhead and processing. ii) The procedure for establishing an association was not flexible enough (i.e. the establishment and release of an association using the ACSE procedure requires the exchange of 4 messages as a minimum, while TC can provide a similar functionality using 2,3 or 4 messages depending on the requirements of each application. iii) The inability to send a first invocation together with the association establishment request or termination request and the ability to concatenate several ROS APDUs in order to minimize the number of messages exchanged over the signalling networks.
i) An a-ASE providing dynamic association establishment and release capabilities ii) An optional z-ASE providing pure information transfer capabilities in addition to those provided by the presentation layer. iii) Supporting ASEs if required (i.e. supporting the aASE mdT-ASE) Three basic realizations are allowed: 1. The Association realization is based on the connectionoriented mode of ACSE while the transfer realization employs the P-DATA service (connection oriented presentation) and optionally the A-ASSOCIATE and ARELEASE services. The newest version of the specification of this realization allows the concatenation of ROSE APDUs in order to use the presentation layer in a more efficient way than transferring one ROSE APDU per P-DATA service primitive. In this realization the aASE is ACSE and there is no z-ASE nor supporting ASE. 2. The association realization and the transfer realization employ RTSE (which in turn require the use of ACSE). In this realization RTSE plays the role of the a-ASE and z-ASE while ACSE is a supporting ASE. 3. The association realization and the transfer realization solely employ the A-UNITDATA service of (connectionless) ACSE.
TC is best understood as a package which provides the S S 7 Remote Operation service and includes all the supporting and associated communication capabilities. In that sense, it can be compared to the collection formed by ROSE, ACSE and in some way the presentation layer. At present TC is modeled as being composed of two sublayers: a) The component sub-layer (CSL) which provides the remote operation service and allows the TCUser to control the association (if any) over which the requests and replies are exchanged. b) The Transaction sub-layer (TSL) which provides (if required) an end-toend connection service between two TC entities. Transaction Sub-Layer The Transaction sub-layer directly interfaces with the Signalling Connection Control Part [SI which provides the SS7 connectionless network service. In some way it replaces the missing transport layer functionality. Similar to the transport layer, the TSL can either be used in a connection-oriented mode which implies the establishment of a transaction or in a connectioless mode using the UNIDIRECTIONAL message.
When the ACSE services are not used for transfer realization, the first mode corresponds to the basic use of ROSE as defined in the 1988 standards. The second mode corresponds to the RTSE-based mode which is also described in these standards. The third mode corresponds to the unstructured mode of SS7 TC (unidirectional). 4. Remote Operations in Signalling Systems The concept of Remote Operations appeared in signalling systems during the 1984-1998 study period. Several variants have been introduced in parallel, the most complete being the one defined for SS7 known as TC [4].
Component Sub-Layer The component sub-layer is further divided into two functional blocks: a) The component handling (CHA) block which provides the remote operation service itself. b) The dialogue handling (DHA) block which provides a simple association control facility. The protocol data units which are generated or interpreted by the CHA block are called "components." They are identical to the generic ROS PDUs except that TC includes a PDU which can convey a segment of a successful result when the complete result can be transferred in a single network service data unit. The service interface above the CHA is very close to the ROSE service interface as far as
Transaction Capabilities
The initial version of the TC specifications was very different from the ROSE specification mainly because the latter did not pay enough attention to real-time performance and traffic load optimization. The main difficulties identified with the use of ROSE specifications for signalling protocols was related to the association and information transfer realizations, even though this terminology was not in use yet, The most
636
operation handling is concerned. In most cases there is a one-to-one correspondence between a ROSE primitive (e.g. RO-INVOKE) and a TC primitive (e.g. TCINVOKE).
which are not used in SS7 (e.g. AE-Qualifier). The ACSE RLRQ and RLRE APDUs are not used since they would not convey any useful information. The release of a TC dialogue cannot be refused and is implicit from the release of the underlying transaction. Both the service interface above and under the TC-DHA are drastically different from the one defined for ACSE (i.e. the ACSE service itself and the presentation service). Thus the DHA procedures are very different from the ACSE procedures.
The DHA services have two main purposes: i) Control of the dialogue (association) and transfer of user information. In this sense, the DHA offers a service similar to the BIND and UNBIND services. This is illustrated in Table 1. ii) Control of the concatenation of the PDUs which convey the requests and replies. This is a major difference with the OS1 realization, since it means that the TRANSFER pseudo primitive is explicitly controlled by the ROS-user and may contain more than one ROS PDU.
4.2 Information Transfer and Association Realization The stub objects are realized by the CSL together with the operation-specific ASEs defined for a particular TCUser. The information transfer object is realized by the TSL. The DHA Block of the CSL includes the role of the a ASE, since it is where the ACSE PDUs are built and interpreted (see Figure 2).
The dialogue control facilities allow the user to establish a dialogue (structured mode) or not (unstructured mode) for sending operation-related protocol data units. The structured mode corresponds to a connection-oriented mode of the application layer (i.e. this is equivalent to an OS1 association) while the unstructured mode corresponds to a connectionless mode of the application layer (i.e. the TC-DHA service (TC-UNI) used in this case is similar to the A-UNITDATA service defined for connectionless ACSE). The dialogue handling services exposed to the TC-user are a mirror of the Transaction services. For each TR service: primitive (e.g. TR-BEGINreq), there is a corresponding TC primitive (e.g. TCBEGIN-req.).
5. Conclusion The Remote Operations model jointly defined by IS0 and ITU provides a simple but powerful tool for the design of distributed applications. The clear distinction introduced between the ROS model and the realizations arrives just at the right moment, where more and more attention is paid to OS1 efficiency and where the boundary between signaling and data communication networks becomes fuzzy. It will probably permit to exter 3 the areas where the concept of Remote Operations can be used, since this takes away the problem of deciding whether the support of the ROSE and ACSE procedures and PDUs will have a negative impact on the performance of an application or on the load of a transport network. This article has been an opportunity to show that apparently diverging specifications could be viewed as different realizations of this generic model. A complete rewriting of all the existing ROS realizations along these principles would certainly avoid unnecessary differences both from an implementation point of view and from a ROS-user specification point of view.
It is worth noting at this stage that the dialogue structured mode which assumes the establishment of a transaction by the TSL is a genuine connection oriented mode, although it is based on unconfirmed services. Thus "Connection-Oriented TC" or "Connectionless TC" are inappropriate and misleading since depending on the dialogue mode (structured/unstructured), TC operates in a connection-oriented or connectionless mode while it always relies on a connectio~ilessnetwork service. In the first version of the TC specifications (1988), the DHA does not generate any protocol data units. Its behavior is entirely driven by the primitive it receives from the user and from the TSL.
6. References [ 11 A.D. Birrell, B.J. Nelson, "Implementing Remote Procedure Calls," XEROX CSL-83-7, Oct. 1983. [2] GCITT Recom. X.410, Message Handling Systems: Remote Operations and Reliable Transfer Service, 1984.
The abstract syntax for the dialogue portion is a strict subset of the abstract syntax for ACSE. Only three PDUs have been retained: Dialogue Request (AARQ), Dialogue Result (AARE) and Dialogue Abort (ABRT). In each of these PDUs a number of optional parameters have been removed, mainly because they were related to concepts
[3] Recom. CCITT X.219/X.229, Remote Operations (also published as IS0 9072-1 /9072-2), 1988.
637
-
[4] Recom. CCITT Q.771-Q.775:SS7- Transaction Capabilities, 1988.
-
APPLICATION PROCESS
APPLICATION PROCESS
[5] B. Jabbari, R. Piplani, F. Yegenoglu, A. Merchant, “Comparison of TSS application layer protocols: TCAP and ROSE,” Proc.of the IEEE Globecom 93, Houston, Texas, Dec. 1993. [6] N. Mitra, S.D. Usikin “Relationship of SS7 protocol architecture to the OS1 Reference Model,” ZEEE Network Magazine Jan. 1991.
TRANSACTION SUB LAYER
Information transfer
[7] Recom. ITU-T X.880/88 1/882,Remote Operations (Also published as DIS 9072-1 /9072-2/9072-3), 1993.
Figure 2. Information realization in TC
[8] Recom. CCITT 4.711-4.714:SS7- Signalling Connection Control Part, 1988.
Figure 1. ROS realization model [7]
ROSE
I
TC
BIND req./Ind.
TC-BEGIN-req./Ind.
BIND rsp./cnf.
TC-CONTINUE req./ind (first one)
UNBIND req./ind
TC-END req./ind
UNBIND r s p k n f
not applicable
Table 1. Comparison of TC Dialogue services with ROSE BINDAJNBIND services
638
Transfer
and
Association
