Internet DRAFT - draft-evans-v2-scp
draft-evans-v2-scp
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:50:32 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 17 Mar 1998 16:33:00 GMT
ETag: "2e6b70-2c68-350ea5bc"
Accept-Ranges: bytes
Content-Length: 11368
Connection: close
Content-Type: text/plain
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
[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
