OSI over UDP: OSI connectionless transport services on top of UDP: Version 1
Running the OSI connectionless transport service on top of UDP, so OSI applications can use the Internet.
Shue, C., Haggerty, W., and K. Dobbins, "OSI connectionless transport services on top of UDP: Version 1", RFC 1240, DOI 10.17487/RFC1240, June 1991, <https://www.rfc-editor.org/info/rfc1240>.
@misc{rfc1240,
series = {Request for Comments},
number = 1240,
howpublished = {RFC 1240},
publisher = {RFC Editor},
doi = {10.17487/RFC1240},
url = {https://www.rfc-editor.org/info/rfc1240},
author = {C. Shue and W. Haggerty and K. Dobbins},
title = {{OSI connectionless transport services on top of UDP: Version 1}},
pagetotal = 8,
year = 1991,
month = jun,
} RFC text
Contents
Network Working Group C. Shue
Request for Comments: 1240 Open Software Foundation
W. Haggerty
Wang Laboratories, Inc.
K. Dobbins
Cabletron Systems, Inc.
June 1991
OSI Connectionless Transport Services on top of UDP
Version: 1
Status of this Memo
This document describes a protocol for running OSI Connectionless
service on UDP. This RFC specifies an IAB standards track protocol
for the Internet community, and requests discussion and suggestions
for improvements. Please refer to the current edition of the "IAB
Official Protocol Standards" for the standardization state and status
of this protocol. Distribution of this memo is unlimited.
1. Introduction and Philosophy
The Internet community has a well-developed, mature set of layered
transport and network protocols, which are quite successful in
offering both connection-oriented (TCP) and connectionless (UDP)
transport services over connectionless network services (IP) to end-
users. Many popular network applications have been built directly on
top of the TCP and UDP over the past decade. These have helped the
Internet services and protocols to become widely-spread de facto
standards. In the past few years, the ISO and CCITT have defined a
well-architected set of upper layer standards which include
connection-oriented and connectionless session, presentation, and
application layer services and protocols. These OSI upper layer
standards offer valuable services to application developers (e.g.,
dialogue control, transfer syntax, peer authentication, directory
services, etc.) which are not currently offered by the TCP/IP
standards.
As indicated in RFC 1006, it is desirable to offer the OSI upper
layer services directly in the Internet without disrupting existing
facilities. This permits a more graceful convergence and transition
strategy from IP-based networks to OSI-based networks in the future.
Using the approach of RFC 1006, this memo specifies how to offer OSI
connectionless transport service using the User Datagram Protocol
(UDP) [RFC768] of the TCP/IP suite.
We will define a Transport Service Access Point (TSAP) which appears
to be identical to the services and interfaces defined in ISO 8072
and its Addendum 1, but we will in fact implement the ISO T-UNIT-DATA
protocol on top of UDP. By this means, OSI TPDU's can be delivered
across the Internet network, and OSI connectionless upper layers can
operate fully without knowledge of the fact that they are running on
top of UDP/IP. In essence, the OSI T-UNIT-DATA service will use UDP
as its connectionless network service provider.
2. Motivation
The primary motivation for the standard described in this memo is to
facilitate the process of gaining experience with OSI connectionless
upper layers protocols, i.e., S-UNIT-DATA [ISO9548], P-UNIT-DATA
[ISO9576] and A-UNIT-DATA [ISO10035], and connectionless transport
protocol T-UNIT-DATA [ISO8602].
Though many OSI standard applications such as X.400 and FTAM are
connection-oriented, it is recognized in the OSI reference model
[ISO7498/AD1] as well as in practice that the connectionless-mode
operations are appropriate for certain distributed application
classes and environments. The following connectionless application
classes were identified by ISO SC21/WG6 [ISOSC21/WG6 N184]:
- Request-Response Applications
- Broadcast/Multicast
- Inward Data Collection
- Migratory/Unreliable Processes
Among them, the "request/response" client-server application class is
the most prominent one, which is gaining popularity and importance.
It is observed that the connection setup and tear-down protocol
exchanges and complex connection-oriented protocol machines become
unnecessary overheads for a simple request/response exchange between
a client application and a server application, especially in reliable
communications environments such as LAN and ISDN. The OSI
connectionless upper layers are thought to be highly effective and
efficient, both in time and space, for the distributed application
classes mentioned above.
The stability, maturity and wide availability of UDP/IP are ideal for
providing solid connectionless transport services independent of
actual implementations.
3. The Model
The [ISO 8072/AD1] standard describes the OSI connectionless
transport services definition. The [ISO 8602] standard describes the
OSI connectionless transport protocols. A defining characteristic of
transport connectionless-mode transmission is the independent nature
of each invocation of the connectionless transport service.
The OSI transport service definition describes the services offered
by the TS-provider and the interfaces used to access those services.
It also describes the services required. This memo focuses on how
UDP [RFC 768] can be used to offer the required services and provide
the interfaces.
The following is the model:
+-----------+ +-----------+
| TS-user | | TS-user |
+-----------+ +-----------+
| |
|CLTS interface |
|[ISO 8072/AD1] |
| |
_________________________________________________________________
| | | |
| | | |
| +-----------+ UD TPDU +-----------+ |
| | TS-peer | <-----------------------> | TS-peer | |
| +-----------+ +-----------+ |
| | | |
| | | |
| | | |
| |UDP interface [RFC 768] | |
| | | |
| +-----------+ UDP datagram +-----------+ |
| | UDP | <-----------------------> | UDP | |
| +-----------+ (UD TPDU encapsulated) +-----------+ |
| | | |
| | | |
| | | |
| | | |
| |
| |
| TS-provider |
|_________________________________________________________________|
The following abbreviations are used:
CLTS Connectionless Transport
TS Transport Services (implies connectionless transport
service in this memo)
TSAP Transport Service Access Point
TS-peer a process which implements the mapping of CLTS
protocols onto the UDP interface as described by
this memo
TS-user a process using the services of a TS-provider
TS-provider the abstraction of the totality of those entities
which provide the overall service between the two
TS-users
UD TPDU Unit Data TPDU (Transport Protocol Data Unit)
Each TS-user gains access to the TS-provider at a TSAP. The two TS-
users can communicate with each other using a connectionless
transport provided that there is pre-arranged knowledge about each
other (e.g., protocol version, formats, options, ... etc.), since
there is no negotiation before data transfer. In the above diagram
one TS-user passes a message to the TS-provider, and the peer TS-user
receives the message from the TS-provider. The interactions between
TS-user and TS-provider are described by connectionless TS
primitives.
All aspects of [ISO 8072/AD1] are supported in this memo with one
exception: QOS (Quality of Service) parameter, which is left for
future study.
The OSI standards do not specify the format of a TSAP selector.
Neither does this memo. However, implementors should consult the
GOSIP 1.0 specification [GOSIP88/FIPS146] for an interpretation of
this parameter, wherein the TSAP selector consists of two octets and
a value of (binary) 1 identifies the service interface between OSI
transport layer and session layer.
4. The Primitives
This RFC assumes that UDP [RFC768] offers the following service
primitives:
send datagram - datagram is sent to the IP address/destination
port
read datagram - datagram is read from UDP
Data can only be read from a receive port after the port has been
created. This is a local matter.
This memo reserves the use of UDP port 102 for the use of
applications which realize the CLTS over UDP. However as with RFC
1006, other port values may be used by prior agreement (e.g., through
use of the OSI Directory).
This RFC describes how to use these services to emulate the following
connectionless-mode network service primitives, which are required by
[ISO8602]:
N-UNIT-DATA.REQUEST - A NS-user requests unit data to be sent
N-UNIT-DATA.INDICATION - A NS-user is notified that unit data
can be read from the NSAP
The mapping between the UDP service primitives and the service
primitives expected by the connectionless transport peer entity are
quite straightforward:
connectionless network service UDP
------------------------------ ---
N-UNIT-DATA.REQUEST send datagram
N-UNIT-DATA.INDICATION read datagram
The parameter mapping is:
connectionless network service UDP
------------------------------ ---
Source address source IP address from
calling TS-address
Destination address destination IP address from
called TS-address
Quality of service (ignored)
NS-user data UD TPDU constructed from T-UNIT-DATA
When the T-UNIT-DATA.REQUEST primitive is issued, the TS-peer
constructs a UD TPDU and sends it as a single datagram to the desired
IP address using UDP.
When UDP indicates that a datagram has been received, a UD TPDU is
read from UDP, and a T-UNIT-DATA.INDICATION primitive is generated.
5. Packet Format
The following is the UD TPDU structure which is encapsulated in UDP
data field:
1 2 3 m m+1 n
+--------------------------------------------------+
| LI | UD | Variable Part | User Data |
| | 01000000 | | |
+--------------------------------------------------+
LI (octet 1) - the length of the header including parameters, but
excluding the LI and user data, with a maximum
value of 254
UD (octet 2) - the type of TPDU
Variable Part (octets 3 to m) - the source and destination TSAP id's
Parameter code: source TSAP 11000001
destination TSAP 11000010
Parameter length: the length of the parameter, not including
the parameter code or length fields, with a
maximum value of 254
Parameter value: source or destination T-selector
The optional checksum parameter is not required in the
variable part since the UDP checksum field in the UDP header
already performs the checking.
User Data (octets m+1 to n) - all the data of the TSDU.
The maximum NS-user data allowed in the OSI connectionless network
service is 64,512 octets. This limit is further constrained by the
lesser maximum datagram size supported by the two communicating UDP
peers, which should be known by a priori agreement.
6. Conclusion
There is a general trend towards support of the OSI protocol suite in
the Internet. This direction is being fostered by the Internet
Activities Board (IAB) and its Internet Engineering Task Force, and
by the Federal Networking Council. By offering an OSI connectionless
transport service on top of the Internet, this RFC will allow future
applications to use the OSI connectionless upper-layer services,
which are required to be conformant to the OSI upper layer
architecture. Currently, T-UNIT-DATA, S-UNIT-DATA, P-UNIT-DATA, and
A-UNIT-DATA have reached International Standard (IS). As
applications based on OSI connectionless services become widely
available and OSI lower-layer service is widely implemented in the
Internet, the underlying UDP/IP services can be simply replaced with
the OSI lower layers.
7. Acknowledgements
Marshall T. Rose of PSI, Inc., provided many valuable comments and
corrections.
8. References
[GOSIP88] U.S. Department of Commerce/National Bureau of Standards,
[FIPS146] "Government Open Systems Interconnection Profile (GOSIP)",
August 1988.
[ISO7498/AD1] ISO, "International Standard 7498 - Information
Processing Systems - OSI: Basic Reference Model
Addendum 1: Connectionless-mode Transmission",
May 1986.
[ISO8072] ISO, "International Standard 8072 - Information Processing
Systems - OSI: Transport Service Definition", June 1984.
[ISO8072/AD1] ISO, "International Standard 8072 - Information
Processing Systems - OSI: Transport Service Definition
Addendum 1: Connectionless-mode Transmission",
December 1986.
[ISO8602] ISO, "International Standard 8602 - Information Processing
Systems - OSI: Connectionless Transport Protocol
Specification", December 1986.
[ISO9548] ISO, "International Standard 9548 - Information Processing
Systems - OSI: Connectionless Session Protocol
Specification", April 1989.
[ISO9576] ISO, "Draft International Standard 9576 - Information
Processing Systems - OSI: Connectionless Presentation
Protocol Specification", April 1989.
[ISO10035] ISO, "Draft International Standard 10035 - Information
Processing Systems - OSI: Connectionless ACSE Protocol
Specification", April 1989.
[ISOSC21/WG6 N184] ISO SC21 WG6, "Justification for Connectionless
Services in the Upper Layers", June 1986.
[RFC768] Postel, J., "User Datagram Protocol", RFC 768,
USC/Information Sciences Institute, September 1981.
[RFC791] Postel, J., "Internet Protocol", RFC 791,
USC/Information Sciences Institute, September 1981.
[RFC1006] Rose, M., and D. Cass, "ISO Transport Service on top of
the TCP - Version 3", RFC 1006, Northrop Research and
Technology Center, May 1987.
Security Considerations
Security issues are not discussed in this memo.
Authors' Addresses
Chikong Shue
Open Software Foundation, Inc.
11 Cambridge Center
Cambridge, MA 02142
Phone: (617) 621-8972
EMail: chi@osf.org
William Haggerty
Wang Laboratories, Inc.
1 Industrial Ave
Lowell, MA 01851
Phone: (508) 967-3403
EMail: bill@comm.wang.com
Kurt Dobbins
Cabletron, Inc.
35 Industrial Way
Rochester, NH 03867
Phone: (603) 332-9400
ISO Plain Language
On this page
§1Why the OSI Upper Layers over UDP
The Internet had a mature, well-developed set of layered transport and network protocols, offering both connection-oriented service through TCP and connectionless service through UDP over the connectionless network service of IP. Many popular applications had been built directly on top of them over the past decade, and they had helped the Internet protocols and services become widely spread de facto standards.
In the years before, the ISO and CCITT had defined a well-architected set of upper layer standards covering connection-oriented and connectionless session, presentation and application services and protocols. These offer services to application developers that the TCP and IP standards do not provide, such as dialogue control, transfer syntax, peer authentication and directory services. As RFC 1006 had already indicated, it is desirable to offer the OSI upper layer services directly in the Internet without disrupting existing facilities, which permits a more graceful convergence and transition strategy from IP-based networks to OSI-based networks.
The primary motivation for this memo is to gain experience with the OSI connectionless upper layer protocols: the connectionless session protocol S-UNIT-DATA, the connectionless presentation protocol P-UNIT-DATA, the connectionless ACSE protocol A-UNIT-DATA and the connectionless transport protocol T-UNIT-DATA. Although many OSI standard applications such as X.400 and FTAM are connection-oriented, the connectionless mode is appropriate for certain application classes. ISO SC21/WG6 identified request-response applications, broadcast and multicast, inward data collection, and migratory or unreliable processes, and the request-response client-server class is the most prominent. The memo argues that connection setup and tear-down exchanges and the complex connection-oriented protocol machines become unnecessary overhead for a simple request-response exchange, especially in reliable environments such as a LAN or ISDN.
The memo's conclusion is that offering an OSI connectionless transport service on top of the Internet allows future applications to use the OSI connectionless upper layer services that are required to conform to the OSI upper layer architecture. At the time, T-UNIT-DATA, S-UNIT-DATA, P-UNIT-DATA and A-UNIT-DATA had reached International Standard, and as such applications become widely available and OSI lower layer service is widely implemented in the Internet, the underlying UDP and IP services can simply be replaced with the OSI lower layers.
The ISO and CCITT had written good standards for the upper layers of a network, including services that TCP and UDP do not offer, such as dialogue control and peer authentication. This RFC works out how to offer the connectionless version of those OSI services over the Internet, using UDP as the transport underneath, so that OSI applications can be tried out without replacing the existing network.
§3The Model: A Transport Service Provided by UDP
The ISO 8072 Addendum 1 standard describes the OSI connectionless transport services, and ISO 8602 describes the connectionless transport protocols. A defining characteristic of connectionless-mode transport transmission is the independent nature of each invocation of the service. The memo defines a Transport Service Access Point, or TSAP, that appears to be identical to the services and interfaces defined in ISO 8072 and its Addendum 1, but in fact implements the ISO T-UNIT-DATA protocol on top of UDP. In essence, the OSI T-UNIT-DATA service uses UDP as its connectionless network service provider.
The model places a TS-user on top of a TS-peer, with the TS-user reaching the service through the connectionless transport interface of ISO 8072/AD1 and the TS-peer reaching UDP through the UDP interface of RFC 768. The TS-peer is a process that implements the mapping of the connectionless transport protocols onto the UDP interface; the TS-user is a process that uses the services of the transport provider.
Each TS-user gains access to the provider at a TSAP, and the two TS-users can communicate with each other using the connectionless transport, provided there is pre-arranged knowledge about each other, such as protocol version, formats and options, because there is no negotiation before data transfer. All aspects of ISO 8072/AD1 are supported with one exception, the quality of service parameter, which is left for future study. The OSI standards do not specify the format of a TSAP selector, and neither does the memo, but implementors are pointed to the GOSIP 1.0 specification, where the TSAP selector consists of two octets and a value of one identifies the service interface between the OSI transport layer and session layer.
Each program that wants the OSI transport service reaches it at a TSAP, a named entry point. A separate piece of software, the TS-peer, sits between the two programs and turns each transport message into a datagram. The two programs must already agree on things like version and format, because nothing is negotiated before the first message is sent.
- OSI upper layersSession, presentation and application protocols
- OSI connectionless transportThe TS-peer, which builds UD TPDUs
- UDPCarries each TPDU in one datagram
- IPDelivers the datagram
§4Primitives and Parameter Mapping
The memo assumes that UDP offers two service primitives: send datagram, which sends a datagram to an IP address and destination port, and read datagram, which reads a datagram from UDP. Data can only be read from a receive port after the port has been created, which is a local matter. The memo reserves UDP port 102 for applications that implement the connectionless transport service over UDP, though as with RFC 1006 other port values may be used by prior agreement, for example through use of the OSI Directory.
The connectionless network service primitives required by ISO 8602 are emulated with those two UDP primitives. N-UNIT-DATA.REQUEST, in which a network service user asks for unit data to be sent, maps to send datagram. N-UNIT-DATA.INDICATION, in which a network service user is notified that unit data can be read, maps to read datagram.
The parameters map in the same straightforward way. The source address of the network service is the source IP address taken from the calling transport address, and the destination address is the destination IP address taken from the called transport address. Quality of service is ignored. The network service user data is a UD TPDU constructed from the T-UNIT-DATA primitive.
When the T-UNIT-DATA.REQUEST primitive is issued, the TS-peer constructs a UD TPDU and sends it as a single datagram to the desired IP address using UDP. When UDP indicates that a datagram has been received, a UD TPDU is read from UDP and a T-UNIT-DATA.INDICATION primitive is generated.
Two UDP operations do all the work: sending a datagram and reading one. Sending stands for the OSI request to transmit a message, and reading stands for the notification that a message has arrived. The addresses come from the transport addresses, and the quality of service setting is ignored.
§5The UD TPDU Packet Format
The UD TPDU is carried in the data field of the UDP datagram. It has four parts. Octet 1 holds LI, the length of the header including parameters but excluding LI and the user data, with a maximum value of 254. Octet 2 holds UD, the type of TPDU, which is 01000000. Octets 3 to m hold the variable part, which carries the source and destination TSAP identifiers as parameters. The parameter code for the source TSAP is 11000001 and for the destination TSAP is 11000010. The parameter length is the length of the parameter, not including the parameter code and length fields, with a maximum value of 254, and the parameter value is the source or destination T-selector. The optional checksum parameter is not required in the variable part, since the checksum field in the UDP header already performs the checking.
Octets m+1 to n hold the user data, which is all of the data of the transport service data unit. The maximum network service user data allowed in the OSI connectionless network service is 64,512 octets. This limit is further constrained by the lesser maximum datagram size supported by the two communicating UDP peers, which should be known by prior agreement.
Each datagram carries a short header before the message. The first byte gives the header length, the second says what kind of message it is, and the bytes after that give the source and destination TSAP identifiers. The message itself follows. The UDP checksum already checks the data, so no extra checksum is added.
1 2 3 m m+1 n
+--------------------------------------------------+
| LI | UD | Variable Part | User Data |
| | 01000000 | | |
+--------------------------------------------------+§6Security Considerations
The memo has a Security Considerations section, and its entire content is one sentence: security issues are not discussed in this memo.
Nothing else in the document addresses authentication, access control or confidentiality, so a reader should not take the silence as a statement that the mapping is free of security concerns. What the document does say about how the service is used is that the two TS-users need pre-arranged knowledge about each other, such as protocol version, formats and options, since there is no negotiation before data transfer, and that the port number to use may be agreed in advance, for example through the OSI Directory.
The memo does not discuss security at all. Its Security Considerations section says only that security issues are not discussed, so nothing here should be read as a claim that the mapping is safe.