draft-ietf-rserpool-tcpmapping-02.txt   draft-ietf-rserpool-tcpmapping-03.txt 
Network Working Group P. Conrad Network Working Group P. Lei
Internet-Draft University of Delaware Internet-Draft Cisco Systems, Inc.
Expires: December 10, 2004 P. Lei Expires: April 9, 2006 P. Conrad
Cisco Systems, Inc. University of Delaware
June 11, 2004 October 6, 2005
TCP Mapping for Reliable Server Pooling Enhanced Mode TCP Mapping for Reliable Server Pooling Enhanced Mode
draft-ietf-rserpool-tcpmapping-02.txt draft-ietf-rserpool-tcpmapping-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 10, 2004. This Internet-Draft will expire on April 9, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
This memo defines the shim protocol that maps the requirements of the This memo defines the shim protocol that maps the requirements of the
ASAP protocol [5] to the capabilities of the TCP protocol [7]. In ASAP protocol [5] to the capabilities of the TCP protocol [3]. In
particular, this shim protocol adds the following capabilties that particular, this shim protocol adds the following capabilties that
are required by ASAP, but not provided by TCP: (1) message are required by ASAP, but not provided by TCP: (1) message
orientation, (2) heartbeat messages, (3) multiple streams, and (4) orientation, (2) heartbeat messages, (3) multiple streams, and (4)
undelivered message retrieval (if provided). undelivered message retrieval (if provided).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Brief overview of RSerPool . . . . . . . . . . . . . . . . 3 1.1. Brief overview of RSerPool . . . . . . . . . . . . . . . . 3
1.2 Role of the TCP Mapping Protocol . . . . . . . . . . . . . 3 1.2. Role of the TCP Mapping Protocol . . . . . . . . . . . . . 3
1.3 Consistency of Service . . . . . . . . . . . . . . . . . . 5 1.3. Consistency of Service . . . . . . . . . . . . . . . . . . 5
2. Conventions Used In This Document . . . . . . . . . . . . . . 6 2. Conventions Used In This Document . . . . . . . . . . . . . . 6
3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Basic Chunk Format . . . . . . . . . . . . . . . . . . . . 6 3.1. Basic Chunk Format . . . . . . . . . . . . . . . . . . . . 6
3.2 DATA Chunk . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. DATA Chunk . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 INIT Chunk . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. INIT Chunk . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 ACK Chunk . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4. ACK Chunk . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 HEARTBEAT Chunk . . . . . . . . . . . . . . . . . . . . . 14 3.5. HEARTBEAT Chunk . . . . . . . . . . . . . . . . . . . . . 14
3.6 HEARTBEAT ACK Chunk . . . . . . . . . . . . . . . . . . . 15 3.6. HEARTBEAT ACK Chunk . . . . . . . . . . . . . . . . . . . 15
4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 16 4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
This memo defines the shim protocol that maps the requirements of the This memo defines the shim protocol that maps the requirements of the
ASAP protocol [5] to the capabilities of the TCP protocol [7]. See ASAP protocol [5] to the capabilities of the TCP protocol [3]. See
[6] for details of these mapping requirements. [6] for details of these mapping requirements.
1.1 Brief overview of RSerPool 1.1. Brief overview of RSerPool
The RSerPool framework is designed to provide high availability for The RSerPool framework is designed to provide high availability for
client/server applications. Servers (called "pool elements" or client/server applications. Servers (called "pool elements" or
"PEs") are grouped into "pools". Each pool is named by a "pool "PEs") are grouped into "pools". Each pool is named by a "pool
handle", which is simply an octet string that identifies the pool. handle", which is simply an octet string that identifies the pool.
PEs join or leave a pool by registering and deregistering with an PEs join or leave a pool by registering and deregistering with an
RSerPool nameserver (called an "ENRP server", after the ENRP protocol RSerPool nameserver (called an "ENRP server", after the ENRP protocol
[4] that is used to share information among RSerPool nameservers). [8] that is used to share information among RSerPool nameservers).
Clients (called "pool users" or "PUs") that want to obtain service Clients (called "pool users" or "PUs") that want to obtain service
contact the ENRP server; the PU provides a pool handle, and the ENRP contact the ENRP server; the PU provides a pool handle, and the ENRP
server returns a list of available servers. Associated with each server returns a list of available servers. Associated with each
server is a policy value; the PU then uses a "pool element selection 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 policy" (such as round robin, or least used) to determine which of
the PEs to contact. the PEs to contact.
The ASAP protocol [5] is used to communicate between the PU and the 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 ENRP server, and between the PE and ENRP server, while the ENRP
protocol [4] is used to communicate between and among RSerPool ENRP protocol [8] is used to communicate between and among RSerPool ENRP
nameservers. nameservers.
The RSerPool services framework provides two distinct channels, The RSerPool services framework provides two distinct channels,
control and data, for delivery of RSerPool control messages and control and data, for delivery of RSerPool control messages and
application layer data messages. Mappings provide the adaptions of application layer data messages. Mappings provide the adaptions of
the ASAP services to the specific transport protocols. the ASAP services to the specific transport protocols.
1.2 Role of the TCP Mapping Protocol 1.2. Role of the TCP Mapping Protocol
The actual application-specific communication between the PU and PE The actual application-specific communication between the PU and PE
is defined by the application layer protocol, and does not use the is defined by the application layer protocol, and does not use the
ASAP protocol, per se. However, when failover services (such as ASAP protocol, per se. However, when failover services (such as
forwarding of undelivered/unacknowledged messages) are desired by the forwarding of undelivered/unacknowledged messages) are desired by the
application, all communication between a PU and a PE takes place application, all communication between a PU and a PE takes place
through services provided by RSerPool, and more specifically, by the through services provided by RSerPool, and more specifically, by the
ASAP entity on the PU or PE. Furthermore, in order for the RSerPool ASAP entity on the PU or PE. Furthermore, in order for the RSerPool
framework to provide a consistent set of services for both framework to provide a consistent set of services for both
application-specific data and RSerPool messages, this transport application-specific data and RSerPool messages, this transport
skipping to change at page 4, line 16 skipping to change at page 4, line 16
stream to allow for undelivered message retrieval (see below), and stream to allow for undelivered message retrieval (see below), and
so that ASAP transport services can be consistent between SCTP and so that ASAP transport services can be consistent between SCTP and
TCP. TCP.
(2) Heartbeat Messages. Heartbeats are needed so that a failed (2) Heartbeat Messages. Heartbeats are needed so that a failed
connection can be detected in a timely manner, even if that connection can be detected in a timely manner, even if that
connection is idle. The "keepalive" mechanism provided in some connection is idle. The "keepalive" mechanism provided in some
TCP implementations (but not a standard feature of the protocol; TCP implementations (but not a standard feature of the protocol;
see RFC1122) is not sufficient for this purpose. see RFC1122) is not sufficient for this purpose.
(3) Retreival of Undelivered Messages. A PU can request that the (3) Retreival of Undelivered Messages. A PU can request that the ASAP
ASAP layer detects when the transport layer association/connection layer detects when the transport layer association/connection
between that PU and some PE has failed, and automatically failover 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 to a new PE. In this case, it is necessary for the ASAP layer to
determine which messages were not successfully delivered to the determine which messages were not successfully delivered to the
PE, retrieve them from the transport layer below, and resend them PE, retrieve them from the transport layer below, and resend them
to the new PE. SCTP provides the RETRIEVE_UNSENT primitive to the new PE. SCTP provides the RETRIEVE_UNSENT primitive
(Section 10.1, item (E) of RFC2960) to enable this retrieval. TCP (Section 10.1, item (E) of RFC2960) to enable this retrieval. TCP
has no such facility. has no such facility.
To provide this capability over TCP, the mapping protocol provides To provide this capability over TCP, the mapping protocol provides
another layer of acknowledgements on top of TCP; these acks are another layer of acknowledgements on top of TCP; these acks are
skipping to change at page 5, line 7 skipping to change at page 5, line 7
protocol or the on-the-wire overhead. This is discussed further protocol or the on-the-wire overhead. This is discussed further
in Section 1.3 in Section 1.3
NOTE: PU-PE communication that is NOT mediated by the RSerPool NOTE: PU-PE communication that is NOT mediated by the RSerPool
framework is allowable when the application layer does not require framework is allowable when the application layer does not require
data channel services. In this case, no mapping for application data channel services. In this case, no mapping for application
layer data is used regardless of the transport protocol used as they layer data is used regardless of the transport protocol used as they
will be tranported over the appropriate application-defined tranport will be tranported over the appropriate application-defined tranport
protocol. protocol.
1.3 Consistency of Service 1.3. Consistency of Service
The main benefit of including provision for multiple streams and the The main benefit of including provision for multiple streams and the
PPID field in the RSerPool TCP mapping protocol is "consistency of PPID field in the RSerPool TCP mapping protocol is "consistency of
service." By "consistency of service", we mean that the data service." By "consistency of service", we mean that the data
transport service provided by RSerPool is consistent regardless of transport service provided by RSerPool is consistent regardless of
the underlying transport protocol used. the underlying transport protocol used.
To see the benefit of consistency of service, consider an RSerPool To see the benefit of consistency of service, consider an RSerPool
enabled application that will be used by clients with a wide range of 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 capabilities, e.g. wired desktop PCs at the one end, down to PDAs or
skipping to change at page 6, line 22 skipping to change at page 6, line 22
Thus, for minimal extra cost, "consistency of service" is preserved Thus, for minimal extra cost, "consistency of service" is preserved
by including multiple streams and the PPID field in the TCP mapping. by including multiple streams and the PPID field in the TCP mapping.
It is RECOMMENDED that any future mappings of RSerPool to other It is RECOMMENDED that any future mappings of RSerPool to other
transport protocols SHOULD follow this model of providing transport protocols SHOULD follow this model of providing
"consistency of service" where possible. "consistency of service" where possible.
2. Conventions Used In This Document 2. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [2].
The terms "transmission sequence number" (TSN), "stream number", The terms "transmission sequence number" (TSN), "stream number",
"stream identifier", "stream sequence number", and "payload "stream identifier", "stream sequence number", and "payload protocol-
protocol-id(PPID)" are used in this document with meanings analogous id(PPID)" are used in this document with meanings analogous to their
to their meanings in RFC2960 [8]; it is assumed that the reader is meanings in RFC2960 [4]; it is assumed that the reader is familiar
familiar with these terms as they appear in that document. with these terms as they appear in that document.
Comparisons and arithmetic on TSNs and stream sequence numbers are Comparisons and arithmetic on TSNs and stream sequence numbers are
governed by the rules in Section 1.6 of RFC2960 [8]. governed by the rules in Section 1.6 of RFC2960 [4].
3. Packet Format 3. Packet Format
In the RSerPool TCP mapping protocol, each peer transmits a series of In the RSerPool TCP mapping protocol, each peer transmits a series of
chunks over the TCP byte stream. The format of these chunks is chunks over the TCP byte stream. The format of these chunks is
similar to that of the chunk format of SCTP. similar to that of the chunk format of SCTP.
3.1 Basic Chunk Format 3.1. Basic Chunk Format
The figure below illustrates the field format for the chunks to be The figure below illustrates the field format for the chunks to be
transmitted in the SCTP packet. Each chunk is formatted with a Chunk 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 Type field, a chunk-specific Flag field, a Chunk Length field, and a
Value field. Value field.
0 1 2 3 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 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 Type | Chunk Flags | Chunk Length |
skipping to change at page 7, line 14 skipping to change at page 8, line 4
0 1 2 3 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 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 Type | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Chunk Value / / Chunk Value /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Type: 8 bits (unsigned integer) Chunk Type: 8 bits (unsigned integer)
This field identifies the type of information contained in the This field identifies the type of information contained in the
Chunk Value field. It takes a value from 0 to 254. The value of Chunk Value field. It takes a value from 0 to 254. The value
255 is reserved for future use as an extension field. of 255 is reserved for future use as an extension field.
The values of Chunk Types are defined as follows: The values of Chunk Types are defined as follows:
ID Value Chunk Type ID Value Chunk Type
----- ---------- -------- ----------
0 - Payload Data (DATA) 0 - Payload Data (DATA)
1 - Initiation (INIT) 1 - Initiation (INIT)
2 - reserved by IETF 2 - reserved by IETF
3 - Acknowledgement (ACK) 3 - Acknowledgement (ACK)
4 - Heartbeat Request (HEARTBEAT) 4 - Heartbeat Request (HEARTBEAT)
5 - Heartbeat Acknowledgement (HEARTBEAT ACK) 5 - Heartbeat Acknowledgement (HEARTBEAT ACK)
6 to 255 - reserved by IETF 6 to 255 - reserved by IETF
Chunk Flags: 8 bits Chunk Flags: 8 bits
The usage of these bits depends on the chunk type as given by the The usage of these bits depends on the chunk type as given by
Chunk Type. Unless otherwise specified, they are set to zero on the Chunk Type. Unless otherwise specified, they are set to
transmit and are ignored on receipt. zero on transmit and are ignored on receipt.
Chunk Length: 16 bits (unsigned integer) Chunk Length: 16 bits (unsigned integer)
This value represents the size of the chunk in bytes including the This value represents the size of the chunk in bytes including
Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value
Therefore, if the Chunk Value field is zero-length, the Length fields. Therefore, if the Chunk Value field is zero-length, the
field will be set to 4. The Chunk Length field does not count any Length field will be set to 4. The Chunk Length field does not
padding. count any padding.
Chunk Value: variable length Chunk Value: variable length
The Chunk Value field contains the actual information to be The Chunk Value field contains the actual information to be
transferred in the chunk. The usage and format of this field is transferred in the chunk. The usage and format of this field
dependent on the Chunk Type. is dependent on the Chunk Type.
The total length of a chunk (including Type, Length and Value fields) The total length of a chunk (including Type, Length and Value
MUST be a multiple of 4 bytes. If the length of the chunk is not a fields) MUST be a multiple of 4 bytes. If the length of the chunk
multiple of 4 bytes, the sender MUST pad the chunk with all zero is not a multiple of 4 bytes, the sender MUST pad the chunk with
bytes and this padding is not included in the chunk length field. all zero bytes and this padding is not included in the chunk
The sender should never pad with more than 3 bytes. The receiver length field. The sender should never pad with more than 3 bytes.
MUST ignore the padding bytes. The receiver MUST ignore the padding bytes.
3.2 DATA Chunk 3.2. DATA Chunk
The figure below illustrates the field format for the 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 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 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 for fragmentation (2) the second, third, and fourth 32-bit words are
all optional, and can be supressed (independently) through flags in all optional, and can be supressed (independently) through flags in
the INIT message (as explained further below.) the INIT message (as explained further below.)
All ASAP protocol messages and application-layer data (when sent All ASAP protocol messages and application-layer data (when sent
through the RSerPool framework data channel) MUST be carried in DATA through the RSerPool framework data channel) MUST be carried in DATA
skipping to change at page 9, line 5 skipping to change at page 9, line 42
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved, and bits marked "R": 5 bits and 2 bits, respectively Reserved, and bits marked "R": 5 bits and 2 bits, respectively
The sender SHOULD set all '0's and the receiver SHOULD ignore. The sender SHOULD set all '0's and the receiver SHOULD ignore.
U bit: 1 bit U bit: 1 bit
The (U)nordered bit, if set to '1', indicates that this is an The (U)nordered bit, if set to '1', indicates that this is an
unordered DATA chunk, and there is no Stream Sequence Number unordered DATA chunk, and there is no Stream Sequence Number
assigned to this DATA chunk. Therefore, the receiver MUST ignore assigned to this DATA chunk. Therefore, the receiver MUST
the Stream Sequence Number field. ignore the Stream Sequence Number field.
Length: 16 bits (unsigned integer) Length: 16 bits (unsigned integer)
This field indicates the length of the DATA chunk in bytes from 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 the beginning of the type field to the end of the user data
excluding any padding. field excluding any padding.
TSN : 32 bits (unsigned integer) TSN : 32 bits (unsigned integer)
This value represents the TSN for this DATA chunk. The valid range This value represents the TSN for this DATA chunk. The valid
of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps back to 0 range of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps
after reaching 4294967295. In the TCP mapping protocol (unlike in back to 0 after reaching 4294967295. In the TCP mapping
SCTP), this field MUST start at 0 with each new connection. Also protocol (unlike in SCTP), this field MUST start at 0 with each
note that this field is redundant; TSN of each data chunk is new connection. Also note that this field is redundant; TSN of
implicit by its position in the TCP byte stream. It does server each data chunk is implicit by its position in the TCP byte
the purpose of providing additional robustness against errors in stream. It does server the purpose of providing additional
a sender or receiver protocol implementation, however if desired, robustness against errors in a sender or receiver protocol
it MAY be supressed for the lifetime of the TCP connection via a implementation, however if desired, it MAY be supressed for the
flag in the INIT chunk. lifetime of the TCP connection via a flag in the INIT chunk.
Stream Identifier S: 16 bits (unsigned integer) Stream Identifier S: 16 bits (unsigned integer)
Identifies the stream to which the following user data belongs. Identifies the stream to which the following user data belongs.
If desired, the entire 32-bit word containing Stream Identifier if desired, the entire 32-bit word containing Stream Identifier
and Stream Sequence Number MAY be supressed to save bandwidth; and Stream Sequence Number MAY be supressed to save bandwidth;
in this case, all data chunks MUST be interpreted by the receiver 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 to be part of stream 0, and should be delivered to the end user
as such. as such.
Stream Sequence Number n: 16 bits (unsigned integer) Stream Sequence Number n: 16 bits (unsigned integer)
This value represents the stream sequence number of the following This value represents the stream sequence number of the following
user data within the stream S. Valid range is 0 to 65535. Note user data within the stream S. Valid range is 0 to 65535. Note
that this field, like TSN, is redundant, but it provides extra that this field, like TSN, is redundant, but it provides extra
robustness. robustness.
Note that unlike SCTP, there is no concept of fragmentation in the Note that unlike SCTP, there is no concept of fragmentation in
TCP mapping protocol. the TCP mapping protocol.
Payload Protocol Identifier: 32 bits (unsigned integer) Payload Protocol Identifier: 32 bits (unsigned integer)
This value represents an application (or upper layer) specified This value represents an application (or upper layer) specified
protocol identifier. This value is passed to the TCP mapping protocol identifier. This value is passed to the TCP mapping
layer from the upper layer and sent to its peer. This identifier 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 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 network entities as well as the peer application to identify the
type of information being carried in this DATA chunk. type of information being carried in this DATA chunk.
The IANA assigned SCTP protocol payload identifier value for ASAP The IANA assigned SCTP protocol payload identifier value for
(11) MUST be used for the transport of ASAP messages (eg. RSerPool ASAP (11) MUST be used for the transport of ASAP messages (eg.
control channel messages). RSerPool control channel messages).
The value 0 indicates no application identifier is specified by The value 0 indicates no application identifier is specified by
the upper layer for this payload data. If the application has no the upper layer for this payload data. If the application has
use for this field, it can be supressed for all data chunks over no use for this field, it can be supressed for all data chunks
the lifetime of the TCP connection via a flag in the INIT message. over the lifetime of the TCP connection via a flag in the INIT
message.
User Data: variable length User Data: variable length
This is the payload user data. The implementation MUST pad the 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 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 padding MUST NOT be included in the length field. A sender MUST
never add more than 3 bytes of padding. never add more than 3 bytes of padding.
3.3 INIT Chunk 3.3. INIT Chunk
The figure below illustrates the field format for the 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 The INIT chunk is transmitted only once at the beginning of the TCP
connection. The purpose of the INIT chunk is to transmit flags connection. The purpose of the INIT chunk is to transmit flags
indicating which fields will be enabled/disabled in all subsequent indicating which fields will be enabled/disabled in all subsequent
data chunks over the lifetime of the TCP connection. data chunks over the lifetime of the TCP connection.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 21 skipping to change at page 13, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ User Data (seq n of Stream S) / / User Data (seq n of Stream S) /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this example, TSN and Stream Sequence Number are implicit from In this example, TSN and Stream Sequence Number are implicit from
the order in which the chunk appears in the TCP byte stream, and the order in which the chunk appears in the TCP byte stream, and
Stream Identifier and PPID are always considered zero. Stream Identifier and PPID are always considered zero.
3.4 ACK Chunk 3.4. ACK Chunk
The figure below illustrates the field format for the ACK chunk. An The figure below illustrates the field format for the ACK chunk. An
RSerPool TCP mapping layer entity MUST transmit exactly one RSerPool TCP mapping layer entity MUST transmit exactly one
corresponding ACK chunk over the TCP connection immediately after corresponding ACK chunk over the TCP connection immediately after
delivering each DATA chunk to the upper layer. Each such ACK chunk delivering each DATA chunk to the upper layer. Each such ACK chunk
SHOULD contain the TSN corresponding to the DATA chunk that was SHOULD contain the TSN corresponding to the DATA chunk that was
delivered, unless inclusion of the TSN has been supressed by receipt 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 of the 0x01 flag value in a previous INIT chunk from the data sender
to the data receiver. to the data receiver.
skipping to change at page 14, line 29 skipping to change at page 14, line 29
This field is OPTIONAL, and SHOULD NOT be included if the side This field is OPTIONAL, and SHOULD NOT be included if the side
sending the ack previously received a value of 0x01 in the INIT sending the ack previously received a value of 0x01 in the INIT
from the peer. The receiver of an ACK chunk can determine from the peer. The receiver of an ACK chunk can determine
whether the TSN field is present by checking whether the length whether the TSN field is present by checking whether the length
of the ACK chunk is 4 bytes or 8 bytes. of the ACK chunk is 4 bytes or 8 bytes.
This field contains the TSN of the last DATA chunk delivered to This field contains the TSN of the last DATA chunk delivered to
the upper layer protocol. Note that this value is implicit from the upper layer protocol. Note that this value is implicit from
the position of the ACK chunk in the TCP byte stream. the position of the ACK chunk in the TCP byte stream.
3.5 HEARTBEAT Chunk 3.5. HEARTBEAT Chunk
The figure below illustrates the field format for the HEARTBEAT The figure below illustrates the field format for the HEARTBEAT
chunk. chunk.
The parameter field contains the Heartbeat Information which is a The parameter field contains the Heartbeat Information which is
variable length opaque data structure understood only by the sender. a variable length opaque data structure understood only by the
sender.
0 1 2 3 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 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 | | Type = 4 | Chunk Flags | Heartbeat Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Heartbeat Information TLV (Variable-Length) / / Heartbeat Information TLV (Variable-Length) /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 45 skipping to change at page 15, line 46
0 1 2 3 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 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 | | Heartbeat Info Type=1 | HB Info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Sender-specific Heartbeat Info / / Sender-specific Heartbeat Info /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.6 HEARTBEAT ACK Chunk 3.6. HEARTBEAT ACK Chunk
The figure below illustrates the field format for the HEARTBEAT ACK The figure below illustrates the field format for the HEARTBEAT ACK
chunk. The RSerPool TCP mapping layer MUST transmit exactly one chunk. The RSerPool TCP mapping layer MUST transmit exactly one
HEARTBEAT ACK chunk in response to each HEARTBEAT chunk received. HEARTBEAT ACK chunk in response to each HEARTBEAT chunk received.
The Heartbeat Information parameter received in the HEARTBEAT chunk The Heartbeat Information parameter received in the HEARTBEAT chunk
MUST be included in the HEARTBEAT ACK chunk. MUST be included in the HEARTBEAT ACK chunk.
The parameter field contains a variable length opaque data structure which The parameter field contains a variable length opaque data
was received in the HEARTBEAT. structure which was received in the HEARTBEAT.
0 1 2 3 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 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 | | Type = 5 | Chunk Flags | Heartbeat Ack Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Heartbeat Information TLV (Variable-Length) / / Heartbeat Information TLV (Variable-Length) /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 17 skipping to change at page 17, line 17
There are no known additional security considerations over what is There are no known additional security considerations over what is
already present for TCP. already present for TCP.
6. IANA Considerations 6. IANA Considerations
[Open Issue TBD: Will there be an enumeration of the various [Open Issue TBD: Will there be an enumeration of the various
transport layer mappings that must be registered with IANA?] transport layer mappings that must be registered with IANA?]
7. Acknowledgements 7. Acknowledgements
8 References 8. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "The Internet Standards Process -- Revision 3",
Levels", BCP 14, RFC 2119, March 1997. BCP 9, RFC 2026, October 1996.
[2] Loughney, J., "Comparison of Protocols for Reliable Server [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Pooling", draft-ietf-rserpool-comp-07 (work in progress), Levels", BCP 14, RFC 2119, March 1997.
October 2003.
[3] Tuexen, M., Xie, Q., Stewart, R., Shore, M. and J. Loughney, [3] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
"Architecture for Reliable Server Pooling", September 1981.
draft-ietf-rserpool-arch-07 (work in progress), October 2003.
[4] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
Protocol (ENRP)", draft-ietf-rserpool-enrp-08 (work in H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
progress), June 2004. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[5] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate [5] Stewart, R., "Aggregate Server Access Protocol (ASAP)",
Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-09 draft-ietf-rserpool-asap-12 (work in progress), July 2005.
(work in progress), June 2004.
[6] Conrad, P. and P. Lei, "Services Provided By Reliable Server [6] Lei, P. and P. Conrad, "Services Provided By Reliable Server
Pooling", draft-ietf-rserpool-service-01 (work in progress), Pooling", draft-ietf-rserpool-service-02 (work in progress),
June 2004. October 2005.
[7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [7] Tuexen, M., "Architecture for Reliable Server Pooling",
September 1981. draft-ietf-rserpool-arch-10 (work in progress), July 2005.
[8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [8] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)",
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, draft-ietf-rserpool-enrp-12 (work in progress), July 2005.
"Stream Control Transmission Protocol", RFC 2960, October 2000.
Authors' Addresses 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 Phillip T. Conrad
University of Delaware University of Delaware
Dept. of Computer and Information Sciences Dept. of Computer and Information Sciences
103 Smith Hall 103 Smith Hall
Newark, DE 19716 Newark, DE 19716
US US
Phone: +1 302 831 8622 Phone: +1 302 831 8622
EMail: conrad@acm.org Email: conrad@acm.org
URI: http://udel.edu/~pconrad URI: http://udel.edu/~pconrad
Peter Lei
Cisco Systems, Inc.
8735 W Higgins Rd, Suite 300
Chicago, IL 60631
US
Phone: +1 773 695 8201
EMail: peterlei@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 19, line 41 skipping to change at page 19, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 55 change blocks. 
127 lines changed or deleted 124 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/