ISO Transport Service on top of the TCP Version: 3
RFC 1006
Document | Type |
RFC - Internet Standard
(May 1987; No errata)
Updated by RFC 2126
Obsoletes RFC 983
Also known as STD 35
|
|
---|---|---|---|
Authors | |||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 1006 (Internet Standard) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
M. Rose & D. Cass [Page 1] Network Working Group Marshall T. Rose, Dwight E. Cass Request for Comments: RFC 1006 Northrop Research and Technology Center Obsoletes: RFC 983 May 1987 ISO Transport Service on top of the TCP Version: 3 Status of this Memo This memo specifies a standard for the Internet community. Hosts on the Internet that choose to implement ISO transport services on top of the TCP are expected to adopt and implement this standard. TCP port 102 is reserved for hosts which implement this standard. Distribution of this memo is unlimited. This memo specifies version 3 of the protocol and supersedes [RFC983]. Changes between the protocol as described in Request for Comments 983 and this memo are minor, but are unfortunately incompatible. M. Rose & D. Cass [Page 1] RFC 1006 May 1987 1. Introduction and Philosophy The Internet community has a well-developed, mature set of transport and internetwork protocols (TCP/IP), which are quite successful in offering network and transport services to end-users. The CCITT and the ISO have defined various session, presentation, and application recommendations which have been adopted by the international community and numerous vendors. To the largest extent possible, it is desirable to offer these higher level directly in the ARPA Internet, without disrupting existing facilities. This permits users to develop expertise with ISO and CCITT applications which previously were not available in the ARPA Internet. It also permits a more graceful convergence and transition strategy from TCP/IP-based networks to ISO-based networks in the medium-and long-term. There are two basic approaches which can be taken when "porting" an ISO or CCITT application to a TCP/IP environment. One approach is to port each individual application separately, developing local protocols on top of the TCP. Although this is useful in the short-term (since special-purpose interfaces to the TCP can be developed quickly), it lacks generality. A second approach is based on the observation that both the ARPA Internet protocol suite and the ISO protocol suite are both layered systems (though the former uses layering from a more pragmatic perspective). A key aspect of the layering principle is that of layer-independence. Although this section is redundant for most readers, a slight bit of background material is necessary to introduce this concept. Externally, a layer is defined by two definitions: a service-offered definition, which describes the services provided by the layer and the interfaces it provides to access those services; and, a service-required definitions, which describes the services used by the layer and the interfaces it uses to access those services. Collectively, all of the entities in the network which co-operate to provide the service are known as the service-provider. Individually, each of these entities is known as a service-peer. Internally, a layer is defined by one definition: a protocol definition, which describes the rules which each service-peer uses when communicating with other service-peers. M. Rose & D. Cass [Page 2] RFC 1006 May 1987 Putting all this together, the service-provider uses the protocol and services from the layer below to offer the its service to the layer above. Protocol verification, for instance, deals with proving that this in fact happens (and is also a fertile field for many Ph.D. dissertations in computer science). The concept of layer-independence quite simply is: IF one preserves the services offered by the service-provider THEN the service-user is completely naive with respect to the protocol which the service-peers use For the purposes of this memo, we will use the layer-independence to define a Transport Service Access Point (TSAP) which appears to be identical to the services and interfaces offered by the ISO/CCITT TSAP (as defined in [ISO8072]), but we will in fact implement the ISO TP0 protocol on top of TCP/IP (as defined in [RFC793,RFC791]), not on top of the the ISO/CCITT network protocol. Since the transport class 0 protocol is used over the TCP/IP connection, it achieves identical functionality asShow full document text