RFC 1240

OSI connectionless transport services on top of UDP: Version 1

๐Ÿ“… published June 1991, from ietf

RFC 1240: OSI Connectionless Transport Services on top of UDP ๐ŸŽ€

okay bestie, this one is Version 1 of a spec for running OSI connectionless transport services on top of UDP โœจ it's from June 1991 and it sits in the Network Working Group. three people wrote it: C. Shue from Open Software Foundation, W. Haggerty from Wang Laboratories, Inc., and K. Dobbins from Cabletron Systems, Inc. ๐Ÿ’– its category is an IAB standards track protocol, and the title block doesn't say it obsoletes or updates anything. the whole vibe is "let's run the OSI goodies on the Internet's existing plumbing" ๐Ÿฆ‹

part 1 of 2, more is coming bestie ๐ŸŽ€

Status of this Memo โœจ

so this doc describes a protocol for running OSI Connectionless service on UDP ๐ŸŒธ it's an IAB standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements ๐Ÿซถ for the actual standardization state and status, check the current edition of the "IAB Official Protocol Standards". and distribution of this memo is unlimited ๐Ÿ’…


1. Introduction and Philosophy ๐Ÿ’…

the Internet community has a super established, mature stack of layered transport and network protocols ๐Ÿ‘‘ they're doing great at giving end-users both connection-oriented (TCP) and connectionless (UDP) transport services over connectionless network services (IP). tons of popular network apps were built right on TCP and UDP over the past decade, and that's how Internet services and protocols became widely-spread de facto standards ๐ŸŒˆ

meanwhile, in the last few years, ISO and CCITT defined a really well-architected set of upper layer standards. those include connection-oriented and connectionless session, presentation, and application layer services and protocols. the OSI upper layers offer app developers valuable stuff (dialogue control, transfer syntax, peer authentication, directory services, etc.) that the TCP/IP standards don't currently offer ๐Ÿงš

as RFC 1006 points out, it's desirable to offer OSI upper layer services directly on the Internet without disrupting existing facilities ๐Ÿฆ‹ that makes for a more graceful convergence and transition from IP-based networks to OSI-based networks down the road. using the RFC 1006 approach, this memo specifies how to offer OSI connectionless transport service using the User Datagram Protocol (UDP) [RFC768] of the TCP/IP suite ๐Ÿ’œ

here's the big move: we define a Transport Service Access Point (TSAP) that looks identical to the services and interfaces in ISO 8072 and its Addendum 1. under the hood, though, we actually implement the ISO T-UNIT-DATA protocol on top of UDP ๐Ÿ“ so OSI TPDU's can be delivered across the Internet, and OSI connectionless upper layers can run totally without knowing they're on UDP/IP. basically, the OSI T-UNIT-DATA service uses UDP as its connectionless network service provider โœจ


2. Motivation ๐ŸŒธ

the main reason for this standard is to help people get experience with OSI connectionless upper layer protocols ๐Ÿ”ฅ that means S-UNIT-DATA [ISO9548], P-UNIT-DATA [ISO9576] and A-UNIT-DATA [ISO10035], plus the connectionless transport protocol T-UNIT-DATA [ISO8602].

a lot of OSI standard apps like X.400 and FTAM are connection-oriented ๐Ÿ™ˆ but it's recognized in the OSI reference model [ISO7498/AD1], and in practice too, that 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

the "request/response" client-server class is the most prominent one, and it's getting more popular and more important by the day ๐Ÿ‘‘ it's observed that connection setup and tear-down exchanges, plus complex connection-oriented protocol machines, become unnecessary overheads for a simple request/response exchange between a client app and a server app ๐Ÿ’€ especially in reliable environments like LAN and ISDN. the OSI connectionless upper layers are thought to be highly effective and efficient, in both time and space, for the distributed application classes listed above ๐Ÿซถ

and the stability, maturity and wide availability of UDP/IP make it ideal for providing solid connectionless transport services, independent of actual implementations ๐ŸŒˆ


3. The Model ๐Ÿฆ‹

[ISO 8072/AD1] describes the OSI connectionless transport services definition, and [ISO 8602] describes the OSI connectionless transport protocols ๐Ÿ’… a defining characteristic of connectionless-mode transmission is that each invocation of the connectionless transport service is independent of the others.

the OSI transport service definition covers the services the TS-provider offers, the interfaces used to access them, and the services required. this memo focuses on how UDP [RFC 768] can be used to offer the required services and provide the interfaces โœจ

here's 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 abbreviations, all in one spot ๐Ÿ“

    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 gets access to the TS-provider at a TSAP ๐ŸŽ€ two TS-users can communicate over connectionless transport as long as they've got pre-arranged knowledge about each other (e.g., protocol version, formats, options, ... etc.), since there's no negotiation before data transfer ๐Ÿ™ˆ in the diagram above, one TS-user passes a message to the TS-provider, and the peer TS-user receives that 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: the QOS (Quality of Service) parameter, which is left for future study ๐Ÿ”ฎ

the OSI standards don't specify the format of a TSAP selector, and neither does this memo ๐Ÿ’– but implementors should consult the GOSIP 1.0 specification [GOSIP88/FIPS146] for an interpretation of this parameter. there, the TSAP selector is 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 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. that's a local matter ๐ŸŒˆ

this memo reserves UDP port 102 for applications that realize CLTS over UDP ๐Ÿ”’ however, just like 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 the connectionless transport peer entity expects is pretty straightforward ๐Ÿ‘‘

    connectionless network service  UDP
    ------------------------------  ---

    N-UNIT-DATA.REQUEST             send datagram

    N-UNIT-DATA.INDICATION          read datagram

and the parameter mapping goes like this ๐Ÿฆ‹

    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 builds 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 ๐ŸŽ€

okay bestie, this is where it gets so pretty ๐Ÿ˜ญ this is the UD TPDU structure that gets tucked inside the 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: here are the two codes you need to know, periodt โœจ
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 ๐Ÿ’œ the source or destination T-selector

The optional checksum parameter is not required in the variable part, and that's the slay part ๐Ÿ™ˆ the UDP checksum field in the UDP header already does the checking, so nothing extra is needed here โœจ

  • 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 gets further constrained by the smaller maximum datagram size supported by the two communicating UDP peers, which should be known beforehand by a priori agreement ๐Ÿ’–


6. Conclusion ๐ŸŒˆ

okay so the big picture is that OSI is lowkey trending on the Internet ๐Ÿ“ˆ this is being fostered by the Internet Activities Board (IAB) and its Internet Engineering Task Force, and also by the Federal Networking Council ๐Ÿซถ by offering an OSI connectionless transport service on top of the Internet, this RFC will let future applications use the OSI connectionless upper-layer services, which are required to be conformant to the OSI upper layer architecture ๐Ÿฆ‹

Right now, T-UNIT-DATA, S-UNIT-DATA, P-UNIT-DATA, and A-UNIT-DATA have reached International Standard (IS) โœจ as applications built on OSI connectionless services become widely available, and OSI lower-layer service is widely implemented in the Internet, the underlying UDP/IP services can simply be replaced with the OSI lower layers ๐ŸŒธ it's giving full glow-up ๐Ÿ’…


7. Acknowledgements ๐Ÿ’–

Marshall T. Rose of PSI, Inc., provided many valuable comments and corrections ๐Ÿ™Œ iconic behaviour, thank you Marshall ๐Ÿซถ


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 ๐Ÿ’€ no security talk in here, bestie, so keep that in mind as you read ๐Ÿ™ˆ


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
๐Ÿ“ฆ where this page comes from