GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1859

Network Working Group Y. Pouffary Request For Comments: 1859 Digital Equipment Corporation Category: Informational October 1995

  ISO Transport Class 2 Non-use of Explicit Flow Control over TCP
                         RFC1006 extension

Status 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 Contents

 1. Introduction - General recommendations.......................2
 2. The protocol.................................................3
 2.1 TCP service as a Network Service - The Primitives...........3
 2.2 Connection Establishment....................................4
 2.3 Data Transfer...............................................5
 2.4 Connection Release..........................................6
 3. Packet Format................................................6
 4. DIGITAL DECnet over TCP/IP...................................8
 Acknowledgements................................................9
 References......................................................9
 Author's Address................................................9

1. 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 in RFC1006 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 the RFC1006 and ISO
 8073.
 The RFC1006 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 the

Pouffary 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-known RFC1006 TCP port 102 not be
 used. This recommendation is done to minimise impact to an existing
 RFC1006 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:
  1. Expedited Data service is supported.
  1. Splitting and Recombining may be used for Expedited Data

transmission.

  1. 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 the
 RFC1006 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          ignored

Pouffary Informational [Page 3] RFC 1859 ISO Transport and Flow Control October 1995

2.2 Connection Establishment

 The principles used in connection establishment are based upon those
 described in ISO 8073, with the following extensions.
  1. Connection Request and Connection Confirmation TPDUs may negotiate

the use of Expedited Data transfer using the negotiation mechanism

   specified in ISO 8073.
  1. 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.
  1. Expedited Data may be supported (if negotiated during connection

establishment).

   In Non-Use of Explicit Flow Control Expedited Data requires no
   Expedited Data Acknowledgement.
  1. 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:
  1. Abort Disconnect specifies that all messages at the source are not

required to be sent to the destination before the connection is

   disconnected.
  1. 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 in RFC1006 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 in RFC1006 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 from
 RFC1006.
     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 this RFC1006 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  as

Pouffary 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, RFC
            793, 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 1995

Security 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.com

Pouffary Informational [Page 8]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1859.txt · Last modified: 1995/11/22 17:53 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki