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 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 , , , or . 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 [1] "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