Internet Draft Yanick Pouffary & Alan Young November 03, 1995 ISO Transport Service on top of TCP (ITOT) Version: 3 Abstract draft-pouffary-itot.txt This document is a revision to RFC1006 written by Marshall T. Rose and Dwight E. Cass. Since the release of RFC1006 in May 1987, much experience has been gained in using ISO transport services on top of TCP. This document refines the protocol and supersedes RFC1006. This document describes the mechanism to allow ISO Transport Services to run over TCP over IPv4 or IPv6. It also defines a number of new features, which are not provided in RFC1006, such as independence of normal and expedited data channels and explicit transport Disconnection. The goal of this version is to minimise the number of changes to RFC1006 and ISO 8073 transport protocol definitions, while maximising performance, extending its applicability and protecting the installed base of RFC1006 users. Discussion list: tosi@lkg.dec.com To Subscribe send mail to tosi-request@lkg.dec.com Expires April 1996 [Page 1] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Expires April 1996 [Page 2] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 1. Introduction, Motivation There are two basic approaches which can be taken when "porting" ISO applications to TCP/IP ([RFC793],[RFC791]) and IPv6 [IPV6] environments. One approach is to port each individual application separately, developing local protocols on top of TCP. A second approach is based on the notion of layering the ISO Transport Service over TCP/IP. This approach solves the problem for all applications which use the ISO Transport Service. This document describes the second approach. The protocol described in this memo is based on the observation that both the Internet Protocol Suite and the ISO Protocol Suite are layered systems. A key aspect of the layering principle is that of layer-independence. The concept of layer-independence means that if one preserves the services offered by a particular layer (the Service-Provider) then the Service-User at that layer is completely unaffected by changes in the underlying layers or by the protocol used within the layer. This document defines a Transport Service which appears to be identical to the Services and Interfaces offered by the ISO Transport Service Definition [ISO8072], but which will in fact implement the ISO Transport Protocol [ISO8073] on top of TCP/IP (IPv4 or IPv6), rather than the ISO Network Service [ISO8348]. This document is largely based on RFC1006 written by Marshall T. Rose and Dwight E. Cass. It further refines the protocol and supersedes RFC1006. It also defines a number of new features, which are not provided in RFC1006, such as independence of Normal and Expedited Data channels and Explicit Transport Disconnection. This document specifies changes to the standards mentioned above and must be read in the context of the above mentioned standards. It will not be meaningful on its own. The 'well known' TCP port 102 is reserved for hosts which implement the Protocol described in this document. Note that the Protocol does not mandate the use of TCP port 102 for all connections. Expires April 1996 [Page 3] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 2. The Model This section describes the differences between the model used by the ISO Transport and that described in this document. 2.1 ISO Transport Model The ISO 8072 standard describes the ISO Transport Service Definition (TS). The ISO Transport Service Definition describes the services offered by the Transport Service Provider and the interfaces used to access these services. The ISO 8073 standard describes the ISO Transport Protocol Specification (TP). The ISO Transport Protocol specifies common encoding rules and a number of classes of transport protocol procedure which can be used with different network Quality of Service. The ISO 8348 standard describes the ISO Network Service Definition (NS). The ISO Network Service Definition describes the services offered by the network service Provider and the interfaces used to access these services. The ISO Network Service specifies two type of service: - Connection Oriented Network Service (CONS) - ConnectionLess Network Service (CLNS) The ISO Transport Protocol specifies five classes of procedures when operating over CONS and one class of procedure when operating over CLNS. The relationship of these ISO standards is illustrated below: Transport Service User | |-ISO Transport Service Definition [ISO8072] | +--------------------------------------------------+ | Transport Service Provider | | ISO Transport Protocol Specification [ISO8073] | +--------------------------------------------------+ | |-ISO Network Service Definition [ISO8348] | Expires April 1996 [Page 4] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 2.2 ISO Transport over TCP (ITOT) Model This document defines a model which provides ISO Transport Service, with minor extensions, running over TCP. The ISO 8072 Transport Service is supported with some modifications. The ISO 8073 Transport Protocol with some modifications is used to provide the modified Transport Service. The Transmission Control Protocol is used in place of the ISO 8348 to provide a CONS like service. This document specifies a simple encapsulation mechanism between the modified ISO 8073 Transport Protocol and the TCP. ISO 8073 Transport Protocol specifies five classes when operating over ISO 8348 CONS. This document specifies how to operate class 0 and 2 over TCP. This document does not prevent use of other classes from operating over TCP, but their specification is beyond the scope of this document. The relationship of these standards is illustrated below: Transport Service User | |-ISO Transport Service (modified) | +--------------------------------------------------+ | Transport Service Provider | | ISO Transport Protocol (modified) Specification | +--------------------------------------------------+ | |-TCP as a Connection Oriented Network Service | 2.3 Overview of Protocol and Service This document defines use of the ISO Transport Protocol (with some extensions) running over TCP. Two variants of the protocol are defined, "Class 0 over TCP" and "Class 2 over TCP", which are based closely on the ISO Transport Class 0 and 2 Protocol. Section 3 defines the Service offered to the Transport User by this protocol, and shows the differences from the ISO Transport Service. The mapping between the Service primitives in the ISO Network Service and TCP are defined. Section 4 defines the Transport Protocol. Expires April 1996 [Page 5] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 3 Service Definition This section describes the Transport Service offered to the Transport User. It also defines the mapping between the Network Service Definition and the TCP Service Definition. 3.1 Transport Service Definition The ISO 8072 Transport Service is supported with the following extensions: - Use of Quality of Service parameter is not defined - Access to Non-disruptive Transport Disconnection With respect to Transport Service Access Point specification, please refer to the 'Open issues' section 7.2. 3.1.1 Transport Service Definition Primitives Information is transferred to and from the TS-User in the Transport Service primitives listed below: Events T-CONNECT.INDICATION - a TS-User is notified that a transport connection establishment is in progress T-CONNECT.CONFIRMATION - a TS-User is notified that the transport connection has been established T-DISCONNECT.INDICATION - a TS-User is notified that the transport connection is closed T-DATA.INDICATION - a TS-User is notified that data can be read from the transport connection T-EXPEDITED_DATA.INDICATION - a TS-User is notified that expedited data can be read from the transport connection Expires April 1996 [Page 6] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 Actions T-CONNECT.REQUEST - a TS-User indicates that it wants to establish transport connection T-CONNECT.RESPONSE - a TS-User indicates that it will honour the request T-DISCONNECT.REQUEST - a TS-User indicates that the transport connection is to be closed T-DATA.REQUEST - a TS-User sends data T-EXPEDITED DATA.REQUEST - a TS-User sends "expedited" data 3.2 Network Service Definition This section describes how TCP is used to provide ISO 8348 CONS. 3.2.1 ISO 8348 CONS primitives Information is transferred to and from the NS-provider in the Network Service Primitives listed below: Events N-CONNECT.INDICATION - a NS-user is notified that a network connection establishment is in progress N-CONNECT.CONFIRMATION - a NS-user is notified that the network connection has been established N-DISCONNECT.INDICATION - a NS-user is notified that the network connection is closed N-DATA.INDICATION - a NS-user is notified that data can be read from the network connection Expires April 1996 [Page 7] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 N-EXPEDITED_DATA.INDICATION - a NS-user is notified that expedited data can be read from the connection Actions N-CONNECT.REQUEST - a NS-user indicates that it wants to establish a network connection N-CONNECT.RESPONSE - a NS-user indicates that it will honour the request N-DISCONNECT.REQUEST - a NS-user indicates that the network connection is to be closed N-DATA.REQUEST - a NS-user sends data N-EXPEDITED_DATA.REQUEST - a NS-user sends "expedited" data 3.2.2 TCP Service primitives The mapping between, ISO 8348 CONS primitives and TCP Service primitives, defined in this document assumes that the TCP offers the following service primitives: Events TCP-CONNECTED - open succeeded (either ACTIVE or PASSIVE) TCP-CONNECT_FAIL - ACTIVE open failed TCP-DATA_READY - Data can be read from the connection TCP-ERRORED - the connection has errored and is now closed TCP-CLOSED - an orderly disconnection has started Expires April 1996 [Page 8] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 Actions TCP-LISTEN_PORT - PASSIVE open on given port TCP-OPEN_PORT - ACTIVE open to the given port TCP-READ_DATA - data is read from the connection TCP-SEND_DATA - data is sent on the connection TCP-CLOSE - the connection is closed (pending data is sent) 3.2.3 Mapping TCP as a Network Service Provider 3.2.3.1 Network Connection Establishment In order to perform a N-CONNECT.REQUEST action, the TS-Provider performs a TCP-OPEN_PORT to the desired IPv4 or IPv6 address using the selected TCP port. When the TCP signals either success or failure, this results in an N-CONNECT.INDICATION action. In order to await a N-CONNECT.INDICATION event, a server performs a TCP-LISTEN_PORT to the selected TCP port. When a client successfully connects to this port, the TCP-CONNECTED event occurs and an implicit N-CONNECT.RESPONSE action is performed. Mapping parameters between the TCP service and the ISO 8348 CONS service is done as follow: Network Service TCP --------------- --- CONNECTION ESTABLISHMENT Called address server's IPv4 or IPv6 address and TCP port number. Calling address client's IPv4 or IPv6 address all others parameters ignored Expires April 1996 [Page 9] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 TCP port 102 is reserved for implementations conforming to this specification. Use of any TCP port is conformant to this specification. 3.2.3.2 Network Data Transfer In order perform a N-DATA.REQUEST action, the TS-provider constructs the desired transport protocol data unit (TPDU), encapsulates the TPDU in a discrete unit called TPKT and uses the TCP-SEND_DATA primitive. In order to trigger a N-DATA.INDICATION action, the TCP indicates that data is ready through TCP-DATA_READY event and a TPKT is read using the TCP-READ_DATA primitive. Mapping parameters between the TCP service and the ISO 8348 CONS service is done as follow: Network Service TCP --------------- --- DATA TRANSFER NS User Data (NSDU) DATA 3.2.3.3 Network Connection Release In order to perform an N-DISCONNECT.REQUEST action, the TS-provider simply closes the TCP connection through TCP-CLOSE primitive. In order to trigger a N-DISCONNECT.INDICATION, the TCP indicates that the connection has been closed through TCP-CLOSE event. If the TCP connection has failed the TCP indicates that the connection has been closed through TCP-ERRORED event, this trigger a N- DISCONNECT.INDICATION. Mapping parameters between the TCP service and the ISO 8348 CONS service is done as follow: Network Service TCP --------------- --- CONNECTION RELEASE all parameters ignored Expires April 1996 [Page 10] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 4. Transport Protocol Specification ISO 8073 Transport Protocol Classes 0 and 2 are supported with extensions. A Transport Protocol class is selected for a particular transport connection based on the requirements of the TS-User. ISO 8073 Transport Protocol exchanges information between peers in discrete units of information called transport protocol data units (TPDU). The protocol defined in this document encapsulates these TPDUs in discrete units termed Packets (TPKT). This documents mandates the implementation of ISO 8073 Transport Protocol options negotiation (which includes class negotiation). Please refer to 'Notes to Implementors' section 6.1 with respect to Class negotiation and to section 7.1 with respect to Interoperability with RFC1006. 4.1 Class 0 over TCP Class 0 provides the functions needed for connection establishment with negotiation, data transfer with segmentation, and protocol error reporting. It provides Transport Connection with flow control based on that of the NS-provider (TCP). It provides Transport Disconnection based on the NS-provider Disconnection. Class 0 is suitable for data transfer with no Explicit Transport Disconnection. 4.1.1 Connection Establishment The principles used in connection establishment are based upon those described in ISO 8073, with the following extensions: - Connect Data may be exchanged using the user data fields of Connect Request (CR) and Connect Confirm (CC) TPDUs - Use of Expedited Data may be negotiated using the negotiation mechanism specified in ISO 8073. The default is to not use Expedited Data. Expires April 1996 [Page 11] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 - Non-standard TPDU size may be negotiated using the negotiation mechanism specified in ISO 8073. The maximum TPDU size is 65531 octets. The Default maximum TPDU size is 65531 octets. Please refer to 'Notes to Implementors' section 6.2. 4.1.2 Data Transfer The elements of procedure used during transfer are based upon those presented in ISO 8073, with the following extension: - Expedited Data may be supported (if negotiated during connection establishment) by sending the defined Expedited Data (ED) TPDU. The ED TPDU is sent on the same TCP connection as all of the other TPDUs. To support Expedited Data a non-standard TPDU is defined. The format used for the ED TPDU is nearly identical to the format for the Normal Data (DT) TPDU. The only difference between ED TPDU and DT TPDU is that the value used for the TPDU code is ED and not DT. The size of a Expedited Data user data field is 1 to 16 octets. For TPDU bit encoding please refer to 'Notes to Implementors' section 6.3. 4.1.3 Connection Release The elements of procedure used during a connection release are identical to those presented in ISO 8073. Transport Disconnection is based on the NS-provider (TCP) Disconnection and is therefore disruptive. Expires April 1996 [Page 12] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 4.2 Class 2 over TCP Class 2 provides the functions needed for connection establishment with negotiation, data transfer with segmentation, and protocol error reporting. It provides Transport Connection with flow control based on that of the NS-provider (TCP). It provides Explicit Transport Disconnection. Class 2 is suitable when independence of Normal and Expedited Data channels are required and when Explicit Transport Disconnection is needed. 4.2.1 Connection Establishment The principles used in connection establishment are based upon those described in ISO 8073, with the following extensions: - Connection Request and Connection Confirmation TPDUs may negotiate the Use of Expedited Data transfer using the negotiation mechanism specified in ISO 8073. The default is to not use Expedited Data. - Connection Request and Connection Confirmation TPDUs must not negotiate the Use of Explicit Flow Control. - Non-standard TPDU size may be negotiated using the negotiation mechanism specified in ISO 8073. The maximum TPDU size is 65531 octets. The default maximum TPDU size is 65531 octets. Please refer to 'Notes to Implementors' section 6.2. For use of ISO 8073 Multiplexing procedure please refer to 'Notes to Implementors' section 6.4. 4.2.2 Data Transfer The elements of procedure used during transfer are based upon those presented in ISO 8073, with the following extensions: - Expedited Data may be supported (if negotiated during connection establishment). Please refer to 'Notes to Implementors' section 6.5. - Splitting and Recombining may be used for Expedited Data transmission. The procedure of splitting and recombining allows a transport connection to make use of multiple TCP connections. Expires April 1996 [Page 13] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 This documents does not mandates implementation of the Splitting procedure for Expedited Data transmission. The Recombination procedure, which associates Data (normal and expedited) TPDUs arriving for a transport connection over two TCP connections must be handled. Please refer to 'Notes to Implementors' section 6.6. 4.2.3 Connection Release The elements of procedure used during a connection release are based upon those described in ISO 8073. A connection can be terminated by the TS-user in one of two ways: - Disruptive Disconnect - Non-Disruptive Disconnect Disconnect Request (DR) and Disconnect Confirm (DC) TPDUs are exchanged in both cases. The DR TPDU carries a Reason code indicating the reason for the Disconnection. Disruptive Disconnect specifies that all TPDUs still at the source are not required to be sent to the destination before the connection is disconnected. The DR Reason code is normal (80 hex). Non-Disruptive Disconnect specifies that all TPDUs already given to the local TS-provider must be delivered to the remote TS-user, before the connection is disconnected. The DR Reason code is normal (80 hex) with Additional Information parameter value set to 80 hex. 4.3 TPKT Packet Format A fundamental difference between the TCP and the ISO Network Service expected by ISO Transport is that the TCP manages a continuous stream of octets, with no explicit boundaries. ISO Transport expects information to be sent and delivered in discrete objects termed Network Service Data Units (NSDU). Although ISO Transport allows combination of more than one TPDU inside a single NSDU for the purposes of discussion an NSDU is identical to a TPDU. Please refer to ISO 8073 for the valid set of concatenated TPDUs. Expires April 1996 [Page 14] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 The protocol described by this memo uses a simple packetization scheme in order to delimit TPDU. Each packet (TPKT), is viewed as an object of variable length composed of an integral number of octets. A TPKT consists of two part: - a Packet Header - a TPDU. The format of the Packet Header is constant regardless of the type of TPDU. The format of the Packet Header is as follows: +--------+--------+----------------+-----------....---------------+ |version |reserved| packet length | TPDU | +----------------------------------------------....---------------+ <8 bits> <8 bits> < 16 bits > < variable length > where: - Protocol Version Number length: 8 bits Value: 3 - Reserved length: 8 bits Value: 0 - Packet Length length: 16 bits Value: Length of the entire TPKT in octets, including Packet Header - TPDU ISO Transport TPDU as defined in ISO 8073 and as defined in this document. Please refer to 'Notes to Implementors' section 6.7. Expires April 1996 [Page 15] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 5. Address representations: NSAPAs & Directory It is sometimes desirable to represent ITOT access point addresses as, printable strings, OSI Network Addresses (often known as NSAP addresses or simply NSAPAs) or in attributes in the X.500 Directory. This section defines the formats which MUST be used. 5.1 String representation of ITOT access point address RFC1278 [RFC1278] defines a string representation for OSI Presentation Addresses in general including specifically RFC1006 addresses which encapsulate IPv4 addresses. RFC1278 is currently being updated to also defines a string representation for ITOT addresses which encapsulate IPv6 addresses. These string representations specify an IP address and an optional TCP port number. 5.2 Network Address encoding RFC1277 [RFC1277] defines mechanisms to encode addressing information within Network Addresses (NSAPA) in general including specifically RFC1006 and ITOT addresses address using IPv4. This encoding format is termed an RFC1006 NSAPA. The following text defines an NSAPA encoding for ITOT over IPv6. Expires April 1996 [Page 16] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 The first three octets are an IDP in binary ICD format, using the ICD code allocated to the IANA, and meaning "this NSAPA embeds a 16 byte IPv6 address". The last octet is a selector and is defined to have the value '10000000'B which is reserved to indicate an ITOT address. This format is termed an ITOT NSAPA. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0-3 | AFI = 47 | ICD = 0090 | IPv6 (byte 0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4-7 | IPv6 (bytes 1-4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8-11 | IPv6 (bytes 5-8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12-15| IPv6 (bytes 9-12) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16-19| IPv6 (bytes 13-15) |1 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Given that IPv6 addresses can encode IPv4 addresses, this format can also encode addresses for ITOT over IPv4. Note: this definition is based upon the work defined in section 6 "IPv6 addresses inside an NSAPA" of draft-ietf-ipngwg-nsap-ipv6-00 [IPV6] This draft is to be published as an Experimental RFC. 5.3 Use of the X.500 Directory When information about an application is stored in the Directory the attributes presentation-address (with syntax PresentationAddress) and protocol-information (with syntax ProtocolInformation) are usually used to specify its access point. The Directory specifications also define attribute types based on the AccessPoint syntax, which includes PresentationAddress and optional ProtocolInformation. The Directory protocols also communicate access points using the AccessPoint type. Expires April 1996 [Page 17] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 5.4 Interpretation of access point information The combination of a presentation address and protocol information in an access point provide three pieces of information relevant to ITOT: (1) the IPv4 or IPv6 address of the peer system; (2) the TCP port number of the peer system or application; (3) the IP network to which the peer system is connected. A presentation address includes from 1 to 8 NSAPAs. The optional protocol information associates an OBJECT IDENTIFIER with each of the NSAPAs. This OBJECT IDENTIFIER identifies the protocol stack and network community for which the NSAPA is valid. The OBJECT IDENTIFIER internet-itot-nsapa is defined in Appendix A for use in protocol information to indicate an ITOT address connected to the Internet. When access point information includes an ITOT NSAPA and the protocol information is either absent, does not contain a corresponding entry for the ITOT NSAPA, or contains a corresponding entry with the value internet-itot-nsapa, then the NSAPA indicates an ITOT address connected to the Internet and using the default TCP port (102). If a corresponding protocol information value is provided with the value {internet-itot-nsapa N}, where N is between 1 and 65535, then this NSAPA indicates an ITOT address connected to the Internet and using TCP port N. If a corresponding protocol information value is provided with some other OBJECT IDENTIFIER (neither internet-itot-nsapa nor an OBJECT IDENTIFIER with that prefix) then this NSAPA indicates an ITOT address connected to an IP network identified by the provided OBJECT IDENTIFIER. Any OBJECT IDENTIFIER defined for such a purpose MUST be defined in such a way that it may be extended to indicate a non- default TCP port number (as in the preceding paragraph). When access point information includes an RFC1006 NSAPA then it shall be interpreted according to the rules of RFC1277. Expires April 1996 [Page 18] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 6. Notes to Implementors 6.1 Class negotiation The principle used in Class negotiation is identical to those described in ISO 8073. Class and options are negotiated during Connection establishment. The choice made by the Transport will depend upon the TS-User requirements as expressed via T-CONNECT service primitives. The initiator of the Transport Connection proposes a preferred class and may propose an alternative class. The responder selects one class defined in the table below. If the preferred class is not selected then on receipt of the connect confirm TPDU the initiator adjusts its operation according to the class selected. +---------------------------------------------+----------------------+ | Proposed in CR TPDU | CC TPDU | | | | |Preferred class | Alternative class | Response | +--------------------+------------------------+----------------------+ | | | | |class 0 | none | class 0 | | | | | |class 2 | class 0 | class 2 or 0 | | | | | |class 2 | none | class 2 | | | | | +---------------------------------------------+----------------------+ Expires April 1996 [Page 19] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 6.2 Default maximum TPDU size The default maximum TPDU size value specified in this document breaks ISO Transport negotiation rule which states that the maximum TPDU size specified or defaulted by the CC TPDU cannot be greater than the maximum TPDU size proposed by the CR TPDU. To avoid the consequences of this, it is strongly recommended that the CC TPDU always specifies the maximum TPDU size value. 6.3 Class 0 TPDU bit encoding RFC1006 TPDU encoding defines inconsistent encoding rules. This protocol no longer allows credit and TPDU-NR (bits 0 to 6) fields to be ignored on input, which is in line with ISO 8073 encoding rules. 6.4 Class 2 Multiplexing In the absence of Flow Control policy, use of ISO 8073 Multiplexing procedure may lead to degradation of the quality of service. The Protocol defined in this document mandates non-use of explicit Flow Control. Therefore, for performance reason, it is recommended to not use ISO 8073 Multiplexing procedure. Please also see issue 7.3. 6.5 Class 2 Expedited Data The document specifies that Class 2 must not negotiate the "Use of Explicit Flow Control". This means that Expedited Data TPDUs requires no Expedited Data Acknowledgement. Expires April 1996 [Page 20] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 6.6 Class 2 Splitting and Recombining procedure When ISO 8073 Splitting and Recombining procedure is used for Expedited Data transmission: - Expedited data must only be sent over an outgoing NS-provider TCP connection. The second TCP connection must not be shared among Transport Connections and must remain established until the Transport Connection is terminated, at which time it must be closed. This is as defined in ISO 8073. It is recommended to only create a second TCP connection for Expedited Data at the time that transmission of Expedited Data is requested. TCP connections created for Splitting purposes should also use the TCP primitives. When this procedure is used for Expedited Data transmission, it guarantees that a busy Normal Data TCP connection cannot block an Expedited Data TCP connection. It also ensures independence of the Normal Data TCP connection from the Expedited Data TCP connection. Please also see issue 7.4. 6.7 TPKT This document specifies the value of the TPKT reserved field. Implementation should not interpret and act upon any value in a reserved field. To avoid Interoperability issues with RFC1006, this field should be ignored on input. Expires April 1996 [Page 21] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 7. Rationale and open issues 7.1 Interoperability with RFC1006 There has been some discussion about the version number to be applied to this protocol. There is two points to be considered in making this decision. 1- The changes between the Protocol defined in RFC1006 and this document are relatively small for Class 0 over TCP. If we were to change the Protocol Version we would prevent existing RFC1006 implementations which mandate version 3 from interoperating with the protocol defined in this document. 2- The Protocol described in this document introduces Class 2 over TCP, and it therefore introduces the need to be able to perform class negotiation between Class 2 and Class 0. While all Transport implementations should be able to handle Class negotiation, we recognise that some RFC1006 implementations cannot. Therefore Implementors should be aware that Class 2 Connect Request (with no Alternative class) could be accepted with a Class 0 Connect Confirm, at which point the Connect Confirm should be rejected as specified in ISO 8073. Given the above, and so long as implementors of this protocol are aware of the implications described above, it is not beneficial to change the Protocol Version Number. Changing the Protocol Version Number could also create Interoperability problems. 7.2 Transport Service Access Point RFC1006 mandates the use of U.S. GOSIP specification for the interpretation of ISO Transport Service Access Point (TSAP-ID). It is the authors belief that no existing implementation of RFC1006 enforces this restriction. Therefore we propose that this requirement should not be carried forward. Expires April 1996 [Page 22] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 7.3 Class 2 Multiplexing ISO 8073 Class 2 allows Multiplexing. This document currently recommends that this capability not be use for performance reasons. We believe that we should not allow Multiplexing. 7.4 Class 2 over TCP Expedited Data handling An issue with the proposal in this document, which allows use of a second channel for Expedited Data transmission, is that in some rare cases the expedited data TPDU on the second channel could be delayed and therefore be overtaken by a following Normal Data TPDU transmitted on the normal channel. A possible solution for this issue is to transmit the same Expedited Data TPDU on both the normal and the secondary channel. But this then leads to the need to identify Expedited Data TPDU with sequence numbers which is non-standard for Class 2 no flow control as well as the need to detect and handle duplicate Expedited Data TPDU. The use of a separate channel as defined in this document is simpler to implement and ensures independence of Normal and Expedited Data channels. The risk associated with Expedited Data TPDU being overtaken is considered low and is preferable to the complexity added by the introduction of Expedited Data sequencing and Expedited Data duplication detection. Expires April 1996 [Page 23] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 Appendix A. Object identifier assignment. The following OBJECT IDENTIFIER is defined for use in protocol information to indicate an ITOT address connected to the Internet using TCP port N. internet-itot-nsapa = (value to be defined by IANA) Immediately subordinate OBJECT IDENTIFIERs, of the form (internet-itot-nsapa N) where N is between 1 and 65535, are defined for use in protocol information to indicate an ITOT address connected to the Internet using TCP port N. Expires April 1996 [Page 24] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 Acknowledgements The authors are pleased to acknowledge the suggestions and comments of Jim Bound, Dan Harrington, Matt Thomas, Steve Kille, John Day, Harald T Alvestrand and many other members of the IETF TOSI mailing list. The support of Allison Mankin of the IESG was essential. References [ISO8072] ISO. "International Standard 8072. Information Processing Systems -- Open Systems Interconnection: Transport Service Definition." [ISO8073] ISO. "International Standard 8073. Information Processing Systems -- Open Systems Interconnection: Transport Protocol Specification." [ISO8348] ISO. "International Standard 8348. Information Processing Systems -- Open Systems Interconnection: Network Service Definition." [RFC791] Internet Protocol. Request for Comments 791 [RFC793] Transmission Control Protocol. Request for Comments 793 [RFC1006] ISO Transport Services on Top of the TCP Version 3. Request for Comments 1006 [RFC1277] Encoding Network Addresses to support operation over non-OSI lower layers Request for Comments 1277 [RFC1278] String encoding of Presentation Address Request for Comments 1278 [IPV6] Internet Protocol, Version 6 (IPv6) Specification (draft-ietf-ipngwg-ipv6-spec-02.txt) IP Version 6 Addressing Architecture (draft-ietf-ipngwg-addr-arch-03.txt) OSI NSAPs and IPv6 (draft-ietf-ipngwg-nsap-ipv6-00.txt) Expires April 1996 [Page 25] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 Authors' Addresses Yanick Pouffary End Systems Networking Phone: +33 92-95-62-85 Digital Equipment Corporation Fax: +33 92-95-62-35 Centre Technique (Europe) Email: pouffary@taec.enet.dec.com B.P. 027 950 Routes des colles 06901 Sophia antipolis, France Alan Young ISODE Consortium Phone: +44 181 332 9091 The Dome Fax: +44 181 332 9019 The Square Email: A.Young@isode.com Richmond, UK Expires April 1996 [Page 26] Internet Draft ISO Transport Service on top of TCP Nov 03, 1995 Y. Pouffary, A. Young Version: 3 Status of this Memo.............................................2 1. Introduction, Motivation.....................................3 2. The Model....................................................4 2.1 ISO Transport Model.........................................4 2.2 ISO Transport over TCP (ITOT) Model.........................5 2.3 Overview of Protocol and Service............................5 3 Service Definition............................................6 3.1 Transport Service Definition................................6 3.1.1 Transport Service Definition Primitives...................6 3.2 Network Service Definition..................................7 3.2.1 ISO 8348 CONS primitives..................................7 3.2.2 TCP Service primitives....................................8 3.2.3 Mapping TCP as a Network Service Provider.................9 3.2.3.1 Network Connection Establishment........................9 3.2.3.2 Network Data Transfer..................................10 3.2.3.3 Network Connection Release.............................10 4. Transport Protocol Specification............................11 4.1 Class 0 over TCP...........................................11 4.1.1 Connection Establishment.................................11 4.1.2 Data Transfer............................................12 4.1.3 Connection Release.......................................12 4.2 Class 2 over TCP...........................................13 4.2.1 Connection Establishment.................................13 4.2.2 Data Transfer............................................13 4.2.3 Connection Release.......................................14 4.3 TPKT Packet Format.........................................14 5. Address representations: NSAPAs & Directory.................16 5.1 String representation of ITOT access point address.........16 5.2 Network Address encoding...................................16 5.3 Use of the X.500 Directory.................................17 5.4 Interpretation of access point information.................18 6. Notes to Implementors.......................................19 6.1 Class negotiation..........................................19 6.2 Default maximum TPDU size..................................20 6.3 Class 0 TPDU bit encoding..................................20 6.4 Class 2 Multiplexing.......................................20 6.5 Class 2 Expedited Data.....................................20 6.6 Class 2 Splitting and Recombining procedure................21 6.7 TPKT.......................................................21 7. Rationale and open issues...................................22 7.1 Interoperability with RFC1006..............................22 7.2 Transport Service Access Point.............................22 7.3 Class 2 Multiplexing.......................................23 7.4 Class 2 over TCP Expedited Data handling...................23 Appendix A. Object identifier assignment.......................24 Acknowledgements...............................................25 References.....................................................25 Authors' Addresses.............................................26 Expires April 1996 [Page 27]