[Open Blueprint] [Cover] [Prev Topic] [Next Topic] ------------------------------------------------------------------------ 1.0 Common Transport Semantics (CTS) Common Transport Semantics (CTS) insulates the higher-level services of the Open Blueprint from the underlying transport network by providing a common view of transport protocols. This common view, coupled with a standard set of compensation mechanisms, enables all higher-level services to be transport-independent, so that different transport network drivers can be plugged in under a common implementation of those services. CTS enables a network to be based upon the one protocol (or few protocols) best suited to the enterprise network requirements. Then, by providing a common view of networking protocols, this structure makes application environments independent of the underlying network. For example, data needing conversational, remote procedure call, or messaging and queuing services may be carried over any network protocol. New applications can be added to any network without requiring installation and maintenance of additional networking protocols. One need not build parallel networks for different applications; all forms of management (problem determination, and configuration) are simplified and less costly since fewer transport types are used. Support for multiple protocols can be achieved in a number of ways; the Open Blueprint provides the context for discussing them. Figure 2 shows the relationship of the Open Blueprint CTS layer and the MPTN architecture. The CTS layer in the Open Blueprint provides support for multiple protocols at the Transport layer. CTS supports all of the basic transport functions of the underlying transport providers in the Open Blueprint. If needed functions are missing from any of the transport providers, CTS itself provides those functions. CTS function can be achieved in different ways depending upon the situation: 1.CTS encompasses the case where the installed application program is native to a specific transport protocol. In this case, CTS is a conceptual structure that adds no line flows or overhead. 2.CTS function can be achieved using industry-standard compensation methods for particular transport-user/transport-provider combinations, such as Request for Comment (RFC) 1006 for OSI over TCP/IP and RFCs 1001 and 1002 for NetBIOS over TCP/IP. 3.The Multiprotocol Transport Networking (MPTN) architecture formats and protocols deliver CTS function in a general manner in situations where the installed application programs are not native to the installed transport protocol, or where multiple transport protocols are installed. Compensation for missing functions is available in those situations. For example, the MPTN architecture defines how SNA can be the transport provider for sockets applications and how TCP/IP can be the transport provider for CPI-C applications. X/Open has published IBM's contribution of MPTN architecture as a preliminary specification for review prior to adoption as a public and industry standard for mixed-protocol internetworking.   Figure 2. Relationship of the Multiprotocol Transport Networking (MPTN) Architecture to the Open Blueprint Common Transport Semantics (CTS) Layer The MPTN architecture, as implemented by the IBM AnyNet family of products, provides a significant aspect of the common transport semantics (CTS) layer of the Open Blueprint. MPTN provides the functions to allow transport users to access non-native transport providers. Any component of a communication system that normally requests services from its native transport layer, requests those same services from the Transport Layer Protocol Boundary (TLPB). Such a component is called the transport user. For a transport API such as sockets or NetBIOS's API, the transport user is the API processing layer. For an API such as CPI-C, which exposes higher-level SNA functions, the transport user is the part of the SNA stack above the transport layer. The communication APIs above the transport users are shown in Figure 3. Once a transport user is changed to use the TLPB, applications written to use the communications API above the transport user do not need to change to gain access to other transport networks. Details of the MPTN functions are described in the next section. Figure 3 shows some examples of transport users. The rows of triangles at the top represent higher-level APIs, and the rows of arrows toward the bottom represent a semantic interface to MPTN functions. The different sizes of the boxes represent differences in the amount of function in the respective system libraries. Thus, there is more function in the system library to support an interface like CPI-C with upper-level services than there is to support a transport-level interface like sockets. The leftmost box, the Direct Transport User, represents new systems programs that choose to write directly to the TLPB and not use any existing higher-level functions.   Figure 3. Examples of MPTN Transport Users CTS is also used by upper layer applications and services to access the Signalling and Control Plane for the purpose of setting up connections across switched networks such as ATM or POTS (Plain Old Telephone Service), and for the purpose of controlling low level multiplexing, such as that employed in H.320 video conferencing. For example, the Telephony and Collaboration resource managers utilize the functions of the Signalling and Control Plane. The Telephony resource manager uses it to set up phone calls, and to manipulate calls which are in progress. The Collaboration resource manager uses the Signalling and Control Plane to set up switched connections among multiple participants in a collaborative session, and to control the low-level multiplexing of voice, video and data, as in the case of H.221 multiplexing (part of the H.320 video conferencing framework). Common Transport Semantics allows a mixing and matching of application requests to lower layer networking services by adding compensations where needed, for example, in order to run sockets applications on an SNA network. If the application request already matches the lower layer service, no compensation is needed and CTS is passive. Today, no mismatches have been identified between application requests and Signalling and Control Plane services, so CTS plays a passive role in all interactions with the Signalling and Control Plane. ------------------------------------------------------------------------ [Open Blueprint] [Cover] [Prev Topic] [Next Topic]     © Copyright IBM Corp. 1995