doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc2126.txt b/doc/rfc/rfc2126.txt
new file mode 100644
index 0000000..28fef84
--- /dev/null
+++ b/doc/rfc/rfc2126.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group                                     Y. Pouffary
+Request for Comments: 2126              Digital Equipment Corporation
+Category: Standards Track                                    A. Young
+                                                     ISODE Consortium
+                                                           March 1997
+
+
+               ISO Transport Service on top of TCP (ITOT)
+
+Status of the Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document is a revision to STD35, 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 will eventually
+   supersede 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.
+
+   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.
+
+Table of Contents
+
+   1. Introduction, Motivation.....................................2
+   2. The Model....................................................3
+   2.1 ISO Transport Model.........................................3
+   2.2 ISO Transport over TCP (ITOT) Model.........................4
+   2.3 Overview of Protocol and Service............................5
+   3 Service Definition............................................5
+   3.1 Transport Service Definition................................5
+   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.................8
+
+
+
+Pouffary & Young            Standards Track                     [Page 1]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+   3.2.3.1 Network Connection Establishment........................8
+   3.2.3.2 Network Data Transfer...................................9
+   3.2.3.3 Network Connection Release.............................10
+   4. Transport Protocol Specification............................10
+   4.1 Class 0 over TCP...........................................10
+   4.1.1 Connection Establishment.................................11
+   4.1.2 Data Transfer............................................11
+   4.1.3 Connection Release.......................................11
+   4.2 Class 2 over TCP...........................................12
+   4.2.1 Connection Establishment.................................12
+   4.2.2 Data Transfer............................................13
+   4.2.3 Connection Release.......................................15
+   4.3 TPKT Packet Format.........................................15
+   5. Address representations.....................................16
+   5.1 String representation of ITOT access point addresses.......17
+   5.2 OSI Network Address encoding...............................17
+   6. Notes to Implementors.......................................17
+   6.1 TCP Connection Establishment...............................17
+   6.2 TCP Data transfer..........................................17
+   6.3 Class negotiation..........................................18
+   6.4 Default maximum TPDU size..................................18
+   6.5 Class 0 TPDU bit encoding..................................18
+   6.6 Class 2 Options............................................19
+   6.7 Class 2 Expedited Data Acknowledgement.....................21
+   6.8 Class 2 Normal Data and Expedited Data handling............21
+   6.9 Class 2 Forward Connection procedure.......................22
+   6.10 TPKT......................................................22
+   7. Rationale - Interoperability with RFC1006...................22
+   8. Security Considerations.....................................23
+   Acknowledgements...............................................23
+   References.....................................................23
+   Authors' Addresses.............................................25
+
+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
+
+
+
+Pouffary & Young            Standards Track                     [Page 2]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+   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].
+
+   The basis of this document is STD35, RFC1006 [RFC1006] written by
+   Marshall T. Rose and Dwight E. Cass and it defines two transport
+   classes of service.  Transport Class 0 refines and supersedes the
+   RFC1006 protocol and is aimed at preserving the RFC1006 installed
+   base.  Transport Class 2 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. These new
+   features are largely based on RFC1859 [RFC1859] and extend the
+   applicability of RFC1006 to new groups of applications.
+
+   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.
+
+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.
+
+
+
+
+
+Pouffary & Young            Standards Track                     [Page 3]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+   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]
+              |
+
+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 minor modifications.
+   See section 3.1.
+
+   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. See section 4.
+
+   This document specifies a simple encapsulation mechanism between the
+   modified ISO 8073 Transport Protocol and the TCP.
+
+
+
+
+
+
+Pouffary & Young            Standards Track                     [Page 4]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+   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.
+
+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
+
+   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
+
+
+
+
+
+Pouffary & Young            Standards Track                     [Page 5]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+3.1.1 Transport Service Definition Primitives
+
+   Information is transferred to and from the TS-User in the Transport
+   Service primitives listed below:
+
+   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
+
+   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
+
+
+
+
+
+
+
+Pouffary & Young            Standards Track                     [Page 6]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+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:
+
+   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
+
+   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
+
+      N-EXPEDITED_DATA.INDICATION
+         - a NS-user is notified that expedited data can be read from
+           the connection
+
+
+
+Pouffary & Young            Standards Track                     [Page 7]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+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:
+
+   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)
+
+   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
+
+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.
+
+
+
+Pouffary & Young            Standards Track                     [Page 8]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+   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
+
+   Please also refer to 'Notes to Implementors' section 6.1.
+
+   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.  Please also refer to 'Notes to Implementors' section 6.2.
+
+   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
+
+
+
+
+
+
+
+Pouffary & Young            Standards Track                     [Page 9]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+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
+
+4. Transport Protocol Specification
+
+   ISO 8073 Transport Protocol Classes 0 and 2 are supported with
+   extensions as defined in each subsections below.
+
+   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 document mandates the implementation of ISO 8073 Transport
+   Protocol options negotiation (which includes class negotiation).
+
+   Please refer to 'Notes to Implementors' section 6.3 with respect to
+   Class negotiation and to the 'Rationale' section 7. 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.
+
+
+
+
+Pouffary & Young            Standards Track                    [Page 10]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+   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 Transfer Service" may be negotiated
+     using the negotiation mechanism specified in ISO 8073. The
+     default is to not use "Expedited Data Transfer Service".
+
+   - 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.4.
+
+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 inband 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.5.
+
+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.
+
+
+
+
+Pouffary & Young            Standards Track                    [Page 11]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+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 or 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 use of "Transport Expedited Data Transfer" service.
+     "Transport Expedited Data Transfer" service is selected
+     by setting bit 1 of the "Additional Option" parameter,
+     and is negotiated using the mechanism specified in ISO 8073.
+
+     The default is to not use "Transport Expedited Data Transfer
+     Service".
+
+   - Connection Request and Connection Confirmation TPDUs may
+     negotiate use of "Expedited Data Acknowledgement".
+     "Expedited Data Acknowledgement" is selected by setting
+     bit 6 of the "Additional Option" parameter, and is
+     negotiated using the mechanism specified in ISO 8073.
+
+     The default is to not use "Expedited Data Acknowledgement"
+     for Expedited Data transfer.
+
+   - Connection Request and Connection Confirmation TPDUs may
+     negotiate use of the "Non-blocking Expedited Data" service.
+     "Non-blocking Expedited Data" is selected by setting
+     bit 7 of the "Additional Option" parameter, and is
+     negotiated using the mechanism specified in ISO 8073.
+
+     The default is to not use the "Non-blocking Expedited
+     Data" service.
+
+   - Connection Request and Connection Confirmation TPDUs may
+     negotiate use of either "Forward Connection (Splitting
+     and Recombining)" or "Reverse Connection" procedure for
+     Expedited Data transfer.
+
+
+
+Pouffary & Young            Standards Track                    [Page 12]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+     Use of "Forward Connection" or use of "Reverse Connection"
+     procedure is selected by setting bit 4 of the "Additional
+     Option" parameter, and is negotiated using the mechanism
+     specified in ISO 8073.
+
+     The default is to use "Forward Connection" procedure for
+     Expedited Data transfer.
+
+   - 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.4.
+
+   In the absence of a Flow Control policy, the use of ISO 8073
+   Multiplexing procedure lead to degradation of the quality of service.
+   The Protocol defined in this document does not supported
+   Multiplexing.
+
+   For the values of the "Additional Option" parameter please refer to
+   'Notes to Implementors' section 6.6.
+
+   For Class 2 options Profile please also refer to 'Notes to
+   Implementors' section 6.6.
+
+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) by sending Expedited Data (ED) TPDU.
+
+   - "Expedited Data Acknowledgement" may be supported (if negotiated
+     during connection establishment) by sending Expedited Data
+     Acknowledgement (EA) TPDU.
+
+     When using "Expedited Data Acknowledgement", ED TPDUs require
+     acknowledgement, and once an ED TPDU is transmitted no further
+     DT/ED TPDUs may be sent until the outstanding ED TPDU has been
+     acknowledged.
+
+     When non-use of "Expedited Data Acknowledgement" has been
+     negotiated, ED TPDUs require no acknowledgement, and further DT/ED
+     TPDUs may be sent immediatly.
+
+
+
+
+Pouffary & Young            Standards Track                    [Page 13]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+     Please refer to 'Notes to Implementors' section 6.7 and section
+     6.8.
+
+   - "Non-blocking Expedited Data" service may be supported (if
+     negotiated during connection establishment).
+
+     When using "Non-blocking Expedited Data" service, the sender of an
+     ED TPDU shall send the ED TPDU on both the Normal Data and
+     Expedited Data TCP connections. Transmission of subsequent DT TPDU
+     will not be interrupted.  The receiver of ED TPDU counts how many
+     ED TPDU it has seen on each TCP connection, and will only deliver
+     to the TS-User the ED TPDU from the TCP connection with the higher
+     count.
+
+     When non-use of "Non-blocking Expedited Data" has been negotiated,
+     ED TPDUs will not be duplicated.
+
+     Please refer to 'Notes to Implementors' section 6.7 and section
+     6.8.
+
+   - For Expedited Data transfer, there are two possible
+     procedures for the establishment and assignment of the Expedited
+     Data TCP connection. Which one is used is negotiated during
+     connection establishment.
+
+     Both the "Forward Connection" procedure and "Reverse Connection"
+     procedure guarantee independence of the Normal Data TCP connection
+     from the Expedited Data TCP connection. They also ensure that a
+     busy Normal Data TCP connection cannot block an Expedited Data TCP
+     connection.
+
+     The Expedited Data TCP connection created by either procedure must
+     be between the same pair of hosts as the Normal Data 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.
+
+     TCP connections created for Expedited Data transfer should also use
+     the TCP primitives defined in this document.
+
+     The Forward Connection (Splitting and Recombining) procedure is
+     defined in ISO 8073. This procedure allows a transport connection
+     to make use of multiple TCP connections. Please refer to 'Notes to
+     Implementors' section 6.9.
+
+     The Reverse Connection procedure is not defined in ISO 8073.  When
+     using the Reverse Connection procedure the initiator of a Transport
+     Connection creates a Normal Data TCP connection using an
+
+
+
+Pouffary & Young            Standards Track                    [Page 14]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+     arbitrarily-chosen local TCP port 'x' and a known remote TCP port
+     (either the ITOT well-known port, or some other). The initiator
+     listens for an incoming TCP connection on the TCP port 'x'. The
+     responder of the Transport Connection must create a second TCP
+     connection (to be used for Expedited Data) using an arbitrarily-
+     chosen local TCP port 'y' and the remote TCP port 'x' , before it
+     can issue a CC TPDU on the Normal Data TCP connection. The
+     initiator need not listen for further TCP connections on port 'x'
+     after the Expedited Data TCP connection is established.
+
+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.
+
+
+
+
+
+
+Pouffary & Young            Standards Track                    [Page 15]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+   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 - (See 'Notes to Implementors' section 6.10)
+
+   - 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.
+
+5. Address representations
+
+   It is desirable to be able to represent ITOT access point addresses
+   as:
+
+      - Printable strings
+
+      - OSI Network Addresses (often known as NSAP addresses
+        or simply NSAPAs)
+
+   This section defines the formats which MUST be used in each case.
+
+
+
+Pouffary & Young            Standards Track                    [Page 16]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+5.1 String representation of ITOT access point addresses
+
+   RFC1278 [RFC1278] defines a general string representation for OSI
+   Presentation Addresses, including specific reference to RFC1006
+   addresses which encapsulate IPv4 addresses. RFC1278 is also
+   applicable to ITOT addresses which encapsulate IPv4 addresses.
+
+   This RFC is currently being updated to define a string representation
+   for ITOT addresses which encapsulate IPv6 addresses.
+
+   ITOT access point address string representation specify an IP address
+   (IPv4 or IPv6) and an optional TCP port number.
+
+5.2 OSI Network Address encoding
+
+   RFC1277 [RFC1277] defines a general mechanism to encode addressing
+   information within OSI Network Addresses (NSAPA), including specific
+   reference to RFC1006 using IPv4. RFC1277 is also applicable to ITOT
+   addresses using IPv4.
+
+   The RFC "IPv6 addresses inside an NSAPA" [IPv6] defines general
+   mechanisms for the support of NSAP addressing in an IPv6 network. It
+   also defines how to embed an IPv6 address inside a OSI NSAP address.
+
+   This RFC is applicable to ITOT addresses using IPv6. For ITOT
+   addresses, the default selector of the NSAPA is defined to have the
+   value '10000000'B.
+
+   It should be noted that given that an IPv6 addresses can encode IPv4
+   addresses, this format can also encode ITOT addresses using IPv4.
+
+6. Notes to Implementors
+
+6.1 TCP Connection Establishment
+
+   Implementors should be aware that ISO transport protocols assume that
+   they will be told by the network service provider (in this case
+   TCP/IP) when the network connection being used to transmit their
+   TPDUs is unexpectedly terminated.  It is therefore strongly suggested
+   that the TCP keep alive mechanism be selected, as this ensures
+   reporting of network connection loss.
+
+6.2 TCP Data transfer
+
+   For performance reason it is suggested that the Nagle algorithm [RFC
+   896] be disabled (using the TCP_NODELAY socket option). This feature
+   allows TPKT data to be sent without delay.
+
+
+
+
+Pouffary & Young            Standards Track                    [Page 17]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+6.3 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         |
+   |                    |                        |                      |
+   +---------------------------------------------+----------------------+
+
+6.4 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.5 Class 0 TPDU bit encoding
+
+   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.  RFC1006 TPDU encoding defined inconsistent encoding
+   rules.
+
+
+
+
+Pouffary & Young            Standards Track                    [Page 18]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+6.6 Class 2 Options
+
+   Class 2 Additional Option parameter value
+
+   +--------------------------------------------------------------------+
+   |  BIT   |                    OPTION                                 |
+   +--------------------------------------------------------------------+
+   |        |                                                           |
+   |    8   | Not applicable                                            |
+   |        |                                                           |
+   |    7   | = 1 Use of Non-blocking Expedited Data                    |
+   |        | = 0 Non-use of Non-blocking Expedited Data (default)      |
+   |        |                                                           |
+   |(*) 6   | = 1 Use of Expedited Data Acknowledgement                 |
+   |        | = 0 non-use of Expedited Data Acknowledgement (default)   |
+   |        |                                                           |
+   |    5   | Not applicable                                            |
+   |        |                                                           |
+   |(*) 4   | = 1 Use of Reverse Connection procedure                   |
+   |        | = 0 Use of Forward Connection procedure (default)         |
+   |        |                                                           |
+   |    3   | Not applicable                                            |
+   |        |                                                           |
+   |    2   | Not applicable                                            |
+   |        |                                                           |
+   |    1   | = 1 Use of Transport Expedited Data Service               |
+   |        | = 0 Non-use of Transport Expedited Data Service (default) |
+   |        |                                                           |
+   +--------------------------------------------------------------------+
+
+   (*) In ISO 8073, bit 4 is defined as use of "Network Expedited"  and
+   bit 6 is defined as "Request Acknowledgement".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pouffary & Young            Standards Track                    [Page 19]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+   Class 2 Options Profile
+
+   +--------------------------------------------------------------------+
+   |  Bits     Service selected                                         |
+   | 1 4 6 7                                                            |
+   +--------------------------------------------------------------------+
+   | 0 x x x   Non-use of Transport Expedited Data Service              |
+   |           ---------------------------------------------------------|
+   |                        Bits 4 6 7 are not applicable (*)           |
+   +--------------------------------------------------------------------+
+   | 1 x x x   Use of Transport Expedited Data Service                  |
+   |           ---------------------------------------------------------|
+   | 1 0 x x       Use of Expedited Data Service with Forward Connection|
+   |               -----------------------------------------------------|
+   | 1 0 1 0                Forward Connection with Expedited Data      |
+   |                        Acknowledgement                             |
+   | 1 0 1 1                Forward Connection with Expedited Data      |
+   |                        Acknowledgement and use of Non-blocking     |
+   |                        Expedited Data  (**)                        |
+   |                        --------------------------------------------|
+   | 1 0 0 0                Forward Connection with non-use of Expedited|
+   |                        Data Acknowledgement  (***)                 |
+   | 1 0 0 1                Forward Connection with non-use of Expedited|
+   |                        Data Acknowledgement and use of Non-blocking|
+   |                        Expedited Data                              |
+   |               -----------------------------------------------------|
+   | 1 1 x x       Use of Expedited Data Service with Reverse Connection|
+   |               -----------------------------------------------------|
+   | 1 1 1 0                Reverse Connection with Expedited Data      |
+   |                        Acknowledgement                             |
+   | 1 1 1 1                Reverse Connection with Expedited Data      |
+   |                        Acknowledgement and use of Non-blocking     |
+   |                        Expedited Data  (**)                        |
+   |                        --------------------------------------------|
+   | 1 1 0 0                Reverse Connection with non-use of Expedited|
+   |                        Data Acknowledgement  (***)                 |
+   | 1 1 0 1                Reverse Connection with non-use of Expedited|
+   |                        Data Acknowledgement and use of Non-blocking|
+   |                        Expedited Data                              |
+   +--------------------------------------------------------------------+
+
+   (*) Note the default (0000) provides an RFC1006-like service with
+   Explicit Transport Disconnection.
+
+   (**) Note in this case use of Expedited Data Acknowledgement with use
+   of Non-blocking Expedited Data is a wasted effort (See section 6.5)
+
+
+
+
+
+Pouffary & Young            Standards Track                    [Page 20]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+   (***) Note in this case Normal and Expedited Data TPDU are not
+   synchronised. (See section 6.6)
+
+6.7 Class 2 Expedited Data Acknowledgement
+
+   The Protocol specified in this document does not define any
+   relationship between use of "Expedited Data Acknowledgement" option
+   and use of "Non-blocking Expedited Data" service.
+
+   However please note that when using "Non-blocking Expedited Data"
+   service it is a wasted effort to use "Expedited Data
+   Acknowledgement", since ED TPDUs are duplicated and sent on both the
+   Normal Data and Expedited Data TCP connections.
+
+6.8 Class 2 Normal Data and Expedited Data handling
+
+   There exist two separate application requirements for using Expedited
+   Data:
+
+   1- Synchronisation of the order of delivery between Normal
+      and Expedited Data TPDU.
+
+   2- Independence of Normal and Expedited data channels. A busy
+      Normal Data channel should not block an Expedited Data channel.
+
+   The protocol described in this document can accommodate both
+   requirements, separately or in combination.
+
+   Synchronisation:
+      If synchronised order of delivery between Normal and Expedited
+      Data TPDU is required then use of either "Expedited Data
+      Acknowledgement" TPDU or use of the "Non-blocking Expedited Data"
+      service must be negotiated during connection establishment.
+
+      If synchronised order of delivery between Normal and Expedited
+      Data TPDU is not required then non-use of "Expedited Data
+      Acknowledgement" need not be negotiated during connection
+      establishment.
+
+   Independence:
+      If Independence of Normal and Expedited data channels is required
+      then Forward or Reverse connection must be negotiated during
+      connection establishment. Expedited data TPDU must be sent on the
+      Expedited data channel.
+
+
+
+
+
+
+
+Pouffary & Young            Standards Track                    [Page 21]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+      If Independence of Normal and Expedited data channels is not
+      required then Forward connection should be negotiated during
+      connection establishment and the Expedited data channels should
+      never be established. Expedited data TPDU is then sent inband on
+      the Normal data channel.
+
+   Finally please note that independence of Normal and Expedited data
+   channels without synchronisation relaxes the Transport Service
+   definition of Expedited data and is not consistent with ISO 8072.
+
+6.9 Class 2 Forward Connection procedure
+
+   As defined in ISO 8073, when "Forward Connection" (Splitting and
+   Recombining) procedure is used for Expedited Data transmission, ED
+   TPDU must only be sent over an outgoing NS-provider TCP connection.
+
+   As defined in ISO 8073, this document does not mandates use 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.
+
+   It is legal to send Expedited Data TPDU inband on the Normal Data TCP
+   connection.
+
+   Please note that the protocol specified in this document does not
+   define when an Expedited Data TCP connection should be established.
+   This is an implementation choice.
+
+   When using "Non-blocking Expedited Data" service it is recommended to
+   not delay establishing Expedited Data TCP connection.
+
+6.10 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.
+
+7. Rationale - Interoperability with RFC1006
+
+   We have chosen to maintain the same TPKT protocol version in ITOT as
+   in RFC1006 (version 3). The reason for this decision is that the
+   changes in this document do not conflict with RFC1006. 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.
+
+
+
+Pouffary & Young            Standards Track                    [Page 22]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+   One consequence of this decision relates to class negotiation.  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.
+
+8. Security Considerations
+
+   Security issues are not specifically addressed in this document.
+   Operation of this protocol is no more and no less secure than
+   operation of TCP and ISO 8073 protocols. The reader is directed there
+   for further reading.
+
+Acknowledgements
+
+   The authors are pleased to acknowledge the suggestions and comments
+   of Harald T. Alvestrand, Jim Bound, John Day, Mike Dyer, Peter
+   Furniss, Dan Harrington, Steve Kille, Keith G. Knightson, Keith
+   Sklower, Matt Thomas, Robert Watson 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." ISO 8073:1992 and 8073:1992/Amd.5:1995.
+
+   [ISO8348]  ISO. "International Standard 8348.  Information Processing
+              Systems - Open Systems Interconnection: Network Service
+              Definition."
+
+   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
+              September 1981.
+
+   [RFC793]   Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, September 1981.
+
+
+
+
+
+Pouffary & Young            Standards Track                    [Page 23]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+   [RFC896]   Nagle, J., "Congestion Control in IP/TCP Inertnetworks",
+              RFC 896, January 1984.
+
+   [RFC1006]  Rose, M., and D. Cass, "ISO Transport Services on Top of
+              the TCP Version 3", STD 35, RFC 1006, May 1987.
+
+   [RFC1277]  Hardcastle-Kille, S., "Encoding Network Addresses to
+              support operation over non-OSI lower layers", RFC 1277,
+              November 1991.
+
+   [RFC1278]  Hardcastle-Kille, S., "String encoding of Presentation
+              Address", RFC 1278, November 1991.
+
+              A string encoding of Presentation Address
+              update to RFC1278, Work in Progress.
+
+   [RFC1859]  Pouffary, Y., "ISO Transport Class 2 Non-use of Explicit
+              Flow Control over TCP - RFC1006 extension", RFC 1859,
+              October 1995.
+
+   [IPV6]     Deering, S., and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 1883, December 1995.
+
+              Hinden,, R., and S. Deeing, "IP Version 6 Addressing
+              Architecture", RFC 1884, December 1995.
+
+              Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.,
+              and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pouffary & Young            Standards Track                    [Page 24]
+
+RFC 2126              ISO Transport on top of TCP             March 1997
+
+
+Authors' Addresses
+
+   Yanick Pouffary
+   End Systems Networking
+   Digital Equipment Corporation
+   Centre Technique (Europe)
+   B.P. 027
+   950 Routes des colles
+   06901 Sophia antipolis, France
+
+   Phone: +33 92-95-62-85
+   Fax:   +33 92-95-62-35
+   EMail: pouffary@taec.enet.dec.com
+
+
+   Alan Young
+   ISODE Consortium
+   The Dome
+   The Square
+   Richmond, UK
+
+   Phone: +44 181 332 9091
+   Fax:   +44 181 332 9019
+   EMail: A.Young@isode.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pouffary & Young            Standards Track                    [Page 25]
+