summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1240.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1240.txt')
-rw-r--r--doc/rfc/rfc1240.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc1240.txt b/doc/rfc/rfc1240.txt
new file mode 100644
index 0000000..2add55a
--- /dev/null
+++ b/doc/rfc/rfc1240.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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
+
+
+
+Shue, Haggerty & Dobbins [Page 1]
+
+RFC 1240 OSI on top of UDP June 1991
+
+
+ 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
+
+
+
+Shue, Haggerty & Dobbins [Page 2]
+
+RFC 1240 OSI on top of UDP June 1991
+
+
+ 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
+
+
+
+Shue, Haggerty & Dobbins [Page 3]
+
+RFC 1240 OSI on top of UDP June 1991
+
+
+ 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
+
+
+
+
+Shue, Haggerty & Dobbins [Page 4]
+
+RFC 1240 OSI on top of UDP June 1991
+
+
+ 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.
+
+
+
+
+Shue, Haggerty & Dobbins [Page 5]
+
+RFC 1240 OSI on top of UDP June 1991
+
+
+ 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
+
+
+
+Shue, Haggerty & Dobbins [Page 6]
+
+RFC 1240 OSI on top of UDP June 1991
+
+
+ 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
+
+
+
+Shue, Haggerty & Dobbins [Page 7]
+
+RFC 1240 OSI on top of UDP June 1991
+
+
+ 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
+
+
+
+
+
+
+
+
+Shue, Haggerty & Dobbins [Page 8]
+ \ No newline at end of file