Interoperability and Protocol Suites

Model

Communications models describe protocols. A protocol is an agreed convention for the exchange of information between communicating entities. A protocol describes the format of the exchanged information, including control information and content, the semantics of the control information, and constraints on communication, such as sequencing and state constraints.

In describing communications, it is necessary to identify:

• the layering of protocols

  In layering, protocols are classified according to communications functions. Basic communications are identified and more sophisticated communications functions are built upon the basic ones. Each set of communications functions has an associated protocol. A protocol is embedded in the information content of a protocol at the next lower layer.

• the association of APIs with the protocol stack.

In a describing protocol layering, it is necessary to:

• classify protocols by function

• describe the possible combinations that can exist among protocols when they are layered

• describe the constraints that apply as protocols are layered.

A protocol suite is a set of protocols, including descriptions of each protocol's function, layering relationships and constraints.

The basic communications model is defined by an adaptation of the OSI Reference Model, which classifies protocols by function and provides a basic framework for layering protocols. The OSI Reference Model defines seven layers of communications services. A given layer is defined to be a Service Provider for the next higher layer and a service user of the next lower layer.

There are two essential properties of layering. The first is that a service user is unaware of characteristics of layers below the corresponding Service Provider. The second is that the protocol is layered such that information is exchanged between peer entities at a given layer according to the protocol defined for that layer.

End systems are platforms that implement communications interfaces and support the functions of all seven layers of the OSI Reference Model.

As defined in Part 1, Overview and Core Specifications, protocols are grouped into Application Protocols and Transport and Lower Layer Protocols, designated by APPL and TLL respectively. APIs are associated with protocols only at Application and Transport Layers.¹

Having this basic grouping for reasons of simplification, it is necessary to describe the possible combinations that can exist among protocols.

Typically, the layering of protocols in a suite is shown graphically by a tile diagram, where each tile represents a protocol at a given layer. The possibility of layering one protocol on another is shown by the lower protocol's tile being positioned directly under the higher protocol's tile.

However, such diagrams are limited when the relationships among protocols become complex. Furthermore, tile diagrams only show protocol layering. They do not show other information such as APIs, constraints and conformance criteria, all of which are relevant for SPIRIT users.

Because of these limitations, protocol suites are defined using tables.

As shown in Modelling Conventions , a table can represent the same information shown graphically by a tile diagram. The tables also identify additional constraints, and any other relevant information such as associated APIs.

As can be seen in the example above, the two conventions are equivalent representations of layering. As is also shown, it is not necessary to have a one-to-one mapping between protocols and layers in the OSI Reference Model.

As shown in Modelling Conventions , some protocols span multiple OSI Layers. In this case, the protocol appears in the uppermost layer in the graphic convention. In the tabular convention, the upper and lower bounds are listed in the layer column.

Although not shown in the above example, it is also possible for multiple layered protocols to exist within a single OSI Layer.

The tables that represent protocol stacks shall contain the following columns:

Layer

Identifies the corresponding layer in the OSI Reference Model. Where a protocol supports the functions of multiple OSI Layers, the top-most layer is used.

Protocol

A brief description of the protocol. A mnemonic designator for the protocol is shown in bold letters.

Reference

This is the label of the normative reference as given in Part 1, Overview and Core Specifications. The designation of the corresponding standard (for example, IEEE 801.2, RFC 877) is also given.

API

Identifies the associated application programming interfaces, if any.

Over

Identifies the Lower Layer protocols on which the protocol can be layered. An "&" indicates a logical "and" of Lower Layer protocols; that is, layered multiple Lower Layer protocols in conjunction; an "|" indicates a logical "or" of Lower Layer protocols; that is, alternatives. The Lower Layer protocol is indicated in bold using the mnemonic identifier for the protocol that is used in the protocol column.

Constraint

Identifies any constraints on the layering or usage of the protocol. Often these are identified by standard protocol profiles. In such cases, it is noted using the label used in the SPIRIT normative references.

Conformance

Identifies the conformance test suite or testing organisation.

SPIRIT describes three protocol suites:

• OSI Transport and Lower Layer Protocols

• Internet Transport and Lower Layer Protocols

• Application Protocols.

There is one table for each of these suites. As a matter of convenience for presentation purposes, the table describing the Application Protocol Suite is segmented into 3 parts, one for OSI-based application protocols, one for Internet-based application protocols, and one for DCE (Distributed Computing Environment) application protocols.

OSI Transport and Lower Layer Protocol Suite

The OSI Transport and Lower Layer Protocol Suite is defined below.

Internet Transport and Lower Layer Protocol Suite

The Internet Transport and Lower Layer Protocol Suite is defined below. Protocols in this suite layer over various OSI protocols at the Lower Layers.

Application Protocol Suite

OSI-based Application Protocols

This part of the Application Protocol Suite shows application protocols either defined by OSI entirely or using OSI standard protocols. They run natively over OSI Transport but may also layer over IP via RFC 1006.

Internet-based Application Protocols

The Internet-based application protocols are those defined by RFCs. They run only over IP, and are defined below.

DCE-based Application Protocols

The DCE-based application protocols are defined as part of the X/Open Distributed Computing Environment. They are independent of transport and are listed below.

Footnotes

1.

Both DIOCES and TR-10000 also group protocols this way.

2.

ES-IS is out-of-band. TP4 does not strictly layer over it, but it does use it.

3.

This is an out-of-band protocol used for controlling the layer in question and is not part of normal data transmission.

4.

Although base standard allows for CONP over LLC, SPIRIT chooses not to exercise this option.

5.

This is an out-of-band protocol used for controlling the layer in question and is not part of normal data transmission.

6.

This is an out-of-band protocol used for controlling the layer in question and is not part of normal data transmission.

7.

CSMA/CD adaptors all support both IEEE 802.3 and DIX 2.0 (Digital, Intel, Xerox) protocols, commonly referred to as Ethernet. Ethernet and IEEE 802.3 differ in the use of a two-octet field in the header. Both protocols run over the same LANs.

8.

This is an out-of-band protocol used for controlling the layer in question and is not part of normal data transmission.

9.

This is a routing protocol.

10.

This is a routing protocol.

11.

This is a routing protocol.

12.

Note that this requires Ethernet (DIX) rather than IEEE 802.3. Both IEEE 802.3 and DIX Ethernet are supported by adaptors and both run over the same wire.

13.

STDL also provides a programming interface for TxRPC. See LANG/TXN-1 for detail mappings of STDL to TxRPC.

14.

Since TxRPC specifies the use of DCE RPC as an ASE of OSI-TP, TxRPC should be characterised more as "with OSI-TP" rather than "over OSI-TP".

15.

There is an X/Open specification, XAP-TP, for the low-level integration of OSI-TP protocols. It is anticipated that only some Service Providers will, on some occasions, need to integrate OSI TP at this low level. (Vendors may use the XAP-TP interface to provide integration of their Communications Resource Managers with OSI-TP, but such use is normally not expected to affect Service Providers.) Thus XAP-TP is not specified here.

16.

ACSE protocol skipped by the RTSE X.410 1984 mode.