Internet-Draft                                                K. Evans
Expires in 6 months                                           J. Klein
                                                      Tandem Computers
                                                               J. Lyon
                                                             Microsoft
                                                              S. Spero
                                          University of North Carolina
                                                          May 5th 1997

                      Session Control Protocol V 2.0

                       <draft-evans-v2-scp-00.txt>

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-Drafts
   as reference material or to cite them other than as "work in
   progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited. Please send comments to
   the authors at <JimLyon@Microsoft.Com>, <Evans_Keith@Tandem.Com>,
   <Klein_Johannes@Tandem.Com>, or <Ses@Tipper.Oit.Unc.Edu>.

Abstract

   This document describes version 2.0 of the Session Control Protocol
   (SCP)[1]. SCP provides a simple mechanism for creating multiple
   lightweight connections over a single TCP connection. Several such
   lightweight connections can be active simultaneously. SCP provides
   a byte oriented service, but allows message boundaries to be
   marked.

Introduction

   There are several protocols in widespread use on the Internet which
   create a single TCP connection for each transaction. Unfortunately,
   because these transactions are short lived, the cost of setting up
   and tearing down these TCP connections becomes significant, both in
   terms of resources used and in the delays associated with TCP's
   congestion control mechanisms.

   The Session Control Protocol (SCP) is a simple protocol running on
   top of TCP that can be used to create multiple lightweight
   connections over a single transport connection. SCP therefore
   provides for more efficient use of TCP connections. Data from

   several different SCP connections can be interleaved, and both
   message boundaries and end of stream markers can be provided.

   Because SCP runs on top of a reliable byte ordered transport
   service it can avoid most of the extra work TCP must go through in
   order to ensure reliability. For example, SCP connections do not
   need to be confirmed, so there is no need to wait for handshaking
   to complete before data can be sent.

Changes From Previous Version (SCP V 1.1)

   The main changes in this version are that: 1) header compression
   has been removed from the specification, 2) the RESET flag can be
   sent together with any other event, 3) connection identifiers
   reserved by the IANA have been removed, and most important 4) each
   SCP connection is started with a SYN handshake (i.e. the client
   sends a SYN request to initiate a new connection, the server must
   respond with SYN response irrespective of any intention to
   immediately close or reject the newly established connection). This
   approach leads to a very simple state machine and removes a lot of
   race conditions.

Protocol Model

   The basic protocol model is that of multiple lightweight
   connections operating over a reliable stream of bytes. The party
   which initiated the connection is referred to as the client, and
   the party which accepted the connection is referred to as the
   server.

   Connections may be unidirectional or bi-directional; each end of a
   bi-directional connection may be closed separately. Connections may
   be closed normally, or reset to indicate an abortive release.
   Aborting a connection closes both data streams.

   Once a connection has been opened, applications can send messages
   over it, and signal the end of application level messages.
   Application messages are encapsulated in SCP packets and
   transferred over the byte stream. Messages can be split up into
   several different packets.

SCPPacket Format

   An SCP packet consists of a 64 bit header followed by zero or more
   octets of data. The header contains three fields; a flag byte, the
   connection identifier, and the packet length. Both integers, the
   connection identifier and the packet length must be sent in network
   byte order.

    FLAGS
   +--------+--------+--------+--------+
   |SFPR0000| Connection ID            |
   +--------+--------+--------+--------+
   |        | Length                   |
   +--------+--------+--------+--------+

   Flag Details

      +-------+-----------+-----------------------------------------+
      | Name  | Mask      | Description                             |
      +-------+-----------+ ----------------------------------------+
      | SYN   | 1xxx|0000 | Open a new connection                   |
      | FIN   | x1xx|0000 | Close an existing connection            |
      | PUSH  | xx1x|0000 | Mark application level message boundary |
      | RESET | xxx1|0000 | Abort the connection                    |
      +-------+-----------+-----------------------------------------+

Connection Identifiers

   Each SCP connection is identified by a 24 bit integer. Connections
   created by a client must have even identifiers; those created by a
   server must have odd identifiers.

SCP Connection States

   SCP connections can exist in several different states; Closed,
   OpenWrite, OpenSynRead, OpenSynReset, OpenReadWrite, CloseWrite,
   and CloseRead. A connection can change its state in response to
   receiving a packet with the SYN, FIN, or RESET bits set, or in
   response to an API call by the application. The available API calls
   are open, close, and abort.

   The meaning of most states is obvious (e.g. OpenWrite means that a
   connection has been opened for writing). The meaning of the states
   OpenSynRead and OpenResetRead need more explanation.

   In the OpenSynRead state a client opened and immediately closed the
   output data stream of a connection, and is now waiting for a SYN
   response from the server to open the input data stream for reading.

   In the OpenResetRead state a client opened and immediately aborted
   a connection, and is now waiting for a SYN response from the server
   to finally close the connection.

Event Priorities and State Transitions

   The state table shown below describes the actions and state
   transitions that occur in response to a given event. The events
   accepted by each state are listed in priority order with highest
   priority first. If multiple events are present in a message, those
   events matching the list are processed. If multiple events match,
   the event with the highest priority is accepted and processed
   first. Any remaining events are processed in the resultant
   successor state.

   For example, if an SCP connection at the server is in the Closed
   state, and the server receives a packet containing a SYN event, a
   FIN event and an input data event (i.e. DATA-IN), the server first
   accepts the SYN event (because it is the only match in Closed
   state). The server accepts the connection, sends a SYN event and
   enters the ReadWrite state. The SYN event is removed from the list
   of pending events. The remaining events are FIN and DATA-IN. In the
   ReadWrite state the server reads the input data (i.e. the DATA-IN
   event is processed first because it has higher priority than the

   FIN event). Once the data has been read and the DATA-IN event has
   been removed from the list of pending events, the FIN event is
   processed and the server enters the CloseWrite state.

   If either party receives an SCP packet that it does not understand,
   or an event in an incorrect state, it closes the TCPconnection.

   +==============+=========+==========+==============+
   | Entry State  | Event   | Action   | Exit State   |
   +==============+=========+==========+==============+
   | Closed       | SYN     | SYN      | ReadWrite    |
   |              | OPEN    | SYN      | OpenWrite    |
   +--------------+---------+----------+--------------+
   | OpenWrite    | SYN     | Accept   | ReadWrite    |
   |              | WRITE   | DATA-OUT | OpenWrite    |
   |              | CLOSE   | FIN      | OpenSynRead  |
   |              | ABORT   | RESET    | OpenSynReset |
   +--------------+---------+----------+--------------+
   | OpenSynRead  | SYN     | Accept   | CloseRead    |
   +--------------+---------+----------+--------------+
   | OpenSynReset | SYN     | Accept   | Closed       |
   +--------------+---------+----------+--------------+
   | ReadWrite    | DATA-IN | Accept   | ReadWrite    |
   |              | FIN     | Accept   | CloseWrite   |
   |              | RESET   | Accept   | Closed       |
   |              | WRITE   | DATA-OUT | ReadWrite    |
   |              | CLOSE   | FIN      | CloseRead    |
   |              | ABORT   | RESET    | Closed       |
   +--------------+---------+----------+--------------+
   | CloseWrite   | RESET   | Accept   | Closed       |
   |              | WRITE   | DATA-OUT | CloseWrite   |
   |              | CLOSE   | FIN      | Closed       |
   |              | ABORT   | RESET    | Closed       |
   +--------------+---------+----------+--------------+
   | CloseRead    | DATA-IN | Accept   | CloseRead    |
   |              | FIN     | Accept   | Closed       |
   |              | RESET   | Accept   | Closed       |
   |              | ABORT   | RESET    | Closed       |
   +--------------+---------+----------+--------------+

References

   [] "SCP - Session Control Protocol V 1.1"
       http://sunsite.unc.edu/ses/scp.html
       S. Spero

Authors' Addresses

   Jim Lyon                           Keith Evans
   Microsoft Corporation              Tandem Computers, Inc.
   One Microsoft Way                  5425 Stevens Creek Blvd
   Redmond, WA  98052-6399, USA       Santa Clara, CA 95051-7200, USA

   Phone: +1 (206) 936 0867           Phone: +1 (408) 285 5314
   Fax:   +1 (206) 936 7329           Fax:   +1 (408) 285 5245
   Email: JimLyon@Microsoft.Com       Email: Evans_Keith@Tandem.Com

   Johannes Klein                     Simon Spero
   Tandem Computers Inc.              CB 3455, Phillips Hall
   10555 Ridgeview Court              University of North Carolina
   Cupertino, CA 95014-0789, USA      Chapel Hill, NC 27599-3455, USA

   Phone: +1 (408) 285 0453           Phone: +1 (919) 962-8104
   Fax:   +1 (408) 285 9818           Fax:   +1 (919) 962-5664
   Email: Klein_Johannes@Tandem.Com   Email: Ses@Tipper.Oit.Unc.Edu