Movatterモバイル変換

Network Working Group                                        Y. PouffaryRequest For Comments: 1859                 Digital Equipment CorporationCategory: Informational                                     October 1995ISO Transport Class 2 Non-use of Explicit Flow Control over TCPRFC1006 extensionStatus of this Memo   This memo provides information for the Internet community.  This memo   does not specify an Internet standard of any kind.  Distribution of   this memo is unlimited.Table of Contents1. Introduction - General recommendations.......................22. The protocol.................................................32.1 TCP service as a Network Service - The Primitives...........32.2 Connection Establishment....................................42.3 Data Transfer...............................................52.4 Connection Release..........................................63. Packet Format................................................64. DIGITAL DECnet over TCP/IP...................................8   Acknowledgements................................................9   References......................................................9   Author's Address................................................91. Introduction - General recommendations   This document is an extension to STD35,RFC1006, a standard for the   Internet community. The document does not duplicate the protocol   definitions contained inRFC1006 and in International Standard ISO   8073.  It supplements that information with the description of how to   implement ISO Transport Class 2 Non-use of Explicit Flow Control on   top of TCP.   The document should be used in conjunction with theRFC1006 and ISO   8073.   TheRFC1006 standard defines how to implement ISO 8073 Transport   Class 0 on top of TCP. This memo defines how to implement ISO 8073   Transport Class 2 Non-use of Explicit Flow Control on top of TCP.   Like ISO Transport Class 0, Class 2 Non-use of Explicit Flow Control   provides basic connection with minimal overhead.   A Transport protocol class is selected for a particular Transport   connection based upon the characteristics of the lower layers and thePouffary                     Informational                      [Page 1]

RFC 1859            ISO Transport and Flow Control          October 1995   requirements of the upper layer. Use of class 2 Non-use of Explicit   Flow Control is suitable when the use of separate virtual data   channels for normal and expedited Data are desirable or when an   explicit disconnection of the Transport connection is desirable.   Hosts which choose to implement this extension are expected to listen   on the well-known TCP port number 399.   It is recommended that the well-knownRFC1006 TCP port 102 not be   used. This recommendation is done to minimise impact to an existingRFC1006 implementation.   The memo also describes the use of this extension within the DIGITAL   Network Architecture (DNA).2. The protocol   The protocol specified by this memo is fundamentally equivalent to   the protocol ISO 8073 Transport Class 2 Non-use of Explicit Flow   Control, with the following extensions:   - Expedited Data service is supported.   - Splitting and Recombining may be used for Expedited Data     transmission.   - The Network Service used is provided by TCP.   The ISO 8073 Transport protocol Class 2 allows Multiplexing. It is   recommended that this capability not be use for performance reasons.   The ISO 8073 Transport protocol exchanges information between peers   in discrete units of information called transport protocol data units   (TPDUs).  The protocol defined in this memo encapsulates these TPDUs   in discrete units called TPKTs.  The structure of these TPKTs and   their relationship to TPDUs are discussed in the next sections.2.1 TCP service as a Network Service - The Primitives   The mapping between the TCP service primitives and the service   primitives expected by ISO 8073 Transport when operation over   Connection-oriented network service is straightforward.Pouffary                     Informational                      [Page 2]

RFC 1859            ISO Transport and Flow Control          October 1995   Note: The following description of the mapping is a repeat from theRFC1006 standard.   network service                 TCP   ---------------                 ---   CONNECTION ESTABLISHMENT           N-CONNECT.REQUEST       open completes           N-CONNECT.INDICATION    listen (PASSIVE open) finishes           N-CONNECT.RESPONSE      listen completes           N-CONNECT.CONFIRMATION  open (ACTIVE open) finishes   DATA TRANSFER           N-DATA.REQUEST          send data           N-DATA.INDICATION       data ready followed by read data   CONNECTION RELEASE           N-DISCONNECT.REQUEST    close           N-DISCONNECT.INDICATION connection closes or errors   Mapping parameters between the TCP service and the network service is   also straightforward:   network service                 TCP   ---------------                 ---   CONNECTION ESTABLISHMENT           Called address          server's IP address (4 octets)           Calling address         client's IP address (4 octets)           all others              ignored   DATA TRANSFER           NS-user data (NSDU)     data   CONNECTION RELEASE           all parameters          ignoredPouffary                     Informational                      [Page 3]

RFC 1859            ISO Transport and Flow Control          October 19952.2 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.   - Connection Request and Connection Confirmation TPDUs must not     negotiate the Use of Explicit Flow Control.   To perform an N-CONNECT.REQUEST action, the TS-peer performs an   active open to the desired IP address using the well know TCP port   399.  When the TCP signals either success or failure, this results in   an N-CONNECT.INDICATION action.   To await an N-CONNECT.INDICATION event, a server listens on the well   know TCP port 399.  When a client successfully connects to this port,   the event occurs and an implicit N-CONNECT.RESPONSE action is   performed.2.3 Data Transfer   The elements of procedure used during transfer are based upon those   presented in ISO 8073, with the two following extensions.   - Expedited Data may be supported (if negotiated during connection     establishment).     In Non-Use of Explicit Flow Control Expedited Data requires no     Expedited Data Acknowledgement.   - 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.     TCP connections created for Splitting purposes should also use     the primitives described in 2.1.     It is recommended to only create a second TCP connection for     Expedited Data when transmission of Expedited Data is requested.     Expedited Data must only be sent over an outgoing TCP connection.     This 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.Pouffary                     Informational                      [Page 4]

RFC 1859            ISO Transport and Flow Control          October 1995   Implementors note: The procedure of Splitting and Recombining for   Expedited Data transmission guaranties that a congested 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.   To perform an N-DATA.REQUEST action, the TS-peer constructs the   desired TPKT and uses the TCP send data primitive.   To trigger an N-DATA.INDICATION action, the TCP indicates that data   is ready and a TPKT is read using the TCP read data primitive.2.4 Connection Release   The elements of procedure used during a connection release are   identical to those presented in ISO 8073.   A connection can be terminated by the user in one of two ways:   - Abort Disconnect specifies that all messages at the source are not     required to be sent to the destination before the connection is     disconnected.   - Synchronous Disconnect specifies that all messages at the source     must be sent to the destination, and that all messages at the     destination must be delivered, before the connection is     disconnected.   Disconnect Request and Disconnect Confirmation TPDUs are exchanged in   both cases. The Disconnect Request TPDU carries a code indicating the   reason for the disconnection.   In the case of a Synchronous Disconnect the Disconnect Request reason   code is normal (80 hex). For an Abort Disconnect the Disconnect   Request reason code is normal with additional information parameter   value set to (c0 hex).   Upon receipt of a Disconnect Confirmation TPDU a N-DISCONNECT.REQUEST   action is performed to close the TCP connection.   If the TCP connection fails for some other reason, this generates an   N-DISCONNECT.INDICATION event.3. Packet Format   A fundamental difference between TCP and the network service expected   by ISO transport is that TCP manages a continuous stream of octets,   with no explicit boundaries.Pouffary                     Informational                      [Page 5]

RFC 1859            ISO Transport and Flow Control          October 1995   The protocol described inRFC1006 uses a simple packetization scheme   in order to delimit TPDUs. Each packet, termed a TPKT, consists of   two parts: a packet-header and a TPDU.   We use the same scheme described inRFC1006 for this extension.   There is no need to change the version number. The ISO transport TPDU   sufficiently describes the transport protocol class being used.   The format of the packet-header described below is a repeat fromRFC1006.       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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |      vrsn     |    reserved   |          packet length        |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         where:         vrsn                         8 bits         This field is always 3 for the version of the protocol         described in this memo.         packet length                16 bits (min=7, max=65535)         The packet length is the length of the entire packet in         octets, including packet-header.   The format of the ISO transport TPDU is defined in ISO 8073.4. DIGITAL DECnet over TCP/IP   DECnet over TCP/IP is implemented using the DECnet Session Control   layer over thisRFC1006 extension protocol.   The informational RFC defined in this document provides the Transport   Service functionality required by DECnet Applications while operating   over TCP/IP.   The next paragraph is a brief summary of the role of the DECnet   Session Control Layer. For further details, refer to the DIGITAL DNA   Session Control Layer Specification.   The DECnet Session Control Layer makes a Transport Service available   to End Users of a network. This layer is concerned with system-   dependent functions related to creating, maintaining, and destroying   Transport Connections.  Separate virtual data channels, known  asPouffary                     Informational                      [Page 6]

RFC 1859            ISO Transport and Flow Control          October 1995   "Normal"  and  "Expedited",  are provided to End Users. DECnet   Session Control must be guaranteed independence of these channels by   the Transport Layer. Expedited Data transmission cannot be blocked by   a congested normal data channel. DECnet Session Control requires that   all data in transit be delivered before initiating the release of the   Transport Connection.   DECnet, DNA, and the DIGITAL logo are trademarks of Digital Equipment   Corporation.Acknowledgements   Bill Duane, Jim Bound, David Sullivan, Mike Dyer, Matt Thomas, Dan   Harrington and many other members of the DECnet engineering team.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."   [ISO8327]  ISO. "International Standard 8327.  Information              Processing Systems -- Open Systems Interconnection:              Session Protocol Specification."   [RFC791]   Postel, J., "Internet Protocol - DARPA Internet Program              Protocol Specification", STD 5,RFC 791,              USC/Information Sciences Institute, September 1981.   [RFC793]   Postel, J., "Transmission Control Protocol - DARPA              Internet Program Protocol Specification", STD 7,RFC793, USC/Information Sciences Institute, September 1981.   [RFC1006]  Rose, M., and D. Cass, "ISO Transport Services on Top of              the TCP - Version: 3", STD 35,RFC 1006, Northrop              Research and Technology Center, May 1987.Pouffary                     Informational                      [Page 7]

RFC 1859            ISO Transport and Flow Control          October 1995Security Considerations   Security issues are not discussed in this memo.Author's Address   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-32   EMail: pouffary@taec.enet.dec.comPouffary                     Informational                      [Page 8]