Internet DRAFT - draft-ietf-rserpool-tcpmapping
draft-ietf-rserpool-tcpmapping
Network Working Group P. Lei
Internet-Draft Cisco Systems, Inc.
Expires: April 9, 2006 P. Conrad
University of Delaware
October 6, 2005
TCP Mapping for Reliable Server Pooling Enhanced Mode
draft-ietf-rserpool-tcpmapping-03.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 April 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo defines the shim protocol that maps the requirements of the
ASAP protocol [5] to the capabilities of the TCP protocol [3]. 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).
Lei & Conrad Expires April 9, 2006 [Page 1]
Internet-Draft RSerPool Mapping for TCP October 2005
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 . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. INIT Chunk . . . . . . . . . . . . . . . . . . . . . . . . 11
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
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Lei & Conrad Expires April 9, 2006 [Page 2]
Internet-Draft RSerPool Mapping for TCP October 2005
1. Introduction
This memo defines the shim protocol that maps the requirements of the
ASAP protocol [5] to the capabilities of the TCP protocol [3]. 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
[8] 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 [8] 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:
Lei & Conrad Expires April 9, 2006 [Page 3]
Internet-Draft RSerPool Mapping for TCP October 2005
(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
Lei & Conrad Expires April 9, 2006 [Page 4]
Internet-Draft RSerPool Mapping for TCP October 2005
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
Lei & Conrad Expires April 9, 2006 [Page 5]
Internet-Draft RSerPool Mapping for TCP October 2005
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 [4]; 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 [4].
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.
Lei & Conrad Expires April 9, 2006 [Page 6]
Internet-Draft RSerPool Mapping for TCP October 2005
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lei & Conrad Expires April 9, 2006 [Page 7]
Internet-Draft RSerPool Mapping for TCP October 2005
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.
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.
Lei & Conrad Expires April 9, 2006 [Page 8]
Internet-Draft RSerPool Mapping for TCP October 2005
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
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.
Lei & Conrad Expires April 9, 2006 [Page 9]
Internet-Draft RSerPool Mapping for TCP October 2005
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
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
Lei & Conrad Expires April 9, 2006 [Page 10]
Internet-Draft RSerPool Mapping for TCP October 2005
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Lei & Conrad Expires April 9, 2006 [Page 11]
Internet-Draft RSerPool Mapping for TCP October 2005
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) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Lei & Conrad Expires April 9, 2006 [Page 12]
Internet-Draft RSerPool Mapping for TCP October 2005
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.
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.
Lei & Conrad Expires April 9, 2006 [Page 13]
Internet-Draft RSerPool Mapping for TCP October 2005
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.
Lei & Conrad Expires April 9, 2006 [Page 14]
Internet-Draft RSerPool Mapping for TCP October 2005
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
Lei & Conrad Expires April 9, 2006 [Page 15]
Internet-Draft RSerPool Mapping for TCP October 2005
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?]
Lei & Conrad Expires April 9, 2006 [Page 16]
Internet-Draft RSerPool Mapping for TCP October 2005
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
8. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[4] 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.
[5] Stewart, R., "Aggregate Server Access Protocol (ASAP)",
draft-ietf-rserpool-asap-12 (work in progress), July 2005.
[6] Lei, P. and P. Conrad, "Services Provided By Reliable Server
Pooling", draft-ietf-rserpool-service-02 (work in progress),
October 2005.
[7] Tuexen, M., "Architecture for Reliable Server Pooling",
draft-ietf-rserpool-arch-10 (work in progress), July 2005.
[8] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)",
draft-ietf-rserpool-enrp-12 (work in progress), July 2005.
Lei & Conrad Expires April 9, 2006 [Page 17]
Internet-Draft RSerPool Mapping for TCP October 2005
Authors' Addresses
Peter Lei
Cisco Systems, Inc.
8735 W Higgins Rd, Suite 300
Chicago, IL 60631
US
Phone: +1 773 695 8201
Email: peterlei@cisco.com
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
Lei & Conrad Expires April 9, 2006 [Page 18]
Internet-Draft RSerPool Mapping for TCP October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lei & Conrad Expires April 9, 2006 [Page 19]
