Network Working Group P. Conrad
Internet-Draft University of Delaware
Expires: June 18, 2004 P. Lei
Cisco Systems, Inc.
December 19, 2003
TCP Mapping for Reliable Server Pooling Enhanced Mode
draft-ietf-rserpool-tcpmapping-01.txt
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 documents 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.
This Internet-Draft will expire on June 18, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This memo defines the shim protocol that maps the requirements of the
ASAP protocol [5] to the capabilities of the TCP protocol [7]. In
particular, this shim protocol adds the following capabilties that
are required by ASAP, but not provided by TCP: (1) message
orientation, (2) heartbeat messages, (3) multiple streams, and (4)
undelivered message retrieval (if provided).
Conrad & Lei Expires June 18, 2004 [Page 1]
Internet-Draft RSerPool Mapping for TCP December 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Brief overview of RSerPool . . . . . . . . . . . . . . . . . . 3
1.2 Role of the TCP Mapping Protocol . . . . . . . . . . . . . . . 3
1.3 Consistency of Service . . . . . . . . . . . . . . . . . . . . 5
2. Conventions Used In This Document . . . . . . . . . . . . . . 6
3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Basic Chunk Format . . . . . . . . . . . . . . . . . . . . . . 6
3.2 DATA Chunk . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 INIT Chunk . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 ACK Chunk . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 HEARTBEAT Chunk . . . . . . . . . . . . . . . . . . . . . . . 14
3.6 HEARTBEAT ACK Chunk . . . . . . . . . . . . . . . . . . . . . 15
4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 19
Conrad & Lei Expires June 18, 2004 [Page 2]
Internet-Draft RSerPool Mapping for TCP December 2003
1. Introduction
This memo defines the shim protocol that maps the requirements of the
ASAP protocol [5] to the capabilities of the TCP protocol [7]. See
[6] for details of these mapping requirements.
1.1 Brief overview of RSerPool
The RSerPool framework is designed to provide high availability for
client/server applications. Servers (called "pool elements" or
"PEs") are grouped into "pools". Each pool is named by a "pool
handle", which is simply an octet string that identifies the pool.
PEs join or leave a pool by registering and deregistering with an
RSerPool nameserver (called an "ENRP server", after the ENRP protocol
[4] that is used to share information among RSerPool nameservers).
Clients (called "pool users" or "PUs") that want to obtain service
contact the ENRP server; the PU provides a pool handle, and the ENRP
server returns a list of available servers. Associated with each
server is a policy value; the PU then uses a "pool element selection
policy" (such as round robin, or least used) to determine which of
the PEs to contact.
The ASAP protocol [5] is used to communicate between the PU and the
ENRP server, and between the PE and ENRP server, while the ENRP
protocol [4] is used to communicate between and among RSerPool ENRP
nameservers.
The RSerPool services framework provides two distinct channels,
control and data, for delivery of RSerPool control messages and
application layer data messages. Mappings provide the adaptions of
the ASAP services to the specific transport protocols.
1.2 Role of the TCP Mapping Protocol
The actual application-specific communication between the PU and PE
is defined by the application layer protocol, and does not use the
ASAP protocol, per se. However, when failover services (such as
forwarding of undelivered/unacknowledged messages) are desired by the
application, all communication between a PU and a PE takes place
through services provided by RSerPool, and more specifically, by the
ASAP entity on the PU or PE. Furthermore, in order for the RSerPool
framework to provide a consistent set of services for both
application-specific data and RSerPool messages, this transport
service must follow a particular model. This model includes features
that are present in SCTP, but are lacking in TCP. Specifically,
these are:
Conrad & Lei Expires June 18, 2004 [Page 3]
Internet-Draft RSerPool Mapping for TCP December 2003
(1) Message Orientation. Messages must be framed within the TCP byte
stream to allow for undelivered message retrieval (see below), and
so that ASAP transport services can be consistent between SCTP and
TCP.
(2) Heartbeat Messages. Heartbeats are needed so that a failed
connection can be detected in a timely manner, even if that
connection is idle. The "keepalive" mechanism provided in some TCP
implementations (but not a standard feature of the protocol; see
RFC1122) is not sufficient for this purpose.
(3) Retreival of Undelivered Messages. A PU can request that the ASAP
layer detects when the transport layer association/connection
between that PU and some PE has failed, and automatically failover
to a new PE. In this case, it is necessary for the ASAP layer to
determine which messages were not successfully delivered to the
PE, retrieve them from the transport layer below, and resend them
to the new PE. SCTP provides the RETRIEVE_UNSENT primitive
(Section 10.1, item (E) of RFC2960) to enable this retrieval. TCP
has no such facility.
To provide this capability over TCP, the mapping protocol provides
another layer of acknowledgements on top of TCP; these acks are
sent only when a message is actually delivered to the end system
application (as opposed to when the message is handed up from the
IP layer to the TCP layer). The sending side buffers messages
until this acknowledgement is received, so that in the event of
failover, these messages can be retrieved by the ASAP entity, and
resent to the new PE.
This feature is optional and is NOT required. However, an
appropriate error code must be returned to the upper layer if this
feature is requested, but is unavailable (not implemented).
(4) Other features present in SCTP. Two other features present in
SCTP are simulated by the TCP mapping layer, namely the multiple
streams feature and the protocol payload identifier field (PPID).
Strictly speaking these features are not necessary for RSerPool
operation. However, it is trivial to provide these features in the
TCP mapping layer, and providing them offers an important benefit,
without significantly increasing the complexity of the protocol or
the on-the-wire overhead. This is discussed further in Section
1.3
NOTE: PU-PE communication that is NOT mediated by the RSerPool
framework is allowable when the application layer does not require
data channel services. In this case, no mapping for application
layer data is used regardless of the transport protocol used as they
Conrad & Lei Expires June 18, 2004 [Page 4]
Internet-Draft RSerPool Mapping for TCP December 2003
will be tranported over the appropriate application-defined tranport
protocol.
1.3 Consistency of Service
The main benefit of including provision for multiple streams and the
PPID field in the RSerPool TCP mapping protocol is "consistency of
service." By "consistency of service", we mean that the data
transport service provided by RSerPool is consistent regardless of
the underlying transport protocol used.
To see the benefit of consistency of service, consider an RSerPool
enabled application that will be used by clients with a wide range of
capabilities, e.g. wired desktop PCs at the one end, down to PDAs or
cell phones at the other. On some of these platforms, SCTP may be
available, while on others, only TCP will be available. If the
multiple stream and PPID features are provided in the TCP mapping,
then the application designer can design once to a single API, where
regardless of the underlying transport used, multiple streams can be
used to multiplex various kinds of messages. On PUs where SCTP is
supported, an additional benefit is available, in that partial order
delivery allows head of line blocking to be avoided. This is not the
case for the systems where the TCP mapping is used, since all streams
are mapped onto a single ordered TCP byte-stream. However, either
way, the application designer doesn't have to be concerned; one can
write to a single API, and the software will function correctly over
either protocols, taking advantage of optimizations where available.
The alternative is to omit these features from the TCP mapping, and
indicate that when the underlying protocol is TCP, that all data is
implicitly sent over stream zero, and that the PPID field is ignored.
However, this will encourage designers of application that run in a
"mixed" environment to write to the "lowest common denominator" of
functionality to avoid having to maintain special case code for each
transport layer mapping. Thus, few applications will take advantage
of the features offered by SCTP. The result may be that application
with multiple streams will do their own multiplexing within the
application layer protocol, send all data over stream zero, thus
defeating the SCTP mechanism for avoiding head of line blocking.
Similiarly, few applications will take advantage of the PPID field,
meaning that it will be wasted space in the case where SCTP is
available.
Of course, providing these extra features is not without some cost;
in particular extra fields in the protocol header, and extra
complexity in the implementation. Our compromise solution to the
overhead of the extra fields is to include them in the data chunk
definition, however to allow the service user to turn them off as an
Conrad & Lei Expires June 18, 2004 [Page 5]
Internet-Draft RSerPool Mapping for TCP December 2003
optimization if they are not going to be used (see Section 3.3 and
Section 3.2 for more details.)
As for the complexity, it turns out that because the TCP byte-stream
preserves the order of each stream, providing for multiple streams is
trivial; it involves only passing the stream number through just as
the PPID is "passed through".
Thus, for minimal extra cost, "consistency of service" is preserved
by including multiple streams and the PPID field in the TCP mapping.
It is RECOMMENDED that any future mappings of RSerPool to other
transport protocols SHOULD follow this model of providing
"consistency of service" where possible.
2. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
The terms "transmission sequence number" (TSN), "stream number",
"stream identifier", "stream sequence number", and "payload
protocol-id(PPID)" are used in this document with meanings analogous
to their meanings in RFC2960 [8]; it is assumed that the reader is
familiar with these terms as they appear in that document.
Comparisons and arithmetic on TSNs and stream sequence numbers are
governed by the rules in Section 1.6 of RFC2960 [8].
3. Packet Format
In the RSerPool TCP mapping protocol, each peer transmits a series of
chunks over the TCP byte stream. The format of these chunks is
similar to that of the chunk format of SCTP.
3.1 Basic Chunk Format
The figure below illustrates the field format for the chunks to be
transmitted in the SCTP packet. Each chunk is formatted with a Chunk
Type field, a chunk-specific Flag field, a Chunk Length field, and a
Value field.
Conrad & Lei Expires June 18, 2004 [Page 6]
Internet-Draft RSerPool Mapping for TCP December 2003
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Chunk Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Type: 8 bits (unsigned integer)
This field identifies the type of information contained in the
Chunk Value field. It takes a value from 0 to 254. The value of
255 is reserved for future use as an extension field.
The values of Chunk Types are defined as follows:
ID Value Chunk Type
----- ----------
0 - Payload Data (DATA)
1 - Initiation (INIT)
2 - reserved by IETF
3 - Acknowledgement (ACK)
4 - Heartbeat Request (HEARTBEAT)
5 - Heartbeat Acknowledgement (HEARTBEAT ACK)
6 to 255 - reserved by IETF
Chunk Flags: 8 bits
The usage of these bits depends on the chunk type as given by the
Chunk Type. Unless otherwise specified, they are set to zero on
transmit and are ignored on receipt.
Chunk Length: 16 bits (unsigned integer)
This value represents the size of the chunk in bytes including the
Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
Therefore, if the Chunk Value field is zero-length, the Length
field will be set to 4. The Chunk Length field does not count any
padding.
Chunk Value: variable length
The Chunk Value field contains the actual information to be
transferred in the chunk. The usage and format of this field is
dependent on the Chunk Type.
Conrad & Lei Expires June 18, 2004 [Page 7]
Internet-Draft RSerPool Mapping for TCP December 2003
The total length of a chunk (including Type, Length and Value fields)
MUST be a multiple of 4 bytes. If the length of the chunk is not a
multiple of 4 bytes, the sender MUST pad the chunk with all zero
bytes and this padding is not included in the chunk length field.
The sender should never pad with more than 3 bytes. The receiver
MUST ignore the padding bytes.
3.2 DATA Chunk
The figure below illustrates the field format for the DATA chunk.
Note that it is nearly identical to the format of the DATA chunk in
SCTP. The following differences should be noted: (1) No B and E bits
for fragmentation (2) the second, third, and fourth 32-bit words are
all optional, and can be supressed (independently) through flags in
the INIT message (as explained further below.)
All ASAP protocol messages and application-layer data (when sent
through the RSerPool framework data channel) MUST be carried in DATA
chunks.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|R R| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved, and bits marked "R": 5 bits and 2 bits, respectively
The sender SHOULD set all '0's and the receiver SHOULD ignore.
U bit: 1 bit
The (U)nordered bit, if set to '1', indicates that this is an
Conrad & Lei Expires June 18, 2004 [Page 8]
Internet-Draft RSerPool Mapping for TCP December 2003
unordered DATA chunk, and there is no Stream Sequence Number
assigned to this DATA chunk. Therefore, the receiver MUST ignore
the Stream Sequence Number field.
Length: 16 bits (unsigned integer)
This field indicates the length of the DATA chunk in bytes from
the beginning of the type field to the end of the user data field
excluding any padding.
TSN : 32 bits (unsigned integer)
This value represents the TSN for this DATA chunk. The valid range
of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps back to 0
after reaching 4294967295. In the TCP mapping protocol (unlike in
SCTP), this field MUST start at 0 with each new connection. Also
note that this field is redundant; TSN of each data chunk is
implicit by its position in the TCP byte stream. It does server
the purpose of providing additional robustness against errors in
a sender or receiver protocol implementation, however if desired,
it MAY be supressed for the lifetime of the TCP connection via a
flag in the INIT chunk.
Stream Identifier S: 16 bits (unsigned integer)
Identifies the stream to which the following user data belongs.
If desired, the entire 32-bit word containing Stream Identifier
and Stream Sequence Number MAY be supressed to save bandwidth;
in this case, all data chunks MUST be interpreted by the receiver
to be part of stream 0, and should be delivered to the end user
as such.
Stream Sequence Number n: 16 bits (unsigned integer)
This value represents the stream sequence number of the following
user data within the stream S. Valid range is 0 to 65535. Note
that this field, like TSN, is redundant, but it provides extra
robustness.
Note that unlike SCTP, there is no concept of fragmentation in the
TCP mapping protocol.
Payload Protocol Identifier: 32 bits (unsigned integer)
This value represents an application (or upper layer) specified
protocol identifier. This value is passed to the TCP mapping
layer from the upper layer and sent to its peer. This identifier
Conrad & Lei Expires June 18, 2004 [Page 9]
Internet-Draft RSerPool Mapping for TCP December 2003
is not used by the TCP mapping layer but can be used by certain
network entities as well as the peer application to identify the
type of information being carried in this DATA chunk.
The IANA assigned SCTP protocol payload identifier value for ASAP
(11) MUST be used for the transport of ASAP messages (eg. RSerPool
control channel messages).
The value 0 indicates no application identifier is specified by
the upper layer for this payload data. If the application has no
use for this field, it can be supressed for all data chunks over
the lifetime of the TCP connection via a flag in the INIT message.
User Data: variable length
This is the payload user data. The implementation MUST pad the
end of the data to a 4 byte boundary with all-zero bytes. Any
padding MUST NOT be included in the length field. A sender MUST
never add more than 3 bytes of padding.
3.3 INIT Chunk
The figure below illustrates the field format for the INIT chunk. The
INIT chunk is transmitted only once at the beginning of the TCP
connection. The purpose of the INIT chunk is to transmit flags
indicating which fields will be enabled/disabled in all subsequent
data chunks over the lifetime of the TCP connection.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 |reservd |P|S|T| Chunk Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Conrad & Lei Expires June 18, 2004 [Page 10]
Internet-Draft RSerPool Mapping for TCP December 2003
Chunk Type: 8 bits (unsigned integer)
0x01, indicating INIT chunk
Chunk Flags: 8 bits
The five high order bits are reserved; the sender SHOULD
set them to zero, and the receiver SHOULD ignore them.
The three low order bits are to be intepreted as follows;
0x01: The TSN value is omitted in subsequent DATA chunks.
Additionally, this indicates that the receiver of the
INIT chunk SHOULD omit the TSN on ACK chunks.
0x02: The Stream Number/Stream Seq Number is omitted in
subsequent DATA chunks
0x04: The PPID value is omitted in subsequent DATA chunks
Chunk Length: 16 bits (unsigned integer)
MUST be set to 0x0004.
NOTE: Unlike SCTP, there is no INIT-ACK defined in the RSerPool TCP
mapping protocol.
The following examples illustrate the use of the flags in the INIT
message.
Example 1: Flags in the INIT are 0x00. Data chunk format is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|R R| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Conrad & Lei Expires June 18, 2004 [Page 11]
Internet-Draft RSerPool Mapping for TCP December 2003
Example 2: Flags in the INIT are 0x01. Data chunk format is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|R R| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this example, TSN is implicit from the order in which the chunk
appears in the TCP byte stream.
Example 3: Flags in the INIT are 0x05. Data chunk format is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|R R| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this example, TSN is implicit from the order in which the chunk
appears in the TCP byte stream, and PPID is treated as zero.
Conrad & Lei Expires June 18, 2004 [Page 12]
Internet-Draft RSerPool Mapping for TCP December 2003
Example 4: Flags in the INIT are 0x07. Data chunk format is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|R R| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this example, TSN and Stream Sequence Number are implicit from
the order in which the chunk appears in the TCP byte stream, and
Stream Identifier and PPID are always considered zero.
3.4 ACK Chunk
The figure below illustrates the field format for the ACK chunk. An
RSerPool TCP mapping layer entity MUST transmit exactly one
corresponding ACK chunk over the TCP connection immediately after
delivering each DATA chunk to the upper layer. Each such ACK chunk
SHOULD contain the TSN corresponding to the DATA chunk that was
delivered, unless inclusion of the TSN has been supressed by receipt
of the 0x01 flag value in a previous INIT chunk from the data sender
to the data receiver.
Conrad & Lei Expires June 18, 2004 [Page 13]
Internet-Draft RSerPool Mapping for TCP December 2003
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 |Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative TSN Ack |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
Set to all zeros on transmit and ignored on receipt.
Cumulative TSN Ack: 32 bits (unsigned integer)
This field is OPTIONAL, and SHOULD NOT be included if the side
sending the ack previously received a value of 0x01 in the INIT
from the peer. The receiver of an ACK chunk can determine
whether the TSN field is present by checking whether the length
of the ACK chunk is 4 bytes or 8 bytes.
This field contains the TSN of the last DATA chunk delivered to
the upper layer protocol. Note that this value is implicit from
the position of the ACK chunk in the TCP byte stream.
3.5 HEARTBEAT Chunk
The figure below illustrates the field format for the HEARTBEAT
chunk.
Conrad & Lei Expires June 18, 2004 [Page 14]
Internet-Draft RSerPool Mapping for TCP December 2003
The parameter field contains the Heartbeat Information which is a
variable length opaque data structure understood only by the sender.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Chunk Flags | Heartbeat Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Information TLV (Variable-Length) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
Set to zero on transmit and ignored on receipt.
Heartbeat Length: 16 bits (unsigned integer)
Set to the size of the chunk in bytes, including the chunk header
and the Heartbeat Information field.
Heartbeat Information: variable length
Defined as a variable-length parameter using the format described
in Section 3.2.1, i.e.:
Variable Parameters Status Type Value
-------------------------------------------------------------
Heartbeat Info Mandatory 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Heartbeat Info Type=1 | HB Info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Sender-specific Heartbeat Info /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.6 HEARTBEAT ACK Chunk
The figure below illustrates the field format for the HEARTBEAT ACK
chunk. The RSerPool TCP mapping layer MUST transmit exactly one
HEARTBEAT ACK chunk in response to each HEARTBEAT chunk received.
The Heartbeat Information parameter received in the HEARTBEAT chunk
Conrad & Lei Expires June 18, 2004 [Page 15]
Internet-Draft RSerPool Mapping for TCP December 2003
MUST be included in the HEARTBEAT ACK chunk.
The parameter field contains a variable length opaque data structure which
was received in the HEARTBEAT.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Chunk Flags | Heartbeat Ack Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Information TLV (Variable-Length) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: 8 bits
Set to zero on transmit and ignored on receipt.
Heartbeat Ack Length: 16 bits (unsigned integer)
Set to the size of the chunk in bytes, including the chunk header
and the Heartbeat Information field.
Heartbeat Information: variable length
This field MUST contain the Heartbeat Information parameter of
the Heartbeat Request to which this Heartbeat Acknowledgement is
responding.
Variable Parameters Status Type Value
-------------------------------------------------------------
Heartbeat Info Mandatory 1
4. Protocol Operations
[TBD: In this section describe the basic operation of the protocol.
Most of this is already pretty much spelled out in the descriptions
of the packets, but a few details need to be ironed out, mainly how
and under what conditions the TCP mapping layer decides that a
failure occured. Perhaps the upper layer needs to be able to specify
a timeout value for data, and a heartbeat interval? Are there any
other details that need to specified in this section?]
Conrad & Lei Expires June 18, 2004 [Page 16]
Internet-Draft RSerPool Mapping for TCP December 2003
5. Security Considerations
There are no known additional security considerations over what is
already present for TCP.
6. IANA Considerations
[Open Issue TBD: Will there be an enumeration of the various
transport layer mappings that must be registered with IANA?]
7. Acknowledgements
References
[1] Tuexen, M. and Q. Xie, "Architecture for Reliable Server
Pooling", draft-ietf-rserpool-arch-07 (work in progress),
October 2003.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Loughney, J., "Comparison of Protocols for Reliable Server
Pooling", draft-ietf-rserpool-comp-07 (work in progress),
October 2003.
[4] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution
Protocol (ENRP)", draft-ietf-rserpool-enrp-07 (work in
progress), October 2003.
[5] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate
Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-08
(work in progress), October 2003.
[6] Conrad, P. and P. Lei, "Services Provided By Reliable Server
Pooling", draft-ietf-rserpool-service-00 (work in progress),
December 2003.
[7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
Conrad & Lei Expires June 18, 2004 [Page 17]
Internet-Draft RSerPool Mapping for TCP December 2003
Authors' Addresses
Phillip T. Conrad
University of Delaware
Dept. of Computer and Information Sciences
103 Smith Hall
Newark, DE 19716
US
Phone: +1 302 831 8622
EMail: conrad@acm.org
URI: http://udel.edu/~pconrad
Peter Lei
Cisco Systems, Inc.
8735 W Higgins Rd, Suite 300
Chicago, IL 60631
US
Phone: +1 847 870 7201
EMail: peterlei@cisco.com
Conrad & Lei Expires June 18, 2004 [Page 18]
Internet-Draft RSerPool Mapping for TCP December 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Conrad & Lei Expires June 18, 2004 [Page 19]
Internet-Draft RSerPool Mapping for TCP December 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Conrad & Lei Expires June 18, 2004 [Page 20]
