[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00
INTERNET-DRAFT C. Sapuntzakis
Cisco Systems
<draft-csapuntz-tcpmsgbnd-00.txt> August 2000
Expires February 2001
TCP Message Boundary Option
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 docu¡
ments at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) Cisco Systems (2000). All Rights Reserved.
Abstract
TCP does not have a mechanism for specifying message boundaries in
a stream. This I-D describes a new TCP option and a new way of
using the TCP urgent field to specify message boundaries in the
stream.
Sapuntzakis [Page 1]
Internet-Draft TCP Message Boundary option 29 August 2000
Introduction
TCP does not have a built-in mechanism for signalling message
boundaries at the TCP layer.
Most current TCP message encapsulations place the message length at
the beginning of each message. The message length serves to delin¡
eate the end of the current message as well as the beginning of the
next message.
Unfortunately, when relying solely on this scheme, missing a seg¡
ment with a message length makes it impossible to find message
boundaries in subsequent segments. The missing segment must be
received before later segments can be parsed and processed.
There are several ways to get around this.
* Make each message fixed size
* Put synchronization information in the stream at fixed intervals
* Use a marker byte to mark message boundaries
However, none of these techniques seems particularly appetizing.
Marker bytes work well for hardware but the escape sequences they
assume make it difficult for software. Putting information at fixed
intervals in the stream does not prevent the information from being
split across segments.
Instead, this document proposes a combination of a TCP option and
an overloaded usage of the urgent field in the TCP header.
This option brings TCP more in-line with the principles of applica¡
tion-layer framing outlined in [ALF].
- Message boundary option
1.1. Usage
This TCP option appears only during negotiation. It is a two byte
option, with kind <fill in here> and length 2. If both sides indi¡
cate support for the TCP message boundary option, then the URG bit
is interpreted as below.
Sapuntzakis [Page 2]
Internet-Draft TCP Message Boundary option 29 August 2000
- Redefinition of the URG bit and
The URG bit and urgent pointer are redefined from RFC 793. An URG
bit set to one in a segment indicates that the urgent pointer is
valid.The sum of the urgent pointer and sequence number of the TCP seg¡
ment yields the sequence number of the first byte of an applica¡
tion-layer message. -
Security considerations
A malicious interceptor could modify the message boundary informa¡
tion, falsely indicating message boundaries and corrupting the
stream. However, such an interceptor could probably manipulate the
stream to corrupt it in other ways.
Sapuntzakis [Page 3]
Internet-Draft TCP Message Boundary option 29 August 2000
- Authors’ Addresses
Constantine Sapuntzakis
Cisco Systems, Inc.
170 W. Tasman Drive
San Jose, CA 95134
USAPhone: +1 408 525 5497
Email: csapuntz@cisco.com -
References
[ALF] D. D. Clark and D. L. Tennenhouse, “Architectural considera¡
tions for a new generation of protocols,” in SIGCOMM Symposium on
Communications Architectures and Protocols , (Philadelphia, Penn¡
sylvania), pp. 200–208, IEEE, Sept. 1990. Computer Communications
Review, Vol. 20(4), Sept. 1990.[TCP] Postel, J., “Transmission Control Protocol – DARPA Internet
Program Protocol Specification”, RFC 793, September 1981Expires February 2001
Sapuntzakis [Page 4]
Html markup produced by rfcmarkup 1.115, available from https://tools.ietf.org/tools/rfcmarkup/