rfc2126.txt

RFC 的详细文档！

   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".