OSF DCE SIG H. Lowe (OSF) Request For Comments: 43.0 J. Quigley (HP) July 1993 MAPPING DCE RPC TO MINIMAL OSI (mOSI) 1. INTRODUCTION This DCE RFC describes a mapping of the DCE RPC onto the OSI stack known as Minimal OSI (mOSI). The mapping uses X/Open's XTI for mOSI (XTI/mOSI) as the interface to the OSI "transport" provider. The intent of this RFC is to introduce the idea of, and solicit comments on, the desirability of mapping DCE RPC (or, for that matter, all of DCE) onto a minimal, standardized, conferment OSI stack thus providing DCE RPC functionality in the OSI environment. mOSI is an OSI ISP (Internationally Standardized Profile) [OIW1] for the upper three layers of OSI developed by OIW and EWOS (the OSE Implementors Workshop and the European Workshop for Open Systems). As the name implies, mOSI defines only the most basic communications facilities, i.e., those common to most connection oriented networks. When used in conjunction with an implementation of one of the OSI lower layer, ISP defined stacks, a mOSI implementation will offer a conferment seven layer OSI implementation. This combination of mOSI plus an OSI lower layer stack will interoperate with a full OSI seven layer OSI implementation. In addition to running over an OSI lower layer stack, mOSI can also be used over most other full duplex, connection oriented transport services, e.g., TCP/IP with RFC 1006. XTI/mOSI is the X/Open XTI interface [XOP3], for which mappings have been defined, such that it provides access to the OSI services made available by the mOSI upper layer stack. In addition to the normal XTI facilities, XTI/mOSI handles naming and addressing for a full seven layer stack and optional access to OSI's application and presentation context facilities [ISO1 and ISO2]. The combination of mOSI and XTI/mOSI is intended to support: (a) Non-OSI applications running over OSI networks, e.g., DCE RPC over OSI. (b) OSI applications requiring only minimal services running over non-OSI networks, e.g., Directory or Remote Database Access. In other words, the combination of mOSI and XTI/mOSI allow networked application (regardless of the type of network for which the applications were originally designed) to be run over almost any connection oriented network transport service. Lowe, Quigley Page 1 DCE-RFC 43.0 Mapping DCE RPC to mOSI July 1993 The goals of this RFC for mapping DCE RPC to mOSI are: (a) To allow DCE RPC to be used efficiently in an OSI environment (e.g., for GOSIP compliance). (b) To extend the domain of DCE RPC thus promoting the portability of DCE RPC based applications. 2. mOSI MODEL AND OPERATION For the purposes of this RFC, the mOSI model is as shown in Figure 1. A more complete model including alternative ways of using the mOSI stack is described in the current draft of the mOSI ISP, ISO/IEC 11188-3, available in the OIW Implementors Agreements. Application (e.g., RPC) +----------------------------+ | XTI/mOSI | +----------------------------+ ACSE \ -------------- | Presentation > mOSI -------------- | stack Session / +----------------------------+ | XTI to Transport (optional)| | or internal interface | +----------------------------+ Figure 1 -- mOSI Model Migrant network applications (i.e., applications not originally written for OSI), such as DCE RPC, access the mOSI services via the XTI/mOSI interface. Generically, the mOSI services are connect/disconnect and send/receive data, i.e., those services common to all client/server connection oriented networks (see 5.1 for a list of the specific services provided). These services are sufficient to support the majority of networked, connection oriented applications (including most "legacy" applications). The mOSI stack uses connection oriented transport services provided either by XTI [XOP2] or, alternatively, by an internal interface to these services. As XTI is supported by both OSI Transport (all classes) and TCP/IP, the mOSI stack will operate over networks based on either of these protocol suites; mOSI will also operate over proprietary networks which support XTI (or an internal equivalent). Lowe, Quigley Page 2 DCE-RFC 43.0 Mapping DCE RPC to mOSI July 1993 The value added by using mOSI rather than a direct mapping to OSI transport is: (a) Better portability -- with mOSI, a network application can operate over a wide range of networks whereas interfacing directly to OSI transport limits the range of networks over which the application can operate to just OSI transport based networks. (b) GOSIP compliance. (c) Ability to run OSI applications over TCP/IP networks. (d) The data tagging facilities offered by the optional use of OSI's Presentation [ISO2] context facility. (e) The ability to use optional application names which are distinct from addresses (so that an application is not tied to the hardware, i.e., the system can take advantage of X.500 or whatever similar directory infrastructure is available). Note that if the XTI interface is used between the mOSI stack and transport (see Figure 1), the application plus the mOSI stack becomes portable across the various transport services available through XTI, e.g., TCP, OSI transport, and NetBIOS. 3. CURRENT mOSI WORK The OIW Upper Layer SIG is responsible for defining mOSI. mOSI is a new part (Part 3) of the CULR (Common Upper Layer Requirements), ISO/IEC ISP 11188. In cooperation with the AOW and EWOS, it is intended that mOSI will be submitted to the ISO's SGFS (Special Group for Functional Standards) for balloting as a pDISP in early calendar 1994. The OIW's program of work for mOSI includes: (a) Defining the minimal set of facilities from the upper three layers of OSI. (b) Selecting API support for mOSI, XTI/mOSI (which is currently being progressed as appendix H to XTI in X/Open) to provide access to the mOSI services. (c) Following the completion of the connection oriented mOSI, the definition of a connectionless mOSI stack (the current X/Open work already includes connectionless). The OIW mOSI work is supported by EWOS which is cooperating with the OIW on progression of the current draft of mOSI. The AOW has been Lowe, Quigley Page 3 DCE-RFC 43.0 Mapping DCE RPC to mOSI July 1993 informed of this project and sent drafts of the document for review. As mentioned above, XTI/mOSI is currently being progressed in X/Open as appendix H to XTI and is a preliminary X/Open specification. There is complimentary work in the IETF on a project called the ThinOSI upper-layers cookbook [IETF]. This project describes how to implement what is a light weight, efficient mOSI stack. The cookbook will be posted as an Internet Draft in July 1993. NOTE: Many of the ideas for mOSI came from techniques used in the mapping of the X-windows protocol onto OSI defined in EWOS Technical Guide 13 [EWOS] (ETG 013, also called Xosi). The emphasis in Xosi was efficiency and small size. Xosi has been implemented and has performance comparable to running X-windows over TCP/IP (see Annex A for a brief description of Xosi). 4. DCE RPC REQUIREMENTS DCE RPC operates over either a connection oriented transport service (COTS) or a datagram, connectionless transport service (CLTS). mOSI and the XTI/mOSI API together with an appropriate OSI lower layer COTS stack meets the COTS requirements of DCE RPC as specified in the RPC AES (section 9.3.5) [OSF]: "The DCE RPC CO protocol requires a connection-oriented transport service that guarantees reliable, sequential delivery of data. This means the transport guarantees that when it delivers data to a transport user, all data previously sent by the remote transport user on that transport connection has been delivered exactly once, unmodified, and in the order it was presented to transport by the remote sender. "The COTS must provide for concurrent transport connections between each Client and Server pair, connection establishment and release, full duplex data transfer, message framing, segmentation and reassembly, flow control, and liveness indication." While there are connectionless services defined for all seven layers of OSI and the definition of a transport independent connectionless mOSI profile is on the OIW/EWOS program of work, it is not yet clear whether an OSI seven layer connectionless mapping for RPC should be pursued. ISSUE: Should a connectionless mapping for RPC be done? Lowe, Quigley Page 4 DCE-RFC 43.0 Mapping DCE RPC to mOSI July 1993 5. mOSI STACK SERVICES, XTI/mOSI, SYNTAX AND REGISTRATION 5.1. Services The connection oriented OSI services provided by mOSI are: (a) A-ASSOCIATE (b) A-ABORT (c) A-P-ABORT (d) A-RELEASE (e) P-DATA The full definition of these services is found in [ISO1] and [ISO2]. Briefly, however, A-Associate provides the connect service, A- Release/A-Abort are disconnect and P-Data provides send data. The difference between the abort and release is that the latter is orderly release whereas the former is potentially disruptive. The specific parameters used with these services and the constraints on their values for use with mOSI are contained in ISO/IEC 11188-3. This set of services comprises less than 20% of the total number of ACSE, Presentation and Session services provided by a full OSI upper layer implementation. However, this subset is sufficient to support almost all connection oriented Internet applications, at least 90% of OSI applications, and the majority of connection oriented applications running on other networks . This minimal set of services is not sufficient, however, to support some of the more complex OSI applications, e.g., the X.400 P1 protocol and ISO TP (when using the commit functional unit). To work with mOSI, OSI applications which require OSI Synchronization and Re-synchronization services would have to be provided with additional library services. 5.2. XTI for mOSI The services of the mOSI stack are made available to the distributed application through the XTI/mOSI interface. This is the X/Open XTI, for which mappings have been defined to allow it to be used in layer 7 of the OSI Reference Model (the original XTI is for the OSI Transport service at layer 4). A specific mapping has been defined to allow the XTI addressing structure to accommodate the full seven layer OSI naming and addressing. Options have also been defined, according to the XTI option management scheme, to handle both application and presentation context. With the exception of these options, XTI/mOSI is essentially unchanged from the original XTI which means XTI based applications can easily migrate to XTI/mOSI. Lowe, Quigley Page 5 DCE-RFC 43.0 Mapping DCE RPC to mOSI July 1993 To aid migration, mOSI provides defaults for both application and presentation context such that byte stream oriented applications don't need to be concerned with contexts. 5.3. Syntax and Registration One of the marked differences between OSI and other network Protocol suites is the fact that OSI distinguishes between what is called the abstract syntax of messages (i.e., the information content of the message) and the transfer syntax of the message (i.e., the representation of the contents -- the bits on the wire, so to speak). The OSI Presentation layer uses this distinction to allow the communicating systems to negotiate the presentation context(s) used by networked applications for the exchange of data and protocol. This OSI facility is often assumed to imply that OSI requires the use of ASN.1 encoding for all data and protocol. This could be a significant issue when considering how to use OSI with networked applications which do not define their protocol and data using ASN.1. This is particularly true for "legacy" applications where an organization may not be able to justify the cost of converting the application to ASN.1 encoding. P mOSI provides for distributed applications which do not use ASN.1 encoding in one of two ways: (a) It provides a default presentation context which will support byte stream protocols, e.g., the X-windows protocol. (b) It allows applications to register their existing syntax and use this with Presentation (the ability to use syntaxes other than ASN.1 with OSI is a normal, though not well known, Presentation facility). It turns out that all OSI Presentation actually mandates is that the syntax(es) used to define the data and protocol for an application should be unambiguously identifiable, i.e., for use with OSI, there must be an unambiguous object identifier which denotes that syntax. Where such an object identifier does not already exist, this means registering the syntax with a registration authority to get an object identifier. This is a clerical task and is not difficult. The object identifiers received when a protocol is registered are used to identify the application's abstract and transfer syntaxes to the OSI Presentation service. Where an application does not distinguish between its abstract and transfer syntaxes (i.e., they are identical -- this is not unusual), the same object identifier can be used for both. There are several instances where this technique is already in use, e.g., the mapping of X-windows onto OSI [EWOS] and UDT [ISO4] (Unstructured Data Transfer which is used with ISO TP to support legacy transaction programs). Lowe, Quigley Page 6 DCE-RFC 43.0 Mapping DCE RPC to mOSI July 1993 6. DCE RPC MAPPING TO mOSI FOR CONNECTION ORIENTED OPERATION For the mapping of DCE RPC to mOSI, the XTI/mOSI interface is used.[1] This section defines this mapping. TEMPORARY NOTE: The current document presents this mapping in outline only, omitting many details which should be specified in a complete mapping. If it is agreed that having a standardized mapping of DCE RPC to mOSI is worthwhile, this mapping will be completed in detail. The rest of this section omits the values for parameters of XTI/mOSI functions where the value is unchanged from that specified in the earlier XTI for transport specification -- values are given only for those parameters which have been changed or added for XTI/mOSI. However, the omission of values for these parameters should not affect the readers understanding of what is being proposed (in fact, the lack of superfluous detail may make understanding the big picture that much easier). This mapping of DCE RPC onto the XTI interface is based on the description of XTI as contained in the X/Open publication CAE Specification: X/Open Transport Interface [XOP2] together with the new Appendix (H) [XOP3] for mOSI functionality which is under development in X/Open. There are two major subsections to the mapping, one for the RPC client and the other for the RPC server, as client and server don't use an identical set of functions. The mappings for both the client and server are divided into the following five functional areas: (a) XTI Initialization. (b) Association Establishment (for use with a series of RPC Calls). (c) RPC Call Invocation (data transfer). (d) Association Release. __________ 1. There are potentially two interfaces for mOSI: - A subset of the full X/Open XAP [XOP1] interface. - The XTI/mOSI interface. The XAP interface is intended for applications which were originally written for OSI. Lowe, Quigley Page 7 DCE-RFC 43.0 Mapping DCE RPC to mOSI July 1993 (e) XTI De-initialization. Details of the specific XTI functions used for each area are then treated in detail in the subsections which follow. 6.1. Client Mapping 6.1.1. XTI initialization Before an association can be established, an endpoint must be initialized. First, t_open() must be called with parameters as specified in appendix H of XTI. This creates an endpoint for the association (a data structure) and populates it with protocol specific information for that endpoint. It also returns a file descriptor which is the local identifier for the endpoint. Once an endpoint exists, t_bind() is called which associates a (local) presentation address with the endpoint for an association, thereby activating the endpoint. For this client mapping, the optional AP-Title and AE-Qualifier are not used. Both of these tasks, creating the endpoint and activating it, are carried out by the CO_CLIENT protocol machine. The t_open() and t_bind() are called by the CO_CLIENT protocol machine with the parameters specified for these functions in the XTI manual as modified by appendix H for mOSI -- in particular, the addr structure of t_bind() shall contain a local OSI presentation address. 6.1.2. Association establishment The client always establishes associations for RPC -- it does not accept them. To establish a new association, the XTI/mOSI option AP_CNTX_NAME must be set to the object identifier for DCE_RPC (note: this will have to be defined and registered) using the t_optmgmt() call. The default value is used for the other options listed in table 1 (APCO-level Options) of appendix H. To establish the new association, the CO_CLIENT protocol machine first calls t_optmgmt() to set the value for the DCE RPC object identifier and then calls t_connect() to synchronously establish the association. The result (success or failure) is returned when the t_connect() returns. 6.1.3. Invoking and receiving RPC calls Following association establishment, the CO_CLIENT protocol machine then sends and receives the RPC protocol defined in the AES [OSF] using the t_snd() and t_rcv() calls. Lowe, Quigley Page 8 DCE-RFC 43.0 Mapping DCE RPC to mOSI July 1993 6.1.4. Release of an association When all RPC exchanges have been completed and the association between the client and server is no longer required, the association is released by the client calling t_snddis(). This is an abortive release (not orderly) and the peer is notified of the event by an unsuccessful return from a t_snd() or t_rcv(). The reason for the release can be had be calling by t_rcvdis(). 6.1.5. XTI de-initialization When the endpoint is no longer needed for communication via the current presentation address, it is deactivated by calling t_unbind(). A t_close() call can then be issued to free all resources used by the endpoint. 6.2. Server Mapping DCE models a DCE RPC server as being instantiated when a request for association establishment is received. Thus, this mapping of DCE RPC to mOSI using XTI models association establishment as being handled by a local listener which accepts the association and then instantiates a DCE RPC server as necessary passing the endpoint and association to the newly created server instance. With this model, initialization and association establishment are handled as described in 6.2.1 and 6.2.2. NOTE: A DCE RPC implementation may choose not to follow this model and, alternatively, instantiate RPC servers before association establishment. Where this is the case, an existent server handles acceptance of new associations from clients instead of a local listener. 6.2.1. XTI initialization Before an association can be established, an endpoint must be initialized. First, t_open() must be called with parameters as specified in appendix H of XTI. This creates an endpoint and protocol specific information for that endpoint. It also returns a file descriptor which is the local identifier for the endpoint. Once an endpoint exists, t_bind() is called which associates a (local) presentation address with the endpoint for an association thereby activating the endpoint. For this server mapping, the optional AP-Title and AE- Qualifier are not used. ISSUE: Should the AP-Title and AE-Qualifier be included so the server is not tied to a particular node? Under the model described in 6.2, both of these tasks, i.e., creating the endpoint and activating it, are carried out by a local listener. Lowe, Quigley Page 9 DCE-RFC 43.0 Mapping DCE RPC to mOSI July 1993 The t_open() and t_bind() are called with the parameters specified for these functions in the XTI manual as specified in appendix H for mOSI -- in particular, the addr structure of t_bind() shall contain a local presentation address designated for RPC. NOTE: If an implementation instantiates RPC servers before association establishment, endpoint initialization would be handled by the CO_SERVER protocol machine. 6.2.2. Association establishment An incoming RPC association request will be accepted by the local listener calling t_accept(). The listener then instantiates a RPC server and passes it the endpoint together with the new association. NOTES: - If an implementation instantiates RPC servers before association establishment, the CO_SERVER protocol machine will handle accepting the association. - An RPC server accepts associations, but does not establish them. 6.2.3. Invoking and receiving RPC calls Following association establishment, the CO_SERVER protocol machine receives and replies to RPC requests as defined in the AES using the t_rcv() and t_snd() calls. 6.2.4. Release of an association Under normal circumstances, the server does not release an association. However, if an abnormal condition occurs requiring the association be aborted, this is done by calling t_snddis(). This is an abortive release (not orderly) and the peer is notified of the event by an unsuccessful return from a t_snd() or t_rcv(). The reason for the release can be had be calling by t_rcvdis(). 6.2.5. Release of an association When the endpoint is no longer needed for communication through the current presentation address, it is deactivated by calling t_unbind(). A t_close() call can then be issued to free all resources used by the endpoint. 7. DCE RPC MAPPING TO mOSI FOR CONNECTIONLESS OPERATION [Reserved for the connectionless mapping when connectionless mOSI is started.] Lowe, Quigley Page 10 DCE-RFC 43.0 Mapping DCE RPC to mOSI July 1993 8. CONCLUSION A mapping of DCE RPC to mOSI can be used to allow DCE RPC to be used in the OSI environment. With this mapping, DCE RPC becomes an OSI application running over a conferment seven layer OSI stack. This stack can interoperate with a full OSI seven layer stack with all the bells and whistles. However, due to the absence of most of the OSI optional functionality, this stack is potentially much more efficient than a full seven layer OSI stack with all the bells and whistles (the quality of the implementation will determine efficiency). In addition, mOSI can also be run over other lower layer transports, e.g., TCP/IP and NetBIOS. Thus, enhanced portability for DCE RPC is another attribute of DCE RPC over mOSI. NOTE (for information only): While the mOSI ISP will not mandate how it should be implemented, for efficiency, as was done in Xosi [EWOS], an annex of the ISP encourages lumping the upper 3 layers of OSI together into one module and using predefined PCI (protocol control information) wherever possible, particularly for the protocol used for exchanging application data. See Annex F of ISO ISP 11188-3 (mOSI) [OIW1] for further information. APPENDIX A. X OVER OSI PROTOTYPE The X Window System (X) with its applications (Xclients and Xservers) is an example of a Basic Communications application. X is being formally standardized as ANSI Standard X3.196. Part 4 of X3.196 specifies the mapping of X over OSI. ANSI standard X3.196 is scheduled to be fast-tracked as an ISO International Standardized Profile (ISP). In the USA, IGOSS specifies the operation of X over OSI. The University of London Computer Center and Peter Furniss (ULCC/Furniss) have developed a prototype OSI upper layer stack that only includes the required functionality for X (Xosi -- a "skinny" stack for X over OSI based on TP4) [FURN]. The ULCC/Furniss Xosi protocol engine consists of approximately 1600 lines of C code. The implementation supports both the UNIX and DEC VMS platforms. Xosi code was made available to the public in July 1992 on an anonymous FTP at ULCC. An Xosi Project report is also available from ULCC/Furniss. Numerous performance runs were made of the ULCC/Furniss Xosi prototype both supporting X and a simple "ship" program. The "ship" was used to time bulk octet transfer of Xosi. For X, comparisons were made between running over Xosi/TP4/CLNP and running over TCP/IP. For the "ship" program, comparisons were made between Xosi/TP4/CLNP Lowe, Quigley Page 11 DCE-RFC 43.0 Mapping DCE RPC to mOSI July 1993 and TP4/CLNP. Using HP 9000/710 workstations on a dedicated LAN, the operation and performance of the demonstrated Xclients over Xosi/TP4/CLNS were comparable to TCP/IP. For the "ship" program, no noticeable performance difference was found between running with TP4/CLNP and running with Xosi/TP4/CLNP. Code for Xosi is available from the ULCC at an anonymous server. A report is also available. For information contact: Peter Furniss Peter Furniss Consultants 58 Alexandra Crescent Bromley, Kent BR1 4EX, UK Email: p.furniss@ulcc.ac.uk Phone and fax: +44 81 313 1833 REFERENCES [EWOS] EWOS EGVT, "A Mapping of the X Window System Over an OSI Stack", EWOS Technical Guide 013 (ETG 013), May 1991. [FURN] P. Furniss, "The OSI skinny stack", ULCC, March 1992. [IETF] P. Furniss, "Octet sequences for upper-layer OSI to support basic communications applications (ThinOSI upper-layer cookbook)", Internet Engineering Task Force, Internet Draft posted July 1993. [ISO1] ISO/IEC and CCITT, "Service Definition for Application Control Service Element (ACSE)", ISO/IEC 8649 and CCITT Recommendation X.217, 1992. [ISO2] ISO/IEC, "Connection Oriented Presentation Service Definition", ISO/IEC 8822, 1988. [ISO3] ISO, "Basic Connection Oriented Session Service Definition", ISO 8326, 1987. [ISO4] ISO/IEC, "Distributed Transaction Processing -- Part 6: Unstructured Data Transfer (UDT)", ISO/IEC DIS 10026-6, June 1992. [OIW1] OIW, "CULR Part 3: Minimal OSI upper layer facilities (Draft for ISP 11188-3 ", OSE Implementors Workshop, March 1993. [OSF] OSF, "AES/Distributed Computing: Remote Procedure Call", Open Software Foundation, August 1992. Lowe, Quigley Page 12 DCE-RFC 43.0 Mapping DCE RPC to mOSI July 1993 [XOP1] X/OPEN, "ACSE, Presentation Services API", X/Open Company Ltd., May 1992. [XOP2] X/OPEN, "X/Open Transport Interface (XTI)", X/Open Company Ltd., January 1992. [XOP3] X/OPEN, "X/Open Transport Interface (XTI), Appendix for Minimum OSI Functionality (XTI/mOSI), Draft 0.3, ISBN 1872630979, X/Open document number C318", April 1993. AUTHORS' ADDRESSES Henry Lowe Internet email: lowe@osf.org Open Software Foundation Telephone: +1-617-621-8783 11 Cambridge Center Cambridge, MA 02142 USA Jim Quigley Internet email: jim_quigley@hp6600.desk.hp.com Hewlett Packard Telephone: +1-408-447-3505 19420 Homestead Rd. FAX: +1-408-447-3660 Cupertino, CA 95014 USA Lowe, Quigley Page 13