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]